Re: [Teas] Lars Eggert's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)

["Les Ginsberg (ginsberg)" <[e-mail]>]

Lars -

Thanx for the review.
Please see inline.

> -----Original Message-----
> From: Lars Eggert via Datatracker <[e-mail]>
> Sent: Wednesday, September 21, 2022 7:00 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Lars Eggert's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with
> COMMENT)
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-lsr-isis-rfc5316bis-04: No Objection
> 
> 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-isis-rfc5316bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # GEN AD review of draft-ietf-lsr-isis-rfc5316bis-04
> 
> CC @larseggert
> 
> ## Comments
> 
> ### Section 3.1, paragraph 2
> ```
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Router ID                                     (4 octets)    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   default metric                              | (3 octets)
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Flags     |                                 (1 octet)
>      +-+-+-+-+-+-+-+-+
>      |sub-TLVs length|                                 (1 octet)
>      +-+-+-+-+-+-+-+-+-+-+-+-
>      | sub-TLVs ...                                    (0-246 octets)
>      +-+-+-+-+-+-+-+-+-+-+-+-
> ```
> It's somewhat unusual to have a header diagram that doesn't fill its
> rows and uses that space to instead define the field length for a
> second time (it's already defined by the horizontal space used,
> which is why there is bit count at the top.)
> 
[LES:] The current format was introduced in V2 at the suggestion of one of the WG members.
Each field type is on a separate line - which I think makes for a clear definition. It may not be what you are used to seeing - but as the point of a diagram is to ensure that the format of the encoded TLV is unambiguous I think we are in good shape here.
I would like to leave this as is.

> ### Section 3.3.1, paragraph 4
> ```
>      The remote AS number field has 4 octets.  When only 2 octets are used
>      for the AS number, the left (high-order) 2 octets MUST be set to 0.
>      The remote AS number sub-TLV MUST be included when a router
>      advertises an inter-AS TE link.
> ```
> Would the higher-order octets not be zero anyway if the value is <= 0xffff?

[LES:] You are right, of course, but the current language eliminates any ambiguity that might arise if someone were to think that we only intended to encode as many octets as the AS number has and opted to 0 fill - which of course is not what we are doing.


> 
> ### Section 3.3.4, paragraph 4
> ```
>      If the originating node does not support IPv4, the IPv6 Local ASBR ID
>      sub-TLV MUST be present in the inter-AS reachability TLV.  Inter-AS
>      reachability TLVs which have a Router ID of 0.0.0.0 and do NOT have
>      the IPv6 Local ASBR ID sub-TLV present MUST be ignored.
> ```
> NOT is not an RFC2119 term.
> 
[LES:] Fixed.

> ## 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.
> 
> ### Grammar/style
> 
> #### Section 5, paragraph 5
> ```
>  this document. No additional acknowledgments are made for the new
> version (
>                               ^^^^^^^^^^^^^^^
> ```
> Do not mix variants of the same word ("acknowledgment" and
> "acknowledgement")
> within a single text.

[LES:] I have deleted the entire sentence.

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