Subject: -technology - change control

From: Scott Bradner <[email-masked]>
Date: Fri, 1 Aug 2003 00:42:55 -0400 (EDT)

> > 9.  Change control for technologies
> >
> >    The IETF must have change control over the technology described in
> >    any standards track IETF Documents in order to fix problems that may
> >    be discovered or to produce other derivative works.  Contributions to
> 
> Change control of the technologies, or over the documentation of such
> technologies? I assume the latter. If so, the wording might be made
> more precise

no - it means change control over the technology itself (see the
references in the text about RPC & NFS)

> Also, here again we have "standards track documents" rather than just
> all IETF documents (I assume the latter is meant).

no - we need change control over the technology if we are to further
develop it on the standards track - we have not required change control
when publishing info rfcs about a technology

if the text is not clear please suggest new text

Scott

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

---

From: Thomas Narten <[email-masked]>
Date: Mon, 11 Aug 2003 12:22:22 -0400

> references in the text about RPC & NFS)

OK.

> when publishing info rfcs about a technology

I understand this point with regards to RFC Editor Contributions. But
not for IETF Contributions, i.e., where the WG is actively involved in
the content.

Its not clear to me that the IETF should be working on technology that
it doesn't have change control over. I.e., not just standards track,
but also info/experimental. Or at least, I don't understand the
motivation for treating info/experimental differently. For example,
it's not always clear up front whether something will be info
vs. standards track, and things can change over time (like moving from
experimental to standards track).

Would extending coverage to all IETF Contributions change anything in
practice? I.e., what are some examples of IETF documents we've worked
on in the past that weren't Standards Track, and for which we didn't
have change control.

Bottom line is that I'd like to understand why the change control
should only be required for standards track, and not for
info/experimental (that are IETF Contributions).

Thomas

---

From: Scott Bradner <[email-masked]>
Date: Mon, 11 Aug 2003 12:37:13 -0400 (EDT)

> info/experimental (that are IETF Contributions).

bottom line - its the running code

we have only said that we need change control over the technology in 
stds track docs - we have said that since at least 1992 when I had
a discussion on the topic with Vint at the San Diego IETF meeting

I think it would be a Good thing to extend the requirement to all 
IETF Documents but that would be beyond the scope of this working 
group to do (since it would be a change to the running code).

Scott

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Aug 2003 12:56:00 -0400

--On Monday, 11 August, 2003 12:37 -0400 Scott Bradner 
<[email-masked]> wrote:

> we have only said that we need change control over the
> technology in  stds track docs - we have said that since at
> least 1992 when I had a discussion on the topic with Vint at
> the San Diego IETF meeting
>
> I think it would be a Good thing to extend the requirement to
> all  IETF Documents but that would be beyond the scope of this
> working  group to do (since it would be a change to the
> running code).

Scott,

There is one small piece of this that could be changed/fixed 
more or less now, since it would not require any significant 
procedural change.  At present, every RFC contains a header of 
"Network Working Group", which is historically important and 
more or less a synonym for "IETF".  There seem to be a growing 
number of cases (IPR generates several examples, but not all of 
them) in which it would be useful to clearly identify IETF 
materials as separate from individual submissions to the RFC 
Editor.  If nothing else, if we are going to have different 
rules -- which, as you know, I consider the right thing to do-- 
then the reader ought to be given some hint as to which rules 
apply.

If the IAB and RFC Editor were persuaded by this, perhaps it 
would be useful to continue to label IETF materials -- i.e., any 
standards-track document, but also any document originating in 
an IETF WG or that the IESG, with author permission, decides to 
process as an IETF document-- with "network working group" but 
to come up with some other label for individual submissions 
going forward.  It would, IMO, help a lot even without expansion 
of the disclosure rules as Thomas suggests.  And, if those rules 
were expanded in the future, it would be very helpful in letting 
the user figure out which rules had been applied.

      john

---

From: Scott Bradner <[email-masked]>
Date: Mon, 11 Aug 2003 13:19:02 -0400 (EDT)

I think this would be a Good Thing to do - (I think the place to
mention it is in 2223bis though)

Scott

---------------------------------------
Date: Mon, 11 Aug 2003 12:56:00 -0400
From: John C Klensin <[email-masked]>
To: Scott Bradner <[email-masked]>
cc: "[email-masked]" <[email-masked]>
Subject: Re: -technology - change control

Scott,

      john

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Aug 2003 13:35:49 -0400

--On Monday, 11 August, 2003 13:19 -0400 Scott Bradner 
<[email-masked]> wrote:

> I think this would be a Good Thing to do - (I think the place
> to mention it is in 2223bis though)

That is clearly where the change would need to be made, since 
this is really an editorial issue only.

   john

---

From: Thomas Narten <[email-masked]>
Date: Thu, 14 Aug 2003 17:07:31 -0400

> (since it would be a change to the running code).

How? What technology has the IETF worked on that was not standards
track, that would have had to be treated differently if the requirement
for having change control also extended to non-standards track docs?

Also, from the document:

>    be discovered or to produce other derivative works.

Seems like we'd need that for anything a WG works on...

>  Contributions to
>    the IETF in which the Contributors do not grant change control to the
>    IETF must include the Internet-Draft statement which does not include
>    the right to make derivative works from [IETF SUB] Section 4.2.

Such a document would also seem to be a problematical one for a WG to
take on. Indeed, we've said in other contexts that no WG document can
have such a clause.

Having said that, I'm of two minds. If, in fact, we have no examples
of IETF info/experimental documents for which change control would
have been necessary, this is a non-problem in practice. On the other
hand, IMO, 2026's use of "standards track" in places rather than "IETF
Document" has led to a fair amount of unfortunate confusion in the
past. I personally have always felt that the rules for IETF WG
documents, regardless of std/info/experimental, should all be the same
with regards to IPR and other issues since the issues largely impact
what a WG can/will do with a document, regardless of its status.

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Fri, 15 Aug 2003 09:43:51 +0300 (EEST)

Another perspective,

I'm confused by this dialogue.  Doesn't anything a WG adopts must 
relinquish change control to the IETF and the WG?  Isn't this already 
running code and current practice, as well as somewhat referred to in 
10.3.1 ("All contributions") in RFC2026?

Now, if we required change control over *all* Experimental/Informational 
documents .. that would be a change (I would like it regardless), but 
outside of the scope of this document.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Scott Bradner <[email-masked]>
Date: Fri, 15 Aug 2003 06:42:33 -0400 (EDT)

> Doesn't anything a WG adopts must
> relinquish change control to the IETF and the WG?

no

if someone "owns" the technology (for example NFS or ISIS) then nothing
the IETF can do on its own can change that fact

Scott

---

From: Pekka Savola <[email-masked]>
Date: Fri, 15 Aug 2003 15:50:48 +0300 (EEST)

> the IETF can do on its own can change that fact

So if the author of draft-ietf-isis-foo is hit by the truck, IETF must
throw the document away, not (for example) find a different editor?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 15 Aug 2003 08:21:17 -0500

Dear Scott,

I'm confused. No news there.

To ask the question I think Pekka was
asking, I thought if we adopted an I-D
as a WG document for standards-track,
the current running code was that we
required change control (not from
2026, but from http://www.ietf.org/ietf/1id-guidelines.txt):

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

and

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

Were you being precise (WG documents that aren't standards-
track, or something)? But I thought the running code was
standards-track = first statement.

Help?

Spencer

---

From: Scott Bradner <[email-masked]>
Date: Fri, 15 Aug 2003 09:32:50 -0400 (EDT)

you are confusing text with technology

take for example the references in the -technology doc

Sun defined ONC RPC, XDR & NFS

they also published various RFCs describing these technologies
	RFC 1014, 1057 & 1094

but until Sun handed over change control for ONC RPC & XDR in rfc 1790
the IETF could not create a RFC that *changed* the specification 
of ONC RPC or XDR since they were still Sun technologies - Sun could have
had a quite legit legal complaint if we tried to do that

originally Sun was going to include NFS in the original hand over of change
control but did not actually do so until RFC 2339

after Sun handed over change control the IETF could, and did, create
working groups to revise and produce new versions of these technologies -
e.g., NFSv4 is now what the IETF says it is not what Sun says it is 

Scott

-----

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 15 Aug 2003 08:21:17 -0500

Dear Scott,

and

Help?

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 15 Aug 2003 08:54:38 -0500

Dear Scott,

OK, this is helping (thanks) - what I think I'm
asking (what I thought Pekka was asking) was,
the ONC specifications would not have been
standards-track until Sun handed over change
control, as best I can tell from the ID guidelines.

Is that true?

Spencer

----- Original Message ----- 
From: "Scott Bradner" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 15, 2003 8:32 AM
Subject: Re: -technology - change control

> From [email-masked]  Fri Aug 15 09:22:07 2003
> Reply-To: "Spencer Dawkins" <[email-masked]>
> From: "Spencer Dawkins" <[email-masked]>
> To: <[email-masked]>
> References: <[email-masked]>
> Date: Fri, 15 Aug 2003 08:21:17 -0500
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 6.00.2800.1158
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> Content-Transfer-Encoding: 7bit
> Sender: [email-masked]
> Errors-To: [email-masked]
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.0.12
> Precedence: bulk
> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipr-wg>,
> <mailto:[email-masked]?subject=unsubscribe>
> List-Id: IPR-WG <ipr-wg.ietf.org>
> List-Post: <mailto:[email-masked]>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipr-wg>,
> <mailto:[email-masked]?subject=subscribe>
>
> Dear Scott,
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Aug 2003 12:17:52 -0400

> the IETF can do on its own can change that fact

ISIS is the example I needed to be reminded of. The ISIS WG has
produced info documents where the IETF didn't really have change
control over the ISIS technology. This was useful in practice (as the
work needed to be done, and wasn't).

So, I withdraw my issue on this point and am fine with the text in the
document.

Thomas