Re: The note (v2) to Tony Li about draft-ietf-isis-traffic

[Alex Zinin <zinin@psg.com>]

Harald,

  Looks fine to me. One thing is the two paragraphs about
  the agreement with JTC1 seem to not contribute much.

-- 
Alex

Wednesday, January 29, 2003, 2:36:34 AM, Harald Tveit Alvestrand wrote:
> Second draft...comments?

> From: Harald Tveit Alvestrand, IETF chair
> To: Tony Li
> Cc: Alex, Bill
> Subject: draft-ietf-isis-traffic-04 and copyright

> Tony,

> the IESG has discussed the issue of the ISIS working group, the
> draft-ietf-isis-traffic-04 document, and the copyright.

> You know the words from the guidelines to internet-draft authors:

>>Mandatory Statements
>>====================
>>
>>All Internet-Drafts must begin with ONE of the following three
>>statements:
>>
>>         This document is an Internet-Draft and is subject to
>>         all provisions of Section 10 of RFC2026.
>>
>>         This document is an Internet-Draft and is subject to
>>         all provisions of Section 10 of RFC2026 except that the
>>         right to produce derivative works is not granted.
>>
>>         This document is an Internet-Draft and is NOT offered in
>>         accordance with Section 10 of RFC2026, and the author does not
>>         provide the IETF with any rights other than to publish as an
>>         Internet-Draft
>>
>>
>>Any submission which does not include one (and only one) of the above
>>three statements will be returned to the submitter. The IETF
>>Secretariat will NOT add this text.
>>
>>The first statement is required for all documents that might be
>>submitted for Standards Track publication. The primary motivation is
>>the the IETF retains change control, thus permitting augmenting the
>>original document to clarify or enhance the protocol defined by the
>>document.

> You also know the history that led up to this piece of formalism -
> Bill Simpson's insistence that he knew better than the IPSEC working
> group what should go into Photuris, and his use of his copyright as
> author in the Photuris documents to enforce the point - eventually
> leading to the IPSec working group abandoning all work on Photuris.

> You have chosen to publish the draft in question with the second
> version of the clause.

>>From what Bill and Alex tell me, your position in the ISIS working group is 
> that you trust your personal judgment more than you do the jugment of the 
> IETF "some time in the future", and that you personally want the ability to 
> block changes to the protocol.
> Apparently, the WG and the IESG agree with the protocol specified in the 
> current version of the document, so this is not an immediate concern, but a 
> future one.

> The document is a specification of extensions to the IS-IS protocol,
> which is formally the realm of ISO/IEC JTC1.
> If it had been solely an IETF protocol extension, it would clearly
> have been a candidate for standards-track processing.

> Alex Zinin and the IESG have been
> working on draft-zinin-ietf-jtc1-aggr, which tries to make explicit
> the relationship between JTC1 and IETF work in this area. But this
> document isn't signed yet, so I'll leave that out of the discussion
> for the time being.

> I'm assuming that you don't care about ownership of the exact words -
> what you care about is changes to the technology.

> In order to block technology changes, I think you have to:

> - Block someone introducing amendments in the ISIS WG
> - Block someone introducing amendments in SC6

> I think this is possible. But I think it will be easier if you work
> within the process to build consensus that this technology should not
> change, or should only change within sharply limited bounds.

> I do not think the lever of refusing to grant the right to produce derived 
> works from the words of your document is a very powerful one - if someone 
> wanted to introduce modifications, that person could do so using his/her 
> own words. Although it would probably be simpler to make changes by 
> revising your document, it's not the only possibility.

> My main worry with this document is not this particular document, but
> the impact its publication will have as a precedent setter.

> If the IESG were to grant your request to have this document published
> with a no-derivative-rights clause, we have established a precedent.
> Next time someone wants an IETF technology to remain under their
> personal control, this precedent will be cited.

> And if we find errors in such published documents, or the ownership of
> the right to produce derivative works grows unclear (through corporate
> mergers, bankruptcies or other maneuvers; personal illness, death or
> extended vacations; other causes one cannot imagine now), we can
> easily find ourselves in a situation neither of us want the IETF to be
> in: Where we have protocol standards with known, important errors that
> we are unable to fix.

> What do you think?

>                   Harald Alvestrand