Subject: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 30 Nov 2020 08:15:53 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-idr-tunnel-encaps-20: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points, and one generic nit.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
A very generic comment about the abstract that is mainly about RFC 5512. I find
it a little surprising as it describes the protocol that this document
obsoletes... I would have preferred an abstract describing what this document
does w/o citing RFC 5512 (except of course at the end of the abstract).

-- Section 1.4 --

It is a little unclear what "these deficiencies" are ? Perhaps add a reference
to previous section 1.2 ?

-- Section 3 --
Would it be easier for the reader to either have a summary table of all sub-TLV
types or repeat the type code in all sub-section headings?

-- Section 3.2.1 and 3.2.2 --
While the assumption of a 48-bit MAC address is correct in 2020 (barring
FireWire, IEEE 802.5.14), it also limits the usability of this document to a
set of data-link layers.

Should the length of the "Reserved" field be specified ?

-- Section 3.3 --
Should the value of IPv6 Flow Label or any IPv6 extension header (e.g., hop by
hop or destination headers) be specified ?

-- Section 3.6 --
If not mistaken, RFC 8669 is only about SR-MPLS. So, I wonder whether the
authors also think to add a similar feature for SRv6 ?

-- Sections 5 & 12 --
Unsure whether this paragraph is really useful, isn't it implicit ? (I am of
course fine in either case)

== NITS ==

I find the choice of "encapsulation sub-TLV" a poor choice as it can easily be
confused with "encapsulation TLV" (section 2) but I guess the train has left
the station ;-)