Re: I-D ACTION:draft-iab-rfc-editor-00.txt
Eliot Lear wrote: Brian E Carpenter wrote: 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 Nice as this sounds, apparently the IESG seems to have no problem 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iab-rfc-editor-00.txt
Brian E Carpenter wrote: 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 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iab-rfc-editor-00.txt
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 Leslie Daigle wrote: 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 PROTECTED] and specifically on the document draft-klensin-rfc-independent . If this document is to capture *all* the specificallys 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. Brian E Carpenter wrote: 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iab-rfc-editor-00.txt
At 12:58 08/06/2006, Brian E Carpenter wrote: I agree that the main point here is to capture the principle that the various streams should not be shooting at each others' feet. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iab-rfc-editor-00.txt
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 PROTECTED] and specifically on the document draft-klensin-rfc-independent . If this document is to capture *all* the specificallys 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. Brian E Carpenter wrote: 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
