Subject: [OPSAWG] Version 3 Changes posted for draft-azinger-additional-private-ipv4-space-issues-03

From: "Azinger, Marla" <[email-masked]>
Date: Mon, 8 Mar 2010 09:00:01 -0500

Hello

Leo and I have taken the last round of input and modified the document.  Below is a roll up of the changes that were made.  Thank you everyone for your input.

http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-03

Changes Made:

Section 3 we removed:

- identification of specific subnets to avoid documenting something as a BCP that is possibly not exactly standard and inserted a more general term and general process that has been used.

-a word typo

-section 4.2 we:

-modified the local scope text to be inline with documentation.

Section 4.4 we added:

-reference to FASTWEB

Section 4.5 we added:

- text covering the increasing difficulty of obtaining unique address space and references to current, new and pending RIR policies that affect this situation.

Section 5.1 we added:

- a reference to [I-D.davies-reusable-ipv4-address-block] and text surrounding this document.

- a reference to a NANOG string about some sections of Allocated /8's being carved out and filtered therefore unofficially enabling the use of these sections for private use.

-text addressing lack of guarantee in regards to uniqueness for newly redefined unicast space.

Thank you

Marla Azinger and Leo Vegoda

---

From: Ricardo Patara <[email-masked]>
Date: Mon, 08 Mar 2010 12:16:04 -0300

Hello,
I appreciate the updates made on the previous document.

One thing that might be hard to keep updated is the mention to the
number of free /8s in iana pool (chap 5.3). In this last version (3), it
is written as being 24. When is actually 22 now. have no suggestion
about how to address this, or if this is an important issue.

Regarding the document composition. I still have problem with the
chapter 5.3 and how it fits in the document.

Chapter 5 "Options and Consequences for Defining New Private Use Space",
to my perception is a list of options for new Private use space. Which
would be, set aside a couple of unallocated prefixes (chap 5.1), have a
shared space (chap 5.2), or put in usage the Future Use space (5.4).

So, why 5.3 is in between those options?

Shouldn't it be the last item for this chapter 5?
Maybe a have 5.4 renumbered to 5.3, and the current 5.3 renumbered to
5.4 as it being the consequence of not implementing neither of options
mentioned before (chaps 5.1, 5.2 and 5.3)

Regards

On Seg, 2010-03-08 at 09:00 -0500, Azinger, Marla wrote:
> Hello
> 
> Leo and I have taken the last round of input and modified the
> document.  Below is a roll up of the changes that were made.  Thank
> you everyone for your input.
> 
> - identification of specific subnets to avoid documenting something as
> a BCP that is possibly not exactly standard and inserted a more
> general term and general process that has been used.
> 
> -a word typo
> 
> -section 4.2 we:
> 
> - text covering the increasing difficulty of obtaining unique address
> space and references to current, new and pending RIR policies that
> affect this situation.
> 
> Section 5.1 we added:
> 
> - a reference to a NANOG string about some sections of Allocated /8's
> being carved out and filtered therefore unofficially enabling the use
> of these sections for private use.
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 10 Mar 2010 06:45:35 -0800

Hi Ricardo,

On Mar 8, 2010, at 7:16 AM, Ricardo Patara wrote:

[…]

> about how to address this, or if this is an important issue.

I think that when considering the issue of whether further IPv4 address space should be designated as additional private address space it is important to consider how much address space is left to take from so that the proportion of the remaining pool used is  clear. It is possible that this could be done in other ways. Suggestions welcome.

> mentioned before (chaps 5.1, 5.2 and 5.3)

I can see what you mean, I suppose we were thinking in a slightly different way. 5.1 and 5.2 deal with different approaches to using unicast space, 5.3 deals with not using unicast space and 5.4 deal with using non-unicast former Class E space.

I suppose we could re-organize those sections based on action taken rather than the kind of address space if that's what people think is more logical.

Kind regards,

Marla & Leo