I agree generally with Brian except for the 2860 part. I would not want to have seen IANA put on the spot for this, even if the IAB had been willing to take responsibility for it.
Meanwhile I will say once again that capitulating here is wrong on many levels. First there is the whole, "They made their non-IPv6 bed, they ought to be required to lay down in it" issue. But completely aside from that, I think Brian is right that the chances are within a close approximation of 100% that whatever we do here will be ignored anyway. So why not take a stand by doing the right thing and not allocating the prefix? ... and a meta-issue for Ron. I saw a lot more opposition to the document in the last call than you did. Are you by any chance referring to my message at https://www.ietf.org/mail-archive/web/ietf/current/msg69583.html below? If so, I guess I needed to actually say the words, "I oppose publication of this document?" If I wasn't clear, sorry. Doug On 11/28/2011 18:43, Brian E Carpenter wrote: > I refrained from commenting during the IETF Last Call, and I think it might > help the IESG to reach the least bad decision if I say why. > > This whole proposal will *never* be palatable to me. However, it may be > reasonable for the IETF to lay down appropriate restrictions, even though > we know that ISPs will ignore them. > > IMNSHO it would have been much better if the IAB had agreed that this > allocation was a policy matter to be left to IANA and the RIRs under > Clause 4.3 of RFC 2860 . Since the IAB chose to define it as a technical > allocation, it is the IETF that has to take responsibility, and it is a > lose-lose game for us. Whatever we decide is wrong. > > Regards > Brian Carpenter > > On 2011-11-29 10:25, Ronald Bonica wrote: >> On October 10, 2011, the IESG issued a last call for comments regarding >> draft-weil-shared-transition-space-request-09 (IANA Reserved IPv4 Prefix for >> Shared CGN Space). While the community did not display consensus supporting >> the draft, it also did not display consensus against the draft. Therefore, I >> will submit the draft to the full IESG for its consideration at its December >> 1 teleconference. The draft will be published as a BCP if a sufficient >> number of IESG members ballot "Yes" or "No Objection", and if no IESG member >> ballots "Discuss". >> >> Because the decision to submit this draft to the full IESG is controversial, >> I will explain the decision making process. >> >> The IETF has a precedent for interpreting silence as consent. Typically, if >> a last call elicits no response, the draft is brought to the full IESG for >> consideration. The October 10 last call regarding >> draft-weil-shared-transition-space-request-09 evoked only two responses. One >> response supported publication of the draft while the other was opposed to >> it. The respondent voicing support for the draft offered no rationale. The >> respondent objecting offered many editorial comments, but almost no >> rationale for blocking the draft once the editorial comments are addressed. >> >> Because the October 10 last call elicited so little response, and because >> many community members have privately expressed strong opinions regarding >> this draft, I will summarize outstanding issues below. The following are >> arguments *against* draft-weil-shared-transition-space-request: >> >> - Allocation of a special-use /10 does not hasten the deployment of IPv6. It >> only extends the life of the IPv4 network. >> - If a special-use /10 is allocated, it will be used as additional RFC 1918 >> address space, despite a specific prohibition against such use stated by the >> draft. >> - If a special-use /10 is allocated, it will encourage others to request >> still more special-use address space. >> - Some applications will break. These applications share the characteristic >> of assuming that an interface is globally reachable if it is numbered by an >> non-RFC 1918 address. To date, the only application that has been identified >> as breaking is 6to4, but others may be identified in the future. >> >> Arguments *supporting* draft-weil-shared-transition-space-request-09 assume >> that operators will deploy CGNs and will number the interfaces between CGN >> and CPE. If the /10 proposed by draft-weil-shared-transition-space-request >> is not allocated, operators will number from one of the following: >> >> - public address space >> - RFC 1918 address space >> - squat space >> >> If operators number from public address space, they will deplete an already >> scarce resource. If operators number from RFC 1918 space and the same RFC >> 1918 space is used on the customer premise, some CPE will behave badly. The >> consequences of numbering from squat space are determined by the squat space >> that is chosen. >> >> In summary, allocation of the /10 will have certain adverse effects upon the >> community. However, failure to allocate the /10 will have different adverse >> effects on the community. The IESG is being asked to choose the lesser of >> two evils. -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
