Dear all Quoting Adrian's RTG DIR review:
> 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? > https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-14#section-7.1.1 defines new capability bits for use in the 6CIO, which was introduced by RFC7400 to announce support of the spec. When there is no 6CIO, there's a plan B using EUI-64 as RUID and IID in a NS(EARO), which is fully backward compatible, and see if the response has an EARO or not from the T flag. Adrian indicates that a double mechanism is complexity. For backwards compatibility we need to be able to live without 6CIO. Still 6CIO seems to be a good mechanism to generalize and that's why we used it. So should we keep the CIO mechanism, or should we drop it? Pascal
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
