[regext] Review of draft-ietf-regext-dnsoperator-to-rrr-protocol-04

[Patrick Mevzek]

Hello authors,

Please find below my review of your draft.
It mixes spellings/phrasing fixes and more formal questions/problems.

* The title itself does not look like to me specific enough to the goal.
Even more so as you finish the abstract with:
"This same protocol can be used by Registrants"
So it is not a "Third Party DNS Operator to ..." but something like a
"Non-Registrar to ..."

In short I am not good at this but I believe a better name can be found.

Also further down you say:
" For the purposes of this draft, a third-party DNS Operator is any DNS
   Operator responsible for a zone, where the operator is neither the
   Registrant nor the Registrar of record for the delegation."

So at the end of the day it is not 100% clear if the intent is to be
also used by registrants or not. I believe the whole document should
be more clear on that and state only one case through the whole of it.

* Abstract

I think it would be best to at least have a sentence explaining the goal
before beginning to describe the current situation and its shortcomings.
So that people reading it know where you are going to right at the beginning.

* "The current system does not work well, as there are many types of
   failures that have been reported at all levels in the registration
   model."
It would be useful to be able to provide such examples or even some references,
if they exist. Or at least types of failures, the kind of consequences they 
create
and so what the protocol in the document could have solved.
There is a sentence just after it about that but it gives one vague example 
where
the sentence above has "many types of failures".

* I am not convinced in the use of REST/REST-framework/REST-nomenclature
for the exposed use case.
The fact that all your exchanges (except one) do not need any content in the 
body
(both in request and in reply) - but need multiple explanations in the protocol,
and the fact that your two resources are not really resources handled at the 
server on which the client has any say show that your protocol is just a 
signaling
one (the client signals the server that it has something to do, that happens 
completely
outside of the REST setup) not something really letting clients act on resources
stored on the server.

In fact, about HTTP verbs to use, I would be more inclined to use PUT to 
initiate
the trust (it is an action of creating something) and PATCH for later updates.

However note that using POST/PUT/PATCH has consequences on property like 
idempotence
and security of write operations, whereas a simple GET would work on your case,
since it is a at its core a signaling protocol.
This GET would also even work for token retrieval and would even be the more 
logical
case.

So is the REST setup really providing you any benefit here?

* 2.1 You say CDS and CDNSKEY are like interchangable in the context of the 
protocol,
so I would recommend to change the path of all endpoints in order to not have
cds at the end, nor cdnskey but something more generic that would not be 
ambiguous.
Maybe /dnssec simply ?

In the same train of thought you write later
"the child DNS Operator needs to upload the DS record(s) to the parent."
... but some registries only work (accept from their childs) with DNSKEY data 
where
they generate the DS records themselves.
I recommend you rephrase there and everywhere below in the same context to have
a more generic sentence that would apply to both DS-based and DNSKEY-based 
registries
without having the need to repeat both cases each time.

* 3.1 Identifying The Registration Entity

About the automated discovery of the base URL of the API, did you think
about using SRV records at the parent? And/or URI or NAPTR?

Would also well-known URIs (RFC5785) have something to offer here?
 

* 3.2 "Registration Entities MAY regularly scan the child name servers of
   unsecured delegations for CDS records in order to bootstrap DNSSEC,
   and are advised to do so." 

I have mixed feelings about the "are advised to do so." part for various 
reasons.
While I can understand your intent, it seems to come out of the blue here,
even more so as this point is not the core of the document and even further than
that since you stipulate that if they were doing as advised the whole protocol
described in the document would not be needed, except one point.

If you really want to discuss that practice I believe you would need more data
or recommendations like on timings (minimum/maximum periods, hardcoded at 
registry
or depending on zone TTL, etc.)

Also, multiple registries do DNS checks after each change and go forward only
if everything returns OK (from their very specific local list of tests).
There may be a merit to discuss what happens when the child does some 
CDS/CDNSKEY
changes that get automatically picked up by registry (for the one doing it
like you advise) but then the DNS checks fails for whatever reason (example
among many other possible cases: the child publishes a new CDS 

Re: [regext] Request for Working Group Last Call for draft-ietf-regext-allocation-token

[Gould, James]

Patrick,

Thanks for your review and attention on the draft.  You find my responses 
embedded below.
  
—
 
JG



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

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

Verisign.com  

On 12/20/17, 12:13 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

Hello James,

Just following on the remaining points:

>> This is not clear technically: The allocation token MAY
>>be returned to an authorized client for passing out-of-band to a
>>client that uses it with an EPP transform command.
>> 
>> Two clients seem defined here, are they the same one or not? If not,
>> what is the difference?
>
> How about
> modifying it to “The allocation token MAY be returned to an authorized
> client (e.g., auction provider) for passing out-of-band to another client
> (e.g., registrant) that uses it with an EPP transform command.”?

I prefer that, indeed.

It has been incorporated.

>> 3.1.1
>> There is a gap between the feature here and the introduction.
>> The introduction says:
>> "authorization to
>>allocate an object using one of the EPP transform commands
>>including
>>create, update, and transfer."
>> 
>> (and this sentence is not clear by itself, why is an update or a
>> transfer
>> now an allocation?)
> 
> It depends on the approach that the registry takes in allocating domain
> names that may be premium.  One approach is to have them defined in a
> reference list, which would mean that the create command would be the
> allocation command.  Another approach is to hold the domain in the domain
> table and to have the registry or another account be the sponsoring
> client, which would mean that the update (new command) or transfer
> commands could be used for allocation.  The protocol supports passing the
> allocation token to any one of the transform commands, where the most
> likely use case is use of the create command for allocation.  

Part of the above should be in the document to make things clearer.
I could see things about the transfer, but I am still not convinced
that domain names could spring into existence from an update command.
If this does not reflect existing use cases and if noone presses for it,
it might be better to just drop the part about the update?

Your original comment is associated with section 3.1.1 (check command 
extension), which is associated with the ability to provision (allocation) an 
object using the  command.  The extension in section 3.1.1 does not 
define any command (e.g., allocation check), so it is exclusively associated 
with the create command.  The use of the allocation token extension for the 
create, update, and transfer commands is covered in the respective sections.  
In the case of update, the allocation token is used for an extension of an 
empty update, which would be used to define a new command (e.g., allocate, 
release).  The allocation token can be used to allocate an object using 
multiple transform commands, but the draft does not intend to dictate which one 
must be used.  The most likely use case is use of the create command, but I 
want to ensure that the allocation token can be used to meet current and future 
server policy.  


>> When doing domain:info, is the allocation token returned the one used
>> to do the create? Or is it the one to be used to do a transfer or
>> update?
> 
> The extension of the info command / response is an alternative mechanism
> for the “authorized client” (e.g., auction provider) to get the
> allocation token value.  

This confuses me a little: how can the authorized client being in your 
sentence the auction provider get the allocation token that way as it would 
mean it is an EPP client that connects to the registry? Also since you can do a 
domain:info only on a domain name that exists, how
can you expect to retrieve data there (the allocation token) that would be 
needed to create the domain name? I see that this could be for the transfer or 
update cases, but I'm no fan
of those.

Forget about my reference to the auction provider, the language as defined in 
the draft provides the ability to retrieve the allocation token for allocated 
objects, which would be past tense.  You are correct that the object must exist 
and the extension of the info command is only meant for an authorized client to 
retrieve the object information along with the allocation token used.  

I know you said they were used in the past. But then it must be clear I 
think
if your document is Informational and writes down what happens on the field 
just for historic information 

Re: [regext] RDAP-JCR -04

[Mario Loffredo]

Hi Andy,

Il 21/12/2017 15:07, Andrew Newton ha scritto:

Mario,


On Tue, Dec 19, 2017 at 5:23 AM, Mario Loffredo
 wrote:

1) I think there is a typo in $nameserver_mixin declaration

"ip6" : [ ipv6 ? ] ? should be "v6" : [ ipv6 ? ] ?

I agree. Fixed...


2)  It seems to me that the @{unordered} annotation of $vcard definition is
not compliant with what it states in RFC6350 (section 6.7.9.) and RFC7095
(section 3.3.1.1.).
The properties in the vCard array can appear in any order but "version" must
be the first one anyway.

Actually, it's worse than that. After reviewing jCard again I've
changed the definition to:

; See RFC 7095
$vcard = [
[ "version", {}, "text", "4.0" ],
[ /^((?!fn).)*$/, $property_attributes ] *,
[ "fn", {}, "text", string ],
[ string, $property_attributes ] *
]

$property_attributes = (
   { /.*/:any * },
   $property_type,
   ( string | [ ( string | [ string * ] ) * ] )
)

$property_type =: (
   "text" |
   "uri" |
   "date-time" |
   "date-and-or-time" |
   "timestamp" |
   "boolean" |
   "integer" |
   "float" |
   "utc-offset" |
   "language-tag" |
   /^x-.*/
)

Annoying but it seems to work.

I've made the changes in the git repo, but I will wait to see if there
is any other feedback before issuing an -05 of the draft.


I am aware that jCard definition is a trouble.
I think that if you want to really use RDAP-JCR rules to strictly 
validate RDAP responses, you should provide a more comprehensive (but, 
unfortunately, much more annoying) description of jCard.
Since jCard is not used only in RDAP, you can think of reporting it in a 
separate document.


Regards
Mario


Thanks for your help.

-andy

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



--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: mario.loffr...@iit.cnr.it
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo

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

Re: [regext] RDAP-JCR -04

[Andrew Newton]

Mario,


On Tue, Dec 19, 2017 at 5:23 AM, Mario Loffredo
 wrote:
> 1) I think there is a typo in $nameserver_mixin declaration
>
> "ip6" : [ ipv6 ? ] ? should be "v6" : [ ipv6 ? ] ?

I agree. Fixed...

> 2)  It seems to me that the @{unordered} annotation of $vcard definition is
> not compliant with what it states in RFC6350 (section 6.7.9.) and RFC7095
> (section 3.3.1.1.).
> The properties in the vCard array can appear in any order but "version" must
> be the first one anyway.

Actually, it's worse than that. After reviewing jCard again I've
changed the definition to:

; See RFC 7095
$vcard = [
   [ "version", {}, "text", "4.0" ],
   [ /^((?!fn).)*$/, $property_attributes ] *,
   [ "fn", {}, "text", string ],
   [ string, $property_attributes ] *
]

$property_attributes = (
  { /.*/:any * },
  $property_type,
  ( string | [ ( string | [ string * ] ) * ] )
)

$property_type =: (
  "text" |
  "uri" |
  "date-time" |
  "date-and-or-time" |
  "timestamp" |
  "boolean" |
  "integer" |
  "float" |
  "utc-offset" |
  "language-tag" |
  /^x-.*/
)

Annoying but it seems to work.

I've made the changes in the git repo, but I will wait to see if there
is any other feedback before issuing an -05 of the draft.

Thanks for your help.

-andy

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