I just think its a little harsh to mandate
that we MUST shut everything down because of a bad informational message.
If that's what the sender of the bad data wants to do (when it get
the fault) then ok - but I'm not convinced the spec should mandate it.
-Doug
"Bob Freund-Hitachi"
<>
07/27/2006 03:38 PM
To
"Anish Karmarkar" <>,
Doug Davis/Raleigh/IBM@IBMUS
cc
"Bob Freund-Hitachi" <>,
"[WS-RX]" <>
Subject
RE: [ws-rx] proposal to address issue
140
Yes,
Sequence spoofing is possible, but hopefully solved with proper
application of the security countermeasures.
The other possibility is a bad implementation.
Should an invalidSequence actually occur, then we do not have a reliable
transfer with consistent sequence state knowledge on both sides of the
transfer. invalidSequence is not far from DANGER DANGER WILL ROBINSON
Thanks
-bob
-----Original Message-----
From: Anish Karmarkar [mailto:]
Sent: Thursday, July 27, 2006 3:01 PM
To: Doug Davis
Cc: Bob Freund-Hitachi; [WS-RX]
Subject: Re: [ws-rx] proposal to address issue 140
Doug Davis wrote:
>
> Bob,
> for InvalidAck - should it really close the sequence? Since
Acks
are
> just informational I'm not so sure they should initiate the closing
down
> of a sequence even when they have bad data - I'd prefer to let the
> receiver of the InvalidAck fault make that decision for itself ( see
> 5.1.3).
Yes, I see your point about seq spoofing. Agree.
> for seqClosed - I don't think the "action upon receipt"
should be to
> terminate - I think 'close' would be more appropriate.
>
Makes sense.
> btw - there were changes to the expires text in the pdf - I'm assuming
> those were left over from other other work and not related to this,
right?
>
Not sure which changes you are talking about.
The only changes are in section 4 and in section 3.4.
Note that the PDF uses WD-15 as the base.
> -Doug
>
>
>
> *"Bob Freund-Hitachi" <>*
>
> 07/27/2006 05:59 AM
>
>
> To
> "[WS-RX]"
<>
> cc
>
> Subject
> [ws-rx]
proposal to address issue 140
>
>
>
>
>
>
>
>
> Anish has been kind enough to prepare the attached draft proposal
to
> address issue 140.
>
> While preparing this draft, some additional points were raised which
we
> enumerate below:
>
> Sequence Terminated Fault:
> There is no text that details under what conditions a sequence
> terminated fault might be raised other than mention of a vague
"protocol
> error".
> One way to address this is to list some or all of the conditions in
> section 4, however it is more concise to represent these in the state
> tables of appendix D were normative.
>
> Unsupported Selection
> This fault description deserves elucidation
>
> Thanks
> -bob[attachment "wsrm-1.1-spec-wd-15-issue140.pdf" deleted
by Doug
> Davis/Raleigh/IBM]
