Re: [regext] regarding draft-ietf-regext-rdap-sorting-and-paging and draft-ietf-regext-rdap-partial-response

[James Galvin]

The Chairs have reviewed these last set of changes and believe them all 
to be editorial.


As there have been no objections to resubmitting these documents the 
Chairs will do so shortly.


Thanks to all,

Antoin and Jim




On 19 Jun 2020, at 9:47, James Galvin wrote:


REGEXT WG,

I’m sure you recall that the documents:

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/

Had been previously submitted to the IESG for consideration as 
Proposed Standards on 25 May 2020.  What you may not have noticed is 
that our Area Director reviewed the documents prior to distributing 
them to the entire IESG (this is an ordinary step in the process) and 
requested some editorial changes to the documents prior to their 
consideration for publication.


The authors have revised the documents as requested and now the Chairs 
need to ask the working group to confirm that the proposed changes are 
only editorial and not material.


You can go to the history tab for each document on the data tracker 
and compare the most recent version to any prior version.  The 
following two links will compare the most recent versions to their 
immediately preceding versions directly:


https://www.ietf.org/rfcdiff?url1=draft-ietf-regext-rdap-partial-response-11&url2=draft-ietf-regext-rdap-partial-response-12
https://www.ietf.org/rfcdiff?url1=draft-ietf-regext-rdap-sorting-and-paging-13&url2=draft-ietf-regext-rdap-sorting-and-paging-14

Would you please review these documents prior to COB Thursday, 25 June 
2020?  If you have any concerns with or objections to the changes 
please respond to the list.  If there are no objections the Chairs 
will resubmit the documents to the IESG on Friday, 26 June 2020.


Thanks in advance for your prompt attention,

Antoin and Jim


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

[regext] Publication has been requested for draft-ietf-regext-rdap-partial-response-12

[James Galvin via Datatracker]

James Galvin has requested publication of 
draft-ietf-regext-rdap-partial-response-12 as Proposed Standard on behalf of 
the REGEXT working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/


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

[regext] Publication has been requested for draft-ietf-regext-rdap-sorting-and-paging-14

[Antoin Verschuren via Datatracker]

Antoin Verschuren has requested publication of 
draft-ietf-regext-rdap-sorting-and-paging-14 as Proposed Standard on behalf of 
the REGEXT working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/


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

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

[Thomas Corte (TANGO support)]

Hello James,

thanks for your reply, I'll go back to check out the respective thread.

On 6/25/20 21:40, Gould, James wrote:

> JG - The RFC only specifies that the fee extension needs to be provided to 
> support the create command, so checking the renewal fee is not applicable.   

So, just to be sure, to the following check for a *renew* fee of a
premium domain, the server should respond with avail="0" (as the check
merely asks for a renewal price, not a creation price)?

http://www.w3.org/2001/XMLSchema-instance";>
  

  
premium-a1.tango
  


  

  1

  

e1f8b4cd61f84469436bf16585f976b3
  


While the following check asking for a creation price should be responded
with avail="1"?

http://www.w3.org/2001/XMLSchema-instance";>
  

  
premium-a1.tango
  


  

  1

  

e1f8b4cd61f84469436bf16585f976b3
  


Just trying to clarify this, as the RFC isn't all that clear about which
exact conditions the fee check extension must meet in order to qualify
for a positive availability check of free premium domains.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

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

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

[Gould, James]

Thomas,

The goal is to cover the case of a client not passing the fee extension at all, 
with the assumption that the fee extension would reference the create command.  
It's simpler to make the case based on the existence or non-existence of the 
fee extension in the check command, but there may be cases were the renew fee 
matches the create fee.  It's up to the server to determine whether a 
particular domain will fail on create without the client having the correct 
non-standard fee.  I realize that there are corner cases where the client may 
know the fee, based on assuming that the create fee matches the renew fee, or 
the fees are provided out-of-band to EPP, but to cover the intent of the RFC 
the safest approach is to return avail="0" for a premium domain if the fee 
extension is not passed in the check command.

The server MUST return avail="0" in its response to a  command
for any object in the  command that does not include the
 extension for which the server would likewise fail a
domain  command when no  extension is provided for that
same object. 

-- 
 
JG



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


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

Verisign.com 

On 6/26/20, 9:46 AM, "regext on behalf of Thomas Corte (TANGO support)" 
 wrote:


Hello James,

thanks for your reply, I'll go back to check out the respective thread.

On 6/25/20 21:40, Gould, James wrote:

> JG - The RFC only specifies that the fee extension needs to be provided 
to support the create command, so checking the renewal fee is not applicable.   

So, just to be sure, to the following check for a *renew* fee of a
premium domain, the server should respond with avail="0" (as the check
merely asks for a renewal price, not a creation price)?

http://www.w3.org/2001/XMLSchema-instance";>
  

  
premium-a1.tango
  


  

  1

  

e1f8b4cd61f84469436bf16585f976b3
  


While the following check asking for a creation price should be responded
with avail="1"?

http://www.w3.org/2001/XMLSchema-instance";>
  

  
premium-a1.tango
  


  

  1

  

e1f8b4cd61f84469436bf16585f976b3
  


Just trying to clarify this, as the RFC isn't all that clear about which
exact conditions the fee check extension must meet in order to qualify
for a positive availability check of free premium domains.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org

https://secure-web.cisco.com/1d4W9Y-JRwUyOsQ5LPwv-1m17UOtveZT4o2_R0VWZfpbiTqJanWb6E-ksO15h7ClxoQY3q9NGnpriFo71j-Jz3SWN4WQcemobVYCyNQp3gp_mAdwxpm-wlzqcs8vUSfe2t-A7ZIYAlHo9X9Bx1otNjXIk8Zq-YRdB6RWikXkuNjOFtRnO2RX89P5ciZ5jM7_thR1kE8aILbzhJMq0uWRyPbLAFIAf3ZOwPH5IZ4oUskSUB4se2h6c4ZgbpfMzl0P0ZPvKG2RzjnF3PXa-m62nDg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext


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

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

[Thomas Corte (TANGO support)]

Hello James,

On 6/26/20 16:18, Gould, James wrote:

> but to cover the intent of the RFC the safest approach is to return avail="0" 
> for a premium domain if the fee extension is not passed in the check command.

In my example, the fee extension was passed, but only asking for the
*renew* fee (which may be standard), not for the *create* fee (which may
be non-standard). Based on your answer above, the server would have to
return avail=1" then (because *some* fee extension was passed), however
the client would still be unaware that the create fee is non-standard.

If the "safest approach" is the goal here, it would probably be better
(albeit indeed more implementation effort) to not only require the fee
extension, but to specifically require the fee extension checking the
"create" price, no?

In this case, the RFC text may need a clarification, as it currently
doesn't reflect such a specific requirement. I'm aware this is a rare
corner case, but still one that should be covered.

Best regards,

Thomas


-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany

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

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

[Gould, James]

Thomas,

Yes, to cover the corner case, avail="0" is the best response when the client 
does not include "create" in the fee extension of the check command of a 
premium domain name.  Without knowing the create fee of the premium, the create 
will likely fail, thus avail="0" is the correct answer.  The intent of the 
language in the RFC was to cover the broader case of a client that doesn't pass 
the fee extension at all in the check command, but your corner case is 
applicable.

-- 
 
JG



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


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

Verisign.com 

On 6/26/20, 10:41 AM, "Thomas Corte (TANGO support)"  
wrote:

Hello James,

On 6/26/20 16:18, Gould, James wrote:

> but to cover the intent of the RFC the safest approach is to return 
avail="0" for a premium domain if the fee extension is not passed in the check 
command.

In my example, the fee extension was passed, but only asking for the
*renew* fee (which may be standard), not for the *create* fee (which may
be non-standard). Based on your answer above, the server would have to
return avail=1" then (because *some* fee extension was passed), however
the client would still be unaware that the create fee is non-standard.

If the "safest approach" is the goal here, it would probably be better
(albeit indeed more implementation effort) to not only require the fee
extension, but to specifically require the fee extension checking the
"create" price, no?

In this case, the RFC text may need a clarification, as it currently
doesn't reflect such a specific requirement. I'm aware this is a rare
corner case, but still one that should be covered.

Best regards,

Thomas


-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany



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

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

[Jothan Frakes]

@Tomas  I could see someone submitting a non-conforming fee extension in
the check command to trick the registry into providing basic availability
or taken of a name.

Possible: perhaps
Probable: unlikely

You make a good point that the respective command, especially billable
events, should perhaps check that the appropriate fee extension was sent.
Depending upon the registry implementation, this could theoretically work,
but a registrar would still have to pay the respective registry designated
fee for a create/renew/transfer,

I am working very hard to imagine why someone would go to the trouble of
sending the wrong fee extension with a command if they were going to be
sending one at all.

Jothan Frakes



On Fri, Jun 26, 2020 at 7:47 AM Gould, James  wrote:

> Thomas,
>
> Yes, to cover the corner case, avail="0" is the best response when the
> client does not include "create" in the fee extension of the check command
> of a premium domain name.  Without knowing the create fee of the premium,
> the create will likely fail, thus avail="0" is the correct answer.  The
> intent of the language in the RFC was to cover the broader case of a client
> that doesn't pass the fee extension at all in the check command, but your
> corner case is applicable.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com
> 
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
> On 6/26/20, 10:41 AM, "Thomas Corte (TANGO support)" <
> thomas.co...@knipp.de> wrote:
>
> Hello James,
>
> On 6/26/20 16:18, Gould, James wrote:
>
> > but to cover the intent of the RFC the safest approach is to return
> avail="0" for a premium domain if the fee extension is not passed in the
> check command.
>
> In my example, the fee extension was passed, but only asking for the
> *renew* fee (which may be standard), not for the *create* fee (which
> may
> be non-standard). Based on your answer above, the server would have to
> return avail=1" then (because *some* fee extension was passed), however
> the client would still be unaware that the create fee is non-standard..
>
> If the "safest approach" is the goal here, it would probably be better
> (albeit indeed more implementation effort) to not only require the fee
> extension, but to specifically require the fee extension checking the
> "create" price, no?
>
> In this case, the RFC text may need a clarification, as it currently
> doesn't reflect such a specific requirement. I'm aware this is a rare
> corner case, but still one that should be covered.
>
> Best regards,
>
> Thomas
>
>
> --
> TANGO REGISTRY SERVICES® is a product of:
> Knipp Medien und Kommunikation GmbH
> Technologiepark Phone: +49 231 9703-222
> Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
> D-44227 Dortmund   E-Mail: supp...@tango-rs.com
> Germany
>
>
>
> ___
> 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] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

[Thomas Corte (TANGO support)]

Hello Jothan,

On 6/26/20 17:15, Jothan Frakes wrote:

> @Tomas  I could see someone submitting a non-conforming fee extension in
> the check command to trick the registry into providing basic availability
> or taken of a name.
> 
> Possible: perhaps
> Probable: unlikely
> 
> You make a good point that the respective command, especially billable
> events, should perhaps check that the appropriate fee extension was
> sent.  Depending upon the registry implementation, this could
> theoretically work, but a registrar would still have to pay the
> respective registry designated fee for a create/renew/transfer,   

Sure, the subsequent domain create attempt would still fail if the wrong
command was sent in the extension, even if the availability check was
"tricked" into confirming availability.

> I am working very hard to imagine why someone would go to the trouble of
> sending the wrong fee extension with a command if they were going to be
> sending one at all. 

Agreed, it's more work to get this wrong than right. We'll go with the
John's lax interpretation in our implementation and will report avail="1"
for premium names as long as the check command contains *any* fee
extension whatsoever.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

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

Re: [regext] [Ext] Alissa Cooper's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS)

[Barry Leiba]

Alissa, will you please check the current version of the data-escrow
document < https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/
> and see if Gustavo's changes address your concern?  And if not,
please work with Gustavo to get it sorted out.  Thanks.

Barry


On Wed, May 13, 2020 at 3:08 PM Gustavo Lozano  wrote:
>
> Thank you Alissa,
>
> Comments inline prefixed with GL-
>
> Regards,
> Gustavo
>
> On 4/9/20, 06:48, "regext on behalf of Alissa Cooper via Datatracker" 
>  wrote:
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-regext-data-escrow-07: 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.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=6KotPsZrrzq2bpn2K-y1yF2urMkEJOz0OITxaBun2Xs&s=hcpPqoVjnm9-aoinq9ndolZqJuxMFPlrXAwKp9NNEi4&e=
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dregext-2Ddata-2Descrow_&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=6KotPsZrrzq2bpn2K-y1yF2urMkEJOz0OITxaBun2Xs&s=tOGRD4dNp47NFz1LacDypLNFM0wMf5om9bc9_HKbQMg&e=
>
>
>
> --
> DISCUSS:
> --
>
> I support Benjamin's DISCUSS and Roman's last DISCUSS point.
>
> GL - The latest version of the draft covers the feedback from Roman (DISCUSS 
> cleared), and I also believe Benjamin's feedback (waiting for his response)
>
> Regarding Section
> 11, there are often legal agreements in place that govern all sorts of 
> things
> about how protocols transfer data between parties, but those are not the 
> main
> thing to document in an RFC. Section 11 should be documenting the 
> technical
> considerations for how to protect the data that may be escrowed.
>
> GL - draft-ietf-regext-data-escrow describes a standardized format for 
> escrow, and it's not a document specifying escrow services (i.e., no 
> definition of a transport protocol, signaling mechanism, etc.). Section 11 
> has been strengthen based on the comments from other IESG's members, and I 
> believe it's in good shape now.
>
> Here are the differences between 07 and 08, and 08 and 09:
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-08.txt
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-09.txt
>
> I think that a draft describing the best security / operational practices for 
> escrow service providers could be a good idea. In the case of the gTLD space, 
> there is no urgency for such a document, as the security / operational 
> requirements are detailed in legal agreements.
>
> Hopefully, this clarifies my previous comments.
>
> ___
> regext mailing list
> regext@ietf.org
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_regext&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=6KotPsZrrzq2bpn2K-y1yF2urMkEJOz0OITxaBun2Xs&s=gtb7G2HcGVH0Nkn1jQNw3zcDejr56jw5emEs2RK8ilw&e=
>

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