Julian and Lars,
We could get clever here. The crucial language in RFC 3720 says:
For IANA registered keys the string following X# must be
registered
with IANA and the use of the key MUST be described by an
informational RFC.
and there's similar language for Y# digest formats and Z# authentication
methods.
Given the level of review this draft has received (not only on the list,
but also in Montreal, I put crucial pieces of this draft's text on the
projector for word-by-word review), I don't think there would be any
problem with this draft becoming a proposed standard RFC, and it could
then update RFC 3720 to change "informational RFC" to "informational,
experimental or standards track RFC" in all three places.
I would want to issue a WG Last Call on these changes (publish
nodearch-key as proposed, standard, update RFC 3720 to allow
experimental
and standards-track RFCs for X# keys, Y# digests, and Z# authentication
methods), so that there is an adequate opportunity for anyone to object.
Comments?
Thanks,
--David (ips WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
________________________________
From: Julian Satran [mailto:[email protected]]
Sent: Monday, October 16, 2006 4:04 AM
To: Lars Eggert
Cc: [email protected]
Subject: Re: [Ips] AD review of
draft-ietf-ips-iscsi-nodearch-key-02
Lars,
Yes we wanted new keys to be publicly documented without
requiring authors to go to a strict review (that might be hard to get in
several years).
In retrospect we should have said "at least informational"
although there is (at least in theory) an ordering between RFC
"classes".
Julo
Lars Eggert <[email protected]>
16/10/06 03:40
To
[email protected]
cc
Subject
Re: [Ips] AD review of
draft-ietf-ips-iscsi-nodearch-key-02
On Oct 16, 2006, at 10:28, Lars Eggert wrote:
> Finally - why is this going for Informational and not PS? PS
seems
> appropriate.
To be precise, I saw David's note on this from the document
writeup
("This document is being published as Informational because RFC
3720
indicates that this class of key specification should be
published as
informational.")
It's unfortunate that 3720 doesn't also allow publication at
Standards Track; I wonder what the rationale for this was.
Intuitively, this should be OK, because Standards Track
publication
has a higher bar.
If the WG decides to go for Informational because of 3720, I'm
OK
with it. It may make sense to add a short note to the
introduction
explaining this.
Lars
--
Lars Eggert NEC Network
Laboratories
_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.