Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

[Gould, James]

One other item that is important is the chosen namespace URI.  Based on the 
latest EPP RFCs, IANA wants the namespace URI to be scoped with “epp”, so the 
namespace URI needs to be changed to 
“urn:ietf:params:xml:ns:epp:maintenance-1.0”.  We made a similar change to the 
Registry Fee Extension in draft-ietf-regext-epp-fees-13.  Adding the needed 
“epp” scoping will help with making XML schema changes based on WG feedback 
without breaking existing implementations.

--

JG

[cid:image001.png@01D69D50.ABCDBCE0]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext  on behalf of "Gould, James" 

Date: Tuesday, October 6, 2020 at 3:27 PM
To: "gal...@elistx.com" , "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: 
draft-ietf-regext-epp-registry-maintenance-03


Hi,



I did a review of draft-ietf-regext-epp-registry-maintenance and the following 
is my feedback:



1.   Section 1.1 Terminology and Definition

a.   Since the draft has moved to WGLC, this is somewhat a non-applicable 
point, but the latest practice for EPP extensions has been to use a pointed XML 
namespace (e.g., “urn:ietf:params:xml:ns:maintenance-0.X”) up until the draft 
moves to WGLC, when the XML namespace moves to 1.0 (e.g., 
“urn:ietf:params:xml:ns:maintenance-1.0”).  Using the pointed XML namespace 
will enable making XML schema changes without impacting existing 
implementations.  Backward compatibility can be broken based on WG feedback 
when using the non-pointed XML namespace.

2.   Section 2.3 Maintenance Elements

a.   I would describe the Maintenance Elements in the description of the 
info response (section 3.1.3 EPP  Command) and then for the poll message, 
I would reference the use of the info response.  See how the poll messaging is 
described for the section 2.5 of the Launch Phase Mapping 
(https://tools.ietf.org/html/rfc8334#section-2.5).

b.   My recommendation is to only define SHOULD for elements that are not 
required per the XML schema, since some of the SHOULD elements in the 
description are for required elements in the XML schema.  The other EPP 
Extension RFCs default to the elements being required, but explicitly define 
optional elements using the OPTIONAL keyword.

c.   Should the  element be of type anyURI or is it free-form 
text?

d.  The  is not defined as a “token” and does not 
include an optional “lang” element with a default value of “en” like other EPP 
extensions.

e.  The  element is required per the XML schema with inclusion 
of at least one  element, but it’s defined as a SHOULD.

f.The  element is required per the XML schema with 
inclusion of both the  and  boolean 
elements, but it’s defined as a SHOULD.

g.  Does it make sense for  and  to be required per 
the XML schema for an inactive maintenance?

h.  When are inactive maintenances returned?


  i.  I would assume that only active maintenances would be returned in 
the maintenance list, but when querying for a specific maintenance that has 
been deleted, can the inactive status be returned?


 ii.  How long should deleted maintenances be kept around for?


   iii.  Wouldn’t it be better to return that the deleted maintenance does 
not exist instead of having the concept of an active and inactive status?


   iv.  The Change Poll EPP extension 
(https://tools.ietf.org/html/rfc8590)
 could be used in combination with the maintenance mapping to address the 
deletion use case, where the previous version of the maintenance is returned 
with the change poll reason that the maintenance was deleted.

i.The  element includes a human readable “msg” attribute, 
which also means that there is the need for the optional “lang” attribute with 
a default value of “en”.  The “msg” attribute seems to 

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

[Jody Kolker]

Thanks for the feedback Jim!  We are reviewing and will get back to you

From: regext  On Behalf Of Gould, James
Sent: Thursday, October 8, 2020 7:55 AM
To: gal...@elistx.com; regext@ietf.org
Subject: Re: [regext] WG LAST CALL: 
draft-ietf-regext-epp-registry-maintenance-03

Notice: This email is from an external sender.


One other item that is important is the chosen namespace URI.  Based on the 
latest EPP RFCs, IANA wants the namespace URI to be scoped with “epp”, so the 
namespace URI needs to be changed to 
“urn:ietf:params:xml:ns:epp:maintenance-1.0”.  We made a similar change to the 
Registry Fee Extension in draft-ietf-regext-epp-fees-13.  Adding the needed 
“epp” scoping will help with making XML schema changes based on WG feedback 
without breaking existing implementations.

--

JG

[cid:image001.png@01D69D49.5EE333D0]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext mailto:regext-boun...@ietf.org>> on 
behalf of "Gould, James" 
mailto:jgould=40verisign@dmarc.ietf.org>>
Date: Tuesday, October 6, 2020 at 3:27 PM
To: "gal...@elistx.com" 
mailto:gal...@elistx.com>>, 
"regext@ietf.org" 
mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: 
draft-ietf-regext-epp-registry-maintenance-03


Hi,



I did a review of draft-ietf-regext-epp-registry-maintenance and the following 
is my feedback:



1.   Section 1.1 Terminology and Definition

a.   Since the draft has moved to WGLC, this is somewhat a non-applicable 
point, but the latest practice for EPP extensions has been to use a pointed XML 
namespace (e.g., “urn:ietf:params:xml:ns:maintenance-0.X”) up until the draft 
moves to WGLC, when the XML namespace moves to 1.0 (e.g., 
“urn:ietf:params:xml:ns:maintenance-1.0”).  Using the pointed XML namespace 
will enable making XML schema changes without impacting existing 
implementations.  Backward compatibility can be broken based on WG feedback 
when using the non-pointed XML namespace.

2.   Section 2.3 Maintenance Elements

a.   I would describe the Maintenance Elements in the description of the 
info response (section 3.1.3 EPP  Command) and then for the poll message, 
I would reference the use of the info response.  See how the poll messaging is 
described for the section 2.5 of the Launch Phase Mapping 
(https://tools.ietf.org/html/rfc8334#section-2.5).

b.   My recommendation is to only define SHOULD for elements that are not 
required per the XML schema, since some of the SHOULD elements in the 
description are for required elements in the XML schema.  The other EPP 
Extension RFCs default to the elements being required, but explicitly define 
optional elements using the OPTIONAL keyword.

c.   Should the  element be of type anyURI or is it free-form 
text?

d.  The  is not defined as a “token” and does not 
include an optional “lang” element with a default value of “en” like other EPP 
extensions.

e.  The  element is required per the XML schema with inclusion 
of at least one  element, but it’s defined as a SHOULD.

f.The  element is required per the XML schema with 
inclusion of both the  and  boolean 
elements, but it’s defined as a SHOULD.

g.   Does it make sense for  and  to be required 
per the XML schema for an inactive maintenance?

h.  When are inactive maintenances returned?

  i.  I would assume that only active maintenances would be 
returned in the maintenance list, but when querying for a specific maintenance 
that has been deleted, can the inactive status be returned?

ii.  How long should deleted maintenances be kept around 
for?

  iii.  Wouldn’t it be better to return that the deleted 
maintenance does not exist instead of having the concept of an active and 
inactive status?

   iv.  The Change Poll EPP extension 
(https://tools.ietf.org/html/rfc8590)
 could be used in combination with the maintenance mapping to address the 
deletion use case, where the previous version of the maintenance is returned 
with the change poll reason that t

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

[Hollenbeck, Scott]

Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t think 
we can update Standard 69 (the set of EPP RFCs) this way. I’m not aware of any 
RFCs that expressly prohibit such things, but it’s a topic that the IESG has 
debated multiple times over the years and there might not be support for doing 
it his way now. A safer path would be to develop an extension using one of the 
techniques described in RFC 3735, “Guidelines for Extending the Extensible 
Provisioning Protocol”.



Scott



From: regext  On Behalf Of Dmitry Belyavsky
Sent: Wednesday, October 7, 2020 9:28 AM
To: regext@ietf.org
Cc: marabox 
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-00.txt



Dear colleagues,

This is an initial version of the IETF draft allowing usage of 
Internationalized Email Addresses in the EPP protocol.

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Wed, Oct 7, 2020 at 4:25 PM
Subject: New Version Notification for draft-belyavskiy-epp-eai-00.txt
To: Dmitry Belyavskiy mailto:beld...@gmail.com>>




A new version of I-D, draft-belyavskiy-epp-eai-00.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:   draft-belyavskiy-epp-eai
Revision:   00
Title:  Use of Internationalized Email Addresses in EPP protocol
Document date:  2020-10-07
Group:  Individual Submission
Pages:  4
URL:
https://www.ietf.org/id/draft-belyavskiy-epp-eai-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-belyavskiy-epp-eai
Htmlized:   
https://tools.ietf.org/html/draft-belyavskiy-epp-eai-00


Abstract:
   This document permits usage of Internationalized Email Addresses in
   the EPP protocol.

   TO BE REMOVED on turning to RFC: The document is edited in the
   dedicated github repo [1].  Please send your submissions via GitHub.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat








--

SY, Dmitry Belyavsky

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

[Dmitry Belyavsky]

Dear Scott,

Many thanks for your response!

I'm sorry, I don't feel the difference between this case and a similar
update of X.509 profile by RFC 8399.

And, as the email field is mandatory on creating the contact, I don't think
that the extension is the best way.

On Thu, Oct 8, 2020 at 5:13 PM Hollenbeck, Scott 
wrote:

> Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t
> think we can update Standard 69 (the set of EPP RFCs) this way. I’m not
> aware of any RFCs that expressly prohibit such things, but it’s a topic
> that the IESG has debated multiple times over the years and there might not
> be support for doing it his way now. A safer path would be to develop an
> extension using one of the techniques described in RFC 3735, “Guidelines
> for Extending the Extensible Provisioning Protocol”.
>
>
>
> Scott
>
>
>
> *From:* regext  *On Behalf Of *Dmitry Belyavsky
> *Sent:* Wednesday, October 7, 2020 9:28 AM
> *To:* regext@ietf.org
> *Cc:* marabox 
> *Subject:* [EXTERNAL] [regext] Fwd: New Version Notification for
> draft-belyavskiy-epp-eai-00.txt
>
>
>
> Dear colleagues,
>
> This is an initial version of the IETF draft allowing usage of
> Internationalized Email Addresses in the EPP protocol.
>
> -- Forwarded message -
> From: 
> Date: Wed, Oct 7, 2020 at 4:25 PM
> Subject: New Version Notification for draft-belyavskiy-epp-eai-00.txt
> To: Dmitry Belyavskiy 
>
>
>
>
> A new version of I-D, draft-belyavskiy-epp-eai-00.txt
> has been successfully submitted by Dmitry Belyavskiy and posted to the
> IETF repository.
>
> Name:   draft-belyavskiy-epp-eai
> Revision:   00
> Title:  Use of Internationalized Email Addresses in EPP protocol
> Document date:  2020-10-07
> Group:  Individual Submission
> Pages:  4
> URL:https://www.ietf.org/id/draft-belyavskiy-epp-eai-00.txt
> 
> Status: https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/
> 
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-belyavskiy-epp-eai
> 
> Htmlized:   https://tools.ietf.org/html/draft-belyavskiy-epp-eai-00
> 
>
>
> Abstract:
>This document permits usage of Internationalized Email Addresses in
>the EPP protocol.
>
>TO BE REMOVED on turning to RFC: The document is edited in the
>dedicated github repo [1].  Please send your submissions via GitHub.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org
> 
> .
>
> The IETF Secretariat
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>


-- 
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

[Gould, James]

An extension was used to override the type of the RFC 5730 password and new 
password element in the Login Security Extension 
(https://tools.ietf.org/html/rfc8807).  In the case of the Login Security 
Extension, a pre-defined placeholder value is used in the RFC 5730 password or 
new password elements to point to the use of the corresponding elements in the 
extension.

What is the issue with the eppcom:minTokenType for an internationalized email 
address, which defines a minimum length of one and uses the XML schema “token” 
type, and which extends from the XML schema “normalizedString”?  The only 
difference between the “token” and the proposed “normalizedString” is the 
collapsing of whitespace.  Is the collapsing of whitespace (#x20 (space), #x9 
(tab), #xA (linefeed), or #xD(carriage return)) an issue for internationalized 
email addresses?

--

JG

[cid:image001.png@01D69D5E.F588FAD0]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext  on behalf of Dmitry Belyavsky 

Date: Thursday, October 8, 2020 at 10:21 AM
To: "Hollenbeck, Scott" 
Cc: "ma...@cctld.ru" , "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-00.txt

Dear Scott,

Many thanks for your response!

I'm sorry, I don't feel the difference between this case and a similar update 
of X.509 profile by RFC 8399.

And, as the email field is mandatory on creating the contact, I don't think 
that the extension is the best way.

On Thu, Oct 8, 2020 at 5:13 PM Hollenbeck, Scott 
mailto:shollenb...@verisign.com>> wrote:
Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t think 
we can update Standard 69 (the set of EPP RFCs) this way. I’m not aware of any 
RFCs that expressly prohibit such things, but it’s a topic that the IESG has 
debated multiple times over the years and there might not be support for doing 
it his way now. A safer path would be to develop an extension using one of the 
techniques described in RFC 3735, “Guidelines for Extending the Extensible 
Provisioning Protocol”.

Scott

From: regext mailto:regext-boun...@ietf.org>> On 
Behalf Of Dmitry Belyavsky
Sent: Wednesday, October 7, 2020 9:28 AM
To: regext@ietf.org
Cc: marabox mailto:ma...@cctld.ru>>
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-00.txt

Dear colleagues,

This is an initial version of the IETF draft allowing usage of 
Internationalized Email Addresses in the EPP protocol.
-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Wed, Oct 7, 2020 at 4:25 PM
Subject: New Version Notification for draft-belyavskiy-epp-eai-00.txt
To: Dmitry Belyavskiy mailto:beld...@gmail.com>>



A new version of I-D, draft-belyavskiy-epp-eai-00.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:   draft-belyavskiy-epp-eai
Revision:   00
Title:  Use of Internationalized Email Addresses in EPP protocol
Document date:  2020-10-07
Group:  Individual Submission
Pages:  4
URL:
https://www.ietf.org/id/draft-belyavskiy-epp-eai-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-belyavskiy-epp-eai
Htmlized:   
https://tools.ietf.org/html/draft-belyavskiy-epp-eai-00

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

[Hollenbeck, Scott]

RFC 8399 is a Proposed Standard RFC that updates RFC 5280, another Proposed 
Standard. RFCs 5730 – 5733 are Internet Standards (RFC 2026 describes the 
difference in maturity levels), and as such the barrier for updates tends to 
be higher. The EPP RFCs are aging, and yes, we’re finding things that need to 
be updated. However, this is precisely why we can extend the protocol without 
having to modify the core XML schemas. You may disagree, but I think you’ll 
find that an extension will be an easier path forward from both implementation 
interest and process perspectives.



Scott



From: Dmitry Belyavsky 
Sent: Thursday, October 8, 2020 10:21 AM
To: Hollenbeck, Scott 
Cc: regext@ietf.org; ma...@cctld.ru
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-00.txt



Dear Scott,



Many thanks for your response!



I'm sorry, I don't feel the difference between this case and a similar update 
of X.509 profile by RFC 8399.



And, as the email field is mandatory on creating the contact, I don't think 
that the extension is the best way.



On Thu, Oct 8, 2020 at 5:13 PM Hollenbeck, Scott mailto:shollenb...@verisign.com> > wrote:

Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t think 
we can update Standard 69 (the set of EPP RFCs) this way. I’m not aware of any 
RFCs that expressly prohibit such things, but it’s a topic that the IESG has 
debated multiple times over the years and there might not be support for doing 
it his way now. A safer path would be to develop an extension using one of the 
techniques described in RFC 3735, “Guidelines for Extending the Extensible 
Provisioning Protocol”.



Scott



From: regext mailto:regext-boun...@ietf.org> > On 
Behalf Of Dmitry Belyavsky
Sent: Wednesday, October 7, 2020 9:28 AM
To: regext@ietf.org 
Cc: marabox mailto:ma...@cctld.ru> >
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-00.txt



Dear colleagues,

This is an initial version of the IETF draft allowing usage of 
Internationalized Email Addresses in the EPP protocol.

-- Forwarded message -
From: mailto:internet-dra...@ietf.org> >
Date: Wed, Oct 7, 2020 at 4:25 PM
Subject: New Version Notification for draft-belyavskiy-epp-eai-00.txt
To: Dmitry Belyavskiy mailto:beld...@gmail.com> >




A new version of I-D, draft-belyavskiy-epp-eai-00.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:   draft-belyavskiy-epp-eai
Revision:   00
Title:  Use of Internationalized Email Addresses in EPP protocol
Document date:  2020-10-07
Group:  Individual Submission
Pages:  4
URL:https://www.ietf.org/id/draft-belyavskiy-epp-eai-00.txt 

Status: https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/ 

Htmlized:   https://datatracker.ietf.org/doc/html/draft-belyavskiy-epp-eai 

Htmlized:   https://tools.ietf.org/html/draft-belyavskiy-epp-eai-00 



Abstract:
   This document permits usage of Internationalized Email Addresses in
   the EPP protocol.

   TO BE REMOVED on turning to RFC: The document is edited in the
   dedicated github repo [1].  Please send your submissions via GitHub.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org 

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

[Dmitry Belyavsky]

Dear James and Scott,

Many thanks for your clarifications and example!
Will soon return with an updated draft!

On Thu, Oct 8, 2020 at 5:37 PM Gould, James  wrote:

> An extension was used to override the type of the RFC 5730 password and
> new password element in the Login Security Extension (
> https://tools.ietf.org/html/rfc8807).  In the case of the Login Security
> Extension, a pre-defined placeholder value is used in the RFC 5730 password
> or new password elements to point to the use of the corresponding elements
> in the extension.
>
>
>
> What is the issue with the eppcom:minTokenType for an internationalized
> email address, which defines a minimum length of one and uses the XML
> schema “token” type, and which extends from the XML schema
> “normalizedString”?  The only difference between the “token” and the
> proposed “normalizedString” is the collapsing of whitespace.  Is the
> collapsing of whitespace (#x20 (space), #x9 (tab), #xA (linefeed),
> or #xD(carriage return)) an issue for internationalized email addresses?
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *regext  on behalf of Dmitry Belyavsky <
> beld...@gmail.com>
> *Date: *Thursday, October 8, 2020 at 10:21 AM
> *To: *"Hollenbeck, Scott" 
> *Cc: *"ma...@cctld.ru" , "regext@ietf.org" <
> regext@ietf.org>
> *Subject: *[EXTERNAL] Re: [regext] Fwd: New Version Notification for
> draft-belyavskiy-epp-eai-00.txt
>
>
>
> Dear Scott,
>
>
>
> Many thanks for your response!
>
>
>
> I'm sorry, I don't feel the difference between this case and a similar
> update of X.509 profile by RFC 8399.
>
>
>
> And, as the email field is mandatory on creating the contact, I don't
> think that the extension is the best way.
>
>
>
> On Thu, Oct 8, 2020 at 5:13 PM Hollenbeck, Scott 
> wrote:
>
> Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t
> think we can update Standard 69 (the set of EPP RFCs) this way. I’m not
> aware of any RFCs that expressly prohibit such things, but it’s a topic
> that the IESG has debated multiple times over the years and there might not
> be support for doing it his way now. A safer path would be to develop an
> extension using one of the techniques described in RFC 3735, “Guidelines
> for Extending the Extensible Provisioning Protocol”.
>
>
>
> Scott
>
>
>
> *From:* regext  *On Behalf Of *Dmitry Belyavsky
> *Sent:* Wednesday, October 7, 2020 9:28 AM
> *To:* regext@ietf.org
> *Cc:* marabox 
> *Subject:* [EXTERNAL] [regext] Fwd: New Version Notification for
> draft-belyavskiy-epp-eai-00.txt
>
>
>
> Dear colleagues,
>
> This is an initial version of the IETF draft allowing usage of
> Internationalized Email Addresses in the EPP protocol.
>
> -- Forwarded message -
> From: 
> Date: Wed, Oct 7, 2020 at 4:25 PM
> Subject: New Version Notification for draft-belyavskiy-epp-eai-00.txt
> To: Dmitry Belyavskiy 
>
>
>
>
> A new version of I-D, draft-belyavskiy-epp-eai-00.txt
> has been successfully submitted by Dmitry Belyavskiy and posted to the
> IETF repository.
>
> Name:   draft-belyavskiy-epp-eai
> Revision:   00
> Title:  Use of Internationalized Email Addresses in EPP protocol
> Document date:  2020-10-07
> Group:  Individual Submission
> Pages:  4
> URL:https://www.ietf.org/id/draft-belyavskiy-epp-eai-00.txt
> 
> Status: https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/
> 
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-belyavskiy-epp-eai
> 
> Htmlized:   https://tools.ietf.org/html/draft-belyavskiy-epp-eai-00
> 

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

[John Levine]

In article <5f28bdeb6cbe4d3fa9bf9b969b170...@verisign.com> you write:
>-=-=-=-=-=-
>Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t think 
>we can update Standard 69 (the set of
>EPP RFCs) this way. ...

Regardless of the standards politics, I don't think it would be a good idea
to unilaterally change the meaning of the address field.  It will take a
while for registries to upgrade to handle EAI mail and they need some way
to signal to the registrars that EAI addresses will work.


-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

[Dmitry Belyavsky]

Dear John,

fair point!

The suggested model with dummy value and extension seems to be a relevant
signal.

On Thu, Oct 8, 2020 at 9:17 PM John Levine  wrote:

> In article <5f28bdeb6cbe4d3fa9bf9b969b170...@verisign.com> you write:
> >-=-=-=-=-=-
> >Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t
> think we can update Standard 69 (the set of
> >EPP RFCs) this way. ...
>
> Regardless of the standards politics, I don't think it would be a good idea
> to unilaterally change the meaning of the address field.  It will take a
> while for registries to upgrade to handle EAI mail and they need some way
> to signal to the registrars that EAI addresses will work.
>
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>


-- 
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] I-D Action: draft-ietf-regext-dnrd-objects-mapping-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : Domain Name Registration Data (DNRD) Objects Mapping
Authors : Gustavo Lozano
  James Gould
  Chethan Thippeswamy
Filename: draft-ietf-regext-dnrd-objects-mapping-10.txt
Pages   : 182
Date: 2020-10-08

Abstract:
   This document specifies the format, contents and semantics of Domain
   Name Registration Data (DNRD) Escrow deposits for a Domain Name
   Registry.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-dnrd-objects-mapping-10
https://datatracker.ietf.org/doc/html/draft-ietf-regext-dnrd-objects-mapping-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnrd-objects-mapping-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] Roman Danyliw's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)

[Gustavo Lozano]

Thank you Roman,

Comments below are prefixed with Authors-.

A new version of the I-D has been published here: 
https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-10.txt

Regards,
Gustavo

On 8/24/20, 12:30, "Roman Danyliw via Datatracker"  wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-regext-dnrd-objects-mapping-09: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PtGJab4!tk33CgA_IPEteHsusEK0roZWxzw786v35y7J1dr-z2AkTO_ktFH_C2B8qt_qla02uh-Mn0wQLRk$
 
for more information about IESG DISCUSS and COMMENT positions.


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

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/__;!!PtGJab4!tk33CgA_IPEteHsusEK0roZWxzw786v35y7J1dr-z2AkTO_ktFH_C2B8qt_qla02uh-MCOlAdzI$
 



--
COMMENT:
--

Thank you for this document and the various XLS/CSV examples related to
particular elements of the data model.

** Section 4.4.  Per the use of SHA-256 as a checksum algorithm, what
identifier should be used in the cksumAlg attribute?

Authors- text added in the next version of the I-D.

** Section 4.4.  I concur with the OPSDIR reviewer (Joe Clarke), it would 
seem
like native support (in the format itself) for a more robust checksum 
algorithm
would be desirable.

Authors- text added in the next version of the I-D.

** Section 4.6.2.1.  Per “The  child element defines a 
reference
to the CSV file name”, is any file path information permitted, or are do all
referenced files in dump need to be unique?

Authors- The CSV file name reference can be any file path, but in general is 
only a file name that is relative to the location of the XML definition file.

** Section 5.8.1.  Please add a normative reference to XPath

Authors- text added in the next version of the I-D.

** Section 7.  If one had a business model requiring that checksums  be
computed using SHA-384 (set @cksumAlg) or using 7z compression (set
@compression), how would one specify that in the profile per the defined 
steps
in this section – nothing needs to be extended (step 1, step 3) or 
doesn’t seem to support specifying a particular attribute (step 2), so would
one hard-code that into a custom schema (step 4)?

Authors- only the values need to be specified in @cksumAlg and @compression 
after an out-of-band negotiation. Escrow services are regulated using legal 
agreements, and the details are usually specified based on 
out-of-band-negotiations.

** Editorial Nits
- Section 9.1  Typo. s/Seperated/Separated/

Authors- fixed in the next version of the I-D.

- Section 11.  Typos.  A few repeated instances.  s/section 
Section/Section/g

Authors- fixed in the next version of the I-D.


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] Warren Kumari's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)

[Gustavo Lozano]

Thank you Warren,

Comments below are prefixed with Authors-.

A new version of the I-D has been published here: 
https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-10.txt

Regards,
Gustavo

On 8/25/20, 09:36, "Warren Kumari via Datatracker"  wrote:

Warren Kumari has entered the following ballot position for
draft-ietf-regext-dnrd-objects-mapping-09: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PtGJab4!pKuQDb7nIt-s3eoVbzePp4BnyUTlt0wM4s_9ouPi6tvjEVyumUR1DiAaO2VEVexqtXZDgTER7i8$
 
for more information about IESG DISCUSS and COMMENT positions.


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

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/__;!!PtGJab4!pKuQDb7nIt-s3eoVbzePp4BnyUTlt0wM4s_9ouPi6tvjEVyumUR1DiAaO2VEVexqtXZDCUpcYvQ$
 



--
COMMENT:
--

Thanks to Joe Clarke for his OpsDir comments, and thanks the authors for
addressing them; this has improved the document noticeably (it's nice when 
the
Directorate process works so well).

Some minor nits / comments:
1: 'Version compatibility: versions 03 - 08 are known to be implemented.' --
probably this should bump to -09 

Authors- fixed in the next version of the I-D.

2: Wrapping the BEGIN  END
in  file "some_file_name.xml"   as 
used by
e.g. rfc6087 S3.1 (or use the v3 RFC tools) -- this will allow standard 
tools
to extract the schemas more easily and with less errors.

Authors- fixed in the next version of the I-D.


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] Murray Kucherawy's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)

[Gustavo Lozano]

Thank you Murray,

Comments below are prefixed with Authors-.

A new version of the I-D has been published here: 
https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-10.txt

Regards,
Gustavo

On 8/26/20, 23:45, "regext on behalf of Murray Kucherawy via Datatracker" 
 wrote:

Murray Kucherawy has entered the following ballot position for
draft-ietf-regext-dnrd-objects-mapping-09: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PtGJab4!un2mkHuPQ5mRGNS4U2-WVSdSrvba5FHUfqqBblQH8KdkfWDL-P5Vf-_lQi970PhodD3Y7KvNG3c$
 
for more information about IESG DISCUSS and COMMENT positions.


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

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/__;!!PtGJab4!un2mkHuPQ5mRGNS4U2-WVSdSrvba5FHUfqqBblQH8KdkfWDL-P5Vf-_lQi970PhodD3Y5Ap2OlU$
 



--
COMMENT:
--

[To the IESG: In the IANA Considerations section, the contact for all
registrations is "IESG ".  That's not the IESG's address
though.  (I remember us discussing this in previous telechats, but it's late
and I'm blanking on whether this is the outcome we wanted.)]

Authors- this is what the IESG indicated to be the correct registration.

My colleagues have made a lot of good suggestions already, so I don't have 
much
to add other than these:

In Section 8, there's this bullet:

   o  If a Differential Deposit is to be tested, the dataset is created
  by using the Differential Deposit plus all the required deposits
  leading to the last previous Full Deposit.

It seems obvious, but should this make clear the order in which the
differential deposits are applied?

Authors- text updated in the next version of the I-D.

Totally a nit (which I now see Eric V also mentioned): In a couple of places
there's an ASCII expression like "ASCII value 0x002B".  Since ASCII is 
7-bit,
shouldn't that just be "ASCII value 0x2B"?

Authors- fixed in the next version of the I-D.

___
regext mailing list
regext@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!un2mkHuPQ5mRGNS4U2-WVSdSrvba5FHUfqqBblQH8KdkfWDL-P5Vf-_lQi970PhodD3YSjmQ7V8$
 

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] Éric Vyncke's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)

[Gustavo Lozano]

Thank you Éric,

Comments below are prefixed with Authors-.

A new version of the I-D has been published here: 
https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-10.txt

Regards,
Gustavo

On 8/25/20, 11:51, "Éric Vyncke via Datatracker"  wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-regext-dnrd-objects-mapping-09: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PtGJab4!rBU0vO-gjw6Fqrub9N1aq4rKO80xoO9oRs_cFwaPjhrsCZ0c_iYme3h4P_pcFT_5zKddow--MeY$
 
for more information about IESG DISCUSS and COMMENT positions.


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

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/__;!!PtGJab4!rBU0vO-gjw6Fqrub9N1aq4rKO80xoO9oRs_cFwaPjhrsCZ0c_iYme3h4P_pcFT_5zKddtQ4jY8o$
 



--
COMMENT:
--

Thank you for the work put into this document. Due to my heavy workload, I 
did
not review in details the model itself.

Please find below a couple of non-blocking COMMENTs (a reply to  my COMMENTs
will be welcome).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

A generic question about the point (5) of the document shepherd write-up:
"The AD is asking for further review from the Internationalization
Directorate, specifically on Section 10, which RECOMMENDS UTF-8 but allows
UTF-16.  The working group cites RFC 5730, Section 5, and aligns with that.
The AD would prefer to deprecate UTF-16, and notes that RFC 5730, is now
well over 10 years old.  Other opinions will be useful."

Did the WG receive any other opinions ? It is not clear from the write-up.

Authors- Scott replied here: 
https://mailarchive.ietf.org/arch/msg/regext/kENFq5jLnSGiIn6oeWOjumY1kcQ/

-- Section 4.3 --
Just curious here, why are the ASCII code expressed as a 16-bit unit while
ASCII codes are 7-bit long ? E.g., '("+", ASCII value 0x002B)'

Authors- fixed in the next version of the I-D.

-- Section 4.4 --
Are you sure that CRC32 and SHA-256 belongs to a section named 'checksum' ?
Those 2 techniques are different than checksums and much stronger for 
integrity
checks. Suggest to renamed this section.

Authors- text updated in the next version of the I-D.

In addition, should the algorithm be identified ?

Authors- text updated in the next version of the I-D.

-- Section 4.5 --
RFC 4291 is about the addressing structure of IPv6 (i.e., semantic), please
replace this reference to RFC 5952 that is about how to write an IPv6 
address
(i.e., syntax).

Authors- fixed in the next version of the I-D.

-- Section 4.6.1 --
Just curious again... why not using plain SQL data definition language 
'create
table()' statements rather than using XML to describe relational tables? Of
course, the XML file contains other information than the SQL data definition
language but it is lacking some information from SQL.

Also, it seems that using XML rather than SQL forces the primary key and
foreign key to have the same name (e.g., )

Authors- XML is used to match the type definitions used the related 
provisioning protocol, which is EPP (RFC 5730 – 5733).  In this case the 
elements provided over the provisioning protocol can be directly used in the 
data escrow.

-- Section 5.3.2.1.3 --
Should the postal ZIP code be included ?

Authors- the postal code is supported with the  field with CSV 
and the  element with XML.

== NITS ==

-- Section 5.1.1.1 --
Really cosmetic, but, having an expiration date in 2015 in the example in a
document published in 2020 ;-)

Authors- fixed in the next version of the I-D.


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] Benjamin Kaduk's Discuss on draft-ietf-regext-dnrd-objects-mapping-09: (with DISCUSS and COMMENT)

[Gustavo Lozano]

Thank you Benjamin,

Comments below are prefixed with Authors-.

A new version of the I-D has been published here: 
https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-10.txt

Regards,
Gustavo

On 8/26/20, 23:30, "Benjamin Kaduk via Datatracker"  wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-dnrd-objects-mapping-09: Discuss

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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PtGJab4!s1nuWEaTWTlygiU9qZXsG1O9BWmgP0nR53eMCtazUTqp49hdVhbJM2IvF2YN_gjULj1e6IR8BTA$
 
for more information about IESG DISCUSS and COMMENT positions.


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

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/__;!!PtGJab4!s1nuWEaTWTlygiU9qZXsG1O9BWmgP0nR53eMCtazUTqp49hdVhbJM2IvF2YN_gjULj1e5ypcsy4$
 



--
DISCUSS:
--

It's possible that I just misunderstand what is required to go where,
but for several (possibly only CSV?) elements, the body text claims that
"[t]he attribute "isRequired" MUST equal "true"." but the corresponding
examples do not consistently list the "isRequired" attribute.
(Sometimes they do, but not always.)  Shouldn't the examples be
consistent with the protocol requirements?  I note some examples in my
COMMENT section but this should not be treated as an exhaustive list.

Authors- The "isRequired" attribute is set by default based on the type 
referenced by the field in the XML schema.  Inclusion of the "isRequired" 
attribute explicitly in the examples is used to override the default of the 
referenced type.  Below is the relevant text for the "isRequired" attribute of 
the  elements, in section 4.6.2.1 " element":

The  elements
support the "isRequired" attribute, with a default value of
"false", when set to "true" indicates that the field must be non-
empty in the CSV files and when set to "false" indicates that the
field MAY be empty in the CSV files.  The "isRequired" attribute
MAY be specifically set for the field elements within the XML
schema and MAY be overridden when specifying the fields under the
 element.

A similar property (again, if I understand correctly) holds for the
"parent" attribute of various elements (which is definitely only a thing
for the CSV objects)..

Authors- The “parent” attribute is explicitly set in the  
elements to provide a hint that it represents a foreign key.  Below is the 
relevant text for describing the “parent” attribute of the  
elements in section 4.6.2.1 " element":

The  element supports an
OPTIONAL "parent" attribute that identifies the field as a
reference to a parent object, as defined in CSV Parent Child
Relationship (Section 4.6.1 [tools.ietf.org]).  For example, the   field SHOULD set the
"parent" attribute to "true" to identify it as the parent domain
name of the domain status.

The claim in the IANA Considerations regarding "URI assignments have
been registered by the IANA", accompanied by specific URN
namespace/schema values, is codepoint squatting, in the absence of a
disclaimer about being "requested values".  The registration policy is
only Specification Required, so there is no formal guarantee that we can
actually get these values.

Authors- text updated in the next version of the I-D.

At least one of the examples shows RSA/MD5 DNSSEC key records.  RSA/MD5
usage is specifically disallowed (see RFC 6944 and RFC 8624);
please replace with a more modern algorithm.  (One location noted in the
COMMENT, along with some SHA-1 usage that should probably go as well.)

Authors- Examples fixed in the next version of the I-D.

--
COMMENT:
--

We have at least one example that shows a gurid of 123, which is an
actual value allocated to a real registrar by ICANN (details in the
section-by-section comments).  Please consider using a different value
for the example.

Authors- fixed in the next version of the I-D.

Section 1

   Registry Data Escrow is the process by which a registry periodically

nit: maybe include "(RDE)", since we use the acronym later on before the
definitions section.

Authors- text updated in the next version of the I-D.

   This document defines the following pseudo-objects:
   [...]
   o  EPP parameters: Definition of the specific EPP parameters
  supported by the Registry Operator.

nit: is the 

Re: [regext] [Ext] Erik Kline's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)

[Gustavo Lozano]

Thank you Erik,

Comments below are prefixed with Authors-.

A new version has been published here:

Regards,
Gustavo

On 8/25/20, 17:47, "Erik Kline via Datatracker"  wrote:

Erik Kline has entered the following ballot position for
draft-ietf-regext-dnrd-objects-mapping-09: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PtGJab4!oublqDZDSArqbWBQnbFor1rxwDgavlq-WBXYt_Cr9S7UqhIyOUn0WdGP8hxc-QTzTjHzr-r7-Q0$
 
for more information about IESG DISCUSS and COMMENT positions.


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

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/__;!!PtGJab4!oublqDZDSArqbWBQnbFor1rxwDgavlq-WBXYt_Cr9S7UqhIyOUn0WdGP8hxc-QTzTjHzztI-XAo$
 



--
COMMENT:
--

[ section 4.5 ]

* For text representations you want RFC 5952 rather than 4291.

Authors- fixed in the next version of the I-D.

[ section 5.1.2.1.5, 5.2.2.1.3 ]

* It's not clear that ",v4" or ",v6" are adding anything. The IP address
  family should be unambiguous without the hint.

  No change necessary, it just seems like this isn't really needed.  (For
  example, if there's even a remote possibility someone might try to list
  IPv4-mapped IPv6 addresses -- or even worse, compat addresses -- then
  there are going some other, much bigger problems ahead.)

Authors- it's a hint for verification to the party restoring the deposit

[ section 5.4.1.1 ]

* Is it recommended at all that rdeRegistrar:url be https whenever possible?

Authors- text added in the next version of the I-D.

* In addition to whois name/url should there RDAP information?  Or is the
  http/https whois URL expected to handle RDAP?

Authors- the industry is moving away for storing the base URL for the RDAP 
services in the SRS. See RFC7484, and 
https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml. There have 
been conversations of having a generic bootstrap-like for Registrars to 
accommodate non-gTLDs. If there is a specific need to store this information in 
the deposit, an extension can be created.


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] Roman Danyliw's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)

[Roman Danyliw]

Hi Gustavo!

Thanks for answers below and addressing my comments in -09.  Please consider my 
feedback resolved.

Thanks,
Roman

> -Original Message-
> From: Gustavo Lozano 
> Sent: Thursday, October 8, 2020 5:44 PM
> To: Roman Danyliw ; The IESG 
> Cc: draft-ietf-regext-dnrd-objects-mapp...@ietf.org; regext-cha...@ietf.org;
> regext@ietf.org; Scott Hollenbeck 
> Subject: Re: [Ext] Roman Danyliw's No Objection on draft-ietf-regext-dnrd-
> objects-mapping-09: (with COMMENT)
> 
> Thank you Roman,
> 
> Comments below are prefixed with Authors-.
> 
> A new version of the I-D has been published here:
> https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-10.txt
> 
> Regards,
> Gustavo
> 
> On 8/24/20, 12:30, "Roman Danyliw via Datatracker" 
> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-regext-dnrd-objects-mapping-09: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-
> criteria.html__;!!PtGJab4!tk33CgA_IPEteHsusEK0roZWxzw786v35y7J1dr-
> z2AkTO_ktFH_C2B8qt_qla02uh-Mn0wQLRk$
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-
> regext-dnrd-objects-
> mapping/__;!!PtGJab4!tk33CgA_IPEteHsusEK0roZWxzw786v35y7J1dr-
> z2AkTO_ktFH_C2B8qt_qla02uh-MCOlAdzI$
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for this document and the various XLS/CSV examples related to
> particular elements of the data model.
> 
> ** Section 4.4.  Per the use of SHA-256 as a checksum algorithm, what
> identifier should be used in the cksumAlg attribute?
> 
> Authors- text added in the next version of the I-D.
> 
> ** Section 4.4.  I concur with the OPSDIR reviewer (Joe Clarke), it would
> seem
> like native support (in the format itself) for a more robust checksum
> algorithm
> would be desirable.
> 
> Authors- text added in the next version of the I-D.
> 
> ** Section 4.6.2.1.  Per “The  child element defines a 
> reference
> to the CSV file name”, is any file path information permitted, or are do 
> all
> referenced files in dump need to be unique?
> 
> Authors- The CSV file name reference can be any file path, but in general is 
> only
> a file name that is relative to the location of the XML definition file.
> 
> ** Section 5.8.1.  Please add a normative reference to XPath
> 
> Authors- text added in the next version of the I-D.
> 
> ** Section 7.  If one had a business model requiring that checksums  be
> computed using SHA-384 (set @cksumAlg) or using 7z compression (set
> @compression), how would one specify that in the profile per the defined
> steps
> in this section – nothing needs to be extended (step 1, step 3) or 
> 
> doesn’t seem to support specifying a particular attribute (step 2), so 
> would
> one hard-code that into a custom schema (step 4)?
> 
> Authors- only the values need to be specified in @cksumAlg and @compression
> after an out-of-band negotiation. Escrow services are regulated using legal
> agreements, and the details are usually specified based on out-of-band-
> negotiations.
> 
> ** Editorial Nits
> - Section 9.1  Typo. s/Seperated/Separated/
> 
> Authors- fixed in the next version of the I-D.
> 
> - Section 11.  Typos.  A few repeated instances.  s/section 
> Section/Section/g
> 
> Authors- fixed in the next version of the I-D.
> 

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext