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

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

 



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)






_______________________________________________

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]