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

From: Bill Fenner <[email-masked]>
Date: Sun, 19 Feb 2006 10:48:03 -0800

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

---

From: Eric Rosen <[email-masked]>
Date: Mon, 20 Feb 2006 11:47:38 -0500

> document quotes RFC2026, or you have a concern with the statement

Yes, to both. 

> 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

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. 

> draft-fenner-zinin rules"? We tried to make the criteria a lot more

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