On Mon, Oct 28, 2024 at 9:33 PM Adrian Farrel via Datatracker <noreply@xxxxxxxx> wrote:
== 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]
We were trying really hard to leave the protocol work to the snac router document. There is in fact language in the flag bit draft that addresses this, though:
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.
So if you aren't a SNAC router, you aren't allowed to set the bit. If you are a SNAC router, by definition, you implement the SNAC router specification, so you will know whether or not to set the bit by reading the specification. I don't think we need additional text about this. You propose that this normative language isn't required here, because this is just what RFC4861 already says. However, the motivation for putting normative language here is to emphasize to the reader, who is not implementing the SNAC router spec, that they aren't allowed to do anything at all with this bit. So I'm sympathetic to your complaing about this, but I don't think punting to RFC4861 gets the point across. We really do want readers who are not implementing SNAC to feel that there is a requirement that they not use this bit for anything at all.
- 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"?
The point of this text, which is common to many specifications, is to avoid requiring non-implementors to log the RA flags in such a way that the presence or absence of this bit is not seen in the log. We have no interest in specifying how such implementations log this bit: the point is precisely that we are not trying to tell them they can't log it.
--> Pointer to some pre-existing document
I don't think there is such a 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
Why do we need to say this? This document is specifying a flag. We are not interested in telling you how to set up RA guard: if you want to do that, presumably you know how or can go look it up. Our goal here is simply to say that if you do set up RA guard, devices on the network where it is active will not see these RAs because they will be blocked. This text was added in response a review comment—my preference would be to remove this text entirely. I don't think it serves any purpose.
== 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
RFC4861 section 4.2.
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
Non-SNAC routers aren't supposed to even listen to RAs. We really tried not to specify protocol in this document based on both the 6man WG consensus and the SNAC WG consensus. We're just trying to write the document in such a way that someone who is not implementing a SNAC router is clear that they should not set the bit, nor should they pay attention to it. If you want to know more you should read the SNAC document.
---
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 that this document does not update RFC4861, I think you could reasonably (and correctly) conclude that the treatment of these bits is as specificed in RFC4861. I think it would be harmful to specify anything about such behavior here.
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.
There is no such risk. If you set the bit, your RA will be ignored in some situations where it otherwise wouldn't be. Which is specified in the SNAC router document. Which we've referenced.
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.
We don't reference those documents otherwise, so this seems like it would make things more, not less, confusing. Our point in referencing RFC4861 is that that is the document in which the RA flags are documented, so whatever security considerations it specifies are not changed by this document.
Thanks for the review. Sorry if this sounds grumpy—I feel like I'm not taking any of your advice, but I do appreciate the time you took to offer it. I think the source of disagreement is sort of a usual one in the IETF: the "one document or two" question. We chose two because it felt like it was out of scope to define this flag in the SNAC working group, since 6man has change control over the Neighbor DIscovery spec, but that leaves us with a document that says nothing other than what the bit is called and where to look if you're curious about what it does. :]
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
