ietf
[Top] [All Lists]

Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC

2013-05-13 09:05:29

On May 11, 2013, at 11:17 AM, SM wrote:

If it's a policy it cannot be a principle.

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'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.

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"? 

I suggest that the proposed alternative text should be rejected.

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.  

Since uniqueness is a basic constraint for most if not all current 
addressing/attachment-related IETF protocols -- even between two virtual 
machines, under lab conditions -- and would still be a basic constraint even if 
current address protocols were not quantity constrained in any way, you seem to 
be suggesting that the IETF forego not only policy statements, but also your 
own "only work" principle, at least under certain circumstances. 

Bottom line: this word "principle," I do not think it means what you think it 
means. 

I suggest leaving section three in place.

TV 






Regards,
-sm 


<Prev in Thread] Current Thread [Next in Thread>