Subject: Re: [rddp] RDDP status of drafts

From: "Talpey, Thomas" <[email-masked]>
Date: Tue, 2 Mar 2004 00:28:40 -0800

I believe there are some in-progress edits on the RDMAP
authors' plate, but the document wasn't resubmitted before
the meeting. Renato, can you confirm?

Tom.

At 03:12 AM 3/2/2004, [email-masked] wrote:
>Here's what the WG chair believes the current status of
>drafts in the RDDP WG to be (if anything seems wrong here,
>please let me know):
>
>IETF RDDP WG Draft Status - March 2004, Seoul IETF meetings
>-----------------------------------------------------------
>
>-- Problem Statement and Architecture
>
>draft-ietf-rddp-problem-statement-03.txt
>draft-ietf-rddp-arch-04.txt
>
>To become Informational RFCs.
>
>Finished WG Last Call, and have been revised to respond to comments
>from our Area Director.  Further IESG discussion has generated
>additional comments that will require further revisions.
>
>-- Main Protocols
>
>DDP (draft-ietf-rddp-ddp-02.txt)
>RDMAP (draft-ietf-rddp-rdmap-01.txt)
>
>To become Proposed Standard RFCs.
>
>No technical issues meriting substantial meeting time.  Waiting
>on security draft (which will probably generate revisions to
>the security considerations sections in these drafts)
>before going to WG Last Call
>
>-- Applicability Statement
>
>draft-ietf-rddp-applicability-01.txt
>
>To become an Informational RFC.
>
>Believed to be in good shape - please review.
>
>-- SCTP Mapping
>
>draft-ietf-rddp-sctp-00.txt
>
>To become a Proposed Standard RFC.
>
>Despite the -00 version number, this is the fourth version of this draft,
>and
>it is relatively mature.
>
>-- TCP Mapping
>
>draft-ietf-rddp-mpa-00.txt
>
>To become an Informational RFC.
>
>The major open issues in this draft involve connection initiation/
>startup.  Substantial meeting time allocated to make progress.
>
>draft-cully-mpa-issuesresponses-00.txt
>
>Will not become an RFC.  This draft describes issues raised about
>MPA and the views of the MPA authors on those issues.
>
>-- Security
>
>draft-ietf-rddp-security-01.txt
>
>Whether this will be Informational vs. Proposed Standard is TBD.
>This draft is on the critical path to completing the DDP and RDMAP
>drafts.  Substantial meeting time has been allocated to it.
>
>
>_______________________________________________
>rddp mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Sukanta Ganguly" <[email-masked]>
Date: Tue, 2 Mar 2004 09:38:48 -0800

Caitlin,
   Even though for the consensus I will say that it is OK to remove the
TCP SCTP adaptation for the Active-Active requirements, I still think it
is worth the effort to probably have a separate effort in defining those
elements for Active-Active model and also a mix of an active-active and
an active-passive for a good failover solution that can be coined in
this area.
   The more I think about the more it makes sense to have some sort of a
standardization in this area for a "near-zero packet loss architecture"
to be defined under this arena. This may become a generic mechanism so
that can it can applied to a non-rdma space too.

Thanks
SG

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2004 8:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rddp] RDDP status of drafts

On Mar 2, 2004, at 2:12 AM, [email-masked] wrote:

> and it is relatively mature.

Earlier I raised the question as to whether the TCP and
SCTP adaptations should be brought into alignment on
support for Active-Active session initiation.

I believe the consensus from reflector discussion was that
it was not worthwhile to add this functionality to MPA/TCP.

I suggest a quick poll at the WG meeting and/or reflector as
to whether the Active-Active support should be removed from
the SCTP mapping. As that legal sessions are defined by an
enumeration of legal patterns, removing one is a very simple
edit should that be the consensus.

I personally remain ambivalent on the issue, seeing both the
merits of flexibility and of eliminating test cases.

---

From: Michael Krause <[email-masked]>
Date: Wed, 03 Mar 2004 06:46:03 -0800

Concur that removal is fine at this time.  If there is demonstrated need at 
later date, then an update can be generated.

Mike