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

From: John Scudder <[email-masked]>
Date: Wed, 2 Dec 2020 20:24:25 +0000

Hi Roman,

Thanks to you and Scott for the review. My comments in line below.

> On Nov 30, 2020, at 3:55 PM, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!SDO6amF-195w2tACTwBncPxZpEwE3lYKshrE25ln2IlWuMo7eyz3ZCHi-_XmfQ$
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/__;!!NEt6yMaO-gk!SDO6amF-195w2tACTwBncPxZpEwE3lYKshrE25ln2IlWuMo7eyz3ZCGbyG-DkQ$
> 
> 
> 
> ----------------------------------------------------------------------
> 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).

Right, see my reply to Martin — this was an error, fixed in the forthcoming version 21.

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

Adopted, but as a SHOULD instead of a MUST — I don’t think we want to absolutely preclude people experimenting with promiscuous Internet-wide tunneling if they really want to. 

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

British vs. American spellings, my nemesis. Fixed.

> ** 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://urldefense.com/v3/__https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml*tunnel-types__;Iw!!NEt6yMaO-gk!SDO6amF-195w2tACTwBncPxZpEwE3lYKshrE25ln2IlWuMo7eyz3ZCGd89XW4g$ ).
> I don’t see such a column, or is the intend simply to update the Reference
> column to this document?

(Already addressed.)

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

Thanks, done.

—John

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 3 Dec 2020 03:55:30 +0000

Hi John!

> -----Original Message-----
> From: John Scudder <[email-masked]>
> Sent: Wednesday, December 2, 2020 3:24 PM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; idr-
> [email-masked]; idr@ietf. org <[email-masked]>; Alvaro Retana
> <[email-masked]>; Hares Susan <[email-masked]>
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-idr-tunnel-encaps-20:
> (with COMMENT)
> 
> Hi Roman,
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discus
> > s-criteria.html__;!!NEt6yMaO-gk!SDO6amF-
> 195w2tACTwBncPxZpEwE3lYKshrE25
> > ln2IlWuMo7eyz3ZCHi-_XmfQ$ for more information about IESG DISCUSS and
> > COMMENT positions.
> >
> >
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> > f-idr-tunnel-encaps/__;!!NEt6yMaO-gk!SDO6amF-
> 195w2tACTwBncPxZpEwE3lYKs
> > hrE25ln2IlWuMo7eyz3ZCGbyG-DkQ$
> >
> >
> >
> > ** 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).
> 

Thanks.

> > ** Section 11.  Please use normative language on the applicability
> > text restricting use to a single administrative domain.
> >
> > OLD
> > well-defined scope such as a set of Autonomous Systems that belong to
> > a single administrative entity.
> 
> Adopted, but as a SHOULD instead of a MUST — I don’t think we want to
> absolutely preclude people experimenting with promiscuous Internet-wide
> tunneling if they really want to.

This gives me a bit of pause.  I read the current text of "well-defined scope" as equivalent to a MUST which is why I noted this as a simple COMMENT.  I shouldn't have assumed.  If the intent is a SHOULD, then providing that clarity with normative language continues to be helpful.  However, as a SHOULD, the current security considerations need to be bolstered to cover the cases where Internet wide tunneling is happening (i.e., outside of the well scoped domain).

> British vs. American spellings, my nemesis. Fixed.

Ooops.  I was faithfully reporting what my US-English configured reader flagged without giving further consideration.  My mistake.

> > ** 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://urldefense.com/v3/__https://www.iana.org/assignments/bgp-
> parameters/bgp-parameters.xhtml*tunnel-types__;Iw!!NEt6yMaO-
> gk!SDO6amF-
> 195w2tACTwBncPxZpEwE3lYKshrE25ln2IlWuMo7eyz3ZCGd89XW4g$ ).
> > I don’t see such a column, or is the intend simply to update the
> > Reference column to this document?
> 
> (Already addressed.)
> 
> > "hijacking" of traffic (insertion of an undesired node in the path
> > allowing for inspection or modification of traffic, or avoidance of
> > security controls)

Thanks.

Roman

---

From: John Scudder <[email-masked]>
Date: Thu, 3 Dec 2020 21:43:45 +0000

On Dec 2, 2020, at 10:55 PM, Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:

Not at all — I’m pretty sure the RFC Editor’s style guidelines call for U.S. English spellings, so you were correct.

Thanks,

—John