Brian Haberman has entered the following ballot position for draft-ietf-homenet-prefix-assignment-07: Discuss
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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated position based on feedback from Int-Dir review (Suresh Krishnan)... I don't object to the publication of this document, but there are some issues that need to be remedied. 1. Section 5 provides the considerations for selecting prefixes. However, those considerations are incomplete. RFC 7421 provides the analysis for the use of the /64 boundary. The Homenet Architecture (RFC 7368) discusses various Homenet-related issues around not getting sufficient address space to allocate /64 prefixes to links. RFC 6164 discusses the use of 127-bit prefixes on point-to-point links. Why does this section not mention any of these considerations when selecting a prefix? 2. I am raising Alvaro's point about the impact of topology changes to a DISCUSS. I think there needs to be sufficient discussion in the document on the impact of topology changes on the prefix assignment algorithm and the impact of changing prefix assignments on nodes in the network. This ties in to the point raised by Brian Carpenter on the claim in the Introduction that this algorithm can be used in "fully autonomic as well as professionally managed networks". This is especially true when convergence is described as occurring "eventually". 3. I understand that this document became standalone when the HNCP and DNCP documents split. What dependencies/assumptions does this document have on either one of them? There appears to be some assumptions on the Node ID and the flood algorithm. 4. How does the algorithm deal with prefix delegations that have holes (e.g. RFC6603)? This text seems to preclude such delegations. 5. Section 6 discusses Listener nodes. Does there need to be some discussion/warning about links that consist of all Listeners? The link will not get a prefix assigned to it in such a situation. 6. How does this approach deal with asynchronous link state changes? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * ID-nits complains about the malformed 2119 keywords text in the Terminology section. It would be good to use the entire boilerplate for the 2119 keywords. * The terminology section claims that the definitions are ordered to avoid forward reference, but that is not the case. For example, Link refers to Shared Link and Private Link, Delegated Prefix refers to Assigned Prefix, etc. * The definition of Node ID is unclear. What do you mean by "The set of identifiers MUST be strictly and totally ordered". A node id is a single identifier, right? _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
