Hemal Shah | 3 Jul 04:18 2006

Summary of AD comments addressed in draft-ietf-rddp-ddp-06.txt

David and Lars,

In the latest DDP draft (draft-ietf-rddp-ddp-06.txt), the AD comments were addressed as described below.

Hemal

> > > Abstract could be reworded. DDP provides "information to Place" 

> > > data? Something a bit more elucidating would be appropriate.

> > >

Hemal The abstract is left unchanged as clarification is already provided in the introduction.

> > > Although this document uses 2119 language, it does not have the

> > > standard terminology boilerplate saying that 2119 terms

> are used.

Hemal Standard terminology boilerplate saying that 2119 terms are used was added.

> > > (Note, this is in the I-D Checklist and is something that

> should be

>

> > > caught in PROTO shepherding).

> > >

> > > The first use of MPA in 1.3 should be expanded.

Hemal First use of MPA was expanded.

> >

> > Please check expansion of acronyms throughout.

Hemal made the check.

> >

> > > From the diagram in 1.3, it appears that MPA provides

> services on

> > > top of MPA that are already present in SCTP. Incidentally,

> > > referring to [TCP] as an LLP in the first paragraph of

> 1.3 may lead

>

> > > readers to the wrong place - really, you just want a

> reference to

> > > [MPA] there, I suspect.

Hemal This was fixed by referring to [MPA] and SCTP DDP mapping [SCTPDDP] as LLPs. Reference to [TCP] as an LLP to DDP was removed.

> > >

> > > Also, iWarp is introduced in 1.3, and used a few other places in

> > > the document. Is there an external reference for iWarp?

> It seems a

> > > bit thrown over the wall in this document. A similar

> comment might

> > > apply to rddp-rdmap. Is iWarp the marketing term for this

> protocol

> > > suite?

> > >

Hemal - iWARP is defined in the glossary. Historically, iWARP name has been used to refer to a suite RDDP protocols (RDMAP/DDP/MPA).

> > > While it is generally useful to have a glossary

> ready-to-hand, are

> > > there any differences between sections 2.1 and 2.2 of the

> glossary

> > > in rddp-rdmap and the glossary in rddp-ddp? I'm more

> concerned for

> > > the sake of consistency than in the elimination of redundancy.

Hemal The glossary terms used in 2.1 and 2.2 was checked for consistency. As far as I know, the terms used in DDP and RDMAP drafts are consistent.

> >

> > Same comment I made for rddp-rdmap: Since many of the RDDP

> documents

> > duplicate very similar glossaries, maybe it'd make sense to

> > consolidate the terminology into a single draft, and place a

> > normative reference on it?

Hemal The glossaries were kept in the draft. It may be a good idea to create a new draft that contains all the glossaries. But, at this point, when all drafts are in last-call, creating a new draft which is normatively referenced by other drafts will be too much of a change at the last moment.

> >

> > > Section 3 might be able to use an introductory sentence

> stating the

>

> > > purpose of these requirements. I assume it would be

> something along

>

> > > the lines of : "Any protocol that can serve as an LLP for

> DDP MUST

> > > have the following properties". There is probably a

> further caveat,

>

> > > however, that a protocol specification like [MPA] would

> be required

>

> > > to describe how exactly these properties are provided. If

> so, that

> > > would probably be worth mentioning as well.

> >

> > More than one sentence wouldn't hurt, either...

> >

Hemal This is a good suggestion. A sentence below was added at the beginning of the section.

Any protocol that can serve as an LLP to DDP MUST meet the following requirements.

> > Figures 3-5: It's a bit odd to see these headers/fields

> start at bit

> > 16. Usually, everything starts at bit zero (the ruler indicates

> > length, not offset).

> >

Hemal The figure was left unchanged as the offset seems odd but when put together with MPA, DDP, and RDMAP headers, the headers get aligned on 32-bit boundary with MPA header starting at offset 0.

> > > The mention of TLS at the end of 8.1 is misleading, given

> that the

> > > normative requirements will be for IPSec. Furthermore, TLS isn't

> > > actually transport-agnostic (there are transport protocols that

> > > traditional TLS does not work with).

> > >

Hemal Good point. The text on TLS was clarified and DTLS reference was added. Also, common security sections in DDP and RDMAP drafts were made consistent.

> > > As is the case with rddp-rdmap, I'm a little concerning

> generally

> > > about summarization in the Security Considerations of

> informative

> > > text that is covered in greater detail in the rddp-security

> document.

> > >

Hemal The text in DDP draft gives the reader one single draft where the implementers can read security considerations for DDP (this comes with some duplication with rddp-security draft, but I think it is OK). The rddp-security draft covers all the security requirements for DDP/RDMAP in greater details.

> > > Just to make things clear, please preface section 9 with "This

> > > document does not specify any actions for the IANA."

> > >

Hemal The statement above was added in section 9.

> > > Is the appendix (section 11) intended to be normative? I

> see some

> > > normative statements in it. As far as I can tell, there are no

> > > references in the main body of the text to Section 11. Since the

> > > guidance in Section 11 seems to pertain to LLP implementations,

> > > perhaps there could be a forward reference in Section 3?

> Otherwise,

>

> > > I'm concerned that implementors might miss the appendix

> entirely. 

> > > Alternatively, some additional text putting the appendix

> in context

>

> > > might be useful.

> > >

Hemal Section 11 is mainly provides guidance to LLP implementers.

> > > Also copied from the rddp-rdmap comments, applicable to this

> > > document as well:

> > >

> > > One does not typically include in an acknowledgments section the

> > > contact information for each individual. Using full names in

> > > concert with a brief description of the role that they played is

> > > usually a bit more helpful. There is sometimes a practice

> of having

>

> > > a "Contributors" section, which distinguishes the editors of the

> > > document (who are credited in the author's list) from a

> vast number

>

> > > of people who have contributed text to the document.

> Contributors

> > > are sometimes listed in the same fashion authors are (with full

> > > contact information).

> >

Hemal The sections name was changed to Contributors.

> > Lars

> > --

> > Lars Eggert                                     NEC Network

> > Laboratories

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
Black_David | 14 Jul 01:36 2006

Draft status report

Here's a report on the status of our drafts, coming near the
end of the Montreal IETF meeting week:

The Security and Applicability drafts are close to approval.
There is one outstanding Discuss against the Security draft
that should be cleared shortly, and there are a number of
RFC Editor Notes that will appear as clarifications.

The RDMAP and DDP drafts are close to IETF Last Call.  The
remaining step is that the authors of the RDMAP draft need
to send a note to the list containing the comments that were
considered in the revision and how they were dealt with, ASAP.
The corresponding email for the DDP draft was:

http://www1.ietf.org/mail-archive/web/rddp/current/msg02445.html

The SCTP draft is basically done, and is likely to go to IETF
Last Call with the RDMAP and DDP drafts.

The MPA draft is going to need another significant revision,
in accordance with what I explained in:

http://www1.ietf.org/mail-archive/web/rddp/current/msg02442.html

I was able to talk to Joe Touch (the primary TCPM) reviewer,
and worked out an approach - the approach is documented in
these slides, which were used at the TCPM meeting today,
and engendered no objection:

http://www3.ietf.org/proceedings/06jul/slides/tcpm-4.pdf

A couple of important notes that go with this approach:
- The Appendix is free to use whatever language is necessary
	to explain how to optimize MPA with TCP, but needs
	to avoid RFC 2119 requirements words (e.g., MUST,
	SHOULD).
- The Appendix needs to contain a sentence saying that if
	any of its implementation optimization guidance appears
	to contradict any of the RFCs that specify TCP, the
	TCP RFCs are the authority.
With that, MPA is essentially finished with Expert Review,
but does require fairly extensive revision.

I will work directly with the MPA draft authors on that revision
as there's a fair amount to be done, and it's important to get
it right, but the path forward is now clear.

Thanks,
--David (rddp WG chair) 
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
The IESG | 19 Jul 23:47 2006
Picon

Last Call: 'Direct Data Placement over Reliable Transports' to Proposed Standard (draft-ietf-rddp-ddp)

The IESG has received a request from the Remote Direct Data Placement WG to 
consider the following documents:

- 'A Remote Direct Memory Access Protocol Specification '
   <draft-ietf-rddp-rdmap-06.txt> as a Proposed Standard
- 'Direct Data Placement over Reliable Transports '
   <draft-ietf-rddp-ddp-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-08-02.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-rddp-rdmap-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-rddp-ddp-06.txt
The IESG | 27 Jul 05:42 2006
Picon

Protocol Action: 'DDP/RDMAP Security' to Proposed Standard

The IESG has approved the following documents:

- 'DDP/RDMAP Security '
   <draft-ietf-rddp-security-10.txt> as a Proposed Standard
- 'Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data 
   Placement (DDP) '
   <draft-ietf-rddp-applicability-08.txt> as an Informational RFC

These documents are products of the Remote Direct Data Placement Working Group. 

The IESG contact persons are Jon Peterson and Magnus Westerlund.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-10.txt

Technical Summary

The RDDP Applicability document provides a description of why RDDP is needed,
what services it supplies, and how it interacts with layers above and below it.
It furthermore shows how RDDP compares with the use of traditional RDMA (not
over IP) and the use of traditional Internet transport in the absence of RDDP.

The RDDP Security document provides guidance on the threats and
countermeasuresin the RDDP space, and prescribes normative guidance for RDDP
implementations.

Working Group Summary

The RDDP WG supports the advancement of these documents as primary outputs of
the WG.

Protocol Quality

Jon Peterson performed AD review of these documents. Derek Atkins reviewed the
security draft on behalf of the Security Directorate. Joel Halpern reviewed
bothdrafts on behalf of GEN-ART.

Note to RFC Editor

RFC Editor Notes for draft-ietf-rddp-applicability-08.txt

(1) Section 1, after:

   o  RDMAP defines RDMA Reads, which allow remote access to advertised
      buffers.  This document will review the advantages of using RDMA
      Reads as contrasted to alternate solutions.

Add the following sentence as a separate paragraph:

   A more comprehensive introduction to the RDMAP and DDP protocols and
   discussion of their security considerations can be found in [6].

(2) In section 6.6.1 and 6.7.1 remove usage of RFC 2119 terms as follows.
OLD:
   It is mandatory for MPA/TCP implementations to implement CRC32c, but
   it is NOT mandatory to use the CRC32c during an RDMA connection.
         ^^^
Change:  not

OLD:
   Applications SHOULD trust that this administrative option will only
NEW:
   Applications should assume that disabling CRC32c will only

OLD:
   Applications SHOULD NOT apply additional
   protection as a guard against this administrative option being turned
   on inadvertently.
NEW:
   Applications should not use additional integrity checks based solely
   on the possibility that CRC32c could be disabled without equivalent
   integrity checks at a lower level.

OLD:
   Administrators MUST NOT enable CRC32c suppression unless the end-to-
   end protection is truly equivalent.
NEW:
   CRC32c must not be disabled unless equivalent or better end-to-end
   integrity protection is provided.

OLD:
   If both ends have been configured NOT to use the CRC, then this is
                                     ^^^
Change:                              not

OLD (6.7.1):
      As covered elsewhere in this document, flow control of untagged
      messages MUST be provided by the ULP itself.
NEW:
      As covered elsewhere in this document, flow control of untagged
      messages is the responsibility of the ULP.

(3)  Section 3.2
OLD:
   Content access applications are primary examples of applications with
   both high bandwidth and a high ratio of content transferred per
   required ULP interaction.
NEW:
   Content access applications are important examples of applications that
   require high bandwidth and can transfer a significant amount of content
   between required ULP interactions.

(4) Section 4.3
OLD:
   A ULP where all exchanges would naturally be untagged messages would
   derive virtually no benefit from the use of RDMAP/DDP as opposed to
   SCTP directly. 
NEW:
   If a ULP cannot effectively use tagged messages, it would derive
   little benefit from use of RDMAP/DDP by comparison to direct use of SCTP.

(5) Section 6.9.1
OLD:
   However, the same
   source/destination pair of ports can be re-used sequentially subject
   to normal TCP rules.
NEW:
   However, the same
   source/destination pair of ports can be re-used for a subsequent TCP
   connection, as allowed by TCP.

RFC-Editor note for rddp-security:

In Section 5.4.2, do the following
1) Change "[RFC 2246]" to "[RFC 4346]"
2) Remove the paragraph starting with "1.  The maximum length supported"
3) Make the following change to the resulting text:

OLD:
   If TLS is layered underneath RDMAP, there are at least two 
   limitations that make TLS inappropriate for DDP/RDMA security:

 2.  TLS is a connection oriented protocol.

NEW:
   If TLS is layered underneath RDMAP, TLS's connection orientation
   makes TLS inappropriate for DDP/RDMA security.

Add the following informative reference:

[RFC 4346] T. Dierks and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.

In Section 5.4.1, make the following change:
OLD:
   2.  Per-packet data source authentication - protects against the 
       following spoofing attacks: network based impersonation 
       (Section 5.1.1), Stream hijacking (Section 5.1.2), and man in 
       the middle (Section 5.1.3). 

   3.  Per-packet integrity - protects against tampering done by 
       network based modification of buffer content (Section 5.2)

NEW:
   2.  Per-packet data source authentication - protects against the 
       following spoofing attacks: network based impersonation 
       (Section 5.1.1) and Stream hijacking (Section 5.1.2).

   3.  Per-packet integrity - protects against tampering done by 
       network based modification of buffer content (Section 5.2)
       and when combined with authentication, also protects against
       man in the middle (Section 5.1.3).

IESG Note

 (Insert IESG Note here)

IANA Note

 (Insert IANA Note here)
The IESG | 27 Jul 05:57 2006
Picon

Last Call: 'Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation' to Proposed Standard (draft-ietf-rddp-sctp)

The IESG has received a request from the Remote Direct Data Placement WG to 
consider the following document:

- 'Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) 
   Adaptation '
   <draft-ietf-rddp-sctp-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-08-09.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-rddp-sctp-06.txt
Black_David | 28 Jul 01:14 2006

Draft status report - update

Update:

The Applicability and Security drafts have been approved for
publication as RFCs and should be in the RFC Editor's Queue
shortly.

The RDMAP and DDP drafts are in IETF Last Call, ending August 2nd.

The SCTP draft is in IETF Last Call, ending August 9th.

The MPA draft should be revised in the next few weeks.

We're making progress.

Thanks,
--David

-----Original Message-----
From: Black_David <at> emc.com [mailto:Black_David <at> emc.com] 
Sent: Thursday, July 13, 2006 7:37 PM
To: rddp <at> ietf.org
Subject: [rddp] Draft status report

Here's a report on the status of our drafts, coming near the
end of the Montreal IETF meeting week:

The Security and Applicability drafts are close to approval.
There is one outstanding Discuss against the Security draft
that should be cleared shortly, and there are a number of
RFC Editor Notes that will appear as clarifications.

The RDMAP and DDP drafts are close to IETF Last Call.  The
remaining step is that the authors of the RDMAP draft need
to send a note to the list containing the comments that were
considered in the revision and how they were dealt with, ASAP.
The corresponding email for the DDP draft was:

http://www1.ietf.org/mail-archive/web/rddp/current/msg02445.html

The SCTP draft is basically done, and is likely to go to IETF
Last Call with the RDMAP and DDP drafts.

The MPA draft is going to need another significant revision,
in accordance with what I explained in:

http://www1.ietf.org/mail-archive/web/rddp/current/msg02442.html

I was able to talk to Joe Touch (the primary TCPM) reviewer,
and worked out an approach - the approach is documented in
these slides, which were used at the TCPM meeting today,
and engendered no objection:

http://www3.ietf.org/proceedings/06jul/slides/tcpm-4.pdf

A couple of important notes that go with this approach:
- The Appendix is free to use whatever language is necessary
	to explain how to optimize MPA with TCP, but needs
	to avoid RFC 2119 requirements words (e.g., MUST,
	SHOULD).
- The Appendix needs to contain a sentence saying that if
	any of its implementation optimization guidance appears
	to contradict any of the RFCs that specify TCP, the
	TCP RFCs are the authority.
With that, MPA is essentially finished with Expert Review,
but does require fairly extensive revision.

I will work directly with the MPA draft authors on that revision
as there's a fair amount to be done, and it's important to get
it right, but the path forward is now clear.

Thanks,
--David (rddp WG chair) 
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

Gmane