Re: BCP97bis and Informational-as-Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Russ Housley <housley@xxxxxxxxxxxx> wrote:
    > I have on concern and a few editorial suggestions.


    > CONCERN

    > Section 4.1 says:

    } o  A note is included in the reference text that indicates that the
    } reference is to a target document of a lower maturity level, that
    } some caution should be used since it may be less stable than the
    } document from which it is being referenced, and, optionally,
    } explaining why the downref is appropriate.

    > There are many cases where cryptographic algorithms are specified in
    > Informational RFC, and then a Standards-Track document is used to
    > specify protocol conventions for using that algorithm.  the algorithm
    > specification is not unstable, and requiring a note like this sends the
    > wrong message to the reader.

I think that this is really a process/RFC2026 process bug that maybe we could
find a way to slightly amend RFC2026 about.  (How many gendispatches ago was
the 2026 revision discussion...?)

I think that we document cryptographic algorithms as Informational because it
is not the IETF's goal to take change control over the algorithm.
It's not that we don't think of them as Standards-Track, it's that our
standards track rules say that can't unless we have change control.
The IETF RFC, because it's accessibility, often become the defacto industry
reference.   It is cited way beyond being cited in some other RFC.

Why doesn't the industry (and the IETF?) cite the original NIST,
etc. document?  Well, historically, because the documents predate the WWW, we
had RFC-by-FTP-email, and NIST didn't.

My thoughts are:

a) create some new category which is pseudo-authoritative standards track,
   which the IESG can annoit a document with.
b) cite the original documents/papers/NIST-etc. publications more often.

Perhaps CFRG has already struggled with this question before.
At this point, what I see is that there is significant original work being
brought to the CFRG *first*, that a CFRG RFC is becoming authoritative for
some algorithms. (No, I don't have an example.)





--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux