Inline with [MB]. Thank you! ________________________________ From: Pascal Thubert <[email protected]> Sent: Friday, June 6, 2025 1:03 PM To: Mike Bishop <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Mike Bishop's No Objection on draft-ietf-6lo-prefix-registration-12: (with COMMENT)
Hello Mike Many thanks for your kind review. I committed the changes below as Mike Bishop's No Objection on draft-ietf-6lo-prefix-registration-12: … · pthubert/6lo-prefix-registration@1d3b5d9<https://github.com/pthubert/6lo-prefix-registration/commit/1d3b5d9958636f4f8ce188205c641c89097c9dcb> I also pushed version 13 so you can observe the overall result here: Diff: draft-ietf-6lo-prefix-registration-12.txt - draft-ietf-6lo-prefix-registration-13.txt<https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-prefix-registration-12&url2=draft-ietf-6lo-prefix-registration-13&difftype=--html> Please let me know if more work would be appropriate... Let us see below for the detailed answers: Le mer. 4 juin 2025 à 18:12, Mike Bishop via Datatracker <[email protected]<mailto:[email protected]>> a écrit : Mike Bishop has entered the following ballot position for draft-ietf-6lo-prefix-registration-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-prefix-registration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document is very dense, and I can tell that you've made efforts to connect it to the context of existing documents in this space. Thank you for that investment. I have a few comments that I hope will help improve the document; they can be incorporated at the editor's and the responsible AD's discretion. Much appreciated In Section 2.1, there is no Extends or Amends "tag" per se. I think it's fine to define the terms as you're using them for precision in this document, but draft-kuehlewind-update-tag has been replaced and its replacement expired without being adopted by RSWG. It has no formal standing at this point. Based on other reviews, I moved back from Mirja's terminology with the more classical "updates" tag. See Github · pthubert/6lo-prefix-registration@dde1a90<https://github.com/pthubert/6lo-prefix-registration/commit/dde1a903729546131610c7e18a838b2a3460e4e3> for those diffs. In Section 2.2, there's already a References section at the end of the document. Consider instead specifying what terminology you're importing from each document. Proposal to change the title to "Inherited Terms and Concepts" and replace the ref to RFC 9008 by that of RFC 6550. What about " 2.2. Inherited Terms and Concepts This document uses terms and concepts that are discussed in: * "Neighbor Discovery for IP version 6" [RFC4861] and * "IPv6 Stateless Address Autoconfiguration" [RFC4862] for the Neighbor Solicitation operation, * Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC6775], as well as * "Registration Extensions for 6LoWPAN Neighbor Discovery" for SND operations [RFC8505] and * "Routing Protocol for Low Power and Lossy Networks" [RFC6550] for RPL, which is the routing protocol used in LLNs for SND. " [MB] That will work, though in some cases it might be nice to pull out the specific terms defined in those documents that you rely on. I'll leave it in your hands how deep you want to go on that, though. Regardless, it's a good orientation point. In Section 3, the second sentence is difficult to parse due to the descriptive clauses for each item in your list. Consider breaking this up into multiple sentences or using a bulleted list to isolate the elements. What about " An SND deployment consists of: * One or more 6LBR(s) that act(s) as RPL Root * intermediate routers down the RPL graph that propagate routing information on addresses and prefixes towards the Root * 6LRs that are RPL-aware 6LNs and can leverage RPL directly to expose their addresses and prefixes * and 6LNs that are the RPL-unaware destinations and need SND to obtain reachability tover the RPL LLN for their addresses and, with this specification, their prefixes as well. The SND operation for prefixes inherits from that for unicast addresses, meaning that it is the same unless specified otherwise herein. " [MB] Yes, that's much more parseable. In Section 7.3, there is an inconsistency between "less than 120 bits long" and "up to 120 bits" / "at most 120". I suspect the first intends to say "at most 120 bits long." fixed It might be worth mentioning earlier in the document that this design excludes support for prefixes longer than 120 bits. That's almost certainly a reasonable restriction, but discovering it in the encoding rules of the message is sub-optimal. Added in the introduction In Section 12.1, is there a citation for "brown field use case"? Is this phrase needed, or could this sentence begin with "A mix of devices that support any or all of..." done ===NITS FOLLOW=== Abstract, "allows to request" => "allows the node to request" or "allows requesting" done Section 1, paragraph 3 has odd spacing. Please check whether you have extraneous whitespace or nbsp characters in your input that might be causing this. Fixed. I believe that was tabulations. Strange: I'd have thought they were filtered Section 3, "that it participates to" => "that it participates in" or "in which it participates"; "enables to decouple" => "enables decoupling"; "to stimulate the" => "to request" done Section 7.2, Should "The Status field that is used only when the EARO is placed in an NA message." be "The Status field is used only when the EARO is placed in an NA message."? done Section 7.4, "similar as" => "similar to that"; "it is of" => "it is" done Many thanks Mike, this was really useful and beneficial for the document. Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
