Lars Eggert has entered the following ballot position for
draft-ietf-lsr-ospf-l2bundles-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/



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


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



_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to