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

[Eliot Lear <[e-mail]>]

Hi Murray,

I apologize for the late comments.  I agree with your concerns. I would 
add four points:

 1. Given the discussion about the nature of Internet Drafts are taking
    place on a mailing list that anyone can join
    ([e-mail]), this working group should neither
    redefine IANA policy nor the nature of I-Ds.
 2. The ISE is *sometimes *available for this purpose, but not a
    guaranteed documentation path.  An RFC is generally a heavy lift no
    matter the path (which I think is in part the motivation for the
    text), and RFC 8126 makes clear it shouldn't be the only path.  What
    is needed is a stable reference.
 3. Anyone can create a git repo and establish a stable reference that
    should be suitable for IANA.  IMHO that should be preferred over
    encouraging a reference to something that has "draft" right in its name.
 4. Confusion over IANA policy can be introduced if a draft is updated
    and the semantics are changed without any in-path signaling of such,
    leading to interoperability risks.

Therefore, I would suggest to the IESG that the discussion about 
Internet-Drafts be removed from this draft prior to publication.

Eliot

On 20.01.2024 07:39, 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.
>
> 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.
>
> Should we deregister something if it references an I-D that expires?  
> Or maybe it should seek publication via the ISE instead if the WG 
> drops it?  Or something?
>
>     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?
>
>     It's not just Kerberos, but TLS and others, that have used I-Ds as
>     "specifications".
>
>
> This isn't making me feel better.  :-)
>
>     Often what we want is just Expert Review, and sometimes we want both
>     Expert Review _and_ Specification Exists.
>
>
> Check out Section 4.6 of RFC 8126.  "Specification Required" includes 
> a designated expert.
>
>     RFC 2434 doesn't limit
>     allocation policies to the ones it lists, as it terms them "example
>     policies, some of which are in use today", but this registry currently
>     requires only Expert Review.  I believe Expert Review is
>     appropriate for
>     this registry.
>
>
> 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".
>
> -MSK
>
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten