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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Feb 2016 14:21:02 -0800

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.

---

From: Gustavo Lozano <[email-masked]>
Date: Fri, 19 Feb 2016 23:44:53 +0000

Thank you Ben,

Comments inline.

Regards,
Gustavo

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

Gustavo - I replied to Stephen¹s comment,
reply here: 
https://mailarchive.ietf.org/arch/msg/eppext/cNizylFVKdWXu20OKKlq5gIA1KM

>person? 

Gustavo - This has been fixed in version 05 of the I-D, <mark:name> is
used when the 
holder is an individual, and <mark:org> when the holder is an organization.

>Along the same lines,  <mark:addr> is described in terms of an

Gustavo - This has been fixed in version 05, see
https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-05

The address element as described in the definition of <mark:addr> refers
to the address of the holder.

>elements can contain the same ID/repository combination. (This language

Gustavo - Clarified in version 05 of the I-D.

>ruling"? (as opposed to the country of protection)

Gustavo - Clarified in version 05 of the I-D.

>part of <smd:signedMark> is signed, which parts?

Gustavo - Clarified in version 05 of the I-D.

>signature, or the mark itself?

Gustavo - It refers to the validity of the SMD. The idea is to have
fields that indicate the validity period for policy purposes without
signaling
that the signature is invalid (e.g. Expires Property of XMLDISG).

>answer is that the signature validation might fail, them maybe this

Gustavo - The SHOULD was changed to a MUST. See version 5 of the I-D.

>imply that there are algorithms that MUST NOT be used?

Gustavo - I did not understand this comment.  I think that
algorithms that MUST NOT be used are globally deprecated by specific I-Ds.

>this draft discusses in the abstract.

Gustavo - text added in version 5 of the I-D.

>just a reference number for the described mark?

Gustavo - Clarified in version 5 of the I-D.

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

Gustavo - I don¹t want to convert the lists to sections, because the diff
would show large portions of the draft as different, potentially creating
confusion on the readers of the I-D.