Hi Robert, Thanks for your clarification of normative references to work in progress.
I would prefer to keep the reference as in the updated version -09: "The FPs in such a scenario should behave as Backbone Routers (6BBR) as defined in [I-D.ietf-6lo-backbone-router]." Are you OK with that? Best regards, Jens -----Original Message----- From: Robert Sparks [mailto:[email protected]] Sent: 17. december 2016 00:31 To: Jens Toftgaard Petersen <[email protected]>; General Area Review Team <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: Gen-art LC review: draft-ietf-6lo-dect-ule-08 Just one comment at the end: On 12/15/16 4:04 PM, Jens Toftgaard Petersen wrote: > Hi Robert, > > Many thanks for your review. See my comments and answers inline below. > > Best regards, > Jens > > -----Original Message----- > From: Robert Sparks [mailto:[email protected]] > Sent: 28. november 2016 21:22 > To: General Area Review Team <[email protected]>; [email protected]; > [email protected]; [email protected] > Subject: Gen-art LC review: draft-ietf-6lo-dect-ule-08 > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-6lo-dect-ule-08 > Reviewer: Robert Sparks > Review Date: 28 Nov 2016 > IETF LC End Date: 02 Dec 2016 > IESG Telechat date: 15 Dec 2016 > > Summary: Ready with nits > > Nits/editorial comments: > > First, forgive me, but I need to grumble a little bit: > > The way this document approaches standardization makes me very uncomfortable. > The language is passive and relies on inference to the point that it risks > being vague. If this review were earlier in the document's life-cycle, I > would strongly suggest a complete restructure focusing on explicitly > specifying what the implementation is supposed to do. > > But, the document has had several reviewers who didn't trip up on this point, > and the working group believes it is implementable, so I'm going to set that > aside and provide some concrete suggestions for removing some nits from the > existing text. > > In document order: > > 1) In section 2.1 "This draft defines 6LoPAN as one of the possible protocols > to negotiate". That's not what this draft appears to do. Rather, it defines > behavior once this 6LoPAN over DECT ULE has been negotiated. Some other > document is defining the negotiation. I suggest replacing the sentence with > "[TS102.939-1] defines this negotiation and specifies an Application Protocol > Identifier of 0x06 for 6LowPAN. This document defines the behavior of that > Application Protocol". > > [Jens]: Very good comment and suggested wording. Is implemented in > revision -09 > > 2) The "not recommended" in the last sentence of 2.3 looks like it > should be a > 2119 keyword (NOT RECOMMENDED). Similarly, the "shall" in the last sentence > of the first paragraph of 2.4 looks like it should be a SHALL (consider using > MUST instead). > > [Jens]: I agree. Is implemented in revision -09 > > 3) At the mention of LOWPAN_IPHC in the second paragraph of 2.4, consider > referencing RFC6282. It's not clear what the sentence is really trying to > convey, though. "all the requirements" is very vague - can you point to a > specific requirement list somewhere? "It is expected" implies that you > believe there's a chance that it might fail. Could the sentence be removed > (you cover this in 3.2) or be replaced with a more direct statement? > > [Jens]: Agreed, is covered in section 3.2. Will be removed in revision > -09 > > 4) In the first section of 3.1 you have "The PP MUST be pageable". > Interestingly, the word "pageable" does not yet appear anywhere in the RFC > series. Please add a reference into the ETSI docs that will lead the reader > to a definition. > > [Jens]: I don't think we have definition of the term we can refer to. Will > change to an explanatory wording in revision -09. > > 5) In the last paragraph of 3.2 (before 3.2.1), third sentence, you > introduce using the multi-link subnet approach. Please either add a > reference to > RFC4903 > here, or point forward to section 3.3. > > [Jens]: A reference to RF4903 added in revision -09 > > 6) In section 3.2.1, third paragraph, you say addresses are derived "similar > to the guidance of [RFC4291]. I don't believe that is sufficient. Perhaps you > should say "following the guidance in Appendix A of [RFC4291]"? > > [Jens]: Yes, your suggestion is more accurate. Will be done revision -09. > > 7) The last paragraph of 3.3 says "The FPs operation role in such scenario > are rather like Backbone Routers (6BBR) than 6LBR, as per > [I-D.ietf-6lo-backbone-router]." Is this trying to _specify_ the behavior of > the FP in this scenario? If not, it's unclear what the sentence is trying to > accomplish. If so, then the sentence should be "The FPs in such a scenario > behave as Backbone Routers (6BBR) as defined in > [I-D.ietf-6lo-backbone-router]." And that reference should be normative, > rather than informative. > > [Jens]: I agree the wording is bit vague, but I believe we cannot > refer to work in progress [I-D.ietf-6lo-backbone-router] in a > normative way. I will tightening the wording revision -09 You _can_ refer normatively to a work in progress (and I think it may still be the right thing to do here). The consequence is that this document would stay in the RFC Editor's queue in a state known as MISSREF (for missing reference) until the referenced document was approved for publication as an RFC. You can see examples of this at work on https://www.rfc-editor.org/current_queue.php. > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
