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

[Harald Tveit Alvestrand <harald@alvestrand.no>]

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