Re: I-D Action: draft-leiba-cotton-iana-5226bis-19.txt

Bob Hinden <bob.hinden@gmail.com> Tue, 10 January 2017 22:57 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5DC129611; Tue, 10 Jan 2017 14:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6SgYLgiquJV; Tue, 10 Jan 2017 14:57:53 -0800 (PST)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A864129638; Tue, 10 Jan 2017 14:57:53 -0800 (PST)
Received: by mail-it0-x22a.google.com with SMTP id c7so51978305itd.1; Tue, 10 Jan 2017 14:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=a06SMaRR1YE5ULUsPE23tNUozbqK2tmRl/9YmbvEwBc=; b=S6/EYqp7ZRntgo4Lmvhm9ml7isG75grIN/zN/tIICpgRD8IblMv85KtwM0bZXXKbL7 3HYSZBJJuXMdAjx6CtbNF6b6ZJUhEjLmlrJJqfjmfqMVMKX15e7IXQ5/z5/ocwzX2H96 RkPZwUTlV8paN6AE2hDJgf7RQBtdqE8VJty3Nw+KMs3sskeiFORV2ukbNLmfDjGvQG1M H0mJFIcI65dnJA5NnaxUyX6zIMi/b5TaU5yKGyqKnyBNRP2DgJ/BW7Ty7tnA1Eyss6QD bU5jNtm47p0Z8U+8V9u92WaJIhWuc2/+ZvE/MxvAYh1z+fHSQj1l3zRXtEbpybeACWOl apuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=a06SMaRR1YE5ULUsPE23tNUozbqK2tmRl/9YmbvEwBc=; b=mBRFTCslhiN/x4IM9DxhcZDNlWmQMdTeQ+I0PXSIZEi/MVrR7UTAPx0/fWtDXZeBmK 5LwYA9EwZv0vfL2lK8K0eQUEZv1nmUrTzokw71cAm0sbT712RtN7ltv6t4y7K5V+jVlS do0zjRaYgiYCjH03r/okGAnC9+Fy2/kK+68RpZwSDLuthOsOw7npmCLIZLE3YjBh+jsV LvhL/xZjSwdQ0SIhT485QV6AVZSyA/g2RDCX3Eok6jNOmNpozGr8swabQjiylRbq+mZ8 H1aScQfDV4g+vv67WjLiH2g3iBXlq99Dgc5NBquIlRcMHqe0rkphFOr0DBp2hrI22g3d CDoA==
X-Gm-Message-State: AIkVDXKuw93e+4lWbxoKu4e+wccCE1SPtMaW5hTbG2eEPZ437f48m+lFOS5gY+cgWSG/pg==
X-Received: by 10.36.111.208 with SMTP id x199mr5772381itb.52.1484089072841; Tue, 10 Jan 2017 14:57:52 -0800 (PST)
Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id j201sm8953809ita.20.2017.01.10.14.57.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 Jan 2017 14:57:52 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_64335F00-04ED-40D0-8469-AEDF63AF1D64"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: I-D Action: draft-leiba-cotton-iana-5226bis-19.txt
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <20170110210547.GM1426@anvilwalrusden.com>
Date: Tue, 10 Jan 2017 14:57:49 -0800
Message-Id: <E47EDE97-9CEB-421A-BC01-28C2BA3DDC68@gmail.com>
References: <148406571988.22226.2636377293389742409.idtracker@ietfa.amsl.com> <b82941e6-c551-f5c3-0ebd-cc0e9a95dfdb@gmail.com> <20170110201914.GK1426@mx2.yitter.info> <EC0B9473-785F-4F6B-8505-A67F7BE1E35B@gmail.com> <20170110210547.GM1426@anvilwalrusden.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/036qij68rHPLC_MD-6p0k-Wgl10>
Cc: IETF Trustees <trustees@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2017 22:57:55 -0000

Andrew,

> On Jan 10, 2017, at 1:05 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> 
> Uh, _this_ time I'm copying trustees.
> 
> On Tue, Jan 10, 2017 at 12:47:10PM -0800, Bob Hinden wrote:
>> 
>> http://www.iana.org
>> 
>> It says:
>> 
>> "The global coordination of the DNS Root, IP addressing, and other Internet protocol resources is performed as the Internet Assigned Numbers Authority (IANA) functions.”
>> 
> 
> Their web page _doesn't_ abbreviate it as "IANA".  It says "the IANA
> functions", and it also says, "As of 1 October 2016, the IANA
> functions are being provided …". It talks about "IANA functions", not "IANA”.

That not the way I read "Internet Assigned Numbers Authority (IANA) functions”.  I see “IANA” quite clearly.  [Nit: it’s also not compliant with license agreement, since “functions” is not in upper case].

> 
> I believe that the IETF Trust's legal counsel agrees about this, but I
> am copying the Trust to confirm.  In any case, see restriction 5 under
> exhibit D of
> http://trustee.ietf.org/documents/License_Agreement09-21-2016Protocolclean.htm.
> Since the new document did not exist as of the Effective Date, we
> should follow those rules.

Thanks for the link, I assume we are discussing Exhibit D “IETF Trust Style Requirements” sentence 5.

    The mark shall not be used to describe products or services in a generic or
    descriptive manner.  For example, services should always be referred to as
    “IANA Services” or “IANA Functions”, not as “IANA”.  This requirement shall
    not apply, however, to archived or legacy web pages or documents existing as
    of the Effective Date.

Based on this shouldn't the title of the document be:

     Guidelines for Writing an IANA Functions Considerations Section in RFCs
or
     Guidelines for Writing an IANA Services Considerations Section in RFCs

and all future RFC should have an

     IANA Functions Considerations Section in RFCs
or
     IANA Services Considerations Section in RFCs

By my reading, this version the document is inconsistent.  If we are not required to change the name of the Considerations section to “IANA Functions…”, then we should not have to change it everyone else.

> 
> Finally,
> 
>> If their web page can abbreviate this as “IANA”, then I think we can as well.
> 
> the problem with trademarks is that normally-sensible things that one
> can do with language are just now allowed.  So one's sense of these
> things is no guide, only one's lawyer's sense.

While I am certainly not a trademark lawyer, I would think that if the last sentence in the first paragraph of Introduction in the draft is changed to:

    For IETF protocols, that role is filled by the Internet Assigned Numbers
    Authority (IANA) Services [RFC2860] described in this document as IANA.

I would think this is not a trademark violation, since it is clear what IANA is referring to.

Thanks,
Bob



> 
> Best regards,
> 
> A
> 
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
>