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

["Felipe Garrido (fegarrid)" <[e-mail]>]

Hi Ben,

Responses are in-line  and updated in the latest draft. Let me know if they address your COMMENTS.

Thanks,
-Felipe



From: Ben Campbell <[e-mail]<mailto:[e-mail]>>
Subject: Ben Campbell's No Objection on draft-ietf-tram-stun-pmtud-10: (with COMMENT)
Date: September 26, 2018 at 3:33:30 PM EDT
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[e-mail]>>, Gonzalo Camarillo <[e-mail]<mailto:[e-mail]>>, Tolga Asveren <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>

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.

[FG] This was addressed in an earlier draft.


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?
[FG] Updated wording.
“This section is meant to be informative only and is not intended as a substitute for…”

§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?
[FG] Yes, and this is noted in later sections. Added additional wording in this section.
“Both endpoints MAY behave as a client and a server to achieve bi-directional path discovery.”

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

[FG]  Yes, this is new for PMTUD.

§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?

[FG] Yes, do you see an issue with the statement?