Re: draft spec of technical work of IANA

[Jeff Williams <jwkckid1@ix.netcom.com>]

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 jwkckid1@ix.netcom.com
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208