Subject: Re: I-D ACTION:draft-iab-rfc-editor-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Jun 2006 09:50:57 +0200

Although I'm an IAB member, I'd rather make my one comment
on this draft in public.

I think it misses one point that should be mentioned. The
easiest way to explain it is to suggest new text:

4.4. Avoiding interference between publication streams

Although diversity of views and alternative solutions are
common and will commonly be published, it would be highly
undesirable for documents published in the different streams
to interfere actively with each other, for example
by specifying incompatible extensions to the same protocol
or alternative uses for the same parameter value.

For this reason, the procedures adopted for the four streams
will include appropriate checks and balances to avoid such
interference. Specifically, this will include a procedure
(currently documented in [RFC3932]) to avoid Independent
Submissions actively interfering with IETF Documents.

     Brian

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

1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <[email-masked]>; Wed, 7 Jun 2006 09:52:55 +0200
Date: Wed, 07 Jun 2006 09:50:57 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: IETF discussion list <[email-masked]>
Subject: Re: I-D ACTION:draft-iab-rfc-editor-00.txt

Although I'm an IAB member, I'd rather make my one comment
on this draft in public.

I think it misses one point that should be mentioned. The
easiest way to explain it is to suggest new text:

4.4. Avoiding interference between publication streams

Although diversity of views and alternative solutions are
common and will commonly be published, it would be highly
undesirable for documents published in the different streams
to interfere actively with each other, for example
by specifying incompatible extensions to the same protocol
or alternative uses for the same parameter value.

For this reason, the procedures adopted for the four streams
will include appropriate checks and balances to avoid such
interference. Specifically, this will include a procedure
(currently documented in [RFC3932]) to avoid Independent
Submissions actively interfering with IETF Documents.

     Brian

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

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 07 Jun 2006 18:51:34 -0400

I agree that the principle of avoiding interference is
a general one that could be captured in this document.
And I think this document had better be consistent in
its application of principles.

I will observe that as the documents are currently
structured, the definitions of the individual streams discuss
the details of handling those (inter)dependencies.  Therefore,
I believe your last sentence belongs as a comment on
[email-masked]  and specifically on the document
draft-klensin-rfc-independent .

If this document is to capture *all* the "specifically"s
of document stream interdependence, we will also have to
capture the expectation that the IETF stream will not interfere
with the IAB stream, and so on.  I don't think that's
effectively achievable or even maintainable in this document.

Leslie.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 08 Jun 2006 08:59:33 +0200

> 4.4. Avoiding interference between publication streams

Nice as this sounds, apparently the IESG seems to have no problem
approving documents within a stream that interfere with each other. 
Perhaps we could have some guidance there as well?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Jun 2006 12:58:33 +0200

I agree that the main point here is to capture the principle
that the various streams should not be shooting at each
others' feet.

    Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 08 Jun 2006 13:31:08 +0200

>that the various streams should not be shooting at each

Then forget about innovation and architectural change within the 
IETF. You will get them anyway. But they will be outside. In 
disorder. And shooting at others feet, legs, etc. This RFC 3774 
affinity group's attitude delayed evolution. To the point a 
revolution is needed. At least try to support it if you cannot 
address or unover it (cf. IAB architecture mailing list). There are 
not many people with a vision. If you push them away ...

Now, RFCs for information may seem confusing. Create a new series and 
publish what people ask. The INTF bootstrap decided to go with an IID 
series (INTF Information Document). We are working on the practical 
aspects (a PDF document - supported in Open Office, an ASCII annex) 
to solve graphic problem. Why not to adopt a similar approach?
jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Jun 2006 15:20:37 +0200

> approving documents within a stream that interfere with each other. 

Well, that gets a bit complicated. I was going to say that we
wouldn't do that *intentionally*, but we might - if there was in
fact IETF consensus to develop alternative solutions for the same
problem. But we certainly shouldn't approve two different uses for
the same TLV, for example.

> Perhaps we could have some guidance there as well?

Like, the IESG should apply common sense? ;-)

Seriously, I find it hard to see what words would help here.

    Brian