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

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

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

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

---

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

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

> 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 be/remain "material that must be available or known in
>> order to 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.

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