Re: [kitten] Murray Kucherawy's No Objection on draft-ietf-kitten-krb-spake-preauth-11: (with COMMENT)

[Nico Williams <[e-mail]>]

On Fri, Jan 19, 2024 at 10:39:32PM -0800, Murray S. Kucherawy wrote:
> On Thu, Jan 18, 2024 at 9:05 PM Nico Williams <[e-mail]> wrote:
> > I-Ds expire, yes, but they are not deleted, neither from the Internet
> > nor from the IETF I-D archive.  I-Ds are versioned, and each version is
> > "stable".  I believe an I-D counts as "specification exists" under RFC
> > 2434.
> 
> RFC 2434 was obsoleted a long time ago, as was its successor.  RFC 8126 is
> current.

Yes, but none of this changed materially.

> If I'm an implementer following a link from an IANA registration to an I-D,
> but then there's a big colorful warning that the I-D is expired, wouldn't
> it be reasonable for me to believe that the registration, the document, or
> both are no longer valid?  This seems really strange to me.  I would expect
> to find a link to something current.

What that situation would mean is this: the registration is valid, the
I-D is expired, and you have to go figure out whether the registered
elements are in use in the wild.  Some of the registrations in that
registry don't even have any specification, so the ones for which an I-D
is listed are a lot easier for implementers to understand that the ones
for which an I-D is not listed.

But this registry is Expert Review, which means NOT EVEN any
specification is needed, not even an expired I-D.  Would you rather that
IANA delete the reference to the expired I-D and make things even harder
for implementers?  Surely not!

> Should we deregister something if it references an I-D that expires?  Or

Oh.  You want the registration removed.  But if the registration didn't
have a specification then that would be ok?

If you want to break the IETF and make it irrelevant then by all means
do just this.  Write an I-D directing IANA to do this, get it published,
then have IANA do this.  Even better, forbid new allocations w/o RFCs.
Then watch camping and collisions happen.  Fortunately you will never
obtain IETF consensus for this.

Sometimes I-Ds don't progress but their implementations remain in use.
What can you do about that?  I don't know.  But everything you've
proposed would make things worse, not better.

> maybe it should seek publication via the ISE instead if the WG drops it?

You can't make the IETF publish RFCs when there's no energy to do it.

Someone has to pay the salaries of the authors and editors and reviewers
and shepherds and ADs who will push a semi-abandoned I-D across the
finish line.  There is also the opportunity cost of not having them do
something more productive.

> Or something?

Sometimes there's nothing good to be done.

The cost of "stale" registrations in large namespaces is near zero.
Leave it be.

> > Many Internet protocols require IANA registry allocations prior to RFC
> > publication for good reasons:
> >
> >  - publishing an RFC just to obtain an allocation for a work-in-progress
> >    is impractical
> >
> >  - not having allocations prior to publication greatly complicates
> >    testing and soaking
> >
> >  - private use namespaces do work, but then when upon publication
> >    _different_ allocations are obtained there then arises an upgrade
> >    problem in the field that may not be trivial to manage
> 
> There's another practice I've seen commonly used: Allow registrations to be
> "provisional", which are First Come First Served so it's trivial to get an
> experimental code point or reserve one, and then allow them to become
> "permanent" with Specification Required or similar.  Would that work here?

No, it wouldn't.  Again, once the document gets published as an RFC you
(right?) would have the IANA allocate NEW non-provisional code points,
and then we would have a migration problem, with large attendant costs.
Do you want to force pointless, unnecessary costs on the industry?

> > It's not just Kerberos, but TLS and others, that have used I-Ds as
> > "specifications".
> 
> This isn't making me feel better.  :-)

It should absolutely give you pause, yes.  Chesterton's fence and all
that.  Before you change something that has been so for decades, and
which has been revised in that time, maybe you ought to educate yourself
on how it got to be that way and think about how the IETF would function
with the changes you have in mind.

> I don't think I'm disputing the registration policy you've chosen.  I'm
> disputing whether we should consider an I-D to be "stable".

They don't get removed from the archive.  Therefore they are "stable".

"Expired" doesn't mean "gone", "deleted".  It means that if you want to
be able to discuss the I-D productively in a WG or in the IETF as a
whole, then you need to submit a new version.  This is wise: a number of
things may have changed that require changes to the I-D in order to
progress it, and making the authors edit it and resubmit it is a good
idea.

Nico
--