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

["todd glassey" <[e-mail]>]

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
>


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