RE: HTTP Extensions Framework status?

At 22:21 06.12.99 -0800, Yaron Goland (Exchange) wrote:

>I think there is a more fundamental problem, the bar for reaching proposed 
>standard for an APP draft must be different than the bar for a transport draft.

Nope.
The difference is between affecting the infrastructure and affecting only 
itself - the bar for routing protocols is SIGNIFICANTLY higher than the bar 
for almost anything else, but there should be no higher bar for Service 
Location or IP-over-vertical-blanking-interval than there should be for 
IMPP or IPP.


>Changing DNS is a serious thing that effects the fundamental architecture 
>of the Internet. As such it is something to be done very carefully.
>
>Changing IP is even more scary and thus requires even more effort.
>
>App protocols, these days at least, have a shelf life measured in minutes. 
>IDs are moving so quickly from first draft to deployed implementation that 
>the application community is forced to come up with its own rules as to 
>when something is done. Now a days a draft is considered fair game as soon 
>as it passes working group last call. The rest of the process is 
>considered irrelevant.

That's the same process as in all other IETF groups - see PPP, MLPS, 
DiffServ. Often they don't wait for WG Last Call before shipping sillicon 
either.
And sometimes the predictable disasters result.


>This is not a workable long term solution as the draft can still be 
>changed by the IESG even after surviving working group last call.
>
>Hence app types need a faster system which, once consensus has been 
>reached in the working group, quickly ensures that the draft is frozen. 
>There are no "experimental" app protocols and no IETF/IESG last call. If 
>all the members of the working group buy off then you have something that 
>will be implemented. That is the process the apps world needs. That isn't 
>the IETF process.
>
>As I see it we have three choices:
>
>1) Invent a new status above ID but below RFC that let's app developers 
>know they have a frozen draft they can develop off of but one that hasn't 
>met all the IETF quality bars.

We've got one. It's called EXPERIMENTAL!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


>2) Change the RFC process for APPs to lower the bar to working group 
>consensus.

That would mean starting to ship Proposed Standard RFCs that a significant 
portion of a WG objects to. Do you really think that's good?


>3) Form a new, separate, standards group specifically for application 
>protocols.

Feel free to start one. The IETF process rules have a very flexible 
licensing scheme. The W3C, the DMTF, the WAP forum and a dozen others are 
already trying, too.
And, as we saw with HTML, separating those concerns from those things that 
concern the network deeply can in fact improve the attention it's possible 
to give to those things, to all our benefit.

The unique things about the IETF as a protocol forum are:

- It works (however badly)
- It has a certain reputation
- It has contact with a large number of networking experts

If all the things that didn't need all these criteria were done elsewhere, 
the IETF workload would be smaller.

                      Harald A



--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no

Received on Tuesday, 7 December 1999 02:39:36 UTC