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 PROTECTED] Sent: Monday, November 12, 2007 5:36 PM To: Per Heldal Cc: ipv6@ietf.org 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
