[eppext] Alissa Cooper's No Objection on draft-ietf-eppext-tmch-smd-04: (with COMMENT)

"Alissa Cooper" <alissa@cooperw.in> Wed, 17 February 2016 21:46 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: eppext@ietf.org
Delivered-To: eppext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7071A8BC3; Wed, 17 Feb 2016 13:46:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160217214608.20749.74849.idtracker@ietfa.amsl.com>
Date: Wed, 17 Feb 2016 13:46:08 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/YG0lwIjiVxHpEz_42aPeGEGJHN8>
Cc: draft-ietf-eppext-tmch-smd@ietf.org, eppext-chairs@ietf.org, eppext@ietf.org, nkong@cnnic.cn
Subject: [eppext] Alissa Cooper's No Objection on draft-ietf-eppext-tmch-smd-04: (with COMMENT)
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Feb 2016 21:46:08 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-eppext-tmch-smd-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


In general I agree with Ben's comments about <mark:treatyOrStatute> and
<mark:court>. I don't understand why these elements contain a smattering
of the same child elements of <mark:trademark> (holder, contact, etc.),
rather than just containing a <mark:trademark> as a child element in its
entirety, and then adding in the additional treaty- or court-specific
elements that are necessary. The way its specified in the document makes
it hard to understand whether the child elements of
<mark:treatyOrStatute> and <mark:court> refer to the treaty/court ruling
at issue, or to the trademark.