Subject: Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..

From: [email-masked] (Scott O. Bradner)
Date: Mon, 21 Jan 2008 17:20:44 -0500 (EST)

Russ,
	I was specifically not commenting on the contents of this ID
(I will soon) but on the process being followed

I see no justification of issuing an IETF Last Call on a ID that 
is designed to modify our core process document where the document
has gotten so little discussion or indication of support

John's suggestion of a plenary discussion may be a reasonable path 
but I do not think that using the IETF Last Call process to
ferment discussion is all that good a way to proceed (this is what
I was calling flippent)

Scott

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked] (Scott O. Bradner)
Date: Mon, 21 Jan 2008 21:28:24 -0500 (EST)

substantive review:

I think that Brian has pointed out a number of areas where, if we were
to produce a revised 2026, work needs to be done and I think that some
number (but by no means all) of his suggestions are good, but
	1/  I think a delta of this complexity makes the result
unreadable - a new version of 2026 would make far more sense 
	2/ I do not think we are remotely ready to produce a revised
2026 (no matter how much I would like to) process- and discussion-wise

that said, some notes as if this might move forward

I'm not sure that tweaking STD is enough of a problem to fix - STDs are
mostly ignored and thus do not get in the way

re expired IDs: see, for example
http://tools.ietf.org/id/draft-bradner-pbk-frame-00.txt
 i.e, "expired" IDs are available through tools.ietf.org (a good thing
in my mind) but confuses the suggested text changes

TS vs AS - it would be good to say that a TS can include an AS - but I'm
not sure one needs to do much more than that

I'm not sure much needs to be done in a delta document about requirement
levels other than mention RFC 4897

renaming the standards levels
	a bit of history 
	the first place I found that lists the standards levels is RFC
	1083 (Dec 1988) - that lists "Proposed Protocol", "Draft Standard
	Protocol" and "Standard Protocol"
	"Proposed Protocol" switched to "Proposed Standard Protocol" in
	RFC 1140 (May 1990)
	The current usage (dropping "protocol") was established by the
	time that RFC 1310 was published (March 1992)

	so we have been using basically the same names since 1990 - I'd
want to see a very good reason to change names with that amount of
history behind them - and I do not see it here - I do think that we have
issues with the 3-level process but tweaking the names in this way
would:
	1/ confuse
	2/ not prevent deployment at the first IESG-approved stage
	(since we often get deployment at the Internet Draft stage)

re: interoperability requirements - Brian details some real issues here
and having a quick punt to the IESG to say what it mans may not be a bad
idea but this is something that may deserve a separate document because
the details of interpretation will change from time to time - and its
easier to update a stand alone doc

re: informational RFCs - proposed addition makes sense

re - non WG. sponsored info & exp RFCs - I do not like this process
anyway when it is uses as a way around getting a nasty (in some people's
minds) IESG note on their RFC (which can happen if it goes through the
RFC Editor) - I'd rather this escape route were closed and the IESG note
made more factual and less something that an author would want to avoid
- if the path involves real IESG review then it would be good to note
  that in the RFC (and note the same in wg info & exp RFCs)

re: stale proposed & draft standards - something like what Brian
proposes makes sense

re: appeals kickoff - if it applies to "any decision whatever" then how
about document editor decisions?  (document editors are not appointed by
the IESG) or decisions by the IETF Trust or IAD (also not appointed by
the IESG)