Subject: Last Call: draft-fenner-zinin-rtg-standard-reqts-01.txt

From: Alex Zinin <[email-masked]>
Date: Thu, 16 Feb 2006 10:02:30 -0800

This is to start a Routing Area-wide two-week Last Call on this document
for submission to the IESG for publication as BCP. The Last Call ends on
March 2nd, 2006.

The document is available here:

http://www.ietf.org/internet-drafts/draft-fenner-zinin-rtg-standard-reqts-01.txt

Abstract:

>    This document provides guidance for the advancement of the protocols
>    produced within the IETF Routing Area.  It places implementation and
>    interoperability constraints on protocols earlier in the standards
>    process than RFC 2026, based on RFC 2026's provision that the IESG
>    may require implementation and/or operational experience prior to
>    granting Proposed Standard status to a specification that materially
>    affects the core Internet protocols or that specifies behavior that
>    may have significant operational impact on the Internet.
> 
>    We also discuss the applicability of these rules to protocols and
>    their extensions.

-- 
Alex
http://www.psg.com/~zinin

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Christian Hopps <[email-masked]>
Date: Fri, 17 Feb 2006 05:50:15 -0800

4.1 Proposed Standard
    4.  Two or more independent interoperable implementations must  
exist.

4.2 Draft Standard
    4.  Two or more interoperable implementations must exist.  At least
        two must be written independently.

Is there a difference of meaning here, rather than just words?

Chris.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 17 Feb 2006 13:39:29 -0500

I have many concerns about this document.  

Beginning with the statement: 

      The IESG may require implementation and/or operational experience
      prior to granting Proposed Standard status to a specification that
      materially affects the core Internet protocols or that specifies
      behavior that may have significant operational impact on the
      Internet.

The first problem is  that there is never a clear set  of criteria given for
identifying "core internet protocols".  The  second problem is that there is
never a  clear set  of criteria for  whether some  specification "materially
affects" a core internet protocol. 

For  instance, I  would really  like to  understand why  DNS is  not  a core
Internet protocol but LDP and RSVP are.  Really, which one is more important
to  the  proper operation  of  the global,  public  Internet?   DNS is  even
arguably a distributed protocol, where,  to quote the draft, "the effects of
a problem ... may easily propagate through the network, and result in service
degradation of complete loss of  connectivity".  In fact, this could even be
said of  http, at least when  all the common  distributed caching procedures
are taken into account. 

I certainly  agree that distributed  n-party protocols such as  routing are
more  difficult to  get  right  than is  the  average two-party  application
protocol.  However,  routing is not  the only distributed  n-party protocol,
so I  don't think that is  the real basis  for requiring it to  have special
treatment. 

Given  the  emphasis on  ROUTING,  one might  infer  that  the protocols  of
interest are the  protocols which set up forwarding  state in routers.  This
criterion is  not given  explicitly, but  at least it  explains why  LDP and
RSVP-TE are  considered to be in  scope.  That still  leaves unclear whether
"ordinary"  RSVP  is  to be  in  scope;  it  can  certainly be  argued  that
"ordinary" RSVP affects the forwarding  state, even if it cannot actually be
used to  change the next hop  at any point along  a path.  The  same is true
though for stuff like WRED, DSCP, etc.  

It seems  to be intended that  tunneling protocols (e.g., L2TP,  GRE) not be
considered to  be "core  internet protocols".  But  now what about  the case
where a  "core internet  protocol" has a  second use  as a tunnel  setup and
maintenance protocol.  For example, the LDP extensions of PWE3 have as their
function  the  setup  and   maintenance  of  tunnels,  so  presumably  these
extensions  would  not  be considered  to  be  part  of the  "core  internet
protocols", even if the base LDP protocol is. 

Which leads to the next problem:   there are a number of protocols which are
sometimes used for setting up forwarding state in the routers, and sometimes
for other  purposes.  That is, the  base protocol might  fall under whatever
criteria we  adopt, but  various extensions might  fail to fall  under those
criteria.  The draft  seems to require that these  extensions be treated the
same way as  the base protocol.  This  just doesn't make any sense  to me at
all. 

There are numerous cases where someone  wants to add a field to some routing
protocol, not to  affect routing, but because the  information in that field
needs to be delivered to a set  of routers, and the routing protocol will do
that.  There's no  reason why these fields should be  considered to be "core
internet protocol". (See above re PWE3 LDP extensions.)

I could of  course imagine someone arguing that  tunneling protocols do need
to be included,  because one can run routing through  the tunnels, and hence
failure of the  tunneling mechanisms can impact the  overall routing system.
If one made  this argument, not even IPsec would be  immune from the special
routing requirements.  

As things  stand now, the  vagueness of the  criteria, and the  inability to
apply criteria  specifically to  extensions, result in  a lot of  extra work
which  is basically useless,  and only  serves to  delay the  progression of
various drafts. 

Now, as to the issue of "two independent implementations", I think the whole
discussion of this area has been somewhat confused.

We  have  just  published a  new  BGP  spec  as  DS.  How  many  independent
implementations of BGP were written from this spec?  We are about to publish
a new  PIM-SM spec  as PS.  How  many independent implementations  of PIM-SM
were  written from  this spec?   Hey, forget  about "independent",  how many
implementations at  all were  actually written from  either of  these specs?
Isn't it  really the  case that  these specs were  written to  correspond to
existing  implementations, rather  than the  other way  around?  If  we were
really  serious about  "proving" the  quality of  the spec  with independent
implementations,  we wouldn't consider  implementations that  existed before
the  spec was  complete,  rather  we'd look  for  implementations that  were
written from  scratch after the spec  was complete.  We'd also  have to make
sure that  the new implementations  were done by  folks who had  no previous
experience with  the protocol, and we'd  have to make sure  that those folks
had  no contact with  the developers  of the  spec.  And  if there  were any
interoperability problems  as a result, we'd  have to start  the process all
over again.

Frankly, I  don't know how  we would  find someone to  sponsor a BGP  or PIM
implementation to  be done directly  from the spec,  by folks with  no prior
knowledge of an implementation; I doubt there are two completely independent
implementations of either one.  Usually if a company needs an implementation
of some  protocol, they try  to find someone  who's done it before,  and who
knows how  to make  it interoperable with  the major deployments,  no matter
what the spec says.  In fact, any implementor who's earning his pay would at
least  look at  an  open source  or  other reference  implementation of  the
protocol,  if one  is available.   But then  his implementation  wouldn't be
independent, would it?

I  think it  might  make sense  to say  that  we don't  want to  standardize
something unless there is running code (i.e., one implementation) and enough
independent review to give us confidence that the spec is adequate.  Even so
I wouldn't  apply this to  every last little  feature of some  protocol, but
only to "major features" (however we choose to define that).  

With regard to  the necessary "paperwork", perhaps we  really need different
processes   for  things   that  already   have   multi-vendor  interoperable
deployments than we do for things are  really new.  I can cite some cases of
specs  that still  haven't made  it through  the IETF  process,  even though
multiple interoperable implementations have been widely deployed for five or
six years.  It's very difficult in such cases to produce "test scenarios and
test  results showing that  the major  features of  the protocols  have been
tested".  This  is very different than the  case where we really  have a new
protocol and the  bake-off was last week. Failure  to "officially" recognize
these  two different  cases  is the  source  of much  red  tape and  useless
effort.  It's also very difficult  to determine from this draft exactly what
one  has to  provide in  order to  be  sure that  one has  provided all  the
necessary paperwork.

Another confusing  thing about the document is  the way it applies  a set of
requirements  to  "routing  area  submissions"  and  an  "elevated  set"  of
requirements to protocols that  meet certain criteria, regardless of whether
they fall in the routing area or not.  I don't think that the different IETF
areas should have special  rules that apply to a WG just  because a WG is in
that area, irrespective of the actual content of the work. 

On the  other hand, by trying  apply some special  requirements to protocols
developed outside the  routing area, the routing ADs seem  to be saying that
they have the right to interfere  in the progress of other areas' WGs, based
on solely on their own judgment as to whether protocols in those other areas
meet some  vague set of  criteria developed by  the routing ADs.   Sure, the
Security ADs already practice this  kind of interference on a regular basis,
but I'm  not at  all sure that  it is  a good thing.   (Hmmm, maybe  what we
really need is  to require a "routing considerations"  section in every spec
;-)) 

Given all  the above, I'd have  to say that  this document is not  ready for
prime time.   I think  the criteria for  "elevated requirements" need  to be
specified a lot  more clearly, the elevated requirements  themselves need to
be a  lot more reasonable, and the  paperwork requirements need to  be a lot
clearer. 

Of  course, one  could actually  ask the  higher level  question  of whether
special requirements for selected protocols  are really necessary at all.  I
don't think  the draft even  tries to  make a case  for this.  It  just says
"some protocols are  special, so the bar should be  higher".  No evidence is
presented to show that the bar needs  to be higher, this is simply stated as
if no one would ever question it. 

Given that the biggest threats to the Internet (broadly construed) today are
computer viruses, spam, enduser  security, etc., perhaps endsystem protocols
really need more attention than BGP extensions!

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 17 Feb 2006 22:02:41 -0500

In message <[email-masked]>
Eric Rosen writes:
>  
>  
>       The IESG may require implementation and/or operational
>       experience prior to granting Proposed Standard status to a
>       specification that materially affects the core Internet
>       protocols or that specifies behavior that may have significant
>       operational impact on the Internet.

I really can't see how the above could be more clear unless you asked
a lawyer to pick it apart.  I hope we haven't come to that.

If we were lawyers (or professional standards body meeting attendees)
we could argue this forever and just keep raking in the fees.

This gives the IESG the responsibility to interpret when to apply
this criteria.

> implementations of BGP were written from this spec?  We are about to
> publish a new PIM-SM spec as PS.  How many independent implementations
> of PIM-SM were written from this spec?

Nowhere does it say that existing implementations have to be tossed
and new ones written from scratch after the spec was completed.

> Given that the biggest threats to the Internet (broadly construed)
> today are computer viruses, spam, enduser security, etc., perhaps
> endsystem protocols really need more attention than BGP extensions!

Ending your argument with FUD?  Perhaps better attention is needed to
the end systems themselves.  The IETF didn't plant any open ports for
MS-Access or Active-X in Windows or help write the browser bugs or
bugs in MS-Outlook.  E-mail is actually traceable to the sending
*machine*.  The only problem with that is the end systems are so full
of security holes that tracing to the sending machine is of little
help in tracing back to the "bot" author that is the actual sender.
Maybe we just need to find a way to ban Microsoft product from the
Internet and we'd have little or no viruses, spam, etc.  That's off
topic for this thread though.

Curtis

ps - Chages that make the "running code" requirement stronger are good
for the IETF and good for the Internet and Internet protocols.  Those
requirements may be bad for professional standards body meeting
attendees who want their name on lots of "standards" whether they get
implemented or not.  Those people should go to ITU meetings.

---

From: Bill Fenner <[email-masked]>
Date: Sat, 18 Feb 2006 12:15:11 -0800

>Is there a difference of meaning here, rather than just words?

Good catch, Chris.  4.1's #4 was changed from "One or more" to "Two
or more independent" without noticing the inconsistency with 4.2's #4.
I'll copy 4.2's version back over to 4.1.

  Bill

---

From: Eliot Lear <[email-masked]>
Date: Sun, 19 Feb 2006 10:13:13 +0100

> a lawyer to pick it apart.  I hope we haven't come to that.

We have.  Get over it.  The statement is clearly intended for lawyers. 
Why otherwise would they need to make such a statement in the first
place?  Would we otherwise be saying that the IESG couldn't stop a
standard they considered risky?  And we've seen plenty of bad BGP actors
over the years with or without an RFC to back them up.

Eliot