Skip to main content

SRv6 Segment Identifiers in the IPv6 Addressing Architecture
draft-ietf-6man-sids-06

Revision differences

Document history

Date Rev. By Action
2024-02-21
06 John Scudder [Ballot comment]
Thanks for the update.
2024-02-21
06 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2024-02-19
06 Jim Guichard [Ballot Position Update] Position for Jim Guichard has been changed to No Objection from Discuss
2024-02-15
06 (System) Changed action holders to Erik Kline (IESG state changed)
2024-02-15
06 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-02-15
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-02-15
06 Suresh Krishnan New version available: draft-ietf-6man-sids-06.txt
2024-02-15
06 (System) New version approved
2024-02-15
06 (System) Request for posting confirmation emailed to previous authors: Suresh Krishnan
2024-02-15
06 Suresh Krishnan Uploaded new revision
2024-02-05
05 Linda Dunbar Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Linda Dunbar. Sent review to list.
2024-02-01
05 (System) Changed action holders to Suresh Krishnan (IESG state changed)
2024-02-01
05 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2024-02-01
05 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on this document. This document is not related to transport protocol aspects, hence no objection.

It was clear to me …
[Ballot comment]
Thanks for working on this document. This document is not related to transport protocol aspects, hence no objection.

It was clear to me that this informational draft is for the "transit node" and I think the prefix would be helpful for filtering. However, I also don't think it solves the related security concerns.
2024-02-01
05 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-02-01
05 Andrew Alston
[Ballot discuss]
*Updated* - While unusual and having now gone through this with even more diligence - I am adding certain additional points to this …
[Ballot discuss]
*Updated* - While unusual and having now gone through this with even more diligence - I am adding certain additional points to this discuss ballot.

Hi,

Thank you for the document.  There are various portions of this document that I feel are worthy of a discussion.

In Abstract the document states:

"Due to the underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations"

I believe this to be inaccurate - you state further down in the document that these SID's are used by transit nodes to forward, and treated (not differentiated) from IPv6 addresses.  Now, the way I see it this document is attempting to have this both ways - either an SRv6 SID is IPv6 address address - or it isn't.  If indeed it is an IPv6 address - it should conform.  If it's not - then SRv6 is indeed a separate data plane with all the caveats that come with that.  Further more, by stating that SID's are not IPv6 addresses, it creates an impression that SID's are not routable over the general internet - which - without special precautions / filters etc - they most certainly are.  Hence I have deep concerns about the impressions this document will create vis-a-vie the security of SRv6.

The document states:

It is clear that this format for SRv6 SIDs is not compliant with the
  requirements set forth in [RFC4291] for IPv6 addresses but it is also
  clear that SRv6 SIDs are not intended for assignment onto interfaces
  on end hosts.

However - this would seem to conflict with RFC8402 which states:

Hosts MAY be part of an SR domain.  A centralized controller can
  inform hosts about policies either by pushing these policies to hosts
  or by responding to requests from hosts.

A host participating in an SR domain is going to almost certainly have interaction with those SID's.

Further - While this document seems to wish to hand wave about if a SID is or isn't an IPv6 address - RFC8402 states explicitly that it is in Section 2 of the terminology - which states:
SRv6 SID: an IPv6 address explicitly associated with the segment.

This is further reiterated in section 3.1.3 on RFC8402 which states:

When SR is used over the IPv6 data plane:

  o  A Prefix-SID is an IPv6 address.

Basically - as stated above this document seems to have it both ways - and this may be because while a SID clearly does not conform to RFC4291 - it is also clear from RFC8402 that according to the authors - SID's are IPv6 addresses.  This leaves this document in a very difficult position since it seems to want it both ways.  I believe if we are going to say that SID's are not conformant to RFC4291 - this constitutes an errata in RFC8402 (Or worthy of a -BIS) to make it clear that these are NOT IPv6 addresses.  But I do not see how a document can seem to have it both ways while the architectural basis for Segment Routing as found in RFC8402 makes explicitly contradictory statements.

It is possible that this could be addressed by changing this document into a BIS that resolves the conflicts found above?
2024-02-01
05 Andrew Alston Ballot discuss text updated for Andrew Alston
2024-01-31
05 Paul Wouters
[Ballot comment]
I too support the DISCUSS position of Andrew, Jim and John and of Warren's ABSTAIN position.

As this is currently being deployed with …
[Ballot comment]
I too support the DISCUSS position of Andrew, Jim and John and of Warren's ABSTAIN position.

As this is currently being deployed with leaks, I think the prefix has a chance to improve
things with vendors putting in default block rules for these prefixes in their devices. I
don't think it will makes things worse. Networks not using/blocking these prefixes won't be
further harmed by this document's actions.
2024-01-31
05 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2024-01-31
05 Roman Danyliw
[Ballot comment]
I support the DISCUSS position of Andrew, Jim and John.

I am also supportive of the security concerns raised by Warren in his …
[Ballot comment]
I support the DISCUSS position of Andrew, Jim and John.

I am also supportive of the security concerns raised by Warren in his ABSTAIN position.
2024-01-31
05 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-01-31
05 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-01-31
05 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-6man-sids-05

Thank you for the work put into this very much needed document. It is short, …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-6man-sids-05

Thank you for the work put into this very much needed document. It is short, straight to the points, and not easy to write albeit easy to read with the logical flow.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Jen Linkova for the shepherd's detailed write-up including the WG consensus _and_ the justification of the intended status.

Other thanks to Juan-Carlos Zúñiga, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-6man-sids-05-intdir-telechat-zuniga-2024-01-30/

Other thanks to Petr Špaček, the DNS directorate reviewer (at my request), please consider this dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-6man-sids-05-dnsdir-telechat-spacek-2024-01-15/ (and I have read Suresh's reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

Like others, I would suggest moving the last sentence (about the prefix) in a separate paragraph (as it is not closely related to the rest of the paragraph) and use "may" (non-normative as it is informational).

## Use of BCP14 terminology

Is the BCP14 template required in an informational document? I only saw one "SHOULD" about the DNS part.

## Section 4.1

This should be removed before publication probably via a note to the RFC editor.

## Section 7

Should there be a recommendation to filter 5ff0::/16 via routing (e.g., static route to /dev/null, or adding it to the global martians/bogons list) rather than ACL -- this could be easier / more performant ? Or would it be too BCP-like ?

# NITS (non-blocking / cosmetic)

## Section 5

s/As an added factor of safety/As an added factor of security/ ? I.e., "safety" is often used when physical harm done to a living being/animal.
2024-01-31
05 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-01-30
05 Murray Kucherawy
[Ballot comment]
I support John Scudder's DISCUSS.  I also support Jim Guichard's DISCUSS, except for the minor nit that I wouldn't use a normative "MAY" …
[Ballot comment]
I support John Scudder's DISCUSS.  I also support Jim Guichard's DISCUSS, except for the minor nit that I wouldn't use a normative "MAY" in an abstract.
2024-01-30
05 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-01-30
05 Warren Kumari
[Ballot comment]
I am balloting Abstain (a non-blocking position) because there is no way to ballot Discuss on one part of a document and NoObj …
[Ballot comment]
I am balloting Abstain (a non-blocking position) because there is no way to ballot Discuss on one part of a document and NoObj (or Yes) on another part.

Abstain" means "I cannot support sending this document forward.", and I'm using it in the "I oppose this document but understand that others differ and am not going to stand in the way of the others." sense (see https://www.ietf.org/standards/process/iesg-ballots/ for the subtleties).


The DISCUSSy part:
I am still deeply concerned about the security, operational and architectural implications of stuffing something other than an IP address in the source or destination fields of a packet. I understand why the document is so handwavey about whether or not SIDS are IP addresses (e.g: "Due to this underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations."), and think that the author has done a good job of dancing around this point -- but it's still an issue for me.

Now the NoObj part:
One of my primary concerns with SRv6 is that these can and do leak (both inbound and outbound). For this reason, I'm supportive of there being a prefix set aside for this use. The document says that "usage of the prefix allocated by this document improves security by making it simpler to filter traffic at the edge of the SR domains." -- this is true, but it is only a marginal improvement; operators still need to manually filter at the edge of the domain. Having a prefix set aside this just makes it that you do the moral equivalent of 'deny ipv6 any 5f00::/16' instead of 'deny ipv6 any {some_internal_prefix_I_have_to_remember}::/32'. There is also the advantage that I can filter this range inbound and if I see any packets hitting the filter, I can tell that my neighbor is leaking -- so, yes, this is an improvement, but it's not a massive one. If the document also specified a default behavior of dropping packets with these addresses, or that device vendors could provide syntactic sugar to help with the filtering, I'd be much more supportive.

But, again, an abstain is not a blocking position...
2024-01-30
05 Warren Kumari [Ballot Position Update] New position, Abstain, has been recorded for Warren Kumari
2024-01-30
05 Juan-Carlos Zúñiga Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Juan-Carlos Zúñiga. Sent review to list.
2024-01-30
05 John Scudder
[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-6man-sids-05
CC @jgscudder

Thanks for taking on this challenging topic.

## DISCUSS

Back in November, I …
[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-6man-sids-05
CC @jgscudder

Thanks for taking on this challenging topic.

## DISCUSS

Back in November, I complained about this document's lack of comprehensive treatment of CSIDs:

https://mailarchive.ietf.org/arch/msg/ipv6/Z2dK5upw3i7Zp3VyHgag6DGAm6E/ (last paragraph)

Suresh's reply was (my paraphrase) that it's not this document's job to track the details of issues with CSIDs:

https://mailarchive.ietf.org/arch/msg/ipv6/h0GpOzFd9-0-F9RknAH3fqK8ZuA/

OK. However, in that case, I think the title ("Segment Identifiers in SRv6") is subtly over-claiming, and the abstract is too:

                                  This document explores the
  characteristics of SRv6 SIDs and clarifies the relationship of SRv6
  SIDs to the IPv6 Addressing Architecture. 
 
I suppose the abstract doesn't say it does these things comprehensively, but surely we can take that as read, absent a disclaimer.

It seems to me that the document should mention that CSIDs are out of scope if that's the intention. I notice you've committed to deleting Section 4.1 (but not Section 4?). I think this concern stands even with that deletion. Regarding the title... naming things is hard, but it would be nice to have a title that makes it more readily apparent that the goals of the present document are narrowly scoped to the IPv6 *Addressing* Architecture, and not to the IPv6 Architecture writ large. That failing, a disclaimer to that effect in the body text would help. Yes, I know that the sentence I've quoted above says "IPv6 Addressing Architecture" in so many words, but I think it's still desirable to be crystal-clear that this document is not the final word in relating SRv6 to the IPv6 Architecture.
2024-01-30
05 John Scudder
[Ballot comment]
## COMMENTS

### Section 2, Unused definitions:

The following defined terms are never referenced:

- SR Policy
- Reduced SRH
- Segments Left …
[Ballot comment]
## COMMENTS

### Section 2, Unused definitions:

The following defined terms are never referenced:

- SR Policy
- Reduced SRH
- Segments Left
- Last Entry

I guess these can be removed.

### Section 5, "at the present time"

In "At the present time, AAAA and PTR records for addresses assigned from this block SHOULD NOT be installed in the global DNS [RFC8499]", what work is "at the present time" doing? If "none" then please delete. If something else, please say what?

### Section 7, last sentence

"Similarly as stated in Section 5.1 of [RFC8754], packets entering an SR domain from the outside need to be configured to filter out the selected prefix if it is different from the prefix allocated here."

This needs a rewrite, if only because I don't know how to configure a packet to filter a prefix. :-P

## NITS

- "This document explores the characteristics of SRv6 SIDs and to clarify the relationship of SRv6 SIDs to the IPv6 Addressing Architecture [RFC4291]."

"And to clarify" should be "and clarifies", or some other fix.

- "an SRv6 SIDs" should be "SRv6 SIDs" with no article.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
2024-01-30
05 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2024-01-30
05 Jim Guichard
[Ballot discuss]
Thank you for this document and the extensive work undertaken by the author and the 6man/spring working groups. I have a couple of …
[Ballot discuss]
Thank you for this document and the extensive work undertaken by the author and the 6man/spring working groups. I have a couple of points that I would like to discuss:

1. The abstract has the following text: "It also allocates an IPv6 prefix for SRv6 SIDs". While this statement is true, the wording could imply that the IPv6 prefix allocation is mandatory but of course it is not. I would suggest changing the text to read "It also allocates an IPv6 prefix that MAY be used for SRv6 SIDs".

2. Section 4.1 (Applicability to other forms of compressed SIDs) of the document points to an expired document (spring-compression-analysis) and the SPRING working group is only focused on https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ . I would like to discuss whether this section is necessary or should be removed from the document.
2024-01-30
05 Jim Guichard [Ballot Position Update] New position, Discuss, has been recorded for Jim Guichard
2024-01-30
05 Andrew Alston
[Ballot discuss]
Hi,

Thank you for the document.  There are various portions of this document that I feel are worthy of a discussion.

In Abstract …
[Ballot discuss]
Hi,

Thank you for the document.  There are various portions of this document that I feel are worthy of a discussion.

In Abstract the document states:

"Due to the underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations"

I believe this to be inaccurate - you state further down in the document that these SID's are used by transit nodes to forward, and treated (not differentiated) from IPv6 addresses.  Now, the way I see it this document is attempting to have this both ways - either an SRv6 SID is IPv6 address address - or it isn't.  If indeed it is an IPv6 address - it should conform.  If it's not - then SRv6 is indeed a separate data plane with all the caveats that come with that.  Further more, by stating that SID's are not IPv6 addresses, it creates an impression that SID's are not routable over the general internet - which - without special precautions / filters etc - they most certainly are.  Hence I have deep concerns about the impressions this document will create vis-a-vie the security of SRv6.
2024-01-30
05 Andrew Alston
[Ballot comment]
Section 4.1 of the document is no longer relevant - Spring Working group is considering CSID (Next/Replace) and only those two, so this …
[Ballot comment]
Section 4.1 of the document is no longer relevant - Spring Working group is considering CSID (Next/Replace) and only those two, so this section of the document is probably unnecessary.

I would also question if since we are talking about special handling of CSID's - would this document not also be the correct place to deal with fact that in certain circumstances CSID's result in broken L4 Checksums?
2024-01-30
05 Andrew Alston [Ballot Position Update] New position, Discuss, has been recorded for Andrew Alston
2024-01-29
05 Robert Wilton
[Ballot comment]
Hi Suresh,

Thanks for this draft.  I believe that allocating a block for SID allocation is a good idea.

A couple of minor …
[Ballot comment]
Hi Suresh,

Thanks for this draft.  I believe that allocating a block for SID allocation is a good idea.

A couple of minor comments on the document:

Minor level comments:

(1) p 4, sec 4.1.  Applicability to other forms of compressed SIDs

  The spring working group is in the process of analyzing multiple
  mechanisms for compressing the SRv6 SID list as described in
  [I-D.ietf-spring-compression-analysis].  Even though this document
  focuses on [CSID], the considerations specified in this document
  might also be applicable to the other mechanisms being analyzed and
  compared.

I was slightly confused by the reference to 'this' document, which I interpreted to be referring to this draft (i.e., the one on the telechat) which doesn't focus or discuss CSIDs at all.  Possibly it would be clearer to refer the document as 'that document'?

E.g.,
                                            Even though that document
  focuses on [CSID], the considerations specified in this document
  might also be applicable to the other mechanisms being analyzed and
  compared.



Nit level comments:

(2) p 3, sec 3.  SRv6 SIDs and the IPv6 Addressing Architecture

  It is clear that this format for SRv6 SIDs is not compliant with the
  requirements set forth in [RFC4291] for IPv6 addresses but it is also
  clear that SRv6 SIDs are not intended for assignment onto interfaces
  on end hosts.  They look and act similar to other mechanisms that use
  IPv6 addresses with different formats such as [RFC6052] that defines
  the IPv6 Addressing of IPv4/IPv6 Translators and [RFC7343] that
  describes ORCHIDv2 (a cryptographic hash identifier format).

Perhaps 'look and act similarly'?

Regards,
Rob
2024-01-29
05 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2024-01-20
05 Bernie Volz Request for Telechat review by INTDIR is assigned to Juan-Carlos Zúñiga
2024-01-18
05 Éric Vyncke Requested Telechat review by INTDIR
2024-01-15
05 Petr Špaček Request for Telechat review by DNSDIR Completed: Ready with Issues. Reviewer: Petr Špaček. Sent review to list.
2024-01-13
05 Jim Reid Request for Telechat review by DNSDIR is assigned to Petr Špaček
2024-01-12
05 Tero Kivinen Request for Telechat review by SECDIR is assigned to Linda Dunbar
2024-01-11
05 Éric Vyncke Requested Telechat review by DNSDIR
2024-01-08
05 Erik Kline Placed on agenda for telechat - 2024-02-01
2024-01-08
05 Erik Kline Changed consensus to Yes from Unknown
2024-01-08
05 Erik Kline Ballot has been issued
2024-01-08
05 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2024-01-08
05 Erik Kline Created "Approve" ballot
2024-01-08
05 Erik Kline IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2024-01-08
05 Erik Kline Ballot writeup was changed
2024-01-08
05 Suresh Krishnan New version available: draft-ietf-6man-sids-05.txt
2024-01-08
05 Suresh Krishnan New version accepted (logged-in submitter: Suresh Krishnan)
2024-01-08
05 Suresh Krishnan Uploaded new revision
2023-12-09
04 (System) Changed action holders to Erik Kline (IESG state changed)
2023-12-09
04 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-12-09
04 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2023-12-09
04 Suresh Krishnan New version available: draft-ietf-6man-sids-04.txt
2023-12-09
04 (System) New version approved
2023-12-09
04 (System) Request for posting confirmation emailed to previous authors: Suresh Krishnan
2023-12-09
04 Suresh Krishnan Uploaded new revision
2023-11-08
03 Erik Kline Awaiting:
  * updates for directorate reviews
  * updates for IANA review
2023-11-08
03 (System) Changed action holders to Suresh Krishnan (IESG state changed)
2023-11-08
03 Erik Kline IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2023-10-30
03 Yingzhen Qu Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Yingzhen Qu. Sent review to list.
2023-10-27
03 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-10-26
03 Barry Leiba Closed request for Last Call review by ARTART with state 'Team Will not Review Document'
2023-10-26
03 Todd Herr Assignment of request for Last Call review by ARTART to Todd Herr was rejected
2023-10-26
03 Reese Enghardt Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Reese Enghardt. Sent review to list.
2023-10-25
03 Linda Dunbar Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Linda Dunbar. Sent review to list.
2023-10-24
03 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2023-10-24
03 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-6man-sids-03. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-6man-sids-03. If any part of this review is inaccurate, please let us know.

IANA has a question about the action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In Section 6 of the current document, the author requests that IANA "assign a /16 address block for the purposes described in Section 5 out of the 'Reserved by IETF' range defined in the Internet Protocol Version 6 Address Space registry."

IANA Question --> IANA would prefer that Section 6 be redrafted to provide the information needed to populate the IANA IPv6 Special-Purpose Address Registry located at:

https://www.iana.org/assignments/iana-ipv6-special-registry/

IANA believes that this registry is the correct place to document a global unicast prefix for SIDs.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2023-10-19
03 Jean Mahoney Request for Last Call review by GENART is assigned to Reese Enghardt
2023-10-19
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2023-10-19
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Yingzhen Qu
2023-10-16
03 Barry Leiba Request for Last Call review by ARTART is assigned to Todd Herr
2023-10-13
03 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-10-13
03 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-10-27):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-sids@ietf.org, ek.ietf@gmail.com, furry13@gmail.com …
The following Last Call announcement was sent out (ends 2023-10-27):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-sids@ietf.org, ek.ietf@gmail.com, furry13@gmail.com, ipv6@ietf.org, otroan@employees.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Segment Identifiers in SRv6) to Informational RFC


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'Segment Identifiers in SRv6'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-10-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The data plane for Segment Routing over IPv6 (SRv6) is built using
  IPv6 as the underlying forwarding plane.  Due to this underlying use
  of IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6
  addresses and behave like them while exhibiting slightly different
  behaviors in some situations.  This document explores the
  characteristics of SRv6 SIDs and to clarify the relationship of SRv6
  SIDs to the IPv6 Addressing Architecture.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-sids/



No IPR declarations have been submitted directly on this I-D.




2023-10-13
03 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-10-13
03 Cindy Morgan Last call announcement was generated
2023-10-12
03 Erik Kline Last call was requested
2023-10-12
03 Erik Kline Last call announcement was generated
2023-10-12
03 Erik Kline Ballot approval text was generated
2023-10-12
03 Erik Kline Ballot writeup was generated
2023-10-12
03 Erik Kline IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2023-10-12
03 Erik Kline
# Internet AD comments for draft-ietf-6man-sids-03
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

### S5

* Might be good to expand on …
# Internet AD comments for draft-ietf-6man-sids-03
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

### S5

* Might be good to expand on "fail closed", even just parenthetically.
  Perhaps " (e.g., nodes can default to dropping traffic within this prefix
  unless explicitly configured otherwise)."

## Nits

### S3

* s/observed/observed./
2023-10-12
03 Erik Kline IESG state changed to AD Evaluation::AD Followup from AD Evaluation
2023-10-06
03 (System) Changed action holders to Erik Kline (IESG state changed)
2023-10-06
03 Erik Kline IESG state changed to AD Evaluation from Publication Requested
2023-10-05
03 Jen Linkova
# Document Shepherd Write-Up for Group Documents


*This version is dated 4 July 2022.*


Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents


*This version is dated 4 July 2022.*


Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.


Note that some numbered items contain multiple related questions; please be sure
to answer all of them.


## Document History


1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?


The work was started in the 6MAN WG on a request from the SPRING WG chairs ( https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=NMqlpoVcUJEvHTcETZ0oAar6sDw, see Section 9 of this write-up for more details).
The draft was discussed extensively in 6MAN and in SPRING. The document received strong support from multiple individuals.


WGLC thread: https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=oWlNKHANKocBjl0lV4ho-jmgoAc


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?


No controversy or particularly rough consensus were observed. The discussion on the mailing list was extensive and productive, but not rough.
The SPRING co-chair (Joel Halpern) also reviewed the document and confirmed that he is happy with the draft.




3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)


Nobody has  threatened an appeal or otherwise indicated extreme discontent.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?


This is not a protocol document. 


This document is informational and doesn’t require any implementation. (If future SRv6 deployments start using the allocated /16 for SIDs it could be considered an implementation, but it’s not going to happen until the IANA allocation is made).






## Additional Reviews


5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.


This document closely interacts with SPRING, as the goal of the draft  is to clarify the relationship between SRv6 SIDs  and IPv6 addressing architecture.


Every revision of the draft (before and after adoption) was actively discussed in SPRING WG, which was also copied (and actively participated) in the WGLC (see https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=oWlNKHANKocBjl0lV4ho-jmgoAc
)


The SPRING co-chair (Joel Halpern) also reviewed the document and confirmed that he is happy with the draft.


As the draft suggested some action items for the SPRING draft-ietf-spring-srv6-srh-compression document,  github issues were opened for draft-ietf-spring-srv6-srh-compression and have been resolved by the SPRING WG:


https://github.com/ietf-wg-spring/draft-ietf-spring-srv6-srh-compression/issues?q=is%3Aissue+is%3Aclosed


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.


No such review is needed.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?


The document doesn’t contain any YANG module.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.


The document doesn’t contain any such formal language.


## Document Shepherd Checks


9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?


The document was created on request and with the collaboration of the SPRING WG.


During the adoption of draft-filsfilscheng-spring-srv6-srh-compression (replaced by draft-ietf-spring-srv6-srh-compression) a number of questions were raised regarding relationship between SRv6 SIDs (esp. C-SIDs) and IPv6 addresses as defined in RFC4291 and RFC8200): while SIDs are 128-bits identifiers placed into the Destination Address field of an IPv6 header, they are semantically different. Both SPRING and 6MAN WGs believe that some clarification is needed to ensure that using C-SIDs do not conflict with IPv6 address architecture and data plane behavior.


After an extensive discussion in  6MAN and SPRING WGs (https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=NMqlpoVcUJEvHTcETZ0oAar6sDw), the chairs and ADs suggested (https://mailarchive.ietf.org/arch/msg/ipv6/rGgpWZyPaKonLaeuT37D7qZ1Vcw/) writing a document to clarify and categorize SRv6 SIDs, especially how they are related to IPv6 addresses.


Both WGs and the shepherd believe that the document is needed, especially for advancing draft-ietf-spring-srv6-srh-compression.


The shepherd believes that the document is clearly written, complete and ready to be handed off to the responsible Area Director.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    Reviews?


As the document discusses the relationship between IPv6 addresses and SRv6 SIDs, most of the issues listed in [6] are not applicable. In particular, the document doesn’t cover any topics from ART, Ops, Routing, Sec and TSV sections of [6]. The document looks good in regards to issues defined in https://wiki.ietf.org/group/int/IntAreaIssues.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?


The draft is requested to be published as an Informational document. This is the most suitable type, as this document doesn’t define a protocol, a procedure or a format.


While it requests an IANA allocation and recommends that SRv6 deployments are using that dedicated block, that doesn’t seem to be sufficient to classify the document as BCP.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.


The author confirmed that they are not  aware of any IPR claims related to draft-ietf-6man-sids.






13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.


Yes the sole author of the document is willing to be listed as such.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)


The -03 version of the draft was checked against https://authors.ietf.org/en/content-guidelines-overview and the idnits tool was run.
Two issues identified by idnits tool will be fixed in -04 (confirmed with the author). No other issues were found.




15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The informative references are either only providing additional information or drafts in progress. None of those references shall be normative instead. The normative references listed in the draft are required to understand the draft in question, hence they shall stay normative.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    References?


All normative references are RFCs, hence freely available to anyone.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.


No such references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?


All normative references are RFCs.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.


This document doesn’t update/change the status of any existing RFC.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).




The document asks IANA to reserve /16 for a Global Unicast Prefix for SIDs. The registry (the Internet Protocol Version 6 Address Space) and the range (“reserved for IETF”) are clearly identified in the document. Overall, the IANA  considerations section is clear.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.


No new IANA registries are proposed by this document.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2023-10-05
03 Jen Linkova Responsible AD changed to Erik Kline
2023-10-05
03 Jen Linkova IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2023-10-05
03 Jen Linkova IESG state changed to Publication Requested from I-D Exists
2023-10-05
03 Jen Linkova Document is now in IESG state Publication Requested
2023-10-05
03 Jen Linkova Notification list changed to otroan@employees.org, furry13@gmail.com, bob.hinden@gmail.com from otroan@employees.org, furry13@gmail.com
2023-10-05
03 Jen Linkova
# Document Shepherd Write-Up for Group Documents


*This version is dated 4 July 2022.*


Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents


*This version is dated 4 July 2022.*


Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.


Note that some numbered items contain multiple related questions; please be sure
to answer all of them.


## Document History


1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?


The work was started in the 6MAN WG on a request from the SPRING WG chairs ( https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=NMqlpoVcUJEvHTcETZ0oAar6sDw, see Section 9 of this write-up for more details).
The draft was discussed extensively in 6MAN and in SPRING. The document received strong support from multiple individuals.


WGLC thread: https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=oWlNKHANKocBjl0lV4ho-jmgoAc


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?


No controversy or particularly rough consensus were observed. The discussion on the mailing list was extensive and productive, but not rough.
The SPRING co-chair (Joel Halpern) also reviewed the document and confirmed that he is happy with the draft.




3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)


Nobody has  threatened an appeal or otherwise indicated extreme discontent.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?


This is not a protocol document. 


This document is informational and doesn’t require any implementation. (If future SRv6 deployments start using the allocated /16 for SIDs it could be considered an implementation, but it’s not going to happen until the IANA allocation is made).






## Additional Reviews


5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.


This document closely interacts with SPRING, as the goal of the draft  is to clarify the relationship between SRv6 SIDs  and IPv6 addressing architecture.


Every revision of the draft (before and after adoption) was actively discussed in SPRING WG, which was also copied (and actively participated) in the WGLC (see https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=oWlNKHANKocBjl0lV4ho-jmgoAc
)


The SPRING co-chair (Joel Halpern) also reviewed the document and confirmed that he is happy with the draft.


As the draft suggested some action items for the SPRING draft-ietf-spring-srv6-srh-compression document,  github issues were opened for draft-ietf-spring-srv6-srh-compression and have been resolved by the SPRING WG:


https://github.com/ietf-wg-spring/draft-ietf-spring-srv6-srh-compression/issues?q=is%3Aissue+is%3Aclosed


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.


No such review is needed.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?


The document doesn’t contain any YANG module.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.


The document doesn’t contain any such formal language.


## Document Shepherd Checks


9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?


The document was created on request and with the collaboration of the SPRING WG.


During the adoption of draft-filsfilscheng-spring-srv6-srh-compression (replaced by draft-ietf-spring-srv6-srh-compression) a number of questions were raised regarding relationship between SRv6 SIDs (esp. C-SIDs) and IPv6 addresses as defined in RFC4291 and RFC8200): while SIDs are 128-bits identifiers placed into the Destination Address field of an IPv6 header, they are semantically different. Both SPRING and 6MAN WGs believe that some clarification is needed to ensure that using C-SIDs do not conflict with IPv6 address architecture and data plane behavior.


After an extensive discussion in  6MAN and SPRING WGs (https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=NMqlpoVcUJEvHTcETZ0oAar6sDw), the chairs and ADs suggested (https://mailarchive.ietf.org/arch/msg/ipv6/rGgpWZyPaKonLaeuT37D7qZ1Vcw/) writing a document to clarify and categorize SRv6 SIDs, especially how they are related to IPv6 addresses.


Both WGs and the shepherd believe that the document is needed, especially for advancing draft-ietf-spring-srv6-srh-compression.


The shepherd believes that the document is clearly written, complete and ready to be handed off to the responsible Area Director.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    Reviews?


As the document discusses the relationship between IPv6 addresses and SRv6 SIDs, most of the issues listed in [6] are not applicable. In particular, the document doesn’t cover any topics from ART, Ops, Routing, Sec and TSV sections of [6]. The document looks good in regards to issues defined in https://wiki.ietf.org/group/int/IntAreaIssues.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?


The draft is requested to be published as an Informational document. This is the most suitable type, as this document doesn’t define a protocol, a procedure or a format.


While it requests an IANA allocation and recommends that SRv6 deployments are using that dedicated block, that doesn’t seem to be sufficient to classify the document as BCP.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.


The author confirmed that they are not  aware of any IPR claims related to draft-ietf-6man-sids.






13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.


Yes the sole author of the document is willing to be listed as such.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)


The -03 version of the draft was checked against https://authors.ietf.org/en/content-guidelines-overview and the idnits tool was run.
Two issues identified by idnits tool will be fixed in -04 (confirmed with the author). No other issues were found.




15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The informative references are either only providing additional information or drafts in progress. None of those references shall be normative instead. The normative references listed in the draft are required to understand the draft in question, hence they shall stay normative.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    References?


All normative references are RFCs, hence freely available to anyone.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.


No such references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?


All normative references are RFCs.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.


This document doesn’t update/change the status of any existing RFC.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).




The document asks IANA to reserve /16 for a Global Unicast Prefix for SIDs. The registry (the Internet Protocol Version 6 Address Space) and the range (“reserved for IETF”) are clearly identified in the document. Overall, the IANA  considerations section is clear.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.


No new IANA registries are proposed by this document.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2023-09-26
03 Ole Trøan Notification list changed to otroan@employees.org, furry13@gmail.com from otroan@employees.org because the document shepherd was set
2023-09-26
03 Ole Trøan Document shepherd changed to Jen Linkova
2023-05-20
03 Ole Trøan Notification list changed to otroan@employees.org because the document shepherd was set
2023-05-20
03 Ole Trøan Document shepherd changed to Ole Trøan
2023-05-19
03 Ole Trøan IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2023-04-11
03 Suresh Krishnan New version available: draft-ietf-6man-sids-03.txt
2023-04-11
03 (System) New version approved
2023-04-11
03 (System) Request for posting confirmation emailed to previous authors: Suresh Krishnan
2023-04-11
03 Suresh Krishnan Uploaded new revision
2022-10-21
02 Jen Linkova Added to session: IETF-115: 6man  Mon-1300
2022-10-11
02 Suresh Krishnan New version available: draft-ietf-6man-sids-02.txt
2022-10-11
02 Suresh Krishnan New version accepted (logged-in submitter: Suresh Krishnan)
2022-10-11
02 Suresh Krishnan Uploaded new revision
2022-09-17
01 Jen Linkova IETF WG state changed to In WG Last Call from WG Document
2022-07-19
01 Jen Linkova Added to session: IETF-114: 6man  Wed-1500
2022-05-17
01 Suresh Krishnan New version available: draft-ietf-6man-sids-01.txt
2022-05-17
01 Suresh Krishnan New version accepted (logged-in submitter: Suresh Krishnan)
2022-05-17
01 Suresh Krishnan Uploaded new revision
2022-04-21
00 Bob Hinden This document now replaces draft-krishnan-6man-sids instead of None
2022-04-17
00 Bob Hinden Intended Status changed to Informational from None
2022-04-14
00 Suresh Krishnan New version available: draft-ietf-6man-sids-00.txt
2022-04-14
00 (System) WG -00 approved
2022-04-14
00 Suresh Krishnan Set submitter to "Suresh Krishnan ", replaces to (none) and sent approval email to group chairs: 6man-chairs@ietf.org
2022-04-14
00 Suresh Krishnan Uploaded new revision