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

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Aug 2003 17:06:25 -0400

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

How about:

   Note that there is no inherent prohibition against a standards
   track IETF Document making a normative reference to proprietary
   technology in some cases. For example, a number of IETF Standards
   support proprietary cryptographic transforms.

Thomas   

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

---

From: Scott W Brim <[email-masked]>
Date: Fri, 1 Aug 2003 17:17:22 -0400

>    support proprietary cryptographic transforms.

The use of "no inherent" ... "in some cases" doesn't feel right.  If
something is inherent then it's a core attribute and not dependent on
case.  I would keep "no inherent" and delete "in some cases".  If you
keep it then you have to explain it.  What you're trying to do is make
the "no inherent" explicit.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Aug 2003 17:37:49 -0400

> the "no inherent" explicit.

I'm fine either way on the "in some cases" wording.

Part of what tripped me up on the original wording had to do with when
a normative reference was appropriate. There are already a number of
considerations in 2026 as to when a normative reference is allowed
from standards track documents (e.g, standards track are not supposed
to normatively refer to info docs, etc.). I think that might be where
the "in some cases" caveat comes from.

Thomas

---

From: Scott Bradner <[email-masked]>
Date: Sat, 2 Aug 2003 00:46:07 -0400 (EDT)

thomas suggests:

this might be OK but what I think is the right concept is that 
a refence to a technology (like encapsulating a proprietary payload
in RTP is not a normative reference in the sense we normally
uise "normative" (e.g., muist bepublished 1st)

Scott

---

From: John C Klensin <[email-masked]>
Date: Sun, 03 Aug 2003 09:27:04 -0400

--On Saturday, August 02, 2003 00:46 -0400 Scott  Bradner
<[email-masked]> wrote:

> thomas suggests:
>    Note that there is no inherent prohibition against a
> standards    track IETF Document making a normative reference
> to proprietary    technology in some cases. For example, a
> number of IETF Standards    support proprietary cryptographic
> transforms.
> 
> a refence to a technology (like encapsulating a proprietary
> payload in RTP is not a normative reference in the sense we
> normally uise "normative" (e.g., muist bepublished 1st)

Scott,

"Must be published first" is a consequence, not a definition and
I hope it stays that way.  The definition of "normative" should
be/remain "material that must be available or known in order to
implement the subject matter of the specification".  We have had
some confusion and abuse of this over the last few years, as
people have tried to identify references as informational
(informative, non-normative) when, by any reasonable definition,
they are normative.

Examples (completely made up):

	(i) "RTP can encapsulate many types of payloads,
	including Foo, Bar, and Baz".  References to foo/bar/baz
	are non-normative.
	
	(ii) SASL is an extensible mechanism for specifying
	applications-level authenticatlon or other security
	mechanisms.  Implementation of the foo method is
	required, other methods including bar and baz and some
	not yet defined, are optional.   The reference to foo is
	normative.  Those to bar, baz, and crystal balls are not.
	
	(iii) The flippit protocol is defined in terms of the
	character lists of the Unicode character set, although
	other character sets may be used to represent the
	characters in databases or on the wire.  Unicode is
	normative.

I suggest that being other than completely clear about this is a
problem waiting to happen.  And that technology-rights may not
be the best place for the definition.

     john

---

From: Scott W Brim <[email-masked]>
Date: Sun, 3 Aug 2003 12:28:38 -0400

On Sun, Aug 03, 2003 09:27:04AM -0400, John C Klensin allegedly wrote:
> Scott,
> 
> "Must be published first" is a consequence, not a definition and I
> hope it stays that way.  The definition of "normative" should
> implement the subject matter of the specification".  

Extension: For non-standards documents it seems to mean material that
must be understood to understand the implications of the document.

> problem waiting to happen.  And that technology-rights may not be the
> best place for the definition.

Absolutely.

---

From: Scott Bradner <[email-masked]>
Date: Sun, 3 Aug 2003 13:08:20 -0400 (EDT)

1/ can you sugegst text to make it clear
2/ if not here, where?

Scott

---

---

From: John C Klensin <[email-masked]>
Date: Sun, 03 Aug 2003 16:33:21 -0400

> 1/ can you sugegst text to make it clear

I'll try to write some words later tonight,  after I get back to
Cambridge, if Thomas doesn't do something first.

> 2/ if not here, where?

I don't know -- these interrelated documents tend to cascade,
which, I assume, is why we started with fewer of them.  Having
to0 look in a half-dozen different places to find some critical
piece of information isn't good either.  But the comment was
caused by my musing about whether things were getting  to the
stage that we needed to supplement RFC 2119 with a "terminology
for use in talking about RFCs and Standards" document.  It might
be worth thinking about as we discuss, in the obvious other WG,
alternate approval and document-naming models.

     john

> ---
> From [email-masked]  Sun Aug  3 09:34:08 2003
> Date: Sun, 03 Aug 2003 09:27:04 -0400
> From: John C Klensin <[email-masked]>
> To: Scott  Bradner <[email-masked]>, [email-masked]
> cc: [email-masked]
> Subject: Re: normative reference text (was: Re: Comments on
>  draft-ietf-ipr-technology-rights-10.txt )
> 
>> this might be OK but what I think is the right concept is
>> that  a refence to a technology (like encapsulating a
>> proprietary payload in RTP is not a normative reference in
>> the sense we normally uise "normative" (e.g., muist
>> bepublished 1st)
> 
> Scott,
> 
> "Must be published first" is a consequence, not a definition
> and I hope it stays that way.  The definition of "normative"
> should be/remain "material that must be available or known in
> order to implement the subject matter of the specification".
> We have had some confusion and abuse of this over the last few
> years, as people have tried to identify references as
> informational (informative, non-normative) when, by any
> reasonable definition, they are normative.
> 
> I suggest that being other than completely clear about this is
> a problem waiting to happen.  And that technology-rights may
> not be the best place for the definition.
> 
>      john
> 
>

---

From: John C Klensin <[email-masked]>
Date: Sun, 03 Aug 2003 16:37:40 -0400

--On Sunday, August 03, 2003 12:28 -0400 Scott W Brim
<[email-masked]> wrote:

> Extension: For non-standards documents it seems to mean
> material that must be understood to understand the
> implications of the document.

Yes.  But the RFC Editor has raised (but I don't think answered)
whether the normative/ non-normative distinction is meaningful
(or useful) in context for non-standards-track documents.  That
presumably doesn't mean the distinction can't be made (I think
you have just defined it), but that it may not be worth the
trouble, since info and experimental documents are not generally
held up until all normative references are published as RFCs or
something presumed to be equally permanent.

>> I suggest that being other than completely clear about this
>> is a problem waiting to happen.  And that technology-rights
>> may not be the best place for the definition.
> 
> Absolutely.

I should ask you the same question Scott asked me -- whether do
you think these things should be defined?     Is defining them
something that should be within the scope of this WG and its
documents, or do we need to do "something else" soon?

      john

---

From: Scott W Brim <[email-masked]>
Date: Mon, 4 Aug 2003 08:05:27 -0400

> documents, or do we need to do "something else" soon?

Well, clearly not in this group.  This group is supposed to be about
IPR, while the question is about organization and administration of
knowledge.  2223?  Mumble.  But not here.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 4 Aug 2003 10:39:42 -0700 (PDT)

> On Sun, Aug 03, 2003 04:37:40PM -0400, John C Klensin allegedly wrote:
...
> knowledge.  2223?  Mumble.  But not here.

To be exact, Section 2.7 of draft-rfc-editor-rfc2223bis (currently
http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-06.txt).

The definition that's currently there is:

 Normative references specify documents that must be read to
 understand or implement the technology in the new RFC, or
 whose technology must be present for the technology in the new
 RFC to work.

For documents that don't discuss a technology I've interpreted the
phrase "the technology in the new RFC" as meaning "the subject
matter of the new RFC" -- do we perhaps want to ask that the
language in the 2223bis document make this explicit?

Mike

---

From: Thomas Narten <[email-masked]>
Date: Fri, 08 Aug 2003 14:10:02 -0400

> 1/ can you sugegst text to make it clear

Seems to me like the issue is we haven't had a good, "official"
definition of normative. Mike tracked down the one from the
rfc-editor, which is also the one I point people to now. But 2223bis
has actually not been around all that long, and the definition is not
in RFC 2223.

> 2/ if not here, where?

I concur that neither this (nor any of the IPR) documents is really
the place to clarify what normative means. I think it's fine though to
point out that standard track docs can have normative refs to
proprietary stuff, as that is a topic clearly of relevance to these
specs.

Defining/clarifying normative in the IPR docs will make it hard to
find them, I suspect, especially since the topic is discussed in 2026
already. It is that text that needs clarifying.

It's also worth noting that on the topic of normative references, we
have running code suggesting that some clarifications are
needed. I.e., in the IESG, we've noted (kind of after the fact) that
we regularly allow the citation of some informational docs normatively
in some cases (e.g., RFC 1321). In the security space, this has
happened a lot, where we republish stuff as informational RFCs (rather
than on standards track), and then cite them normatively. 

So, if we open up the topic of normative references, this may be a bit
bigger than we first think. I'm inclined to suggest we (or someone) do
a separate document on just this topic. Indeed, I've seen a private
draft along these lines (to deal with the above issue) that might
serve as a starting point.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 08 Aug 2003 14:11:50 -0400

John C Klensin <[email-masked]> writes:

> (or useful) in context for non-standards-track documents.

My recollection is that this was discussed a couple of years back
within the IESG/RFC Editor (and maybe the IAB?) when they put in place
their policy to require splitting of references. Even then, there was
a feeling (at least amoung some) that the split was useful for all
documents, but in the end the decision was made to only require it in
standards track documents. My recollection too was that for quite some
time, the official policy on their web page said as much (and was in
conflict with 2223bis as it was being updated). Checking now,
http://www.rfc-editor.org/policy.html#policy.refs now just points to
the 2223bis ID.

It says:

      An RFC must include separate lists of normative and informative
      references (see Section 4.7f below.)

Thomas

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Aug 2003 14:23:06 -0400

The discussion about not requiring the split for experimental 
and informational documents, or some of them, occurred after the 
last go-round in the document to which you refer.  As I said, I 
don't believe that any final decision has been made.

At worst, requiring the split for those documents is a harmless 
irritation to the editor and user.   There is certainly no major 
harm in doing it.  And I assume that is why the RFC Editor has 
not given this issue high priority, although someone who cares 
should ask them.

      john

--On Friday, 08 August, 2003 14:11 -0400 Thomas Narten 
<[email-masked]> wrote:

>> Yes.  But the RFC Editor has raised (but I don't think
>> answered) whether the normative/ non-normative distinction is
>> meaningful (or useful) in context for non-standards-track
>> documents.
>
> My recollection is that this was discussed a couple of years
> back within the IESG/RFC Editor (and maybe the IAB?) when they
> put in place their policy to require splitting of references.
> Even then, there was a feeling (at least amoung some) that the
> split was useful for all documents, but in the end the
> decision was made to only require it in standards track
> documents. My recollection too was that for quite some time,
> the official policy on their web page said as much (and was in
> http://www.rfc-editor.org/policy.html#policy.refs now just
> points to the 2223bis ID.
>
> It says:
>
>       An RFC must include separate lists of normative and
> informative       references (see Section 4.7f below.)
>
> Thomas

---

From: Scott Bradner <[email-masked]>
Date: Fri, 8 Aug 2003 15:14:59 -0400 (EDT)

> a separate document on just this topic.

that makes sense to me

Scott