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

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 17 Feb 2016 13:46:08 -0800

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:
https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Gustavo Lozano <[email-masked]>
Date: Sat, 20 Feb 2016 00:36:44 +0000

Thank you Alissa,

Comments inline.

Regards,
Gustavo

>https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/

I am not a lawyer, but during the design of the spec, trademark experts
participated. Trademark is a type of the three types of marks described in
the document. There are some elements that are shared between the three
types of marks, and the first internal spec contemplated another object to
capture the shared elements, but considering that an SMD may contain
several marks, it started to get too complex. We decided that the current
design was easier to implement / understand.