Thank you for your patience while discussing this with me. I'm also ok with leaving the current text alone at this point.
RjS Sent from my iPhone > On Dec 21, 2016, at 3:26 AM, Jens Toftgaard Petersen <[email protected]> wrote: > > Hi Robert, > > Thanks for your useful comment and guidance. > > The multi-cell scenario, that the section is addressing, will probably only > be used rare cases - currently it is definitely not the primary use case. > I believe that even without the reference to 6BBR the draft has all the > information to ensure interoperability between DECT ULE devices. The sentence > is rather to remind implementers of "backbone" infrastructure of the guidance > in ietf-6lo-backbone-router. > I am fine with current wording, but for me it is also OK changing the wording > if that makes it clearer - any guidance from AD? > > Thanks and best regards, > Jens > > > -----Original Message----- > From: Robert Sparks [mailto:[email protected]] > Sent: 20. december 2016 15:38 > 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 > > > >> On 12/20/16 6:26 AM, Jens Toftgaard Petersen wrote: >> 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? > Maybe. I'm not the expert here, so all I can do is ask (what are hopefully > useful) questions: > > Here's one way to help figure this out: Would you be ok deleting the sentence > and the reference? (I'm not asking you to do that, just to consider what it > would mean to the resulting set of implementations if you did.) > > If you think people will build the right software with that sentence missing, > and you'll get the interoperability you're aiming for, then it's fine as an > Informative reference. This would be the case if what you're really doing > with that sentence is saying "other documents in the base protocol this is > building on require you to behave this way, we're just pointing at that here > to remind you of that fact". > > If that's going to leave implementers guessing at what their implementation > is supposed to do, and interoperability will suffer, then it's normative. > (What you're really doing with that sentence is telling the implementers > something _new_ - that they SHOULD behave as a 6BBR in this situation, and > nothing else tells them to do that, and the reference is here to tell them > how to do that). > > Alternatively, if it's just fine that some large subset _doesn't_ behave as a > 6BBR, then its fine the way it is. You might consider saying "One good way > for an FP can behave in such scenarios is as a Backbone Router..." instead, > to make it clearer that this is just informational guidance rather than > something that would affect interoperability in the resulting implementation > base. > > Either way, I'm happy leaving it up to you and your ADs at this point. >> >> 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
