Author(s), I just had a fresh look at the -07 version of this draft and I felt that all of my commments were addressed. However, in one case the fix actually makes it harder to read.
I had pointed out that MPA was not expanded anywhere in the draft. Caitlin had suggested that a reference could be added. This is what happened, however the reference replaces the one instance of the word - so it is not immediately clear what the reference refers to. The new text reads: "DDP Segments are as defined in [I-D.ietf-rddp-ddp]. The DDP Segment Chunk serves the same purpose as the [I-D.ietf-rddp-mpa] Upper Layer PDU (MULPDU) in that it carries DDP Segments over a reliable protocol with added sequencing information." The problem is that - by replacing the acronym MPA with the reference [I-D.ietf-rddp-mpa], it is not immediately obvious what the 'M' in "MULPU" stands for (until and unless you are able to pick up on the fact that this reference defines MPA). I suggest adding "MPA" back in - along the lines of: "... the MPA [I-D.ietf-rddp-mpa] Upper Layer PDU (MULPDU) ..." This seems awkward (it might have better to add MPA to the list of acronyms, defined in section 2, and inserted the reference there), but it takes a bit less thought to follow this way. Chances are this could be handled as a note to the RFC Editor. -- Eric --> -----Original Message----- --> From: Gray, Eric --> Sent: Wednesday, August 09, 2006 3:29 PM --> To: 'Caitlin Bestler'; 'Randall R Stewart' --> Cc: [email protected]; 'Lars Eggert' --> Subject: [Gen-art] Gen-ART LC review of draft-ietf-rddp-sctp-06 --> --> --> --> I am the assigned Gen-ART reviewer for this document. --> For background --> on Gen-ART, please see the FAQ at: --> --> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html --> --> Please consider these comments along with any other last --> call comments you --> may receive. --> --> Document: draft-ietf-rddp-sctp-06 ("Stream Control --> Transmission Protocol --> (SCTP) Direct Data Placement (DDP) Adaptation") --> --> Authors: Caitlin Bestler, Randall R. Stewart --> Shepherding AD: Lars Eggert --> --> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> +++++++++++++++++ --> --> I have one minor question/issue and a few editorial --> NITs to point --> out as part of this last call review. --> --> Comments/Questions/Issues --> ========================= --> --> Section 7.2 seems incomplete. From the text, it appears --> that support for --> multiple IP addresses is allowed by this proposal. --> However, for this to --> work, this would need to be something that both SCTP --> end-points are able --> to handle, or it should not be done by either. How is this --> "capability" --> negotiated? --> --> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> +++++++++++++++++ --> --> NITs --> ---- --> --> One term is not used consistently in this document: --> DDP-SSN. It is expanded --> as (DDP) "Source Stream Sequence" (in its definition), as --> "Stream Sequence" --> (in the defintion of "DDP Segment Chunk") and "Source --> Sequence Number" (in --> sections 5.2.1 and 6). In all of these places, it probably --> should have been --> (DDP) "Stream Sequence Number" as it is obviously analogous --> to "STCP Stream --> Sequence Number" (which - AFAIK - is used consistently this --> way in the draft) --> based on the following excerpt: --> --> "The DDP-SSN MUST have the same value that the SCTP Stream --> Sequence Number --> (SSN) would have been assigned had ordered SCTP Payload --> Data Chunks been --> used rather than unordered." --> --> On that basis, I suggest changing all expansions of DDP-SSN --> to either omit --> the expansion (relying on the fact that is is provided in --> the definitions --> section) or replace the expansion with "DDP Stream Sequence Number". --> --> ------------------------------------------------------------ --> ------------------- --> --> The following terms and/or acronyms should be added to --> section 2 (Definitions): --> --> LLP - this is expanded as "lower layer protocol" (I believe --> it should be "Lower --> Level Protocol entity") in section 4 but occurs in earlier --> text unexpanded. --> --> ULP - this is not expanded anywhere but I assume it is --> meant to be "Upper Layer --> (or Level) Protocol (entity)." This term appears in the --> draft almost as often --> as the definite article "the". --> --> MPA - This term is used in the expansion of "MULPDU" --> (section 5.2.2) but is not --> itself expanded anywhere in the draft. --> --> MULPDU - this is expanded as "MPA Upper Layer PDU" in --> section 5.2.2 but is used --> in the definition of "DDP Segment" in section 2. --> --> ------------------------------------------------------------ --> ------------------- --> --> In the definition of "SCTP endpoint" - in section 2 - you --> use "a SCTP port" in --> one line and "an SCTP endpoint" in the next. Shouldn't it --> be consistently one --> or the other ("a" or "an")? --> --> ------------------------------------------------------------ --> ------------------- --> --> In section 5.2.3, the second paragraph - first sentence - --> should read: --> --> "ULP supplied Private Data MUST be included for DDP Stream --> Session Initiate, --> DDP Stream Session Accept and DDP Stream Session Reject messages." --> --> (Comma inserted after "Initiate") --> --> ------------------------------------------------------------ --> ------------------- --> --> It would help if the 3rd paragraph in section 6.6 were --> reworded to use a bit --> more precise terminology. Currently, it says: --> --> "This MAY be determined by SCTP acking of the Data Chunk --> used to carry the --> DDP Stream Session Initiate message, or by receipt of a --> responsive DDP --> Stream Session Control message." --> --> ------------------------------------------------------------ --> ------------------- --> --> I assume that it should be "Stream Identifier" (rather than --> simply "Stream") --> in the 4th paragraph of the same section (6.6). Currently it says: --> --> "A DDP Stream MUST NOT be re-used for another DDP Stream --> Session while any --> Data Chunk from a prior session might be outstanding." --> _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
