Network Service Header (NSH) Encapsulation for In Situ OAM (IOAM) Data
draft-ietf-sfc-ioam-nsh-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2023-08-15
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2023-07-31
|
13 | (System) | RFC Editor state changed to AUTH48 |
2023-06-02
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2023-05-11
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2023-05-11
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2023-05-11
|
13 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2023-05-11
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2023-05-11
|
13 | (System) | IANA Action state changed to In Progress from On Hold |
2023-05-11
|
13 | (System) | IANA Action state changed to On Hold from In Progress |
2023-05-11
|
13 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2023-05-11
|
13 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Leif Johansson was marked no-response |
2023-05-08
|
13 | (System) | RFC Editor state changed to EDIT |
2023-05-08
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2023-05-08
|
13 | (System) | Announcement was received by RFC Editor |
2023-05-08
|
13 | (System) | IANA Action state changed to In Progress |
2023-05-08
|
13 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2023-05-08
|
13 | Amy Vezza | IESG has approved the document |
2023-05-08
|
13 | Amy Vezza | Closed "Approve" ballot |
2023-05-08
|
13 | Amy Vezza | Ballot approval text was generated |
2023-05-08
|
13 | (System) | Removed all action holders (IESG state changed) |
2023-05-08
|
13 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2023-05-05
|
13 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-13.txt |
2023-05-05
|
13 | (System) | New version approved |
2023-05-05
|
13 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2023-05-05
|
13 | Frank Brockners | Uploaded new revision |
2023-05-05
|
12 | Robert Wilton | [Ballot comment] Updated position. Thank you for addressing my discuss concern and comments. Regards, Rob |
2023-05-05
|
12 | Robert Wilton | [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss |
2023-05-04
|
12 | Éric Vyncke | [Ballot comment] Thank you for addressing my previous DISCUSS at https://mailarchive.ietf.org/arch/msg/sfc/AJhH4WygXQyA9AKFBuWTgnFUfik/. Regards -éric |
2023-05-04
|
12 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to Yes from Discuss |
2023-05-04
|
12 | Jim Guichard | [Ballot Position Update] Position for Jim Guichard has been changed to No Objection from Discuss |
2023-05-04
|
12 | Roman Danyliw | [Ballot comment] Thank you for addressing my DISCUSS and COMMENT feedback. |
2023-05-04
|
12 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2023-05-04
|
12 | (System) | Changed action holders to Andrew Alston (IESG state changed) |
2023-05-04
|
12 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-05-04
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-05-04
|
12 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-12.txt |
2023-05-04
|
12 | (System) | New version approved |
2023-05-04
|
12 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2023-05-04
|
12 | Frank Brockners | Uploaded new revision |
2023-05-04
|
11 | Warren Kumari | [Ballot comment] I believe that the Security Considerations section is very underspecified - simply saying that "operators need to properly secure the IOAM domain to … [Ballot comment] I believe that the Security Considerations section is very underspecified - simply saying that "operators need to properly secure the IOAM domain to avoid malicious configuration" feels like it is sidestepping the issues / absolving itself of responsibility. |
2023-05-04
|
11 | Warren Kumari | [Ballot Position Update] New position, Abstain, has been recorded for Warren Kumari |
2023-05-04
|
11 | (System) | Changed action holders to Andrew Alston, Frank Brockners, Shwetha Bhandari (IESG state changed) |
2023-05-04
|
11 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2023-05-03
|
11 | Murray Kucherawy | [Ballot comment] I support Jim's and Roman's DISCUSS positions. Thanks for a well done shepherd writeup. I note that the writeup advises notifying IPPM of … [Ballot comment] I support Jim's and Roman's DISCUSS positions. Thanks for a well done shepherd writeup. I note that the writeup advises notifying IPPM of this work. Was that done? Section 2 defines "SFC", but the document doesn't actually use that term anywhere. |
2023-05-03
|
11 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2023-05-03
|
11 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specification. I am supporting Jim's and Roman's discuss. |
2023-05-03
|
11 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2023-05-02
|
11 | Paul Wouters | [Ballot comment] I support Jim's and Roman's discuss points. |
2023-05-02
|
11 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2023-05-02
|
11 | Robert Wilton | [Ballot discuss] Hi, Thanks for this document. A couple of discuss points that I raised only because I find the spec to be unclear which … [Ballot discuss] Hi, Thanks for this document. A couple of discuss points that I raised only because I find the spec to be unclear which should be be easy to clarify: (1) p 2, sec 3. IOAM encapsulation with NSH The operator MUST ensure that all nodes along the service path support IOAM. Is it actually 'all nodes along the service path' or "SFC aware nodes along the service path" that MUST support IOAM? (2) p 3, sec 3. IOAM encapsulation with NSH IOAM HDR Len: 8 bit Length field contains the length of the IOAM header in 4-octet units. Does this mean quantized to 4 byte units, or that the actual length in bytes is 4 * "Hdr Len" field? |
2023-05-02
|
11 | Robert Wilton | [Ballot comment] (3) p 2, sec 3. IOAM encapsulation with NSH Otherwise packets with IOAM are likely to be dropped per [ … [Ballot comment] (3) p 2, sec 3. IOAM encapsulation with NSH Otherwise packets with IOAM are likely to be dropped per [RFC8300]. There can be multiple IOAM headers added by encapsulating nodes as configured. Possibly "MAY" may be better than "can", since RFC 2119 language is being used elsewhere in this paragraph. Also thanks to Susan Hares for the OPSDIR review. Regards, Rob |
2023-05-02
|
11 | Robert Wilton | [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton |
2023-05-01
|
11 | Éric Vyncke | [Ballot discuss] Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points … [Ballot discuss] Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Greg Mirsky for the shepherd's detailed write-up including the WG consensus ***and*** the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ## Section 3 This is probably due to my lack of knowledge about NSH... So, a simple discussion over email will probably be enough to clear my DISCUSS points. RFC 9197 has an incremental tracing (section 4.4.1), how does it impact the length of the IOAM header in this case? Assuming that this header size is increased, I suggest to add some text about increasing the length field of IOAM header. `When a packet with IOAM is received at an NSH based forwarding node such as an Service Function Forwarder (SFF) that does not understand IOAM header, it SHOULD drop the packet.` is actually a copy of RFC 8300 ``` Packets with Next Protocol values not supported SHOULD be silently dropped by default, although an implementation MAY provide a configuration parameter to forward them. ``` and not a new behaviour. So, let's rather be clear and use a structure like "Per section 2.2 of RFC 8300, ..." followed by the RFC 8300 text. While very similar to Jim Guichard's DISCUSS point, it is related to another part of the document. |
2023-05-01
|
11 | Éric Vyncke | [Ballot comment] # COMMENTS (non-blocking) ## Section 1 Please expand SFF at first use. ## Section 3 Please expand ESP (is it IPsec ESP ?) … [Ballot comment] # COMMENTS (non-blocking) ## Section 1 Please expand SFF at first use. ## Section 3 Please expand ESP (is it IPsec ESP ?) in the packet format. Should there be text about the absence of padding in the "IOAM Option and Optional Data Space" field (assuming that all IOAM options are always in 32-bit units)? ## Section 4 `IANA is requested to allocate protocol numbers for the following "NSH Next Protocol" related to IOAM` is underspecified. If it is about https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol, then let's be clear. Note: I intended to DISCUSS this point, but as Jim is already holding a DISCUSS on the same point, I will let him to be the owner. # NITS (non-blocking / cosmetic) A couple of missing hypens in "open source" or "8 bit field". |
2023-05-01
|
11 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2023-05-01
|
11 | Martin Duke | [Ballot comment] Thanks to Mirja Kuhlewind for the TSVART review. |
2023-05-01
|
11 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2023-05-01
|
11 | John Scudder | [Ballot comment] # John Scudder, RTG AD, comments for draft-ietf-sfc-ioam-nsh-11 CC @jgscudder Thanks for this document. I have a few brief comments. ## COMMENTS ### … [Ballot comment] # John Scudder, RTG AD, comments for draft-ietf-sfc-ioam-nsh-11 CC @jgscudder Thanks for this document. I have a few brief comments. ## COMMENTS ### Section 1, implementation "An implementation of IOAM which leverages NSH to carry the IOAM data is available from the FD.io open source software project [FD.io]." - Is it appropriate to include this here? If you wanted to flag this for reviewers' and WG's information, maybe following the practice recommended in RFC 7942 would be better? That document makes the case (Section 2) for not leaving it in the RFC: Since this information is necessarily time dependent, it is inappropriate for inclusion in a published RFC. - The contradiction with the shepherd writeup is a little concerning: "Although no implementations have been reported..." The shepherd writeup was last updated in July of 2022 but the draft text appears to have been present since the 01 version published March 11, 2019. ### Section 3, header length Perhaps in "IOAM HDR Len: 8 bit Length field contains the length of the IOAM header in 4-octet units", mention that the length covers the type and length fields? I think this is already implicit in what you've written, but better explicit than implicit. ### Section 5, "several operators" I support Roman Danyliw's DISCUSS. ## 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 |
2023-05-01
|
11 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2023-05-01
|
11 | Roman Danyliw | [Ballot discuss] (revised ballot) ** Section 5. IOAM is considered a "per domain" feature, where one or several operators decide on leveraging and … [Ballot discuss] (revised ballot) ** Section 5. IOAM is considered a "per domain" feature, where one or several operators decide on leveraging and configuring IOAM according to their needs. This seems like an an expansion of the applicability statement of IOAM. I don’t see reference to multiple operators in Section 3 of RFC9197. Please explicitly cite the RFC9197 applicability statement to be clear that scope is not being expanded and and consider if discussion of multiple operators is needed. |
2023-05-01
|
11 | Roman Danyliw | [Ballot comment] I support Jim Guichard's DISCUSS position on clarifying Section 3's text: "[t]he operator MUST ensure that all nodes along the service path support … [Ballot comment] I support Jim Guichard's DISCUSS position on clarifying Section 3's text: "[t]he operator MUST ensure that all nodes along the service path support IOAM. Otherwise packets with IOAM are likely to be dropped per [RFC8300]." ** Section 5. Wrong reference. (Same observation as Jim) For additional IOAM related security considerations, see Section 10 in [RFC9197]. s/see Section 10/see Section 9/. |
2023-05-01
|
11 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to Discuss from No Objection |
2023-05-01
|
11 | Roman Danyliw | [Ballot comment] I support Jim Guichard's DISCUSS position on clarifying Section 3's text: "[t]he operator MUST ensure that all nodes along the service path support … [Ballot comment] I support Jim Guichard's DISCUSS position on clarifying Section 3's text: "[t]he operator MUST ensure that all nodes along the service path support IOAM. Otherwise packets with IOAM are likely to be dropped per [RFC8300]." ** Section 5. IOAM is considered a "per domain" feature, where one or several operators decide on leveraging and configuring IOAM according to their needs. Is this an expansion of the applicability statement of IOAM? I don’t see reference to multiple operators in Section 3 of RFC9197. Consider explicitly citing this section. ** Section 5. Wrong reference. (Same observation as Jim) For additional IOAM related security considerations, see Section 10 in [RFC9197]. s/see Section 10/see Section 9/. |
2023-05-01
|
11 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2023-04-30
|
11 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2023-04-28
|
11 | Jim Guichard | [Ballot comment] General comment. There are several typos or grammatical errors in the document. Suggest running an error checker against the document. Section 1: "In-situ … [Ballot comment] General comment. There are several typos or grammatical errors in the document. Suggest running an error checker against the document. Section 1: "In-situ OAM (IOAM)" in the first sentence does not need to be expanded as the authors already did so in the abstract. Section 1: "Service Function Chaining (SFC) [RFC7665]" should read "Service Function Chaining (SFC) Architecture [RFC7665]". Section 3: 6th sentence use of "service path" should probably be changed to the correct terminology used by the SFC architecture which is Service Function Path (SFP). Further, the next sentence should be folded into the 6th sentence as a single sentence to make it more readable. Section 3: "See [I-D.ietf-ippm-ioam-deployment] for a discussion of deployment related aspects of IOAM-Data-fields.". This reference should be changed to [RFC9378]. Section 3: "[I-D.ietf-ippm-ioam-flags]". This reference should be changed to [RFC9322]. Several outdated references need to be updated: == Outdated reference: A later version (-03) exists of draft-ietf-sfc-oam-packet-01 == Outdated reference: draft-ietf-ippm-ioam-deployment has been published as RFC 9378 == Outdated reference: draft-ietf-ippm-ioam-direct-export has been published as RFC 9326 == Outdated reference: draft-ietf-ippm-ioam-flags has been published as RFC 9322 |
2023-04-28
|
11 | Jim Guichard | Ballot comment text updated for Jim Guichard |
2023-04-28
|
11 | Jim Guichard | [Ballot comment] General comment. There are several typos or grammatical errors in the document. Suggest running an error checker against the document. Section 1: "In-situ … [Ballot comment] General comment. There are several typos or grammatical errors in the document. Suggest running an error checker against the document. Section 1: "In-situ OAM (IOAM)" in the first sentence does not need to be expanded as the authors already did so in the abstract. Section 1: "Service Function Chaining (SFC) [RFC7665]" should read "Service Function Chaining (SFC) Architecture [RFC7665]". Section 3: 6th sentence use of "service path" should probably be changed to the correct terminology used by the SFC architecture which is Service Function Path (SFP). Further, the next sentence should be folded into the 6th sentence as a single sentence to make it more readable. Section 3: "See [I-D.ietf-ippm-ioam-deployment] for a discussion of deployment related aspects of IOAM-Data-fields.". This reference should be changed to [RFC9378]. Section 3: "[I-D.ietf-ippm-ioam-flags]". This reference should be changed to [RFC9322]. Several outdated references need to be updated: == Outdated reference: A later version (-03) exists of draft-ietf-sfc-oam-packet-01 == Outdated reference: draft-ietf-ippm-ioam-deployment has been published as RFC 9378 == Outdated reference: draft-ietf-ippm-ioam-direct-export has been published as RFC 9326 == Outdated reference: draft-ietf-ippm-ioam-flags has been published as RFC 9322 |
2023-04-28
|
11 | Jim Guichard | Ballot comment text updated for Jim Guichard |
2023-04-28
|
11 | Jim Guichard | [Ballot discuss] - Section 3: The IOAM-Data-Fields MUST follow the definitions corresponding to IOAM-Option-Types (e.g., see Section 5 of [RFC9197] and … [Ballot discuss] - Section 3: The IOAM-Data-Fields MUST follow the definitions corresponding to IOAM-Option-Types (e.g., see Section 5 of [RFC9197] and Section 3.2 of [I-D.ietf-ippm-ioam-direct-export]) The above reference to RFC9197 is incorrect although a simple fix. The IOAM-Option-Types are defined in Section 4 of that document not Section 5. Adding a DISCUSS as this reference is important enough to not just be a comment. Note that the same incorrect reference is used later on in Section 3 and must be corrected also. - Section 3: The operator MUST ensure that all nodes along the service path support IOAM. Otherwise packets with IOAM are likely to be dropped per [RFC8300]. This text needs clarification as RFC8300 says nothing about IOAM specifically and dropping of OAM packets is discussed in that RFC here -> https://www.rfc-editor.org/rfc/rfc8300#:~:text=O%20bit%3A%20%20Setting,disabled%20by%20default. The authors should clarify exactly what they mean by the above text and clarify what specifically in RFC8300 would cause packets to be dropped if a node does not support IOAM. - IANA Considerations: The text says "IANA is requested to allocate protocol numbers for the following "NSH Next Protocol" related to IOAM" but there is no reference to the correct registry. NSH Next Protocol allocations can be found here: https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol and they are part of the Network Service Header (NSH) Parameters registry. Please provide an accurate reference to the Network Service Header (NSH) Parameters registry for IANA. - Section 5: Another incorrect reference needs to be corrected. "For additional IOAM related security considerations, see Section 10 in [RFC9197].". It is actually section 9 of that RFC so please correct the reference. |
2023-04-28
|
11 | Jim Guichard | [Ballot comment] General comment. There are several typos or grammatical errors in the document. Suggest running an error checker against the document. - Section 1: … [Ballot comment] General comment. There are several typos or grammatical errors in the document. Suggest running an error checker against the document. - Section 1: "In-situ OAM (IOAM)" in the first sentence does not need to be expanded as the authors already did so in the abstract. - Section 1: "Service Function Chaining (SFC) [RFC7665]" should read "Service Function Chaining (SFC) Architecture [RFC7665]". - Section 3: 6th sentence use of "service path" should probably be changed to the correct terminology used by the SFC architecture which is Service Function Path (SFP). Further, the next sentence should be folded into the 6th sentence as a single sentence to make it more readable. - Section 3: "See [I-D.ietf-ippm-ioam-deployment] for a discussion of deployment related aspects of IOAM-Data-fields.". This reference should be changed to [RFC9378]. - Section 3: "[I-D.ietf-ippm-ioam-flags]". This reference should be changed to [RFC9322]. Several outdated references need to be updated: == Outdated reference: A later version (-03) exists of draft-ietf-sfc-oam-packet-01 == Outdated reference: draft-ietf-ippm-ioam-deployment has been published as RFC 9378 == Outdated reference: draft-ietf-ippm-ioam-direct-export has been published as RFC 9326 == Outdated reference: draft-ietf-ippm-ioam-flags has been published as RFC 9322 |
2023-04-28
|
11 | Jim Guichard | [Ballot Position Update] New position, Discuss, has been recorded for Jim Guichard |
2023-04-27
|
11 | Andrew Alston | Placed on agenda for telechat - 2023-05-04 |
2023-04-27
|
11 | Andrew Alston | Ballot has been issued |
2023-04-27
|
11 | Andrew Alston | [Ballot Position Update] New position, Yes, has been recorded for Andrew Alston |
2023-04-27
|
11 | Andrew Alston | Created "Approve" ballot |
2023-04-27
|
11 | Andrew Alston | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2023-04-27
|
11 | Andrew Alston | Ballot writeup was changed |
2023-04-19
|
11 | Susan Hares | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Susan Hares. Sent review to list. |
2023-04-19
|
11 | Mirja Kühlewind | Request for Last Call review by TSVART Completed: Ready. Reviewer: Mirja Kühlewind. Sent review to list. |
2023-04-17
|
11 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2023-04-17
|
11 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2023-04-17
|
11 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2023-04-13
|
11 | David Dong | IANA Experts State changed to Reviews assigned |
2023-04-13
|
11 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2023-04-13
|
11 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-sfc-ioam-nsh-11. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-sfc-ioam-nsh-11. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the NSH Next Protocol registry on the Network Service Header (NSH) Parameters registry page located at: https://www.iana.org/assignments/nsh/ a single new registration is to be made as follows: Next Protocol: [ TBD-at-Registration ] Description: Reference: [ RFC-to-be ] IANA Question --> What is the description to be used with this registration? TBD_IOAM appears to be a placeholder for a future, edited version of the draft. As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions 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 list of actions 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 Specialist |
2023-04-12
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2023-04-11
|
11 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Mirja Kühlewind |
2023-04-06
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Leif Johansson |
2023-04-06
|
11 | Christer Holmberg | Request for Last Call review by GENART Completed: Ready. Reviewer: Christer Holmberg. Sent review to list. |
2023-04-06
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2023-04-04
|
11 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2023-04-04
|
11 | Amy Vezza | The following Last Call announcement was sent out (ends 2023-04-18): From: The IESG To: IETF-Announce CC: andrew-ietf@liquid.tech, draft-ietf-sfc-ioam-nsh@ietf.org, gregory.mirsky@ericsson.com, sfc-chairs@ietf.org, sfc@ietf.org … The following Last Call announcement was sent out (ends 2023-04-18): From: The IESG To: IETF-Announce CC: andrew-ietf@liquid.tech, draft-ietf-sfc-ioam-nsh@ietf.org, gregory.mirsky@ericsson.com, sfc-chairs@ietf.org, sfc@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data) to Proposed Standard The IESG has received a request from the Service Function Chaining WG (sfc) to consider the following document: - 'Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data' as Proposed Standard 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-04-18. 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 In-situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated with the Network Service Header (NSH). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3527/ |
2023-04-04
|
11 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2023-04-04
|
11 | Andrew Alston | Last call was requested |
2023-04-04
|
11 | Andrew Alston | Last call announcement was generated |
2023-04-04
|
11 | Andrew Alston | Ballot approval text was generated |
2023-04-04
|
11 | Andrew Alston | Ballot writeup was generated |
2023-04-04
|
11 | Andrew Alston | IESG state changed to Last Call Requested from AD Evaluation |
2022-11-06
|
11 | (System) | Changed action holders to Andrew Alston (IESG state changed) |
2022-11-06
|
11 | Andrew Alston | IESG state changed to AD Evaluation from Publication Requested |
2022-09-30
|
11 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-11.txt |
2022-09-30
|
11 | (System) | New version approved |
2022-09-30
|
11 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2022-09-30
|
11 | Frank Brockners | Uploaded new revision |
2022-08-30
|
10 | Mach Chen | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Mach Chen. |
2022-08-17
|
10 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Mach Chen |
2022-08-17
|
10 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Mach Chen |
2022-08-17
|
10 | Andrew Alston | Requested Last Call review by RTGDIR |
2022-07-23
|
10 | Greg Mirsky | # Document Shepherd Writeup *This version is dated 8 July 2022.* ## Document History 1. Does the working group (WG) consensus represent the strong concurrence … # Document Shepherd Writeup *This version is dated 8 July 2022.* ## 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 WG consensus represents the strong concurrence among all active participants of the SFC WG. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There were no controversial points brought up in the course of discussing this document by the SFC WG. 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.) No, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC). 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)? Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH. ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? Notifying the IPPM WG seems like a reasonable step. 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. None of the abovementioned formal reviews is required to progress this document. 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 include the 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. None required. ### 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 is clearly written, easy to read, and based on pragmatic engineering practices. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? I believe that all the listed common issues are reasonably addressed in the latest version of the document. 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/. All authors responded to the IPR inquiry stating that they are not aware of any IPR other than already disclosed. https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. The same statement was made by the following contributors: Vengada Prasad Govindan, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Carlos Pignataro, and David Mozes. Two contributors have not responded: Petr Lapukhov and Remy Chang. Note that the email for Remy Chang is missing. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. All Authors and Contributors agreed to be listed accordingly. 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197. 15. Should any informative references be normative or vice-versa? All references are used appropriately. 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 in the open access. 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. No downrefs in the document. 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state. 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. The publication of this document would not 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][12]). All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries. 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 requested. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-07-20
|
10 | Greg Mirsky | # Document Shepherd Writeup *This version is dated 8 July 2022.* ## Document History 1. Does the working group (WG) consensus represent the strong concurrence … # Document Shepherd Writeup *This version is dated 8 July 2022.* ## 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 WG consensus represents the strong concurrence among all active participants of the SFC WG. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There were no controversial points brought up in the course of discussing this document by the SFC WG. 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.) No, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC). 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)? Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH. ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? Notifying the IPPM WG seems like a reasonable step. 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. None of the abovementioned formal reviews is required to progress this document. 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 include the 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. None required. ### 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 is clearly written, easy to read, and based on pragmatic engineering practices. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? I believe that all the listed common issues are reasonably addressed in the latest version of the document. 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/. All authors responded to the IPR inquiry stating that they are not aware of any IPR other than already disclosed. https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. The same statement was made by the following contributors: Vengada Prasad Govindan, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, and Carlos Pignataro. Several contributors have not responded: David Mozes, Petr Lapukhov, and Remy Chang. Note that the email for Remy Chang is missing. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. All Authors and Contributors agreed to be listed accordingly. 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197. 15. Should any informative references be normative or vice-versa? All references are used appropriately. 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 in the open access. 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. No downrefs in the document. 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state. 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. The publication of this document would not 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][12]). All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries. 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 requested. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-07-08
|
10 | Cindy Morgan | Changed consensus to Yes from Unknown |
2022-07-08
|
10 | Cindy Morgan | Intended Status changed to Proposed Standard from None |
2022-07-08
|
10 | Joel Halpern | # Document Shepherd Writeup *This version is dated 8 July 2022.* ## Document History 1. Does the working group (WG) consensus represent the strong concurrence … # Document Shepherd Writeup *This version is dated 8 July 2022.* ## 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 WG consensus represents the strong concurrence among all active participants of the SFC WG. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There were no controversial points brought up in the course of discussing this document by the SFC WG. 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.) No, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC). 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)? Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH. ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? Notifying the IPPM WG seems like a reasonable step. 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. None of the abovementioned formal reviews is required to progress this document. 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 include the 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. None required. ### 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 is clearly written, easy to read, and based on pragmatic engineering practices. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? I believe that all the listed common issues are reasonably addressed in the latest version of the document. 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/. All authors responded to the IPR inquiry stating that they are not aware of any IPR other than already disclosed. https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. The same statement was made by the following contributors: Vengada Prasad Govindan, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi. Several contributors have not responded: Carlos Pignataro, David Mozes, Petr Lapukhov, and Remy Chang. Note that the email for Remy Chang is missing. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. All Authors and Contributors agreed to be listed accordingly. 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197. 15. Should any informative references be normative or vice-versa? All references are used appropriately. 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 in the open access. 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. No downrefs in the document. 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state. 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. The publication of this document would not 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][12]). All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries. 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 requested. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-07-08
|
10 | Joel Halpern | Responsible AD changed to Andrew Alston |
2022-07-08
|
10 | Joel Halpern | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2022-07-08
|
10 | Joel Halpern | IESG state changed to Publication Requested from I-D Exists |
2022-07-08
|
10 | Joel Halpern | IESG process started in state Publication Requested |
2022-07-08
|
10 | Greg Mirsky | # Document Shepherd Writeup *This version is dated 8 July 2022.* ## Document History 1. Does the working group (WG) consensus represent the strong concurrence … # Document Shepherd Writeup *This version is dated 8 July 2022.* ## 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 WG consensus represents the strong concurrence among all active participants of the SFC WG. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There were no controversial points brought up in the course of discussing this document by the SFC WG. 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.) No, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC). 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)? Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH. ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? Notifying the IPPM WG seems like a reasonable step. 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. None of the abovementioned formal reviews is required to progress this document. 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 include the 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. None required. ### 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 is clearly written, easy to read, and based on pragmatic engineering practices. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? I believe that all the listed common issues are reasonably addressed in the latest version of the document. 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/. All authors responded to the IPR inquiry stating that they are not aware of any IPR other than already disclosed. https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. The same statement was made by the following contributors: Vengada Prasad Govindan, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi. Several contributors have not responded: Carlos Pignataro, David Mozes, Petr Lapukhov, and Remy Chang. Note that the email for Remy Chang is missing. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. All Authors and Contributors agreed to be listed accordingly. 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197. 15. Should any informative references be normative or vice-versa? All references are used appropriately. 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 in the open access. 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. No downrefs in the document. 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state. 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. The publication of this document would not 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][12]). All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries. 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 requested. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-07-05
|
10 | Greg Mirsky | # Document Shepherd Writeup *This version is dated 5 July 2022.* ## Document History 1. Does the working group (WG) consensus represent the strong concurrence … # Document Shepherd Writeup *This version is dated 5 July 2022.* ## 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 WG consensus represents the strong concurrence among all active participants of the SFC WG. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There were no controversial points brought up in the course of discussing this document by the SFC WG. 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.) No, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC). 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)? Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH. ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? Notifying the IPPM WG seems like a reasonable step. 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. None of the abovementioned formal reviews is required to progress this document. 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 include the 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. None required. ### 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 is clearly written, easy to read, and based on pragmatic engineering practices. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? I believe that all the listed common issues are reasonably addressed in the latest version of the document. 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/. Most authors and contributors responded to the IPR inquiry https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. Waiting for replies from Carlos Pignataro, David Mozes, Petr Lapukhov, and Remy Chang. Note that the email for Remy Chang is missing. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. All Authors and Contributors agreed to be listed accordingly. 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197. 15. Should any informative references be normative or vice-versa? All references are used appropriately. 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 in the open access. 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. No downrefs in the document. 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state. 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. The publication of this document would not 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][12]). All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries. 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 requested. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-06-27
|
10 | Joel Halpern | Notification list changed to gregory.mirsky@ericsson.com because the document shepherd was set |
2022-06-27
|
10 | Joel Halpern | Document shepherd changed to Greg Mirsky |
2022-06-27
|
10 | Joel Halpern | The authors will be posting a revision to reflect WG last call comments. |
2022-06-27
|
10 | Joel Halpern | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2022-05-18
|
10 | Shwetha Bhandari | New version available: draft-ietf-sfc-ioam-nsh-10.txt |
2022-05-18
|
10 | Shwetha Bhandari | New version accepted (logged-in submitter: Shwetha Bhandari) |
2022-05-18
|
10 | Shwetha Bhandari | Uploaded new revision |
2022-04-27
|
09 | Shwetha Bhandari | New version available: draft-ietf-sfc-ioam-nsh-09.txt |
2022-04-27
|
09 | Shwetha Bhandari | New version accepted (logged-in submitter: Shwetha Bhandari) |
2022-04-27
|
09 | Shwetha Bhandari | Uploaded new revision |
2022-04-03
|
08 | Shwetha Bhandari | New version available: draft-ietf-sfc-ioam-nsh-08.txt |
2022-04-03
|
08 | (System) | New version approved |
2022-04-03
|
08 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2022-04-03
|
08 | Shwetha Bhandari | Uploaded new revision |
2022-01-31
|
07 | Shwetha Bhandari | New version available: draft-ietf-sfc-ioam-nsh-07.txt |
2022-01-31
|
07 | (System) | New version approved |
2022-01-31
|
07 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2022-01-31
|
07 | Shwetha Bhandari | Uploaded new revision |
2021-08-18
|
06 | Jim Guichard | IETF WG state changed to In WG Last Call from WG Document |
2021-07-31
|
06 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-06.txt |
2021-07-31
|
06 | (System) | New version approved |
2021-07-31
|
06 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2021-07-31
|
06 | Frank Brockners | Uploaded new revision |
2021-06-15
|
05 | (System) | Document has expired |
2020-12-12
|
05 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-05.txt |
2020-12-12
|
05 | (System) | New version approved |
2020-12-12
|
05 | (System) | Request for posting confirmation emailed to previous authors: sfc-chairs@ietf.org, Shwetha Bhandari , Frank Brockners |
2020-12-12
|
05 | Frank Brockners | Uploaded new revision |
2020-06-16
|
04 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-04.txt |
2020-06-16
|
04 | (System) | New version approved |
2020-06-16
|
04 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2020-06-16
|
04 | Frank Brockners | Uploaded new revision |
2020-03-19
|
03 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-03.txt |
2020-03-19
|
03 | (System) | New version approved |
2020-03-19
|
03 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2020-03-19
|
03 | Frank Brockners | Uploaded new revision |
2020-03-14
|
02 | (System) | Document has expired |
2019-09-11
|
02 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-02.txt |
2019-09-11
|
02 | (System) | New version approved |
2019-09-11
|
02 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , sfc-chairs@ietf.org, Vengada Govindan , Tal Mizrahi , John Leddy , Petr Lapukhov , … Request for posting confirmation emailed to previous authors: Frank Brockners , sfc-chairs@ietf.org, Vengada Govindan , Tal Mizrahi , John Leddy , Petr Lapukhov , Carlos Pignataro , Shwetha Bhandari , Hannes Gredler , Stephen Youell , David Mozes , Remy Chang |
2019-09-11
|
02 | Frank Brockners | Uploaded new revision |
2019-05-20
|
Jenny Bui | Posted related IPR disclosure: Juniper's Statement about IPR related to draft-ietf-sfc-ioam-nsh | |
2019-03-27
|
01 | Tal Mizrahi | Added to session: IETF-104: sfc Thu-1610 |
2019-03-11
|
01 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-01.txt |
2019-03-11
|
01 | (System) | New version approved |
2019-03-11
|
01 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , sfc-chairs@ietf.org, Tal Mizrahi , Vengada Govindan , John Leddy , Petr Lapukhov , … Request for posting confirmation emailed to previous authors: Frank Brockners , sfc-chairs@ietf.org, Tal Mizrahi , Vengada Govindan , John Leddy , Petr Lapukhov , Carlos Pignataro , Shwetha Bhandari , Hannes Gredler , Stephen Youell , David Mozes , Remy Chang |
2019-03-11
|
01 | Frank Brockners | Uploaded new revision |
2018-12-02
|
00 | (System) | Document has expired |
2018-11-06
|
00 | Tal Mizrahi | Added to session: IETF-103: sfc Thu-1350 |
2018-07-15
|
00 | Tal Mizrahi | Added to session: IETF-102: sfc Thu-1550 |
2018-05-31
|
00 | (System) | This document now replaces draft-brockners-sfc-ioam-nsh instead of None |
2018-05-31
|
00 | Frank Brockners | New version available: draft-ietf-sfc-ioam-nsh-00.txt |
2018-05-31
|
00 | (System) | New version approved |
2018-05-31
|
00 | Frank Brockners | Request for posting confirmation emailed to submitter and authors: Frank Brockners , Tal Mizrahi , Vengada Govindan , John Leddy , Petr Lapukhov , Carlos … Request for posting confirmation emailed to submitter and authors: Frank Brockners , Tal Mizrahi , Vengada Govindan , John Leddy , Petr Lapukhov , Carlos Pignataro , Shwetha Bhandari , Hannes Gredler , Stephen Youell , David Mozes |
2018-05-31
|
00 | Frank Brockners | Uploaded new revision |