[RTG-DIR] Review of draft-bradner-rfc3979bis-10

Stewart Bryant <stewart@g3ysx.org.uk> Tue, 24 January 2017 16:21 UTC

Return-Path: <stewart@g3ysx.org.uk>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFDA12962C; Tue, 24 Jan 2017 08:21:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Stewart Bryant <stewart@g3ysx.org.uk>
To: rtg-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148527491228.12747.12659683399033217868.idtracker@ietfa.amsl.com>
Date: Tue, 24 Jan 2017 08:21:52 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/msq2Ohd2rkY5Rj_DIwahQM_rtow>
Cc: ietf@ietf.org, draft-bradner-rfc3979bis.all@ietf.org
Subject: [RTG-DIR] Review of draft-bradner-rfc3979bis-10
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2017 16:21:52 -0000

Reviewer: Stewart Bryant
Review result: Has Issues

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing
Directorate seeks to review all routing or routing-related drafts as
they pass
through IETF last call and IESG review, and sometimes on special
request. The
purpose of the review is to provide assistance to the Routing ADs. For
more
information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be
helpful if you could consider them along with any other IETF Last Call
comments
that you receive, and strive to resolve them through discussion or by
updating the
draft.

Document: draft-bradner-rfc3979bis-10.txt
Reviewer: Stewart Bryant
Review Date: 2017/01/24
IETF LC End Date: In Last Call (ends 2017-02-15)
Intended Status: Best Current Practice

Summary: Ready with Issues

Comments:

Given the multitude of issues that surround IPR this is a document
that is almost
impossible to perfect. I have noted below a number of concerns and
consequences
that I suggest the RTG ADs consider during their deliberations.

Issues

I am not sure what classification to give the following comments.


 1. Definitions


      Such statements include oral statements, as well as written and
      electronic communications, which are addressed to:

      o the IETF plenary session,
      o any IETF working group [see BCP 25] or portion thereof,
      o any IETF "birds of a feather" (BOF) session or portion
thereof,
      o any design team [see BCP 25] or portion thereof,
      o the IESG, or any member thereof on behalf of the IESG,
      o the IAB or any member thereof on behalf of the IAB,
      o any IETF mailing list, web site, chat room or discussion
board,
         operated by or under the auspices of the IETF, including the
         IETF list itself,
      o the RFC Editor or the Internet-Drafts function.

      Statements made outside of an IETF session, mailing list or
other
      function, or that are clearly not intended to be input to an
IETF
      activity, group or function, are not Contributions in the
context
      of this document.  For example, the presentations made by
invited
      speakers at IETF plenary sessions to discuss advances in
Internet
      technology generally, or to describe their existing products or
      technologies, are not Contributions.

SB> It is interesting that you exclude WG Chairs from the list of
SB> officials that you call out, and yet they can be a key player in
SB> in deciding whether an encumbered technology progresses or not.
SB>
SB> Would it not be cleaner to express this in terms of "officials"?

=============


   e. "IETF": In the context of this document, the IETF includes all
      individuals who participate in meetings, working groups,
mailing
      lists, functions and other activities which are organized or
      initiated by ISOC, the IESG or the IAB under the general
      designation of the Internet Engineering Task Force or IETF, but
      solely to the extent of such participation.

SB> I think this is a definition of so called "members of the IETF"
SB> Certainly the term "IETF" on its own means a multitude of things
SB> to different people and is easily confused.

==============




   j. "Internet-Draft": a temporary document used in the IETF and RFC
      Editor processes, as described in [RFC2026].

SB> IDs are no longer temporary documents. There was a myth that
SB> were temporary long after they were unofficially archived, but
they
SB> are now formally archived by the tools system. This is important
SB> because they have a potential influence that stretches beyond
SB> the notional six months.

===============


   B. Such Contributor represents that there are no limits to the
      Contributor's ability to make the grants, acknowledgments and
      agreements herein that are reasonably and personally known to
the
      Contributor.

SB> I do not understand what point B above means.

================


   5.2.3      Timing of Disclosure by ADs

   By the nature of their office, IETF area directors may become
aware
   of Contributions late in the process (for example at IETF Last
Call
   or during IESG review) and, therefor and in such cases, cannot
   reasonably be expected to disclose IPR Covering those
Contributions
   until they become aware of them.

SB> I made the following point as an input via another route.
SB>
SB> There are a number of people that would not ordinarily be
expected
SB> to see a document until the very late stages of the process.
SB> The Gen-art reviewers, and the directorates doing cross are
SB> reviews. It would seem reasonable to give dispensation to all
SB> of the groups assisting the ADs in late stage reviews where
SB> the reviewer took no part in the development of the document.
SB>
SB> Either the above or strike the section.

====================

5.4. What Must be in an IPR Disclosure?

5.4.1. Content of IPR Disclosures

   The IPR disclosure must
   also list the name(s) of the inventor(s) (with respect to issued
   patents and published patent applications) and the specific IETF
   Document(s) or activity affected.

SB> It is new to require the names of inventors. Given that the names
SB> of inventors are in the published patent it would seem reasonable
SB> to follow the principle of minimizing the actions required by
SB> organizations outside the IETF and not add this requirement.

   If the IETF Document is an
   Internet-Draft, it must be referenced by specific version number.

SB> That is presumably the version number in which the IPR was
SB> first observed by the IPR owner. You cover updates later
SB> but it may be useful to clarify upfront that you do not expect
SB> per version IPR refresh.

======================


   A. An IPR disclosure must be updated or a new disclosure made
      promptly after any of the following has occurred unless
sufficient
      information to identify the issued patent was disclosed when
the
      patent application was disclosed: (1) the publication of a
      previously unpublished patent application, (2) the abandonment
of
      a patent application (3) the issuance of a patent on a
previously
      disclosed patent application ), (4) a material change to the
IETF
      Document covered by the Disclosure that causes the Disclosure
to
      be covered by additional IPR. If the patent application was
      abandoned, then the new IPR disclosure must explicitly withdraw
      any earlier IPR disclosures based on the application.  IPR
      disclosures against a particular Contribution are assumed to be
      inherited by revisions of the Contribution and by any RFCs that
      are published from the Contribution unless the disclosure has
been
      updated or withdrawn.

SB> The above is ideal, but I seriously wonder if a busy IPR group
SB> will provide update (2) and (3). Given the application number
SB> anyone interested can find the (2)and (3) for themselves.
SB> Again the principle of minimizing the work of third parties
SB> applies.

========================



5.5. Licensing Information in an IPR Disclosure

   A. Since IPR disclosures will be used by IETF working groups
during
      their evaluation of alternative technical solutions, it is
helpful
      if an IPR disclosure includes information about licensing of
the
      IPR in case Implementing Technologies require a license.
      Specifically, it is helpful to indicate whether, upon approval
by
      the IESG for publication as an RFC of the relevant IETF
      specification(s), all persons will be able to obtain the right
to
      implement, use, distribute and exercise other rights with
respect
      to an Implementing Technology a) under a royalty-free and
      otherwise reasonable and non- discriminatory license, or b)
under
      a license that contains reasonable and non-discriminatory terms
      and conditions, including a reasonable royalty or other
payment,
      or c) without the need to obtain a license from the IPR holder
      (e.g., a covenant not to sue).

SB> One of the most popular IPR terms is so called MAD. It is
surprising
SB> that you do not call this out.

===================



5.7. Disclosures for Oral Contributions.

   .... then the Contributor must accompany
   such oral Contribution with an oral declaration that he/she is
aware
   of relevant IPR in as much detail as reasonably possible

SB> I do not recall ever seeing a purely verbal disclosure, and
wonder
SB> what the process is, how this is archived and how it is
discovered?


================


6. Failure to Disclose

   There may be cases in which individuals are not permitted by their
   employers or by other factors to disclose the existence or
substance
   of patent applications or other IPR.  Since disclosure is required
   for anyone making a Contribution or participating in IETF
activities,
   a person who is not willing or able to disclose IPR for this
reason,
   or any other reason, must not contribute to or participate in IETF
   activities with respect to technologies that he or she reasonably
and
   personally knows to be Covered by IPR which he or she will not
   disclose, unless that person knows that his or her employer or
   sponsor will make the required disclosures on his or her behalf.

SB> Doesn't this have implications for those that work or have
SB> previously worked in the defence sector? Do we really wish
SB> to potentially exclude such individuals? I am not sure how
SB> we deal with the situation, but I am concerned about unintended
SB> consequences here.

==================


7. Evaluating Alternative Technologies in IETF Working Groups

   In general, IETF working groups prefer technologies with no known
IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  However, to solve a given technical
problem,
   IETF working groups have the discretion to adopt a technology as
to
   which IPR claims have been made if they feel that this technology
is
   superior enough to alternatives with fewer IPR claims or free
   licensing to outweigh the potential cost of the licenses. To
assist
   these working groups, it is helpful for the IPR claimants to
declare,
   in their IPR Declarations, the terms, if any, on which they are
   willing to license their IPR Covering the relevant IETF Documents.

SB> I really do not see how a WG can properly apply the above
considerations
SB> given that it is not permitted to discuss the financial terms
SB> of the licence.
SB>
SB> Historically this may have been less important, but with IoT this
changes.
SB> what would be a reasonable cost in a core router can be a
showstopper
SB> in a $1 device.


   When adopting new technologies, the participants in an IETF
working
   group are expected to evaluate all the relevant tradeoffs from
their
   perspective. Most of the time these considerations are based
purely
   on technical excellence, but IPR considerations may also affect
the
   evaluation and specific licensing terms may affect the
participants'
   opinion on the desirability of adopting a particular technology.

SB> Again I do not see how this works given the inability to discuss
SB> the detailed licence terms within a WG.

====================

   Some common
   conditions include 1) terms that are fair, reasonable and non-
   discriminatory, and which may bear royalties or other financial
   obligations (FRAND or RAND); 2) royalty-free terms that are
otherwise
   fair, reasonable and non-discriminatory (RAND-z); and 3)
commitments
   not to assert declared IPR.

SB> One of the most common (at least in the Routing area) is
non-assert
SB> unless the other party asserts (so called MAD)

====================

12. Security Considerations

   This memo relates to IETF process, not any particular technology.
   There are security considerations when adopting any technology,
   whether IPR-protected or not.  A working group should take those
   security considerations into account as one part of evaluating the
   technology, just as IPR is one part, but there are no known issues
of
   security with IPR procedures.

SB> I wonder if this is entirely correct. How about someone who owns
SB> IPR silently waiting until deployment and then getting an IPR
SB> based shutdown order? With nations and quasi nations applying
unconventional
SB> warfare, I suspect that there is a potential IPR attack vector.