I-D list for IPv6 Maintenance RSS FeedDocument changesurn:uuid:2cdb3c87-ecc2-5dea-86aa-f5088c14112b2024-03-28T19:36:34-0700Signalling DHCPv6 Prefix Delegation Availability to Hosts9829392024-03-21T21:47:37-07002024-03-21T21:47:37-0700Jen LinkovaNew version available: <b>draft-ietf-6man-pio-pflag-02.txt</b>new_revisionietf6manactiveidexistswg-doc This document defines a "P" flag in the Prefix Information Option of
IPv6 Router Advertisements (RAs). The flag is used to indicate that
the network prefers that clients do not use the prefix provided in
the PIO for SLAAC but request a prefix via DHCPv6 PD instead, and use
that delegated prefix to form addresses.
02Signalling DHCPv6 Prefix Delegation Availability to Hosts9829382024-03-21T21:47:37-07002024-03-21T21:47:37-0700Jen LinkovaNew version accepted (logged-in submitter: Jen Linkova)new_submissionietf6manactiveidexistswg-docSignalling DHCPv6 Prefix Delegation Availability to Hosts9829372024-03-21T21:47:37-07002024-03-21T21:47:37-0700Jen LinkovaUploaded new revisionnew_submissionietf6manactiveidexistswg-docLimits on Sending and Processing IPv6 Extension Headers9829162024-03-21T20:17:46-07002024-03-21T20:17:46-0700Jen LinkovaTo match the actual rendered text, as we agreed to change the statusadded_commentietf6manSuresh Krishnanactiveidexistschair-wLimits on Sending and Processing IPv6 Extension Headers9829152024-03-21T20:17:44-07002024-03-21T20:17:44-0700Jen LinkovaIntended Status changed to <b>Best Current Practice</b> from Proposed Standardchanged_documentietf6manSuresh Krishnanactiveidexistschair-wLimits on Sending and Processing IPv6 Extension Headers9826932024-03-21T01:26:36-07002024-03-21T01:26:36-0700Bob HindenNotification list changed to suresh.krishnan@gmail.com because the document shepherd was setadded_commentietf6manSuresh Krishnanactiveidexistschair-wLimits on Sending and Processing IPv6 Extension Headers9826922024-03-21T01:26:36-07002024-03-21T01:26:36-0700Bob HindenDocument shepherd changed to Suresh Krishnanadded_commentietf6manSuresh Krishnanactiveidexistschair-wRepresenting IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers9826372024-03-21T00:05:01-07002024-03-21T00:05:01-0700(System)Document has expiredexpired_documentietf6manJen LinkovaErik Klineexpiredchangeddeadsub-pubRepresenting IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers9825442024-03-20T21:08:17-07002024-03-20T21:08:17-0700Erik KlineClosing out this document and its approach.<br><br>Moving forward by considering:<br><br>* [draft-carpenter-6man-zone-ui](https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/) and<br>* [draft-schinazi-httpbis-link-local-uri-bcp](https://datatracker.ietf.org/doc/draft-schinazi-httpbis-link-local-uri-bcp/)<br><br>as starting points.added_commentietf6manJen LinkovaErik Klineexpiredchangeddeadsub-pubRepresenting IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers9825432024-03-20T21:08:16-07002024-03-20T21:08:16-0700(System)Removed all action holders (IESG state changed)changed_action_holdersietf6manJen LinkovaErik Klineexpiredchangeddeadsub-pubRepresenting IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers9825422024-03-20T21:08:16-07002024-03-20T21:08:16-0700Erik KlineIESG state changed to <b>Dead</b> from IESG Evaluation::AD Followupchanged_stateietf6manJen LinkovaErik Klineexpiredchangeddeadsub-pubThe IPv6 Compact Routing Header (CRH)9824352024-03-20T17:34:44-07002024-03-20T17:34:44-0700Erik KlineIESG state changed to <b>AD Evaluation</b> from Publication Requestedchanged_stateietf6manBob HindenErik Klineactivead-evalsub-pubStub Router Flag in ICMPv6 Router Advertisement Messages9819552024-03-19T21:04:53-07002024-03-19T21:04:53-0700Jonathan HuiThis document now replaces <b>draft-hui-stub-router-ra-flag</b> instead of Nonechanged_documentnoneactiveidexistsStub Router Flag in ICMPv6 Router Advertisement Messages9819542024-03-19T21:04:53-07002024-03-19T21:04:53-0700Jonathan HuiNew version available: <b>draft-hui-6man-stub-router-ra-flag-00.txt</b>new_revisionnoneactiveidexists This document defines a new flag, the Stub Router flag, in the Router
Advertisement message that can be used to distinguish configuration
information sent by stub routers from information sent by
infrastructure routers. This flag is used only by stub routers and
is ignored by all other devices.
00Stub Router Flag in ICMPv6 Router Advertisement Messages9819532024-03-19T21:04:53-07002024-03-19T21:04:53-0700Jonathan HuiNew version accepted (logged-in submitter: Jonathan Hui)new_submissionnoneactiveidexistsStub Router Flag in ICMPv6 Router Advertisement Messages9819522024-03-19T21:04:03-07002024-03-19T21:04:03-0700Jonathan HuiUploaded new revisionnew_submissionnoneactiveidexistsThe IPv6 Compact Routing Header (CRH)9810322024-03-18T16:15:06-07002024-03-18T16:15:06-0700Bob HindenThe IPv6 Compact Routing Header (CRH)<br>draft-ietf-6man-comp-rtg-hdr-04<br><br>Document Shephard: Bob Hinden <bob.hinden@gmail.com><br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad<br> agreement?<br><br>There was strong support for publishing this document as an Experimental<br>RFC. Some questions were raised about open source implementations, but<br>that wasn't required to be published as an Experimental RFC.<br><br>Several issues with the document were identified during the w.g. last<br>call, these were all resolved in the current version of the document.<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>No, there was a consensus to publish as an Experimental RFC.<br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No.<br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br><br>Current implementations are documented in Section 12. "Implementation and<br>Deployment Status":<br><br> Juniper Networks has produced experimental implementations of the CRH<br> on the MX-series (ASIC-based) router<br><br> Liquid Telecom has produced experimental implementations of the CRH<br> on software based routers.<br><br> The CRH has carried non-production traffic in CERNET and Liquid<br> Telecom.<br><br>Also, given the intended status of Experimental, Section 13 "Experimental<br>Results" provides topics that experimenters should evaluate.<br><br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>The document describes a new type of IPv6 Routing header. There were<br>good reviews in the 6MAN w.g., and several people from the SPRING<br>w.g. expressed support.<br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>N/A<br><br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>N/A, no Yang model.<br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>N/A<br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>Yes<br><br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>N/A<br><br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Experimental RFC. The Datatracker shows this intended status.<br><br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Yes, all of the authors have confirmed IPR requirements.<br><br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Yes, all authors confirmed this.<br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br><br>There were a few minor ID nits in the -03 draft , the shepherd asked the authors to fix<br>them, they are fixed in the -04 draft.<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>References are appropriate.<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br><br>All references are stable and accessable.<br><br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br><br>No. <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>All references point to RFCs or other stable document. No references to IDs.<br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is<br> discussed.<br><br>This does not change the status of any existing RFCs.<br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>The IANA considerations section makes permanent two temporary assignments Routing<br>Types that were assinged earlier.<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>None.<br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_documentietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9810312024-03-18T16:15:06-07002024-03-18T16:15:06-0700Bob HindenIETF WG state changed to <b>Submitted to IESG for Publication</b> from WG Consensus: Waiting for Write-Upchanged_stateietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9810302024-03-18T16:15:05-07002024-03-18T16:15:05-0700Bob HindenIESG state changed to <b>Publication Requested</b> from I-D Existschanged_stateietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9810292024-03-18T16:15:05-07002024-03-18T16:15:05-0700(System)Changed action holders to Erik Kline (IESG state changed)changed_action_holdersietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9810282024-03-18T16:15:05-07002024-03-18T16:15:05-0700Bob HindenResponsible AD changed to Erik Klinechanged_documentietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9810272024-03-18T16:15:04-07002024-03-18T16:15:04-0700Bob HindenDocument is now in IESG state <b>Publication Requested</b>started_iesg_processietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9810242024-03-18T16:13:48-07002024-03-18T16:13:48-0700Bob HindenThe IPv6 Compact Routing Header (CRH)<br>draft-ietf-6man-comp-rtg-hdr-04<br><br>Document Shephard: Bob Hinden <bob.hinden@gmail.com><br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad<br> agreement?<br><br>There was strong support for publishing this document as an Experimental<br>RFC. Some questions were raised about open source implementations, but<br>that wasn't required to be published as an Experimental RFC.<br><br>Several issues with the document were identified during the w.g. last<br>call, these were all resolved in the current version of the document.<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>No, there was a consensus to publish as an Experimental RFC.<br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No.<br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br><br>Current implementations are documented in Section 12. "Implementation and<br>Deployment Status":<br><br> Juniper Networks has produced experimental implementations of the CRH<br> on the MX-series (ASIC-based) router<br><br> Liquid Telecom has produced experimental implementations of the CRH<br> on software based routers.<br><br> The CRH has carried non-production traffic in CERNET and Liquid<br> Telecom.<br><br>Also, given the intended status of Experimental, Section 13 "Experimental<br>Results" provides topics that experimenters should evaluate.<br><br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>The document describes a new type of IPv6 Routing header. There were<br>good reviews in the 6MAN w.g., and several people from the SPRING<br>w.g. expressed support.<br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>N/A<br><br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>N/A, no Yang model.<br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>N/A<br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>Yes<br><br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>N/A<br><br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Experimental RFC. The Datatracker shows this intended status.<br><br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Yes, all of the authors have confirmed IPR requirements.<br><br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Yes, all authors confirmed this.<br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br><br>There were a few minor ID nits in the -03 draft , the shepherd asked the authors to fix<br>them, they are fixed in the -04 draft.<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>References are appropriate.<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br><br>All references are stable and accessable.<br><br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br><br>No. <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>All references point to RFCs or other stable document. No references to IDs.<br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is<br> discussed.<br><br>This does not change the status of any existing RFCs.<br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>The IANA considerations section makes permanent two temporary assignments Routing<br>Types that were assinged earlier.<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>None.<br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9807472024-03-18T05:42:43-07002024-03-18T05:42:43-0700Bob HindenThe IPv6 Compact Routing Header (CRH)<br>draft-ietf-6man-comp-rtg-hdr-04<br><br>Document Shephard: Bob Hinden <bob.hinden@gmail.com><br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad<br> agreement?<br><br>There was strong support for publishing this document as an Experimental<br>RFC. Some questions were raised about open source implementations, but<br>that wasn't required to be published as an Experimental RFC.<br><br>Several issues with the document were identified during the w.g. last<br>call, these were all resolved in the current version of the document.<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>No, the consensus was strong.<br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No.<br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br><br>Current implementations are documented in Section 12. "Implementation and<br>Deployment Status":<br><br> Juniper Networks has produced experimental implementations of the CRH<br> on the MX-series (ASIC-based) router<br><br> Liquid Telecom has produced experimental implementations of the CRH<br> on software based routers.<br><br> The CRH has carried non-production traffic in CERNET and Liquid<br> Telecom.<br><br>Also, given the intended status of Experimental, Section 13 "Experimental<br>Results" provides topics that experimenters should evaluate.<br><br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>The document describes a new type of IPv6 Routing header. There were<br>good reviews in the 6MAN w.g., and several people from the SPRING<br>w.g. expressed support.<br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>N/A<br><br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>N/A, no Yang model.<br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>N/A<br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>Yes<br><br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>N/A<br><br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Experimental RFC. The Datatracker shows this intended status.<br><br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Yes, all of the authors have confirmed IPR requirements.<br><br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Yes, all authors confirmed this.<br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br><br>There were a few minor ID nits in the -03 draft , the shephard asked the authors to fix<br>them, they are fixed in the -04 draft.<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>References are appropriate.<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br><br>All references are stable and accessable.<br><br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br><br>No. <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>All references point to RFCs or other stable document. No references to IDs.<br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is<br> discussed.<br><br>This does not change the status of any existing RFCs.<br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>The IANA considerations makes permeant two temporary assignments Routing<br>Types.<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>None.<br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9807452024-03-18T05:41:02-07002024-03-18T05:41:02-0700Bob HindenThe IPv6 Compact Routing Header (CRH)<br>draft-ietf-6man-comp-rtg-hdr-04<br><br>Document Shephard: Bob Hinden <bob.hinden@gmail.com><br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad<br> agreement?<br><br>There was strong support for publishing this document as an Experimental<br>RFC. Some questions were raised about open source implementations, but<br>that wasn't required to be published as an Experimental RFC.<br><br>Several issues with the document were identified during the w.g. last<br>call, these were all resolved in the current version of the document.<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>No, the consensus was strong.<br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No.<br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br><br>Current implementations are documented in Section 12. "Implementation and<br>Deployment Status":<br><br> Juniper Networks has produced experimental implementations of the CRH<br> on the MX-series (ASIC-based) router<br><br> Liquid Telecom has produced experimental implementations of the CRH<br> on software based routers.<br><br> The CRH has carried non-production traffic in CERNET and Liquid<br> Telecom.<br><br>Also, given the intended status of Experimental, Section 13 "Experimental<br>Results" provides topics that experimenters should evaluate.<br><br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>The document describes a new type of IPv6 Routing header. There were<br>good reviews in the 6MAN w.g., and several people from the SPRING<br>w.g. expressed support.<br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>N/A<br><br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>N/A, no Yang model.<br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>N/A<br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>Yes<br><br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>N/A<br><br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Experimental RFC. The Datatracker shows this intended status.<br><br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Yes, all of the authors have confirmed IPR requirements.<br><br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Yes, all authors confirmed this.<br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br><br>There were a few minior ID nits in the -03 draft , the shephard asked the authors to fix<br>them, they are fixed in the -04 draft.<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>References are appropriate.<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br><br>All references are stable and accessable.<br><br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br><br>No. <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>All references point to RFCs or other stable document. No references to IDs.<br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is<br> discussed.<br><br>This does not change the status of any existing RFCs.<br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>The IANA considerations makes permeant two temporary assignments Routing<br>Types.<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>None.<br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9807282024-03-18T05:04:13-07002024-03-18T05:04:13-0700Ron BonicaNew version available: <b>draft-ietf-6man-comp-rtg-hdr-04.txt</b>new_revisionietf6manBob HindenErik Klineactivead-evalsub-pub This document describes an experiment in which two new IPv6 Routing
headers are implemented and deployed. Collectively, they are called
the Compact Routing Headers (CRH). Individually, they are called
CRH-16 and CRH-32.
One purpose of this experiment is to demonstrate that the CRH can be
implemented and deployed in a production network. Another purpose is
to demonstrate that the security considerations, described in this
document, can be addressed with access control lists. Finally, this
document encourages replication of the experiment.
04The IPv6 Compact Routing Header (CRH)9807272024-03-18T05:04:13-07002024-03-18T05:04:13-0700Ron BonicaNew version accepted (logged-in submitter: Ron Bonica)new_submissionietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9807262024-03-18T05:04:12-07002024-03-18T05:04:12-0700Ron BonicaUploaded new revisionnew_submissionietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9804922024-03-17T23:05:54-07002024-03-17T23:05:54-0700Bob HindenThe IPv6 Compact Routing Header (CRH)<br>draft-ietf-6man-comp-rtg-hdr-03<br><br>Document Shephard: Bob Hinden <bob.hinden@gmail.com><br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad<br> agreement?<br><br>There was strong support for publishing this document as an Experimental<br>RFC. Some questions were raised about open source implementations, but<br>that wasn't required to be published as an Experimental RFC.<br><br>Several issues with the document were identified during the w.g. last<br>call, these were all resolved in the current version of the document.<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>No, the consensus was strong.<br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No.<br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br><br>Current implementations are documented in Section 12. "Implementation and<br>Deployment Status":<br><br> Juniper Networks has produced experimental implementations of the CRH<br> on the MX-series (ASIC-based) router<br><br> Liquid Telecom has produced experimental implementations of the CRH<br> on software based routers.<br><br> The CRH has carried non-production traffic in CERNET and Liquid<br> Telecom.<br><br>Also, given the intended status of Experimental, Section 13 "Experimental<br>Results" provides topics that experimenters should evaluate.<br><br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>The document describes a new type of IPv6 Routing header. There were<br>good reviews in the 6MAN w.g., and several people from the SPRING<br>w.g. expressed support.<br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>N/A<br><br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>N/A, no Yang model.<br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>N/A<br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>Yes<br><br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>N/A<br><br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Experimental RFC. The Datatracker shows this intended status.<br><br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Yes, all of the authors have confirmed IPR requirements.<br><br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Yes, all authors confirmed this.<br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br><br>A few minior ID nits were found, the shephard asked the authors to fix<br>them.<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>References are appropriate.<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br><br>All references are stable and accessable.<br><br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br><br>No. <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>All references point to RFCs or other stable document. No references to IDs.<br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is<br> discussed.<br><br>This does not change the status of any existing RFCs.<br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>The IANA considerations makes permeant two temporary assignments Routing<br>Types.<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>None.<br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietf6manBob HindenErik Klineactivead-evalsub-pubSignalling DHCPv6 Prefix Delegation Availability to Hosts9804232024-03-17T21:48:10-07002024-03-17T21:48:10-0700Jen LinkovaNew version available: <b>draft-ietf-6man-pio-pflag-01.txt</b>new_revisionietf6manactiveidexistswg-doc This document defines a "P" flag in the Prefix Information Option of
IPv6 Router Advertisements (RAs). The flag is used to indicate that
the network prefers that clients do not use the prefix provided in
the PIO for SLAAC but request a prefix via DHCPv6 PD instead, and use
that delegated prefix to form addresses.
02Signalling DHCPv6 Prefix Delegation Availability to Hosts9804222024-03-17T21:48:10-07002024-03-17T21:48:10-0700Jen LinkovaNew version accepted (logged-in submitter: Jen Linkova)new_submissionietf6manactiveidexistswg-docSignalling DHCPv6 Prefix Delegation Availability to Hosts9804212024-03-17T21:48:10-07002024-03-17T21:48:10-0700Jen LinkovaUploaded new revisionnew_submissionietf6manactiveidexistswg-docThe IPv6 Compact Routing Header (CRH)9803702024-03-17T21:02:48-07002024-03-17T21:02:48-0700Bob HindenIntended Status changed to <b>Experimental</b> from Nonechanged_documentietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9803572024-03-17T20:43:50-07002024-03-17T20:43:50-0700Bob HindenNotification list changed to furry13@gmail.com, bob.hinden@gmail.com from furry13@gmail.com because the document shepherd was setadded_commentietf6manBob HindenErik Klineactivead-evalsub-pubThe IPv6 Compact Routing Header (CRH)9803562024-03-17T20:43:50-07002024-03-17T20:43:50-0700Bob HindenDocument shepherd changed to Bob Hindenadded_commentietf6manBob HindenErik Klineactivead-evalsub-pubConsiderations for common QoS IPv6 extension header(s)9800072024-03-17T07:47:03-07002024-03-17T07:47:03-0700Lou BergerAdded to session: IETF-119: detnet Wed-2330added_commentnoneactiveidexists