Re: [rddp] MPA startup sequence issues (1) and (2)

["Talpey, Thomas" <[e-mail]>]

Okay, I'll bite! :-)

Both the proposed behaviors are appropriate and the spec
should retain them. There is no present motivation which
warrants the added complexity they would entail.

Tom.

At 12:16 PM 3/24/2004, [e-mail] wrote:
>This is the first of several emails whose goal is to achieve
>mailing list consensus on issues discussed in Seoul.  This
>email covers issues (1) and (2), which concern permissible
>startup sequences for MPA.  The Seoul minutes say:
>
>  (1) Fast FPDU return (responder need not wait for first pdu). 
>  Tentative proposal: leave as-is (responder must wait). 
>  No dissension in room.  This is not needed for client/server,
>  as the server expects to wait for the client.  Need to take
>  proposal to the list. 
>
>  (2) Active/Active startup. Tentative proposal: leave as-is (no 
>  support for active/active). No dissension in room.  Note, no 
>  known applications require it.  Need to take proposal to the list.
>
>For both of these issues, the rationale for not supporting
>the expanded functionality (Fast FPDU return, Active/Active
>startup) centers around practical issues for dual-stack
>implementations.  draft-culley-mpa-issueresponses-00.txt
>contains an extensive discussion of these implementations,
>why they're of interest, and the difficulties that these
>two features pose to that class of implementation, which
>the WG clearly considers to be important.
>
>In other words, this is a "what is reasonable to build
>in practice" engineering rationale, as opposed to a "what
>is possible in principle" design rationale, which is a good
>way to go about making decisions in the IETF.  For the
>purpose of starting discussion, since Caitlin Bestler is
>the only person I can recall strongly advocating these
>two features, I believe that there is rough consensus
>not to support them (and hence also not to support them
>in the SCTP mapping for consistency).
>
>Not supporting these features means senders MUST NOT
>attempt them, and they are an error case at the receiver
>if they occur.
>
>For further discussion ...
>
>Thanks,
>--David
>----------------------------------------------------
>David L. Black, Senior Technologist
>EMC Corporation, 176 South St., Hopkinton, MA  01748
>[phone]             FAX: [phone]
>[e-mail]        Mobile: [phone]
>----------------------------------------------------
>
>_______________________________________________
>rddp mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/rddp