Subject: RE: New Version Notification for draft-mrw-6man-ulac-analysis-00

From: "Azinger, Marla" <[email-masked]>
Date: Tue, 13 Nov 2007 12:45:29 -0500

Margaret-  Thank you for taking time on this.  Not to be pushy, but when do you plan to have your revision out?

Thank you
Marla

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]]
Sent: Monday, November 12, 2007 5:36 PM
To: Per Heldal
Cc: [email-masked]
Subject: Re: New Version Notification for
draft-mrw-6man-ulac-analysis-00

Hi Per,

> Regardless of the listed arguments one may also question IETFs role in
> the definition of (any) ULA as there is no technical reason why  
> such an
> address-block must be tagged 'special'.

Thanks for raising this point.  Others have made a similar argument  
in the past, and it should definitely be added to the document.  I  
didn't fully understand this point before, but I think I get it now.   
The key point, I think, is that there is no direct connection between  
IETF address block allocations and registry policy.  In this  
particular case, the registries could decide to assign ULA-C  
equivalents from the regular address pool if they thought that would  
be a good idea, or they could choose not to register ULA-Cs,  
regardless of an IETF document allocating a particular address block  
for this purpose.

> If the IETF wants to provide
> guidance to the policy-process such should be no stronger than BCPs
> (like rfc1918), not technical standards (rfc4193). The regional
> registries, through the ICANN/ASO and IANA, may or may not choose to
> implement policies that support some form of ULA. There's no need for
> the IETF to dictate that process.

I don't think it makes sense to include this argument regarding all  
ULAs in the current document, because RFC 4193 has already been  
published and the case for/against locally-allocated ULAs is outside  
the scope of this document.  Personally, I think that there is a big  
difference between defining locally-assigned ULAs and defining ULA- 
Cs.  In the case of locally-assigned ULAs, RFC 4193 effectively  
removed a block of addresses (the locally-assigned ULAs starting with  
FD00::/8) from the set of addresses that are registry-assigned,  
whereas for ULA-Cs we would by trying (perhaps unsuccessful, as you  
point out) to set central registration policies for a group of  
addresses.

>  Also consider the signals such
> standards communicate to manufacturers. Misleading standards and
> policies have led vendors to introduce artificial limitations in
> hardware and software in the past (example: 240/4). Do we really want
> that?

This is a very good point, and I think it should be included in the  
document separate from your first argument.  The installation of  
default filters to prevent routing ULAs, for example, might have  
undesirable consequences later.

I think that Geoff Huston has made the same (or a similar) argument  
when he has indicated that it is architecturally unsound to associate  
routing properties with a specific address block. There is no  
inherent guarantee that any registry-assigned address block will be  
routable (you need to arrange for routing with your ISP), so there is  
no need to create a new registry-assigned address block to remove  
that non-existent guarantee.

I'll capture this argument in the next version of my document, as  
well as you first point.

Let me know if I seem to be misunderstanding what you've said.

Thanks!
Margaret

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 14 Nov 2007 10:04:59 -0500

If the ID submission tool will let me submit a -01 version of the  
draft later this week, even though I submitted the -00 version just  
before the -00 deadline last week, I'll publish another version later  
this week with changes based on Per's message and any other feedback  
I receive.  Otherwise, I won't be able to post a new version until  
after the Vancouver IETF meeting.

Margaret

On Nov 13, 2007, at 12:45 PM, Azinger, Marla wrote:

> Margaret-  Thank you for taking time on this.  Not to be pushy, but  
> when do you plan to have your revision out?
>
> Thank you
> Marla
>