Subject: Re: [newtrk] Re: I-D ACTION:draft-ietf-newtrk-promotion-00.txt

From: Pekka Savola <[email-masked]>
Date: Sun, 19 Mar 2006 17:40:19 +0200 (EET)

On Tue, 28 Feb 2006, Brian E Carpenter wrote:
> These are personal comments only.
>
> At the top level, I believe this is the wrong solution to
> the right problem. I already proposed what I believe is the
> right solution in draft-carpenter-newtrk-twostep. I'm sure
> your local time machine will find this expired draft easily,
> but its main point was to combine DS and Standard into
> a single grade called Interoperable Standard, thereby
> avoiding makework.

I read the draft and I liked it in principle -- but I also liked 
two-step.  I guess I'm just anxious to do *something*.  Maybe we could 
start testing the promotion with Draft Standards like Phil suggested 
(or very mature PS's) while we argue whether the long term goal is 
1/2/3 step..

I agree with Brian that the IAD/IESG-secretary's role doesn't seem to 
be only clerical (e.g., verification that something has been 
implemented for at least 3 years), though I like the fact that this 
doesn't gate more and more stuff on the IESG :).

Higher level comments:
  1) I'm concerned about sufficient deployment.  In a place the doc 
uses "a reasonable variety of networks", and maybe with 
s/networks/different kinds of networks/, if uses consistently 
throughout the doc, it might be good enough.

The reason is, any protocol that has been implemented has been 
deployed in some networks.  My main resistance to this experiment 
would be if this would result in "non-majority" protocols getting 
pushed to full standard.

For example, COPS (RFC2748) is PS.  From my perspective, it doesn't 
seem to have obtained wide deployment.  I wouldn't want to see it move 
forward in the standards process.  Another example: IntServ (RFC2210).

As such, it might be helpful to give a bit more definition of what 
qualifies as sufficient deployment... or require serious handling of 
"I don't believe this has been sufficiently deployed" Last Call 
responses (I think this is currently the other way around).

  2) the assumption seems to be that for simplicity, the enabling docs 
would be published as RFC (or pushed along using the same process), 
but I don't see any reason why that'd need to be in case they don't 
replace the old spec -- just a web page along the lines of interop 
report would probably do (e.g., an xml2rfc draft format turned to a 
HTML with a new boilerplate).

    This is semi-important because folks are going to argue that 
publishing these RFCs would burden the RFC-editor unduly.

smaller comments:
-----------------

  - section 1, 3rd paragraph mentions downref rules but those aren't 
further discussed in the document AFAICS.
  - section 3.1, last bullet point -- is this about downref 
rules/"variances" or something else?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html