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

From: Bill Fenner <[email-masked]>
Date: Mon, 20 Feb 2006 09:11:15 -0800

>> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Eric Rosen <[email-masked]>
Date: Tue, 21 Feb 2006 12:46:57 -0500

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.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Feb 2006 13:16:07 -0000

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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 22 Feb 2006 13:49:01 -0500

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

---

From: "Alia Atlas" <[email-masked]>
Date: Wed, 22 Feb 2006 12:15:59 -0800

> 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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 22 Feb 2006 16:17:15 -0500

> level plus" as is done for the submission requirements.

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

---

From: "Alia Atlas" <[email-masked]>
Date: Wed, 22 Feb 2006 13:40:04 -0800

Curtis,

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

> "standards" that never should have been accepted.

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

> 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

---

From: Eric Rosen <[email-masked]>
Date: Wed, 22 Feb 2006 17:53:03 -0500

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 22 Feb 2006 19:49:54 -0500

> 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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Feb 2006 10:34:32 +0100

> 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

---

From: Eric Rosen <[email-masked]>
Date: Fri, 24 Feb 2006 11:43:48 -0500

Acee> I would hope that if a draft includes protocol encodings for both IPv4
Acee> and IPv6 and has met the implementation requirements for one of these,
Acee> we could still progress the  draft as long as there aren't substantial
Acee> differences  between the  protocol mechanisms  and state  machines. In
Acee> fact, can text to this effect be added? 

What would be the grounds for giving IPv6 this special exemption? 

We  could  have  a general  exemption  for  anything  that doesn't  cause  a
substantial change  in protocol procedures  and state machines.   That would
make sense, and  though there will sometimes be  disagreements on what falls
into that category, that exemption would apply to more than just IPv6. 

Or I  suppose we  could have a  general exemption  for things that  the IESG
makes us put  in but nobody really wants; that sort  of exemption would help
us with a lot of the "mandatory to implement" security features.

If exemptions are  allowed, the draft needs to  state the general principles
behind the exemptions, it shouldn't just have a list of exemptions.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 24 Feb 2006 12:34:26 -0500

> What would be the grounds for giving IPv6 this special exemption? 

It has very little operational impact?  :-)

> behind the exemptions, it shouldn't just have a list of exemptions. 

This is a legitimate topic.  Protocol documents want IPv6
considerations to be included in virtually anything done in the IETF
but it is harder to find implementations for the IPv6 part of some
protocols and it is nearly impossible to find deployments of some
protocols that are widely used in IPv4.  The IPv6 usage may lag by
many years.

Do we declare the IPv6 portion of the protocol to not meet the
requirements for routing protocols and remove them?  Do we put them in
separate companion documents so as not to interfere with the progress
of the IPv4 portion?  Or could we exempt the IPv6 portion as an
experiment in progress that we'd like to support?  There is nothing
wrong with calling something an experiment.  For example, the NFSNET
was in its time considered an experiment, one that succeeded.

I prefer either the latter (exempt IPv6) or separating the base and
IPv4 and IPv6 parts of documents and allowing them to progress
somewhat independently.

Curtis