Reviewer: Adrian Farrel Review result: Has Issues Hello, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Regards, Adrian === Reviewer: Adrian Farrel Draft reviewed: draft-ietf-6man-snac-router-ra-flag-02 Review Result: Has Issues This is an extremely simple draft that serves as an enabler for the work of the SNAC working group. It allows SNAC routers to identify themselves during IPv6 router advertisement. There are a few minor issues that I think could usefully be resolved before publication. == Manageability issues == There is nothing substantive to say about manageability in this document. That is, the manageability issues can largely be punted to [I-D.ietf-snac-simple]. However, it is probably worth pointing that out to readers of this document. For example, - How does a router know that it should set the SNAC router flag? Perhaps that is baked in. Perhaps it is configured. --> Pointer to [I-D.ietf-snac-simple] - How does a node (that does not support the new flag) decide to "log and cache the value of the flag as part of normal router advertisement processing, where applicable"? --> Pointer to some pre-existing document - How is an environment that implements RA guard in a way that filters RAs sent by SNAC routers arranged? --> Pointer to some pre-existing document == Minor == Section 3 attempts to use BCP 14 language to define the behaviour of nodes that do not support the SNAC Router flag. But you can't do that! (Because nodes that do not recognise the new flag, don't implement this document.) So you should achieve this by reference to RFC 5175 or RFC 4861. Thus... OLD The SNAC router flag is to be used by SNAC routers. The use of this flag is documented in [I-D.ietf-snac-simple]. Devices that do not operate as SNAC routers [I-D.ietf-snac-simple] MUST NOT set the SNAC router flag, and MUST silently ignore the SNAC router flag. NEW The SNAC router flag is to be used by SNAC routers. SNAC routers and the use of this flag are documented in [I-D.ietf-snac-simple]. As defined by [RFCxxxx] devices that do not operate as SNAC routers will not set the SNAC router flag, and will silently ignore the SNAC router flag. END But! The router that sends a SNAC Router flag in its RA is operating as a SNAC router. Fine. But the router that receives this RA is not a SNAC router, I think. It is a regular router that supports being paired with a SNAC router. So I think... NEWER The SNAC router flag is to be used by SNAC routers. SNAC routers and the use of this flag are documented in [I-D.ietf-snac-simple]. As defined by [RFCxxxx] devices that do not operate as SNAC routers will not set the SNAC router flag, and routers that do not understand the SNAC router flag will silently ignore it. END --- I wonder whether the O bit (or, indeed, any other bit) is used when the S bit is set. Are there any rules? Or this also punted to [I-D.ietf- snac-simple]? --- Given the security discussion in 4861, I think the Security Considerations section should indicate the risk associated with a router or host flasely setting the S flag. Also, perhaps, what risk there is if the presence of the S flag is observed by a third party. == Nits == You have both - the "SNAC router" flag and - the "SNAC Router" flag --- The security considerations delegate to 4861, which is fine. But since 4861 refers onwards to 3756 and 3971, it might be helpful to include those pointers from this draft. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
