On 6/15/19 4:52 PM, John C Klensin wrote:
--On Saturday, June 15, 2019 16:32 -0400 Keith Moore
<moore@xxxxxxxxxxxxxxxxxxxx> 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.
I'm sort of thinking that the response should be: The mission of IETF
and affiliated organizations is to promote the Internet and
interoperability of applications using the Internet. If you want to
promote specifications that break interoperability with our protocols,
you're on your own. Do your own research, hire your own lawyers to
advise you, seek out whatever permissions from the original authors or
their estates that you can get. We're not going to help you, and we're
not going to promise to not sue you if we find grounds to do so.
(more diplomatically than that, I suppose, but I find it easier to get
the clear statement first then to recast it in diplomatic language if
it's worth doing so)
And I get the idea of minimizing confusion between what IETF says and
what some other organization says, but it might still be bad precedent
to encourage that practice.
Say, for instance, some organization decided to promote a version of TLS
that was exactly like IETF TLS except that it leaked keying material via
a side channel. We should do everything in our power to discourage
that, and punish those promoting such practices, via any legal means
available to us.
Keith
