Re: Rights in early RFCs

["Joel M. Halpern" <[e-mail]>]

I think there are two separate issues.

First, the way they structured their profile, they were making verbatim 
quotes, and then putting there own text around taht.  As far as I can 
tell, in terms of our copyright rules, we have said they have the right 
to do that.  I believe the trust will have to tell them that they have 
those rights.

The fact that the profile they are building around those quotes does not 
match our intentions is a different problem.  It is not, as far as I can 
tell, a problem the trust can deal with.  The trust can call IESG 
attention to the activity, in hopes that via discussion the right things 
happen.  But as long as what they quote is verbatim, and they include 
our boilerplate where required, we do not have the right to decide 
whether we like or dislike the usage.

Put differently, what I have seen looks a lot like the case John 
describes below as a perfectly valid usage that we can't stop.  But the 
IESG can certainly talk to them about the interoperability issues.

Yours,
Joel

On 6/15/19 4:52 PM, John C Klensin wrote:
> 
> 
> --On Saturday, June 15, 2019 16:32 -0400 Keith Moore
> <[e-mail]> wrote:
> 
>> On 6/15/19 6:48 AM, Kathleen Moriarty wrote:
>>
>>> I'll add to Paul's description.  Within the request, for one
>>> document,  they wish to make a profile.  Normally, that's
>>> fine.  Except that they  want to change keywords in
>>> directions that they should not be changed  in a profile.
>>> For instance changing a MUST to a SHOULD or even a MUST
>>> NOT.  This obviously results in the profile not being in
>>> compliance  with the referenced document and therefore not
>>> interoperable.
>>
>> Why would this community want to grant permission to do that,
>> even if it were in our power to do so?
> 
> Keith (and others),
> 
> I've supplied a good deal of historical information to John
> Levine off-list, but your question goes to what I think is the
> key issue.  Unless we, for some reason I can't imagine, want to
> encourage the creation of confusion about what our standards do
> or do not say or require, we shouldn't grant this permission or
> spend energy exploring ways to figure out what can or cannot
> reasonably be granted and/or what is in the IETF Trust's power
> to grant.   Instead, we should encourage whomever this is to
> incorporate our standard (or selected parts of it) by reference
> (something we could not prevent if we wanted to) and then to
> identify what they want to make different.
> 
> 	"Our protocol is just like the IETF's User Datagram
> 	Protocol [RFC768] except that where the FizzleFraz case
> 	is mentioned the implementer MUST NOT do Garglezork even
> 	if the IETF requires doing so."
> 
> Is a perfectly good style of statement.  We couldn't prevent it
> if we wanted to (although some effort to explain to them why it
> would be a bad idea might be in order depending on what they are
> actually trying to do and why).  And it creates absolutely no
> confusion about what the IETF Protocol is.
> 
> It seems to me that trying to give them permission to make
> partial copies in support of developing a forked or conflicting
> standard is not in the interest of either the IETF community or
> the RFC Series and that, if the IETF Trust is exploring doing
> so, they are in danger of losing their way about their
> obligations to the community.
> 
> best,
>     john
> 
> 
> 
>