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]> 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. " > > 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. " > 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]
