Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-05.txt

[Patrick Mevzek]

Hi Scott,

On Tue, Oct 24, 2017, at 14:04, Hollenbeck, Scott wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > Title   : Registration Data Access Protocol (RDAP) Object
> > Tagging

One comment on the draft itself.
While I think I can understand the need, I still feel very uneasy by the
solution of tackling two values together by a given separator.
In fact it shows even in the history of the document, where you had to
change the separator multiple times.

Even beside the fact that tilde looks like a dash inferior lookalike, I
think that you would get problems whatever separator value is used. This
shows in many sentences of the text.

Were other solutions already explored?

Like one the following two:
- instead of adding the service provider to the current handle, why not
having a new RDAP attribute, like handle_provider to store only this
value?
- or, even more radical, having the current handle element not a string
anymore but a dictionary/map with one or two keys, like value
(mandatory, would be the current text in the element) and provider
(optional).

Obviously these 2 solutions involve schema changes so are more difficult
to put in place,
but I see them are more future-proof.

Sorry if I'm late to the game and I revisit already rehashed grounds.

Regards,

-- 
  Patrick Mevzek
  p...@dotandco.com

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

Re: [regext] Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)

[Eric Rescorla]

On Mon, Dec 11, 2017 at 3:17 PM, Gould, James  wrote:

> Eric,
>
>
>
> In reviewing the threads, I noticed that I missed your open question “How
> do you say in the protocol that no validation is wanted.”
>
>
>
> I’ll lead with restating that the requirement for validation depends on
> the launch phases used by the server and the models chosen by the server
> for those launch phases, which is referred to as server policy.  The launch
> phases and models chosen by the server is currently not defined by the
> protocol and currently needs to be communicated out-of-band.  The WG is
> going to discuss a framework (Registry Mapping and Registry Policy
> Extensions) to communicate the server policies in-band to EPP that should
> include a policy extension for draft-ietf-regext-launchphase (e.g.,
> draft-ietf-regext-launchphase-policy).  The short answer is that the
> protocol may say that no validation is wanted in the future but outside of
> draft-ietf-regext-launchphase.
>
>
OK. Do you think you could add some text saying that validation is
currently required. It confused me.

-Ekr


>
>
Thanks,
>
>
>
> —
>
>
>
> JG
>
>
> [image: id:image001.png@01D255E2.EB933A30]
>
>
> *James Gould *Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271 <(703)%20948-3271>
> 12061 Bluemont Way
> 
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *Eric Rescorla 
> *Date: *Tuesday, December 5, 2017 at 4:40 PM
> *To: *James Gould 
> *Cc: *The IESG , "draft-ietf-regext-launchph...@ietf.org" <
> draft-ietf-regext-launchph...@ietf.org>, Ulrich Wisser ,
> "regext-cha...@ietf.org" , "regext@ietf.org" <
> regext@ietf.org>
> *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on
> draft-ietf-regext-launchphase-06: (with COMMENT)
>
>
>
>
>
>
>
> On Tue, Dec 5, 2017 at 1:34 PM, Gould, James  wrote:
>
> Eric,
>
>
>
> My replies are included below.
>
>
>
> —
>
>
>
> JG
>
>
>
>
>
> *James Gould *Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271 <(703)%20948-3271>
> 12061 Bluemont Way
> 
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *Eric Rescorla 
> *Date: *Tuesday, December 5, 2017 at 4:02 PM
> *To: *James Gould 
> *Cc: *The IESG , "draft-ietf-regext-launchph...@ietf.org" <
> draft-ietf-regext-launchph...@ietf.org>, Ulrich Wisser ,
> "regext-cha...@ietf.org" , "regext@ietf.org" <
> regext@ietf.org>
> *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on
> draft-ietf-regext-launchphase-06: (with COMMENT)
>
>
>
>
>
>
>
> On Tue, Dec 5, 2017 at 12:02 PM, Gould, James  wrote:
>
> Eric,
>
>
>
> Thanks again, I provide answers embedded below.
>
>
>
> —
>
>
>
> JG
>
>
>
>
>
> *James Gould *Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271 <(703)%20948-3271>
> 12061 Bluemont Way
> 
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *Eric Rescorla 
> *Date: *Monday, December 4, 2017 at 6:39 PM
> *To: *James Gould 
> *Cc: *The IESG , "draft-ietf-regext-launchph...@ietf.org" <
> draft-ietf-regext-launchph...@ietf.org>, Ulrich Wisser ,
> "regext-cha...@ietf.org" , "regext@ietf.org" <
> regext@ietf.org>
> *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on
> draft-ietf-regext-launchphase-06: (with COMMENT)
>
>
>
>
>
>
>
> On Mon, Dec 4, 2017 at 3:03 PM, Gould, James  wrote:
>
> Eric,
>
> Thank you for the review.  Below are my answers to your feedback.
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> 
> Reston, VA 20190
>
> Verisign.com 
>
> On 11/29/17, 2:20 PM, "Eric Rescorla"  wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-regext-launchphase-06: 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-launchphase/
>
>
>
> 

Re: [regext] Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)

[Gould, James]

Eric,

In reviewing the threads, I noticed that I missed your open question “How do 
you say in the protocol that no validation is wanted.”

I’ll lead with restating that the requirement for validation depends on the 
launch phases used by the server and the models chosen by the server for those 
launch phases, which is referred to as server policy.  The launch phases and 
models chosen by the server is currently not defined by the protocol and 
currently needs to be communicated out-of-band.  The WG is going to discuss a 
framework (Registry Mapping and Registry Policy Extensions) to communicate the 
server policies in-band to EPP that should include a policy extension for 
draft-ietf-regext-launchphase (e.g., draft-ietf-regext-launchphase-policy).  
The short answer is that the protocol may say that no validation is wanted in 
the future but outside of draft-ietf-regext-launchphase.

Thanks,

—

JG

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

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

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

Verisign.com

From: Eric Rescorla 
Date: Tuesday, December 5, 2017 at 4:40 PM
To: James Gould 
Cc: The IESG , "draft-ietf-regext-launchph...@ietf.org" 
, Ulrich Wisser , 
"regext-cha...@ietf.org" , "regext@ietf.org" 

Subject: [EXTERNAL] Re: Eric Rescorla's No Objection on 
draft-ietf-regext-launchphase-06: (with COMMENT)



On Tue, Dec 5, 2017 at 1:34 PM, Gould, James 
> wrote:
Eric,

My replies are included below.

—

JG

[cid:image002.png@01D372AC.5B5D2A10]

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

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

Verisign.com

From: Eric Rescorla >
Date: Tuesday, December 5, 2017 at 4:02 PM
To: James Gould >
Cc: The IESG >, 
"draft-ietf-regext-launchph...@ietf.org"
 
>,
 Ulrich Wisser >, 
"regext-cha...@ietf.org" 
>, 
"regext@ietf.org" 
>
Subject: [EXTERNAL] Re: Eric Rescorla's No Objection on 
draft-ietf-regext-launchphase-06: (with COMMENT)



On Tue, Dec 5, 2017 at 12:02 PM, Gould, James 
> wrote:
Eric,

Thanks again, I provide answers embedded below.

—

JG

[cid:image003.png@01D372AC.5B5D2A10]


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

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

Verisign.com

From: Eric Rescorla >
Date: Monday, December 4, 2017 at 6:39 PM
To: James Gould >
Cc: The IESG >, 
"draft-ietf-regext-launchph...@ietf.org"
 
>,
 Ulrich Wisser >, 
"regext-cha...@ietf.org" 
>, 
"regext@ietf.org" 
>
Subject: [EXTERNAL] Re: Eric Rescorla's No Objection on 
draft-ietf-regext-launchphase-06: (with COMMENT)



On Mon, Dec 4, 2017 at 3:03 PM, Gould, James 
> wrote:
Eric,

Thank you for the review.  Below are my answers to your feedback.

—

JG



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

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

Verisign.com 

On 11/29/17, 2:20 PM, "Eric Rescorla" > 
wrote:

Eric Rescorla has entered the following ballot position for
draft-ietf-regext-launchphase-06: 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, 

Re: [regext] Artart telechat review of draft-ietf-regext-launchphase-06

[Gould, James]

Harald,

Thanks, as before my responses are embedded below.
  
—
 
JG



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

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

Verisign.com  

On 12/11/17, 6:47 AM, "Harald Alvestrand"  wrote:

Den 06. des. 2017 20:18, skrev Gould, James:
> Harald, 
> 
> Thank you for your review and feedback, below are my answers to your 
feedback.
>   

Thanks for the quick response!
Deleting all below where you said "yes, we'll do that" and where I have
no further comment.




> 2.4
> 
> This sentence: "if a launch status is supported and the launch status
> is not one of the final statuses, including the "allocated" and
> "rejected" statuses." makes equal grammatical sense if "allocated" and
> "rejected" are final statuses or non-final statuses. Could be clearer.
> 
> Would the use of parenthesis work better as in the sentence below?
> “if a launch status is supported and the launch status is not one of the 
final statuses ("allocated" and "rejected").”

This is much more readable, thank you.

> It is not clear what causes the transition from "validated" to
> "pendingAllocation". It is also not clear if a transition possibility
> exists straight from "validated" to "allocated" for the case where no
> external process is needed.
> 
> The transitions between the statuses is up to the server policy.  There 
is no pre-defined timeframe that a domain must remain in a status.  In general, 
the processing is done asynchronously and based on a batch schedule, where a 
batch may validate thus putting the domains in the “validated” status.  A 
separate batch may prepare the domains for the allocation process thus putting 
the domains in the “pendingAllocation” status.  Finally, a batch will allocate 
the domains thus putting the domains in either the “allocated” or the 
“rejected” status.  
> 
> Yes, there can be a server policy that supports moving domains to the 
“validated” or “invalid” status in one step and then deciding on the allocation 
in a separate step synchronously.  In this case, there is no need for the 
“pendingAllocation” status.  
>   
> One scenario is that a pendingValidation domain may skip the validated 
status and transition immediately to the pendingAllocation status, or 

In that case, it would be clearer if the drawing was preceded by a
sentence saying: "The transitions between states is a matter of server
policy. One possible set of permitted transitions is given in the
diagram below".

This will make it clear to people that this isn't a total map of
possible transitions.

Ok, I’ll add a preamble to the diagram that reads “The transitions between the 
states is a matter of server policy.  This diagram defines one possible set of 
permitted transitions.”  Does this work?

> 
> 2.5
> 
> "A Launch Application MUST and a Launch Registration MAY" would be
> clearer if there were commas around "and a Launch Registration MAY".
> 
> How about trying to fix the sentence overall, with the following two 
sentences?
> 
> “A Launch Application MUST be handled as an EPP domain name object, as 
specified in RFC 5731 [RFC5731], with the "pendingCreate" status and with the 
launch status values defined in Section 2.4.  A Launch Registration MAY be 
handled as an EPP domain name object, as specified in RFC 5731 [RFC5731], with 
the "pendingCreate" status and with the launch status values defined in Section 
2.4.” 
> 

This looks good to me.


> 2.6.3
> 
> This section's sentence structure is unclear due to a missing comma
> before "or the ".
> 
> I believe the fix here is to remove “either” and the comma from the 
sentence as in:
> 
> “Digital signatures MAY be used by the server to validate the mark 
information when using the "signed mark" validation model with the 
 (Section 2.6.3.1) element or the  
(Section 2.6.3.2) element.”
> 
> Do you agree that this is better?

I'm still a bit confused about where the beginning of the sentence is
that ends with "or". Is it obvious to everyone that the "signed mark"
validation model is used both with  and with
? It's possible to read this as there being two
validation models, one that is called "signed mark and uses
, and another one that's not named, but uses
.

The  is the  encoded (e.g., Base64), 
where both are directly related to the “signed mark” validation model.  The 
“signed mark” validation model is defined in 2.6 applies to the use of the 
 and the  elements.  The description in 
2.6.3 should match the description in 2.6 with using an “and” instead of an 
“or”.  It would be more consistent to read