[IPv6]Re: [Snac] Datatracker State Update Notice: <draft-ietf-6man-snac-router-ra-flag-03.txt>

[[e-mail]]

Hi all,

Exactly what Éric said.

As a disclaimer, note that I’m interested in resolving this in a timely manner as we have a V6OPS document approved recently and which has a dependency on draft-ietf-6man-rfc6724-update, which in turn depends on draft-ietf-6man-snac-router-ra-flag. So, thanks to Éric for his effort to uncluster these docs.

I see that the authors of draft-ietf-6man-snac-router-ra-flag already published a new revision but I’m afraid more changes are needed. As currently written, the document suggests that the description of what is a SNAC router is out of the scope, points that readers should refer to simple I-D for security threats, etc., which make simple snac still look like normative (even if it is listed as Info).

My suggestion is to reposition the main contribution of draft-ietf-6man-snac-router-ra-flag to defining a signal that allows to identify a SNAC router. Given its intended BCP status, simple doc is positioned as an approach to illustrate practices for enabling connectivity automation. For interop, all what we need the interpretation of the flag.

An attempt to help with tweaking the text to have a document that is independent of snac-simple can be found here:

  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-ietf-6man-snac-router-ra-flag-04-rev%20Med.pdf
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-ietf-6man-snac-router-ra-flag-04-rev%20Med.doc

I can copy/paste the proposed changes here as well, if needed.

Cheers,
Med

De : Eric Vyncke (evyncke) <evyncke=[e-mail]>
Envoyé : vendredi 3 avril 2026 08:06
À : Bob Hinden <[e-mail]>; Michael Richardson <[e-mail]>
Cc : Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>; [e-mail]
Objet : [IPv6]Re: [Snac] Datatracker State Update Notice: <draft-ietf-6man-snac-router-ra-flag-03.txt>


Michael,

Bob is correct, the IESG decided yesterday to strictly follow the process but redoing the WGLC, IETF Last Call, IESG evaluation for this 4-page draft.

BTW, it is more than 2 documents as you may remember that snap-simple (not yet WGLC) has normative reference to DNSSD drafts... I.e., the whole cluster is potentially with 6 drafts with some of them not moving forward quickly.

Hope this clarifies things,

Regards

-éric

From: Bob Hinden <[e-mail]<mailto:[e-mail]>>
Date: Friday, 3 April 2026 at 01:00
To: Michael Richardson <[e-mail]<mailto:[e-mail]>>
Cc: Bob Hinden <[e-mail]<mailto:[e-mail]>>, Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>>, IPv6 List <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Ted Lemon <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Snac] Datatracker State Update Notice: <draft-ietf-6man-snac-router-ra-flag-03.txt>
Michael,

On Apr 2, 2026, at 1:06 PM, Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:

Signed PGP part

Eric Vyncke ＼(evyncke＼) <evyncke=[e-mail]<mailto:evyncke=[e-mail]>> wrote:
You may be aware of a big cluster of IESG-approved drafts in 6MAN &
V6OPS WGs https://www.rfc-editor.org/cluster_info.php?cid=C525 This
MISSREF cluster prevents publication until all missing references are
also approved (i.e., including draft-ietf-snac-simple).

Big? two documents waiting for ra-flag.  Nothing happened to the document in 2025.

I see Jonathan Hui has submitted an update.  Doesn't that unblock things?

That is the intent.

But as I understand it, the IESG would like 6MAN to do a w.g. last call to confirm there is still a concensus in the working group for this change.

Bob




--
Michael Richardson <[e-mail]<mailto:[e-mail]>>   . o O ( IPv6 I�T consulting )
          Sandelman Software Works Inc, Ottawa and Worldwide



Jv恙ｨ･岳%翰l擧"zﾗ隶霄{.nﾇ+温ｬzwZ晞嚏[hｲv恤豈z'ｭ~癌

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.