Lame Delegations in IN-ADDR.ARPA

2004-3: Global Addresses for Private Network Inter-Connectivity

Assessment: Consistent · In February 2005 Randy repeatedly opposed official encouragement of private addresses and explicitly distinguished that objection from banning their use. His April 2004 challenge concerned the cost and technical justification of one VPN use case. Those are different propositions: conserving global space in a case he considered weak does not entail endorsing official promotion of private space everywhere.

Conditions: The stronger disease metaphor is limited by his later express rejection of a ban. · This is compatibility of the specific arguments, not proof that all of his allocation preferences remained unchanged.

Apr 5, 2004

now you want the world to bear the cost? gimme a break.

Feb 15, 2005

in particular the word "encouraged,"

Feb 16, 2005

i did not propose to remove rfc 1918, forbid use of 1918 address space, ...

Feb 16, 2005

what i said was that we, arin, should not "encourage" it.

Lame Delegations in IN-ADDR.ARPA

Assessment: Insufficient evidence to assess consistency · One contribution supports removing lame DNS delegations and improving data quality. It cannot establish stability or change over time for this proposal.

Conditions: WHOIS visibility and DNS delegation removal are separate suggestions.

Mar 8, 2002

yes!!! at last, something to move towards cleaning up bad data and keeping it clean. thank you!

Experimental Internet Resource Allocations

Assessment: Consistent · Both contributions argue for the IETF consensus process to govern the relevant experimental allocations. The later message clarifies that process authority is distinct from who may originate proposals; it does not retract the earlier cooperation concern.

Conditions: He speaks as an IETF member, expressly not as its representative. · This finding concerns the stated process and RFC scope, not every condition of experimental allocation.

Nov 16, 2002

i am concerned that the rir/ietf cooperation continue to be constructive, with each playing its part in the movie.

Nov 19, 2002

the issue is what standards organization's process is used to process a proposal. in that case, indeed i am saying it should be ietf's. note that this is not who may think of proposals.

2006-2: Micro-allocations for Internal Infrastructure

Assessment: Consistent · The two technical questions ask whether proposed private-address mechanisms conflate locators with identifiers and whether they avoid known operational failures. They are compatible requests for technical explanation, not recorded opposing votes.

Conditions: A question about an alternative in the thread is not an endorsement or rejection of the entire proposal.

Apr 21, 2006

is this another binding of locators to identifiers?

Apr 21, 2006

is there something we can do to not continue the pain while getting some benefit?

ARIN-prop-54: PIv6 for legacy holders with RSA and efficient use

Assessment: Insufficient evidence to assess consistency · The single contribution criticizes using address policy to pressure vendors and stresses dual-stack equipment availability. It does not establish a settled allocation stance or a change over time on the linked proposal.

Conditions: The discussion includes operational and market arguments beyond the proposal's exact eligibility wording.

Aug 1, 2007

lack of availability will severely limit our options.

Aug 1, 2007

this discussion should be happening on nanog and the isps should be shaking withheld orders at the vendors unless they have high quality dual stack kit.

2004-3: Global Addresses for Private Network Inter-Connectivity · 2006-2: Micro-allocations for Internal Infrastructure

Assessment: Consistent · His warning about applications broken by private addressing in 2004-3 is compatible with later requests that private-address alternatives solve actual operational problems in the 2006-2 discussion. Both examine practical costs rather than assuming that a policy admonition prevents failures.

Conditions: Different mechanisms and policy scopes prevent a direct comparison of their support labels. · This comparison does not imply a final vote on 2006-2.

Feb 16, 2005

it causes pain via a number of applications is breaks, e.g. sip/rtp.

Apr 21, 2006

we have a plenty of history that "should not" in an rfc does not help much.