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

Gustavo Lozano <gustavo.lozano@icann.org> Fri, 19 February 2016 23:44 UTC

Return-Path: <gustavo.lozano@icann.org>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161291B361F; Fri, 19 Feb 2016 15:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 ppPFYYznGB05; Fri, 19 Feb 2016 15:44:57 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3731B361A; Fri, 19 Feb 2016 15:44:57 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 19 Feb 2016 15:44:54 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1130.005; Fri, 19 Feb 2016 15:44:54 -0800
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
Thread-Topic: Ben Campbell's No Objection on draft-ietf-eppext-tmch-smd-04: (with COMMENT)
Thread-Index: AQHRa2+IQbzAEmlTJU6AcP5ZZ9nZfQ==
Date: Fri, 19 Feb 2016 23:44:53 +0000
Message-ID: <D2ECE5F2.F545A%gustavo.lozano@icann.org>
References: <20160216222102.24096.14754.idtracker@ietfa.amsl.com>
In-Reply-To: <20160216222102.24096.14754.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.35.2]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3538741490_4358536"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/zZZTX8c8FnMP3ACCuqG63HgAcx4>
Cc: "draft-ietf-eppext-tmch-smd@ietf.org" <draft-ietf-eppext-tmch-smd@ietf.org>, "eppext-chairs@ietf.org" <eppext-chairs@ietf.org>, "eppext@ietf.org" <eppext@ietf.org>, "nkong@cnnic.cn" <nkong@cnnic.cn>
Subject: Re: [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
Precedence: list
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: Fri, 19 Feb 2016 23:44:59 -0000

Thank you Ben,

Comments inline.

Regards,
Gustavo

On 2/16/16, 14:21, "Ben Campbell" <ben@nostrum.com>; wrote:

>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?

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


>
>- 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? 

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
>organization address. What is only <mark:name> is present?


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.




>
>- 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)

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


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

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


>
>- 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?

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


>
>-- Do <smd:notBefore> and <smd:notAfter> refer to the validity of the
>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).


>
>-- 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?)

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


>
>-- Does the reasoning for RSA-SHA256 being a SHOULD rather than a MUST
>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.



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

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


>
>-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?

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


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

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.

>