IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)
draft-ietf-ippm-ioam-ipv6-options-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2023-09-26
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2023-09-22
|
12 | (System) | RFC Editor state changed to AUTH48 |
2023-07-19
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2023-05-26
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2023-05-26
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2023-05-26
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2023-05-25
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2023-05-25
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2023-05-22
|
12 | (System) | RFC Editor state changed to EDIT |
2023-05-22
|
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2023-05-22
|
12 | (System) | Announcement was received by RFC Editor |
2023-05-19
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2023-05-19
|
12 | (System) | IANA Action state changed to In Progress |
2023-05-19
|
12 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2023-05-19
|
12 | Cindy Morgan | IESG has approved the document |
2023-05-19
|
12 | Cindy Morgan | Closed "Approve" ballot |
2023-05-19
|
12 | Cindy Morgan | Ballot approval text was generated |
2023-05-19
|
12 | Martin Duke | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2023-05-07
|
12 | Frank Brockners | New version available: draft-ietf-ippm-ioam-ipv6-options-12.txt |
2023-05-07
|
12 | (System) | New version approved |
2023-05-07
|
12 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2023-05-07
|
12 | Frank Brockners | Uploaded new revision |
2023-05-05
|
11 | John Scudder | [Ballot comment] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-11 CC @jgscudder ## COMMENT Thanks for taking care of my previous DISCUSSes and many of … [Ballot comment] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-11 CC @jgscudder ## COMMENT Thanks for taking care of my previous DISCUSSes and many of my earlier comments. There remain a few comments that weren't addressed in versions 10 or 11 nor responded to in email, please forgive me if I've missed a response. I repeat the comments below, with section numbers updated to match the numbering in versions 10 and 11. ### Section 3, reference for IOAM Type, nomenclature ``` IOAM Type: 8-bit field as defined in section 7.1 in [RFC9197]. ``` Section 7.1 of RFC 9197 is the IOAM Option-Type Registry in the IANA Considerations section. I wouldn't say an IANA registry "defines" anything, it lists code points. I think a better reference would be Section 4 of 9197, which does indeed define IOAM-Option-Types (in Section 4.1). Also, it would be better to be consistent with your naming, in RFC 9197 you don't call this the "IOAM Type" but rather the "IOAM-Option-Type" (34 occurrences in 9197) or "IOAM Option-Type" without the first hyphen (4 occurrences in 9197). I see why you don't want to use the full string from RFC 9197 in your packet diagram (too many characters) but "IOAM-Opt-Type" would fit in the character budget. ### Section 4.2, encapsulation? ``` For deployments where the IOAM domain is bounded by hosts, hosts will perform the operation of IOAM data field encapsulation and decapsulation. ``` Do you intend to imply that the hosts at the edge of the domain are sending IP-in-IPv6 encapsulated data? It wouldn't seem to be required; since the hosts are the source/sink of the packets, the problem described in C6 doesn't apply, and the host can directly place the IOAM data in the header. (What would be the "inner header" in an overlay solution.) I suppose it's technically accurate to describe this as an "encapsulation and decapsulation" operation, insofar as any data placed in any header might be said to be encapsulated in that header -- but it's misleading. I think this section needs to be rewritten to make the meaning plain. For example, something like "... hosts will place the IOAM data field directly in the IPv6 header." (You could say "outer IPv6 header" since there's nothing precluding a host from sending tunneled packets for some purpose.) (I notice Éric Vyncke raises a similar concern about the nontraditional use of the term "encapsulation" in his comments.) ### Section 4.3, encapsulation again This one is less misleading, but by analogy to 4.2 I suspect more clarity is required here too. ``` For deployments where the IOAM domain is bounded by network devices, network devices such as routers form the edge of an IOAM domain. Network devices will perform the operation of IOAM data field encapsulation and decapsulation. ``` For example, a more straightforwardly understandable version of the last sentence might be "Network devices will encapsulate in-flight packets in an outer IPv6 header which carries the IOAM data field." ## 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-05
|
11 | John Scudder | [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss |
2023-05-04
|
11 | (System) | Removed all action holders (IESG state changed) |
2023-05-04
|
11 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-05-04
|
11 | Frank Brockners | New version available: draft-ietf-ippm-ioam-ipv6-options-11.txt |
2023-05-04
|
11 | (System) | New version approved |
2023-05-04
|
11 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2023-05-04
|
11 | Frank Brockners | Uploaded new revision |
2023-04-25
|
10 | Martin Duke | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2023-04-25
|
10 | Martin Duke | Changed action holders to Shwetha Bhandari, Frank Brockners (Authors are working on a response to the latest DISCUSS) |
2023-04-11
|
10 | Carlos Jesús Bernardos | Request closed, assignment withdrawn: Dave Thaler Telechat INTDIR review |
2023-04-11
|
10 | Carlos Jesús Bernardos | Closed request for Telechat review by INTDIR with state 'Overtaken by Events' |
2023-04-08
|
10 | Erik Kline | [Ballot Position Update] Position for Erik Kline has been changed to No Objection from Discuss |
2023-03-20
|
10 | Andrew Alston | [Ballot comment] Hi, Firstly thanks for the modifications to the text. While I still support the discuss points raised by John, I'm going to clear … [Ballot comment] Hi, Firstly thanks for the modifications to the text. While I still support the discuss points raised by John, I'm going to clear my discuss based on the fact that I think that the new next in C2 seems to address my destination option query, since I'm going to presume that if the destination address is a SID - it stands to reason that where a SID is not bound to a specific interface, it cannot be IOAM enabled and therefore the packets should be ignored. |
2023-03-20
|
10 | Andrew Alston | [Ballot Position Update] Position for Andrew Alston has been changed to No Objection from Discuss |
2023-03-08
|
10 | John Scudder | [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-10 CC @jgscudder ## DISCUSS Thanks for taking care of my previous DISCUSS! I'm so sorry … [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-10 CC @jgscudder ## DISCUSS Thanks for taking care of my previous DISCUSS! I'm so sorry to have to raise another one, related to the new text. C1 IOAM MUST be deployed as a limited domain feature as defined in [RFC8799]. I applaud your desire to be prescriptive and concise. Unfortunately, I think there are a few problems here. First the small ones: you have RFC 8799 as an Informative reference, which is problematic since you want to make adherence to it mandatory. But, if you move it to be a Normative reference (as seems indicated), then we encounter two further issues: first and less importantly, it’s not an IETF document, so possibly needs to be treated as a downref? But most importantly, as far as I can tell RFC 8799 does not define “a limited domain feature”. It provides a taxonomy for talking about limited domains and various considerations, but nothing I would call a “definition”. I confess I’ve only briefly reviewed 8799 just now, not fully re-read it, so maybe you will be able to point me to a clear and actionable definition, that an implementor of your spec could apply in order to comply with C1. If so, please do let me know what that definition is, and also update your reference to cite it specifically, rather than just the RFC number. In my own review of 8799, the closest I see is Section 6, "Functional Requirements of Limited Domains”. I will be a little surprised if you really want to require adherence requirements 1-11 in that section, though. Sadly, I suspect that you’ll end up concluding that RFC 8799 isn’t fit for the purpose you’re trying to use it for and that you’ll need to write out in your own words what the specific requirements are for your case. It looks to me as though the taxonomy section of RFC 8799 might be quite useful to you in that respect, indeed that seems to be partly what it’s for: ``` A.9. Making Use of This Taxonomy This taxonomy could be used to design or analyze a specific type of limited domain. ``` It’s unfortunate that we don’t have a good, citable definition of “limited domain” in our document set... but we don’t. This might be merely because nobody has bothered to write it yet, although I think the real reason is more likely that it turns out to be a sticky problem to nail it down to a definition that is both general enough to be broadly applicable and specific enough to be actionable. |
2023-03-08
|
10 | John Scudder | [Ballot comment] ## COMMENT Thanks for taking care of many of my previous comments. A few appear not to have been addressed in version 10 … [Ballot comment] ## COMMENT Thanks for taking care of many of my previous comments. A few appear not to have been addressed in version 10 nor responded to in email, please forgive me if I've missed a response. I repeat the comments below, with section numbers updated to match the numbering in version 10. ### Section 3, reference for IOAM Type, nomenclature ``` IOAM Type: 8-bit field as defined in section 7.1 in [RFC9197]. ``` Section 7.1 of RFC 9197 is the IOAM Option-Type Registry in the IANA Considerations section. I wouldn't say an IANA registry "defines" anything, it lists code points. I think a better reference would be Section 4 of 9197, which does indeed define IOAM-Option-Types (in Section 4.1). Also, it would be better to be consistent with your naming, in RFC 9197 you don't call this the "IOAM Type" but rather the "IOAM-Option-Type" (34 occurrences in 9197) or "IOAM Option-Type" without the first hyphen (4 occurrences in 9197). I see why you don't want to use the full string from RFC 9197 in your packet diagram (too many characters) but "IOAM-Opt-Type" would fit in the character budget. ### Section 4.2, encapsulation? ``` For deployments where the IOAM domain is bounded by hosts, hosts will perform the operation of IOAM data field encapsulation and decapsulation. ``` Do you intend to imply that the hosts at the edge of the domain are sending IP-in-IPv6 encapsulated data? It wouldn't seem to be required; since the hosts are the source/sink of the packets, the problem described in C6 doesn't apply, and the host can directly place the IOAM data in the header. (What would be the "inner header" in an overlay solution.) I suppose it's technically accurate to describe this as an "encapsulation and decapsulation" operation, insofar as any data placed in any header might be said to be encapsulated in that header -- but it's misleading. I think this section needs to be rewritten to make the meaning plain. For example, something like "... hosts will place the IOAM data field directly in the IPv6 header." (You could say "outer IPv6 header" since there's nothing precluding a host from sending tunneled packets for some purpose.) (I notice Éric Vyncke raises a similar concern about the nontraditional use of the term "encapsulation" in his comments.) ### Section 4.3, encapsulation again This one is less misleading, but by analogy to 4.2 I suspect more clarity is required here too. ``` For deployments where the IOAM domain is bounded by network devices, network devices such as routers form the edge of an IOAM domain. Network devices will perform the operation of IOAM data field encapsulation and decapsulation. ``` For example, a more straightforwardly understandable version of the last sentence might be "Network devices will encapsulate in-flight packets in an outer IPv6 header which carries the IOAM data field." ## 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-03-08
|
10 | John Scudder | Ballot comment and discuss text updated for John Scudder |
2023-03-06
|
10 | Éric Vyncke | [Ballot comment] Thanks for addressing my previous blocking DISCUSS issue. For archive: https://mailarchive.ietf.org/arch/msg/ippm/iFh9vrAOZ-79nVqR3QF5kOEKUcM/ -éric |
2023-03-06
|
10 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2023-03-01
|
10 | Roman Danyliw | [Ballot comment] Thank you for addressing my DISCUSS and COMMENT feedback. |
2023-03-01
|
10 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2023-02-28
|
10 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2023-02-28
|
10 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-02-28
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-02-28
|
10 | Shwetha Bhandari | New version available: draft-ietf-ippm-ioam-ipv6-options-10.txt |
2023-02-28
|
10 | (System) | New version approved |
2023-02-28
|
10 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2023-02-28
|
10 | Shwetha Bhandari | Uploaded new revision |
2022-12-07
|
09 | Lars Eggert | [Ballot comment] # GEN AD review of draft-ietf-ippm-ioam-ipv6-options-09 CC @larseggert Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/N0aMpTOtDieVf0vT6Tu2reLFewI). … [Ballot comment] # GEN AD review of draft-ietf-ippm-ioam-ipv6-options-09 CC @larseggert Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/N0aMpTOtDieVf0vT6Tu2reLFewI). ## Comments I find myself agreeing with the numerous DISCUSS positions, but I trust the ADs that raised them to resolve them with the authors. ### Section 4, paragraph 28 ``` All the in-situ OAM IPv6 options defined here have alignment requirements. Specifically, they all require 4n alignment. This ``` I haven't come across the term "4n alignment" before. Suggest to rephrase (by using the text in the following sentence.) ## Nits 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. ### Typos #### Section 5.1, paragraph 4 ``` - C3 Packets with IOAM data or associated ICMP errors, should not - - ``` ### Outdated references Document references `draft-ietf-ippm-ioam-direct-export`, but that has been published as `RFC9326`. ### URLs These URLs point to tools.ietf.org, which has been taken out of service: * https://tools.ietf.org/id/draft-kitamura-ipv6-record-route-00.txt These URLs in the document can probably be converted to HTTPS: * http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2 ### Grammar/style #### Section 5.1, paragraph 3 ``` IOAM. For example, if IOAM is used in in transit devices, misleading ICMP er ^^^^^ ``` Possible typo: you repeated a word. #### Section 5.1, paragraph 3 ``` ommunicate the errors to devices outside of the IOAM domain MUST remove any ^^^^^^^^^^ ``` This phrase is redundant. Consider using "outside". #### Section 5.1, paragraph 5 ``` options that follow IOAM options. Hence when the IOAM Incremental Trace Opt ^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Hence". #### Section 5.4.1, paragraph 1 ``` LA destination address is invalid outside of the IOAM domain. There is no ext ^^^^^^^^^^ ``` This phrase is redundant. Consider using "outside". ## 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. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2022-12-07
|
09 | Lars Eggert | Ballot comment text updated for Lars Eggert |
2022-12-07
|
09 | Lars Eggert | [Ballot comment] # GEN AD review of draft-ietf-lamps-rfc3709bis-08 CC @larseggert Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/IiFgJfnLGPzwxj92raQWE4oI108). … [Ballot comment] # GEN AD review of draft-ietf-lamps-rfc3709bis-08 CC @larseggert Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/IiFgJfnLGPzwxj92raQWE4oI108). ## Comments ### Section 4.1, paragraph 8 ``` Note that the HTTPS scheme (https://...) requires the validation of other certificates to establish a secure connection. For this reason, the HTTP scheme (http://...) may be easier for a client to handle. Also, the hash of the logotype data provides data integrity. ``` It may be easier, but it's also insecure. I find it odd that we don't recommend HTTPS over HTTP here? ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `his`; alternatives might be `they`, `them`, `their` * Term `traditional`; alternatives might be `classic`, `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`, `long-established`, `popular`, `prescribed`, `regular`, `rooted`, `time-honored`, `universal`, `widely used`, `widespread` ## Nits 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. ### Typos #### Section 3, paragraph 6 ``` - applications where the audio text is placed as the "alt" atttribute - - ``` #### Section 3, paragraph 6 ``` - value of an html image (img) element and the language value obtained - ^^^^ + value of an HTML image (img) element and the language value obtained + ^^^^ ``` #### Section 7, paragraph 16 ``` - When a bitmapped image is used, the PNG [ISO15948] format SHOULD be - --- ``` ### URLs These URLs in the document can probably be converted to HTTPS: * http://www.w3.org/TR/2008/PR-SVGTiny12-20081117 ### Grammar/style #### Section 1, paragraph 3 ``` tificate may be examined from several different perspectives. Systematic pro ^^^^^^^^^^^^^^^^^ ``` Consider using "several". #### Section 1, paragraph 9 ``` a user identifies the owner of the web site. * Peer e-mail exchange in busin ^^^^^^^^ ``` Nowadays, it's more common to write this as one word. #### Section 1.1, paragraph 4 ``` ate is too technical and is not user friendly. It contains no graphic symbol ^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 1.3, paragraph 3 ``` the end, the human will decide whether or not to accept an executable email a ^^^^^^^^^^^^^^ ``` Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". #### Section 6, paragraph 7 ``` references to information stored outside of the SVG image of type B, C, or D ^^^^^^^^^^ ``` This phrase is redundant. Consider using "outside". #### Section 7, paragraph 2 ``` FC1952] as specified in [SVGR]. When a uncompressed SVG image is fetched wit ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### Section 7, paragraph 3 ``` characters as specified above. When a SVG image is embedded in the certific ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". ## 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. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2022-12-07
|
09 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2022-12-01
|
09 | (System) | Changed action holders to Martin Duke, Frank Brockners, Shwetha Bhandari (IESG state changed) |
2022-12-01
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2022-12-01
|
09 | Robert Wilton | [Ballot comment] Hi, Thanks for this doc. Minor level comments: … [Ballot comment] Hi, Thanks for this doc. Minor level comments: (1) p 5, sec 4. In-situ OAM Metadata Transport in IPv6 IPv6 options can have a maximum length of 255 octets. Consequently, the total length of IOAM Option-Types including all data fields is also limited to 255 octets when encapsulated into IPv6. Given the alignment requirements, wouldn't the max length be slightly smaller, e.g. 252 bytes? (2) p 6, sec 5.2. IOAM domains bounded by hosts For deployments where the IOAM domain is bounded by hosts, hosts will perform the operation of IOAM data field encapsulation and decapsulation. IOAM data is carried in IPv6 packets as Hop-by-Hop or Destination options as specified in this document. For clarity, does this mean that in this case that there is presumably no need to encapsulate the host packet within a separate IPv6 packet, and the OAM extension header could be embedded directly when the v6 header of the host packet is being constructed? (3) p 7, sec 5.4.1. IP-in-IPv6 encapsulation with ULA An IPv6 header including IOAM data fields in an extension header is added in front of it, to forward traffic within and across the IOAM domain. Rather than saying add an IPv6 in front of it, wouldn't be more accurate to say that it is being encapsulated with an IPv6 header including the IOAM data fields? (4) p 7, sec 5.4.1. IP-in-IPv6 encapsulation with ULA IPv6 addresses for the IOAM Overlay Network, i.e. the outer IPv6 addresses are assigned from the ULA space. Addressing and routing in the IOAM Overlay Network are to be configured so that the IP-in-IPv6 encapsulated packets follow the same path as the original, non-encapsulated packet would have taken. This would create an internal IPv6 forwarding topology using the IOAM domain's interior ULA address space which is parallel with the forwarding topology that exists with the non-IOAM address space (the topology and address space that would be followed by packets that do not have supplemental IOAM information). Establishment and maintenance of the parallel IOAM ULA forwarding topology could be automated, e.g., similar to how LDP [RFC5036] is used in MPLS to establish and maintain an LSP forwarding topology that is parallel to the network's IGP forwarding topology. Maintaining a separate ULA forwarding topology seems to introduce a certain level of additional complexity. Is there any risk of the parallel forwarding plane programming lagging behind the non-IOAM topology such that different paths through the network would be taken? (5) p 8, sec 6. Security Considerations As this document describes new options for IPv6, these are similar to the security considerations of [RFC8200] and the weakness documented in [RFC8250]. Are there any security considerations relative to using ULA addressing for encapsulating the traffic that should be documented here? Regards, Rob |
2022-12-01
|
09 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2022-11-30
|
09 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2022-11-30
|
09 | Erik Kline | [Ballot discuss] # Internet AD comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @ekline * Thanks to 6MAN chairs Bob, Ole, and Jen for their last-minute "IPv6 Directorate" … [Ballot discuss] # Internet AD comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @ekline * Thanks to 6MAN chairs Bob, Ole, and Jen for their last-minute "IPv6 Directorate" reviews. Some of their comments are reflected below. * There was kind of leaning toward concluding that the rewriting of a Hop-by-Hop option's size was both against the spirit of RFC 8200 and not actually against the letter. I'm not sure that's actually the case and so my biggest DISCUSS is this point (more below). ## Discuss ### S4 * I don't think the Incremental Trace Option is something that can be supported by current text in RFC 8200. While is makes sense to have this behavior described in RFC 9197, I don't think IPv6 HbH can support it. My rationale for seeing this as a protocol violation is as follows. - RFC 8200 S4.2 says this about the on-path mutability bit and the expectations that result: """ The third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en route to the packet's final destination. When an Authentication header is present in the packet, for any option whose data may change en route, its entire Option Data field must be treated as zero-valued octets when computing or verifying the packet's authenticating value. """ - Specifically, only the Option Data (not Option Length) is allowed to change. Any AH header, for example, would still have processed the entire option with only the Data being zeroed -- the existence of the option and the length of it would still have been part of the AH computation. Unless there's some misunderstanding here I think this option would need removing from the document. * I think text needs to be added to make it clear that whatever options are used they MUST be added, though not necessarily "filled in", by the originator of the packet (the node bearing the interface assigned the outermost Source Address). The reasoning here again is the defined behavior of AH processing. Any options, even on-path mutable ones, MUST be present in the Hop-by-Hop option when an AH is computed. |
2022-11-30
|
09 | Erik Kline | [Ballot comment] ## Comments ### S5.1 * In C2: "domain SHOULD ensure that the addition of OAM information does not lead to fragmentation of … [Ballot comment] ## Comments ### S5.1 * In C2: "domain SHOULD ensure that the addition of OAM information does not lead to fragmentation of the packet" This should probably be rephrased to be more IPv6-compatible (as there is no on-path fragmentation). Perhaps: "does not lead to an ICMP Packet To Big error message being sent to the originator and the packet being dropped" or something to that effect. * Also in C2: "exceeds the packet size beyond PTMU" in the domain, etc. It may be worth noting that any single node can only know the configured MTU of its outgoing links, and that this is why it MUST be a domain-managed parameter. * C3 appears to create a requirement for some very deep packet inspection on IOAM domain egress. Also, if there's going to be talk of ICMPv6 you probably need to add a reference to RFC 4443. * With respect to C4, I'd defer to the other IESG comments. * C5: this seems like it might be important for a Standards Track feature? If it were Experimental, perhaps, then there could be text saying that learning how this might best be done was an expected outcome of the experiment? |
2022-11-30
|
09 | Erik Kline | [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline |
2022-11-30
|
09 | Andrew Alston | [Ballot discuss] Hi There, Firstly thanks for the document. I have two issues I'd like to discuss and see if we can find some clarity … [Ballot discuss] Hi There, Firstly thanks for the document. I have two issues I'd like to discuss and see if we can find some clarity on. The first stems from RFC8200 Section 4.8 Third Paragraph, which reads: New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Designers considering defining new hop-by-hop options need to be aware of this likely behavior. There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized. I believe that the document potentially needs to spell out a clearer justification to meet the requirements laid out in the above text. The second question relates to dealing with IOAM in the context of SRv6. With the HbH option - this is processed on a hop-by-hop basis and, as per RFC8200, is placed directly after the IPv6 header. This I don't see as a problem. My question comes in the case of the destination option. In SRv6, where a SID is, for all intents and purposes, acting like an address - I'd like to see some text dealing with what happens when the DO is applied in the context of the SRv6 where the destination address is not a normal address - but rather an IPv6 SID. Does the router drop the entire packet? Does the router "de-encap" as if it were a tunneled packet? Basically - I see a situation where that could lead to undefined behavior that always makes me nervous. Could the authors, therefore, expand slightly on how the destination option is handled in the context of SRv6 and its various flavors? |
2022-11-30
|
09 | Andrew Alston | [Ballot Position Update] New position, Discuss, has been recorded for Andrew Alston |
2022-11-29
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-11-29
|
09 | Warren Kumari | [Ballot comment] I spent a while oscillating between DISCUSS and NoObjection when balloting on this document, before finally settling on Abstain (a non-blocking position). Like … [Ballot comment] I spent a while oscillating between DISCUSS and NoObjection when balloting on this document, before finally settling on Abstain (a non-blocking position). Like others, I have concerns about what happens when IOAM EH packets invariably leak outside the IOAM domain. My views align very strongly with John Scudder's, but seeing as he is already carrying the DISCUSS, I'm going to cowardly abstain and hide behind him. The document feels like it is creating something very similar to a "limited domain"; the reason that I'm not balloting DISCUSS is that the document "feels" like it is trying to minimize the damage when IOAM packets do leak. This includes "failing closed" ('IOAM MUST be explicitly enabled per interface on every node within the IOAM domain'). I am, however, quite troubled by the "As additional security, IOAM domains MUST provide a mechanism to prevent unauthorized injections at ingress or leaks at egress." without actually stating how this would be performed. The fact that the IOAM data is information (it doesn't obfuscate the source of the traffic, nor (hopefully!) change routing / forwarding) also helps push this from DISCUSS to Abstain for me - when a domain *does* leak packets with IOAM info, they will either exceed the MTU and so be dropped, or will "just" be leaking traffic stats from that domain, and should otherwise be forwarded OK. There are some Considerations in Sec 5 which I think are unrealistic, but not harmful - for example: * I suspect that in some cases adding IOAM will change ECMP hashing (C1); * they *will* leak (C3), but this shouldn't break things; * they *will* leak (C4), but I suspect that external devices will simply ignore the EH header; I have a horrible feeling that I'm being inconsistent with my balloting: normally I would ballot DISCUSS on documents which either add information to an in-flight packet, or which create any sort of closed domain, but in this case I feel that the document has sufficiently attempted to mitigate the (external) consequences of leaks that I'm choosing Abstain instead. |
2022-11-29
|
09 | Warren Kumari | [Ballot Position Update] New position, Abstain, has been recorded for Warren Kumari |
2022-11-29
|
09 | John Scudder | [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request … [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Structure of the document; Section 5 is vague The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine. But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way. Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents. ### Section 5.1, C5 is problematic ``` An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document. ``` First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic. Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done. Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand. |
2022-11-29
|
09 | John Scudder | Ballot discuss text updated for John Scudder |
2022-11-29
|
09 | John Scudder | [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request … [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Structure of the document; Section 5 is vague The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine. But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way. Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents. ### Section 5.1, C5 is problematic ``` An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document. ``` First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic. Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done. Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand. |
2022-11-29
|
09 | John Scudder | Ballot discuss text updated for John Scudder |
2022-11-29
|
09 | John Scudder | [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request … [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Structure of the document; Section 5 is vague The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine. But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way. Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents. ### Section 5.1, C5 is problematic ``` An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document. ``` First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic. Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done. Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand. |
2022-11-29
|
09 | John Scudder | Ballot discuss text updated for John Scudder |
2022-11-29
|
09 | John Scudder | [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request … [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Structure of the document; Section 5 is vague The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine. But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way. Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents. ### Section 5.1, C5 is problematic ``` An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document. ``` First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic. Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done. Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand. |
2022-11-29
|
09 | John Scudder | Ballot discuss text updated for John Scudder |
2022-11-29
|
09 | John Scudder | [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request … [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Structure of the document; Section 5 is vague The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine. But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way. Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents. ### Section 5.1, C5 is problematic ``` An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document. ``` First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic. Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done. Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand. |
2022-11-29
|
09 | John Scudder | Ballot discuss text updated for John Scudder |
2022-11-29
|
09 | John Scudder | [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request … [Ballot discuss] # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @jgscudder ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Structure of the document; Section 5 is vague The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine. But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way. Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents. ### Section 5.1, C5 is problematic ``` An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document. ``` First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic. Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done. Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand. |
2022-11-29
|
09 | John Scudder | [Ballot comment] ## COMMENTS These comments are non-blocking, but I'd still appreciate responses. ### Section 4, a particular interface ``` Unless a particular interface is … [Ballot comment] ## COMMENTS These comments are non-blocking, but I'd still appreciate responses. ### Section 4, a particular interface ``` Unless a particular interface is explicitly enabled (i.e., explicitly configured) for IOAM, a router MUST ignore IOAM Options. ``` I suppose what you mean is, the router MUST ignore IOAM Options on packets received on that interface? If so, please say so. (If not, let's discuss.) ### Section 4, reference for IOAM Type, nomenclature ``` IOAM Type: 8-bit field as defined in section 7.1 in [RFC9197]. ``` Section 7.1 of RFC 9197 is the IOAM Option-Type Registry in the IANA Considerations section. I wouldn't say an IANA registry "defines" anything, it lists code points. I think a better reference would be Section 4 of 9197, which does indeed define IOAM-Option-Types (in Section 4.1). Also, it would be better to be consistent with your naming, in RFC 9197 you don't call this the "IOAM Type" but rather the "IOAM-Option-Type" (34 occurrences in 9197) or "IOAM Option-Type" without the first hyphen (4 occurrences in 9197). I see why you don't want to use the full string from RFC 9197 in your packet diagram (too many characters) but "IOAM-Opt-Type" would fit in the character budget. ### Section 4, Trace-Type constraints ``` In addition, to maintain IPv6 extension header 8-octet alignment and avoid the need to add or remove padding at every hop, the Trace-Type for Incremental Trace Option in IPv6 MUST be selected such that the IOAM node data length is a multiple of 8-octets. ``` I spent some time trying to understand exactly what it means for the Trace-Type to be selected such that, etc. I suppose this isn't too complicated in the end, since all the types defined in RFC 9197 are either four- or eight-byte fields. I don't see an explicit pad field being defined, though, so I wonder if it would be a helpful hint to note that the Opaque State Snapshot with Length 0 and Schema ID 0xFFFFFF can be used as a four-octet pad if needed. I see you use 0xFFFFFFFF as a pad in some places in RFC 9197, but there's no corresponding Trace-Type and it doesn't seem prudent to just poach a currently undefined bit to indicate the pad. I guess the other alternative would be to allocate a new Trace-Type bit to explicitly indicate a four-byte pad field, but given you can use Opaque State for this purpose, I don't see why you'd burn the bit. Anyway, if I've missed some explicit way eight-byte alignment is supported in RFC 9197, please point it out to me? Otherwise, I think you need to be clearer about this, to discourage implementors from exercising "creativity". ### Section 5.1, C3, entities that communicate the errors ``` The entities that communicate the errors to devices outside of the IOAM domain MUST remove any IOAM data from the packet included in the error message ``` This is quite non-specific. Who are “the entities“ in this context? The host or router that originates the ICMP report? The router that forwards it outside the domain? If the former, I guess that means every entity within the domain that might originate an ICMP message has to know a priori if it's sending its message to an internal or external recipient. If the latter, that's a notable new requirement on border routers. ### Section 5.1, C4 violates closed domain ``` OAM data leaks can affect the forwarding behavior and state of network elements outside an IOAM domain. IOAM domains MUST provide a mechanism to prevent data leaks or be able to ensure that if a leak occurs, network elements outside the domain are not affected (i.e., they continue to process other valid packets). ``` I have a few difficulties with C4. Among them -- - The first sentence is quite nonspecific, I don't know if you have some actual failure modes in mind but I suppose you must. Can you elucidate? - The second sentence, starting with "or", appears to violate the limited domain assumption, or at the least, it introduces a creative understanding of it ("go ahead and leak as long as you're sure the leaks are fine"). - I don't understand how an operator could possibly fulfill the "or" clause with confidence since by definition whatever is happening outside the border of the limited domain is not under the control of, or even necessarily known to, the operator. My guess is that you're trying to motivate the ULA deployment option here, without talking about it specifically. Is that right? ### Section 5.1, C6 is inaccurate ``` Compliance with [RFC8200] requires OAM data to be encapsulated instead of header/option insertion directly into in-flight packets using the original IPv6 header. ``` I don't think you mean the OAM data (by which I think you mean IOAM data) needs to be encapsulated, but rather that it needs to be within an encapsulation header? That's what's implied by your Deployment Options section, anyway. If so, please say so, if not, let's discuss. Assuming I've guessed correctly, a possible rewrite could look something like ``` [RFC8200] precludes insertion of IOAM data directly into the original IPv6 header of in-flight packets. Therefore, in order to add IOAM data, in-flight packets must be encapsulated in an outer header, and the IOAM data added to that header. ``` ### Section 5.1, C7, wording ``` Hence when the IOAM Incremental Trace Option-Type is used in the deployment the RemainingLen field of the option MUST follow the guidance in [RFC9197] and must be computed and set appropriately. ``` I assume you mean "used in deployment" and didn't intend the definite article (which would imply you're talking about a specific deployment). But I think instead of just dropping "the", you might as well go ahead and drop "in the deployment" (where else is it going to be used after all, where this guidance wouldn't apply?). ### Section 5.1, C7, lack of specificity ``` The IOAM Incremental Trace Option-Type expands the option length that may affect the processing of extension headers and options that follow IOAM options. Hence when the IOAM Incremental Trace Option-Type is used in the deployment the RemainingLen field of the option MUST follow the guidance in [RFC9197] and must be computed and set appropriately. ``` What guidance, exactly, is supposed to be followed? I dug around in RFC 9197 and the best guess I could come up with is ``` The sender MAY calculate the value of the RemainingLen field by computing the number of node data bytes allowed before exceeding the PMTU, given that the PMTU is known to the sender. ``` I'm not very happy with that guess, because it doesn't seem to be responsive to the problem you've posed. What I've quoted from RFC 9197 is a way to avoid exceeding the PMTU, but in the present document you've posed the concern that if you shove too much data into the IOAM header, other extension headers may be ignored. That's not the same as PMTU, which relates to total packet size, not header options size. Whatever it is you're trying to do here, I think you need to be more specific about it. ### Section 5.2, encapsulation? ``` For deployments where the IOAM domain is bounded by hosts, hosts will perform the operation of IOAM data field encapsulation and decapsulation. ``` Do you intend to imply that the hosts at the edge of the domain are sending IP-in-IPv6 encapsulated data? It wouldn't seem to be required; since the hosts are the source/sink of the packets, the problem described in C6 doesn't apply, and the host can directly place the IOAM data in the header. (What would be the "inner header" in an overlay solution.) I suppose it's technically accurate to describe this as an "encapsulation and decapsulation" operation, insofar as any data placed in any header might be said to be encapsulated in that header -- but it's misleading. I think this section needs to be rewritten to make the meaning plain. For example, something like "... hosts will place the IOAM data field directly in the IPv6 header." (You could say "outer IPv6 header" since there's nothing precluding a host from sending tunneled packets for some purpose.) (I notice Éric Vyncke raises a similar concern about the nontraditional use of the term "encapsulation" in his comments.) ### Section 5.3, encapsulation again This one is less misleading, but by analogy to 5.2 I suspect more clarity is required here too. ``` For deployments where the IOAM domain is bounded by network devices, network devices such as routers form the edge of an IOAM domain. Network devices will perform the operation of IOAM data field encapsulation and decapsulation. ``` For example, a more straightforwardly understandable version of the last sentence might be "Network devices will encapsulate in-flight packets in an outer IPv6 header which carries the IOAM data field." ### Section 5.4.1 infeasible requirement ``` Addressing and routing in the IOAM Overlay Network are to be configured so that the IP-in-IPv6 encapsulated packets follow the same path as the original, non-encapsulated packet would have taken. ``` This doesn't seem to be feasible in the face of ECMP. ### Section 5.4.2, wording ``` In this case IOAM can be encapsulated in as an extension header in the tunnel (outer) IPv6 header. ``` Is the "as" unintended in the quoted text? If so, please remove it, if not, I don't understand the meaning. ## NITS ### Section 5.1 "if IOAM is used in in transit devices" s/in in/in/ ### Section 5.4 "This section lists out" Just "lists", no "out". ### 5.4.1 "almost close to zero" I assume you mean either "almost zero" or "close to zero". Because as written, I would parse "almost close to zero" as "not close to zero" which is probably not what you're going for. ## 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 |
2022-11-29
|
09 | John Scudder | [Ballot Position Update] New position, Discuss, has been recorded for John Scudder |
2022-11-29
|
09 | Éric Vyncke | [Ballot discuss] # Éric Vyncke, INT AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @evyncke Thank you for the work put into this document. Please find below one … [Ballot discuss] # Éric Vyncke, INT AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @evyncke 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 Marcus Ihlar for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Please note that Dave Thaler is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Tim will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/reviewrequest/16642/ I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Section 5.1 ``` Operators of an IOAM domain SHOULD ensure that the addition of OAM information does not lead to fragmentation of the packet, e.g., by configuring the MTU of transit routers and switches to a sufficiently high value. ``` Should it be a MUST as IPv6 routers are unable to fragment an IPv6 packet ? Should "e.g." be replaced by "i.e." ? Roman's DISCUSS points are also sensible. |
2022-11-29
|
09 | Éric Vyncke | [Ballot comment] ## COMMENTS ### Encapsulation In the abstract and introduction, it is written that "IOAM options are encapsulated in IPv6". I am unsure whether … [Ballot comment] ## COMMENTS ### Encapsulation In the abstract and introduction, it is written that "IOAM options are encapsulated in IPv6". I am unsure whether this is the right wording as it is the original packet that is encapsulated and then IOAM options added. Suggest to simply use "IOAM option are transported in IPv6 packets". It also seems to prevent the use of IOAM by the source node, which appears to me as an important use case (e.g., video conferencing). ### Section 2 As written by others, the location of the contributors is at a weird location. ### Section 4 `IOAM data fields can be encapsulated in "option data" fields` is hard to parse even for an IPv6-aware person. Is it "option data" as in the diagram below ? Or is it the option fields of HbH & DO as defined in RFC 8200. Does every interface really need to be IOAM enabled ? It seems that not enabling on interface will only degrade the collected information but would still be useful. `a router MUST ignore IOAM Options` what about a host (i.e., not a router) receiving a packet with a destination option containing an IOAM option ? The Reserved field must be set to 0 on transmission, does it include also when it is received in HbH ? I.e., then re-transmitted to the next node ? Suggest to use "set to 0 by the source". ### Section 5.1 To be honest, I was about to mark those comments as blocking discuss points. In C1: ``` Implementations of IOAM SHOULD ensure that ECMP behavior for packets with and without IOAM data fields is the same. ``` What about non-IOAM-aware routers (or even not routers like LACP bundles)? Is it the reason why all routers need to support IOAM as specified in section 4 ? In C2: `which is intended to support hardware implementations of IOAM, ` seems weird. Is it about "which is intended to be used only by hardware-supported implementation" ? In C3, I am afraid that I cannot really parse this consideration. E.g., what is meant by "associated ICMP errors" ? Is it ICMP packet generated by an IOAM-domain router containing IOAM options (my guess) ? If the original packet is encapsulated (per the rest of this I-D), how could an ICMP sent back to the encapsulating node be sent further once decapsulated ? C4, does "data leak" means a "packet with IOAM data leaking outside of the IOAM domain" ? Unsure about the usefulness of C5. ### Section 5.2 The use of "encapsulation" and "decapsulation" appears weird in a host processing. ### Section 5.4 Should it be a sub-section of 5.3 ? (IOAM bounded by network devices) ### Section 5.4.1 Unsure whether there could be a real use case of using ULA just for IOAM... Suggest to remove this section. ### Section 5.4.2 Please add reference to VXLAN and Geneve. ## NITS ### Capitalized Extension header Some occurrence of `Extension header`, unsure whether "extension" should be capitalized though. ### IOAM or in-situ OAM Suggest to always use either "IOAM" or "in-situ OAM" and not the current mix. ### Section 5.1 s/that/than/ in `should follow the same path within the domain that an identical` ? ## 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 |
2022-11-29
|
09 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2022-11-27
|
09 | Tianran Zhou | Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Tianran Zhou. |
2022-11-27
|
09 | Tianran Zhou | Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Tianran Zhou. Sent review to list. Submission of review completed at an earlier date. |
2022-11-24
|
09 | Paul Wouters | [Ballot comment] I support Roman's DISCUSS points. NITS: It is non-standard to list contributors at the start of the document. Usually this is done in … [Ballot comment] I support Roman's DISCUSS points. NITS: It is non-standard to list contributors at the start of the document. Usually this is done in an acknowledgement section at the end of the document. Any reason why not to move the Contributors section just before or within the Acknowledgement section ? are encapsulated in the IPv6 -> are encapsulated in IPv6 |
2022-11-24
|
09 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2022-11-22
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tianran Zhou |
2022-11-22
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tianran Zhou |
2022-11-22
|
09 | Roman Danyliw | [Ballot discuss] Section 4 and RFC9197 seem clear that IOAM traffic cannot leave the IOAM domain. However, this document seems to be suggesting behavior that … [Ballot discuss] Section 4 and RFC9197 seem clear that IOAM traffic cannot leave the IOAM domain. However, this document seems to be suggesting behavior that violates this guidance. Specifically, in Section 5.1, it allows for the possibility of leaks per (a) and explicitly describe a use case where leaks are intentional (b). (a) Section 5.1. C3. IOAM domains MUST provide a mechanism to prevent data leaks or be able to ensure that if a leak occurs, network elements outside the domain are not affected (i.e., they continue to process other valid packets). (b) Section 5.1. C5. An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting,... Furthermore, per (a), why are “IOAM domains … provid[ing] a mechanism” which suggests a feature rather than a required to explicitly prevent this behavior. |
2022-11-22
|
09 | Roman Danyliw | [Ballot comment] ** Section 4. As additional security, IOAM domains MUST provide a mechanism to prevent unauthorized injections at ingress or leaks … [Ballot comment] ** Section 4. As additional security, IOAM domains MUST provide a mechanism to prevent unauthorized injections at ingress or leaks at egress. No disagreement. To clarify, is this a new requirement? I thought this configuration was the mandatory architecture of IOAM. Per RFC9197: Notably, IOAM is expected to be deployed in limited domains, thus confining the potential attack vectors to within the limited domain. A limited administrative domain provides the operator with the means to select, monitor, and control the access of all the network devices, making these devices trusted by the operator. Indeed, in order to limit the scope of threats mentioned above to within the current limited domain, the network operator is expected to enforce policies that prevent IOAM traffic from leaking outside of the IOAM- Domain and prevent IOAM data from outside the domain to be processed and used within the domain. ** Section 4. Please be explicit on where the Option Data is specified. I believe it is: -- For the “Pre-allocated Traction Option” and “Incremental Trace Option”, Section 4.4 of RFC9197 -- For the “Proof of Transition Option”, Section 4.5 of RFC9197 -- For the “Edge to Edge Option”, Section 4.6 of RFC9197 -- For the “Direct Export Option” Section 3.2 of RFC9326 ** Section 5.1. C3. Packets with IOAM data or associated ICMP errors, should not arrive at destinations that have no knowledge of IOAM. For example, if IOAM is used in in transit devices, misleading ICMP errors due to addition and/or presence of OAM data in a packet could confuse the host that sent the packet if it did not insert the OAM information. Is the expectation that any entity which adds IOAM headers (either at the source or in transit) will know if a destination in the IOAM domain supports these headers? If so, is that realistic (not knowing where this is currently, or anticipated to be, fielded)?. ** Section 5.1. C3. The entities that communicate the errors to devices outside of the IOAM domain MUST remove any IOAM data from the packet included in the error message. The completeness of this guidance seems to depend on how one reads “the entities that communicate the error” – is it the IOAM hosts or also the network devices at the edge of the IOAM domain. I took it to mean hosts per the deployment model defined in Section 5.2. (IOAM domains bounded by hosts) which would be insufficient. Could this text please be made clearer to cover the deployment models described in 5.2 and 5.3. Editorial ** Section 4. Typo. s/inSection 7/in Section 7/ |
2022-11-22
|
09 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2022-11-17
|
09 | Dan Romascanu | Assignment of request for Telechat review by OPSDIR to Dan Romascanu was rejected |
2022-11-04
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Dan Romascanu |
2022-11-04
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Dan Romascanu |
2022-11-03
|
09 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Dave Thaler |
2022-11-03
|
09 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Dave Thaler |
2022-10-31
|
09 | Éric Vyncke | Requested Telechat review by INTDIR |
2022-10-31
|
09 | Martin Duke | Placed on agenda for telechat - 2022-12-01 |
2022-10-31
|
09 | Martin Duke | Ballot has been issued |
2022-10-31
|
09 | Martin Duke | [Ballot Position Update] New position, Yes, has been recorded for Martin Duke |
2022-10-31
|
09 | Martin Duke | Created "Approve" ballot |
2022-10-31
|
09 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-10-31
|
09 | Martin Duke | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::Revised I-D Needed |
2022-10-19
|
09 | Martin Duke | There was no reply to the SECDIR issue posted here: https://mailarchive.ietf.org/arch/msg/secdir/g6R86wLqJHBC7D4T5khm9nfzQTE/ |
2022-10-19
|
09 | (System) | Changed action holders to Martin Duke, Frank Brockners, Shwetha Bhandari (IESG state changed) |
2022-10-19
|
09 | Martin Duke | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead::AD Followup |
2022-10-11
|
09 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-10-11
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-10-11
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-10-11
|
09 | Shwetha Bhandari | New version available: draft-ietf-ippm-ioam-ipv6-options-09.txt |
2022-10-11
|
09 | Shwetha Bhandari | New version accepted (logged-in submitter: Shwetha Bhandari) |
2022-10-11
|
09 | Shwetha Bhandari | Uploaded new revision |
2022-07-23
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Radia Perlman. Submission of review completed at an earlier date. |
2022-07-15
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Radia Perlman. |
2022-07-13
|
08 | Tianran Zhou | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Tianran Zhou. Sent review to list. |
2022-07-01
|
08 | Martin Duke | Waiting on a response to the GenART review (and any other timely directorate reviews). |
2022-07-01
|
08 | (System) | Changed action holders to Martin Duke, Frank Brockners, Shwetha Bhandari (IESG state changed) |
2022-07-01
|
08 | Martin Duke | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup |
2022-07-01
|
08 | Martin Duke | Ballot writeup was changed |
2022-07-01
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2022-06-28
|
08 | Joel Halpern | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list. |
2022-06-27
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2022-06-27
|
08 | Michelle Thangtamsatid | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ippm-ioam-ipv6-options-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-ippm-ioam-ipv6-options-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 is a single action which we must complete. In the Destination Options and Hop-by-Hop Options registry on the Internet Protocol Version 6 (IPv6) Parameters registry page located at: https://www.iana.org/assignments/ipv6-parameters/ two existing, temporary registrations will be made permanent and their references changed to [ RFC-to-be ] as follows: Hex Value: 0x11 Binary Value (act): 00 Binary Value (chg): 0 Binary Value (rest): 10001 Description: IOAM Reference: [ RFC-to-be ] Hex Value: 0x31 Binary Value (act): 00 Binary Value (chg): 1 Binary Value (rest): 10001 Description: IOAM Reference: [ RFC-to-be ] 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, Michelle Thangtamsatid IANA Services Specialist |
2022-06-24
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2022-06-24
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2022-06-22
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tianran Zhou |
2022-06-22
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tianran Zhou |
2022-06-20
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2022-06-20
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2022-06-17
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2022-06-17
|
08 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-07-01): From: The IESG To: IETF-Announce CC: draft-ietf-ippm-ioam-ipv6-options@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com, martin.h.duke@gmail.com … The following Last Call announcement was sent out (ends 2022-07-01): From: The IESG To: IETF-Announce CC: draft-ietf-ippm-ioam-ipv6-options@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com, martin.h.duke@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (In-situ OAM IPv6 Options) to Proposed Standard The IESG has received a request from the IP Performance Measurement WG (ippm) to consider the following document: - 'In-situ OAM IPv6 Options' 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 2022-07-01. 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) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3529/ |
2022-06-17
|
08 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2022-06-17
|
08 | Martin Duke | Last call was requested |
2022-06-17
|
08 | Martin Duke | Last call announcement was generated |
2022-06-17
|
08 | Martin Duke | Ballot approval text was generated |
2022-06-17
|
08 | Martin Duke | Ballot writeup was generated |
2022-06-17
|
08 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-06-17
|
08 | Martin Duke | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2022-06-16
|
08 | (System) | Removed all action holders (IESG state changed) |
2022-06-16
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-06-16
|
08 | Shwetha Bhandari | New version available: draft-ietf-ippm-ioam-ipv6-options-08.txt |
2022-06-16
|
08 | Shwetha Bhandari | New version accepted (logged-in submitter: Shwetha Bhandari) |
2022-06-16
|
08 | Shwetha Bhandari | Uploaded new revision |
2022-06-01
|
07 | Martin Duke | Changed action holders to Frank Brockners, Shwetha Bhandari |
2022-04-28
|
07 | (System) | Changed action holders to Martin Duke, Frank Brockners, Shwetha Bhandari (IESG state changed) |
2022-04-28
|
07 | Martin Duke | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2022-04-28
|
07 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-04-28
|
07 | Martin Duke | IESG state changed to AD Evaluation from Publication Requested |
2022-04-12
|
07 | Marcus Ihlar | 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? Proposed Standard, this is appropriate since this describes a common deployment option of the IOAM proposed standard. (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: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6 Working Group Summary: To my knowledge the working group process has been fairly smooth and uncontroversial. The document was at first proposed to the 6man wokring group, but there it was decided that it would be more appropriate for ippm to take responsibility for it. Document Quality: The specification has good implementation support, in particular it has been implemented in the Linux kernel. Asside from a few small nits the shepherd has no concerns with the document quality. Personnel: Shepherd: Marcus ihlar Responsible AD: Martin Duke (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. I have reviewed this document as part of the shepherding process. Furthermore, this document has received substantial review as part of the working group process. With the exception from a few small nits this document shoudld be ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, reviews have been recived by ippm participants and 6man participants. (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. No. (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. No particular concerns. (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? The authors have confirmed that, to their knowledge, there are no more IPR declarations other than https://datatracker.ietf.org/ipr/3529/. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure (https://datatracker.ietf.org/ipr/3529/) that references this document, it was done prior to WG adoption and I could not see much discussion about it. (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? There seems to be pretty solid consensus, there's quite a large set of contributors and some good feedback from the 6man wg has been considered. (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.) Not to my knowledge. (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. The ID nits tool produced a single comment about the publication date of the document. Nits found by me: Section 4, paragraph 2 has a reference to section 4 of draft-ietf-ippm-ioam-data-17, this one should probably be to section 5 of that document. Last paragraph of section 4 has a spelling mistake: lenght -> length. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (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 two normative references that are not yet published RFCs are draft-ietf-ippm-ioam-data-17 which is in AUTH48 and draft-ietf-ippm-ioam-direct-export-07 which is under AD evaluation. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (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 (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). This document adds two values to the the Destination Options and Hop-by-Hop Options sub-registry of IPv6 Parameters. (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. Not applicable. (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. Not applicable. (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? Not applicable. |
2022-04-12
|
07 | Marcus Ihlar | Responsible AD changed to Martin Duke |
2022-04-12
|
07 | Marcus Ihlar | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2022-04-12
|
07 | Marcus Ihlar | IESG state changed to Publication Requested from I-D Exists |
2022-04-12
|
07 | Marcus Ihlar | IESG process started in state Publication Requested |
2022-04-12
|
07 | Marcus Ihlar | 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? Proposed Standard, this is appropriate since this describes a common deployment option of the IOAM proposed standard. (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: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6 Working Group Summary: To my knowledge the working group process has been fairly smooth and uncontroversial. The document was at first proposed to the 6man wokring group, but there it was decided that it would be more appropriate for ippm to take responsibility for it. Document Quality: The specification has good implementation support, in particular it has been implemented in the Linux kernel. Asside from a few small nits the shepherd has no concerns with the document quality. Personnel: Shepherd: Marcus ihlar Responsible AD: Martin Duke (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. I have reviewed this document as part of the shepherding process. Furthermore, this document has received substantial review as part of the working group process. With the exception from a few small nits this document shoudld be ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, reviews have been recived by ippm participants and 6man participants. (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. No. (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. No particular concerns. (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? The authors have confirmed that, to their knowledge, there are no more IPR declarations other than https://datatracker.ietf.org/ipr/3529/. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure (https://datatracker.ietf.org/ipr/3529/) that references this document, it was done prior to WG adoption and I could not see much discussion about it. (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? There seems to be pretty solid consensus, there's quite a large set of contributors and some good feedback from the 6man wg has been considered. (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.) Not to my knowledge. (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. The ID nits tool produced a single comment about the publication date of the document. Nits found by me: Section 4, paragraph 2 has a reference to section 4 of draft-ietf-ippm-ioam-data-17, this one should probably be to section 5 of that document. Last paragraph of section 4 has a spelling mistake: lenght -> length. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (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 two normative references that are not yet published RFCs are draft-ietf-ippm-ioam-data-17 which is in AUTH48 and draft-ietf-ippm-ioam-direct-export-07 which is under AD evaluation. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (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 (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). This document adds two values to the the Destination Options and Hop-by-Hop Options sub-registry of IPv6 Parameters. (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. Not applicable. (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. Not applicable. (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? Not applicable. |
2022-03-29
|
07 | Marcus Ihlar | 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? Proposed Standard, this is appropriate since this describes a common deployment option of the IOAM proposed standard. (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: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6 Working Group Summary: To my knowledge the working group process has been fairly smooth and uncontroversial. The document was at first proposed to the 6man wokring group, but there it was decided that it would be more appropriate for ippm to take responsibility for it. Document Quality: The specification has good implementation support, in particular it has been implemented in the Linux kernel. Asside from a few small nits the shepherd has no concerns with the document quality. Personnel: Shepherd: Marcus ihlar Responsible AD: Martin Duke (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. I have reviewed this document as part of the shepherding process. Furthermore, this document has received substantial review as part of the working group process. With the exception from a few small nits this document shoudld be ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, reviews have been recived by ippm participants and 6man participants. (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. No. (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. No particular concerns. (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? Waiting for one of the two authors to respond to this, but the current indication is that there are no more IPR declarations other than https://datatracker.ietf.org/ipr/3529/. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure (https://datatracker.ietf.org/ipr/3529/) that references this document, it was done prior to WG adoption and I could not see much discussion about it. (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? There seems to be pretty solid consensus, there's quite a large set of contributors and some good feedback from the 6man wg has been considered. (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.) Not to my knowledge. (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. The ID nits tool produced a single comment about the publication date of the document. Nits found by me: Section 4, paragraph 2 has a reference to section 4 of draft-ietf-ippm-ioam-data-17, this one should probably be to section 5 of that document. Last paragraph of section 4 has a spelling mistake: lenght -> length. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (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 two normative references that are not yet published RFCs are draft-ietf-ippm-ioam-data-17 which is in AUTH48 and draft-ietf-ippm-ioam-direct-export-07 which is under AD evaluation. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (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 (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). This document adds two values to the the Destination Options and Hop-by-Hop Options sub-registry of IPv6 Parameters. (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. Not applicable. (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. Not applicable. (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? Not applicable. |
2022-03-29
|
07 | Marcus Ihlar | 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? Proposed Standard, this is appropriate since this describes a common deployment option of the IOAM proposed standard. (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: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6 Working Group Summary: To my knowledge the working group process has been fairly smooth and uncontroversial. The document was at first proposed to the 6man wokring group, but there it was decided that it would be more appropriate for ippm to take responsibility for it. Document Quality: The specification has good implementation support, in particular it has been implemented in the Linux kernel. Asside from a few small nits the shepherd has no concerns with the document quality. Personnel: Shepherd: Marcus ihlar Responsible AD: Martin Duke (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. I have reviewed this document as part of the shepherding process. Furthermore, this document has received substantial review as part of the working group process. With the exception from a few small nits this document shoudld be ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, reviews have been recived by ippm participants and 6man participants. (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. No. (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. No particular concerns. (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? Waiting for one of the two authors to respond to this, but the current indication is that there are no more IPR declarations other than https://datatracker.ietf.org/ipr/3529/. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure (https://datatracker.ietf.org/ipr/3529/) that references this document, it was done prior to WG adoption and I could not see much discussion about it. (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? There seems to be pretty solid consensus, there's quite a large set of contributors and some good feedback from the 6man wg has been considered. (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.) Not to my knowledge. (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. The ID nits tool produced a single comment about the publication date of the document. Nits found by me: Section 4 has a reference to section 4 of draft-ietf-ippm-ioam-data-17, this one should probably be to section 5 of that document. Last paragraph of section 4 has a spelling mistake: lenght -> length. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (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 two normative references that are not yet published RFCs are draft-ietf-ippm-ioam-data-17 which is in AUTH48 and draft-ietf-ippm-ioam-direct-export-07 which is under AD evaluation. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (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 (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). This document adds two values to the the Destination Options and Hop-by-Hop Options sub-registry of IPv6 Parameters. (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. Not applicable. (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. Not applicable. (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? Not applicable. |
2022-02-15
|
07 | Marcus Ihlar | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2022-02-08
|
07 | Tommy Pauly | Notification list changed to marcus.ihlar@ericsson.com because the document shepherd was set |
2022-02-08
|
07 | Tommy Pauly | Document shepherd changed to Marcus Ihlar |
2022-02-06
|
07 | Frank Brockners | New version available: draft-ietf-ippm-ioam-ipv6-options-07.txt |
2022-02-06
|
07 | (System) | New version approved |
2022-02-06
|
07 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Shwetha Bhandari |
2022-02-06
|
07 | Frank Brockners | Uploaded new revision |
2022-02-01
|
06 | (System) | Document has expired |
2021-12-17
|
06 | Marcus Ihlar | IETF WG state changed to In WG Last Call from WG Document |
2021-12-17
|
06 | Marcus Ihlar | Changed consensus to Yes from Unknown |
2021-12-17
|
06 | Marcus Ihlar | Intended Status changed to Proposed Standard from None |
2021-07-31
|
06 | Frank Brockners | New version available: draft-ietf-ippm-ioam-ipv6-options-06.txt |
2021-07-31
|
06 | (System) | New version approved |
2021-07-31
|
06 | (System) | Request for posting confirmation emailed to previous authors: Aviv Kfir , Barak Gafni , Carlos Pignataro , Frank Brockners , Hannes Gredler , John Leddy … Request for posting confirmation emailed to previous authors: Aviv Kfir , Barak Gafni , Carlos Pignataro , Frank Brockners , Hannes Gredler , John Leddy , Mark Smith , Mickey Spiegel , Petr Lapukhov , Rajiv Asati , Shwetha Bhandari , Stephen Youell , Suresh Krishnan , Tal Mizrahi , ippm-chairs@ietf.org |
2021-07-31
|
06 | Frank Brockners | Uploaded new revision |
2021-02-21
|
05 | Shwetha Bhandari | New version available: draft-ietf-ippm-ioam-ipv6-options-05.txt |
2021-02-21
|
05 | (System) | New version approved |
2021-02-21
|
05 | (System) | Request for posting confirmation emailed to previous authors: Aviv Kfir , Barak Gafni , Carlos Pignataro , Frank Brockners , Hannes Gredler , John Leddy … Request for posting confirmation emailed to previous authors: Aviv Kfir , Barak Gafni , Carlos Pignataro , Frank Brockners , Hannes Gredler , John Leddy , Mark Smith , Mickey Spiegel , Petr Lapukhov , Rajiv Asati , Shwetha Bhandari , Stephen Youell , Suresh Krishnan , Tal Mizrahi , ippm-chairs@ietf.org |
2021-02-21
|
05 | Shwetha Bhandari | Uploaded new revision |
2020-11-01
|
04 | Frank Brockners | New version available: draft-ietf-ippm-ioam-ipv6-options-04.txt |
2020-11-01
|
04 | (System) | New version approved |
2020-11-01
|
04 | (System) | Request for posting confirmation emailed to previous authors: Mickey Spiegel , Carlos Pignataro , Barak Gafni , Suresh Krishnan , Hannes Gredler , Aviv Kfir … Request for posting confirmation emailed to previous authors: Mickey Spiegel , Carlos Pignataro , Barak Gafni , Suresh Krishnan , Hannes Gredler , Aviv Kfir , Petr Lapukhov , Shwetha Bhandari , John Leddy , Rajiv Asati , ippm-chairs@ietf.org, Stephen Youell , Frank Brockners , Tal Mizrahi , Mark Smith |
2020-11-01
|
04 | Frank Brockners | Uploaded new revision |
2020-09-18
|
03 | Frank Brockners | New version available: draft-ietf-ippm-ioam-ipv6-options-03.txt |
2020-09-18
|
03 | (System) | New version approved |
2020-09-18
|
03 | (System) | Request for posting confirmation emailed to previous authors: Frank Brockners , Stephen Youell , Tal Mizrahi , Barak Gafni , Rajiv Asati , ippm-chairs@ietf.org, … Request for posting confirmation emailed to previous authors: Frank Brockners , Stephen Youell , Tal Mizrahi , Barak Gafni , Rajiv Asati , ippm-chairs@ietf.org, Hannes Gredler , John Leddy , Suresh Krishnan , Aviv Kfir , Petr Lapukhov , Mickey Spiegel , Carlos Pignataro , Shwetha Bhandari |
2020-09-18
|
03 | Frank Brockners | Uploaded new revision |
2020-07-13
|
02 | Shwetha Bhandari | New version available: draft-ietf-ippm-ioam-ipv6-options-02.txt |
2020-07-13
|
02 | (System) | New version approved |
2020-07-13
|
02 | (System) | Request for posting confirmation emailed to previous authors: Barak Gafni , Carlos Pignataro , Stephen Youell , ippm-chairs@ietf.org, Mickey Spiegel , Hannes Gredler , … Request for posting confirmation emailed to previous authors: Barak Gafni , Carlos Pignataro , Stephen Youell , ippm-chairs@ietf.org, Mickey Spiegel , Hannes Gredler , Suresh Krishnan , Frank Brockners , Rajiv Asati , Tal Mizrahi , Petr Lapukhov , John Leddy , Aviv Kfir , Shwetha Bhandari |
2020-07-13
|
02 | Shwetha Bhandari | Uploaded new revision |
2020-03-09
|
01 | Shwetha Bhandari | New version available: draft-ietf-ippm-ioam-ipv6-options-01.txt |
2020-03-09
|
01 | (System) | New version approved |
2020-03-09
|
01 | (System) | Request for posting confirmation emailed to previous authors: John Leddy , Stephen Youell , Carlos Pignataro , Tal Mizrahi , Hannes Gredler , Rajiv Asati … Request for posting confirmation emailed to previous authors: John Leddy , Stephen Youell , Carlos Pignataro , Tal Mizrahi , Hannes Gredler , Rajiv Asati , Mickey Spiegel , ippm-chairs@ietf.org, Frank Brockners , Barak Gafni , Suresh Krishnan , Shwetha Bhandari , Aviv Kfir , Petr Lapukhov |
2020-03-09
|
01 | Shwetha Bhandari | Uploaded new revision |
2019-09-26
|
00 | Tommy Pauly | This document now replaces draft-ioametal-ippm-6man-ioam-ipv6-options instead of None |
2019-09-26
|
00 | Shwetha Bhandari | New version available: draft-ietf-ippm-ioam-ipv6-options-00.txt |
2019-09-26
|
00 | (System) | WG -00 approved |
2019-09-26
|
00 | Shwetha Bhandari | Set submitter to "Shwetha Bhandari ", replaces to draft-ioametal-ippm-6man-ioam-ipv6-options and sent approval email to group chairs: ippm-chairs@ietf.org |
2019-09-26
|
00 | Shwetha Bhandari | Uploaded new revision |