Subject: Re: [INDEP] Re: Last call on draft-klensin-independent...

From: Bob Braden <[email-masked]>
Date: Tue, 23 Jan 2007 09:29:19 -0800 (PST)

*> I did note an issue which I think could use more clarification in this document,
  *> which is whether the Independent Submission track is solely for 
  *> publication of Informational/Experimental RFCs, or whether it can be also 
  *> used to publish BCPs or Standards track RFCs.   I would like to see an 
  *> explicit statement in the document saying that the process only applies to 
  *> Informational/Experimental documents, and cannot be used for other 
  *> purposes.

Bernard,

Certainly everyone understands this, and I thought that 2026 already
stated it.  Whatever. It is not clear that this is the correct place
for defining legal mappings of document streams onto RFC categories,
but as a pragmatic matter, fine, let's make sure draft-klensin is
explicit about what categories are allowed.

  *> 
  *> RFC 3932 Section 1 says that it solely concerns "RFC Editor
  *> documents to Experimental/ Informational" status.  This implies that
  *> the process defined in that document can't be used for Standard track 
  *> documents, but it doesn't preclude other documents from specifying such a 
  *> process.  Given this, I would like to make sure that 

Wow!! You have missed a calling as a lawyer!! Or ARE you a lawyer?
That implication seems far-fetched to me, and clearly was not intended.

Bob Braden

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Jan 2007 09:40:04 -0800 (PST)

> explicit about what categories are allowed.

My concern in part derives from recent Independent Submissions which, 
while specified as Informational Status, modify Standards Track 
documents, or request the allocation of IANA parameters reserved for 
Standards Action or IETF Consensus.  This does not appear to be precluded 
by this document, yet if allowed to proceed would circumvent RFC 2026.

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Jan 2007 14:45:31 -0500

--On Tuesday, 23 January, 2007 09:40 -0800 Bernard Aboba
<[email-masked]> wrote:

>> Certainly everyone understands this, and I thought that 2026
>> already stated it.  Whatever. It is not clear that this is
>> the correct place for defining legal mappings of document
>> streams onto RFC categories, but as a pragmatic matter, fine,
>> let's make sure draft-klensin is explicit about what
>> categories are allowed.
> 
> My concern in part derives from recent Independent Submissions
> which,  while specified as Informational Status, modify
> Standards Track  documents, or request the allocation of IANA
> parameters reserved for  Standards Action or IETF Consensus.
> This does not appear to be precluded  by this document, yet if
> allowed to proceed would circumvent RFC 2026. 

In practical terms, if such a document reaches the IESG on
RFC3932 review, the IESG should say "whoops, RFCs 2026 and 9999
require that the actions specified here by done only in
standards track documents, so we are taking over responsibility"
and the IANA should say "the document can't do that because
those things can be done only in a standards-track document".  

While I would expect the RFC Editor to speak up if they
discovered these, or similar problems (that is exactly what
asking a relevant AD to do an early-stage review is all above),
requiring that the RFC Editor detect such things would be
pointless: we can't expect them to have the needed comprehensive
knowledge and that fact is what the required IESG and IANA
reviews are all about.  If I recall, the drafts doesn't
explicitly require an IANA review -- perhaps that should be
fixed, or perhaps we can rely on the RFC Editor's good sense
when a document appears to require IANA actions).

It seems to me that your request is getting close to a provision
that says "the RFC Editor will not be stupid and will avoid
acting in ways that are obviously intended to end-run
established IETF or IANA procedures or otherwise against the
clear best interests of the community".   If there is consensus
that such a statement should be added, and on appropriate text,
I'll be happy to add it.   However...

    john