In Situ Operations, Administration, and Maintenance (IOAM) Deployment
draft-ietf-ippm-ioam-deployment-05

[Ballot discuss]
# Internet AD comments for draft-ietf-ippm-ioam-deployment-02
CC @ekline

## Discuss

### S7.3

* "A deployment can choose to configure and support one or both of the
  IOAM Trace-Option-Types."

  I don't think this paragraph is quite correct as written, since it's
  theoretically tied to the limitations of the protocols in use in a
  deployment.  Perhaps adding something along the lines:

  "Which options can be supported is not only a function of the
  operator-defined configuration, but may also be limited by protocol
  constraints unique to a given encapsulation layer."

[Ballot comment]
# Internet AD comments for draft-ietf-ippm-ioam-deployment-02
CC @ekline

## Comments

### S7.2

* "Similarly, the sematics of the IOAM-Data-
  Fields, can, do not have to be associated to across different layers."

  This didn't scan correctly for me.  Perhaps you mean:

"Similarly, the semantics of the IOAM-Data-
  Fields, can, but do not have to be associated to cross different layers."

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-ippm-ioam-deployment-02
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus *and* a partial justification of the intended status.

Other thanks to Juan-Carlos Zúñiga, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-ippm-ioam-deployment-02-intdir-telechat-zuniga-2022-12-11/


I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 2

Should there be references to BIER and GRE as references are given for Geneve and others?

### Section 5.4

Why is the GRE encapsulated described in more details than the other encapsulations ? The encapsulation is also an individual draft, what will happen to this document if the individual draft is changed heavily ?

## 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

[Ballot comment]
I concur with the shepherd suggestion that the BCP 14 references can be removed.

Section 2 defines "E2E", "SFC", "SID", and "SR", but this document doesn't use those terms anywhere.

[Ballot discuss]
Thanks for working on this specification.

I have a easy to fix discuss point. It is a bit confusing to see where these IOAM namespace, IOAM laying at section 7 come from. Is this something this document is suggesting to use to easy implementation and deployment? or is this something described in other documents and merely described here. As Section 7 is the main meat of this specification, I would like to discuss if this could be clarified better.

[Ballot comment]
- The last sentence in the abstract has been already noticed as confusing. I would suggest to replace with something like - "this document provides IOAM deployment considerations."

- Section 4.2 : SSSS would need a reference.

[Ballot comment]

        Proof-of-transit uses methods like nested hashing or nested encryption
        of the IOAM data or mechanisms such as Shamir's Secret Sharing Schema
        (SSSS).

is there a draft or RFC reference for SSSS? It seems like a the main example of a
Proof-of-transit as it is the only mechanism named, but it has no informative
reference?

NITS:

        node A is IOAM encapsulating node

Node A is the IOAM .... ?  (more occurances of missing "the" in this section.

        that addes

that adds ?

        A deployment can leverage IOAM profiles is to limit the scope of IOAM features

Doesn't parse, perhaps "is" should be removed?

[Ballot comment]
# GEN AD review of draft-ietf-ippm-ioam-deployment-02

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/A39Rwii1B-f8X3VfnjmdQ2Iz_6k).

## Comments

### "Abstract", paragraph 1
```
    In-situ Operations, Administration, and Maintenance (IOAM) collects
    operational and telemetry information in the packet while the packet
    traverses a path between two points in the network.  This document
    provides a framework for IOAM deployment and discusses best current
    practices.
```
Since this document is not a BCP, it might be better to
rephrase "discusses best current practices" as "gives deployment
guidance" or something like that.

### Section 3, paragraph 4
```
    An "IOAM transit node" updates one or more of the IOAM-Data-Fields.
    If both the Pre-allocated and the Incremental Trace Option-Types are
    present in the packet, each IOAM transit node will update at most one
    of these Option-Types.  A transit node does not add new IOAM-Option-
    Types to a packet, and does not change the IOAM-Data-Fields of an
    IOAM Edge-to-Edge Option-Type.
```
If each node can unilaterally determine which of the two option types
to update, how will the eventual receiver of this information be able
to come to a consistent view of he signaled information, if two
different values are present in a packet?

## 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 1, paragraph 1
```
-    leveraged where mechanisms using e.g.  ICMP do not apply or do not
-                                        ^
+    leveraged where mechanisms using, e.g., ICMP, do not apply or do not
+                                    +    ^    +
```

#### Section 3, paragraph 1
```
-    an IOAM domain, e.g. using for example packet filtering methods.  The
-                              ------------
+    an IOAM domain, e.g., using packet filtering methods.  The
+                        +
```

#### Section 7.2, paragraph 1
```
-    encapsulation mechanisms.  Similarly, the sematics of the IOAM-Data-
+    encapsulation mechanisms.  Similarly, the semantics of the IOAM-Data-
+                                                  +
```

#### Section 7.3, paragraph 1
```
-    is expanded at every IOAM node that addes IOAM-Data-Fields.  "Pre-
-                                          -
```

#### Section 10, paragraph 5
```
-    are subject to IOAM encpasulation and the rate of exported traffic,
-                            -
-    it is possible to cofine the impact of such attacks.
+    are subject to IOAM encapsulation and the rate of exported traffic,
+                          +
+    it is possible to confine the impact of such attacks.
+                        +
```

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Outdated references

Document references `draft-ietf-ippm-ioam-flags`, but that has been published
as `RFC9322`.

Document references `draft-ietf-ippm-ioam-conf-state-07`, but `-10` is the
latest available revision.

Document references `draft-gandhi-spring-ioam-sr-mpls-02`, but `-08` is the
latest available revision.

Document references `draft-ietf-ippm-ioam-direct-export`, but that has been
published as `RFC9326`.

### Grammar/style

#### Section 4.1, paragraph 2
```
s for generic IOAM data include geo-location information (location of the no
                                ^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 6, paragraph 2
```
elds. IOAM-Namespaces support several different uses: o IOAM-Namespaces can
                              ^^^^^^^^^^^^^^^^^
```
Consider using "several".

#### Section 7.1, paragraph 3
```
-Data-Fields in one layer are independent from IOAM-Data-Fields in another l
                              ^^^^^^^^^^^^^^^^
```
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

#### Section 7.1, paragraph 3
```
tionship, in IOAM, layers are independent from each other and don't assume a
                              ^^^^^^^^^^^^^^^^
```
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

#### Section 7.2, paragraph 3
```
ta-Fields does not exceed the MTU of any of the links in the IOAM domain. In
                                  ^^^^^^^^^
```
Consider simply using "of" instead.

#### Section 7.3, paragraph 1
```
tays within the bounds of the MTU of any of the links in the IOAM domain. Th
                                  ^^^^^^^^^
```
Consider simply using "of" instead.

#### Section 7.3, paragraph 1
```
as to ensure that the minimum MTU of any of the links in the IOAM domain is k
                                  ^^^^^^^^^
```
Consider simply using "of" instead.

#### Section 7.6, paragraph 3
```
Proof of Transit Option-Type (Section Section 4.2) is used for verifying the
                              ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 7.6, paragraph 5
```
single LAN, but span multiple inter-connected sites (for example, using an o
                              ^^^^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 8, paragraph 2
```
revent IOAM traffic from leaking outside of the IOAM domain, and prevent IOA
                                ^^^^^^^^^^
```
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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ippm-ioam-deployment-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-11-16):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ippm-ioam-deployment@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, martin.h.duke@gmail.com, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (In-situ OAM Deployment) to Informational RFC


The IESG has received a request from the IP Performance Measurement WG (ippm)
to consider the following document: - 'In-situ OAM Deployment'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-11-16. 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) collects
  operational and telemetry information in the packet while the packet
  traverses a path between two points in the network.  This document
  provides a framework for IOAM deployment and discusses best current
  practices.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-deployment/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document had strong support for adoption as being useful to help explain
IOAM. It didn't see large changes during the ~1 year of WG development, and
the WGLC was supportive, but not as many people chimed in as the adoption call.
However, that is what I would expect for an informational document like this
that didn't require many changes.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals threatened, or discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

IOAM is already implemented and deployed, and this document is informationally
advising deployments.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

IOAM development has occurred primarily within IPPM, with input and reviews
from groups that define the encapsulations that IOAM uses. This document
has had input from people in those other groups, although we did not feel
the need for formal reviews from any other groups or organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I find this document to be clear and a good overview of the IOAM space.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No such issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This was previously marked BCP, but the chairs and AD thought
this made most sense as informational.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I have contacted all the authors about IPR, and they have confirmed that they are
not aware of any IPR related to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors are willing to be authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The only nit seen is:

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
    2119 boilerplate text.

The boilerplate can likely be removed if that is the right approach.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All references other than RFC2119/RFC8174 are (correctly) informational. It's possible
that RFC2119/RFC8174 can be removed.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not applicable

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA impact

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document had strong support for adoption as being useful to help explain
IOAM. It didn't see large changes during the ~1 year of WG development, and
the WGLC was supportive, but not as many people chimed in as the adoption call.
However, that is what I would expect for an informational document like this
that didn't require many changes.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals threatened, or discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

IOAM is already implemented and deployed, and this document is informationally
advising deployments.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

IOAM development has occurred primarily within IPPM, with input and reviews
from groups that define the encapsulations that IOAM uses. This document
has had input from people in those other groups, although we did not feel
the need for formal reviews from any other groups or organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I find this document to be clear and a good overview of the IOAM space.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No such issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This was previously marked BCP, but the chairs and AD thought
this made most sense as informational.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I have contacted all the authors about IPR, and they have confirmed that they are
not aware of any IPR related to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors are willing to be authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The only nit seen is:

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
    2119 boilerplate text.

The boilerplate can likely be removed if that is the right approach.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All references other than RFC2119/RFC8174 are (correctly) informational. It's possible
that RFC2119/RFC8174 can be removed.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Not applicable

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA impact

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/