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

[Ben Campbell <[e-mail]>]

Hi,

I am no longer an AD, so my comments are only advisory at this point. But in any case, your responses resolve my comments.

Thanks!

Ben.



> On Nov 14, 2019, at 2:29 AM, Felipe Garrido (fegarrid) <[e-mail]> wrote:
> 
> 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 <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/ <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?
> 
> 
>