Re: [regext] [Gen-art] Genart last call review of draft-ietf-regext-org-ext-09

[Alissa Cooper]

Jari, thank you for your review. I have entered a No Objection ballot.

Alissa

> On Sep 28, 2018, at 5:56 AM, Jari Arkko  wrote:
> 
> Reviewer: Jari Arkko
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-regext-org-ext-09
> Reviewer: Jari Arkko
> Review Date: 2018-09-27
> IETF LC End Date: 2018-10-08
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> While not being a DNS, EPP, or XML expert :-) I have reviewed this document 
> and
> found it to be clear and reasonable. I have no issues. And I was happy to see
> some implementations in the implementation report at the end.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [regext] Alexey Melnikov's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Alexey,
Thanks for your review. I have listed the reference in the following text. The 
references will be applied to other part in the document. Please see my 
feedbacks inline with [Linlin].
 
Regards,
Linlin


Linlin Zhou
 
From: Alexey Melnikov
Date: 2018-10-24 20:42
To: The IESG
CC: regext-chairs; pieter.vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Alexey Melnikov's No Objection on draft-ietf-regext-org-11: 
(with COMMENT)
Alexey Melnikov has entered the following ballot position for
draft-ietf-regext-org-11: 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-regext-org/
 
 
 
--
COMMENT:
--
 
This is a well written document, but I am concerned about missing references
for various syntactic elements that you use. Having proper references will save
developers time and will improve interoperability. The same issue in at least 3
places in the document, I am mentioning the first one below.
 
In 4.1.1:
 
   o  An OPTIONAL  element that may be provided when an
  object cannot be provisioned.  If present, this element contains
  server-specific text to help explain why the object cannot be
  provisioned.  This text MUST be represented in the response
  language previously negotiated with the client; an OPTIONAL "lang"
 
Please either point to the Language tag RFC 5646/BCP 47 or point to another RFC
which defines the "lang" attribute.
[Linlin] ...an OPTIONAL "lang" attribute as defined in [RFC 5646] MAY be 
present... 
 
  attribute MAY be present to identify the language if the
  negotiated value is something other than the default value of
  "en"(English).
 
4.1.2.  EPP  Command
 
   o  Zero to two  elements that contain postal-address
  information.  Two elements are provided so that address
  information can be provided in both internationalized and
  localized forms; a "type" attribute is used to identify the two
  forms.  If an internationalized form (type="int") is provided,
  element content MUST be represented in a subset of Unicode in the
  range U+0020 - U+007E.  If a localized form (type="loc") is
  provided, element content MAY be represented in unrestricted UTF-
  8.  The  element contains the following child
  elements:
 
[snip]
 
 +  An  element that contains the organization's country
code.
 
Please add the correct reference for country codes. I believe you want to
reference D country codes from ISO 3166. (There are also alpha-3 country
codes.)
 
Alternative you can just reference a section from RFC 5733.
[Linlin]  An  element that contains the alpha-2 organization's country 
code. The detailed format of this element is described in section 2.4.3 of RFC 
5733.
 
   o  An OPTIONAL  element that contains the organization's
  email address.
 
Please point to specific format for email addresses (there is RFC 5321 format
and RFC 5322 format. They are not identical.) Alternative you can just
reference a section from RFC 5733.
[Linlin] An OPTIONAL  element that contains the organization's 
email address. The detailed format of this element is described in section 2.6 
of RFC 5733.
 
   o  An OPTIONAL  element that contains the URL to the website
  of the organization. 
 
Please add a reference to RFC 3986 or to one of HTTP RFCs if you want to
restrict this to https: or http:
[Linlin] An OPTIONAL  element that contains the URL to the website of 
the organization. The detailed format of this element is described in RFC 3986.
 
One possible way of addressing all of the above is to add a few sentences with
references to the "Conventions Used in This Document" section.
 
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Alexey Melnikov's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Alexey Melnikov]

Hi Linlin,
Your proposed changes look good to me!

Thank you,
Alexey

> On 25 Oct 2018, at 08:37, Linlin Zhou  wrote:
> 
> Dear Alexey,
> Thanks for your review. I have listed the reference in the following text. 
> The references will be applied to other part in the document. Please see my 
> feedbacks inline with [Linlin].
>  
> Regards,
> Linlin
> Linlin Zhou
>  
> From: Alexey Melnikov
> Date: 2018-10-24 20:42
> To: The IESG
> CC: regext-chairs; pieter.vandepitte; draft-ietf-regext-org; regext
> Subject: [regext] Alexey Melnikov's No Objection on draft-ietf-regext-org-11: 
> (with COMMENT)
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-regext-org-11: 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-regext-org/
>  
>  
>  
> --
> COMMENT:
> --
>  
> This is a well written document, but I am concerned about missing references
> for various syntactic elements that you use. Having proper references will 
> save
> developers time and will improve interoperability. The same issue in at least 
> 3
> places in the document, I am mentioning the first one below.
>  
> In 4.1.1:
>  
>o  An OPTIONAL  element that may be provided when an
>   object cannot be provisioned.  If present, this element contains
>   server-specific text to help explain why the object cannot be
>   provisioned.  This text MUST be represented in the response
>   language previously negotiated with the client; an OPTIONAL "lang"
>  
> Please either point to the Language tag RFC 5646/BCP 47 or point to another 
> RFC
> which defines the "lang" attribute.
> [Linlin] ...an OPTIONAL "lang" attribute as defined in [RFC 5646] MAY be 
> present... 
>  
>   attribute MAY be present to identify the language if the
>   negotiated value is something other than the default value of
>   "en"(English).
>  
> 4.1.2.  EPP  Command
>  
>o  Zero to two  elements that contain postal-address
>   information.  Two elements are provided so that address
>   information can be provided in both internationalized and
>   localized forms; a "type" attribute is used to identify the two
>   forms.  If an internationalized form (type="int") is provided,
>   element content MUST be represented in a subset of Unicode in the
>   range U+0020 - U+007E.  If a localized form (type="loc") is
>   provided, element content MAY be represented in unrestricted UTF-
>   8.  The  element contains the following child
>   elements:
>  
> [snip]
>  
>  +  An  element that contains the organization's country
> code.
>  
> Please add the correct reference for country codes. I believe you want to
> reference D country codes from ISO 3166. (There are also alpha-3 country
> codes.)
>  
> Alternative you can just reference a section from RFC 5733.
> [Linlin]  An  element that contains the alpha-2 organization's 
> country code. The detailed format of this element is described in section 
> 2.4.3 of RFC 5733.
>  
>o  An OPTIONAL  element that contains the organization's
>   email address.
>  
> Please point to specific format for email addresses (there is RFC 5321 format
> and RFC 5322 format. They are not identical.) Alternative you can just
> reference a section from RFC 5733.
> [Linlin] An OPTIONAL  element that contains the organization's 
> email address. The detailed format of this element is described in section 
> 2.6 of RFC 5733.
>  
>o  An OPTIONAL  element that contains the URL to the website
>   of the organization. 
>  
> Please add a reference to RFC 3986 or to one of HTTP RFCs if you want to
> restrict this to https: or http:
> [Linlin] An OPTIONAL  element that contains the URL to the website 
> of the organization. The detailed format of this element is described in RFC 
> 3986.
>  
> One possible way of addressing all of the above is to add a few sentences with
> references to the "Conventions Used in This Document" section.
>  
>  
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Eric,
Thanks for your review. Please see my feedbacks below with [Linlin].

Regards,
Linlin


Linlin Zhou
 
From: Eric Rescorla
Date: 2018-10-25 02:05
To: The IESG
CC: regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with 
DISCUSS and COMMENT)
Eric Rescorla has entered the following ballot position for
draft-ietf-regext-org-11: 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://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-regext-org/
 
 
 
--
DISCUSS:
--
 
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624
 
 
This DISCUSS should be easy to clear. I have noted a few points where
I do not believe that the spec is sufficiently clear to implement.
 
DETAIL
S 3.4.
>   
>  o  clientUpdateProhibited, serverUpdateProhibited: Requests to update
> the object (other than to remove this status) MUST be rejected.
>   
>  o  clientDeleteProhibited, serverDeleteProhibited: Requests to delete
> the object MUST be rejected.
 
How does access control work here? If either of these values are set,
then it must be rejected?
[Linlin] If you mean that clientUpdateProhibited and serverUpdateProhibited are 
set, these two statuses can coexist in the system. "clientUpdateProhibited" is 
set by the client and "serverUpdateProhibited" is set by the server.
 
 
S 4.1.2.
>  C:res1523
>  C:  
>  C:
>  C:ABC-12345
>  C:  
>  C:
 
So I can only  one org?
[Linlin] Yes,  command supports one org id.
 
 
S 4.1.2.
>   
>  o  One or more  elements that contain the operational
> status of the organization, as defined in Section 3.4.
>   
>  o  An OPTIONAL  element that contains the identifier of
> the parent object, as defined in Section 3.6.
 
It's not clear to me what's really optional here, because you say
above that it's up to the server but then you label some stuff here as
OPTIONAL
[Linlin] If this sentence makes confusion. How about changing it to "It is up 
to the server policy to decide 
what optional attributes will be returned of an organization object." or just 
remove it?
 
 
--
COMMENT:
--
 
S 3.2.1.
>  object.  A client can change the role of an organization object using
>  the EPP  command.
>   
>   3.2.1.  Role Type
>   
>  An organization role MUST have a type which supports a list of
 
Editorial: I found this confusing. I think you want to say "MUST have
a type field. This may have any of the values listed in "
 
It's not the type that supports the list.
 [Linlin] Yes, thank you for your text.
 
 
 
S 3.4.
> rejected.
>   
>  o  linked: The organization object has at least one active
> association with another object.  The "linked" status is not
> explicitly set by the client.  Servers should provide services to
> determine existing object associations.
 
I'm not following this text. It is set by the server?
[Linlin] Yes, it is set by the server. Benjamin's comment will be adopted. 
Adding a sentence to clarify. "Other status values that do not begin with 
either "client" or "server" are server-managed".
 
 
S 3.4.
> has been processed for the object, but the action has not been
> completed by the server.  Server operators can delay action
> completion for a variety of reasons, such as to allow for human
> review or third-party action.  A transform command that is
> processed, but whose requested action is pending, is noted with
> response code 1001.
 
Who can set this?
 [Linlin] The server can set the error code to 1001 and send the response to 
the client.
 
S 3.5.
> association with another object.  The "linked" status is not
> explicitly set by the client.  Servers SHOULD provide services to
> determine existing object associations.
>   
>  o  clientLinkProhibited, serverLinkProhibited: Requests to add new
> links to the role MUST be rejected.
 
see above question about access control
[Linlin] If both the clientXXXProhibited and serverXXXProhibited are set, this 
situation is permitted.
 
 
S 3.6.
>  not defined for the top level reseller, namely the registrar of the
>  registry.  An N-tier reseller has a parent reseller and at least one
>  child reseller.  A 

Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Thu, Oct 25, 2018 at 2:44 AM Linlin Zhou  wrote:

> Dear Eric,
> Thanks for your review. Please see my feedbacks below with [Linlin].
>
> Regards,
> Linlin
> --
> Linlin Zhou
>
>
> *From:* Eric Rescorla 
> *Date:* 2018-10-25 02:05
> *To:* The IESG 
> *CC:* regext-chairs ; Pieter Vandepitte
> ; draft-ietf-regext-org
> ; regext 
> *Subject:* [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11:
> (with DISCUSS and COMMENT)
> Eric Rescorla has entered the following ballot position for
> draft-ietf-regext-org-11: 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://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-regext-org/
>
>
>
> --
> DISCUSS:
> --
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3624
>
>
> This DISCUSS should be easy to clear. I have noted a few points where
> I do not believe that the spec is sufficiently clear to implement.
>
> DETAIL
> S 3.4.
> >
> >  o  clientUpdateProhibited, serverUpdateProhibited: Requests to
> update
> > the object (other than to remove this status) MUST be rejected.
> >
> >  o  clientDeleteProhibited, serverDeleteProhibited: Requests to
> delete
> > the object MUST be rejected.
>
> How does access control work here? If either of these values are set,
> then it must be rejected?
> [Linlin] If you mean that clientUpdateProhibited and
> serverUpdateProhibited are set, these two statuses can coexist in the
> system. "clientUpdateProhibited" is set by the client and
> "serverUpdateProhibited" is set by the server.
>
>
That's not what I mean. What I mean is "what is the access control rule
that the server is supposed to apply".

>
>
>
> S 4.1.2.
> >  C:res1523
> >  C:  
> >  C:
> >  C:ABC-12345
> >  C:  
> >  C:
>
> So I can only  one org?
> [Linlin] Yes,  command supports one org id.
>
>
Ok.


>
> S 4.1.2.
> >
> >  o  One or more  elements that contain the operational
> > status of the organization, as defined in Section 3.4.
> >
> >  o  An OPTIONAL  element that contains the identifier
> of
> > the parent object, as defined in Section 3.6.
>
> It's not clear to me what's really optional here, because you say
> above that it's up to the server but then you label some stuff here as
> OPTIONAL
> [Linlin] If this sentence makes confusion. How about changing it to "It
> is up to the server policy to decide
> what optional attributes will be returned of an organization object." or
> just remove it?
>
>
I don't know, because I don't understand the semantics you are aiming for.
Are the other attributes optional.



>
> S 3.4.
> > rejected.
> >
> >  o  linked: The organization object has at least one active
> > association with another object.  The "linked" status is not
> > explicitly set by the client.  Servers should provide services to
> > determine existing object associations.
>
> I'm not following this text. It is set by the server?
> [Linlin] Yes, it is set by the server. Benjamin's comment will be adopted.
> Adding a sentence to clarify. "Other status values that do not begin with
> either "client" or "server" are server-managed".
>
>
> S 3.4.
> > has been processed for the object, but the action has not been
> > completed by the server.  Server operators can delay action
> > completion for a variety of reasons, such as to allow for human
> > review or third-party action.  A transform command that is
> > processed, but whose requested action is pending, is noted with
> > response code 1001.
>
> Who can set this?
>  [Linlin] The server can set the error code to 1001 and send the response
> to the client.
>
>
Sorry, context got lost. Who can set "pendingCreate"?



> S 3.5.
> > association with another object.  The "linked" status is not
> > explicitly set by the client.  Servers SHOULD provide services to
> > determine existing object associations.
> >
> >  o  clientLinkProhibited, serverLinkProhibited: Requests to add new
> > links to the role MUST be rejected.
>
> see above question about access control
> [Linlin] If both the clientXXXProhibited and serverXXXProhibited are set,
> this situation is permitted.
>
>
Sorry, this is still not clear to me.

>
>
>


> S 3.6.
> >  not defined for the top level reseller, namely the registrar of the
> >  registry.  An N-tier reseller has a parent reseller and a

[regext] FW: Re: Re: Re: Re: Document Shepherd check on draft-ietf-regext-bundling-registration-05

[Hollenbeck, Scott]

Sorry, I should have sent this to the list, too.



Scott



From: Hollenbeck, Scott
Sent: Thursday, October 25, 2018 10:35 AM
To: 'j...@afilias.info' 
Subject: RE: [EXTERNAL] Re: Re: Re: Re: [regext] Document Shepherd check on 
draft-ietf-regext-bundling-registration-05



Actually, there is one more thing: an entry should be added to the IANA 
Considerations section to add this extension to the EPP extensions registry 
found here:



https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml



The registration template can be found in Section 2.2.1 of RFC 7451:



https://tools.ietf.org/html/rfc7451



Scott



From: Joseph Yee mailto:j...@afilias.info>>
Sent: Thursday, October 25, 2018 10:08 AM
To: Hollenbeck, Scott 
mailto:shollenb...@verisign.com>>
Subject: [EXTERNAL] Re: Re: Re: Re: [regext] Document Shepherd check on 
draft-ietf-regext-bundling-registration-05



Thank you!



-Joseph



On Wed, Oct 24, 2018 at 6:22 PM Hollenbeck, Scott 
mailto:shollenb...@verisign.com>> wrote:

   Yes, all addressed. Thank you.

   Scott


   On Oct 24, 2018, at 4:35 PM, Joseph Yee 
mailto:j...@afilias.info>> wrote:

  HI Scott,



  Do the current draft address all your concerns? Thanks.



  Best,

  Joseph





  On Thu, Oct 11, 2018 at 10:05 AM Hollenbeck, Scott 
mailto:shollenb...@verisign.com>> wrote:

 Thanks, Jiankang.



 Scott



 From: Jiankang Yao mailto:ya...@cnnic.cn>>
 Sent: Thursday, October 11, 2018 5:50 AM
 To: Hollenbeck, Scott 
mailto:shollenb...@verisign.com>>; jyee 
mailto:j...@afilias.info>>; regext 
mailto:regext@ietf.org>>
 Subject: [EXTERNAL] Re: Re: [regext] Document Shepherd check on 
draft-ietf-regext-bundling-registration-05



 Dear Scott,



   Thanks for your kind support and review.

   The version 06 has been updated to address your concerns.

 
https://www.ietf.org/internet-drafts/draft-ietf-regext-bundling-registration-06.txt





 section  7.2.3.  EPP  Command

  section  7.2.4.  EPP  Command

 section  7.2.5.  EPP  Command

 have refined the text and added the example according to your kind 
suggestion.



 Section  11.  Security Considerations   has been updated to add some 
words related security.





 CNNIC and some other registries have implemented this document, and 
tested the examples.



 Thanks a lot.


   _


 Jiankang Yao



 From: Hollenbeck, 
Scott

 Date: 2018-10-02 19:29

 To: 'j...@afilias.info'; 
'regext@ietf.org'

 Subject: Re: [regext] Document Shepherd check on 
draft-ietf-regext-bundling-registration-05

 I don’t recall seeing any discussion of or text changes to address my 
feedback. Here’s my note:



 https://www.ietf.org/mail-archive/web/regext/current/msg01541.html



 Scott



 From: regext mailto:regext-boun...@ietf.org>> 
On Behalf Of Joseph Yee
 Sent: Monday, October 01, 2018 5:15 PM
 To: regext@ietf.org
 Subject: [EXTERNAL] [regext] Document Shepherd check on 
draft-ietf-regext-bundling-registration-05



 HI all,



 I'm the document shepherd of 
draft-ietf-regext-bundling-registration-05.  During review. The WG had made a 
last call on its -03 version (subject: [regext] WGLC: 
draft-ietf-regext-bundling-registration-03), and Scott Hollenbeck supported the 
publication but also raised concern on security consideration.



 I have not see any further discussion on this, I would like to ask 
whether WG closed the issue. Thanks to all.



 Best,

 Joseph



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

[regext] IANA Considerations for draft-ietf-regext-org and draft-ietf-regext-org-ext

[Hollenbeck, Scott]

Minor comments here that I just noticed while looking at a different document...

The registration template for the EPP extensions registry is described in 
Sections 2.2.1 and 2.2.2 of RFC 7451. Both draft-ietf-regext-org and 
draft-ietf-regext-org-ext are missing the "Reference" information. It should be 
added, like this (or similar):

Reference: RFC  (please replace "" with the RFC number for this 
document after a number is assigned by the RFC Editor)

Scott

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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Thu, Oct 25, 2018 at 11:29:41AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> Thanks for your review. Please see my feedbacks below.
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Benjamin Kaduk
> Date: 2018-10-24 03:13
> To: The IESG
> CC: regext-chairs; pieter.vandepitte; regext; draft-ietf-regext-org-ext
> Subject: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: 
> (with DISCUSS and COMMENT)
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-regext-org-ext-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://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-regext-org-ext/
>  
>  
>  
> --
> DISCUSS:
> --
>  
> I have two points that I would like to discuss.  It is more likely than not
> that at least one of them merely reflects my confusion and is a non-issue,
> but I would like to get these at least clarified.
>  
> First, the examples throughout the document use organization identifiers
> like "myreseller" or "myproxy".  This seems to me to be highly confusing,
> since these IDs are supposed to be server-unique values per organization,
> and are highly unlikely to be "my" reseller/proxy/etc. for all the entries
> in the registry.  If I understand things correctly, the example IDs should
> instead be company-name-like values or "random" numbers or similar (or
> combination thereof).
> [Linlin]  Thank you for pointing out this. To be more consistent with the 
> draft-ietf-regext-org draft, I suggest using the IDs defined in the "org" 
> draft, like "reseller1523" , "registrar1362" or "proxy2935".

Excellent; thank you!

> Second, I am unsure of the semantics relating to role types, especially as
> they interact with the  command.  Various aspects of the examples
> seem to imply that it is only permitted to have at most one organization
> mapping of a given role type (i.e., one reseller, one proxy, etc.).  In
> particular, the  element seems to be using the  role
> attribute to determine which  is being changed (with the new
> value being provided in the element body), and the  element is
> providing  with only the role attribute and no body to identify
> a specific organization to remove.  If this reading of the document is
> correct, then I would expect the limitation to be called out more clearly,
> especially as it would seem to prevent a domain owner from (e.g.) using
> multiple DNS service operators.
> [Linlin] In the normal business model, for example a domain should have one 
> reseller, one registrar etc.  How about adding some text like "One 
>  element is suggested for each role type." in the element 
> description.

I don't think that addresses my core concern (though it is probably worth
doing in its own right).

In particular, if it is allowed by the protocol/registry to have more than
one  element of a given role type, then several of the protocol
exchanges this document defines within  are not fully defined in an
interoperable fashion.  For example, what if I receive a
 [Linlin] Yes. "...which are not formally defined yet..."
>  
>An organization mapping object defined in [ID.draft-ietf-regext-org]
>SHOULD be created first.  The organization information specified in
>this document MUST reference the existing organization identifier.
>  
> What does "first" refer to?  "prior to the use of that object"?
> [Linlin] Yes. The organizations object should be created prior to using the 
> organization ID for the extension. Maybe I can change the words to be more 
> clear, "Organization object identifiers MUST be known to the server before 
> the organization object can be associated with the EPP object."

I think that helps; thank you.

-Benjamin

> Section 2
>  
>The XML namespace prefix "orgext" is used, but implementations MUST
>NOT depend on it and instead employ a proper namespace-aware XML
>parser and serializer to interpret and output the XML documents.
>  
> [This could probably be written more clearly; see my comment on the
> companion document]
>  [Linlin] I'll update it to use the full namespace.
> 
> Section 9
>  
> IIRC the authorization model for EPP does not allow arbitrary clients to
> retrieve information about arbitrary (unrelated) domains.  If that's not
> the case, there would be privacy considerations with respect to exposing
> the linkages of the organization mappings (and roles).
> [Linlin] Yes. EPP provides a authentication mechanism which is mentioned in 
> RFC5730.
>  
>  
> 

[regext] draft-ietf-regext-org extensibility comments

[Martin Thomson]

Hi,

I was asked to review draft-ietf-regext-org for the XML namespace and
schema registries.  Everything looks fine, except that I think we got
crossed wires somewhere in the back and forth.

The comment I made was that certain types use xs:enumeration with a
set of values.  Here I refer to epp-org:statusType,
epp-org:roleStatusType, and epp-org:contactAttrType.

The question was whether these types were intended to be extended, or
whether the working group was confident that the list was exhaustive.
Based on the content of the lists, it doesn't appear possible that the
lists could be exhaustive, but maybe there are constraints in this
domain that ensure this is the case.

The current structure of the schema would prevent these from ever
being extended [1].  The comment was then a question: does the working
group believe that the set of values for these

When I asked, the response was about epp-org:roleType/type. That
confused me.  That element is defined as xs:token and has a registry
associated with it, so it's clear that this is extensible.  I'm asking
about these enumerated types.

And a bonus question, which I would not have commented on as the
designated expert, but since I'm writing, I'll ask for my own
gratification: Why define yet another addressing format?  Just in the
IETF we have a ton of those already.  RFC 5139 (of which I'm an
author, for my sins), RFC 6351 (XML vCard), just to start with.

--Martin


[1] I guess you could say that the schema isn't normative, and it's
just illustrative.  But that is contrary to common practice and would
require a LOT more text for the document to make any sense, because
you would end up relying much more on the text having a normative
description of elements.  So I'm assuming here that implementations
will be allowed to reject inputs that fail schema validation.

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