Subject: [Ietf-krb-wg] A proposal from Adrian on the des deprecation registry

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Apr 2012 09:14:56 -0400

IANA's question about whether we should  deprecate code points in the
registry came up during IESG discussion of
draft-ietf-krb-wg-des-die-die-die.
It looks like our discussion is sufficient and we will be able to move
forward with no change if we like.

However, since a specific proposal was made  I'd like to forward it to
the WG in case people start shouting for joy.
we could potentially make the change now if the document doesn't end up
getting approved today and people are very supportive.
Or we could make this with some-numbers-to-iana.

Subject: RE: Adrian Farrel's Discuss on draft-ietf-krb-wg-des-die-die-die-04: (with DISCUSS)
From: "Adrian Farrel" <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>
Cc: "'Sam Hartman'" <[email-masked]>
Date: Thu, 26 Apr 2012 14:06:35 +0100

Hi again,
 
(Apologies for html email, but the layout of the registry columns works better
in a non-proportional font)
 
> >> [1] https://lists.anl.gov/pipermail/ietf-krb-wg/2012-April/010096.html
> >
> > The thread seems to talk about the addition of a column on the intended
> > "required to implement" level. I would, as I said in my previous mail, not
think
> > that appropriate for a registry.
> >
> > "Deprecated" in a registry is a different thing. It describes the use of the
> > code point, not the use of the thing the code point indicates.
> 
> So, I'm now unsure as to what's needed to clear the discuss.
 
I think I am going to clear on the basis that Discussion has been had.
 
> They thought about modifying the registry but decided not to
> add a status column that would say deprecated which is what I
> thought you were asking. I think Sam's mail summarised the (not
> very energetic;-) discussion nicely. [1]
 
Nah, that wasn't what I was suggesting. I was not after such a sweeping change,
and I see why you are nervous of it. I was simply suggesting deprecating the
code points for the deprecated mechanisms.
 
I was thinking that the registry might change as
 
OLD
       etype     encryption type              Reference
         0       reserved                     [RFC6448]
         1       des-cbc-crc                  [RFC3961]
         2       des-cbc-md4                  [RFC3961]
         3       des-cbc-md5                  [RFC3961]
NEW
       etype     encryption type              Reference
         0       reserved                     [RFC6448]
         1       Deprecated                   [RFC3961], [This.I-D]
         2       Deprecated                   [RFC3961], [This.I-D]
         3       Deprecated                   [RFC3961], [This.I-D]
 
Thanks,
Adrian
 
> If there's something else needed can you say what? E.g. if
> you're saying "you must add that column even though the WG
> didn't want to" it'd be better to be clear about that.
> 
> The danger with doing that is as noted in Sam's mail above:
> it'd maybe open a can of worms about the status values to
> put in for a bunch of other things. (Yuk - endless process
> discussions that affect no code, unlike this draft;-)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 26 Apr 2012 12:32:03 -0700

Like Adrian's proposed registry changes.  Don't want to slow down adoption of the draft for it.

On Apr 26, 2012, at 6:14 AM, Sam Hartman wrote:

> From: Adrian Farrel <[email-masked]>
> Date: April 26, 2012 6:06:35 AM PDT
> To: 'Stephen Farrell' <[email-masked]>
> Cc: 'Sam Hartman' <[email-masked]>
> Reply-To: <[email-masked]>
> 
> 
> Hi again,
>  
> (Apologies for html email, but the layout of the registry columns works better in a non-proportional font)
>  
> > > "required to implement" level. I would, as I said in my previous mail, not think
> Nah, that wasn't what I was suggesting. I was not after such a sweeping change, and I see why you are nervous of it. I was simply suggesting deprecating the code points for the deprecated mechanisms.
>  

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Apr 2012 15:53:25 -0400

It looks like there ended up being no open issues at the end of today's
telechat, so I think the question now is whether we want to do this in
the future.  Because it looks like des-die-die-die was approved.

I'd really like to thank Stephen, Love and  Tom for their work on this.  The
approval process for this draft was surprisingly challenging given its
content.  I think Stephen really pushed hard to avoid slowing down.

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Apr 2012 15:30:49 -0500

I would rather not replace deprecated enctypes' names with "deprecated".

I continue to disagree that adding a column to indicate status should
require any additional process.  Adding a column to reflect reality
that has come about through IESG Protocol Action should require no
special process.  RFC3961 does not specify a number of columns, only
tables from which the initial registry contents should be seeded.
Note that IANA could not add arbitrary fields, such as, say, a public
comment field, without approval -- I'm arguing that no process is
required to add a field to reflect an IESG action that is best
represented by the addition of such a field.

However, if a special process were to be insisted on by IANA or the WG
chairs then I propose that WG chair and AD approval during the IANA
phase of RFC editing for this I-D is the right process.  After all,
it's a bug that this I-D says that "there are no IANA Considerations
for this document", and such a bug is to be fixed no later than the
IANA phase of RFC editing.

I move to apply the KISS principle here.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 Apr 2012 17:04:51 -0400

> I would rather not replace deprecated enctypes' names with "deprecated".

Oh, dear, I missed that.  I agree strongly -- it's the enctype that's
deprecated not the number, and the enctype still has a name.  We have
enough problems with people using made-up names for enctypes without
removing the real names from the registry.

> represented by the addition of such a field.

I think you are conflating setting the status column to "deprecated",
which should not require additional process beyond making the decision
to deprecate the enctype (which is an _IETF_ action, not something the
IESG does unilaterally) with making the schema change to introduce the
column.  It seems the schema change might require some amount of
process, if for no other reason than that IANA has tried hard over the
last few years to get itself out of the business of making unilateral
decisions about registries and their contents.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 26 Apr 2012 15:35:14 -0700

I think what you're saying is that no special action or process should be needed to allow the IANA to publish what the current state of affairs is based on the currently issued publications.

+1 on that.

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Apr 2012 18:53:17 -0500

On Thu, Apr 26, 2012 at 4:04 PM, Jeffrey Hutzelman <[email-masked]> wrote:
>> [...]

First, no schema was ever specified for this registry, only initial
content.  That initial content implies a minimal schema, but today's
deprecation of enctypes clearly implies that enctypes have at least a
metadata attribute indicating whether they are deprecated or not.  If
we're going to imply important things to the IANA in one case I don't
see why not in another, unless you want to set an example for others,
in which case we should pull the I-D out of the RFC-Editor queue and
start the process over as punishment for not having dotted every t and
crossed every i.  Mind you, I don't think that pulling the I-D is the
right answer -- if we failed, partly the process failed us by putting
IANA's review so late in the process that we now have no clue what
process to follow to fix a trivial bug.

Let's not compromise the quality of the registry by *refusing* to do
the utterly, painfully, obnoxiously obvious thing that is adding a
status column as a result of... an RFC changing the status of an item
in the registry.  (See how obvious that is?)

If the WG chairs, AD(s), and/or IESG are willing to make up a process
by which to approve the addition of a column to these registries, then
please do so, but do so quickly and make that process light-weight.
The most/slowest process that this triviality should require is a
consensus call on the KRB-WG list + AD approval.

(If there were disagreement w.r.t a status column for any reason other
than the process for adding that column being unclear, then we'd have
a substantive lack of consensus requiring abandonment of that proposal
or more process to make progress.  But that's not the situation.)

Nico

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Apr 2012 09:09:18 -0400

If the registry update can be made without process, the person who can
make it Ken Raeburn, the expert for that registry.

Ken, you should feel free to make your own determination about whether
1) you want to act, 2) you have any community support you feel you
need. And if you choose to act see if IANA would be willing to add a
status column.  I have no idea how they would respond to a request from
an expert to do that.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Apr 2012 22:16:47 +0100

> removing the real names from the registry.

Hi.

This is a perfectly valid view.

To be clear, you are deprecating the use of the mechanism, but if someone wants to use it, you want to make sure there is a clear code point available so that they can indicate which deprecated mechanism they are using.

Cheers,
Adrian