Skip to main content

SNAC Router Flag in ICMPv6 Router Advertisement Messages
draft-ietf-6man-snac-router-ra-flag-03

Yes

Erik Kline

No Objection

Jim Guichard
Orie Steele
(Francesca Palombini)
(Murray Kucherawy)
(Zaheduzzaman Sarker)

Note: This ballot was opened for revision 02 and is now closed.

Éric Vyncke
Yes
Comment (2024-11-26 for -02) Sent
# É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.
Erik Kline
Yes
Deb Cooley
No Objection
Comment (2024-12-03 for -02) Sent
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.
Gunter Van de Velde
No Objection
Comment (2024-11-29 for -02) Not sent
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.
Jim Guichard
No Objection
Mahesh Jethanandani
(was Discuss) No Objection
Comment (2024-12-18) Sent
Thanks for addressing my concerns.
Orie Steele
No Objection
Paul Wouters
No Objection
Comment (2024-12-01 for -02) Sent
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.
Roman Danyliw
No Objection
Comment (2024-11-22 for -02) Sent
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?
Francesca Palombini Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Murray Kucherawy Former IESG member
No Objection
No Objection () Not sent

                            
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection (for -02) Not sent