Skip to main content

Last Call Review of draft-ietf-6man-snac-router-ra-flag-02
review-ietf-6man-snac-router-ra-flag-02-opsdir-lc-farrel-2024-10-28-00

Request Review of draft-ietf-6man-snac-router-ra-flag
Requested revision No specific revision (document currently at 02)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2024-11-11
Requested 2024-10-21
Authors Jonathan Hui
I-D last updated 2024-10-28
Completed reviews Genart Last Call review of -02 by Gyan Mishra
Secdir Last Call review of -02 by Shivan Kaul Sahib
Opsdir Last Call review of -02 by Adrian Farrel
Iotdir Telechat review of -02 by Thomas Fossati
Intdir Telechat review of -02 by Juan-Carlos Zúñiga
Assignment Reviewer Adrian Farrel
State Completed
Request Last Call review on draft-ietf-6man-snac-router-ra-flag by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/zmvAjQGMRmKId4CHbmYoY3_UIKY
Reviewed revision 02
Result Has issues
Completed 2024-10-28
review-ietf-6man-snac-router-ra-flag-02-opsdir-lc-farrel-2024-10-28-00
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.