Revisions to the RFC Editor web site make it easier to use. A searchable database is available. Marshall
Rose and Carl Malamud started a project where they converted RFCs to XML as source rather than
ASCII.
A common tool would make life easier, but not Word. RFCs need to be easier to produce. Would be nice
to have a format that supports tables and graphs. IETF is not trying to sell RFCs, but maintain an archive.
Good reason to stick with ASCII is for developing countries. Format should be self-contained (therefore
not HTML), so links would not be stale, and conformant in a verifiable way. Don�t use proprietary
formats. Need to move on from ASCII; publish in more than one format. No consensus. Is this purely a
technical specification? Yes. Consensus on Marshall publishing his draft as an informational RFC and
individual members of the WG encouraged to comment.
3. Copyright
Copyright statement is embedded in standard process RFC. Scott Bradner: the reason for the copyright is
to ensure RFC�s availability; limited use. See RFC 2026. To apply to all contributions? When does this
apply? Are derivative rights permitted? Three options. Issue: documents submitted to the working group
containing a prohibition on the creation of derived works. Motivation: protection against other-party
takeover of submitters� drafts. In essence, lack of trust in the integrity of other participants. Problem:
even informational-track material may be destined for incorporation in another document rather than being
kept in its original form. Resolution: advice that prohibition against creation of derived works is
acceptable only for non-standards-track documents which are strictly for the information of the Internet
community and not intended to be incorporated into working group documents. Documents, for example,
submitted to other organizations such as ISO should not be modified later. ISIS case could see both
options
one and two. Suggestion to ask the lawyers for a statement to justify the copyright statement and to
reduce
confusion.
4. IETF protocol parameter registration
Brian Carpenter: Everything is still working and done by the same people in the same location (former
IANA). Job list created. US Government said, ��coordinate the assignment of technical protocol
parameters.� Esther Dyson clarified that it is not ICANN policy to do parameter assignments. After policy
discussions, we will finalize the job list between IAB and ICANN/IANA.
5. ICANN and PSO
Scott Bradner: ICANN grew out of the Green Paper and White Paper and its charter is be the top of the
pyramid for domain names and IP addresses, responsible for root name servers, and to �coordinate the
assignment of protocol parameters.� Structure is Board, supporting organizations and committees, and
miscellaneous ICANN committees. ICANN is the facilitator of rule making, not actual assigning of
parameters. Domain Name Supporting Organization, Address Supporting Organization, and Protocol
Supporting Organization: propose and review policies related to names, addresses, and standards
organizations. Board consists of 9 at-large directors and 3 from each SO with geographical distribution.
Remark: Respond to WIPO RFC3, which is input to ICANN�s processes re: trademarks (www.wipo.int).
Is there a need for a PSO? What is the role of the PSO? Pro: structured way to import technical clues
into
ICANN, protocol council gets to review protocol-related policy proposals, PSO nominated Board members
vote on policy proposals from elsewhere, forum to resolve assignment disputes between standards
organizations. Cons: ICANN can ask when it needs advice, standards organizations are different than
addresses or names (addresses and names get some authority from ICANN; not needed for standards
organization), unknown impact on standards organization�s autonomy. For example, standards
organizations need to review for content.
Should a PSO be a committee of ICANN (like the DNSO proposal)? Pro: It�s what the Board seems to
like, no confusing separate organization, liability issues are clearer, it is cheaper, may be easier for some
standards organizations to deal with. Con: unknown impact on standards organization�s autonomy, not in
control of own processes (may be ameliorated by MoU instead of membership or appointing
representatives).
How many classes/constituencies? Proposal: two classes: 1) open, international, voluntary technical
standard and technical specification development organization which: develop IP standards, is greater than
a minimum size, produces significant deployment of standards, whose standards are available for free or a
small processing fee, 2) other standards organizations. Rationale behind this (change from last time when
four were presented) is that the PSO should be composed of �practitioners of the art.� Can participate
through the standards organizations or through the at-large members. Anyone can come to IETF; many
companies can join W3C.
Esther Dyson: Similar to IETF, the Board has different opinions but operates through consensus. DNSO
process: Board will ratify what comes up that isn�t crazy. More than one proposal was presented and
Board
combined them. Would like to see the same process used. General assembly and constituencies are used;
would IETF map to one or the other? Send three people, and policy recommendations to the ICANN
Board are the two things the PSO needs to do. The PSO would involve more than talking to ICANN
Board, they would also be talking to other SOs. May 24-27 is next Board meeting in Berlin. If the
proposal can be posted a month before, then the Board can consider it at this meeting. The WIPO paper
will be discussed in Berlin. The ASO will probably be presented in Santiago, Chile August 24-26.
Mike Roberts: People need to understand the government process was bureaucratic, but it has been
trimmed back. The SOs are a device for intelligent advice to be present at the table for discussions.
Bylaws got top heavy due to latecomers with paranoia. Want to stay as lightweight as possible while
satisfying openness and fairness. CEO gets the people to get the job done, also gets advice. For example,
accreditation guidelines moved from the Board to actual documents and people are working on
submissions. Will ICANN take advice? Yes, IANA has technical advisors. Also position for CTO to be
recruited.
Hans Kraijenbrink: From principles derived at the Singapore meeting for the DNSO:
ICANN Board
At-large DNSO ASO PSO
|
protocol council members Council
representatives from |
standards committees General Assembly
IETF
John Klensin: Are there alternatives to the PSO while preserving the objectives? I support this Board and
ICANN. IETF doesn�t vote. Proposal: drop the PSO and replace it with ex-officio, non-voting seats on
the
Board. Work by persuasion. This is very lightweight.
After these presentations there was a discussion. Where some sort of consensus seemed to emerge, so the
Chair took some straw polls:
1. No PSO? IETF delivers expertise via another method. No consensus.
2. If there is a PSO, does IETF need to be a part of it? Yes, consensus.
3. If there is a PSO, should it be lightweight. Not asked because no one presented a different viewpoint.
4. Should the PSO be part of ICANN? Consensus was that people did not have enough information to
decide.
Erik Huizer: My summary is 1) to support ICANN, 2) to keep the IETF independent, and 3) to provide
technical input to ICANN. What is the best means to provide this input?
Scott Bradner: Let�s propose a concrete skeleton and discuss it on the POISED list.
Erik Huizer: And let�s try to get consensus by the deadline for the Berlin Board meeting which is
approximately April 20.
