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

[Amanda Baber <[e-mail]>]

Hi Murray,

About this question: "In Section 12, we're telling the Designated Experts that an I-D counts as a
specification, even if it is never published as an RFC.  But an I-D can expire.
Are we OK with having an IANA registry with an entry that claims as its
authoritative specification an expired I-D?"

I just want to note that this isn't without precedent. RFC 8447, for example, had us add notes that specifically state "It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc." to TLS registries that use the Specification Required registry. 

Otherwise, in the absence of registry-specific instructions, it's been left up to experts. Many of them don't accept I-Ds, but the experts for the https://www.iana.org/assignments/smi-numbers registries, for example, generally do, depending on the document. 

Amanda

On 1/18/24, 7:17 AM, "iesg on behalf of Murray Kucherawy via Datatracker" <[e-mail] on behalf of [e-mail]> wrote:

    Murray Kucherawy has entered the following ballot position for
    draft-ietf-kitten-krb-spake-preauth-11: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!9QSe7V_EPNdzZYIcKy8Q2tXMvA81tTtRojwyDancKu8Sx1shB0IG3euGWk5ZtO4CLNynzSYB1Y5r2kXbnEDZExU$ [ietf[.]org] 
    for more information about how to handle DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/__;!!PtGJab4!9QSe7V_EPNdzZYIcKy8Q2tXMvA81tTtRojwyDancKu8Sx1shB0IG3euGWk5ZtO4CLNynzSYB1Y5r2kXbTxjEu1A$ [datatracker[.]ietf[.]org]



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    In Section 12, we're telling the Designated Experts that an I-D counts as a
    specification, even if it is never published as an RFC.  But an I-D can expire.
     Are we OK with having an IANA registry with an entry that claims as its
    authoritative specification an expired I-D?

    Section 12.2.2 appears to have four registrations all run together.  Could we
    separate them somehow, either with line breaks or with subsections?

    Section 4.1: Why is this only a SHOULD?  Is it OK if I do something different?

    Section 4.3: Same question.

    ===

    Additional comments from incoming ART AD, Orie Steele:

    9.  Hint for Authentication Sets

    Why MAY and not SHOULD?

    Phrasing around MUST NOT and must only could be clearer, and is possibly the
    reason for the MAYs?

    10.2 Unauthenticated Plaintext

    > Second factor
       types MUST account for this when specifying the semantics of the data
       field.

    It's not clear (to me) how to comply with this MUST, an example of citation
    might help.

    In 10.4

    Several SHOULD's that maybe ought to be MUSTs?

    It would be nice to see clearer recommendations on achieving forward secrecy,
    and on rotating the cookie.