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

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Alex Zinin
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
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

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

On Feb 16, 2006, at 10:02 AM, Alex Zinin wrote:

> 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


_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Eric Rosen
In reply to this post by Alex Zinin

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!











_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Curtis Villamizar

In message <[hidden email]>
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.

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

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.

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Bill Fenner
In reply to this post by Christian Hopps

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

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

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Eliot Lear
In reply to this post by Curtis Villamizar
Curtis Villamizar wrote:

> In message <[hidden email]>
> 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.
>  

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

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Bill Fenner
In reply to this post by Alex Zinin

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

I'm sorry, I'm a bit confused here - you have a concern that this
document quotes RFC2026, or you have a concern with the statement
that appears in RFC2026?

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

This document, especially section 3, is intended to give some
criteria. Under the RFC1264 rules, we didn't even have this,
so we picked and chose when to apply the rules ourselves, which
of course is only a problem when we're wrong ;-)

>For instance, I would really like to understand why DNS is not a core
>Internet protocol but LDP and RSVP are.

I've heard Internet ADs ask the same question, and the answer is
basically "nobody's gotten around to writing something like 1264
for any other protocols". Are you arguing that routing protocols
shouldn't be considered core Internet protocols, and perhaps we
should just reclassify RFC1264 as historic, or that this document
should cover other types of protocols, or that someone else should
work on another document to cover those other types of protocols,
or what?

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

Do you have a suggestion for how to classify these objectively? We've
had trouble with subjective rules, which is why we settled on the
objective "same as the base protocol".

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

By "now", do you mean "with the RFC1264 rules", or "with the
draft-fenner-zinin rules"? We tried to make the criteria a lot more
concrete in our draft.

>Hey, forget about "independent", how many
>implementations at all were actually written from either of these specs?

Actually, while one implementation was written during the development of
the new PIM spec, I'm aware of at least one that was written from the
spec. (And we got a lot of spec bug reports from that author, validating
the theory that you learn about the clarity of the spec when you implement
from it.)

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

We wrote the checklists in section 5 specifically to address this problem.
E.g., if you're submitting for Proposed Standard, if you've got the
7 items listed in section 5.1 bullet points 1. - 7., then you can be
pretty sure that you've provided all the necessary paperwork.

If this is confusing, can you suggest a better way to present
this information?

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

I agree with this, but during development of this draft we thought
the consensus of the area was otherwise.  If consensus is with us then
we can remove this requirement.

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

If it's a routing protocol, there are already additional requirements,
described in RFC 1264.  Again, we tried to make the criteria in
draft-fenner-zinin more concrete than the ones in 1264, but of course
it's not easy to come up with one complete answer.

>I think the criteria for "elevated requirements" need to be
>specified a lot more clearly

Do you have any suggestions?  What's unclear about the current
formulation?

>the elevated requirements themselves need to be a lot more reasonable

Which parts do you find unreasonable?

>and the paperwork requirements need to be a lot clearer.

Again, I can't understand this comment.  What is unclear about the
checklist of required items?

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

I believe that the paragraph at issue is a quote from RFC 2026, and you're
right, we don't try to justify that paragraph's existence in that RFC.

  Bill

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Eric Rosen

> I'm sorry, I'm a bit confused here - you have a concern that this
> document quotes RFC2026, or you have a concern with the statement
> that appears in RFC2026?

Yes, to both.

> This document, especially section 3, is intended to give some
> criteria. Under the RFC1264 rules, we didn't even have this,
> so we picked and chose when to apply the rules ourselves, which
> of course is only a problem when we're wrong ;-)

Well, "everything from  a routing area WG" is a  clear enough criterion, but
it selects many things that don't seem to be crucial to the operation of the
Internet, that  don't seem to be  "core internet protocols",  and that might
not even be technically classified as "routing".  Rather than clarifying the
criteria  for which  submissions need  special  treatment, it  gives up  and
proposes to apply special treatment to  stuff that just doesn't seem to need
it.

E.g., it's rather difficult to see why every minor change to a BGP attribute
needs special treatment.

Various peculiar and  time-wasting things really do happen  when these rules
are  enforced.  To take  a recent  case, IPv6-specific  extended communities
were added to the BGP extended communities spec in order to satisfy the rule
that IPv6 not  be ignored.  Then they were removed to  satisfy the rule that
anything not implemented has to be removed.  This is just making the authors
run around in circles.  It's hard to see how the presence or absence of this
kind of  extended community in the spec  makes any difference at  all to the
health of the Internet.  

With regard to  the other criterion in section  3, "protocols implementing a
distributed algorithm  whose functional domain  spans more than  one network
segment ... or otherwise affects the state of the distributed routing system
or per-hop forwarding behavior", let's see how clear this is.

It seems to me that the "distributed algorithm" criterion as stated includes
such things as:

- Bittorrent  (if we might  suppose for a  moment that that would  ever fall
  under the IETF's purview)

- Web-caching and proxying protocols (e.g., akamai)

- DNS

- Mail

- SETI

Is it your  intention that the criterion include such  things?  If not, then
it's not clear what it is meant to include.

The "per-hop forwarding behavior" criterion would include anything having to
do with per-hop QoS treatment (Diffserv, RSVP).  Is that your intention?

If these  criteria are taken literally,  they greatly increase  the scope of
the routing ADs to make demands  on submissions from other area.  This would
put the routing ADs on a par with the security ADs in terms of their ability
to delay progress.

The "functional domain spans more than one network segment (link)" criterion
confuses me.   Does this mean that  special requirements are  not needed for
those protocols which provide  distributed algorithms that affect forwarding
state, but  which don't have  a "functional domain"  of more than  one link?
What would be an example of such a protocol?

> Are you arguing that routing protocols
> shouldn't be considered core Internet protocols, and perhaps we
> should just reclassify RFC1264 as historic, or that this document
> should cover other types of protocols, or that someone else should
> work on another document to cover those other types of protocols,
> or what?

I  don't think a  clear distinction  has been  drawn between  "core internet
protocols" and others, and I don't think a good case has been made that core
internet  protocols need special  treatment, or  that the  special treatment
that  they've been  given  has made  any  difference to  the  health of  the
Internet.  

In  general,  I  do  not  favor   adding  more  red  tape  to  the  process.
Reclassifying 1264 has historical might be a good move though.

> Do  you  have  a  suggestion   for  how  to  classify  these  [extensions]
> objectively?  We've  had trouble  with subjective rules,  which is  why we
> settled on the objective "same as the base protocol"

If the criteria applied to the base protocol were really clear and technical
(i.e., based on  technical characteristics of the base  protocol rather than
which Area its WG belongs to),  then why wouldn't the same criteria would be
applicable to the extensions.

> By "now", do you mean "with the RFC1264 rules", or "with the
> draft-fenner-zinin rules"? We tried to make the criteria a lot more
> concrete in our draft.

When I complain about how things are working "now", I mean with whatever set
of rules the ADs are now applying.  

I think  the draft-fenner-zinin  rules make things  worse, as it  seems that
they  try to  require special  treatment for  more things,  rather  than for
fewer.  Maybe that's the problem in a nutshell.

> while one implementation was written during the development of the new PIM
> spec, I'm aware of at least one that was written from the spec

I guess I  should only have mentioned the  BGP spec as an example  of a spec
that no one's every done an implementation from ;-)

> And we got a lot of spec bug reports from that author, validating
> the theory that you learn about the clarity of the spec when you implement
> from it

That theory is not in dispute!

> if you've  got the 7 items  listed in section  5.1 bullet points 1.  - 7.,
> then  you  can be  pretty  sure that  you've  provided  all the  necessary
> paperwork.

The terms "implementation  experience", "interoperability report", and "test
scenarios and test  results" are not very clear to me.   If you haven't done
this before,  I'm not  sure there is  anyplace you  can look that  tells you
exactly what is required.  And in  many cases, it seems nearly impossible to
produce this sort  of stuff.  E.g., when you're  advancing a spec describing
implementations that have been deployed and interoperating for 5 or 6 years,
it's very hard  to produce anything like "test  scenarios and test results".
That's why I think the paperwork requirements are not particularly clear.







_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Bill Fenner
In reply to this post by Alex Zinin

>> I'm sorry, I'm a bit confused here - you have a concern that this
>> document quotes RFC2026, or you have a concern with the statement
>> that appears in RFC2026?
>
>Yes, to both.

I guess I still don't understand.  Would it be correct to say that
your position is that the IESG should not be permitted to require
implementation and/or operational experience prior to granting
Proposed Standard, period?

>Well, "everything from  a routing area WG" is a  clear enough criterion, but
>it selects many things that don't seem to be crucial to the operation of the
>Internet, that  don't seem to be  "core internet protocols",  and that might
>not even be technically classified as "routing".  Rather than clarifying the
>criteria  for which  submissions need  special  treatment, it  gives up  and
>proposes to apply special treatment to  stuff that just doesn't seem to need
>it.

I already said that I agreed with you that that particular criteron
should be changed.

>Various peculiar and  time-wasting things really do happen  when these rules
>are  enforced.  To take  a recent  case, IPv6-specific  extended communities
>were added to the BGP extended communities spec in order to satisfy the rule
>that IPv6 not  be ignored.

There was no draft-ietf-idr-bgp-ext-communities-* published with
IPv6-specific extended communities.  Are you thinking of 4-byte ASes,
which were in the spec from the beginning (or, at least, from
draft-ramachandra-bgp-ext-communities-08, which is the oldest version
I have)?

>In  general,  I  do  not  favor   adding  more  red  tape  to  the  process.
>Reclassifying 1264 has historical might be a good move though.

That was the position that I started with, and got lots of pushback
from both open routing area meetings and on this list.

>I think  the draft-fenner-zinin  rules make things  worse, as it  seems that
>they  try to  require special  treatment for  more things,  rather  than for
>fewer.  Maybe that's the problem in a nutshell.

Well, it's really trying to clarify the rules that we've been trying to
use to apply RFC 1264.  So in a way it's like the new BGP spec - trying
to document current practice, not introduce new practice.

>The terms "implementation  experience", "interoperability report", and "test
>scenarios and test  results" are not very clear to me.   If you haven't done
>this before,  I'm not  sure there is  anyplace you  can look that  tells you
>exactly what is required.  And in  many cases, it seems nearly impossible to
>produce this sort  of stuff.  E.g., when you're  advancing a spec describing
>implementations that have been deployed and interoperating for 5 or 6 years,
>it's very hard  to produce anything like "test  scenarios and test results".
>That's why I think the paperwork requirements are not particularly clear.

Thanks for the concrete feedback.

  Bill

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Eric Rosen
Bill> Would it be correct to say  that your position is that the IESG should
Bill> not  be   permitted  to  require   implementation  and/or  operational
Bill> experience prior to granting Proposed Standard, period?

With regard to operational experience, I think that a standards organization
is not really in a position  to determine whether there has been an adequate
amount  of operational  experience with  some protocol  to  draw conclusions
about the viability of the protocol.

With regard to implementation, I  tend to think that the useful requirements
are too  subtle and case-specific to  lend themselves to  enforcement by the
process.  If a mechanism is well-understood,  having it in a PS is okay even
if there  aren't any existing implementations.   If the mechanism  is not so
well-understood,  one  may  want  to  hold  it back  or  to  publish  it  as
experimental.  I think  the WG itself might be the best  place to make these
decisions.  It  does seem useful to  have a process for  removing stuff that
hasn't  been  implemented  ever after  six  or  seven  years, but  that's  a
different issue.

Bill> There was no draft-ietf-idr-bgp-ext-communities-* published with
Bill> IPv6-specific extended communities.  Are you thinking of 4-byte ASes,

Yes, sorry.  Luckily the attribute is  not long enough to hold a v6 address,
otherwise it would have definitely been  put in (due to the "requirement" to
support IPv6) and then taken out again (due to lack of implementation).

Bill> which  were  in  the spec  from  the  beginning  (or, at  least,  from
Bill> draft-ramachandra-bgp-ext-communities-08, which  is the oldest version
Bill> I have)?

Hey, that means there were eight earlier versions ;-)

Eric> In  general, I  do not  favor  adding more  red tape  to the  process.
Eric> Reclassifying 1264 to historical might be a good move though.

Bill> That was the position that I started with, and got lots of pushback
Bill> from both open routing area meetings and on this list.

I have noticed  that when one sets  a committee to the task  of reducing the
amount of red  tape, the result is  likely to be an increased  amount of red
tape instead.  

I think  that the folks who  want more process and  more requirements should
point out  the facts to  show that the  extra process and  requirements have
made  a big difference.   Unsubstantiated opinions  do not  gain credibility
through multiplication.

> Well, it's really trying to clarify the rules that we've been trying to
> use to apply RFC 1264.  So in a way it's like the new BGP spec - trying
> to document current practice, not introduce new practice.

Well, once  it's published  as a BCP,  folks will  think that these  are the
real, set in stone rules, not merely what the current crop of ADs are trying
to do. That is a significant difference.

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Adrian Farrel(IETF CCAMP WG)
Hi,

I think my opposition to the direction of this I-D has been aired, and I
don't need to repeat my general case. I believe that the increased hurdle
to PS will either gum up the WGs or will simply cause everything to be
published as Experimental.

But here are some specific points about this I-D which I don't think was
ready for last call and doesn't appear to have had any significant review
(including perhaps by the Routing Area Directorate?)

Eric and Bill's conversation has brought up a point by mentioning IPv6.

Let us imagine a widely implemented and deployed signlaing protocol. It is
an IETF requirement that such protocol specifications include IPv6. This
is no problem form the point of view of specification, and would be easy
to implement, but the fact is that it is not implemented because no-one is
building or deploying networks that use IPv6 in conjunction with this
protocol (they may do in the future, but they are not doing so now).

What will happen to the publication request for the I-D that specifies
this protocol? We will not be able to say that the protocol specification
has been fully implemented, and there certainly will not be any
operational experience. Will this result in the RFC publication being help
up? Does it mean that the I-D must be split into two parts before the main
body can move forwards?


The I-D does not state a proposed status.

In section 3.2 you have (the much discussed)
   In consultation with the community, the IESG MAY decide to waive some
   or all of the requirements specified in this document.  A situation
   where this might be needed is when factors not envisioned in this
   document arise and applying elevated requirements does more harm than
   good.
Why are you making this a full IESG decision? Isn't it enought to delegate
it to the Routing Area ADs?

Section 4.1 point 2 (and through out). Please say MIB *module* not MIB.

Section 4.1 point 4. What is an interoperable implementation of a MIB
module?

Progression to DS or S is dependent on implementation and deployment of
associated MIB modules. I think you are setting yourself up for failure
and not recognising the way the world is moving wrt SNMP. While the
specification of the MIB modules is highly desireable, you may find that
certain protocols do not see wide uptake of SNMP as a management
technique. Do you propose that such protocols can never become standards,
or will you invoke section 3.2? (If section 3.2 is to be so easily invoked
we might as well dispose of this I-D and immediately hand all decisions to
the IESG!)

Section 5.1 seems at odds with the details in the Proto work. Can I
suggest that you converge on a common set of information to be supplied at
publication-request time so that the WG chairs do not have to fiddle about
collecting different information for different I-D processing procedures.

Section 5. point 2
This is a change the order of events since previously it has been the ADs
that have requested the RAD to review documents.
Please supply details of how the review is actually initiated, how the
progress of the review is tracked, and how the comments are returned to
the working group.

Section 5. point 3
A little more detail about the submission and publication of the
implementation and interoperability report would be helpful. Is this an
email to the IETF secretariat? Or perhaps it is an I-D? Where on the IETF
Web site will this be publicly available?

Section 5 is missing MIB Doctor review

Section 5 is missing appropriate cross-area and cross-WG review.

Section 5.1 says "IETF secretariat" and then lists the IESG Secretary's
email address. (See Section 5 point 3)

Long-term persistence of reports.
In several cases we are required to submit reports (implementation,
interoperability, operational experience, etc.). What is the archival
process for this? If they are submitted as I-Ds will they be published as
Informational RFCs to preserve them, or is some other archive proposed?

Section 8 seems to be a tiny bit empty. I'm surprised to see a last call
with that problem :-)

Use of RFC2119 language. This may or may not be appropriate in this I-D.
But if you use it you must include 2119 as a reference and use the normal
2119 boilerplate.

Thanks,
Adrian


_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Thomas D. Nadeau
In reply to this post by Alex Zinin

        Alex/Bill,

        A comments on the draft below.

1) In section 4.1 you have the following:

    2.  A Management Information Base (MIB) must be written for the
        protocol.  The MIB does not need to submitted for Proposed
        Standard at the same time as the routing protocol, but must  
be at
        least an Internet Draft.

        I suggest that this requirement be a little stronger in
        that the document must "be at least a Working Group
        Draft".   Just being a draft doesn't mean that it is
        going to be an agreed/inter-op standard some day. Well,
        neither does a WG draft, but it has a better chance of
        being one. Also, if you just require it to be an ID,
        how do you handle say individual submissions that might
        conflict/compete with a WG document and so forth?  I
        think just requiring a WG draft is cleaner.


2) Further along in the same section the following statement
        appears, which to me seems far too open-ended for
        my tastes in that it gives far too much latitude for
        an IESG review to kill or delay a protocol based on
        personal tastes for what constitutes "set forth
        explicitly".

        3.  The security architecture of the protocol must be set forth
        explicitly.  The security architecture must include mechanisms
        for authenticating protocol messages and may include other  
forms
        of protection.

        I am also concerned by the second sentence,
        "...may include other forms".  I am not a security expert,
        but to me, it seems more straight forward if we require
        the aforementioned "security architecture", to contain
        at least one method of each:
               
                - message authentication
                - replay protection
                - message encryption
                - message filtering (to help prevent DOS attacks)



3)   I would just say "At least two independent..." here

        4.  Two or more independent interoperable implementations must exist.

        Also, is this for *any* standards track documents or just
        protocol specifications? Namely, does this impact MIBs, PIBs, XML
        schemas, etc... out of a WG?

4)    Further down, point #5 seems a bit specious to me. Do you mean
        that they have been tested within a vendor's test lab or
        in somewhere else? I would say that an independent test such
        as the ones done at GMU or UNH might be what you are looking for
        here.  Also, HOW do you mean for them to be tested? Above you
        talk much about your concerns over scale testing, but the statement
        in #5 just says "tested".  Please be more specific.


        5.  There must be evidence that the major features of the protocol
        have been tested.


5) Section 4.2 gives me similar concerns as above. Specifically the
        security requirement in #3:

           3.  The security architecture of the protocol must be set forth
        explicitly.  The security architecture must include mechanisms
        for authenticating protocol messages and may include other forms
        of protection.

6) Further in 4.2 I have similar concerns in the testing section:

           5.  There must be evidence that all features of the protocol have
        been tested, running between at least two implementations.  This
        must include that all of the security features have been
        demonstrated to operate, and that the mechanisms defined in the
        protocol actually provide the intended protection.

        How should this be demonstrated?

7) Further in 4.2 you have:

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

        Please be more specific about what "written independently"
        means. I *think* you mean that the code is not
        derived from the same code base (i.e.: purchased code or
        two divergent code trains within a single vendor), but
        please be specific anyway.


8) Further in 4.2 you have:

    6.  There must be significant operational experience.  This must
        include running in a moderate number routers configured in a
        moderately complex topology, and must be part of the operational
        Internet.  All significant features of the protocol must be
        exercised.  In the case of an Interior Gateway Protocol (IGP),
        both interior and exterior routes must be carried (unless  
another
        mechanism is provided for the exterior routes).  In the case  
of a
        Exterior Gateway Protocol (EGP), it must carry the full
        complement of exterior routes.

        I think you should also include as part of the operational
        experience, some statement about the MIBs being used/tested
        and found to be useful. This is the phase where you might
        go back and refine them, so its important that this be included.
        In fact, you might also want to include them explicitly
        as part of the interop statements above.


9) Under section 5.  Submitting, I would like you to consider
        a time limit for the processing of documents both by
        the WG and the IESG review process.  Specifically,
        if you are going to put more burden on the WG and
        document editors to produce better specifications,
        I don't see why it is not appropriate to also put
        more stringent review guidelines on the review
        process.  All too often, documents seem to be lost
        in document review for (literally) a half of a year or
        more.  I suggest that we do something like say
        that if a document has been offered for review to the
        IESG or the RTG Area Dir review, and no answer has been
        given in 6 months, that the document proceed to the next
        phase.

10) 5.4:

    4.  A pointer (e.g.  URL) to the implementation and interoperability
        report previously submitted to the IETF secretariat.

        Shouldn't this be an IETF RFC or somewhere that can be
        solidly referenced? References to URLs can come and go,
        right?  I would say a fixed copy of the interop report
        is what you are looking for.

11) Later in 5.5:

    5.  A pointer to the corresponding MIB document with an explanation
        of how the MIB maturity requirement has been satisfied, or an
        explanation of why no MIB modifications are required to support
        functionality described in the Technical Specification.

        I am unclear on what the "MIB maturity requirement" is;
        can you be more specific or refer to a specific section
        in the document?


        --Tom









> ----- Original Message -----
> From: "Alex Zinin" <[hidden email]>
> To: <[hidden email]>
> Sent: Thursday, February 16, 2006 6:02 PM
> Subject: Last Call: draft-fenner-zinin-rtg-standard-reqts-01.txt
>
>
>> 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
>> [hidden email]
>> https://www1.ietf.org/mailman/listinfo/routing-discussion
>>
>>

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Susan Hares
In reply to this post by Alex Zinin
Eric:

I listening to your email thread - but confused.  Can you explain what
you mean by:

        = E.g., it's rather difficult to see why every minor change to a
BG
        Attribute needs special treatment.


I think you have a good point about other Internet protocols (DNS, DHCP,
HTTP, SIP) need to have the same level of documentation and review due
their wide-spread distributed nature.  The IESG should consider making
the bar for acceptance even for these distributed network essential
protocols.

    IE routing bar for entry == DNS, DHCP, HTTP, SIP bar for entry



Sue Hares

-----Original Message-----
From: Eric Rosen [mailto:[hidden email]]
Sent: Monday, February 20, 2006 11:48 AM
To: Bill Fenner
Cc: Alex Zinin; [hidden email]
Subject: Re: Last Call: draft-fenner-zinin-rtg-standard-reqts-01.txt


> I'm sorry, I'm a bit confused here - you have a concern that this
> document quotes RFC2026, or you have a concern with the statement
> that appears in RFC2026?

Yes, to both.

> This document, especially section 3, is intended to give some
> criteria. Under the RFC1264 rules, we didn't even have this,
> so we picked and chose when to apply the rules ourselves, which
> of course is only a problem when we're wrong ;-)

Well, "everything from  a routing area WG" is a  clear enough criterion,
but
it selects many things that don't seem to be crucial to the operation of
the
Internet, that  don't seem to be  "core internet protocols",  and that
might
not even be technically classified as "routing".  Rather than clarifying
the
criteria  for which  submissions need  special  treatment, it  gives up
and
proposes to apply special treatment to  stuff that just doesn't seem to
need
it.

E.g., it's rather difficult to see why every minor change to a BGP
attribute
needs special treatment.

Various peculiar and  time-wasting things really do happen  when these
rules
are  enforced.  To take  a recent  case, IPv6-specific  extended
communities
were added to the BGP extended communities spec in order to satisfy the
rule
that IPv6 not  be ignored.  Then they were removed to  satisfy the rule
that
anything not implemented has to be removed.  This is just making the
authors
run around in circles.  It's hard to see how the presence or absence of
this
kind of  extended community in the spec  makes any difference at  all to
the
health of the Internet.  

With regard to  the other criterion in section  3, "protocols
implementing a
distributed algorithm  whose functional domain  spans more than  one
network
segment ... or otherwise affects the state of the distributed routing
system
or per-hop forwarding behavior", let's see how clear this is.

It seems to me that the "distributed algorithm" criterion as stated
includes
such things as:

- Bittorrent  (if we might  suppose for a  moment that that would  ever
fall
  under the IETF's purview)

- Web-caching and proxying protocols (e.g., akamai)

- DNS

- Mail

- SETI

Is it your  intention that the criterion include such  things?  If not,
then
it's not clear what it is meant to include.

The "per-hop forwarding behavior" criterion would include anything
having to
do with per-hop QoS treatment (Diffserv, RSVP).  Is that your intention?


If these  criteria are taken literally,  they greatly increase  the
scope of
the routing ADs to make demands  on submissions from other area.  This
would
put the routing ADs on a par with the security ADs in terms of their
ability
to delay progress.

The "functional domain spans more than one network segment (link)"
criterion
confuses me.   Does this mean that  special requirements are  not needed
for
those protocols which provide  distributed algorithms that affect
forwarding
state, but  which don't have  a "functional domain"  of more than  one
link?
What would be an example of such a protocol?

> Are you arguing that routing protocols
> shouldn't be considered core Internet protocols, and perhaps we
> should just reclassify RFC1264 as historic, or that this document
> should cover other types of protocols, or that someone else should
> work on another document to cover those other types of protocols,
> or what?

I  don't think a  clear distinction  has been  drawn between  "core
internet
protocols" and others, and I don't think a good case has been made that
core
internet  protocols need special  treatment, or  that the  special
treatment
that  they've been  given  has made  any  difference to  the  health of
the
Internet.  

In  general,  I  do  not  favor   adding  more  red  tape  to  the
process.
Reclassifying 1264 has historical might be a good move though.

> Do  you  have  a  suggestion   for  how  to  classify  these
[extensions]
> objectively?  We've  had trouble  with subjective rules,  which is
why we
> settled on the objective "same as the base protocol"

If the criteria applied to the base protocol were really clear and
technical
(i.e., based on  technical characteristics of the base  protocol rather
than
which Area its WG belongs to),  then why wouldn't the same criteria
would be
applicable to the extensions.

> By "now", do you mean "with the RFC1264 rules", or "with the
> draft-fenner-zinin rules"? We tried to make the criteria a lot more
> concrete in our draft.

When I complain about how things are working "now", I mean with whatever
set
of rules the ADs are now applying.  

I think  the draft-fenner-zinin  rules make things  worse, as it  seems
that
they  try to  require special  treatment for  more things,  rather  than
for
fewer.  Maybe that's the problem in a nutshell.

> while one implementation was written during the development of the new
PIM
> spec, I'm aware of at least one that was written from the spec

I guess I  should only have mentioned the  BGP spec as an example  of a
spec
that no one's every done an implementation from ;-)

> And we got a lot of spec bug reports from that author, validating
> the theory that you learn about the clarity of the spec when you
implement
> from it

That theory is not in dispute!

> if you've  got the 7 items  listed in section  5.1 bullet points 1.  -
7.,
> then  you  can be  pretty  sure that  you've  provided  all the
necessary
> paperwork.

The terms "implementation  experience", "interoperability report", and
"test
scenarios and test  results" are not very clear to me.   If you haven't
done
this before,  I'm not  sure there is  anyplace you  can look that  tells
you
exactly what is required.  And in  many cases, it seems nearly
impossible to
produce this sort  of stuff.  E.g., when you're  advancing a spec
describing
implementations that have been deployed and interoperating for 5 or 6
years,
it's very hard  to produce anything like "test  scenarios and test
results".
That's why I think the paperwork requirements are not particularly
clear.







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





_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Acee Lindem (acee)
In reply to this post by Adrian Farrel(IETF CCAMP WG)
Hi Bill,
Adrian raises an important point. I would hope that if a draft includes
protocol encodings
for both IPv4 and IPv6 and has met the implementation requirements for
one of these, we
could still progress the draft as long as there aren't substantial
differences between the
protocol mechanisms and state machines. In fact, can text to this effect
be added?

Thanks,
Acee

Adrian Farrel wrote:

>Hi,
>
>I think my opposition to the direction of this I-D has been aired, and I
>don't need to repeat my general case. I believe that the increased hurdle
>to PS will either gum up the WGs or will simply cause everything to be
>published as Experimental.
>
>But here are some specific points about this I-D which I don't think was
>ready for last call and doesn't appear to have had any significant review
>(including perhaps by the Routing Area Directorate?)
>
>Eric and Bill's conversation has brought up a point by mentioning IPv6.
>
>Let us imagine a widely implemented and deployed signlaing protocol. It is
>an IETF requirement that such protocol specifications include IPv6. This
>is no problem form the point of view of specification, and would be easy
>to implement, but the fact is that it is not implemented because no-one is
>building or deploying networks that use IPv6 in conjunction with this
>protocol (they may do in the future, but they are not doing so now).
>
>What will happen to the publication request for the I-D that specifies
>this protocol? We will not be able to say that the protocol specification
>has been fully implemented, and there certainly will not be any
>operational experience. Will this result in the RFC publication being help
>up? Does it mean that the I-D must be split into two parts before the main
>body can move forwards?
>
>
>The I-D does not state a proposed status.
>
>In section 3.2 you have (the much discussed)
>   In consultation with the community, the IESG MAY decide to waive some
>   or all of the requirements specified in this document.  A situation
>   where this might be needed is when factors not envisioned in this
>   document arise and applying elevated requirements does more harm than
>   good.
>Why are you making this a full IESG decision? Isn't it enought to delegate
>it to the Routing Area ADs?
>
>Section 4.1 point 2 (and through out). Please say MIB *module* not MIB.
>
>Section 4.1 point 4. What is an interoperable implementation of a MIB
>module?
>
>Progression to DS or S is dependent on implementation and deployment of
>associated MIB modules. I think you are setting yourself up for failure
>and not recognising the way the world is moving wrt SNMP. While the
>specification of the MIB modules is highly desireable, you may find that
>certain protocols do not see wide uptake of SNMP as a management
>technique. Do you propose that such protocols can never become standards,
>or will you invoke section 3.2? (If section 3.2 is to be so easily invoked
>we might as well dispose of this I-D and immediately hand all decisions to
>the IESG!)
>
>Section 5.1 seems at odds with the details in the Proto work. Can I
>suggest that you converge on a common set of information to be supplied at
>publication-request time so that the WG chairs do not have to fiddle about
>collecting different information for different I-D processing procedures.
>
>Section 5. point 2
>This is a change the order of events since previously it has been the ADs
>that have requested the RAD to review documents.
>Please supply details of how the review is actually initiated, how the
>progress of the review is tracked, and how the comments are returned to
>the working group.
>
>Section 5. point 3
>A little more detail about the submission and publication of the
>implementation and interoperability report would be helpful. Is this an
>email to the IETF secretariat? Or perhaps it is an I-D? Where on the IETF
>Web site will this be publicly available?
>
>Section 5 is missing MIB Doctor review
>
>Section 5 is missing appropriate cross-area and cross-WG review.
>
>Section 5.1 says "IETF secretariat" and then lists the IESG Secretary's
>email address. (See Section 5 point 3)
>
>Long-term persistence of reports.
>In several cases we are required to submit reports (implementation,
>interoperability, operational experience, etc.). What is the archival
>process for this? If they are submitted as I-Ds will they be published as
>Informational RFCs to preserve them, or is some other archive proposed?
>
>Section 8 seems to be a tiny bit empty. I'm surprised to see a last call
>with that problem :-)
>
>Use of RFC2119 language. This may or may not be appropriate in this I-D.
>But if you use it you must include 2119 as a reference and use the normal
>2119 boilerplate.
>
>Thanks,
>Adrian
>
>
>_______________________________________________
>routing-discussion mailing list
>[hidden email]
>https://www1.ietf.org/mailman/listinfo/routing-discussion
>
>  
>

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Alia Atlas
In reply to this post by Adrian Farrel(IETF CCAMP WG)
On 2/22/06, Adrian Farrel <[hidden email]> wrote:
> I think my opposition to the direction of this I-D has been aired, and I
> don't need to repeat my general case. I believe that the increased hurdle
> to PS will either gum up the WGs or will simply cause everything to be
> published as Experimental.

I am also concerned about the increased hurdle to PS.  We already have
a problem with drafts being treated as standards; this seems to
increase that problem.

Treating extensions the same as the base protocol seems like overkill
for many of the common extensions.  I don't currently have a good
suggestion for how to split the extensions into those that are of
greater concern & those that aren't.  I would rather see the
extensions be more relaxed by default, with the ability by the WG/WG
chairs/routing ADs to require the elevated requirements when
appropriate.

For the obligatory textual comment, the draft would be clearer to read
if the requirements for each level described "those for the previous
level plus" as is done for the submission requirements.

Alia

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Curtis Villamizar

In message <[hidden email]>
"Alia Atlas" writes:

>  
> On 2/22/06, Adrian Farrel <[hidden email]> wrote:
> > I think my opposition to the direction of this I-D has been aired, and I
> > don't need to repeat my general case. I believe that the increased hurdle
> > to PS will either gum up the WGs or will simply cause everything to be
> > published as Experimental.
>  
> I am also concerned about the increased hurdle to PS.  We already have
> a problem with drafts being treated as standards; this seems to
> increase that problem.
>  
> Treating extensions the same as the base protocol seems like overkill
> for many of the common extensions.  I don't currently have a good
> suggestion for how to split the extensions into those that are of
> greater concern & those that aren't.  I would rather see the
> extensions be more relaxed by default, with the ability by the WG/WG
> chairs/routing ADs to require the elevated requirements when
> appropriate.
>  
> For the obligatory textual comment, the draft would be clearer to read
> if the requirements for each level described "those for the previous
> level plus" as is done for the submission requirements.
>  
> Alia


Alia,

A bigger problem is carriers, particularly far east and third world,
who point to anything remotely resembling a standard and wanting it
implemented, sometimes not even understanding what it is supposed to
do or how it works.

Lowing the bar for something to be called a standard won't help.  I'd
rather see a smaller set of standards that really do work than a large
set of ideas standardized, many of which eventually prove not to work.

My favorite example within IETF has always been NHRP.  Another from
outside the IETF is OIF UNI.  Another is the ITU's MPLA OAM, where the
authors didn't like the IETF rigorous process so they went elsewhere
so they could get a rubber stamp on it.  There is a long list of
"standards" that never should have been accepted.

What you are suggesting would make it easier for any of those or
future bad ideas to become IETF PS.  There is a very long list of
proposed extensions to BGP alone.  Its almost certain that some
percentage of them will never be implemented or will prove to not be
useful.  The RFC collection is cluttered enough already without dozens
of protocol extensions that don't work (or dozens more).

Curtis

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Alia Atlas
Curtis,

On 2/22/06, Curtis Villamizar <[hidden email]> wrote:
> A bigger problem is carriers, particularly far east and third world,
> who point to anything remotely resembling a standard and wanting it
> implemented, sometimes not even understanding what it is supposed to
> do or how it works.
>
> Lowing the bar for something to be called a standard won't help.  I'd
> rather see a smaller set of standards that really do work than a large
> set of ideas standardized, many of which eventually prove not to work.

We aren't talking about lowering the bar - but raising it from
requiring one implementation to requiring two.  I agree that we want
ideas standardized that really do work.

If drafts take even longer to get standardized because of more
hurdles, that makes
it more likely that many drafts will be treated as defacto standards,
that will be requested
for implementation also.

> My favorite example within IETF has always been NHRP.  Another from
> outside the IETF is OIF UNI.  Another is the ITU's MPLA OAM, where the
> authors didn't like the IETF rigorous process so they went elsewhere
> so they could get a rubber stamp on it.  There is a long list of
> "standards" that never should have been accepted.

Sure.  There are always those who go elsewhere to get rubberstamped.

> What you are suggesting would make it easier for any of those or
> future bad ideas to become IETF PS.  There is a very long list of
> proposed extensions to BGP alone.  Its almost certain that some
> percentage of them will never be implemented or will prove to not be
> useful.  The RFC collection is cluttered enough already without dozens
> of protocol extensions that don't work (or dozens more).

For extensions, I am not suggesting that an implementation isn't
required.  It is the
elevated requirement of needing two implementations that I am questioning.

Alia

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Eric Rosen
In reply to this post by Curtis Villamizar

Curtis> I'd rather see a smaller set of standards that really do work than a
Curtis> large set of ideas standardized,  many of which eventually prove not
Curtis> to work.

A laudable  goal.  However, since  bad ideas frequently have  multiple early
implementations,  and good ideas  can be  slow to  catch on,  requiring more
implementations and/or deployments is not going to help us meet this goal.




_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Curtis Villamizar

In message <[hidden email]>
Eric Rosen writes:
>  
>  
> Curtis> I'd rather see a smaller set of standards that really do work than a
> Curtis> large set of ideas standardized,  many of which eventually prove not
> Curtis> to work.
>  
> A laudable  goal.  However, since  bad ideas frequently have  multiple early
> implementations,  and good ideas  can be  slow to  catch on,  requiring more
> implementations and/or deployments is not going to help us meet this goal.


I'm sure the ratio of bad ideas with multiple implementations to bad
ideas with single implementations or no implementations is quite high.

Therefore raising the bar will not entirely eliminate bad ideas, just
reduce the number of bad ideas that become standards within the IETF.

Curtis

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

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

Eliot Lear
Curtis Villamizar wrote:
> I'm sure the ratio of bad ideas with multiple implementations to bad
> ideas with single implementations or no implementations is quite high.
>
> Therefore raising the bar will not entirely eliminate bad ideas, just
> reduce the number of bad ideas that become standards within the IETF.
>  

And so now I have two problems with this document:

    * People with GOOD ideas may not wish to deal with the IETF if the
      bar is explicitly raised.  It's already pretty high, which is why
      we have seen a plethora of SDOs over the last few years.
    * And *still* this document is redundant.  The IESG should already
      feel free to demand implementation experience prior to letting a
      really sensitive change go through.  Heck, this is how
      internet-drafts are used today, anyway.

Eliot

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