On 20.11.2015, at 17.50, Barry Leiba <[email protected]> wrote: > I can still be convinced that this is the way to go, but I haven't > been yet, so let's please talk about it a bit more. > > I see your point about the possibility that future DNCP updates could > change the registry, though that's always a problem, and that issue > should be caught during IANA and IESG review in the future: changes > that conflict with how HNCP uses the registry should be noticed and > questioned.
Yes, but not automatically rejected. > It seems to me (not having participated in the discussion of DNCP) > that DNCP registered some common TLV types to be used by all profiles, > and then set aside overlapping space for each profile to define its > own TLV types. So… Yeah, and I find that design more undesirable the more I think about it. > 1. there's common space left in which profiles can register common TLV > types that can be used by other profiles and... > > 2. there's profile-specific space in which profiles can register their > own TLV types that other profiles won't use (and where other profiles > will, in fact, use the same type numbers for their own purposes). > > That all seems sensible. And, given that, what makes the most sense > to me is for this profile to *only* specify allocation for the range > that was allocated for profile-specific stuff (and to use the base > DNCP registry for any other ranges). Repeating information from one > registry into another is a bad recipe, more prone to future conflicts, > I think, than what you're concerned about. > > How about this?: > Add something like this to my suggested change above: > > NEW+ > In the DNCP TLV Types registry, IANA is asked to change the > descriptions of two value ranges, as follows: > > 32-511, new description "Reserved for per-DNCP profile use; this range > is in active use by DNCP profiles and must remain reserved." > > 768-1023, new description "Reserved for Private Use; this range is in > active private use and must remain reserved." > END > > Markus, would that address your concern about possible future changes? Hmm. I am not quite sure about how this whole DNCP <> DNCP extensions <> DNCP#2 maps to the two registries in my head, so not quite sure how it _should_ be addressed. However, as Steven already staged the changes limiting the registry range to 32-511, I guess I can live with that :) To expand on my concern, while HNCP refers to a particular DNCP version, what about DNCP extensions and/or DNCPv2 relation to HNCP (and the related registry content changes if any). It is not clear that an arbitrary DNCP extension needs to be supported by a HNCP implementation (unless HNCP 1.1 spec refers to it), but just looking at the main DNCP registry will not really work well to see what is ’the current state’ HNCP implementor needs to follow. Anyway, I can live with even what’s currently staged, just general unease about the ‘future’ with dual registry model. Having _just_ HNCP registry would have made this much more understandable for an implementor, and less likely to break in the future too. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
