Hi Thomas,
Thanks for your review and comments.
I just posted a -03 version that incorporates your suggested edits and attempts to address your comments.
https://www.ietf.org/archive/id/draft-ietf-6man-snac-router-ra-flag-03.html
https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-snac-router-ra-flag-03
Looking forward to your feedback.
Thanks!
--
Jonathan Hui
I just posted a -03 version that incorporates your suggested edits and attempts to address your comments.
https://www.ietf.org/archive/id/draft-ietf-6man-snac-router-ra-flag-03.html
https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-snac-router-ra-flag-03
Looking forward to your feedback.
Thanks!
--
Jonathan Hui
On Thu, Nov 21, 2024 at 2:54 PM Thomas Fossati via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Thomas Fossati
Review result: Ready with Nits
The document defines a flag to mark NDP RA messages as originating from
an SNAC router.
As 6LoWPANs are likely to be typical stub networks, there may be relevant
IoT-related considerations in the broader context of SNAC, where this flag is
actually used. However, within the limited, "define-and-register" scope of
this document, I struggle to find an IoT angle. I guess topics like ND
optimisations/adaptations for 6LoWPANs, discussion on how constrained hosts on
the stub are protected from the infrastructure et similia will be tackled in
the main SNAC spec.
(RA-Guard is mentioned en-passant. Maybe worth discussing it in the security
considerations -- e.g., mentioning RFC7113?)
# Nits (in --word-diff format):
* an [-autonomously-configuring-]{+autonomously configuring+} router
* The "SNAC Router" flag is[-router advertisement-] flag bit [-TBD.-]{+TBD in
the RA Flags Extension Option.+}
* Devices that do not operate as SNAC routers[-[I-D.ietf-snac-simple]-]
* In environments that implement [-RA guard-]{+RA-Guard+}
* does not [-changes-]{+change+} these considerations
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
