Subject: RE: Obsoleting RFC 1264?

From: "Margaret Wasserman" <[email-masked]>
Date: Thu, 1 Jun 2006 09:13:07 -0400

Having seen the difficulties caused by RFC 1264 from several perspectives, I
support Bill's proposal to obsolete it.

I believe that these policies were very valuable at the time they were
written, but that they no longer provide benefits that outweigh their costs.

Margaret 

> -----Original Message-----
> From: Bill Fenner [mailto:[email-masked]] 
> Sent: Wednesday, May 31, 2006 8:40 PM
> To: [email-masked]
> Subject: Obsoleting RFC 1264?
> 
> 
> [I've bcc'd this message to the int-area list, but I'd like 
> the discussion to occur on the Routing area list.
> There's not much other traffic on the Routing area list so I 
> encourage int-area subscribers to pick it up for this thread.]
> 
> Dear friends,
> 
>   There was quite a bit of discussion at the last IETF 
> meeting, in the Routing Area and Internet Area meetings, 
> about draft-fenner-zinin-rtg-standard-reqts.  The discussion 
> was quite split, with strenuous arguments on both sides of 
> the issue.  I'd like to float the opposite plan as a trial
> balloon: declare RFC1264 obsolete.  I believe that
> a) the existing (business, etc.)  incentives against 
> deploying something prematurely in the Internet are sufficient, and
> b) the lack of an RFC doesn't prevent something's deployment.
> 
>   All the rules serve to do is to increase the work on the 
> working groups and the ADs, and make the IETF appear to be a 
> bureaucratic organization that makes it difficult to publish 
> good ideas.  The barriers against bad ideas are still in place:
> - The judgement of the Working Group
> - The judgement of the IESG
> - The IESG [presumably delegating the task to the Routing ADs]
>   can still ask for implementation/deployment experience if
>   it appears to be needed.
> 
> I have just spent too long watching the barriers work against 
> good ideas.
> 
>   Bill
> 
> ----- Begin forwarded message:
> 
> From: [email-masked]
> Subject: I-D ACTION:draft-fenner-obsolete-1264-00.txt
> Date: Wed, May 31 12:50:02
> To: [email-masked]
> Reply-to: [email-masked]
> 
> 
> 	Title		: RFC 1264 is Obsolete
> 	Author(s)	: B. Fenner
> 	Filename	: draft-fenner-obsolete-1264-00.txt
> 	Pages		: 5
> 	Date		: 2006-5-31
> 	
> RFC 1264 was written during what was effectively a completely
> different time in the life of the Internet.  It prescribed rules to
> protect the Internet against new routing protocols that may have
> various undesirable properties.  In today's Internet, there are so
> many other pressures against deploying unreasonable protocols that we
> believe that existing controls suffice, and the RFC 1264 rules just
> get in the way.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-fenner-obsolete-1264-00.txt
> 
> ----- End forwarded message:
> 
> _______________________________________________
> 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

---

From: "Mark Handley" <[email-masked]>
Date: Thu, 1 Jun 2006 14:23:54 +0100

On 6/1/06, Bill Fenner <[email-masked]> wrote:
> Dear friends,
>
>   There was quite a bit of discussion at the last IETF meeting,
> in the Routing Area and Internet Area meetings, about
> draft-fenner-zinin-rtg-standard-reqts.  The discussion
> a) the existing (business, etc.)  incentives against deploying
> something prematurely in the Internet are sufficient, and

I agree.  Most RFCs already take long enough without dragging the
process out further.  And I rarely see vendors rushing to support a
routing protocol just because it became an RFC :-)

 - Mark

---

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Jun 2006 10:35:15 -0400

I'd also like to express my support for Bill's proposal.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 01 Jun 2006 10:54:23 -0400

Bill,
I support this proposal as well - we'll have to find something
new to argue about at the Routing Area meetings :^)

Thanks,
Acee

---

From: Bob Hinden <[email-masked]>
Date: Thu, 1 Jun 2006 08:57:07 -0700

Bill,

> balloon: declare RFC1264 obsolete.

I support this.  It made sense back in 1991 when it was published,  
but things have changed a lot and I agree it is no longer necessary.

Bob

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 1 Jun 2006 22:04:16 +0200

> b) the lack of an RFC doesn't prevent something's deployment.

Seems reasonable.

- kurtis -

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 1 Jun 2006 16:12:12 -0400

Bill, thank you.  Yes, put a fork in 1264, it's done.

--John

---

From: JP Vasseur <[email-masked]>
Date: Thu, 1 Jun 2006 19:50:16 -0400

Hi Bill,

In favor.

Thanks.

JP.

On May 31, 2006, at 8:40 PM, Bill Fenner wrote:

>
> [I've bcc'd this message to the int-area list, but I'd
> like the discussion to occur on the Routing area list.
> There's not much other traffic on the Routing area list
> so I encourage int-area subscribers to pick it up for
> this thread.]
>
> Dear friends,
>
> working groups and the ADs, and make the IETF appear to be
> a bureaucratic organization that makes it difficult to publish

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 2 Jun 2006 00:08:00 -0700 (PDT)

On Wed, 31 May 2006, Bill Fenner wrote:

> I'd like to float the opposite plan as a trial

Whoa!  A major attack of sanity!

Bill, I commend you on your courage in reversing course.  Really.

Kireeti.
-------

---

From: Ari Ollikainen <[email-masked]>
Date: Fri, 2 Jun 2006 07:05:47 -0700

>b) the lack of an RFC doesn't prevent something's deployment.

	I concur...

-- 

  _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
  You can't depend on your judgement when your imagination is out of focus.
						          -- Mark Twain.
  _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

        OLTECO                    Ari Ollikainen
        P.O. BOX 20088            Technology Consulting
        Stanford, CA              [email-masked]
        94309-0088                415.517.3519

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 3 Jun 2006 15:54:20 +0100

Yes, indeed.

Many thanks for this initiative.  Fully supported.

Adrian

---

From: [email-masked]
Date: Sat, 3 Jun 2006 19:16:57 +0200

hi bill

- in favor - sensible initiative.

d.

Bill Fenner <[email-masked]>
01/06/2006 02:40
 
        cc: 

Dear friends,

  Bill

                 Title                           : RFC 1264 is Obsolete
                 Author(s)               : B. Fenner
                 Filename                : 
draft-fenner-obsolete-1264-00.txt
                 Pages                           : 5
                 Date                            : 2006-5-31

---

From: Alex Zinin <[email-masked]>
Date: Sat, 3 Jun 2006 12:05:21 -0700

Glad to see consensus forming on this. Interestingly, we didn't have it a
few years back when it was first suggested. Apparently, discussion about
1264bis has put things in perspective :)

Let's try this and see how well this works.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 01 Jun 2006 12:48:53 -0400

In message <[email-masked]>
> routing protocol just because it became an RFC :-)

I'm not in favor of obsoleting rfc1264 if it means we'll be letting
protocols that are not implented and at least some deployment
experience.  There are enough junk RFCs without making it easier to
add more of them.

Its way too easy to go off and define a protocol that looks like it
will work.  Its a lot harder to implement it and prove that it works
in the field.  That is the value in keeping rfc1264.

Curtis

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 4 Jun 2006 11:58:45 -0400

I would like to join the consensus in supporting obsoleting RFC 1264.
The arguments below for retaining it have nothing to do with routing and
are really arguments for changing the standards levels structure of all
of the IETF. As such, they seem more relevant to the NEWTRK working
group.

Donald

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Thursday, June 01, 2006 12:49 PM
To: Mark Handley
Cc: Bill Fenner; [email-masked]
Subject: Re: Obsoleting RFC 1264? 

"Mark Handley" writes:
> >   There was quite a bit of discussion at the last IETF meeting, in 
> > the Routing Area and Internet Area meetings, about 
> > draft-fenner-zinin-rtg-standard-reqts.  The discussion was quite 
> > split, with strenuous arguments on both sides of the issue.  I'd 
> > like to float the opposite plan as a trial

I'm not in favor of obsoleting rfc1264 if it means we'll be letting
protocols that are not implented and at least some deployment
experience.  There are enough junk RFCs without making it easier to add
more of them.

Its way too easy to go off and define a protocol that looks like it will
work.  Its a lot harder to implement it and prove that it works in the
field.  That is the value in keeping rfc1264.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 04 Jun 2006 12:41:35 -0400

In message <[email-masked]>
> of the IETF. As such, they seem more relevant to the NEWTRK working

What is being proposed it a change to the way routing protocols are
handled within the IETF.  The reason for doing this for routing and
not for all IETF standards is that interoperability problems with
routing protocols could have a widespread impact, even global impact.
A user service with interoperability problems (for example) would only
mean that end users would have to use some other service, which is bad
but doesn't impact the infrastructure.

The changes makes IETF procedures more like ITU procedures where there
is no requirement for implementation (but doesn't go that far).  ITU
has a terrible track record for *deployed* routing protocols.  ITU has
wasted a lot of engineers' time writing protocols that seemed like
they would be simple enough and work but proved otherwise.

Relax the procedures too far and we'll end up standardizing junk.

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Sun, 4 Jun 2006 19:44:58 -0700

Curtis,

  In my AD practice, there were a few cases where the implementation
  requirement really made a difference. Fortunately, these are typically
  easily identifiable and the AD still has the right to request
  implementations in those cases according to 2026.

---

From: mike shand <[email-masked]>
Date: Mon, 05 Jun 2006 10:13:35 +0100

Bill,
         Add my name to the ever growing list in support of your 
proposal. It seems absolutely the right thing to do.

         Mike

---

From: Eliot Lear <[email-masked]>
Date: Mon, 05 Jun 2006 11:17:42 +0200

Curtis,

Two things:

It seems to me that WG chairs and ADs are more reticent to sanction work
where they see no engineering behind it.  This has been the case even
for stuff I thought was crap, but for other stuff too.

Further, it seems to me, particularly in the area of MPLS, that stupid
interoperability problems have developed because of this policy when
vendors did their own implementations and deployed them throughout the
network.  Thus far it's been dumb things like error codes but you could
easily imagine worse.  The point is that nobody waits for the WG to
start, much less finish, so what does this document buy?

Eliot

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 05 Jun 2006 09:36:58 -0400

> start, much less finish, so what does this document buy?

MPLS FRR is a good example.

Some would argue that a common spec was needed much earlier.  If we
had done that it would very likely have been based entirely on the
detour method (one-to-one) simple because it was there first.  The
work didn't go forward mostly because of the limited interoperability.
The original implementations of the bypass method (facilities) was
challenged and didn't get deployed for a long time.  The facilities
method does turn out to be the preferred method since it requires less
LSPs but as long as the bypass tunnesl can be set up automatically as
needed.  The detour method does not require a platform label space.

This is an example of vendors doing their own thing but in the end the
IETF process worked.  The FRR spec accomodates both methods.  I think
at this point most of the major players support both methods.
Providers seem to be leaning toward the bypass method.  Had we rushed
through the IETF process we'd have FRR using detour only and possibly
a later separate doc supporting bypass.

Some people think that as soon as the ink dries we should RAM specs
through as long as people voice support for it.  I don't agree.

With the current procedures vendors will experiment with specs before
they are accepted and there will be a lot of failed experiments.  Only
the ones that work get standardized.  Lighten the requirements too
much and we'll be standardizing things that don't work.  We don't need
more RFC1577s or NHRP.  The IETF IP over ATM and related WGs was a
nightmare with lots of proposals that are dead now and a few that went
through that are RFCs that never went anywhere.  We have seen multiple
generations of telco engineer trying to reengineer the Internet, from
the days of IPLDN (IP over Large Data Network) to ATM to today.  Most
of that work has been a complete failure.  If anything we've already
let too much slip through that either never got deploued or failed.
There are only a few cases of specs that were never implemented but
very many where they were not deployed or had limited deployment and
failed (very often for reasons that had already been predicted).

Curtis

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 5 Jun 2006 22:42:26 -0400

See below at @@@ 

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Sunday, June 04, 2006 12:42 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: Obsoleting RFC 1264? 

In message <[email-masked]>
"Eastlake III Donald-LDE008" writes:
> The arguments below for retaining it have nothing to do with routing 
> and are really arguments for changing the standards levels structure 
> of all of the IETF. As such, they seem more relevant to the NEWTRK 
> working group.
>  
> Donald

handled within the IETF.  

@@@ Believe it or not I do understand, or at least think I understand,
what this discussion is about.

The reason for doing this for routing and not for all IETF standards is
that interoperability problems with routing protocols could have a
widespread impact, even global impact.
A user service with interoperability problems (for example) would only
mean that end users would have to use some other service, which is bad
but doesn't impact the infrastructure.

@@@ I am aware of this theory but your message, to which I was
responding, did not mention it and contained only generic IETF
standardization statements, more suitable for NEWTRK. In any case, I
don't believe that the mere demonstration of interoperability makes that
much difference to the probability of the existence of obscure perverse
behavior modes or the difficulty of people who are anywhere along the
spectrum from incompetent implementers to brilliant malefactors from
producing implementations that will try to screw things up. As well as
all the other factors that have been mentioned, such as the strong
motivation for ISPs to deliver bits since they are unlikely to be paid
if they fail in this, there is also the ever increasing attention being
given to security hardening of the network to defend against attacks.
The DNS is globally distributed, there is no evidence it has had any
more problems than routing, but it never had the RFC 1264 restriction.

The changes makes IETF procedures more like ITU procedures where there
is no requirement for implementation (but doesn't go that far).  ITU has
a terrible track record for *deployed* routing protocols.  ITU has
wasted a lot of engineers' time writing protocols that seemed like they
would be simple enough and work but proved otherwise.

@@@ Sounds good. I hope the ITU will continue to occupy engineers
willing to work on bad routing protocols so only those who want to work
on good routing protocols are active in the IETF. :-)

@@@ Seriously, I think the main difference is that in groups like the
ITU and the IEEE, a working group is a very expensive ponderous thing
while in the IETF they are relatively (and I emphasize this is only
relative) light weight. Sure, many more IETF WGs fail and the heavy
weight model increases the probability that a working group will produce
some document, nicely typeset and edited, more or less on schedule, but
it sure doesn't guarantee it will always be useful. I prefer the light
weight IETF model which, in my opinion, includes the relatively low
threshold for the lowest rung of the standardization ladder. And I think
that the relatively greater success of IETF protocols over the long run
supports my inclination.

@@@ I just don't see it being much of a problem, with routing having
achieved its current state of maturity. And even if a new junk routing
protocol should achieve the status of Proposed Standard, why would this
really be such a problem? Seems like it would provide an excellent
opportunity for many academic papers analyzing its weaknesses...

Curtis

@@@ Donald

> In message 
> <[email-masked]>
> "Mark Handley" writes:
> >  

> protocols that are not implanted and at least some deployment

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 06 Jun 2006 17:06:59 -0400

In message <[email-masked]>

> See below at @@@ 

My comments inline.  Trimmed your response.

> on good routing protocols are active in the IETF. :-)

Nice to know we agree on something.  Unfortunately the IETF has
already been infiltrated.  :-)

> that the relatively greater success of IETF protocols over the long run

The ITU has evolved considerably since the CCITT days when the DoD was
the official US representation and they essentially deferred to AT&T
which made for an interesting situation when MFJ split AT&T in 1984.

It is still very much a place for big company politics and votes cast
by members with deep pockets based on their own internal company
politics.  Doesn't and never will work well IMHO.

> opportunity for many academic papers analyzing its weaknesses...

I see this a problem with RFC clutter and people not "in the know" not
being able to separate the junk from the essential RFCs.

I also see this as a problem for vendors that get RFPs with the junk
protocol in the list of required features because it had an IETF
blessing.  Some RFPs read like "we want you to implement everything
ever standardized whether we understand what its for or not as long as
it sounds like something we might someday want to use".  This is often
the product of an "RFP writing team" that cranks out 100+ page RFPs for
a living.  That's only a problem when you are on the receiving end of
one of these.

> @@@ Donald

I'm in the minority on this and we do still beleive in rough
consensus.  So although I am expressing my opinion on this I will very
likely have to accept an outcome that is not what I'd like it to be in
this case.

Regards,

Curtis

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 6 Jun 2006 17:10:39 -0500

> > willing to work on bad routing protocols so only those who want
> > to work on good routing protocols are active in the IETF. :-)

> > @@@ Seriously, I think the main difference is that in groups like
> > the ITU and the IEEE, a working group is a very expensive 
> > ponderous thing while in the IETF they are relatively (and I
> > emphasize this is only relative) light weight. Sure, many more
> > IETF WGs fail and the heavy weight model increases the
> > probability that a working group will produce some document,
> > nicely typeset and edited, more or less on schedule, but it sure
> > doesn't guarantee it will always be useful. I prefer the light
> > threshold for the lowest rung of the standardization ladder. And I
> > think that the relatively greater success of IETF protocols over 
> > the long run supports my inclination.

> politics.  Doesn't and never will work well IMHO.

Same old Curtis who answered by first post to IETF in 1998 (déjà vu all over again).  

With all due respect, are all the ITU protocols, e.g. in http://www.itu.int/ITU-T/50/vote.html in the junk category, to remain forever in the dog pound?

Regards,
Jerry

---

From: "Janet Plato" <[email-masked]>
Date: Tue, 6 Jun 2006 17:53:50 -0500

I am against this proposal simply because complex things
sometimes fail in bynzantine ways, and operational experience
is how you find out.  Witness OSPF v1's problem with the
LSP state space.

But a lot of people I respect are in favor of it, and of the
nay votes, I only know one of them, but his voice carries
a lot of weight with me (Curtis).

I hate to make people retread old issues, but I am curious
what experiences have made people want to ditch the
rigor of RFC 1264.  It seems to me giving directors the
option of requiring operational experience is not really
the same as requiring operational experience.  Since
requiring something optional makes you look hard nosed,
I figure in practice not a lot of folks are going to be forced
to run their protocols through an operational phase since
the directors are not going to want to look needlessly
difficult.

If anyone if favor can provide pointers to materials, or summations
of their personal experiences with RFC1264 making things needlessly
difficult I would be interested.  If the answer is RTFA (A== mailing list
archive) that's OK too, but since this thread started with a comment about
how people had a discussion and much thought was exchanged, I
figured it was reasonable to ask.

Regards,

Janet Plato
In theory, there's no difference between theory and practice.
In practice, there is a difference.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 07 Jun 2006 17:00:40 -0400

In message <[email-masked]>
"Ash, Gerald R \(Jerry\), ALABS" writes:
>  
>  
> With all due respect, are all the ITU protocols, e.g. in
> http://www.itu.int/ITU-T/50/vote.html in the junk category, to remain
> forever in the dog pound?
>  
> Regards,
> Jerry

Of course not.  ITU is where many link layer protocols used in
telecommunication are defined.  Its when they get above layer 2 that
too often the result is junk.

Even at layer-1 and layer-2 not every ITU protocol is very good.  In
some cases its what we have to live with.

Sometimes things need a little fixing like the SONET scrambling that
repeated every 128 bits if you remember when Internet providers first
started using POS.  Too often 10% of the defined protocol proves
useful in the long run.  For example carriers have been moving away
from SONET protection for many years now.  Advances in 10GbE and
emergence of 40GbE and 100GbE may mean the end of SONET except as a
legacy service (much as FR and ATM are today).  The majority of use of
OC192 is OC192c as a link layer for POS and interest in OC768 seems
limited.  We'll have to wait and see.

Then there are things like X.25 and ISDN.

On the bright side above layer-2 is the widespread acceptance of X.509
PKE for SSL key distribution.  Again a fraction of the protocol is
used and not for its original purpose much as is the case in ISO 10589
(ISIS if I have the number right).

Not every IETF spec is any good either, though at layer-3 IETF has a
much better track record of defining usable protocols.  IETF has a
small problem in that the RFC collection is already cluttered with
4,000 going on 5,000 documents.  Many critical protocols are at the PS
level where it is already very difficult for newcomers and even the
moderately experienced to distinguish junk from essential documents.

Fortunately OSPF is at full standard and BGP is now at draft standard
but does that mean the ISIS work can be ignored.  Definitely not.
These are just examples.  There are plenty of PS documents that are
essential and many that simply don't work well.  Gradually we declare
the latter to be historic but in some cases they should have never
made PS.

Curtis

---

From: Stephen J Trowbridge <[email-masked]>
Date: Wed, 07 Jun 2006 15:26:32 -0600

Curtis,
The broken mapping you are describing for POS came from IETF (RFC 1619), fixed
later in RFC 2615. AFAIK, the mappings defined by ATIS or ITU-T for carrying
clients over SONET or SDH all worked. By the way, SONET came first from Bellcore
(remember GR-253), picked up later by T1X1(now called OPTXS) (ATIS) in the
T1.105 series. Original SDH came from ETSI. The current ITU-T SDH standard is a
superset of SONET and ETSI SDH, but there never was an ITU-T spec for SONET.

I think we see a pattern here (see also Jonathan's posting regarding ISO routing
standards): if Curtis doesn't like something, it must have come from ITU-T.
Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 07 Jun 2006 19:53:33 -0400

In message <[email-masked]>
Stephen J Trowbridge writes:
>  
> Curtis,
>  
> The broken mapping you are describing for POS came from IETF (RFC
> 1619), fixed later in RFC 2615. AFAIK, the mappings defined by ATIS or
> ITU-T for carrying clients over SONET or SDH all worked. By the way,
> SONET came first from Bellcore (remember GR-253), picked up later by
> T1X1(now called OPTXS) (ATIS) in the T1.105 series. Original SDH came
> from ETSI. The current ITU-T SDH standard is a superset of SONET and
> ETSI SDH, but there never was an ITU-T spec for SONET.

RFC1619 says "no scrambling is needed".  The reason for that was the
SONET already does scrambling.

I distinctly remember BBN folks (in particular John Hawkinson) arguing
at an IETF meeting that the scrambling used by Lucent at the time
already had been proven in the field not to be adequate with a brief
experiment that resulted in data on a single OC3c POS interface taking
down and entire OC48c.  That occurred somewhere between RFC1619 and
RFC2615 when the scrambiling offered by SONET was being used and the
problem occurred in the BBN/Planet network with Lucent gear.

RFC1619bis with scrambling enabled existed as a draft for a very long
time.  RFC2615 specifies the use of 43 bit scrambling.  Unless I'm
mistaken it was decided to put the scrambling in the router to
accommodate transport gear that didn't scramble adequately.

Anyway SONET is definitely not my area of expertice.  I was mostly
woking in Internet operations at the time and not involved at L2
except to configure the routers to specify scrambling.  Perhaps I
should talk to Andy Malis or Bill Simpson.

btw- Yes I know that SONET came from Bellcore but I was mistaken in
that ANSI specified SONET when this problem occurred.  I think the
problem we are talking about was identified by BBN in the 1994 to 1996
time frame.

> I think we see a pattern here (see also Jonathan's posting regarding
> ISO routing standards): if Curtis doesn't like something, it must have
> come from ITU-T.  Steve

As I said ITU does useful L1/L2 work.  Sorry to attribute SONET to
ITU at a time when ANSI handled that.

We are clearly drifting off topic.  The topic was RFC 1264.

Curtis

---

From: Bill Fenner <[email-masked]>
Date: Wed, 14 Jun 2006 14:39:34 -0700

Janet,

  My apologies for taking so long to reply.

>rigor of RFC 1264.

One problem is that it's not particularly clear what's
a routing protocol.  Should l2vpn and l3vpn's developments
be held to these standards?  How about forces?  vrrp?
"It should be obvious" until it's not and it's just a
matter of judgement.  Is something a routing protocol
because it's developed in the routing area?  Is something
not a routing protocol because it's developed outside the
routing area?

It also takes away our ability to specify things that we
know we'll need but just not yet - e.g., 4 byte ASes
languished for a few years waiting for implementations;
it's easy to imagine some IPv6 extensions that might
trivially be specified ("carry the address in 16 bytes
instead of 4") but not standardized because of these rules.
Imagine the conflicting requirements: IESG says you must
support IPv6, and security; 1264 says that if it's not
implemented it can't be standardized; you have a MUST and
a MUST NOT meeting, which is the immovable object and
which is the irresistable force?

>difficult I would be interested.

I've heard that people look at writing up implementation reports as:
1) make-work
2) a snapshot of implementation status at a point in time
   which may be used against you in the future -- e.g.,
   "The implementation report says that vendor C doesn't
    implement feature foo, but vendor J does, so let's use
    that in our purchasing decision".

So even for something that's implemented, it can be hard to get
an implementation report.

  Bill

---

From: "Janet Plato" <[email-masked]>
Date: Wed, 14 Jun 2006 22:39:36 -0500

Thanks Bill,

I needed to chew on this a little bit before replying.  I can definitely
see how implementation experience, when written into an RFC,
should be obviously a snapshot in time, but could end up being
used against one later.  As for the issue of defining a routing protocol
vs non-routing protocol for RFC 1246 purposes, it *seems*
obvious to me, which usually means I have not thought it through.
;-)

It seems that RFC2026 provides one stop shopping for standards
approvals, and makes the desirability of operational experience
abundantly clear.

You've sold me.

Cheers,

Janet Plato

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 15 Jun 2006 14:25:22 -0400

> which is the irresistable force?

Yes and IPv6 is the source of a lot of unimplemented junk.  Amazing
how providers argued against such things as link local addresses and
this was standardized and eventually depricated.

With regard to IPv6 IESG is acting like ISO with the OSI protocols.
Standardize anything that seems to be a good idea at the time and
don't worry about implementations let alone interoperability.

> an implementation report.

Maybe that's an argument to allow vendor C in your example to insist
the implementation report be updated as features are completed.  It
should be possible to insure that there is nothing to prevent an
update to the implementation report.

Besides reality is customers read the RFP response freshly prepared
just for them, not a year old RFC (or many years old).  When making
multi-million dollar purchases customers also don't take anyones word
for it and test the products themselves and do field trials, etc.

Curtis