[regext] AD Review: draft-ietf-regext-rdap-object-tag

[Adam Roach]

I've reviewed the document draft-ietf-regext-rdap-object-tag in 
preparation for
placing it into IETF last call. The mechanism and document generally 
look good

and useful; however, I have some concerns about its URL synthesis.

The mechanical synthesis of URLs as described in this document 
contravenes the

requirements of BCP 190, section 2.3. Ordinarily, I would consider this a
showstopper and ask the working group to adjust handling to match BCP 190
requirements (e.g., using RFC 6570 URI Templates). Because this 
specification
simply builds upon RFC 7484 techniques for performing URI synthesis, 
however,

forcing such a change would result in an incongruity that I understand might
cause deployment issues.

Nonetheless, I request that the working group consider whether the use of
something like RFC 6570 would be appropriate for the mechanism described 
this
document. Please also understand that other area directors may note and 
object

to this type of URL synthesis during IESG processing. Chairs: please let me
know when you believe working group consideration of this issue is complete.

---

I also have one question about an example in section 2:

>  For example, if the base RDAP URL
>  "https://example.com/rdap/; is associated with service provider
>  "" in an IANA registry, an RDAP client will parse a tagged entity
>  identifier "-" into distinct handle ("") and service
>  provider ("") identifiers.  The service provider identifier
>  "" is used to query an IANA registry to retrieve the base RDAP
>  URL "https://example.com/rdap/".  The base RDAP URL is concatenated
>  to the entity handle to create a complete RDAP query path segment of
>  "https://example.com/rdap/entity/-;.

I read the text as calling for implementors to concatenate "-" 
to the
end of the IANA-registered base URL ("https://example.com/rdap/;), 
resulting in

"https://example.com/rdap/-;. The example instead shows
"https://example.com/rdap/entity/-YYY;. Is the inclusion of "entity/" in
this example an error?


Thanks for the work everyone has done on this document.

/a

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

Re: [regext] REGEXT Interim Meeting

[Gould, James]

Roger,

I preparation for the Interim Meeting, I did a deeper dive into the Validate 
draft, and I have the following feedback:


  1.  I don’t see the purpose of the  element in the check 
command.  Initially, I thought the  may support a list within a 
list (e.g., ), but that is not the case.  There is also a 
little confusion with the use of  in both the check command and 
response.  My recommendation is to remove the  element from the 
check command and simply move all its sub-elements to sub-elements of the 
 element.
  2.  Is the extension meant to validate the contact details of existing 
contacts by contact id and also non-existent contacts based on the contact 
details, by contact type and by tld?
 *   If both cases are true, then wouldn’t you have a choice of referencing 
the contact by identifier for an existing contact or defining the contact 
attributes for a non-existing contact?
 *   Also, what if you desire to use the same contact information for 
multiple contact types for a tld?

  i.  Do you 
need to replicate the same attributes for each contact type?

ii.  It may be 
better to define a single contact (existing with contact identifier) or contact 
attributes for non-existing with the list of contact types.  I imagine that you 
always want to validate a contact within the scope of a tld.

  1.  I view definition of only the check command and response with many 
contacts and with extensibility via the kv elements as somewhat non-optimal.  
Other options include:
 *   Instead of supporting multiple contacts in an individual command, why 
not support the check or info of an individual contact with attribute 
extensibility via command / response extensions.  Yes, you can validate only a 
single contact with multiple target types and a tld at a time, but you get to 
use existing contact command / response extensions to define the additional 
contact attributes without having to use key / value pairs.
 *   Create a validate command / response extension of the contact mapping 
that extends the contact create to function as a no-op with the additional 
attributes used to validate usage of the contact (e.g., object - domain, 
contact types, tld), which would define a validate contact validate create 
command.  The contact info could have been extended by the validate extension 
to function as a validate usage command with the usage attributes consistent 
with the contact validate create command (e.g., object – domain, contact types, 
tld).  In this case, the contact commands can be directly extended by the 
validate extension.
  2.  Each element needs to be fully described.  I include some examples below:
 *element does not define the required “contactType” 
or “tld” attributes.
 *   There is no description of any of the  sub-elements in 
the check command or response.
  3.  Wouldn’t be better to include a required “valid” attribute in the check 
response  element with an optional reason and reason language 
similar to the domain check response?  I’m not sure if there is a real need to 
define a whole list of validity errors using the list of  
elements.  It may be good enough to short circuit the validation by simply 
saying yes or no and if no a human readable reason.  There would be no need for 
the  element or the  elements.
  4.  I don’t recommend directly referencing the 
urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a direct dependency 
to inclusion of the contact XML schema and namespace for a subset of the 
elements that are really specific to the validate mapping.  I would prefer for 
the validate XML schema to stand on its own by only referring to epp and 
eppcom, with no cross references to contact.  This would mean copying and 
pasting elements directly from the contact XML schema into the validate XML 
schema, which is an inconvenient, but makes it easier to implement.

—

JG

[cid:image001.png@01D255E2.EB933A30]

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

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

Verisign.com

From: regext  on behalf of Roger Carney 

Date: Friday, May 4, 2018 at 12:33 PM
To: Registration Protocols Extensions 
Subject: [EXTERNAL] [regext] REGEXT Interim Meeting


Good Morning,



I would like to invite everyone to an interim meeting Tuesday June 5th at 16:00 
UTC for 60 minutes.



We plan to focus the discussion around two topics:



Agenda
1.   Validate draft (comments, concerns, implementations)
2.   Registry Mapping
a.   Continue the lively discussion that was started in London
b.   Policy Extension Review: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.



We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.



Please reply to the 

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Gould, James]

To add to Roger’s note about the Registry Mapping, I posted the Launch Phase 
Policy Extension 
(draft-gould-regext-launch-policy).
  This is the first Registry Mapping command / response extension that defines 
the policies (MAYs, SHOULDs, and options) associated with the Launch Phase 
Extension (RFC 8334).  There was interest 
in discovering the launch phase schedule in the working group, which is fully 
supported by the Launch Phase Policy Extension.

As a co-author of the Launch Phase Extension (RFC 
8334), I found it extremely useful to 
formally define the MAYs, SHOULDs, and options of the RFC into a draft that can 
be defined by the server and consumed by a client.

Please review both the Registry Mapping and the Launch Phase Policy Extension 
and provide any feedback on the list.

Thanks,

—

JG

[cid:image001.png@01D255E2.EB933A30]

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

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

Verisign.com

From: regext  on behalf of Roger Carney 

Date: Friday, June 1, 2018 at 11:17 AM
To: regext 
Subject: [EXTERNAL] Re: [regext] New Version Notification for 
draft-gould-carney-regext-registry-00.txt


Good Morning,



We have been talking about Registry Mapping for over a year now and here is the 
official first 
draft.



Please take a read and let the discussions flow! We will be having an interim 
meeting
 next Tuesday (June 5th at 16:00 UTC) and one of the two agenda items is a 
discussion of this idea/draft.





Thanks

Roger





-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, May 31, 2018 3:12 PM
To: Roger D Carney ; Lin Jia ; James 
Gould ; Roger D Carney ; Jody Kolker 

Subject: New Version Notification for draft-gould-carney-regext-registry-00.txt





A new version of I-D, draft-gould-carney-regext-registry-00.txt

has been successfully submitted by James Gould and posted to the IETF 
repository.



Name:  draft-gould-carney-regext-registry

Revision:  00

Title:  Registry Mapping for the Extensible Provisioning 
Protocol (EPP)

Document date:   2018-05-31

Group:  Individual Submission

Pages:   61

URL:
https://www.ietf.org/internet-drafts/draft-gould-carney-regext-registry-00.txt

Status: 
https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/

Htmlized:   
https://tools.ietf.org/html/draft-gould-carney-regext-registry-00

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry





Abstract:

   This document describes an Extensible Provisioning Protocol (EPP)

   mapping for provisioning registry zones (e.g. top-level domains) in a

   Domain Name Registry.  The attributes of a registry zone include the

   features and policies of the registry zone.









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


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