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

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Feb 2006 09:11:06 -0700

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:[email-masked]] 
Sent: Monday, February 20, 2006 11:48 AM
To: Bill Fenner
Cc: Alex Zinin; [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

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