keep up with the current workload.
The Secretariat does not believe that the IETF Community appreciates
the scope of the tasks. The Secretariat is automating more tasks,
hopefully reducing the overall workload. There is a long queue of
requests for new features in the tools that the Secretariat has
built. There is not money to hire more developers. The IETF
Executive Director is documenting processes. This has naturally
caused discussion about whether the processes are what everyone wants
the processes to be. While expected, it also increases workload.
* (6) How do you see the costs of your function evolving? If
* things become more costly over time, what are the main
* determiners of cost (e.g., general inflation, general IETF
* growth, increase in the number of particular functions you are
* carried out to perform,...). Are you doing some things that
* IETF (IESG or otherwise) request that you do not consider
* cost-effective and, if so, what are they?
The total budget for IETF-related activities at Foretec last year was
about $2.5M. The vast bulk was covered by IETF meeting fees, but the
shortfall was covered by contributions from CNRI and Foretec.
CNRI has been asked by its Board to find a solution to the problem.
Appendix E. Consultation with ICANN: IANA protocol
Parameter Assignment
Responses to Questions from IAB Advisory Committee
for the IANA Protocol Parameter Assignment Function
November 7, 2003
* (1) Your description of the function you are performing. Is that
* function, and its relationship to the IETF, adequately described in
* RFC 2860 (the MOU) and RFC 2434 (Guidelines for IANA
* considerations), or is additional description required? If the
* latter, what would you suggest?
Per Michelle [Cotton, IANA], RFC 2860 probably remains sufficient as
an MOU describing the functions that the IANA provides to the IETF.
That office consists of, effective soon, a manager, three technical
clerical staff (four full-time equivalents) plus half a dozen people
on a consulting basis, performing functions for the IETF and the
RIRs. The portion of that effort supporting IETF parameter
assignment is roughly a full-time-equivalent plus software support
and normal management/employment overheads. Fundamentally, the IETF
parameter assignment function consists of accepting requests for
protocol numbers for extensible protocols (such as IP Protocol, PPP
PID, TCP/UDP Port, and the like), validating them according to
business rules, identifying the appropriate registry, and in some
cases portion of a registry, assigning the number, and documenting
the result.
RFC 2434 has served the IANA staff well as a guide, but is now in
need of updating. Specific concerns with the document relate to the
meaning of terms and the specificity of the information provided to
the IANA in internet drafts.
One issue relates to the meaning of the term "IETF consensus". When
a document has passed through a defined consensus process, such as a
working group, this is straightforward. When requests come to IANA
that have not done so, IANA needs specific guidance on IETF
expectations. This generally comes in the form of AD direction or
consulting advice. An improved process would help, though; business
rules that inform the IANA when a new registry is appropriate, and
what rules should be applied in assignment of values in any given
registry, for example, would help.
Parameter assignment being an essentially clerical function, specific
guidance to the clerical staff is absolutely mandatory, and often
lacking or unclear. In IANA’s dreams, every internet draft would
contain an IANA Considerations section, even if all it said was "IANA
need not concern itself with this draft". In the absence of such a
statement, the IESG’s IANA Liaison is forced to read the entire
document at least twice: once when the IESG is first handed the
document, to ensure that any instructions to IANA are clear, and
again when the IESG hands the document on, to ensure that it can
perform the requests the draft makes. This is clearly time-consuming
and prone to error.
IANA is now receiving a certain level of instruction in internet
drafts, which is good. However, even the present level of advice is
frequently lacking in clarity. For example, a PPP NCP definition
might well require the assignment of two PIDs, one for the data
exchange and one for the NCP itself. These two numbers come from
four very separate ranges: 0001..00FF, 0101..7FFF, 8001..BFFF, and
C001..FFFF. The choice of range is important, especially on low
speed lines using byte-oriented asynchronous transmission, as the
data assignment has a trade-off implied for the relative frequency of
messages using the specified protocol, and the control function PIDs
are partitioned as well. In such a case, IANA needs to know not that
"two PIDs are required", but that "two PPP PIDs are required, the
data PID named <d-name$gt; defined in section <> from the range
0001..00FF, and the control PID named <c-name$gt; defined in section
<> from the range 8001..BFFF".
Descriptions of registries to be designed need to be equally clear.
If the specification says in its IANA Considerations section that "a
registry named ’Fubar Code Points’ should be built; the initial
values in a table <name> and IANA may assign additional values in any
remaining value between the last initial code point and 65535", that
is exactly what will happen. If there are additional expectations,
such as "the working group’s assigned number advisor will be asked"
or "all assignments must be made in an RFC of informational or
standard status", they won’t necessarily be met - unless the IANA
Considerations section specifies as much. What you put in the IANA
Considerations section is what will be followed. It should be made
clear so that the implementors get what they requested. Also, clear
IANA Considerations sections also help the community, not only IANA.
It makes (1) the authors think about all aspects of the creation of a
registry and instructions on how to maintain but also (2) the public
knows and understands the new registry instructions and how they can
get assignments/registrations in that registry.
Something that would materially help the IANA in its evaluation of
internet drafts is a comment tracking system on the IETF side. The
IANA’s use of such a system is apparent: any comments it makes on the
draft would appear in the system, where the IESG may readily retrieve
them, and the IANA can find its comments when the draft later comes
there. To be truly helpful, it should also include at least any last
call IETF commentary and AD commentary, including agreed changes to
the document. This would permit IANA to review those notes as well,
which may in turn elicit further IANA commentary ("if you make that
change, you should also specify <> in the IANA Considerations
section") or may guide IANA’s implementation.
Normative references apply to IANA considerations as well as to other
parts of the specification. Recently, the IESG started passing
documents along prior to other documents normative for them, allowing
them to sit in later queues to synchronize with their normative
documents. In the special case where the normative document defines
a registry and the draft under discussion assigns a value from that
registry, this case needs to be handled in queue and in process like
any other normative reference.
* (2) What staff is being used to perform these functions and what
* are their particular skills for doing so (either individually or
* in the aggregate)?
The staff assigned to this function, on 4 November 2003, includes
Michelle Cotton and an assistant. They are essentially intelligent
clerical staff familiar with computer back office applications, but
otherwise with no special technical training. For technical
questions, they depend heavily on advisors within IANA or assigned by
the IETF.
It should be kept in mind that it is not the IANA’s job to understand
how every protocol works that is being defined in a new registry.
The IANA needs to know how to create and maintain the registry
administratively.
* (3) What criteria do you use to determine whether you are being
* successful, and how successful? Using those criteria, how
* successful are you and what could be done, especially from the IETF
* side, to improve that evaluation?
The basic measure of success is the number of assignments made.
Michelle’s sense is that IANA is now moderately successful, however
further improvement can be made internally and externally.
Paul is defining web-based automation which should help various
aspects of IANA’s work, including in part the IETF IANA function.
Michelle believes that this automation will materially help her
timeliness. But for that to be carried out properly, clear business
guidelines must be given IANA for each of the existing registries,
guidelines whose application can be readily automated. This is
likely an IETF effort, or at least requires serious IETF input.
* (4) How would you characterize the quality of your relationship
* with the IETF and its leadership? Is there mutual trust and a
* sense of working together on issues, or do you and your
* colleagues sometimes see the relationship as adversarial?
At this point, Michelle feels that IETF/IAB leadership is friendly
and generally constructive. She is very cognizant of AD workload,
and as such tries to focus questions and find other people to ask
them of. As such, she perceives the communication level and volume
to be on the light side of "about right".
Again, amplified clarity of IESG/WG policy would reduce her question
load, and there may be utility for an IAB liaison from the IANA such
as IANA has with the IESG. That is really a question for the IAB; if
it has questions for IANA, the chair should feel free to invite her
comment or invite a liaison.
* (5) Are there specific known problems you would like us to look at
* and understand? If so, please describe them.
This note has made a point concerning clarity of instructions,
clarity of policy, and clarity of registries. There is ongoing work
at IANA to clean up registry files inherited when IANA was split out
from the RFC Editor’s office; in dealing with the business
considerations questions already raised, it may be helpful for a
tiger team from the IETF to review their registries with them and
make suggestions.
There is an ongoing problem with receiving announcements concerning
at least some internet drafts. Michelle plans to follow up with the
Secretariat on this, but in short it appears that the IANA liaison is
not copied on at least some list that internet draft actions are
announced on. This seems to pertain to individual submissions that
the IESG advises the RFC Editor that it "has no problem" publishing.
* (6) How do you see the costs of your function evolving? If things
* become more costly over time, what are the main determiners of
* cost (e.g., general inflation, general IETF growth, increase in the
* number of particular functions you are carried out to
* perform,...). Are you doing some things that IETF (IESG or
* otherwise) request that you do not consider cost-effective and,
* if so, what are they?
As detailed, the function described in RFC 2860 represents
approximately a person-equivalent, plus facilities, software support,
and standard business loading. This has been the approximate load
level for at least the past five years, and is projected to remain
about the same for the near future. The cost-effectiveness issues
revolve around human-in-the-loop effort involved in reading drafts,
investigating inquiries, and such that have been detailed here. The
sense is that an effective comment management system plus the work
flow systems ICANN is planning to implement should result in a net
near term improvement in efficiency and timeliness; projected IETF
growth should then consume that improvement over time.
Author’s Address
IAB Advisory Committee
IETF
EMail: iab@iab.org
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.