<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div style=""><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica';">Bruce Tonkin <<a href="mailto:Bruce.Tonkin@melbourneit.com.au">Bruce.Tonkin@melbourneit.com.au</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica';"><b>[council] Guiding the Evolution of the IANA Protocol Parameter Registries</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica';">February 25, 2014 at 3:01:16 PM CST<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica';">"<a href="mailto:council@gnso.icann.org">council@gnso.icann.org</a>" <<a href="mailto:council@gnso.icann.org">council@gnso.icann.org</a>><br></span></div><br><div><br>For info:<br><br>The IETF is trying to document a set of principles for Evolution of the IANA Protocol Parameter Registries, as part of input into the current Internet Governance debates:<br><br>From: IAB Chair <br><br>To: IETF Announce<br><br>Subject: Guiding the Evolution of the IANA Protocol Parameter Registries<br><br>Existing IETF and IAB consensus concerning Internet registry functions<br>and IANA are documented in a variety of RFCs and IAB communications<br>[RFC2860,RFC6220,IAB1,IAB2]. Since registry functions and IANA are<br>likely to be the subject of discussion in a number of venues outside the<br>IETF over the coming months and years, the IAB is seeking community<br>feedback about operating principles to use when they find themselves<br>involved in those discussions.<br><br>While dealing with these issues the IAB has consistently approached the<br>issues from a set of (implicit) principles. Since the registry functions<br>are subject of discussion in various fora, the IAB has tried to make<br>these operating principles explicit and seeks to confirm these with the<br>community.<br><br>The IAB are planning to use part of the time in the IGOVUPDATE session at<br>IETF 89 (6 March 2014, 17:00-18:30 GMT) for a discussion of such operating<br>principles. But we wanted to kick-start that discussion with a few<br>thoughts about principles that the IAB and IETF have articulated in<br>various documents already and some that have emerged over time but may<br>not have been written down. What we are interested in is an articulation<br>of what the IETF community values. What other parties (ICANN, RIRs,<br>governments, etc.) value when they think about registry functions is<br>interesting, but we want to focus this discussion on the IETF and not<br>those other parties.<br><br>This is a first cut of making the principles more explicit for which we<br>seek your views.<br><br>Some of these might seem a bit generic, but it is difficult to predict<br>the nature of future discussions in which IETF and IAB leaders might find<br>themselves, so generality helps in that regard.<br><br>On behalf of the IAB,<br> Russ Housley<br> IAB Chair<br><br>= = = = = = = =<br><br>Principles Guiding the Evolution of the IANA Protocol Parameter Registries<br><br>1. The IETF protocol parameters function has been and continues to be<br>capably provided by the Internet community.<br><br>The strength and stability of the function and its foundation within the<br>Internet community are both important given how critical protocol<br>parameters are to the proper functioning of IETF protocols.<br><br>We think the structures that sustain the protocol parameters function<br>needs be strong enough that they can be offered independently by the<br>Internet community, without the need for backing from external parties.<br>And we believe we largely are there already, although the system can be<br>strengthened further, and continuous improvements are being made.<br><br><br>2. The administration of the protocol parameters function by ICANN is<br>working well for the Internet and the IETF.<br><br>We are pleased with the publication and maintenance of the protocol<br>parameter function and the coordination of the evaluation of<br>registration requests through the IANA function provided by ICANN.<br><br><br>3. The IETF protocol parameters function requires openness,<br>transparency, and accountability.<br><br>Existing documentation of how the function is administered and overseen<br>is good [RFC2860,RFC6220], but further articulation and clarity may be<br>beneficial. It is important that the whole Internet community can<br>understand how the function works, and that the processes for<br>registering parameters and holding those who oversee the protocol<br>parameter function accountable for following those processes are<br>understood by all interested parties. We are committed to making<br>improvements here if necessary.<br><br><br>4. Any contemplated changes to the protocol parameters function should<br>use the current RFCs and model as the starting point.<br><br>The protocol parameters function is working well, and as a result<br>wholesale changes to the role of the IETF vis a vis the function are not<br>warranted. The IETF/IANA Memorandum of Understanding [RFC2860] is a good<br>model to work from in the event that other parties do want to contemplate<br>changes. Put quite simply: evolution, not revolution.<br><br><br>5. The Internet architecture requires and receives capable service by <br>Internet registries.<br><br>The stability of the Internet depends on capable provision of not just<br>IETF protocol parameters, but IP numbers, domain names, and other<br>registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols.<br>Thus we expect the role of the IETF in standards development, architectural<br>guidance, and allocation of certain name/number parameters to continue.<br>IP multicast addresses and special-use DNS names are two examples where<br>close coordination is needed. The IETF will continue to coordinate with<br>ICANN, the RIRs, and other parties that are mutually invested in the<br>continued smooth operation of the Internet registries. We fully<br>understand the need to work together.<br><br><br>6. The IETF will continue its direction and stewardship of the protocol<br>parameters function as an integral component of the IETF standards<br>process and the use of resulting protocols.<br><br>RFC 6220 specifies the role and function of the protocol parameters<br>registry, which is critical to IETF standards processes and IETF<br>protocols. We see no need to revisit or reconsider our current approach<br>with regard to protocol parameters, including the ability to delegate<br>operational responsibility for registries to other organizations.<br><br>[RFC2860] <a href="http://www.rfc-editor.org/rfc/rfc2860.txt">http://www.rfc-editor.org/rfc/rfc2860.txt</a><br>[RFC6220] <a href="http://www.rfc-editor.org/rfc/rfc6220.txt">http://www.rfc-editor.org/rfc/rfc6220.txt</a><br>[IAB1] <a href="http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-final.pdf">http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-final.pdf</a><br>[IAB2] <a href="http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf">http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf</a><br><br></div></blockquote></div><br><div apple-content-edited="true">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com">www.haven2.com</a>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)</span>
</div>
<br></body></html>