On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
While not really disagreeing with Leslie and Olaf, I would point out that the IPR WG was chartered to look at IETF documents.
Those being ietf-stream exclusively or implicitly also covering the iab-stream?
Personally, I think it makes sense that the iab-stream is covered, but let me put that in front of the IAB too.
We can have a meta-discussion about where the clarifications belong, but it seems to me that the WG consensus definitely assumed that scope and no wider scope. I'd be happy if that was made clear in the drafts, rather than trying to cover the other documents streams by some kind of awkward retro-fit.
My suggestion is to rewrite section 4 a bit to call out that this document does not cover the incoming rights for the independent and irtf stream and to use the terms "ietf-stream" and possibly "iab- stream" in the definitions.
Such a rewrite would preserve the status quo for the independent and irtf stream.
no-hats, --Olaf <no further comments below> On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
While not really disagreeing with Leslie and Olaf, I would point out that the IPR WG was chartered to look at IETF documents. We can have a meta-discussion about where the clarifications belong, but it seems to me that the WG consensus definitely assumed that scope and no wider scope. I'd be happy if that was made clear in the drafts, rather than trying to cover the other documents streams by some kind of awkward retro-fit. Brian On 2008-03-28 08:15, Leslie Daigle wrote:--On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman <olaf@xxxxxxxxxxxx>wrote:I would think that the document would gain in clarity if it explicitly ties the incoming rights to the streams as defined in RFC4844 and also explicitly calls out that if new streams would be defined those should specifically define if and how rights are transferred to the IETF Trust.I would have to agree with the above, and say further that the the IAB should make sure that the entities responsible for the non-IETF streams are okay with the result. When writing the streams definitions, it was clear that there was a lot of material that was spread across existing documents without clear delineation between "IETF" or "non-IETF" documents, let alone further refinement into what has become "streams". THat's understandable, historically, but we should be clearer going forward. Breaking it out, as you suggest, would be consistent with that goal. Leslie.While reviewing the documents I tried to determine how the 4 streams currently defined in RFC4844 fit into the framework.Although the stream is not specifically mentioned it is clear that theincoming rights document applies to the IETF Stream.To me it is clear that a contribution to the IAB is explicitly bound bythe rules (including the No Duty to Publish rule, that allows forconfidential information to be supplied to the IAB), so are contributions from the IAB, i.e. IAB stream document. I conclude this from the fact that "IAB" is part of the IETF under the definition in 1.e. However, I may be over-interpreting, and the status of the incoming rights for theIAB stream is also not captured.The independent stream document are clearly excluded by section 4 of thedocument.It is not quite clear where the IRTF stream document live. This could befixed in a document which defines the IRTF stream.I would think that the document would gain in clarity if it explicitly ties the incoming rights to the streams as defined in RFC4844 and also explicitly calls out that if new streams would be defined those should specifically define if and how rights are transfered to the IETF Trust.--Olaf (no hats)_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf