On Tuesday, October 03, 2006 11:27:36 AM -0400 John C Klensin
<john-ietf(_at_)jck(_dot_)com> wrote:
Good. If we disagree, it is only on what a "formal change"
constitutes. I would consider an in-depth summary of what is
wrong with 2026 (at least on any basis other than a personal
informational opinion piece) and any attempt to replace 2026
with a version that reflects current practice to be such formal
changes, if only because they would require almost the same
level of effort in review and consensus-finding as actually
changing the process. But some might disagree.
As I start to write this, I've read through a little more than half of
Brian's draft; I stopped when I found something to comment on. What I'm
seeing is descriptive, not prescriptive - it describes ways in which
RFC2026 differs from what we actually do, offers interpretation based on
current practice, and so on. I think a document like that, taken as a
non-normative description rather than a specification, could be useful
operationally. People who read RFC2026 without being familiar with current
practice are likely to be rather confused, and Brian's draft clears up many
of the possible confusions and offers additional commentary that may be
useful in understanding what goes on.
I assume that a document like this would be published as an informational
document, without the benefit of IETF consensus and possibly without even a
Last Call (there is _nothing_ that says Informational documents need a last
call, and they are frequently published without one). I wouldn't have a
problem with that, and in fact, it's probably best that this _not_ be an
IETF consensus document if it is to serve a useful purpose.
Now, the thing I found to comment on. Brian writes the following about the
last paragraph of section 4.2.2:
This presumably means "outside of the IETF process" not "outside of
the Internet community." As part of this year's RFC Editor RFP
process, clarity is being sought about the independent submissions
track, which should probably not be discussed at all in the basic
definition of the standards process. See
[I-D.klensin-rfc-independent] for a more current description.
Actually, I think the section means what it says, and is referring _not_ to
independent submissions but to cases where a specification developed
elsewhere is republished as an RFC to make it more readily available to the
Internet community. For example, we do this on a fairly regular basis with
the specifications of cryptographic hash functions.
-- Jeff
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf