Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 Dec 2018 18:20:07 -0600

Hi, Simon,

On Fri, Nov 23, 2018 at 7:27 AM Simon Perreault <[email-masked]>
wrote:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This seems like an interesting technique that warrants collection of
> operational
> experience.
>
> >From a process perspective, I think we have a bit of an issue, unless I've
> overlooked something relevant. This is proposed as a Standards-Track
> document,
> but it relies on the use of the PADDING attribute defined in RFC 5780. RFC
> 5780 is Experimental, so this is a formal downref. And RFC 5780 does not
> appear in the downref registry [1], nor did the IETF last call [2] include
> a
> request that the IETF community consider allowing such a refernce.
>
> >From a practical perspective, the mechanism described in this document
> seems
> like the kind of thing that it would be useful to gather operational
> experience
> with prior to putting it on the standards track. I have some operational
> concerns (described below) that I think could be either proven out or
> dispelled
> by experimental deployment of the technology.
>
> My recommendation is to recategorize this mechanism as experimental,
> adding some
> text about the desire to gather operational experience.
>
> For avoidance of doubt: My DISCUSS is only on the process issue, and I'll
> happily clear regardless of how this issue is rationalized (e.g., either by
> running IETF last call again, by reclassifying this mechanism as
> experimental,
> or perhaps some novel solution that I may not have thought of). Everything
> else is merely a recommendation.
>
>
>
> I don't think I've seen a specific response to Adam's point here, which I
> believe is that one of (at least) three things should happen -
>
>
>
> - a second Last Call, explicitly calling out this downref, OR
>
>
>
> - approval as an Experimental RFC, which makes the downref issue go away,
> OR
>
>
>
> - (and this didn't happen in this thread, but in some conversation, I
> remember that) Adam wondered if reusing the PADDING attribute was the right
> thing to do (and that was a question, not a concern, but relevant here,
> since if this document defined its own attribute, the downref would also go
> away).
>
>
>
> Any thoughts on this?
>
>
>
> Spencer, Adam,
>
>
>
> I see an easy fourth option:
>
>
>
> - Pull the definition of PADDING into this document. Declare that we've
> gathered sufficient experience with PADDING that it now warrants being
> elevated to Standards Track. That is, it's been proven to work.
>

This is plausible. It solves the first-order problem.

I note that RFC 5780 defined a number of new attributes. Is pulling PADDING
forward the right thing to do, or are there others that would also qualify
(so, perhaps a status change for RFC 5780)?

I don't have an opinion about this, but I should ask.

Thanks,

Spencer

> I’m fine with whatever, for the record.
>
>
>
> Simon
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 13 Dec 2018 13:11:58 +0000

- Pull the definition of PADDING into this document. Declare that we've gathered sufficient experience with PADDING that it now warrants being elevated to Standards Track. That is, it's been proven to work.

I note that RFC 5780 defined a number of new attributes. Is pulling PADDING forward the right thing to do, or are there others that would also qualify (so, perhaps a status change for RFC 5780)?

I don’t think the others have been implemented much, so that’s why I think only pulling PADDING makes sense. If I remember correctly, I only implemented PADDING in Numb (I don’t have access to the source code anymore so can’t be sure).

Anyone else with an opinion?

Simon

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 13 Dec 2018 08:27:26 -0600

Hi, Simon,

On Thu, Dec 13, 2018 at 7:12 AM Simon Perreault <[email-masked]>
wrote:

> I note that RFC 5780 defined a number of new attributes. Is pulling
> PADDING forward the right thing to do, or are there others that would also
> qualify (so, perhaps a status change for RFC 5780)?
>
>
>
> I don’t think the others have been implemented much, so that’s why I think
> only pulling PADDING makes sense. If I remember correctly, I only
> implemented PADDING in Numb (I don’t have access to the source code anymore
> so can’t be sure).
>
>
>

That's helpful information.

We should wait for anyone else with information to weigh in, but if it's
correct that the other experimental attributes haven't been implemented and
deployed in a way that would provide guidance for standards-track use, I
think defining PADDING in this document makes more sense to me than adding
a downref to an experimental RFC that we wouldn't consider if the reference
was using anything except PADDING.

Thanks,

Spencer