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

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:narten@us.ibm.com]
Sent: Tuesday, September 25, 2007 10:43 AM
To: Azinger, Marla
Cc: radir@ietf.org
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
RADIR@ietf.org
https://www1.ietf.org/mailman/listinfo/radir