Subject: RE: [RADIR] Last Call on problem statement -01

From: "Azinger, Marla" <[email-masked]>
Date: Tue, 25 Sep 2007 14:38:30 -0400

1. toning down is fine.  I feel this is necessary because I expect a wider viewing of this than your average IETF document.  And just wish to avoid misunderstandings/rat holes.

2.ok.  I think you see for the most part what I am getting at.  I would at least modify these ones.  >(There
are a few places where adding "upstream" seems like a good clarification, but this is mostly in the context of address
delegations.)<

3. I would at least add the small bit that I sent regarding NAT.  Anymore detail and addressing why its not recommended as a solution set...gets into the solution set...and thats not problem statement.

Cheers!
Marla

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Tuesday, September 25, 2007 10:43 AM
To: Azinger, Marla
Cc: [email-masked]
Subject: Re: [RADIR] Last Call on problem statement -01

> Ok.  Here are my comments.  Sorry its not the "ship it" one.

:-)

> 1. At definitions.  I think it would be helpful to write one
> sentence/disclaimer at the beginning.  I propose this because
> definitions quickly become a rat hole and at least two of them I
> read could easily confuse and rat hole some people if they are not
> warned.  Suggested text follows:

> "The definitions provided in this document have been created for sole =
> use within this document and may differ from Internet Registry's, =
> References and or other documentation."

How about I tone this down just a bit (it almost sounds like a
disclaimer!) and say:

  The terms and definitions used in this document are intended to
  increase the clarity of this document. Be aware that some
  definitions may differ (slightly) from usages in other contexts.

I'm not strongly opposed to this, but also kind of feel like this a
given and goes without saying.

> 2. Change ISP to Upstream Provider throughout the document.  Add =
> definition of Upstream Provider.  I suggest this because the term ISP =
> has become a rat hole in the ARIN region.  I thought to replace it with =
> LIR, but you can still end up with a rat hole on that as well.  Saying =
> Upstream Provider makes it clear without dictating a categorical type.  =
> OR add a definition of ISP to mean Upstream Provider.

I just went through the document searching for ISP, and I think in
most cases, the current term ISP is correct, as the term is used
generically. Indeed, I think using "upstream" would be wrong. (There
are a few places where adding "upstream" seems like a good
clarification, but this is mostly in the context of address
delegations.)

Thinking a bit more about this, what exactly does the term "Upstream
Provider" (as you are thinking) mean? Is this just to indicate where
the address block comes from (i.e., out of an upstream's aggregate),
or does it mean more than that, e.g., where one gets transit from?

> 3. Shouldn't 4.3 have a caveat "renumbering can be painful if NAT is not =
> utilized"?  This paragraph makes its sound like everyone finds =
> renumbering painful...when they don't.

I agree that something about this needs to be added.

Hmm. I'm somewhat surprised to note that NAT isn't even used in the
document!

I wonder if we then need to add a section (somehow) that points out
that NAT avoids renumbering pain, but then also list some of the
standard reasons why NAT is not recommended as the solution to our
"problem".

> 4.  Section 4.5 second to last sentence has typo in it. "had to >me< =
> made"  I think this is supposed to be the word "be"

fixed.

> 5.  Section 4.8.  last sentence has "use" in it twice. Remove one of the =
> "use"

fixed.

Thomas

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

---

From: "Azinger, Marla" <[email-masked]>
Date: Tue, 25 Sep 2007 14:39:16 -0400

sorry. I got held up and dialed in 20 min. late and you were already gone.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Tuesday, September 25, 2007 11:29 AM
To: Azinger, Marla; [email-masked]
Subject: Re: [RADIR] Last Call on problem statement -01

Hi Marla,

Vince, Jason and I had a short call. We chatted about your comments.

> or does it mean more than that, e.g., where one gets transit from?

Revised suggestion:

add the following definition:

Internet Service Provider (ISP): an entity that provides Internet
	 connectivity between sites. The term is used loosely in this
	 document to mean any entity that provides connectivity
	 between different organizations. Customers may number their
	 devices out of the ISP's address space, or use address space
	 obtained from elsewhere.

In the following, change "ISP" to "upstream ISP" in a couple of
places.

OLD:
	  <t hangText="Provider Aggregatable (PA) address space:">

	    Address space that an end site obtains from an ISP's
	    address block. The main benefit of PA address space
	
NEW:
	  <t hangText="Provider Aggregatable (PA) address space:">

	    Address space that an end site obtains from an upstream
	    ISP's address block. The main benefit of PA address space

OLD:
      <section title="Traffic Engineering">
	<t>
	  The mechanisms used to achieve multihoming and inbound
	  Traffic Engineering are the same. In both cases, a specific
	  prefix is advertised into the routing system to "catch"
	  traffic and route it over a different path than it would
	  otherwise be carried. When multihoming, the specific prefix
	  is one that differs from that of its ISP or is a
	  more-specific of the ISP's PA. Traffic Engineering is

NEW:
      <section title="Traffic Engineering">
	<t>
	  The mechanisms used to achieve multihoming and inbound
	  Traffic Engineering are the same. In both cases, a specific
	  prefix is advertised into the routing system to "catch"
	  traffic and route it over a different path than it would
	  otherwise be carried. When multihoming, the specific prefix
	  is one that differs from that of its upstream ISP or is a
	  more-specific of the ISP's PA. Traffic Engineering is

> standard reasons why NAT is not recommended as the solution to our

I think we are collectively nervous about mentioning NAT. It could be
quite a challenge to mention it without adding a lot of text and we'd
risk getting sucked into the big "NAT is evil," "is not" rathole.

Can you suggest some text?

Thomas

---

From: "Azinger, Marla" <[email-masked]>
Date: Tue, 25 Sep 2007 14:49:22 -0400

These look good to me.

Suggested text change to second sentence for 4.3 is:
When using PA space, a site must renumber when changing providers, and this has only been made less painful when NAT is an acceptable solution and utilized.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Tuesday, September 25, 2007 11:29 AM
To: Azinger, Marla; [email-masked]
Subject: Re: [RADIR] Last Call on problem statement -01

Hi Marla,

Revised suggestion:

OLD:

NEW:

OLD:

NEW:

Thomas