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 |