[IPv6]Re: WG Last Call: draft-ietf-6man-snac-router-ra-flag-06 (Ends 2026-04-23)

[Ted Lemon <[e-mail]>]

If we wanted the document defining the snac router bit to make normative statements about how it should be used, we would have defined the bit in snac-simple. There was a deliberate choice made to separate this out. I think what we are doing here by removing the normative reference is actually more correct than what we did previously in terms of the motivation for keeping these two drafts separate. 

This document is to inform /receivers/ of the snac router bit. Not senders. So specifying what senders must or must not do is out of scope. Even if we had a normative reference to snac simple we would not put this requirement here—it doesn't make sense here. 

One important benefit of this is that it lets RA consumers who are not implementing snac know what they need to do without having to read the snac document. 

On Wed, Apr 15, 2026, at 9:31 AM, Philipp Tiesel wrote:
> 
> 
>> On 14. Apr 2026, at 19:12, Ted Lemon <[e-mail]> wrote:
>> 
>> On 14 Apr 2026, at 19:08, Philipp Tiesel <[e-mail]> wrote:
>>> I agree that this limits what snac-simple can specify as behavior, but it gives away the important bits to know to judge how the new RA flag changes the way "routing works” (not) and it is a safe add-on. Having this as a normative statement helps to reduce fears of touching it. 
>> 
>> We explicitly say that the recipient of an RA that has the stub router flag set doesn't behave differently. So if a stub router RA sets router lifetime to nonzero, we expect recipients to treat this as a default route. This flag does not exist to guard against that possibility.
>> 
>> Of course, that would generally be wrong behavior on the part of the stub router, but that's immaterial here. From the perspective of a device receiving the RA, it's completely allowed for the router lifetime to be nonzero. More accurately, we don't care if the device enforces such a restriction: the issue is with the SNAC implementation, not with the recipient of the RA.
>> 
> 
> I agree that this is consistent and sufficient for an implementer to know, but I dislike an RFC that defines something without giving a clue how it interacts in the ecosystem. It’s for a good reason, but not what I would expect from an IETF document.
> 
> For the sake of not taking on too much SNAC content, I would prefer a sentence like:
>    RAs having the SNAC RA flag set MUST also have the RA lifetime set to zero and thus have no effect on the default route.
> We already have similar defined behavior of RIOs and PIOs in draft-ietf-6man-rfc6724-update.
> 
> Don’t take this as non-consent to publication of the document as-is, but as an issue I see we should briefly discuss as a WG and that might cause more discussion in IESG review. I I am the only one having concerns here, I am fine to count this as support for going ahead.
> 
> AVE!
>    Philipp
> 
> 
>