Re: Last Call for draft-ietf-rolc-apr-00.txt

Curtis Villamizar <curtis@ans.net> Wed, 25 October 1995 19:20 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16389; 25 Oct 95 15:20 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa16385; 25 Oct 95 15:20 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id OAA17433; Wed, 25 Oct 1995 14:37:06 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id OAA27840 for rolc-out; Wed, 25 Oct 1995 14:47:14 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id OAA27831 for <rolc@nexen.com>; Wed, 25 Oct 1995 14:47:11 -0400
Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id OAA17425 for <rolc@nexen.com>; Wed, 25 Oct 1995 14:35:40 -0400
Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id OAA17843; Wed, 25 Oct 1995 14:46:28 -0400
Message-Id: <199510251846.OAA17843@brookfield.ans.net>
To: Yakov Rekhter <yakov@cisco.com>
cc: curtis@ans.net, rolc@nexen.com
Reply-To: curtis@ans.net
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
In-reply-to: Your message of "Tue, 24 Oct 1995 16:46:55 PDT." <199510242346.QAA26631@hubbub.cisco.com>
Date: Wed, 25 Oct 1995 14:46:27 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

In message <199510242346.QAA26631@hubbub.cisco.com>om>, Yakov Rekhter writes:
> Curtis,
> 
> > It seems you want a term that covers the case where there is an
> > address prefix that covers the NBMA network exactly.  I'll argue that
> > this is a special case of an NBMA, so if anything, a separate term is
> > needed so we can still talk about NBMA in which the is no address
> > prefix that overlaps the NBMA exactly.  If you define the first term,
> > the second is just "an address prefix that overlaps an NBMA exactly"
> > (replacing NBMA for the term chosen).
> 
> I need a term that would cover a group of hosts on an NBMA network
> with a router on the NBMA network that would act as the last hop router
> for these hosts. The group of hosts may form a subset of all the 
> hosts connected to the NBMA network. So, an NBMA network may have
> more than one APR (more than one address prefix), but each APR
> would have exactly one address prefix.
> 
> Yakov.


Yakov,

How about:

  NBMA (or it's replacement)

  address prefix falling entirely within an NBMA (was APR)

  address prefix reachable through a router on the NBMA

  a firewall or concentrating router on an NBMA serving a specific
  prefix on the NBMA but requiring connectivity through the firewall

Why do we have to associate new terms for a prefix used in a specific
situation?  The term you are asking to define is the fourth case.

The fourth case above is special case of the third.  There is always
some reason behind being reachable through a router rather than
direct.  The reason in the fourth case is not the most common reason
that the media types are not the same.  What makes this case special
enough to require another term be defined for it?

If there is substantial content in your draft and there is a concept
that is used frequently and is likely to be needed frequently in
technical discussions and current requires a lengthy or awkward
phrase, then we need a new term.  Let's not define the jargon first,
then figure out if we need the new terms for anything.

I think the call in the Danvers IETF was for the definition of a term
to replace "NBMA network" *only* since subnet didn't fit.  Here a new
term was clearly needed.  It was not a call for a whole new set of
jargon and acronyms.

Curtis