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

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

Pekka -
----- Original Message ----- 
From: "Pekka Savola" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 09, 2003 3:59 AM
Subject: Re: I-D ACTION:draft-savola-ipr-lastcall-03.txt


> 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.

Then my only choice is to create a competitive document. Wouldnt you think?

>
> 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