Subject: Re: [INDEP] Re: FYI: Last Call for "Independent Submissions to the RFC Editor"

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Jan 2007 13:45:58 +0100

On 2006-12-28 23:31, Frank Ellermann wrote:
> Olaf M. Kolkman wrote:
> 
>>     "Independent Submissions to the RFC Editor"
>>     http://tools.ietf.org/id/draft-klensin-rfc-independent-05.txt
> 
> There are some "historically" in this text, where my interpretations
> of "not more relevant" or "not more true" don't fit.  It starts in
> chapter 1.1, the given definitions of "independent submission" and
> "individual submission" are fine, not only "historically".
> 
> In chapter 2 the "historically" starts to worry me:
> 
> |  o  Technical contributions (e.g., RFC 1810 [RFC1810]) and,
> |     historically,
> |  o  RFC Editor and, at least prior to the handoff between ISI and
> |     ICANN and the June 2000 MOU [RFC2860], IANA Policy Statements
> |     (e.g., [RFC2223] and RFC 1591 [RFC1591]).
> 
> They (RfC-editor + ICANN) should be free to continue this tradition.
> Important texts like 2223bis.08 available "only" as I-D aren't ideal.

The text doesn't prevent the RFC Editor from submitting an Independent
Submission to itself, or IANA from submitting one. So I don't see
any restriction introduced by the factual "historically." I would be
against creating explicit "document streams" for the RFC Editor or
IANA; it's complicated enough already.

I would also argue that neither of the examples are good ones for
the future. RFC 2223 is procedural material that should be easy
to update - ideal for an ION. 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.

    Brian

_______________________________________________
INDEPENDENT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/independent

---

From: JFC Morfin <[email-masked]>
Date: Thu, 04 Jan 2007 03:09:01 +0100

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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 06 Jan 2007 17:45:17 +0100

Brian E Carpenter wrote:

> I don't see any restriction introduced by the factual "historically."

Maybe it's a bad case of DEnglish on my side, but I'd still prefer to
remove the "historically" from the draft before publication.

> I would be against creating explicit "document streams" for the
> RFC Editor

+1

> or IANA

That could be tricky, but getting a proper RFC number for their "ICP"
documents, US ASCII and all, I'd like that.  The status could be also
"informational", like RFCs published by the IAB, IESG, or IASA.

> RFC 2223 is procedural material that should be easy to update - ideal
> for an ION.

It will be soon ten years old, it doesn't change often enough for an
ION.  Or rather that's my concept of ION:  Needing modifications often,
like your roadmap text.  Maybe your concept of ION is more like "doesn't
need the complete last call + approval + RFC editor bureaucracy", that
would be somewhat different.

> mad the year after it was published, and I don't ever expect to see

What happened 1995 ?  RFC 1591 is clearly better than RFC 1032, but in
that case the official status is critical to cover the relevant parts
of RFC 954.

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 07 Jan 2007 09:21:41 +0100

> What happened 1995 ?  

pimples.com was registered, which for me was a clear sign of world
insanity. Please excuse me; this is off topic.

    Brian