Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

From: Keith Moore <[email-masked]>
Date: Fri, 19 Aug 2011 12:25:51 -0400

I recommend that the address block be published in the document when it becomes an RFC.

It's also arguable that 6to4 implementations should recognize addresses from the assigned prefix and disable 6to4 when configured with such addresses.

The document could perhaps make it clearer that this prefix is intended for assignment by access providers and not, e.g., by enterprise networks or for use in interconnection between private networks.

Keith

---

From: Peter Koch <[email-masked]>
Date: Fri, 19 Aug 2011 23:30:05 +0200

On Fri, Aug 19, 2011 at 09:10:25AM -0700, The IESG wrote:
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'IANA Reserved IPv4 Prefix for Shared Transition Space'
>   <draft-weil-shared-transition-space-request-03.txt> as an Informational
> RFC

I am a bit confused about the exact purpose of this last call and would appreciate
some guidance by the IESG and/or IAB how to read this in context.
It appears the draft is meant to gauge consensus as per the communication
archived at
<http://www.iab.org/documents/correspondence-reports-documents/2011-2/response-to-arins-request-for-guidance-regarding-draft-policy-arin-2011-5/>.

However, all the content and discussion is essentially deferred to
draft-bdgks-arin-shared-transition-space-01.txt, which has a status of "I-D Exists",
is not subject to this Last Call and is, to my surprise, an Informative Reference
in the draft under consideration.

content/nits:

o draft-bdgks-arin-shared-transition-space-01.txt would have to be elevated 
  to a normative reference, with all consequences

o the document should have operational considerations as in RFC 1918,
  regarding the leakage of addresses in IP headers and elsewhere (cf. "AS112")

o the document does not discuss the risk of the new address space being
  absorbed as a simple addition to RFC1918 space

o the Security considerations are non existent, especially given the
  long experience with actual and perceived threats connected to RFC 1918
  address space

o the document would have to change its perspective to as if the address
  range had already been assigned (no more "proposes" language).

o the document ought to expand used acronyms and add references to IETF
  or other documents, e.g., for CGN, CPE, and other terms

o without any judgement re: the "B", this document should aim at BCP status
  since it would have to give (more detailed) instructions what and what
  not to do with the assigned/allocated address.

o RFC 2119 would have to be elevated to a normative reference

o add reference to RFC 6319

Quite frankly, without taking any position on the actual proposal, these
bullet items suggest the draft is not ready for publication.

-Peter

---

From: SM <[email-masked]>
Date: Fri, 19 Aug 2011 14:42:07 -0700

At 09:10 19-08-2011, The IESG wrote:
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2011-09-16. Exceptionally, comments may be

Making such an allocation through a document which is not intended 
for the Standards Track is highly unusual.  Last year I raised a 
concern in a non-IETF mailing list about making IPv4 allocations 
using "RFC required" as there will be more economic pressure for 
process end-run as the world gets to the odds and ends of IPv4 
addresses.  I don't see any text that fits under protocol assignment 
(see RFC 2860) in draft-weil-shared-transition-space-request-03.  In 
fact, the Security Considerations section mentions that the "memo 
does not define any protocol".

The draft only mentions an applicability and justification for Shared 
Transition Space and references 
draft-bdgks-arin-shared-transition-space-00.  While the policy fits 
under RIR community processes, it does not fit under allocations made 
for technical specifications.  Publishing this document on the 
grounds that the ARIN wants it is not a good enough reason.  Will 
ARIN be "donating" the /10 IPv4 address space to IANA for it to make 
this allocation?

The draft mentions that:

   "Network equipment manufacturers MUST NOT use the
    assigned block in default or example device configurations."

As the IPv4 address block is not specified in the document, the above 
requirement cannot be followed.  The expectation that the IPv4 
address block will only be used by Infrastructure Providers is 
optimistic.  RFC 5735 covers Special Use IPv4 Addresses.  This 
document should update the BCP.

A proposal similar to this one was discussed in a V6OPS meeting in 
Asia.  If my reading is correct, it did not gain consensus.  The 
proposal gets discussed in North America in
OPSAWG and it gains consensus.  BTW, this draft contains only 220 
lines, including boilerplate and it has five authors.

Regards,
-sm

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 20 Aug 2011 00:23:57 +0200

On 19 August 2011 23:42, SM wrote:

> RFC 5735 covers Special Use IPv4 Addresses.

BTW, some days ago the "errata system" informed me that a rather old
nit about class E in RFC 3330 made it to "held for document update",
but I think RFC 5735 already did that, cf. RFC 3330 eid 1436.

The I-D discussed here mainly consists of an informative reference
to another I-D.bdgks-arin-shared-transition-space-01, and the latter
mentions class E in section 2.2.3.

Is nobody going to use these 268,435,455 "free" IPs waiting for IETF
experiments?

-Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Aug 2011 11:05:58 +1200

On 2011-08-20 09:30, Peter Koch wrote:
...
>   to a normative reference, with all consequences

I don't think this is really required; it is after all an
explanatory document. However, I do think that *if* draft-weil-
is to be published, draft-bdgks needs to be published
simultaneously. Therefore, I think that synchronised Last Calls
are needed.

I have previously argued against draft-weil on the OPSAWG list
and lost, so I will not repeat that argument here. However, if
it is to proceed, then some of my WGLC comments have not yet
been fixed:

>> At the very minimum, if draft-weil is to proceed, it should describe the
>> phase-out plan for the proposed prefix (i.e. the phase-out plan for CGN
>> deployment). One approach to that is documented in RFC 6264.

The authors didn't agree with that comment, but since this is
essentially an operational matter, I think they are wrong. If
the IETF sticks its nose into RIR matters in this way (as the
IAB has concluded that we should*), then we should do a complete
job.

>> It is strange that draft-weil doesn't reference RFC 6319 and RFC 6269.

In other words, draft-weil doesn't recognise the
counter-arguments. That seems wrong to me.

   Brian Carpenter

*
http://www.iab.org/documents/correspondence-reports-documents/2011-2/response-to-arins-request-for-guidance-regarding-draft-policy-arin-2011-5/

---

From: Chris Donley <[email-masked]>
Date: Mon, 22 Aug 2011 15:56:23 -0600

>ARIN be "donating" the /10 IPv4 address space to IANA for it to make
This proposal reached ARIN consensus (2011-5), and has been recommended
for adoption to the ARIN board. The ARIN BoD has indicated that it is
willing to reserve a /10 if asked to do so by the IETF/IANA.

>optimistic.  
This will be supplied by IANA in consultation with ARIN.  ARIN has not
pre-announced what block might be used, so we need to wait until IANA gets
back to us later in the process.

>RFC 5735 covers Special Use IPv4 Addresses.  This
Once we get an assignment from IANA/ARIN, we'll look into updating RFC
5735.
>OPSAWG and it gains consensus.
Not quite right. We first brought this proposal to OPSAWG in Maastricht,
and then updated it for Beijing.  From the opsawg (79) minutes:
> Straw poll: more people in the room supported the draft than didn't,
> perhaps 2:1. About half the room expressed an opinion.

Because IANA was down to its final /8, we were asked to also present in
v6ops, which did not reach consensus for or against. Feedback from v6ops
was to approach the RIRs for space, rather than IANA, which we did.

> BTW, this draft contains only 220
How is this relevant? Jason, Victor, and I have been working on this for
over a year.  Chris L and Marla joined the author team with significant
contributions when we substantially updated the draft prior to IETF79.

Chris
>
>Regards,
>-sm 
>
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: SM <[email-masked]>
Date: Mon, 22 Aug 2011 21:23:00 -0700

>willing to reserve a /10 if asked to do so by the IETF/IANA.
[snip]
>back to us later in the process.

The information could have been mentioned as a note in the draft.

>was to approach the RIRs for space, rather than IANA, which we did.

And a RIR sent this back to the IETF.

>contributions when we substantially updated the draft prior to IETF79.

That was an editorial nit.  Without the above explanation, it comes 
through as a case of corporate name-dropping.

Regards,
-sm