At 13:45 03/01/2007, Brian E Carpenter wrote:
RFC 1591 is a wonderful document, but unfortunately the world went
mad the year after it was published, and I don't ever expect to see a 1591bis.
There is an RFC 1591 independent submission candidate: the ICP-1
ICANN document. Its update is currently under discussion by ICANN
(http://icann.org/announcements/announcement-2-05dec06.htm). At the
end of the debate, ICANN will have to produce an independent
submission to state its policy in the discussed area (the
IETF/ICANN/IANA MoU makes this kind of decision free from any IETF review).
1) This illustrates one of the issues that I do not see addressed in
John's document (I am travelling and was not able to print it)
This is the name of the I_D to be initially submitted. Independent
submissions of primary interest to the RFC series and IETF are I_D
submitted by other SSDOs, and national or international entities -
including governments (in particular, this is of the essence if we
would like to retain the unity of the Multilingual Internet, with
nationally defined TLDs, such as in China). My understanding is that
only a limited number of organisations belonging to the IETF sphere
can name their I_D texts with their name (e.g. iesg-xxx-01.txt). This
seems inadequate for two reasons:
a) it does not permit one to support the mechanism that produced the
document. For example, why would Paul Twomey or David Conrad affix
their name to a text approved by the ICANN BoD? At the same time, I
cannot see an iana-xxx-01.txt being introduced without having been
approved by the ICANN BoD, most probably by the GAC and certainly by
the NTIA (along with the NTIA/ICANN agreement).
b) this creates an imbalance between SSDOs. As the Draft underlines
it, the IETF is only one of the users/clients of the RFC Editor. All
of the SSDOs should be treated the same. This means that when an
independent submission results from an organised task force, a public
entity, or an international organisation it should be able to sign
its I_D with its own name.
2) the Draft is not clear about the proposed I_D revision process.
There are many reasons provided for the proposed I_Ds to be
discussed, challenged, delayed, or blocked. There is no documentation
about the way the proposed I_D can be modified and further reviewed.
The current procedure seems to imply that an I_D is always proposed
as -00.txt and can only be proposed anew. This may lead to tension
and extra-work, of which a procedure could help avoid. For example, I
would suggest that every Independent Submission, once it is
established that its subject matter lies in the RFC Editor area, be
assigned a Shepherd. He would help the authors to adapt to the RFC
Editor's constraints and to take into account the different reviews
it may receive, as well as to discuss with the reviewers if the
changes made match their "discuss". Moreover, that the procedure will
be documented but as a related ION, so it can adapt to experience
without resulting in an RFC Change.
3) I have another concern, which is translation. Independent
Submissions can result from the effort made by foreign entities or
SSDOs to document their positions to the benefit of the Internet
Community at large. These positions can be expressed in different
languages. I suggest the following:
a) the Independent Submissions MUST indicate if they are the text of
reference, or if they only are a translation of a text of reference
in a non-English language.
b) if the text of reference is not in English, it should be attached
as an appendix to the RFC (to make sure that the same versions are referred to)
c) only texts of reference in one of the relevant languages as
documented by ISO 3166-1:2006 should then be accepted.
jfc
_______________________________________________
INDEPENDENT mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/independent
