Summary of AD comments addressed in draft-ietf-rddp-ddp-06.txt
2006-07-03 02:18:53 GMT
David and Lars,
In the latest DDP draft (draft-ietf-rddp-ddp-06.txt), the AD comments were addressed as described below.
> > > 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
> > > 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
> > > 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
> > 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
> > > about summarization in the Security Considerations of
> > > text that is covered in greater detail in the rddp-security
> > >
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?
> > > I'm concerned that implementors might miss the appendix
> > > 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.
> > > 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
_______________________________________________ rddp mailing list rddp <at> ietf.org https://www1.ietf.org/mailman/listinfo/rddp