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. 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. 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. 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. 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." 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. 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..." ===NITS FOLLOW=== Abstract, "allows to request" => "allows the node to request" or "allows requesting" 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. 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" 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."? Section 7.4, "similar as" => "similar to that"; "it is of" => "it is" _______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
