Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd)

I support the adoption of this.  It should go quickly.

I suggest a few changes though:

:   In the modern terminology, the term "route server" refers to a
:   designated, normal BGP speaker set up for specific purposes such as
:   data collection or retrieval; such route servers do not implement RFC
:   1863.  For clarity, in the context of this document the term "RFC
:   1863 route server" is used to refer to a route server as specified in
:   RFC 1863.

In "modern teminology", route servers are actually route servers in
the traditional proxy routing sense.  The current route collectors have,
IMO, co-opted the term.  So, I'd suggest something along these lines:

By common usage, a "route server" can refer to one of two things:
A "routing proxy" such as that used in the early NSF-Net at the
NAPs or a "route collector" which is used for routing data collection
and retrieval.  The latter case is also called a "looking glass".

Neither form of these route servers had implemented RFC 1863.  

For clarity, in the context of this document, the term "RFC 1863
route server" is used to refer to a route server as specified in RFC 1863.

:    Implementations of RFC 1863 route servers do not exist, and are not
:    used as an alternative to full mesh routing.  Therefore the RFC 1863
:    route server concept is considered extinct and RFC 1863 is requested
:    to be moved to Historic status.

If something is extinct, should it not have lived before?  

Minor tweaks suggested:

Implementations of RFC 1863 route servers do not exist and are not
used as an alternative to full mesh routing.  Therefore RFC 1863
is requested to be moved to Historic status.

:   The most common technique as an alternative to full mesh routing is
:   to use BGP route reflectors [2].  Conferedations [3] and/or dividing
:   the autonomous system to multiple private AS numbers have also been
:   used.  IDRP itself has never been standardized by the IETF and can be
:   considered obsolete.

Two comments here aside from some punctuation suggestions:
1. Do people typically deploy private AS's outside of a confederation
   context?
2. While IDRP never made it as an IETF specification, I believe it is
   still a valid ISO specification and thus our opinion of its obsolteness
   isn't so important.  I'll let Sue comment on this.

Suggested changes:

Current techniques that serve as an alternative to full mesh routing
include BGP Route Reflectors [2] and BGP Confederations [3].

Do [2] and [3] need to be made Normative references in this document?

Additionally (Danny), RFC 3065-bis needs to make sure RFC 1863 is used
as an Informative Reference.

If the updates to RFC 2796 and 3065 get published after this, we should
make sure they reference this memo.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr