Re: IETF Last Call for two IPR WG Dcouments

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(_at_)NLnetLabs(_dot_)nl>
> > 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  
> > > the
> > > incoming rights document applies to the IETF Stream.
> > >
> > > To me it is clear that a contribution to the IAB is explicitly  
> > > bound by
> > > the rules (including the No Duty to Publish rule, that allows for
> > > confidential 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 the
> > > IAB stream is also not captured.
> > >
> > > The independent stream document are clearly excluded by section 4  
> > > of the
> > > document.
> > >
> > > It is not quite clear where the IRTF stream document live. This  
> > > could be
> > > fixed 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(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> IETF mailing list
> IETF(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf