Re: [Ieprep] proposed charter

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
"James M. Polk" writes:
>  
> comments in-line

same here.

> At 01:21 AM 9/26/2006 -0400, Curtis Villamizar wrote:
>  
> >Two people sent me private email pointing to the email message with
> >the proposed charter.
> >
> >http://www1.ietf.org/mail-archive/web/ieprep/current/msg02421.html
> >
> >Thanks.
> >
> >Seems mostly reasonable to me.  One paragraph seems open ended and may
> >be a source of trouble for other reasons.
> >
> >   If there is an existing group that can extend a protocol or
> >   mechanism, IEPREP will generate only a requirements document for
> >   those groups to evaluate. If there is not an existing group that can
> >   extend a protocol or mechanism, IEPREP will prepare requirements and
> >   discuss the extension of that protocol/mechanism or
> >   protocols/mechanisms within IEPREP.
> >
> >This is a promise to liason with anybody and everbody that intends to
> >work in this area and to step back and let that other group do the
> >protocol work.
>  
> Correct, and this is what IEPREP has been limited to since its creation 
> (i.e. it has only been able to do requirements, and no solutions)

This may come from the "requirements first, then solutions" approach
that the IETF has taken where there has been disagreement about what
the requirements are.  I've read all of the IEPREP RFCs and the
requirements are still not nailed down.  For example, it is important
to know how many priority/preemption values there will be and whether
each priority requires three drop preferences as required by an AF
service.

> >The IESG favors (with good reason) WG charters that
> >propose to do work
>  
> ah, but IEPREP isn't allowed to *do* anything, only write requirements for 
> other WGs to *do* something, and only *if* that WG decides to *do* anything 
> with the requirement(s), which may get brushed asside as not interesting, 
> or without significant WG interest (from that other WG).
>  
> RFC4412 took 6 years to get done due to lack of interest in another WG, yet 
> the IEPREP WG could have done the work in 2.

Lack of interest translates to lack of paying customers.  If a
government or government agency has an urgent need they may need to
cough up research money and later fund a deployment.

It would be interesting to have a report on implementation of RFC4412
and deplyment experience.  Generally things with lots of "interest"
get deployed before the RFC is even reviewed by the IESG.

> >rather than WG charters that propose to sit back
> >and watch the ITU do work in that area.
>  
> Well... the intention is to have IEPREP actually be able to extend 
> protocols that don't currently have WGs chartered for said protocols, and 
> it there are WGs for said protocols - to give those WGs merely the 
> requirements.  This paragraph's intent is to state that IEPREP doesn't want 
> to step on anyone's toes if a current WG charter elsewhere covers a desired 
> piece of protocol work, and actually do the work if it isn't chartered 
> anywhere else.
>  
> ITU-T is mentioned in a cooperative sense, but IEPREP isn't expecting to 
> assign ITU-T work.

The way the paragraph reads, if ITU is doing something, then IEPREP
should not be doing protocol work in the same area.

> >A good example (and closely
> >related to this sort of work) where the result coming from the ITU was
> >not at all useful is the ITU QoS requirements work in the mid to late
> >1990s.  This may be looking too much like more of the same.
>  
> <snip>
>  
> >Any effort which requires the whole world to agree before getting
> >started will never get started.
> >
> >Curtis

_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep