Subject: Why not change the text?

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Jul 2006 23:49:31 -0400

I believe Larry asked that those of us opposed to allowing changes to 
the non-code text state why we oppose it.
While the answers have been stated by multiple people multiple times 
on the list, I will try to state my view again.

The IETF works very hard to pick words that describe our standards, 
both in the normative and non-normative portions of the 
specification.  It is often hard to get agreement on the words.  It 
is very often the case that small changes in the wording can have 
large changes in the meaning, which are not obvious until you look at 
the words from many different perspectives.

Hence, allowing changes to the words encourages people to make 
innocent, non-interoperable changes to the standard.  My concern is 
not the people who want to pretent their work is the standard when it 
isn't.  Rather, it is the person who puts in the comment, 
paraphrasing the RFC, and changes a the meaning slightly.  Later 
maintainers are likely to make mistakes.  Other folks using his work 
as inspiration are likely to make mistakes.
Now, I will admit that this can happen when the words are the 
implementors own.  The difference is that in that case everyone knows 
the words are the implementors, and that they need to look at the RFC 
themselves.

And, at the same time, the marginal benefit to the implementor of 
using our words is small.  If he can use them and make sure they stay 
faithful to the standard, there may be an actual advantage to using 
them.  And we allow that. But otherwise, the return is small.  And 
while there may be a few cases where folks have used RFCs as 
documentation or man pages, providing such text is not the job of the IETF.

Yours,
Joel M. Halpern

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Jul 2006 10:23:32 +0200

"Joel M. Halpern" <[email-masked]> writes:

> both in the normative and non-normative portions of the specification.
> It is often hard to get agreement on the words.  It is very often the
> case that small changes in the wording can have large changes in the
> meaning, which are not obvious until you look at the words from many
> different perspectives.
>
> isn't.

Oh.  That would be the "fake RFC" concern.  I'm glad that we've moved
beyond it, I don't think it is a valid concern.

> Rather, it is the person who puts in the comment, paraphrasing
> the RFC, and changes a the meaning slightly.  Later maintainers are
> likely to make mistakes.  Other folks using his work as inspiration
> are likely to make mistakes.

I don't believe this will happen generally.

I also believe that IF it would happens, and the modified version is
picked up by others, it will be for a good reason: the original
specification was flawed, and people corrected it and other people
built on the improved version.  This is how specifications has always
evolved.

The fear appear to be that someone picks up a specification, modifies
it and makes it less useful or correct.  When that happens, I don't
think others will be happy to promote that approach, since, well, it
is worse.  Others may implement it for compatibility, but we already
have this situation when Microsoft or someone extends Kerberos or some
other protocol without telling anyone how it is done.  This situation
is a nuisance, but a temporary one.

> the words are the implementors, and that they need to look at the RFC

This is incorrect, and there is no such difference: It is OK to put in
an IETF license that you cannot modify text from RFCs without also
adding a note that the text has been modified, and a link to the
"real" RFC.  My proposed license did exactly that, see:

http://josefsson.org/bcp78broken/draft-josefsson-ipr-rules-update.html#anchor5

> using our words is small.

I believe being able to re-use text from RFCs has helped getting
specifications implemented and deployed faster.  Thus, it would
further the goals of the IETF to promote this behaviour.

> If he can use them and make sure they stay faithful to the standard,
> there may be an actual advantage to using them.  And we allow
> that. But otherwise, the return is small.

The problem here is a technicality: People cannot use it in free
software products, even if they intend to stay faithful to the
standard.  The license must permit modifications, even if they don't
happen.

> And while there may be a few cases where folks have used RFCs as

I believe you are underestimating how widely used RFC text quotes are,
and how helpful they have been in getting IETF specifications
implemented and deployed.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Jul 2006 04:21:03 +0200

There's a related aspect to this. I've recently published
draft-carpenter-protocol-extensions, and I believe that we
may want some levers to dissuade extensions that the IETF
considers unfortunate. Copyright might be one of them
(not the best, however).

     Brian