Subject: Re: [tcpm] Alissa Cooper's No Objection on draft-ietf-tcpm-undeployed-03: (with COMMENT)

From: Wesley Eddy <[email-masked]>
Date: Wed, 20 Jan 2016 14:39:03 -0500

In this case, the implementation wound up deployed in the Linux kernel 
using that experimental codepoint, which then made it difficult for 
others to use the experimental codepoint.

The ultimate conclusion of this (and similar episodes) was RFC 6994.

On 1/20/2016 2:04 PM, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-tcpm-undeployed-03: 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-tcpm-undeployed/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Regarding RFC 6013, wouldn't implementations of an experimental spec be
> expected to use experimental code points? It seems to me like the last
> two bullets of explanation would be sufficient without the first one.
>
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Jan 2016 16:25:06 -0800

Agreed- to be more clear, the problem of RFC 6013 is not using these
codepoints is restricted in RFC4727, Sec. 1:

   It is not appropriate to simply select one of
   these values and hard code it into a system.

RFC3692 has even more direct discussion:

   Values reserved for experimental use are never
   to be made permanent; permanent assignments should be obtained
   through standard processes.  As described above, experimental numbers
   are intended for experimentation and testing and are not intended for
   wide or general deployments.

   When protocols that use experimental numbers are included in
   products, the shipping versions of the products must disable
   recognition of protocol experimental numbers by default -- that is,
   the end user of the product must explicitly "turn on" the
   experimental protocol functionality.  In most cases, a product
   implementation must require the end user to configure the value
   explicitly prior to enabling its usage.  Should a product not have a
   user interface for such end user configuration, the product must
   require explicit re-programming (e.g., a special firmware download,
   or installation of a feature card) to configure the experimental
   number(s) of the protocol(s) implicitly.

I'm not sure if it would be useful to include some of this with the
first bullet, but that's the context, FYI.

Joe

On 1/20/2016 11:39 AM, Wesley Eddy wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 20 Jan 2016 11:04:53 -0800

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 20 Jan 2016 11:44:17 -0800

> On Jan 20, 2016, at 11:39 AM, Wesley Eddy <[email-masked]> wrote:
> 
> In this case, the implementation wound up deployed in the Linux kernel using that experimental codepoint, which then made it difficult for others to use the experimental code point.

Ah, I see. That is slightly different from what the text says. I think it could help to clarify, but it’s not a big deal either way.

Alissa