headers
Scott Bradner | 1 Aug 2003 02:03
Picon
Favicon

Re: Comments on draft-ietf-ipr-technology-rights-10.txt

thomas has many comments - I'll respond to them off and on
as I review them

the 1st one

> >    Note that an standards track IETF Document can make normative
> >    reference to proprietary technology in some cases, for example, when
> >    making parameter assignments or encapsulations (e.g., "parameter
> >    value 1234 refers to proprietary technology A" or "proprietary
> >    technology B can be encapsulated using the techniques described in
> >    RFC XYZ.")
> 
> While I don't necessarily disagree with the words, this text seems
> somewhat out of place in this document. I.e, this seems to be a
> change to the "normative" language of 2026. Is it? Is this the right
> place to do so? 

1/ since this issue has come up many times in the past I think it needs
to be somewhate in one of the defining RFCs (i.e. not in a descriptive RFC
like the WG guidelines

2/ it is not a change to the normative refence rule in 2026 - it is
an explanation of how assigning a codepoint (for example) does not
require a normative refence to where the technology that will
use the codepoint is defined - this is how we have been operating for
many years

Scott
Permalink | Reply | 19 comments |
headers
Thomas Narten | 1 Aug 2003 04:00
Picon
Favicon

normative reference text (was: Re: Comments on draft-ietf-ipr-technology-rights-10.txt )

Hi Scott.

Please feel free to change subject headings when responding to
individual points. That will make it a bit easier for folks to follow.

> > >    Note that an standards track IETF Document can make normative
> > >    reference to proprietary technology in some cases, for example, when
> > >    making parameter assignments or encapsulations (e.g., "parameter
> > >    value 1234 refers to proprietary technology A" or "proprietary
> > >    technology B can be encapsulated using the techniques described in
> > >    RFC XYZ.")
> > 
> > While I don't necessarily disagree with the words, this text seems
> > somewhat out of place in this document. I.e, this seems to be a
> > change to the "normative" language of 2026. Is it? Is this the right
> > place to do so? 

> 1/ since this issue has come up many times in the past I think it needs
> to be somewhate in one of the defining RFCs (i.e. not in a descriptive RFC
> like the WG guidelines

Which issue? The issue of whether a standards track document can
normatively reference proprietary technology? (I agree that such
references are allowed.)

> 2/ it is not a change to the normative refence rule in 2026 - it is
> an explanation of how assigning a codepoint (for example) does not
> require a normative refence to where the technology that will
> use the codepoint is defined - this is how we have been operating for
> many years
(Continue reading)

Permalink | Reply | 18 comments |
headers
Scott Bradner | 1 Aug 2003 04:15
Picon
Favicon

Re: normative reference text (was: Re: Comments on draft-ietf-ipr-technology-rights-10.txt )

> > 1/ since this issue has come up many times in the past I think it needs
> > to be somewhate in one of the defining RFCs (i.e. not in a descriptive RFC
> > like the WG guidelines
> 
> Which issue? The issue of whether a standards track document can
> normatively reference proprietary technology? (I agree that such
> references are allowed.)

yes - that issue
I have gotten this question every year or so for the past 6 years

> > 2/ it is not a change to the normative refence rule in 2026 - it is
> > an explanation of how assigning a codepoint (for example) does not
> > require a normative refence to where the technology that will
> > use the codepoint is defined - this is how we have been operating for
> > many years
> 
> If the codepoint example _isn't_ normative, then I don't understand
> the quoted text in the document, which cites codepoints as an example
> of where such a normative reference might be appropriate.
>  
> If the point is just to make it clear that Standard Track documents
> can reference encumbered technology, I agree that this document is an
> OK place to say that. (I could also try to suggest better wording, but
> I first need to understand what is intended.)

yes - that is what is intended
plese do send better words if the current ones are confusing

Scott
(Continue reading)

Permalink | Reply | 17 comments |
headers
Scott Bradner | 1 Aug 2003 04:48
Picon
Favicon

-technology-rights-10.txt - rfc ed docs & ipr


thomas asks
> >    Drafts not intended to become part of the Standards Process, the
> >    following are required in all such drafts to protect the IETF and its
> >    processes.  The RFC Editor may require additional notices.
> >
> >    a. An IPR Disclosure Acknowledgement, identical to that specified in
> >       Section 5.1.
> 
> I gather from this that IPR disclosures for RFC contributions are the
> same as for IETF contribution. Correct?

yes

> But the above text is implied only because an RFC Editor Document must
> first be an ID. Once the ID is an RFC, is there any obligation to
> disclose or update IPR?

that is up to the RFC Editor - the reason this doc talks about IPR & 
RFC Ed contributions at all is because the IETF publishes IDs
anything after the ID stage if up to the RFC Ed because it is not
an IETF activity

Scott
Permalink | Reply | 1 comment |
headers
Scott Bradner | 1 Aug 2003 04:55
Picon
Favicon

-technology-rights-10.txt - implementors


thomas notes:
> >    n. "IPR" or "Intellectual Property Rights": means patent, copyright,
> >       utility, model, invention registration, database and data rights
> >       that may Cover an Implementing Technology, whether such rights
> >       arise from a registration or renewal thereof, or an application
> >       therefore, in each case anywhere in the world.
> 
> It might be good to more clearly define the term "implementor", as the
> term is used in ipr-template and I'm not sure *exactly* what it
> means. I.e., isn't the disributer of software (who may not be the
> implementor) also subject to IPR issues? ipr-template doesn't could be
> read to say the IPR issues only apply to the implementor.

I assume this comment referes to the template not to the technology ID since
I do not see how it matters in this document- if someone claims IPR 
they mean that an implementation, whatever way they mean by the term, 
is covered by the patent or patent claim - if they do not so assert then
there is nothing to worry about

Scott
Permalink | Reply | 501 comments |
headers
Scott Bradner | 1 Aug 2003 05:07
Picon
Favicon

-technology - definitions


thomas sez:
> I assume these are suppsoed to be _identical_ to those in the          
> draft-ietf-ipr-technology-rights-10.txt? Hmm. they aren't quite. Note:
> Definition m. has more text in one than the other, and n., o., and
> p. are absent in ipr-technology.

n, o & p (included in -technology and not in -subnissions) are not
in submissions because the terms are not used - I saw no reason to
include them

the defs that are in both docs should have been the same - and will be
made so

Scott
Permalink | Reply | 501 comments |
headers
Scott Bradner | 1 Aug 2003 05:16
Picon
Favicon

Re: -technology-rights-10.txt - rfc ed docs & ipr

oops - sorry, the comments I just sent were relative to Thomas's 
notes about -submissions not -technology

Scott
Permalink | Reply | 0 comments |
headers
Scott Bradner | 1 Aug 2003 05:26
Picon
Favicon

-technology (actually thi stime) - ipr disclosure for rfc ed docs


thomas sez:
> Note: We currently have no way of looking at an RFC and knowing
> whether it is the result of an IETF activity or not. But the current
> set of documents makes it clear that IPR disclosures apply to "IETF
> documents". It is less clear they apply to "RFC Editor
> Contributions". I.e., RFC Editor Contributions must first be submitted
> as IDs (at which point IPR must be disclosed), but once the RFC is
> published, there appears to be no such requirement anymore.  Seems
> like this leaves things underspecified.  Two practical points:
> 
> 1) Is someone who gets an RFC published via the RFC Editor
>    Contribution route obligated to update the IETF (or anyone) about
>    IPR once their document is a published RFC? (AFAIK, this is not
>    clearly specified).
> 
> 2) If known IPR is not required to be disclosed for RFCs in category
>    1, but is for IETF-produced RFCs, it seems like we may need a way
>    to identify which RFCs are IETF documents and which are not. How is
>    this intended to be done? (E.g., maybe all future IETF RFCs should
>    have a line along the lines "this document was produced by the IETF
>    Foo Bar WG".)

I agree that this is the case (the reader does not know) and maybe
something should be added to the headers of IETF RFCs to indicate 
that they are IETF-generated not just for IPR disclosure reasons 
(because I would expect that the RFC Editor rules will say that 
such disclosure is required) but to reduce confusion as to what 
is an IETF document and what is someone's pipe dream but that is 
not something we can do in this WG since the charter limits us to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Bradner | 1 Aug 2003 05:31
Picon
Favicon

-technology & implementor


thomas again sez
> In the definitions section, it might be good to define the term
> "implementor" more formally, as the term is used in ipr-template and
> I'm not sure *exactly* what it means. I.e., isn't the disributor of
> software (who may not be the implementor) also subject to some issues
> with regards to technology that has IPR associated with it?

see response for -submissions
I do not think there is a need to define implementor in these
documents because I do not think it makes any difference to
the requirement for someone to disclose

as far as defining the term in the template - the most I would suggest
to to have a place for the person filling out the teplate to
say who the free license covers - I see no reason that we should
restrict or define what the IPR discloser wants to say about 
who can implement their technology for what type of license

Scott
Permalink | Reply | 0 comments |
headers
Scott Bradner | 1 Aug 2003 05:33
Picon
Favicon

-technology - ipr queries


thomas asks
> >    (D)  Where Intellectual Property Rights have been disclosed as
> >       provided in Section 6 of this document, the IETF Executive
> >       Director shall request from the discloser of such IPR, a written
> >       assurance that upon approval by the IESG for publication as RFCs
> >       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 Implementing Technology under one of the
> >       licensing options specified in Section 6.5 below unless such a
> >       statement has already been submitted.  The working group proposing
> >       the use of the technology with respect to which the Intellectual
> >       Property Rights are disclosed may assist the IETF Executive
> >       Director in this effort.
> 
> Note: the above seems to apply only to IETF contributions the way it
> is written. I guess RFC editor contributions are funny. But, if the
> submitter said there was IPR, is the secretariat supposed to do the
> normal IPR query? Or is it explicitely not supposed to?

RFC Editor contributions are not IETF documents (other than for the
IETF publishing the ID) - I see no reason for the IETF Secretariat
to do anything related to IPR in them

Scott
Permalink | Reply | 503 comments |

Gmane