Ballot for draft-ietf-6man-snac-router-ra-flag
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.
Section 3, paragraph 2 > 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. This > means that the presence or absence of the flag should not change the > behavior of such devices in any way (other than that it is of course > permissible to log and cache the value of the flag as part of normal > router advertisement processing, where applicable). Hear hear! The DISCUSS criteria for IESG telechats serve to ensure that only significant, unresolved issues block the advancement of a document. More importantly, it is meant to stimulate a discussion around the issue. Toward that end, I would like to Adrian Farel for his OPSDIR and Juan-Carlos Zuniga for his INTDIR review. I agree and 'am holding a DISCUSS on the points raised by both of them as it relates to the use of BCP 14 language to describe the behavior of a non-SNAC router and hope that the author, other contributors, and reviewers come to some form of agreement before moving the document forward. My reading of the thread indicates that the comments have not been adequately addressed, and if that is incorrect feel free to correct me.
DOWNREF [I-D.ietf-snac-simple] from this Proposed Standard to draft-ietf-snac-simple of unknown standards level. (For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and also seems to not appear in the DOWNREF registry.) ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Document references draft-ietf-snac-simple-05, but -06 is the latest available revision. Section 4, paragraph 2 > on of the SNAC router flag does not changes these considerations. 6. Normativ > ^^^^^^^ The auxiliary verb "do" requires the base form of the verb.
# Éric Vyncke, INT AD, comments for draft-ietf-6man-snac-router-ra-flag-02 Thank you for the work put into this document. As the responsible AD for the SNAC WG, this document is important for draft-ietf-snac-simple and the relationships between the 6MAN and SNAC WG were discussed and the process agreed upon by the respective WG chairs and ADs. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Jen Linkova for the shepherd's *very* detailed write-up including the WG consensus, why it is in 6MAN, relationship with SNAC WG, and the justification of the intended status. Other thanks to Thomas Fossati, the IoT directorate reviewer (at my request), please consider this iot-dir review: https://datatracker.ietf.org/doc/review-ietf-6man-snac-router-ra-flag-02-iotdir-telechat-fossati-2024-11-21/ (Jonathan, please start a discussion with Thomas) Other thanks to Juan-Carlos Zúñiga, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-6man-snac-router-ra-flag-02-intdir-telechat-zuniga-2024-11-26/ (Jonathan, please start a discussion with Juan-Carlos, in my view, there is no need to update RFC 4861/5175 as it is merely one new bit in a registry) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 1 Please add an informational reference to 6LoWPAN RFC. Also add a reference to RFC 4861 for the RA. ## Section 3 s/The use of this flag is documented in/The use of this flag is specified in/ Like Thomas, I think that the RA guard paragraph should either be moved in the security considerations or in a new operational considerations. An informative reference to RA-guard should be added as well. Finally, I would use 'will' rather than 'should' in `devices on the infrastructure network should never receive an RA with the SNAC router flag set`. ## Section 5 Please reply to Roman Danyliw comment about other nodes pretending to be a SNAC router or about a on-path-attacker setting/clearing this bit. It may even be better to add this part in the snac-simple I-D and add a reference in this draft to the security considerations of snac-simple.
Thanks for both Shivan Kaul Sahib and Tomas Fossati for their reviews. Both have suggestions that impact Security Considerations, and both suggestions should be considered either for this draft or for draft-ietf-snac-simple. It would be nice to hear whether these suggestions are being considered, in addition to which draft is considered appropriate. I also echo Paul's comment about the separation of this draft and draft-ietf-snac-simple. It would seem logical to have put them together.
I agree with Eric V. that the shepherd write-up was good and it helped me to understand that consensus was to split off the snac router ra flag allocation from the draft-ietf-snac-simple document, which seemed when reading this draft as an unusual procedural decision.
I found it a it weird that this document registers a new flag with IANA, but the definition and usage of the flag is done in another document (draft-ietf-snac-simple) It feels as if this document should have been part of that document instead of being separate, unless the description of the new flag was moved from the snac-simple document to this one.
Thank you to Gyan Mishra for the GENART review. ** Section 5. What is the implication (risk) if this bit being setting (or unset) by a router, host, or on-path attacker?