Hello Adrian: Thanks a bunch for your review!
Let us address the major concerns first. Please see below: > > Comments: > > The document is quite hard work. More cross-references would help, and > bringing the abbreviations to the top would also make things easier. But the > main problem was the trickle feed of how everything hangs together - it's all > there, but you have to read the entire document to get the whole picture. [PT>] [PT>] will do. > > ==Major== > > 4.3 > > With this specification, the Registration Unique ID is allowed to be > extended to different types of identifier, as long as the type is > clearly indicated. For instance, the type can be a cryptographic > string and used to prove the ownership of the registration as > discussed in "Address Protected Neighbor Discovery for Low-power and > Lossy Networks" [I-D.ietf-6lo-ap-nd]. In order to support the flows > related to the proof of ownership, this specification introduces new > status codes "Validation Requested" and "Validation Failed" in the > EARO. > > This seems fine, but I don't see how "the type is clearly indicated". [PT>] AP -ND https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-05 introduce a new flag to indicate its form of RUID. Other may come in the future. It is important that it does signal the type because that triggers the validation flow. > > I think you also have to restate the uniqueness assumption in this new > context. Probably that uniqueness is required across {type, value} (unless, of > course, your answer to my first question is that type is embedded in value). > This possibly cuts into backward compatibility as well? > [PT>] A pure RFC 6775 6LR/6LBR will not need to know the difference, since it cannot validate a thing anyway. It will figure that the field is an EUI 64. As you point out, the additional risk vs. an implementation of the update is that the name spaces are not differentiated. So there is a (very^64 remote) risk that a crypto token ends up with the same value as an EUI 64 in the network; for that to have an impact, it would take that 2 nodes register a same address. Note that the Ap ND token is not expected to be used a IID. In other words, for the use that we make of the RUID, there is no real issue that an older implementation confuses the name spaces. Note that AP-ND may have 2 devices form the same RUID from 2 different keys. Then again, very bad luck. Still, not real damage even if that happens unless it is done willingly. DFrom the AP-ND perspective, that is address protection, one node could control the other's address but it does not even know they exist. > See also 6.1/6.2 > > Furthermore, 7.1.2 says... > > A node that supports this specification MUST always use an EARO as a > replacement to an ARO in its registration to a router. This is > harmless since the "T" flag and TID field are reserved in [RFC6775], > and are ignored by a RFC6775-only router. A router that supports > this specification answers an ARO with an ARO and answers an EARO > with an EARO. > > ...but this doesn't mention the "variation" of the RUID that might also arise > with the EARO. How will the RFC6775-only router handle these new RUIDs > and their "clearly indicated" types? [PT>] [PT>] This is defined in the specs that provide those variations; in the case of AP ND there is a proof of ownership challenge of the RUID. You own the RUID if you have the key, and then you are entitled to register and use the address... A router that supports the RFC 6775 update and not any of the coming specs cannot process the RUID differently than a RFC6775-only router. Which is OK as long as the extensions are backwards compatible, IOW the RUID can be used as a unique token. > > --- > > 7.1.2 > > One alternate way for a 6LN to discover the router's capabilities is > to start by registering... > > You went to a lot of trouble to define the E-flag. You then made the use of > the > 6CIO (and hence the E-flag) only a SHOULD, and you defined an alternate > mechanism. (Note: you say "one alternate" implying there are > more!) > > Choice is not good. It complicates the specification and the implementation. > Why go there? Can't you settle on one mechanism and make it necessary and > sufficient? > [PT>] We could live without the 6CIO. The draft does not seem to be very much used and for backward compatibility we cannot depend on it. Still I think it is a good idea to expose capabilities and then start. This draft encourages to start using it more now. Unsure what to do here, I need to take the pulse of the WG. > --- > > You create new registries in 10.1 and 10.2. You must tell the IANA what > allocation policies to use > > [PT>] Yes, it is missing in 10.2 though present in 10.1. I do not see a reason to make them different, so that would be: ' The policy is "IETF Review" or "IESG Approval" [RFC8126]'. Take care, Pascal _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
