Re: HTTP Extensions Framework status?

[I feel compelled to point out at the outset that none of the discussoin
below has anything to do with the HTTP Extensions Framework document -
(a) this was an indivdual submission, not an HTTP working group document, 
and (b) the document received mixed reviews both within the HTTP WG
and during Last Call, which is why it was not approved as Proposed.]

> 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.

In a sense, the bars *are* different - the criteria are generally the 
same regardless of area but things that seem to have the potential to 
have a disruptive effect on the infrastructure are scruitinized 
more closely, and IESG has the power to declare those Pxperimental
even if they otherwise meet the requirement for Proposed.

> 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.

People can ship code whenever they want - there's nothing IETF could 
do to stop them - but that doesn't mean that IETF should rubber stamp
the output of a working group.  One of the biggest problems in
Internet protocol development these days is the tendency for groups to
work at cross purposes to one another.  So just because something gets
past one working group doesn't mean that there aren't problems with it.
Ideally, of course, we identify those problems well before the working 
group thinks it's done with a document.  

> 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.

What you are saying is that there's no need for independent review of a 
group's work.  I've seen too many groups go completely off into the weeds, 
or produce documents full of technical errors and/or security holes, to 
believe that.  It is unfortuntely the case that working grups often 
reach consensus due to exhaustion rather than because the work is complete;
when that happens, someone outside the working group - whether it be 
someone responding to the Last Call or an IESG member -  needs to call them 
on things that are broken.  And when groups threaten to work at cross 
purposes with one another, there needs to be a mechanism to push back on 
those groups to get them to work together.  This wouldn't happen if there 
were no IETF-wide Last Call and IESG review.

As it is, IESG feels tremendous pressure to approve any document that
comes out of a working group - or at least, to find a way to let it
be approved without making major changes to the document (and 
without making changes to the protocol if it is deployed).  IESG members
often feel that they cannot push back much on WG documents even when
they are of really dubious quality, especially when a WG is so tired
and non-functional that it's unlikely to be able to make useful changes
in finite time.  So IESG members often try to content themselves with 
disclaimer language even when they have serious technical concerns about 
the protocol or the quality of the document.  Relabelling a working group 
document as Experimental is something IESG does only very rarely - probably 
less than once a year for the entire IETF and its O(100) working groups.

> 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.

Experimental already exists for this purpose.
 
> 2) Change the RFC process for APPs to lower the bar to working group
> consensus.

as explained above, that's a really bad idea.
 
> 3) Form a new, separate, standards group specifically for application
> protocols.

folks do this all the time.

Look, IETF has a good reputation at least partially because its protocols
work well and have a high liklihood of being deployable.  The IETF process
is geared toward upholding protocol quality and making sure that things
work together.  External review and oversight are fundamental parts of
that process, and it's difficult to understand how the quality/deployability
of IETF protocols could be maintained without them.  

To the extent that our process is bogging things down without improving
the quality of the output, I agree that we would do well to streamline
things.  But while I like to think we can improve turn-around times, I 
don't think we can do without external review.

Keith

Received on Tuesday, 7 December 1999 10:34:19 UTC