Re: As Promised, an attempt at 2026bis

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

 





On Tuesday, October 03, 2006 11:27:36 AM -0400 John C Klensin <john-ietf@xxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

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