Advertising Layer 2 Bundle Member Link Attributes in OSPF
draft-ietf-lsr-ospf-l2bundles-10

[Ballot comment]
When the L2 Bundle Member Attributes TLV for BGP-LS was specified in rfc9085, the OSPF functionality (in this document) was not defined.

It would be great if this document formally Updated rfc9085 to indicate that the information for the L2 Bundle Member Attributes TLV can also be derived from the L2 Bundle Member Attributes sub-TLV.

[Ballot comment]
# GEN AD review of draft-ietf-lsr-ospf-l2bundles-06

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/IqLhVi63YKAt6GINPOKUQ0sGt3g).

## 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 2, paragraph 3
```
-    assymetric for an OSPF link depending on the underlying layer 2
-      -
+    asymmetric for an OSPF link depending on the underlying layer 2
+      +
```

### Grammar/style

#### Section 2, paragraph 2
```
member link is operationally up. Therefore advertisements of member links MU
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 2, paragraph 19
```
which the OSPF protocol operates. Therefore the security considerations of th
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

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

[Ballot comment]
Thank you to Russ Mundy for the SECDIR review.

I support Lars Eggert DISCUSS position.  It would be clearer if the the Y/N status indicated by Figure 2 were document via an additional column in the https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#extended-link-tlv-sub-tlvs registry.  Same observation for Y/N/X in Figure 3 and https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#extended-lsa-sub-tlvs.

[Ballot comment]
Hi,

I support Lars's discuss.

I don't really object to publishing this document, although I don't really like the fact that the LAG member information that is being propagated isn't of any relevance to OSPF routing itself, and OSPF is being used only as a generic information propagation mechanism.  However, I acknowledge that horse has probably bolted long ago.

One point that is not clear to me, is the configuration/management of this feature:  Is the expectation that OSPF implementations that support this RFC would automatically propagate bundle member information? Or would this be disabled by default and need to be enabled through configuration?  If there is configuration associated with this feature then would it be part of a updated version of the standard OSPF YANG model, or is it via YANG module augmentation to the base OSPF YANG module?  If this is configurable then having an informational reference to how/where this OSPF feature can be configured would likely be helpful.

Regards,
Rob

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-lsr-ospf-l2bundles-06
CC @evyncke

Thank you for the work put into this document: it is short, clear, and will be useful.

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

Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. A follow up on the Ericsson IPR would be welcome though if there is any update.

As a side note, yet another definition for the overloaded "SID" ;-)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### IEEE802.1AX as informative ?

The only occurence of IEEE802.1AX appears to me as informative: ` for instance a Link Aggregation Group (LAG) [IEEE802.1AX]`
=> suggest to change the reference type to informative rather than normative.

### Section 2

```
  ... Therefore advertisements of member links MUST NOT
  be done when the member link becomes operationally down or it is no
  longer a member of the identified L2 bundle.
```

OTOH, if the information is for an external party (e.g., a controler), having information of an operationally-down link could be useful. Are the authors sure that this would never be used ?

### Section 2, length field

`Length: Variable.` while it is probably obvious, it would probably not hurt to specify the units and what is included.

### Section 2, extensibility

Should there be some text on how to decide applicable/non-applicable for any new link attribute TLV that could be added in the coming years ?

## 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 discuss]
# GEN AD review of draft-ietf-lsr-ospf-l2bundles-06

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/IqLhVi63YKAt6GINPOKUQ0sGt3g).

I'm raising Paul's review comment as a DISCUSS:
```
2) MINOR: Section 2: Normative requirements on future documents

While I don't fully understand all the document dependencies, the following normative requirement:

  ... Specifications that introduce new sub-TLVs of the Extended Link
  TLV MUST indicate their applicability for the L2 Bundle Member
  Attributes Sub-TLV.  An implementation MUST ignore any sub-TLVs
  received that are not applicable in the context of the L2 Bundle
  Member Attribute Sub-TLV.

looks to me like it may be imposing requirements on future work that may not itself be aware of or normatively linked to this document. The registry in question is defined only by RFC7684. Figure 2 further supports this point by effectively revising the format for the registry, adding an additional column.

I suggest it would be appropriate to formally update the registry to reference this document to impose requirements on future registrations, and add a column indicating applicability in the context of the L2 Bundle Member Attribute Sub-TLV.

The same logic applies to Figure 3 and the IANA OSPFv3 Extended-LSA Sub-TLVs registry. I suggest the same sort of fix for it.
```

[Ballot comment]
## 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 2, paragraph 3
```
-    assymetric for an OSPF link depending on the underlying layer 2
-      -
+    asymmetric for an OSPF link depending on the underlying layer 2
+      +
```

### Grammar/style

#### Section 2, paragraph 2
```
member link is operationally up. Therefore advertisements of member links MU
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 2, paragraph 19
```
which the OSPF protocol operates. Therefore the security considerations of th
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

## 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 completed its review of draft-ietf-lsr-ospf-l2bundles-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the OSPFv2 Extended Link TLV Sub-TLVs registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

https://www.iana.org/assignments/ospfv2-parameters/

the early registration for:

Value: 24
Description: L2 Bundle Member Attributes

will be made permanent and its reference will be changed to [ RFC-to-be ].

Second, in the OSPFv3 Extended-LSA Sub-TLVs registry on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

https://www.iana.org/assignments/ospfv3-parameters/

the early registration for:

Value: 29
Description: L2 Bundle Member Attributes

will be made permanent and its reference will be changed to [ RFC-to-be ].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

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-09-29):

From: The IESG
To: IETF-Announce
CC: acee@cisco.com, chopps@chopps.org, draft-ietf-lsr-ospf-l2bundles@ietf.org, jgs@juniper.net, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Advertising Layer 2 Bundle Member Link Attributes in OSPF) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Advertising Layer 2 Bundle Member Link
Attributes in OSPF'
  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-09-29. 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


  There are deployments where the Layer 3 (L3) interface on which OSPF
  operates is a Layer 2 (L2) interface bundle.  Existing OSPF
  advertisements only support advertising link attributes of the Layer
  3 interface.  If entities external to OSPF wish to control traffic
  flows on the individual physical links which comprise the Layer 2
  interface bundle, link attribute information for the bundle members
  is required.

  This document defines the protocol extensions for OSPF to advertise
  the link attributes of L2 bundle members.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/



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

# Document Shepherd Writeup

*This version is dated 8 April 2023.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup 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], and informally. You will need the cooperation of
authors 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?

This document is definitely needed analogous to RFC 8668. Given that it is a
protocol maintenance document, it has not generated a lot of excitement in the
LSR WG.

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

No controversy over any points.

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.

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)?

None to date.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Stewart Bryant provided a Routing Directorate review and agreed the document
is ready for publication.

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.

N/A

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]?
N/A

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.
N/A

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

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

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

Proposed Standard. This is required since new OSPF Sub-TLV code points and
encoding have been defined.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

Yes. Need one follow-up from Ericsson which has disclosed IPR on the analogous IS-IS
document, RFC 8668.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Yes.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

None.

15. Should any informative references be normative or vice-versa?

No.

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

There is one IEEE normative reference.

IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation
IEEE Std 802.1AX-2020 (Revision of IEEE Std 802.1AX-2014), January 30th, 2020

However, it is available via the IEEE Get Program.

https://ieeexplore.ieee.org/Xplorehelp/subscriptions-and-open-access/ieee-get-program


17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.
No.


18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?
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.

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

I have reviewed and corrected the names of the two registries.

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

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

No new registries.

# Document Shepherd Writeup

*This version is dated 8 April 2023.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup 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], and informally. You will need the cooperation of
authors 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?

This document is definitely needed analogous to RFC 8668. Given that it is a
protocol maintenance document, it has not generated a lot of excitement in the
LSR WG.

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

No controversy over any points.

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.

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)?

None to date.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Routing Directorate Review Requested.

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.

N/A

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]?
N/A

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.
N/A

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

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

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

Proposed Standard. This is required since new OSPF Sub-TLV code points and
encoding have been defined.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

Yes. Need one follow-up from Ericsson which has disclosed IPR on the analogous IS-IS
document, RFC 8668.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Yes.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

None.

15. Should any informative references be normative or vice-versa?

No.

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

              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Local and Metropolitan Area Networks - Link
              Aggregation.", Nov 2008.

    IEEE documents are not freely available but most companies have procured access.
    Free access to IEEE documents is outside the scope of the Document Shepherd, LSR WG,
    and IETF itself.


17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.
No.


18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?
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.

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

I have reviewed and corrected the names of the two registries.

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

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

No new registries.

# Document Shepherd Writeup

*This version is dated 8 April 2023.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup 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], and informally. You will need the cooperation of
authors 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?

This document is definitely needed analogous to RFC 8668. Given that it is a
protocol maintenance document, it has not generated a lot of excitement in the
LSR WG.

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

No controversy over any points.

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.

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)?

None to date.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Routing Directorate Review Requested.

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.

N/A

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]?
N/A

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.
N/A

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

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

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

Proposed Standard. This is required since new OSPF Sub-TLV code points and
encoding have been defined.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

Yes. Need one follow-up from Ericsson which has disclosed IPR on the analogous IS-IS
document, RFC 8668.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Yes.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

None.

15. Should any informative references be normative or vice-versa?

No.

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

              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Local and Metropolitan Area Networks - Link
              Aggregation.", Nov 2008.

    IEEE documents are not freely available but most companies have procured access.
    Free access to IEEE documents is outside the scope of the Document Shepherd, LSR WG,
    and IETF itself.


17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.
No.


18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?
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.

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

I have reviewed and corrected the names of the two registries.

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

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

No new registries.

# Document Shepherd Writeup

*This version is dated 8 April 2023.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup 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], and informally. You will need the cooperation of
authors 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?

This document is definitely needed analogous to RFC 8668. Given that it is a
protocol maintenance document, it has not generated a lot of excitement in the
LSR WG.

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

No controversy over any points.

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.

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)?

None to date.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Routing Directorate Review Requested.

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.

N/A

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]?
N/A

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.
N/A

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

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

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

Proposed Standard. This is required since new OSPF Sub-TLV code points and
encoding have been defined.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

Yes. Need one follow-up from Ericsson which has disclosed IPR on the analogous IS-IS
document, RFC 8668.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Yes.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

None.

15. Should any informative references be normative or vice-versa?

No.

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

              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Local and Metropolitan Area Networks - Link
              Aggregation.", Nov 2008.

    IEEE documents are not freely available but most companies have procured access.
    As document shepherd, it is certainly not my job to make these documents
    available. 


17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.
No.


18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?
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.

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

I have reviewed and corrected the names of the two registries.

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

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

No new registries.