Alfred, Thanks for these comments. Please find my responses and proposed actions inline below. Best regards, Mark Watson On 4/3/09 9:28 AM, "ah@xxxxxxxxx" <ah@xxxxxxxxx> wrote: > I have studied your Internet-Draft in IETF Last Call, > draft-ietf-rmt-bb-lct-revised-09, > and would like to submit a few comments. > > > (A) Prose++ > > I personally would have appreciated it very much if the > lengthy prose in Sections 1..4, with all of these more-or-less > repetitions of similar arguments (some of which discussed again > in Sections 6..8), would have been condensed by at least a > factor of two. > This all was o.k. in RFC 3451, where the technology was new and > the authors spent much time and paper to convince the audience > that this kind of framework specification is a useful document; > but now that things have settled, I expected a Proposed Standard > document to be more concise. > > However, this observation should not stop the draft at this stage. > > I have some sympathy. Unfortunately this suggestion was never made during the update process. > > (B) Technical > > I found no serious technical issues with the normative parts of the > document. > > Since we know that this is only a framework, it must be accepted > that the normative language is less strong, and the number of > possible options and variations is much larger than in a complete > protocol specification. However I fear this would be prohibitive > -- under the existing rules for the Standards Track -- for a future > promotion of this document to DS. > > A small detail should be reconsidered, however: > > Section 5.2.2 specifies an overloading of the ERT flag and ERT field: > > | Expected Residual Time (ERT): ERT flag, corresponding 32 bit time > | value > | > | This timing information represents the sender expected residual > | transmission time for the current session or for the transmission > | of the current object. If the packet containing the ERT timing > | information also contains the TOI field, then ERT refers to the > | object corresponding to the TOI field, otherwise it refers to the > | session. > > This overloading seems to be potentially dangerous; it prematurely > excludes the possibility to specify a session ERT value whenever > a session carries multiple objects and hence needs to make use of > TOI in every packet. > Wouldn't it be a more clean solution to spent another bit and > optional field, to achieve a clean separation of both Object ERT > and Session ERT ? > > I raised this question on the RMT list and the conclusion there was to clarify the ERT should always be the end time of the current object. The possibility to separately specify the end time of the current session is not believed to be useful, but could anyway be added in future in another document if needed (with an LCT header extension). > (C) Security > > I have some issues with the Security Considerations. > The text on possible mitigations there has been minimized. > Yet, some of these issues are laudably discussed in other parts of > the document; so it would be very useful to have pointers to the > precise locations of these discussions be placed into Sect. 8.*. > Ok. I will add such pointers. > > (D) Editorial flaws (in textual order) > > <omitting purely editorial comments - I will implement all these> > > (10) Section 5.1 > > (10a) 1st paragraph below Figure 1 > > The draft says: > > The function and length of each field in the default LCT header is > | the following. Fields marked as "1" mean that the corresponding bits > | MUST be set to "1" by the sender. Fields marked as "r" or "0" mean > | that the corresponding bits MUST be set to "0" by the sender. > > The last two sentences are dangerous in two aspects, and almost moot. > > First, it is potentially confusing to include numerical values in > double quotes; this could be interpretted as denoting a (ASCII) > string constant, not a binary value. > Thus, the quotes should be dropped from the phrases > set to "1" > and > set to "0" > > Next, Figure 1 contains a field labelled "O", which in printned > form can easily be confused with what the above text refers to as > field marked ... "0" . > The 'MBZ' rule does not apply to the field labelled "O". > > However, the whole document does not contain any fields marked as > either "1" or "0", and also no more field marked as "r". > (There now is a single field marked "Res", but that has an extra > paragraph of explanation.) > > Therefore, I strongly suggest to simply drop these sentences > and replace the paragraph by the shortened form: > > The function and length of each field in the default LCT header is > | the following. > Agreed. > > (15) Section 9.2, 1st paragraph -- incomplete URN > > The URN given apparently is incomplete (cf. 9.1!); > further, I strongly suggest to force the whole URN on a single line > for clarity. > > | This document registers two values in the namespace "ietf:rmt:lct: > | headerExtensionTypes:variableLength" as follows: > --- > | This document registers two values in the namespace > | "ietf:rmt:lct:headerExtensionTypes:variableLength:ietf" as follows: > ^^^^^ > Based on a discussion on the list in response to IANA comments, we will remove the URNs and simply establish a single registry for the LCT Header Extension Types. > (16) Section 11, 1st bullet > > This bullet is bogus: > > | o Update all references to the obsoleted RFC 2068 to RFC 2616 > > Neither did RFC 3451 contain a reference to RFC 2068, nor does this > draft contain a reference to RFC 2616. > RFC 3451 referred to RFC 2616, but the specifics of alternative > methods to SDP (for session descriptions) have been dropped entirely > from this memo. > > So please delete this bullet. > Agreed. > > Kind regards, > Alfred HÎnes. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@xxxxxxxxx | > +------------------------+--------------------------------------------+ > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf