Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers
draft-ietf-sfc-nsh-tlv-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-08-05
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-07-01
|
15 | (System) | RFC Editor state changed to AUTH48 |
2022-06-14
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-05-12
|
15 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-05-11
|
15 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-05-11
|
15 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-05-11
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-05-06
|
15 | (System) | RFC Editor state changed to EDIT |
2022-05-06
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-05-06
|
15 | (System) | Announcement was received by RFC Editor |
2022-05-06
|
15 | (System) | IANA Action state changed to In Progress |
2022-05-06
|
15 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-05-06
|
15 | Cindy Morgan | IESG has approved the document |
2022-05-06
|
15 | Cindy Morgan | Closed "Approve" ballot |
2022-05-06
|
15 | Cindy Morgan | Ballot approval text was generated |
2022-05-06
|
15 | Cindy Morgan | Ballot writeup was changed |
2022-05-05
|
15 | (System) | Removed all action holders (IESG state changed) |
2022-05-05
|
15 | Andrew Alston | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2022-04-26
|
15 | Paul Wouters | [Ballot comment] DISCUSS items from Ben have been addressed in -14 |
2022-04-26
|
15 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss |
2022-04-20
|
15 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-15.txt |
2022-04-20
|
15 | Yuehua Wei | New version accepted (logged-in submitter: Yuehua Wei) |
2022-04-20
|
15 | Yuehua Wei | Uploaded new revision |
2022-04-20
|
14 | Paul Wouters | [Ballot discuss] Setting this ballot as DISCUSS for now, pending the resolving of Ben's DISCUSS items. Donald Eastlake communicated changes that will resolve these, so … [Ballot discuss] Setting this ballot as DISCUSS for now, pending the resolving of Ben's DISCUSS items. Donald Eastlake communicated changes that will resolve these, so waiting on that new ID. |
2022-04-20
|
14 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2022-03-31
|
14 | Francesca Palombini | [Ballot comment] Thank you for the work on this document, and for addressing my previous DISCUSS. Francesca |
2022-03-31
|
14 | Francesca Palombini | [Ballot Position Update] Position for Francesca Palombini has been changed to No Objection from Discuss |
2022-03-30
|
14 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-14.txt |
2022-03-30
|
14 | (System) | New version accepted (logged-in submitter: Yuehua Wei) |
2022-03-30
|
14 | Yuehua Wei | Uploaded new revision |
2022-03-24
|
13 | Andrew Alston | [Ballot Position Update] New position, Yes, has been recorded for Andrew Alston |
2022-03-23
|
13 | Amy Vezza | Changed action holders to Andrew Alston |
2022-03-23
|
13 | Amy Vezza | Shepherding AD changed to Andrew Alston |
2022-02-11
|
13 | Francesca Palombini | [Ballot discuss] Thank you for the work on this document, and for partly addressing my previous DISCUSS. I only have the one point about interoperability … [Ballot discuss] Thank you for the work on this document, and for partly addressing my previous DISCUSS. I only have the one point about interoperability left, which I believe requires some additional clarification in the text. More details below. As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise. Francesca 1. ----- Tenant ID: Represents an opaque value pointing to Orchestration system-generated tenant identifier. The structure and semantics of this field are deployment specific. FP: I am worried about interoperability, as the field is defined as deployment specific. Could you clarify why you don't think this is an issue? Please see the telechat minutes for more details about the discussion and context of this comment: https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt |
2022-02-11
|
13 | Francesca Palombini | Ballot comment and discuss text updated for Francesca Palombini |
2022-01-27
|
13 | Murray Kucherawy | [Ballot comment] Thank you for a well done shepherd writeup. Thanks also for tidying up the IANA Considerations. I support Ben's DISCUSS position, particularly the … [Ballot comment] Thank you for a well done shepherd writeup. Thanks also for tidying up the IANA Considerations. I support Ben's DISCUSS position, particularly the first point. A suggestion on organization: I think what you have as the top of Section 7 should be a subsection (e.g., 7.1), and then the other subsections moved down. It doesn't make sense to me to have these registrations be dominant over the others; they're all just a set of IANA actions. I have the same comment as Francesca about Section 4.1. |
2022-01-27
|
13 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2022-01-26
|
13 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-13.txt |
2022-01-26
|
13 | (System) | New version approved |
2022-01-26
|
13 | (System) | Request for posting confirmation emailed to previous authors: Carlos Pignataro , Donald Eastlake , Sumandra Majee , Uri Elzur , Yuehua Wei , sfc-chairs@ietf.org |
2022-01-26
|
13 | Yuehua Wei | Uploaded new revision |
2022-01-25
|
12 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-12.txt |
2022-01-25
|
12 | (System) | New version approved |
2022-01-25
|
12 | (System) | Request for posting confirmation emailed to previous authors: Carlos Pignataro , Donald Eastlake , Sumandra Majee , Uri Elzur , Yuehua Wei , sfc-chairs@ietf.org |
2022-01-25
|
12 | Yuehua Wei | Uploaded new revision |
2022-01-12
|
11 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-11.txt |
2022-01-12
|
11 | (System) | New version approved |
2022-01-12
|
11 | (System) | Request for posting confirmation emailed to previous authors: Carlos Pignataro , Donald Eastlake , Sumandra Majee , Uri Elzur , Yuehua Wei , sfc-chairs@ietf.org |
2022-01-12
|
11 | Yuehua Wei | Uploaded new revision |
2022-01-11
|
10 | John Scudder | [Ballot comment] Thanks for the updates! --- Previous DISCUSS: 1. I notice that in his RTGDIR review of version 08 [*], Stig Venaas suggested some … [Ballot comment] Thanks for the updates! --- Previous DISCUSS: 1. I notice that in his RTGDIR review of version 08 [*], Stig Venaas suggested some improvements to the security considerations section. This was subsequently discussed and Yuehua Wei proposed some new text [**] for version 09. That text isn’t present, and I don’t see any further resolution on the mailing list either. I’d appreciate it if the topic were closed by either adding the proposed text, or some other text to resolve Stig’s concern, or explanation of why no change was made. [*] https://datatracker.ietf.org/doc/review-ietf-sfc-nsh-tlv-08-rtgdir-lc-venaas-2021-09-29/ [**] https://mailarchive.ietf.org/arch/msg/sfc/Q2Snf_ZLTkJ1augbaWpmNYlwFBU/ 2. In §8.2, the two first references, [GROUPBASEDPOLICY] and [GROUPPOLICY] are deficient. At a minimum, a reference should provide enough information to allow a reader to straightforwardly determine how to retrieve it. This is true even if it’s not an openly-available online source. These two references have less than the bare bones, I don’t know how to find them or refer to them. --- Previous comments: 1. I support all of Ben’s discuss points. I also want to reiterate his comment about the desirability of having useful captions on the figures. 2. In §4.2, you write, This context header carries both the format and value of the Tenant identifier. However, I don’t see anywhere that the header “carries… the format”. Indeed, you write that the Tenant ID is an opaque value. As far as I can tell, there’s no way to infer anything about its structure without a priori knowledge. If that is correct, you can simplify the sentence to “This context header carries the Tenant Identifier.” If it’s not correct, please explain? 3. Nit, in §4.7 the words “quite efficiently” don’t seem to serve any useful purpose; the document would be better off without them IMO. |
2022-01-11
|
10 | John Scudder | [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss |
2021-12-03
|
10 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-12-03
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-12-03
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-12-03
|
10 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-10.txt |
2021-12-03
|
10 | (System) | New version approved |
2021-12-03
|
10 | (System) | Request for posting confirmation emailed to previous authors: Carlos Pignataro , Donald Eastlake , Sumandra Majee , Uri Elzur , Yuehua Wei , sfc-chairs@ietf.org |
2021-12-03
|
10 | Yuehua Wei | Uploaded new revision |
2021-12-02
|
09 | (System) | Changed action holders to Uri Elzur, Donald Eastlake, Carlos Pignataro, Martin Vigoureux, Sumandra Majee, Yuehua Wei (IESG state changed) |
2021-12-02
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2021-12-01
|
09 | Murray Kucherawy | [Ballot discuss] I'm having trouble understanding the first thing you've got in Section 7. You have one table of assignments to make, but you're referencing … [Ballot discuss] I'm having trouble understanding the first thing you've got in Section 7. You have one table of assignments to make, but you're referencing two distinct sub-registries under "Network Service Header (NSH) Parameters", namely "NSH MD Class" and "NSH IETF-Assigned Optional Variable-Length Metadata Types". There doesn't appear to be a "metadata context type registry". I think this change clarifies what you mean, but please tell me if I'm wrong: OLD: IANA is requested to assign the following types from the "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000 IETF Base NSH MD Class) registry available at [IANA-NSH-MD2]: This document defines the following new values (Table 1) in the Network Service Header (NSH) metadata context Type registry: NEW: IANA is requested to assign the following types (Table 1) from the IETF Review range in the "NSH MD Class" sub-registry of the "Network Service Header (NSH) Parameters" registry: |
2021-12-01
|
09 | Murray Kucherawy | [Ballot comment] Thank you for a well done shepherd writeup. I support Ben's DISCUSS position, particularly the first point. A suggestion on organization: I think … [Ballot comment] Thank you for a well done shepherd writeup. I support Ben's DISCUSS position, particularly the first point. A suggestion on organization: I think what you have as the top of Section 7 should be a subsection (e.g., 7.1), and then the other subsections moved down. It doesn't make sense to me to have these registrations be dominant over the others; they're all just a set of IANA actions. I have the same comment as Francesca about Section 4.1. |
2021-12-01
|
09 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2021-12-01
|
09 | Francesca Palombini | [Ballot discuss] Thank you for the work on this document. I have some comments, mostly having to do with clarifications and improvement of text for … [Ballot discuss] Thank you for the work on this document. I have some comments, mostly having to do with clarifications and improvement of text for readability. I'd like answers to two main points: first - I believe the lack of normative references to the documents that define the fields this document registers into IANA is important enough to warrant some discussion. Second - I'd like some clarification about interoperability. More details below. As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise. Francesca 1. ----- Tenant ID: Represents an opaque value pointing to Orchestration system-generated tenant identifier. The structure and semantics of this field are deployment specific. FP: I am worried about interoperability, as the field is defined as deployment specific. Could you clarify why you don't think this is an issue? Also, please add a normative reference to the section and document defining tenant identification. 2. ---- Section 4.3 FP: Same comment as above for Node ID: please add a reference and explain interoperability, as this is defined as deployment specific. 3. ----- Sections 4.4, 4.5 FP: I do think these fields need references to the documents they are defined in. (I am aware section 2.1 and the normative references should help, but I think it would be much clearer to have direct links to the right place in the text.) For Flow ID, if I understand correctly, this document defines it high level and gives examples of what value it can take. I would clarify that in the first paragraph of the section (as you do for Section 4.6), instead of having the references only in the "Length" paragraph. |
2021-12-01
|
09 | Francesca Palombini | Ballot discuss text updated for Francesca Palombini |
2021-12-01
|
09 | Warren Kumari | [Ballot comment] I had started writing this as a DISCUSS position, mainly about the lack of Security Considerations and lack of context / detail around … [Ballot comment] I had started writing this as a DISCUSS position, mainly about the lack of Security Considerations and lack of context / detail around fields, but changed to NoObj because the SecADs are already holding the DISCUESSes, and the fields *can* be figured out with sufficient effort. For future documents, it would be really helpful to have some more information / detail. As an example: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class = 0x0000 | Type = TBA4 |U| Length = var| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Source Interface ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Ingress Network Source Interface The fields are described as follows: Length: Indicates the length of the Source Interface in bytes (see Section 2.5.1 of [RFC8300]). Source Interface: Identifier of the ingress interface of the ingress network node." Erm, what format is the Source Interface in? Is "XE-0/0/0.23" an option? What do I *do* with this?! Only after rereading the section multiple times and then hunting down some other SFC documents did I notice the text above the document which says: "This is an opaque quantity to the NSH." -- Ok, fair enough (yes, I'm dumb for not having noticed that in the intro, but this is just an example of a common thread in the document) A "good" example is: "Node ID: Represents an opaque value of the ingress network node ID. The structure and semantics of this field are deployment specific. For example, Node ID may be a 4 bytes IPv4 address Node ID, or a 16 bytes IPv6 address Node ID, or a 6 bytes MAC address, or 8 bytes MAC address (EUI-64), etc,." -- this explains what goes in the field, and a helpful example to situate the reader. |
2021-12-01
|
09 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-12-01
|
09 | John Scudder | [Ballot discuss] 1. I notice that in his RTGDIR review of version 08 [*], Stig Venaas suggested some improvements to the security considerations section. This … [Ballot discuss] 1. I notice that in his RTGDIR review of version 08 [*], Stig Venaas suggested some improvements to the security considerations section. This was subsequently discussed and Yuehua Wei proposed some new text [**] for version 09. That text isn’t present, and I don’t see any further resolution on the mailing list either. I’d appreciate it if the topic were closed by either adding the proposed text, or some other text to resolve Stig’s concern, or explanation of why no change was made. [*] https://datatracker.ietf.org/doc/review-ietf-sfc-nsh-tlv-08-rtgdir-lc-venaas-2021-09-29/ [**] https://mailarchive.ietf.org/arch/msg/sfc/Q2Snf_ZLTkJ1augbaWpmNYlwFBU/ 2. In §8.2, the two first references, [GROUPBASEDPOLICY] and [GROUPPOLICY] are deficient. At a minimum, a reference should provide enough information to allow a reader to straightforwardly determine how to retrieve it. This is true even if it’s not an openly-available online source. These two references have less than the bare bones, I don’t know how to find them or refer to them. |
2021-12-01
|
09 | John Scudder | [Ballot comment] 1. I support all of Ben’s discuss points. I also want to reiterate his comment about the desirability of having useful captions on … [Ballot comment] 1. I support all of Ben’s discuss points. I also want to reiterate his comment about the desirability of having useful captions on the figures. 2. In §4.2, you write, This context header carries both the format and value of the Tenant identifier. However, I don’t see anywhere that the header “carries… the format”. Indeed, you write that the Tenant ID is an opaque value. As far as I can tell, there’s no way to infer anything about its structure without a priori knowledge. If that is correct, you can simplify the sentence to “This context header carries the Tenant Identifier.” If it’s not correct, please explain? 3. Nit, in §4.7 the words “quite efficiently” don’t seem to serve any useful purpose; the document would be better off without them IMO. |
2021-12-01
|
09 | John Scudder | [Ballot Position Update] New position, Discuss, has been recorded for John Scudder |
2021-12-01
|
09 | Robert Wilton | [Ballot comment] I support Ben's discuss for clarifying the length and padding for the flow id in section 4.5. In particular, I note that the … [Ballot comment] I support Ben's discuss for clarifying the length and padding for the flow id in section 4.5. In particular, I note that the diagram suggests that the size is fixed at 4 bytes, but the text suggests that the length is variable. |
2021-12-01
|
09 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-12-01
|
09 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2021-11-30
|
09 | Roman Danyliw | [Ballot comment] I strongly support Ben Kaduk’s DISCUSS position. To repeat (Ben’s first point), the privacy and security implications of each of these new meta-data … [Ballot comment] I strongly support Ben Kaduk’s DISCUSS position. To repeat (Ben’s first point), the privacy and security implications of each of these new meta-data items defined in Section 4 needs to be evaluated and documented. Thanks to Charlie Kaufman for the SECDIR review. ** Section 1. Typo. s/serveral/several/ ** Section 4.1 References needed for certain the CT values. -- 0x0, Shouldn’t this also reference [IEEE.802.1Q_2018] (just like with 0x1)? -- 0x2 and 0x3 is there a reference for MPLS VPN and VNI? ** Section 4.5. Editorial. Multiple Instances of s/Dest Group/Destination Group/ |
2021-11-30
|
09 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-11-29
|
09 | Benjamin Kaduk | [Ballot discuss] (1) RFC 8300 is pretty clear that "Metadata privacy and security considerations are a matter for the documents that define metadata format." Some … [Ballot discuss] (1) RFC 8300 is pretty clear that "Metadata privacy and security considerations are a matter for the documents that define metadata format." Some of the metadata context headers defined in this document clearly have privacy considerations that need to be documented (e.g., policy ID and source/destination group serve to concretely identify flows that are related in some way), though some may not have much that needs documenting (e.g., the forwarding context metadata seems to just be extracting out information that is already present in the packet being wrapped). Regardless, we need to have some discussion of the privacy and security considerations of the new metadata context headers, even if that is just "no new considerations" for some of them. (2) I think we need to discuss the Flow ID context header further. Is it intended to just be a container to hold a flow identifier already present in the contained packet (such as the IPv6 Flow Label or MPLS Entropy Label that are called out), or can it also be used to apply a new flow identifier at the SFC layer? The named examples of a flow ID are both 20 bits long; if that is an exhaustive listing, shouldn't we update the figure accordingly (to include Length=3, four leading bits of padding, and a trailing byte of padding)? If that is not an exhaustive listing and longer flow identifiers are expected, how do we know what length of flow identifier is being conveyed? (3) If we are to allow for specifying the "logical grouping of source and/or destination objects" in §4.6 (emphasis on "and/or"), but the context header always conveys both a source group and dest group field, do we need to reserve a dedicated value for "no group information specified"? |
2021-11-29
|
09 | Benjamin Kaduk | [Ballot comment] Section 1 This document does not address metadata usage, updating/chaining of metadata, or other SFP functions. Those topics are described in … [Ballot comment] Section 1 This document does not address metadata usage, updating/chaining of metadata, or other SFP functions. Those topics are described in [RFC8300]. I'm not entirely sure what is meant by "chaining of metadata" (unless it's just a synonym for "updating of metadata"?), and having reviewed all 18 instances of "chain" and 88 instances of "metadata" in RFC 8300, I am not sure which part you're intending to refer to by it. Could you please point to a more specific part of RFC 8300 (at least in this email thread for now, not necessarily in a document update)? Section 4.1 I suggest putting a context (forgive the pun) indicator in the figure legends, e.g., "Figure 4: Forwarding Context - 2 (QinQ)". The information is already available elsewhere, but having it in the caption helps focus the reader on the important/relevant part of the figure. Section 4.3 It might be interesting to say something about when the SPI itself suffices to identify the ingress node vs. when this metadata context header is needed. Node ID: Represents an opaque value of the ingress network node ID. The structure and semantics of this field are deployment specific. For example, Node ID may be a 4 bytes IPv4 address Node ID, or a 16 bytes IPv6 address Node ID, or a 6 bytes MAC address, or 8 bytes MAC address (EUI-64), etc,. There seems to be some dissonance between saying this field is "an opaque value" and also saying that it might be an IP or MAC address. In the vein of Francesca's Discuss point, I don't think we can have interoperability if the NSH implementation is expected to process this as IP/MAC address information (as opposed to just an opaque identifier). Section 8.2 URLs for [GROUPBASEDPOLICY] and [GROUPPOLICY] would be helpful. |
2021-11-29
|
09 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2021-11-29
|
09 | Lars Eggert | [Ballot comment] Thanks to Roni Even for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/_Ko2OFHveBlBtmwVVHVjz1hewZo). ------------------------------------------------------------------------------- All comments below are about very minor … [Ballot comment] Thanks to Roni Even for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/_Ko2OFHveBlBtmwVVHVjz1hewZo). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 4.2. , paragraph 3, nit: > , or 8 bytes MAC address (EUI-64), etc,. > ^^ Did you just mean "," or "."? These URLs in the document can probably be converted to HTTPS: * http://ieeexplore.ieee.org/servlet/opac?punumber=8403925 |
2021-11-29
|
09 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-11-29
|
09 | Francesca Palombini | [Ballot discuss] Thank you for the work on this document. I have some comments, mostly having to do with clarifications and improvement of text for … [Ballot discuss] Thank you for the work on this document. I have some comments, mostly having to do with clarifications and improvement of text for readability. I'd like answers to two main points: first - I believe the lack of normative references to the documents that define the fields this document registers into IANA is important enough to warrant some discussion. Second - I'd like some clarification about interoperability. More details below. Francesca 1. ----- Tenant ID: Represents an opaque value pointing to Orchestration system-generated tenant identifier. The structure and semantics of this field are deployment specific. FP: I am worried about interoperability, as the field is defined as deployment specific. Could you clarify why you don't think this is an issue? Also, please add a normative reference to the section and document defining tenant identification. 2. ---- Section 4.3 FP: Same comment as above for Node ID: please add a reference and explain interoperability, as this is defined as deployment specific. 3. ----- Sections 4.4, 4.5 FP: I do think these fields need references to the documents they are defined in. (I am aware section 2.1 and the normative references should help, but I think it would be much clearer to have direct links to the right place in the text.) For Flow ID, if I understand correctly, this document defines it high level and gives examples of what value it can take. I would clarify that in the first paragraph of the section (as you do for Section 4.6), instead of having the references only in the "Length" paragraph. |
2021-11-29
|
09 | Francesca Palombini | [Ballot comment] 4. ----- Section 4.1 FP: I think it would be better to have the sentence "Reserved bits MUST be sent as zero and … [Ballot comment] 4. ----- Section 4.1 FP: I think it would be better to have the sentence "Reserved bits MUST be sent as zero and ignored on receipt." only once, rather than repeat for each context. What is missing instead is the number of bits that are reserved for each CT. I know that it can be extracted from the figure or from the value of the Forwarding Context field, but I believe figures should be complemented by clear written text. Additionally, to improve readability, references should be added for the forwarding context where they are missing: VLAN identifier, MPLS VPN label‚ VNI. |
2021-11-29
|
09 | Francesca Palombini | [Ballot Position Update] New position, Discuss, has been recorded for Francesca Palombini |
2021-11-18
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-11-16
|
09 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking minor COMMENT points (but replies would be appreciated even … [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking minor 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 write-up about the WG consensus. Thank you also to Bob Halley for the positive review for the Internet directorate: https://datatracker.ietf.org/doc/review-ietf-sfc-nsh-tlv-09-intdir-telechat-halley-2021-11-09/ I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 4.3 and 4.4 -- Suggestion be consistent about where the 'opaque' tag is used, i.e., in the preamble in §4.4 and in the Node ID description in §4.3. -- Section 4.5 -- The IPv6 Flow Label header field length/type are described in RFC 8200 and not in RFC 6437. == NITS == Some glaring typos s/serveral/several/, please use a spell checker ;-) Sometimes 'octet' is used but 'byte' is also used, I would prefer to be consistent and use only 'octet' but this is very cosmetic. |
2021-11-16
|
09 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2021-11-09
|
09 | Bob Halley | Request for Telechat review by INTDIR Completed: Ready. Reviewer: Bob Halley. Sent review to list. |
2021-11-09
|
09 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Bob Halley |
2021-11-09
|
09 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Bob Halley |
2021-11-09
|
09 | Éric Vyncke | Requested Telechat review by INTDIR |
2021-11-01
|
09 | Cindy Morgan | Placed on agenda for telechat - 2021-12-02 |
2021-10-31
|
09 | Martin Vigoureux | Ballot has been issued |
2021-10-31
|
09 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2021-10-31
|
09 | Martin Vigoureux | Created "Approve" ballot |
2021-10-31
|
09 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2021-10-31
|
09 | Martin Vigoureux | Ballot writeup was changed |
2021-10-11
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-10-11
|
09 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-09.txt |
2021-10-11
|
09 | (System) | New version accepted (logged-in submitter: Yuehua Wei) |
2021-10-11
|
09 | Yuehua Wei | Uploaded new revision |
2021-10-08
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Charlie Kaufman. Submission of review completed at an earlier date. |
2021-09-30
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Charlie Kaufman. |
2021-09-29
|
08 | Stig Venaas | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Stig Venaas. Sent review to list. |
2021-09-28
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-09-25
|
08 | Scott Bradner | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Scott Bradner. Sent review to list. |
2021-09-24
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2021-09-24
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-sfc-nsh-tlv-08. 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-nsh-tlv-08. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the NSH IETF-Assigned Optional Variable-Length Metadata Types on the Network Service Header (NSH) Parameters registry page located at: https://www.iana.org/assignments/nsh/ seven new values are to be registered as follows: Value: [ TBD-at-Registration ] Description: Forwarding Context Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: Tenant Identifier Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: Ingress Network NodeID Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: Ingress Network Interface Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: Flow ID Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: Source and/or Destination Groups Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: Policy Identifier Reference: [ RFC-to-be ] Second, a new registry is to be created called the Forwarding Context Types registry. The new registry will be created on the Network Service Header (NSH) Parameters registry page located at: https://www.iana.org/assignments/nsh/ The registration policy for the new registry is IETF Review as defined in RFC8126. There are initial registrations in the new registry as follows: +---------+-----------------------------------------+---------------+ | Value | Forwarding Context Header Types | Reference | +---------+-----------------------------------------+---------------+ | 0x0 | 12-bit VLAN identifier | This document | | 0x1 | 24-bit double tagging identifiers | This document | | 0x2 | 20-bit MPLS VPN label | This document | | 0x3 | 24-bit virtual network identifier (VNI) | This document | | 0x4 | 32-bit Session ID | This document | | 0x5-0xE | Unassigned | IETF Review | | 0xF | Reserved | This document | +---------+-----------------------------------------+---------------+ The IANA Functions Operator understands that these are the only actions 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. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2021-09-23
|
08 | Roni Even | Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list. |
2021-09-22
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2021-09-22
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2021-09-17
|
08 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Stig Venaas |
2021-09-17
|
08 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Stig Venaas |
2021-09-16
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2021-09-16
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2021-09-16
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
2021-09-16
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
2021-09-14
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2021-09-14
|
08 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-09-28): From: The IESG To: IETF-Announce CC: draft-ietf-sfc-nsh-tlv@ietf.org, gregimirsky@gmail.com, martin.vigoureux@nokia.com, sfc-chairs@ietf.org, sfc@ietf.org … The following Last Call announcement was sent out (ends 2021-09-28): From: The IESG To: IETF-Announce CC: draft-ietf-sfc-nsh-tlv@ietf.org, gregimirsky@gmail.com, martin.vigoureux@nokia.com, sfc-chairs@ietf.org, sfc@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Network Service Header Metadata Type 2 Variable-Length Context Headers) to Proposed Standard The IESG has received a request from the Service Function Chaining WG (sfc) to consider the following document: - 'Network Service Header Metadata Type 2 Variable-Length Context Headers' 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 2021-09-28. 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 Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context Metadata (MD) with each packet. Such Metadata can be of various Types including MD Type 2 variable length context headers. This document specifies several such context headers that can be used within a service function path. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ No IPR declarations have been submitted directly on this I-D. |
2021-09-14
|
08 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-09-14
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested::Revised I-D Needed |
2021-09-14
|
08 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2021-09-14
|
08 | Martin Vigoureux | Last call announcement was generated |
2021-09-14
|
08 | Martin Vigoureux | Last call announcement was generated |
2021-09-14
|
08 | Martin Vigoureux | Last call was requested |
2021-09-14
|
08 | Martin Vigoureux | Last call announcement was generated |
2021-09-14
|
08 | Martin Vigoureux | Ballot approval text was generated |
2021-09-14
|
08 | Martin Vigoureux | Ballot writeup was generated |
2021-09-14
|
08 | (System) | Changed action holders to Uri Elzur, Donald Eastlake, Carlos Pignataro, Martin Vigoureux, Sumandra Majee, Yuehua Wei (IESG state changed) |
2021-09-14
|
08 | Martin Vigoureux | IESG state changed to Last Call Requested::Revised I-D Needed from AD Evaluation |
2021-09-14
|
08 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-09-14
|
08 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2021-09-02
|
08 | Joel Halpern | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document is on the Standard track. The document defines several metadata type 2 variable-length optional context headers for the Network Service Header SFC encapsulation. Based on the scope of the document, the Standard track is the most appropriate. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Service Function Chaining (SFC) uses the Network Service Header, defined in RFC 8300, to steer and provide context Metadata with each packet. Such Metadata can be of various types including MD Type 2 variable-length optional context headers. The document specifies several such context headers, e.g., Forwarding Context, Flow ID, that can be used within a service function path. Working Group Summary: The document received a good amount of comments from the WG community. Resulting from the WG discussion, some of the originally proposed context headers were taken out for consideration in the future. Document Quality: The document is well-written and is easy to read. All technical aspects received a thorough review from the WG. Several vendor companies indicated their plans to implement MD Type 2 context headers defined in this specification. Personnel: Greg Mirsky is the Document Shepherd. Martin Vigoureux is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. As the Document Shepherd, I've reviewed the document and shared my comments (https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=_S9emNJV_ts58bJrcKZWkWPVeRc). All the comments have been properly addressed. The document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concerns about the reviews and discussions the documennt received from the WG. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Though the SFC WG always welcomes additional input, particularly from the Security Area experts, the security aspects for this document are addressed using methods described in draft-ietf-sfc-nsh-integrity that, at the time of writing this Shepherd review, is in IESG Review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no outstanding, unaddressed comments or concerns about the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? All authors responded to the IPR poll to the SFC WG mailing list https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=fu7hEqUljp-h1X3LNzjWhZNnZLU (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures has been filed in relation to this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document received a strong support from active members of the SFC WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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 opposing opinions were expressed, no one objected to progressing this specification to the publication. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. In my review, several editorial nits were found and thoroughly addressed by the Editor. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? All references, normative and informative, are used appropriately, based on the importance of their information to this document. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? The document uses draft-ietf-sfc-nsh-integrity, which is in ISEG review, as the normative reference. It is likely that draft-ietf-sfc-nsh-integrity will be published well before this document. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. IDNits reports that the normative reference to the IANA "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry is a potential downref. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, the publication of this document would not change the status of any already published RFC. (17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). I've found minor editorial nits in the IANA Considerations section. All my comments have been addressed. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There is no request to create a new IANA registry that requires the Expert Review in this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. IDNits, Grammarly (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342? N/A |
2021-09-02
|
08 | Joel Halpern | Responsible AD changed to Martin Vigoureux |
2021-09-02
|
08 | Joel Halpern | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-09-02
|
08 | Joel Halpern | IESG state changed to Publication Requested from I-D Exists |
2021-09-02
|
08 | Joel Halpern | IESG process started in state Publication Requested |
2021-09-02
|
08 | Joel Halpern | Tag Doc Shepherd Follow-up Underway cleared. |
2021-09-01
|
08 | Greg Mirsky | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document is on the Standard track. The document defines several metadata type 2 variable-length optional context headers for the Network Service Header SFC encapsulation. Based on the scope of the document, the Standard track is the most appropriate. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Service Function Chaining (SFC) uses the Network Service Header, defined in RFC 8300, to steer and provide context Metadata with each packet. Such Metadata can be of various types including MD Type 2 variable-length optional context headers. The document specifies several such context headers, e.g., Forwarding Context, Flow ID, that can be used within a service function path. Working Group Summary: The document received a good amount of comments from the WG community. Resulting from the WG discussion, some of the originally proposed context headers were taken out for consideration in the future. Document Quality: The document is well-written and is easy to read. All technical aspects received a thorough review from the WG. Several vendor companies indicated their plans to implement MD Type 2 context headers defined in this specification. Personnel: Greg Mirsky is the Document Shepherd. Martin Vigoureux is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. As the Document Shepherd, I've reviewed the document and shared my comments (https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=_S9emNJV_ts58bJrcKZWkWPVeRc). All the comments have been properly addressed. The document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concerns about the reviews and discussions the documennt received from the WG. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Though the SFC WG always welcomes additional input, particularly from the Security Area experts, the security aspects for this document are addressed using methods described in draft-ietf-sfc-nsh-integrity that, at the time of writing this Shepherd review, is in IESG Review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no outstanding, unaddressed comments or concerns about the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? All authors responded to the IPR poll to the SFC WG mailing list https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=fu7hEqUljp-h1X3LNzjWhZNnZLU (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures has been filed in relation to this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document received a strong support from active members of the SFC WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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 opposing opinions were expressed, no one objected to progressing this specification to the publication. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. In my review, several editorial nits were found and thoroughly addressed by the Editor. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? All references, normative and informative, are used appropriately, based on the importance of their information to this document. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? The document uses draft-ietf-sfc-nsh-integrity, which is in ISEG review, as the normative reference. It is likely that draft-ietf-sfc-nsh-integrity will be published well before this document. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. IDNits reports that the normative reference to the IANA "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry is a potential downref. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, the publication of this document would not change the status of any already published RFC. (17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). I've found minor editorial nits in the IANA Considerations section. All my comments have been addressed. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There is no request to create a new IANA registry that requires the Expert Review in this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. IDNits, Grammarly (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342? N/A |
2021-09-01
|
08 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-08.txt |
2021-09-01
|
08 | (System) | New version accepted (logged-in submitter: Yuehua Wei) |
2021-09-01
|
08 | Yuehua Wei | Uploaded new revision |
2021-08-25
|
07 | Greg Mirsky | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document is on the Standard track. The document defines several metadata type 2 variable-length optional context headers for the Network Service Header SFC encapsulation. Based on the scope of the document, the Standard track is the most appropriate. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Service Function Chaining (SFC) uses the Network Service Header, defined in RFC 8300, to steer and provide context Metadata with each packet. Such Metadata can be of various types including MD Type 2 variable-length optional context headers. The document specifies several such context headers, e.g., Forwarding Context, Flow ID, that can be used within a service function path. Working Group Summary: The document received a good amount of comments from the WG community. Resulting from the WG discussion, some of the originally proposed context headers were taken out for consideration in the future. Document Quality: The document is well-written and is easy to read. All technical aspects received a thorough review from the WG. Several vendor companies indicated their plans to implement MD Type 2 context headers defined in this specification. Personnel: Greg Mirsky is the Document Shepherd. Martin Vigoureux is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. As the Document Shepherd, I've reviewed the document and shared my comments (https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=_S9emNJV_ts58bJrcKZWkWPVeRc). All the comments have been properly addressed. The document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concerns about the reviews and discussions the documennt received from the WG. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Though the SFC WG always welcomes additional input, particularly from the Security Area experts, the security aspects for this document are addressed using methods described in draft-ietf-sfc-nsh-integrity that, at the time of writing this Shepherd review, is in IESG Review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no outstanding, unaddressed comments or concerns about the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? All authors responded to the IPR poll to the SFC WG mailing list https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=fu7hEqUljp-h1X3LNzjWhZNnZLU (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures has been filed in relation to this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document received a strong support from active members of the SFC WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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 opposing opinions were expressed, no one objected to progressing this specification to the publication. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. In my review, several editorial nits were found and thoroughly addressed by the Editor. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? All references, normative and informative, are used appropriately, based on the importance of their information to this document. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? The document uses draft-ietf-sfc-nsh-integrity, which is in ISEG review, as the normative reference. It is likely that draft-ietf-sfc-nsh-integrity will be published well before this document. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. IDNits reports that the normative reference to the IANA "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry is a potential downref. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, the publication of this document would not change the status of any already published RFC. (17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). I've found minor editorial nits in the IANA Considerations section. All my comments have been addressed. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There is no request to create a new IANA registry that requires the Expert Review in this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. IDNits, Grammarly (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342? N/A |
2021-07-26
|
07 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-07.txt |
2021-07-26
|
07 | (System) | New version approved |
2021-07-26
|
07 | (System) | Request for posting confirmation emailed to previous authors: Carlos Pignataro , Sumandra Majee , Uri Elzur , Yuehua Wei , sfc-chairs@ietf.org |
2021-07-26
|
07 | Yuehua Wei | Uploaded new revision |
2021-07-09
|
06 | Greg Mirsky | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document is on the Standard track. The document defines several metadata type 2 variable-length context headers for the Network Service Header SFC encapsulation. Based on the scope of the document, the Standard track is the most appropriate. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Service Function Chaining (SFC) uses the Network Service Header, defined in RFC 8300, to steer and provide context Metadata with each packet. Such Metadata can be of various types including MD Type 2 variable-length context headers. The document specifies several such context headers, e.g., Forwarding Context, Flow ID, that can be used within a service function path. Working Group Summary: The document received a good amount of comments from the WG community. Resulting from the WG discussion, some of the originally proposed context headers were taken out for consideration in the future. Document Quality: The document is well-written and is easy to read. All technical aspects received a thorough review from the WG. Several vendor companies indicated their plans to implement MD Type 2 context headers defined in this specification. Personnel: Greg Mirsky is the Document Shepherd. Martin Vigoureux is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. As the Document Shepherd, (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concerns about the reviews and discussions the documennt received from the WG. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Though the SFC WG always welcomes additional input, particularly from the Security Area experts, the security aspects for this document are addressed using methods described in draft-ietf-sfc-nsh-integrity that, at the time of writing this Shepherd review, is in IESG Review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no outstanding, unaddressed comments or concerns about the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? All authors responded to the IPR poll to the SFC WG mailing list https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=fu7hEqUljp-h1X3LNzjWhZNnZLU (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures has been filed in relation to this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document received a strong support from active members of the SFC WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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 opposing opinions were expressed, no one objected to progressing this specification to the publication. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. In my review, several editorial nits were found and thoroughly addressed by the Editor. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? All references, normative and informative, are used appropriately, based on the importance of their information to this document. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? The document uses draft-ietf-sfc-nsh-integrity, which is in ISEG review, as the normative reference. It is likely that draft-ietf-sfc-nsh-integrity will be published well before this document. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. IDNits reports that the normative reference to the IANA "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry is a potential downref. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, the publication of this document would not change the status of any already published RFC. (17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). I've found minor editorial nits in the IANA Considerations section. All my comments have been addressed. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There is no request to create a new IANA registry that requires the Expert Review in this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. IDNits, Grammarly (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342? N/A |
2021-06-01
|
06 | Joel Halpern | Tag Doc Shepherd Follow-up Underway set. |
2021-06-01
|
06 | Joel Halpern | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-06-01
|
06 | Joel Halpern | Changed consensus to Yes from Unknown |
2021-06-01
|
06 | Joel Halpern | Intended Status changed to Proposed Standard from None |
2021-06-01
|
06 | Joel Halpern | Notification list changed to gregimirsky@gmail.com because the document shepherd was set |
2021-06-01
|
06 | Joel Halpern | Document shepherd changed to Greg Mirsky |
2021-05-12
|
06 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-06.txt |
2021-05-12
|
06 | (System) | New version approved |
2021-05-12
|
06 | (System) | Request for posting confirmation emailed to previous authors: Carlos Pignataro , Sumandra Majee , Uri Elzur , Yuehua Wei , sfc-chairs@ietf.org |
2021-05-12
|
06 | Yuehua Wei | Uploaded new revision |
2021-04-01
|
05 | Joel Halpern | This starts a two week last call for this document. Please speak up. We need to see support for sending this to the IESG. Silence … This starts a two week last call for this document. Please speak up. We need to see support for sending this to the IESG. Silence is not consent. The last call will end at the end of 16-April-2021. Thank you, Joel (and Jim) |
2021-04-01
|
05 | Joel Halpern | IETF WG state changed to In WG Last Call from WG Document |
2021-04-01
|
05 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-05.txt |
2021-04-01
|
05 | (System) | New version approved |
2021-04-01
|
05 | (System) | Request for posting confirmation emailed to previous authors: Carlos Pignataro , Sumandra Majee , Uri Elzur , Yuehua Wei , sfc-chairs@ietf.org |
2021-04-01
|
05 | Yuehua Wei | Uploaded new revision |
2021-01-04
|
04 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-04.txt |
2021-01-04
|
04 | (System) | New version approved |
2021-01-04
|
04 | (System) | Request for posting confirmation emailed to previous authors: Sumandra Majee , Uri Elzur , Yuehua Wei , sfc-chairs@ietf.org |
2021-01-04
|
04 | Yuehua Wei | Uploaded new revision |
2020-11-21
|
03 | (System) | Document has expired |
2020-05-20
|
03 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-03.txt |
2020-05-20
|
03 | (System) | New version approved |
2020-05-20
|
03 | (System) | Request for posting confirmation emailed to previous authors: Uri Elzur , sfc-chairs@ietf.org, Yuehua Wei , Sumandra Majee |
2020-05-20
|
03 | Yuehua Wei | Uploaded new revision |
2020-03-04
|
02 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-02.txt |
2020-03-04
|
02 | (System) | New version approved |
2020-03-03
|
02 | (System) | Request for posting confirmation emailed to previous authors: Yuehua Wei , Paul Quinn , Uri Elzur , sfc-chairs@ietf.org, Sumandra Majee |
2020-03-03
|
02 | Yuehua Wei | Uploaded new revision |
2019-12-16
|
01 | Yuehua Wei | New version available: draft-ietf-sfc-nsh-tlv-01.txt |
2019-12-16
|
01 | (System) | Forced post of submission |
2019-12-15
|
01 | (System) | Request for posting confirmation emailed to previous authors: Uri Elzur , Paul Quinn , sfc-chairs@ietf.org, Sumandra Majee |
2019-12-15
|
01 | Yuehua Wei | Uploaded new revision |
2018-08-02
|
00 | (System) | Document has expired |
2018-01-29
|
00 | Sumandra Majee | New version available: draft-ietf-sfc-nsh-tlv-00.txt |
2018-01-29
|
00 | (System) | New version approved |
2018-01-29
|
00 | Sumandra Majee | Request for posting confirmation emailed to submitter and authors: Uri Elzur , Paul Quinn , Sumandra Majee |
2018-01-29
|
00 | Sumandra Majee | Uploaded new revision |