Subject: [tram] Ben Campbell's No Objection on draft-ietf-tram-stun-pmtud-10: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Sep 2018 12:33:30 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-tram-stun-pmtud-10: 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-tram-stun-pmtud/

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

I support Adam's DISCUSS. I will go a bit further to say that, even if a new
IETF LC occurs, I would be skeptical that the dependency on PADDING in a
standards track protocol is appropriate unless people are willing to argue that
RFC 5780 has become mature enough that it could reasonably be promoted to
standards track.

Another alternative might be to re-describe PADDING in this draft, as it is
used in the context of the draft. I don't normally love that sort of
duplication, but it might be appropriate here.

Other comments:

§2: "It is not intended as a replacement for [RFC4821]": I find this comment
confusing. Are other sections in the document intended to replace some or all
of 4821?

§4: "The probing mechanism is used to discover the Path MTU in one direction
only...": Can this mechanism not be used bidirectionally, with reciprocal
client-server roles?

§4.1.2: "The server MUST add the FINGERPRINT attribute...": Is this a new
requirement for PMTUD, or a generic STUN requirement? If the latter, it should
not be stated normatively. (Same comment for §4.2.1)

§4.2.1: "If the authentication mechanism permits it, then the Indication MUST
be authenticated": Is that intended to imply it's okay to use authentication
mechanisms that don't allow this?

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Sep 2018 15:48:38 -0500

> RFC 5780 has become mature enough that it could reasonably be promoted to

To be clear, I agree with this sentiment, which is a part of why I 
suggested the STUN PMTUD mechanism be experimental.

> duplication, but it might be appropriate here.

If we go down the path of defining an attribute in this document, I 
would suggest that the WG consider using a new TLV. The original purpose 
of PADDING was to force fragmentation. This document is using it for a 
somewhat different purpose.

/a