Re: I-D ACTION:draft-savola-ipr-lastcall-03.txt

[Pekka Savola <[e-mail]>]

Todd,

Thanks for comments.  Unfortunately, our views on the fundamental IETF
procedures (including but not limited to IPR) seem to differ so much that
I don't think it is possible to incorporate your view in the document.  
If the view would become more prevalent in the IETF and the IPR WG, I
would try to work on them at more length.

On Fri, 4 Jul 2003, todd glassey wrote:
> Pekka - lets talk a little walk here - the cut and pasted sections from your
> document are the indented ones and my comments are on the left margin.
> 
> TSG: In the Intro:
> 
>    Additionally, all documents under the IETF change control (i.e. the
>    author grants the right to create derivative works) for which a last
>    call prior to the approval was not required and IPR disclosures are
>    known, must now be either last-called or rejected.
> 
> TSG: The problem here is that anyone that already started their process had
> a set of terms and conditions set forth for them at that time. There is
> nothing in ANY documents that I have seen that say's "This standards process
> is subject to change, and all terms and conditions for Standards are "soft"
> in nature until such time as the initiative is actually submitted to the
> IESG as a standard"...
> 
> TSG: No WG Chair, AD nor the IETF may changes the conditions on ANY
> initiative already in process. Sorry, but them is lawsuit words. And I will
> take anyone's money on that the IETF and its officers/operators loose  this
> one too.
> 
> TSG: in SS2 -
> 
>    If a verbal IPR disclosure has been minuted in a WG meeting, or an
>    informal IPR disclosure has been made on an IETF mailing list, or
>    other submission subject to the Note Well [NOTE] has been made,
>    documents should not be last-called until a formal IPR disclosure has
>    been made. If this does not occur within a reasonable time, this fact
>    must be mentioned in the last call message.
> 
> 
> TSG: OK - Why the should and not must? what SS2 needs to read like is:
> 
>     In order to qualify for Last-Call capability in the IETF a  IPR
>    disclosure is required to proceed with the last call. If there are no
>    known IPR claims then the IPR declaration of the authors would
>    simply state that there are no known IP Rights issues with this
>    initiative and a simple statement of the manner this was verified in.
> 
>    If a verbal IPR disclosure has been minuted in a WG meeting, or an
>    informal IPR disclosure has been made on an IETF mailing list, or
>    other submission subject to the Note Well [NOTE] has been made,
>    documents cannot not be last-called until a formal IPR disclosure has
>    been made to satisfy the concern raised as part of the organizations
>    records. No initiative may be advanced to Last Call without some
>    cursory IPR disclosure at the WG level and a formal one at the IETF
>    or Standards Track Level.
> 
> TSG: ... and onward - I eliminated the first paragraph of 3. IPR disclosures
> at some level are mandatory in my book for all initiatives entering into any
> last-call's whether as part of the WG or the organization as a whole. The
> formal IPR and licensing statement should only be necessary for the IETF
> Last Call but certainly a cursory one is needed at the WG level because by
> this time there is significant investment by many individuals who may be
> stepping into a legal morass (or more importantly - they are being led into
> this morass...)
> 
> 3. Working Group Last Calls
> 
>    Working group last call, the chair(s) issuing the last
>    call should also make a mention whether IPR concerns have been raised
>    regarding the document, or whether no disclosures or other knowledge
>    are known, as described in section 2.
> 
>    The reason why describing IPR issues in WG last calls is not
>    mandatory is due to the assumption that most WG participants can be
>    expected to be aware of the IPR of the technologies being worked on
>    in the working group.
> 
> TSG: Hmmm - This is a very slippery legal premise and its really
> unenforceable.
> 
>    However, everyone may not be fully aware of
>    all the IPR in a WG, and IPR disclosures may have been made only
>    recently after a participant has last looked at the IPR repository.
>    Thus, it is strongly encouraged to include an IPR notice in all
>    working group last calls.
> 
> TSG: yeah - OK, look this is way to complex and you don't need to justify
> why your process is what it is so my take is a total rewrite on SS3 reducing
> it to TWO (2) Paragraphs:
> 
>     When submitting an initiative for Last-Call at the WG level a topical
>     statement of IPR and any concerns is to be created as part of the
>     initiatives IETF Standards Portfolio. This document is a simple
>     declaration stating the either there are no known IPR issues at
>     that time, or that there are known IPR issues in the areas of... and
>     then a listing of these areas.
> 
>     This statement can be qualified with a simple IP Search and a listed
>     set of keywords. The search sites are to be the US Patent and Trade
>     Mark offices online Websearch Tool, and the same for the Euro
>     Patent Office.
> 
> And on to ss4 -
> 
> 4. IETF Last Calls
> 
>    IETF Last Calls are mandatory for all standards track documents
>    [IETF], whether for entering into, advancing within or removing from
>    the standards track.
> 
> TSG: I have a fundamental disagreement with much of 4.1. It is more complex
> rules that are easily twisted. What is needed is much more simple processes.
> 
> 4.1. When to Have an IETF Last Call
> 
>    It has not been necessary to last-call Experimental and Informational
>    RFC's which are products of a working group.
> 
> TSG: No, I disagree. Anything that is published in the form of any formal
> initiative MUST have a IPR for it if the IETF is to be indemnified by the
> process such that it would me held blameless.
> 
>    If such a document has
>    known IPR, whether formally disclosed or not, an IETF last call must
>    be executed in the similar fashion as with standards track documents
>    [IETF].
> 
>    It has not been necessary to last-call non-WG Experimental or
>    Informational RFC submissions going directly to the RFC Editor.  Some
>    of these documents are not under the IETF change control, i.e., no
>    rights to create derivative works are granted, or that only
>    publication as an Internet-Draft is allowed; examples of such are
>    proprietary protocols and republications of other Standards
>    Organizations' documents.
> 
> TSG: Any document published with the ISOC copyright on it is a liability
> here.
> 
>    When a document under the IETF change control is passed to the IESG
>    for review, and the document has known (to the Area Director and the
>    IESG in particular, but also in general) IPR, whether disclosed or
>    not, an IETF last call must be executed in similar fashion as with
>    standards track documents, or the IESG must propose that the RFC
>    Editor not publish the document.
> 
> TSG: This is a complex and very dangerous process. If a IESG staffer failed
> to "SUGGEST" or "PROPOSE" that the Editor not publish it, they would likely
> bear direct liability in any damages. Further that there is no real
> responsibility of the Editor to make sure that the document is fit for
> publication is another serious liability.
> 
>    If the RFC Editor publishes such a document anyway,
> 
> TSG: See this is the point - How can the Editor publish this document. Are
> they immune from the IETF's control here? if so then this whole effort is
> pointless and will be seen for what it is, a song-and-dance effort at vapor
> to protect the management of the IETF from their own acts. Sorry - but
> that's how it is.
> 
>    the IESG must
>    insert an appropriate IESG Note in the document, as described in
>    [IETF], indicating the presence of IPR.
> 
> TSG: Which further brings up who manages the Editors, and if they can tell
> the IETF's WG Chairs and AD's to get stuffed and that they are going to
> publish the disputed IP's anyway, then how does the above sentence possibly
> apply?
> 
>    Note that due to possibly different policies, the existence of IPR
>    issues in e.g. IRTF RFC submissions may not be known at all if no IPR
>    disclosures are made for such Internet-Drafts.
> 
> TSG: And now onto SS 4.2
> 
> 
> 4.2. The Contents of the IETF Last Call
> 
>    Any IETF Last Call must include an indication whether IPR has been
>    disclosed or otherwise known, and if so, the pointer to the
>    disclosure in the IPR repository, as specified in section 2.
> 
>    It is recommended that some additional information is also provided
>    in the last call, as the readers of the IETF last call cannot be
>    expected to know the details why the particular solution was chosen
>    despite the known IPR.
> 
>    If a document is being removed from the standards track and is being
>    replaced with something else, possible IPR disclosures with the
>    latter should also be described in the similar fashion in the last
>    call.
> 
>    The responsibility for filling the IPR parts of an IETF last call is
>    with the shepherding Area Director [PROCED], but it is expected that
>    in practice it's done by the working group chairs (if applicable) or
>    document authors/editors.
> 
> TSG: OK - But the last paragraph needs to go. The AD's CANNOT be responsible
> for any of the IP Filings or they will bear direct liability for any
> failings. So the only possible solution here is that the AD's cannot advance
> any initiative without proper IPR in place, but in all instances, the IPR
> filing process and content MUST come from those submitting and petitioning
> for the advancement of any initiative.
> 
> TSG: As to SS5 - REMOVE IT IN ITS ENTIRETY. It creates a set of loopholes
> and makes this process of dubious value.
> 
> 
> Todd
> 
> 
> 
> 
> 
> 
> 
> ----- Original Message ----- 
> From: "Pekka Savola" <[e-mail]>
> To: <[e-mail]>
> Sent: Friday, July 04, 2003 5:42 AM
> Subject: Re: I-D ACTION:draft-savola-ipr-lastcall-03.txt
> 
> 
> > FWIW,
> >
> > I've updated the document based on comments (everything incorporated in
> > some fashion or another).  The policies are slightly more flexible now.
> >
> > Any issues left?
> > Is this something we could recommend e.g. the IESG to try out?
> >
> >
> > On Thu, 3 Jul 2003 [e-mail] wrote:
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > >
> > >
> > > Title : Mentioning Intellectual Property Rights Considerations
> > >                           in Last Calls
> > > Author(s) : P. Savola
> > > Filename : draft-savola-ipr-lastcall-03.txt
> > > Pages : 9
> > > Date : 2003-7-3
> > >
> > > This memo describes an additional policy with last calls regarding
> > > Intellectual Property Rights (IPR) disclosures or other knowledge of
> > > IPR.  The existence and the pointer to the IPR disclosures or an
> > > indication of non-existence of knowledge of such disclosures must be
> > > mentioned in all IETF last calls and should be mentioned in working
> > > group last calls.  Additionally, all documents under the IETF change
> > > control for which a last call prior to the approval was not required
> > > and IPR disclosures are known, must now be either last-called or
> > > rejected.  This memo updates RFC 2026 and RFC 2418.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-savola-ipr-lastcall-03.txt
> > >
> > > To remove yourself from the IETF Announcement list, send a message to
> > > ietf-announce-request with the word unsubscribe in the body of the
> message.
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > > "get draft-savola-ipr-lastcall-03.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > > [e-mail].
> > > In the body type:
> > > "FILE /internet-drafts/draft-savola-ipr-lastcall-03.txt".
> > >
> > > NOTE: The mail server at ietf.org can return the document in
> > > MIME-encoded form by using the "mpack" utility.  To use this
> > > feature, insert the command "ENCODING mime" before the "FILE"
> > > command.  To decode the response(s), you will need "munpack" or
> > > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > > exhibit different behavior, especially when dealing with
> > > "multipart" MIME messages (i.e. documents which have been split
> > > up into multiple messages), so check your local documentation on
> > > how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> >
> > -- 
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> >
> > _______________________________________________
> > Ipr-wg mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/ipr-wg
> >
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


_______________________________________________
Ipr-wg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipr-wg