Re: [Ianaplan] Process concern regarding the IETF proposal development process

[Jefsey <[e-mail]>]

At 16:09 19/01/2015, Seun Ojedeji wrote:
>I will say i observed some level of IETF community experience making 
>great influence in the proposal development, nevertheless the "not 
>so IETF experienced" me agree on the group decision with regards to 
>the IPR on <http://iana.org/IANA>iana.org/IANA. I think Richard may 
>want to further clarify the section of his mail below (especially 
>the one in bold as a non-legal me tend to disagree):
>
>  .....the IETF proposal does not adequately address certain issues, 
> in particular: (a)
>
>replacing the existing IANA functions contract between NTIA and ICANN with
>
>an equivalent legally binding contract for what concerns protocol parameters
>
>(the current MoU between ICANN and IETF is probably not a legally binding
>
>contract)....

Dear Seun,

Things are politically binding by virtue of the NTIA which is assumed 
to be gone by Sept 15, 2015. This is why we can only trust the last 
public commitment and the cross-protocol documentation (in being 
prepared it may changed). Please remember Brian Carpenter's RFC 1958. 
"Architectural Principles of the Internet": "Principles that seemed 
inviolable a few years ago are deprecated today. Principles that seem 
sacred today will be deprecated tomorrow. The principle of constant 
change is perhaps the only principle of the Internet that should 
survive indefinitely".

This WG has published a soon-to-be-forgot Draft. Its only virtue will 
be its RFC number and the time-stamp of the ISOC response to my 
appeal. It will be the self-acknowledged date of the end of the IET 
Internet exclusive on the Catenet. From then on, it will be clear 
that catenet users will be free to use non-IETF internet coopetitive 
innovation as per RFC 6852. As per these OpenStand 
IEEE/IAB/IETF/W3C/ISOC rules ICANN will continue to operate in 
parallel with other national, Libre and commercial IANA/DNS propositions.

What is important is to make sure there is no name, number or 
parameter collision.
jfc