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

"Ben Campbell" <ben@nostrum.com> Tue, 16 February 2016 22:21 UTC

Return-Path: <ben@nostrum.com>
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 50F401A871C; Tue, 16 Feb 2016 14:21:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160216222102.24096.14754.idtracker@ietfa.amsl.com>
Date: Tue, 16 Feb 2016 14:21:02 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/oVp3j8W_tB5lrc6Bb-I3F5qIaWM>
X-Mailman-Approved-At: Wed, 17 Feb 2016 08:21:56 -0800
Cc: draft-ietf-eppext-tmch-smd@ietf.org, eppext-chairs@ietf.org, eppext@ietf.org, nkong@cnnic.cn
Subject: [eppext] Ben Campbell'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: Tue, 16 Feb 2016 22:21:02 -0000

Ben Campbell 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:
----------------------------------------------------------------------

*** Substantive Comments ***

- General: I share Stephen's and Russ's concern about the lack of
signature policies either here or in [ICANN-TMCH]. In particular, what
does it mean for a mark to be signed?

- 2.1: What is the semantic difference between <mark:name> and
<mark:org>? If the latter represents an organization, should we assume
the former does not? Or more specifically, does <mark:name> represent a
person? Along the same lines,  <mark:addr> is described in terms of an
organization address. What is only <mark:name> is present?

- 2.2: <mark:id> must be globally unique in relation to the repository? I
_think_ this means that it must uniquely define a mark in relation to a
repository. But that can also be interpreted to mean that no two mark
elements can contain the same ID/repository combination. (This language
occurs several times)

-- <mark:treatyOrStatute>: Can you clarify the meaning of "country of the
ruling"? (as opposed to the country of protection)

- 2.3: 
-- <smd:signedMark> is described as the fragment of xml that is signed.
But the text suggests the <signature> element is a child of
<smd:signedMark>. Is the signature itself expected to be signed? If only
part of <smd:signedMark> is signed, which parts?

-- Do <smd:notBefore> and <smd:notAfter> refer to the validity of the
signature, or the mark itself?

-- Why is XML canonicalization a SHOULD rather than a MUST? Why might one
choose not to use it? What can go wrong if you don't use it? (If the
answer is that the signature validation might fail, them maybe this
should be a MUST?)

-- Does the reasoning for RSA-SHA256 being a SHOULD rather than a MUST
imply that there are algorithms that MUST NOT be used?

*** Editorial Comments ***

- Abstract:
It would be helpful to see a sentence describing what sort of "marks"
this draft discusses in the abstract.

-2.2, <mark:treatyOrStatute>, <mark:refNum>:
I am not sure the intent of "number of the mark of the treaty or
statute." Does the treaty or statute itself have a mark? A number? Or is
just a reference number for the described mark?

-6: Section numbers would be helpful for the references back into the
body.