[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [INDEP] Last Call for "Independent Submissions to the RFC Editor"
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
INDEPENDENT at ietf.org
https://www1.ietf.org/mailman/listinfo/independent