Brian E Carpenter wrote: > Hi, I'd like to ask for any final comments on this draft > spec of the technical work of the IANA. This is just > an update of earlier drafts, with all technical comments > incorporated and all non-technical aspects removed. > > Thanks > Brian > > SPECIFICATION OF THE TECHNICAL WORK OF THE IANA > > Purpose - this document specifies the technical work to be > performed by the IANA on behalf of the IETF, and how the IANA > interacts with the IETF. > > Terminology - > > IANA - Internet Assigned Numbers Authority (a traditional name, used > here to refer to the technical team making and publishing > the assignments of Internet protocol technical parameters). > > IETF - the Internet Engineering Task Force, the unincorporated > association that creates Internet Standards and related documents. > > IAB - the Internet Architecture Board, an oversight committee of the IETF. > The IAB is chartered to designate the IANA on behalf of the IETF. > > IESG - the Internet Engineering Steering Group, a management committee of the IETF. > > IRTF - the Internet Research Task Force, an informal body also overseen by the IAB. > > IRSG - the Internet Research Steering group, a management committee of the IRTF. > > RFC - "Request For Comments", the archival document series of the IETF, also > used by the IRTF and by third parties. > > Technical work items - > > 1. The IANA will assign and register Internet protocol parameters only as > directed by the criteria and procedures for specified in RFCs, including > Proposed, Draft and full Internet Standards and Best Current Practice > documents, and any other RFC that calls for IANA assignment. If they are > not so specified, or in case of ambiguity, IANA will continue to assign > and register Internet protocol parameters that have traditionally been > registered by IANA, following past and current practice for such assignments, > unless otherwise directed by the IESG. THis should be determined by the At-Large membership not the IESG. > > > If in doubt or in case of a technical dispute, IANA will seek and follow > technical guidance exclusively from the IESG. Where appropriate the IESG > will appoint an expert to advise IANA. > > The IETF will develop any missing criteria and procedures over time, > which the IANA will adopt when so informed by the IESG. > > 2. In the event of technical dispute between the IANA and the IESG, both > will seek guidance from the IAB whose decision shall be final. Bad idea, and one of the reasons the decision tree needs to be much more inclusive. The At-Large membership should have the final decision here by majority vote as a resolution, if necessary. > > > 3. Two particular assigned spaces present policy issues, in addition > to the technical considerations specified by the IETF: the assignment > of top level domain names, and the assignment of scarce subscriber > IPv4 address blocks. These policy issues are outside the scope of the > present specification. > > Note that technical assignments of domain names (such as domain names > for inverse DNS lookup), or assignments of specialised address blocks > (such as multicast or anycast blocks) are not considered to be policy > issues. The same applies to experimental allocations. This may need some hashing over... > > > 4. The IANA shall make available to the public, on-line and free of charge, > information about each current assignment, including contact details for > the assignee. > > 5. The IANA shall provide on-line facilities for the public to request > Internet protocol parameter assignments and shall either execute > such assignments, or deny them for non-conformance with applicable > technical requirements, in a timely manner. There shall be no charge > for assignments without the consent of the IAB. Requests shall > only be denied on technical grounds. The IAB should ONLY act in a an advisory capacity, not as a determination body. All final decisions as to assignments should be determined by the At-Large membership only. > > > For protocols within the IETF scope (i.e., registries created > by IETF action), appeals against such denials may be made to the IESG and > subsequently to the IAB as provided in 2 above. This is fine as depository function, but not as a decision function of the IESG and the IAB. Those appeal decisions should as in compliance with the White Paper should be stakeholder driven, and hence made by the At-Large membership. > > > 6. The IANA shall have non-voting liaison seats in IETF committees > as determined by the IETF, and may participate in all IETF discussions > concerning technical requirements for protocol parameter assignment > through such liaisons. > > 7. The IANA shall review all documents in IETF Last Call to identify > any issues of concern to the IANA, and shall raise these issues > with the IESG. > > 8. All of the above shall also apply as relevant to the IRTF and IRSG, > by analogy to the IETF and IESG. > > --- Regards, -- Jeffrey A. Williams CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail [EMAIL PROTECTED] Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208