Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
Dave, Just on this point: On 5/11/13 2:36 AM, David Conrad wrote: There isn't any mention of privacy [2] considerations in the draft. True. The document is documenting current practices and policies. At this point in time, I'm unaware of a global privacy practice or policy that is applicable to all levels of the Internet Numbers Registry System. It's probably worth saying that the various PDPs SHOULD address policy considerations. How they address them is a matter for them, individually. Eliot
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
Uch... you can see where my head is: On 5/11/13 2:14 PM, Eliot Lear wrote: It's probably worth saying that the various PDPs SHOULD address policy considerations. How they address them is a matter for them, individually. s/policy considerations/privacy considerations/ Grr... Eliot
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
Hi David, At 18:36 10-05-2013, David Conrad wrote: Sure, but it is also looking towards the remaining few IPv4 allocations that will be made over the next few years. I am looking at the draft from an IETF perspective. There is IPv4 address space for protocol assignments. It could be said that the IETF's role is limited to providing guidance on IP architectural and operational considerations (e.g. RFC 6177). Several years ago some RIRs adopted policies which were inconsistent with IAB/IESG recommendations. I suggest leaving IPv4 allocations unrelated to protocol assignments up to other communities to avoid further inconsistencies. The fact that the IPv6 address pool is very large does not remove the fact that it is a not an infinite resource and thus, constraints must be applied to allocation policy. The constraints are not set by the IETF. It's up to other communities to see what constraints, if any, should be applied. Lacking those constraints, I'm sure you or I could come up with an allocation policy that would blow through the IPv6 free pool quite quickly. To date, the communities Yes. I doubt that you or I would get away with it. :-) interested in IP addressing have established policies that dictate operational needs should be the primary constraint (as opposed to say constraining on geo-political boundaries, by ability to pay, etc). However, the second part of that sentence is saying that pool limitations at the time of allocation should also be taken into consideration. Since _at this time_ the IPv6 free pool is quite large, it would follow that allocation policy constraints would be minimal (as I believe they are). InternetNZ wrote a very good message, in my opinion, a few months to argue for the position it took on a proposal. It applied its principles to explain its position. I would like to look at this in terms of principles instead of politics. From the above I see that communities interested in IP addressing set the policy constraints, e.g. operational needs. If it's a policy it cannot be a principle. I'll suggest alternative text: 1) Allocation Pool: IP addresses and AS numbers are fixed length numbers. The allocation pools for these number resources are considered as resources which are finite. The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to work. True. The document is documenting current practices and policies. At this point in time, I'm unaware of a global privacy practice or policy that is applicable to all levels of the Internet Numbers Registry System. Is it up to the IETF to set up a one-stop shop for personal data requests? I suspect not, but I suspect it isn't up to the IETF to dictate global privacy policy either. Section 2 is about the goals for distributing number resources (re. first sentence). I suggest removing the third goal as it might be a matter of global (or other) policy. It also makes privacy a non-issue as there isn't any relationship between it and the goals. In Section 5: The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. I'll wordsmith this: It is expected that discussions regarding Internet Numbers Registry evolution will continue to consider the overall Internet address architecture and goals mentioned in this document. I removed the must. I noticed the following in Section 5: In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue. The text does not add any value as must be taken into consideration does mean anything. The IETF publishes recommendations which people can elect to follow or ignore. If one believes that it is important to consider technical recommendations the person or organization can try and convince the appropriate venue to state that. Regards, -sm
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On 12/05/2013 03:17, SM wrote: ... The fact that the IPv6 address pool is very large does not remove the fact that it is a not an infinite resource and thus, constraints must be applied to allocation policy. The constraints are not set by the IETF. It's up to other communities to see what constraints, if any, should be applied. It's up to the IETF to set boundary conditions for the address space that it created (in the case of IPv6) or inherited (in the case of IPv4), in order to protect the long-term viability of the Internet. ... I'll suggest alternative text: 1) Allocation Pool: IP addresses and AS numbers are fixed length numbers. The allocation pools for these number resources are considered as resources which are finite. That doesn't set any boundary conditions beyond those imposed by mathematics, and is therefore a no-op. The mention of operational needs is a real boundary condition that makes it clear that address space is not to be wasted. As has been pointed out from time to time, it would be quite easy to design an allocation model, fully respecting the hierarchical constraint in the following guideline, that blows away galactic quantities of address space, even for IPv6. It is entirely appropriate for the IETF and IAB to write a goal that avoids this. The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to work. No IETF protocol will work if the address space is exhausted of if BGP4 runs out of steam or otherwise fails. The goals listed in Section 2 address that. ... Section 2 is about the goals for distributing number resources (re. first sentence). I suggest removing the third goal as it might be a matter of global (or other) policy. No, it's a necessity in order for the two preceding goals to be verifiably achieved, and to avoid accidental duplication of addresses. ... In Section 5: The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. I'll wordsmith this: It is expected that discussions regarding Internet Numbers Registry evolution will continue to consider the overall Internet address architecture and goals mentioned in this document. I removed the must. The must is necessary. I noticed the following in Section 5: In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue. The text does not add any value as must be taken into consideration does mean anything. Er, it means what it says. It is exactly as powerful as any other must or even MUST written by the IETF. If you ignore it, your network might break. I think that the current wording of the draft is correct. Brian
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
At 13:08 11-05-2013, Tom Vest wrote: Sorry, but unless you can point to some relevant real-world examples of self-executing, self-sustaining principles, or you're a nihilist and don't really believe that such things as principles exist at all, this is a patently false, bordering on nonsense statement. I am not suggesting any self-executing or self-sustaining principles. One is tempted to ask work for who? but that would entail giving this statement more credence that it merits. Since TCP/IP is only useful to the end of communication between two or more nodes, the proposed principle of finitude would perfectly consistent with this, and almost every other IETF addressing/attachment protocol *not* working at all. Or did you mean to say that The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to 'work' between two virtual machines, under lab conditions? What I meant was to leave policy (PDP, etc.) to the communities interested in IP addressing. I'll quote part of a message posted on the thread: 'To date, the communities interested in IP addressing have established policies that dictate operational needs should be the primary constraint (as opposed to say constraining on geo-political boundaries, by ability to pay, etc).' The message is at http://www.ietf.org/mail-archive/web/ietf/current/msg79200.html in case what I was quoted is misrepresented. At 13:14 11-05-2013, Brian E Carpenter wrote: It's up to the IETF to set boundary conditions for the address space that it created (in the case of IPv6) or inherited (in the case of IPv4), in order to protect the long-term viability of the Internet. There is some text about Internet address architecture. It would cover that if the relevant communities are agreeable to it. Regards, -sm
