Barry Leiba has entered the following ballot position for draft-ietf-homenet-hncp-09: 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-hncp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have two points that I'd like to discuss, both of which should be very easy to resolve: -- Section 10.1 -- For all the capability values you say something like this: It MUST be set to some value between 1 and 7 included (4 is the default) if the router is capable of proxying MDNS and 0 otherwise. First, the word you want is "inclusive", not "included". Second, "4 is the default" really means that you can set it to 0, and that's the same as setting it to 4. But it seems that 0 means that the router does not have the specified capability. Those seem to be in conflict. I strongly suggest you do NOT have a default, and allow the use of 0 *only* to designate lack of that capability. Please discuss this with me to make sure I'm not misunderstanding you here. -- Section 13 -- I have two concerns with how the HNCP TLV Types registry is specified: 1. Because the DNCP TLV Types registry specifically allocates 32-511 for profiles, it'd be better to simply limit the range of values in this registry to those values, rather than making it broader and duplicating the other values from the other registry. 2. I think it's a bad idea for HNCP to re-define DNCP's Private Use range in its registry. I would rather see this be text in the document (here in the IANA Considerations is a fine place for it) that says that HNCP uses the Private Use range for per-implementation experimentation, and not have that be in the HNCP registry. In other words, I'd make it more like this (and add a reference to RFC 5226): NEW IANA should set up a registry for the (decimal values within range 32-511, as allocated to profiles by DNCP) "HNCP TLV Types" under "Distributed Node Consensus Protocol (DNCP)", with the following initial contents: 32: HNCP-Version 33: External-Connection 34: Delegated-Prefix 35: Assigned-Prefix 36: Node-Address 37: DHCPv4-Data 38: DHCPv6-Data 39: DNS-Delegated-Zone 40: Domain-Name 41: Node-Name 42: Managed-PSK 43: Prefix-Policy 44-511: Unassigned The policy "RFC Required" [RFC5226] should be used for future assignments. The range reserved by DNCP for Private Use (768-1023) is used by HNCP for per-implementation experimentation. How collisions are avoided is out of scope of this document. END Does that make sense? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 1.1 -- As HNCP uses DNCP as the actual state synchronization protocol, the applicability statement of DNCP can be used here as well; HNCP should not be used for any data that changes rapidly and constantly, and locators to find such services should be published using it instead. I don't follow the second half of that (after the semicolon): I don't get the antecedents to "such services" (there are no services mentioned) and "it" (maybe understanding "such" will help sort this part out). Can you re-word this to make it clearer? -- Section 3 -- 3. DNCP Profile The DNCP profile of HNCP is defined as follows: That seems backwards to me; I'd say this is "the HNCP profile of DNCP", no? o HNCP operates on multicast-capable interfaces only. HNCP nodes MUST assign a locally unique non-zero 32-bit endpoint identifier to each interface for which HNCP is enabled. The value zero it is not used in DNCP TLVs, but it has a special meaning in HNCP TLVs (see Section 10.3 and Section 6.4). Implementations MAY use a value equivalent to the IPv6 link-local scope identifier for the given interface. I want to probe that "MAY" for a moment. Of course, implementations can use anything they want to, right? So what's the point of calling out the scope identifier specifically? Is it because that's a particularly convenient ur useful value? Is it something you're recommending (but not at the "RECOMMEND" level)? If so, it might be better to say that, rather than saying "MAY"; the "MAY" seems rather useless here. * Imax SHOULD be 7 doublings of Imin (i.e., 25.6 seconds) but MUST NOT be lower. The "i.e." is only correct here if the previous bullet's recommendation of 200ms is actually used. I suggest avoiding the Latin abbreviation, and saying explicitly what you mean: "(25.6 seconds, if Imin is the recommended 200 milliseconds)". It could also be unclear about whether "MUST NOT be lower" means "MUST NOT be lower than (Imin * 2**7)" or "MUST NOT be lower than 25.6 seconds". I presume you mean the former, but I suggest making that explicit as well, either way. -- Section 6.2 -- In presence of any type 1 to 128 Prefix Policy TLV the prefix is specialized to reach destinations denoted by any such Prefix Policy TLV, i.e., in absence of a type 0 Prefix Policy TLV it is not usable for general internet connectivity. An HNCP router MAY enforce this restriction with appropriate packet filter rules. I have a similar question as above about the "MAY" here. Are you actually saying, "Packet filter rules are a good way for an HNCP router to enforce this restriction." ? Would that be better than using "MAY" here? -- Section 6.3.1 -- ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix adoption MAY be done instantly). Here, I think the "MAY" is actually wrong. I think what you mean is "(i.e., prefix adoption is done instantly unless it is delayed by a non-zero value here)." -- Section 6.4 -- o A node MUST NOT start advertising an address if it is already advertised by another node. ... o Whenever the same address is advertised by more than one node, all but the one advertised by the node with the highest node identifier MUST be removed. How can the second happen, given the first? -- Section 8 -- Each HNCP node SHOULD announce a node name for itself to be easily reachable and MAY do so on behalf of other devices. MAY announce a node name for itself on behalf of other devices? That's what "do so" says to me. Better to replace "do so" with something clearer: "...and MAY also announce node names for other devices." Announcements are made using Node Name TLVs (Section 10.7) and MUST be unique in the whole network. The announcements are, I presume, not what MUST be unique. You mean the node names MUST be uniques, yes? So: NEW Announcements are made using Node Name TLVs (Section 10.7) and the node names MUST be unique within the whole network. END _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
