The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <200404080143.SAA26584@redback.com>, Naiming Shen writes:
> 
> Curtis,
> 
>  ] 
>  ] In message <200404052214.PAA24523@redback.com>, Naiming Shen writes:
>  ] > 
>  ] > Hi,
>  ] > 
>  ] > We presented the below two drafts in Seoul ietf, and we would like
>  ] > them to be discussed more on this mailing alias. The authors would
>  ] > like to move them into WG documents. We are very interested in any
>  ] > comments on them.
>  ] > 
>  ] > draft-shen-nhop-fastreroute-00.txt
>  ] > draft-shen-mpls-ldp-nnhop-label-00.txt
>  ] > 
>  ] > thanks.
>  ] > - Naiming
>  ] 
>  ] 
>  ] I'd say reject them both on the basis that they contain the following
>  ] statement.
>  ] 
>  ]   7. Intellectual Property Considerations
>  ] 
>  ]    Redback Networks may have intellectual property rights claimed in
>  ]    regard to some of the specification contained in this document.
>  ] 
>  ] We can't be moving things to standards which are encumbered by
>  ] intellectual property restrictions.
>  ] 
> 
> We are not asking for moving into standards for those drafts at this
> stage. By the time those drafts were ready to be advanced to the
> standards, we would do whatever IETF IPR procedure requires, I don't
> have any problem with that. Similar statements are not uncommon in
> Internet drafts and working-group documents before they are advanced
> to IESG as far as I can tell. For example, in the draft
> draft-atlas-ip-local-protect-00.txt section 8:
> 
>    Avici Systems has intellectual property rights claimed in regard to
>    the specification contained in this document.
> 
> I would think it's a professional courtesy for the authors of that
> draft to mention this issue within this community when it's first
> published. If this working-group has some special procedures to follow,
> we would like to hear them from the chairs or ADs, I would be happen
> to comply.
> 
> thanks.
> 
>  ] Curtis
>  ] 
> 
> - Naiming


Naiming,

My personal opinion, which is not necessarily my employers opinion, is
that the IESG sorely needs to revisit their policy and procedures for
handling encumbered documents.  An example of a better procedure is:

  For all drafts which are enbumbered by intellectual property
  restrictions the following procedure should be followed:

  If an agreement can be reached such that any party can license the
  technology for a nominal fee (for example: $1 and/or agreement to
  acknowledge the holder of the technology), then state this in the
  document and consider the document unencumbered.

  Otherwise:

  Determine what subset of the draft would require licensing.  If that
  can't be determined assume that the entire draft is encumbered.

  If a non-essential subset is encumbered, break out that subset into
  a separate draft, such that the base document is unencumbered, then
  reconsider the second as an extension to the base document.

  If an entire draft is encumbered, then under no circumstances can
  the draft be advanced on the standards track, however under certain
  conditions it may be advanced to informational.  If a protocol is
  widely deployed and there is a need for the networking community to
  know about it, then the draft can become an informational RFC.  If
  the draft is not widely deployed or there is no need for the
  networking community to know its workings, then it should not be
  published in any form.  Any encumbered subset split from a base
  document specificly to make the base document unencumbered can also
  be advanced to informational.

Cases where the community may need to understand how a protocol works
include protocols in which the open software community has been
granted fairly unrestricted permission to implement (NFS for example).
Another case would be where there may be a need to monitor the
activity of the protocol for network management reasons and that
monitoring would not infringe, though I can't think of a good example
of this at the moment.  Any cases where a proprietary extension has
been split from a non-proprietary base document should be given
special consideration and the encumbered extension accepted as
informational as further incentive to make the split.

No draft, including draft-atlas-ip-local-protect, should be excluded
from this process.

This is a topic for the IPR WG, not for MPLS so this is the last Cc of
MPLS for me.  My earlier point was we should reject this document at
this point.  If you would provide more detailed information on what
the restrictions are, I might change my mind but I also might ask that
you split the document (see above).

Once again, in IETF tradition, I'm giving my personal opinion.  I feel
this is a matter of what is good for the networking community as a
whole, which should be the IETF goal, not what is good for individual
stakeholders.

Curtis

ps - Since you brought up Alia's draft perhaps Alia could comment on
Avici's intention to licence.  I haven't check with the powers that be
and legal so I won't try to answer that.