[rddp] 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 section's name was changed to Contributors.
> > Lars
> > -- 
> > Lars Eggert                                     NEC Network 
> > Laboratories