[Idr] Roman Danyliw's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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 to Scott Kelly for performing the SECDIR review.

** Section 1.5.  Per “Because RFC 8365 depends on RFC 5640, it is similarly
obsoleted.”, this seems inconsistent with the meta-data header in the document
(as RFC8365 isn’t obsoleted).

** Section 11.  Please use normative language on the applicability text
restricting use to a single administrative domain.

OLD
However, it is intended that the Tunnel Encapsulation
   attribute be used only within a well-defined scope, e.g., within a
   set of Autonomous Systems that belong to a single administrative
   entity.

NEW (or something like this)

However, the Tunnel Encapsulation attribute MUST only be used within a
well-defined scope such as a set of Autonomous Systems that belong to a single
administrative entity.

** Section 12.  Typo. s/tunnelling/tunneling/

** Section 14.2.  Per “Specifically, the following code points should be marked
as deprecated”, how does one mark code points as deprecated in the “BGP Tunnel
Encapsulation Attribute Tunnel Types” registry
(https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types).
 I don’t see such a column, or is the intend simply to update the Reference
column to this document?

** Section 15.  Clarifying text
OLD
"hijacking" of traffic (insertion of
   an undesired node in the path)

NEW
"hijacking" of traffic (insertion of an undesired node in the path allowing for
inspection or modification of traffic, or avoidance of security controls)