Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

[Hollenbeck, Scott]

> -Original Message-
> From: Gould, James 
> Sent: Thursday, December 9, 2021 11:59 AM
> To: Hollenbeck, Scott ;
> ietf=40antoin...@dmarc.ietf.org ; regext@ietf.org
> Subject: [EXTERNAL] Re: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-
> eai-04
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> Scott,
>
> Thanks for the review and feedback.  I provide responses to your feedback
> embedded below.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com  B4BA42740803/jgo...@verisign.com>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com  web.cisco.com/1bUEhaRz5CoSQPd4colm8eTGE5D6zPQvtrYPAzQf9pUSXnqD
> Nq7mmnlZ8At92joPzY5DkJdQiiPe1mlyvgzDAdDz_shcqHzSugkfXA2qX9z7aQp0
> 6ld-
> LnwMzxo2VGkwqFH5gLrI7qSYQlgj4Unll4AIUd6ALSZ38i2kjYqgA0AnBBjaJEVg7
> yUIN-
> P8bpFGxQgN__tWour_sxUBBx2vUcVpmrR7SUG6UsUo5U3gb_YbWCYcRn8b
> 4Rl06BQIL8B8k/http%3A%2F%2Fverisigninc.com%2F>
>
> On 12/6/21, 9:18 AM, "regext on behalf of Hollenbeck, Scott"  boun...@ietf.org on behalf of shollenbeck=40verisign@dmarc.ietf.org>
> wrote:
>
>
> A few questions/comments:
>
> Section 6: We need to provide the rationale for that SHOULD (Registries
> SHOULD validate the domain names in the provided email addresses). What
> does "validate" mean? For syntax? For reachability?
>
> JG - This is associated with validating the syntax.  The goal is to ensure 
> that
> the domain name, whether an ASCII or IDN domain name is a syntactic valid
> domain name the may be reachable.  Would it help to modify this to read
> "Registries SHOULD validate the syntax of the domain names in the provided
> email addresses so they may be reachable."?

[SAH] Syntax validity is no guarantee of reachability. The only way to confirm 
that an email address "works" is to send email to that address and confirm 
that it's delivered. I don't think we want to suggest that registries should 
start sending out email delivery tests, so maybe something like this instead:

" Registries SHOULD ensure that the provided email addresses are syntactically 
valid to reduce the risk of future usability errors."

> Section 7: What's significant about "eai-0.3"? The "0.3" part doesn't 
> track to
> the current version of the draft; perhaps "1.0" would be better now. See 
> also
> Section 5.2.
>
> JG - Yes, the namespace will be changed to "eai-1.0" once it passes WGLC
> similar to what has happened in past EPP extensions with pointed
> namespaces.

[SAH] OK.

> Section 8: It might be helpful to add more text to explain why 
> "Registries
> MAY apply extra limitation to the email address syntax". Why might they
> want to do that? It seems a little unusual to say that they MAY do 
> something,
> but in the next sentence say, "These limitations are out of scope of this
> document".
>
> JG - Agreed, this does not look to add value.  Do you believe the
> Implementation Considerations section should be removed, since the
> contents really don't provide any material considerations?

[SAH] Yes, that's probably a good idea.

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

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

[Mario Loffredo]

+1

Mario

Il 06/12/2021 14:45, Antoin Verschuren ha scritto:

Dear Working Group,

The authors of the following working group document have indicated that it is 
believed to be ready for submission to the IESG for publication as a standards 
track document:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/

This WG last call will end at close of business, Monday, 20 December 2021.

Please review this document and indicate your support (a simple “+1” is 
sufficient) or concerns with the publication of this document by replying to 
this message on the list.

The document shepherd for this document is Jody Kolker.

Regards,

Jim and Antoin





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


--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

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

Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt

[Antoin Verschuren]

Hi All,

I’m glad that my bad phrasing at least got some action into this discussion.
I didn’t mean to say that we can’t have 2 standards, but we should at least 
have clarity on the status of this document.
Because the original document title was "jcard-deprecation 
",
 and the introduction still talks about the intent and transition mechanisms to 
replace jCard, we can be a bit clearer that jsContact is a second standard, at 
least until jCard can be deprecated from support in RDAP after jsContact is 
sufficiently supported.

When we all agree jsContact is a second standards track document not intended 
to deprecate jCard just yet today, then that’s fine.
If we don’t get feedback this document should have a different status than 
standards track, then the chairs will add that intended status next week.

Which leaves the remaining questions Mario posted in his original message.

- -- 
Antoin Verschuren








> Op 8 dec. 2021, om 14:53 heeft Gould, James 
>  het volgende geschreven:
> 
> I view the jscontact is a valid use case for a standards track RDAP 
> extension.  We have many similar use cases for standards track extensions in 
> EPP, where the RFCs couldn't envision a feature or an approach that comes up 
> later.  The jscontact draft needs to be defined as an RDAP extension that is 
> optional, with the appropriate signaling, and with transition considerations 
> to support a transition from the jCard defined in RFC 9083 to JSContact 
> defined in the extension.  I don't foresee that support for jCard will go 
> away, but that JSContact can be become an alternative and potentially a 
> preferred format for the RDAP contact data.  As Scott points out, supporting 
> multiple formats can add complexity, but I believe that is a known cost to 
> progress.  
> 
> -- 
> 
> JG
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com  
>  >
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com   >
> 
> On 12/8/21, 5:31 AM, "regext on behalf of Gavin Brown" 
> mailto:regext-boun...@ietf.org> on behalf of 
> gavin.br...@centralnic.com > wrote:
> 
> 
>On 8 Dec 2021, at 09:55, Mario Loffredo  > wrote:
>> 
>> 
>> 
>> Il 07/12/2021 14:42, Marc Blanchet ha scritto:
>>> 
 Le 7 déc. 2021 à 08:35, Hollenbeck, Scott 
 >>> > a écrit :
 
 We can *certainly* do that, Mario. It’s the option I support because there 
 is a cost to replace a jCard implementation once it’s been implemented and 
 deployed. Make it an optional extension and let server operators decide 
 if/when they want to make the change.
 
 I note that this will make life more difficult for client implementors 
 because they’ll have to support both formats.
>>> 
>>> But the genie is already out of the bottle… I.e. if one have done a client 
>>> implementation, it has already support for jCard. Adding the JSContact is 
>>> just more code.  There will be only less work if one is implementing a 
>>> client in the future after the whole ecosystem had moved to JSContact, 
>>> therefore no need to implement jCard, which is still a good win, as I guess 
>>> that many haven’t implemented a client yet since whois is still dominant 
>>> and RDAP is not yet at the same level.
>> +1
>> 
>> Every extension requires an implementation effort and every transition 
>> process from the old to the new requires a period where both coexist. 
>> 
>> If we hadn't been aware of that, we wouldn't have started the process to 
>> replace Whois with RDAP. And, like Marc pointed out, this process is still 
>> at the beginning  and we still don't imagine when it will really be 
>> completed.
>> 
>> In addition to that, I wonder why some members are so worried about the 
>> implementation effort done in this case in comparison to other extensions 
>> that completed the reviewing process.
> 
>Speaking as a client implementer, the amount of work required to update my 
> RDAP client to support JSContact was minimal - which speaks to how much 
> easier JSContact is to work with than jCard. You can see every change 
> required in https://client.rdap.org  here:
> 
>
> https://secure-web.cisco.com/1_Pf0XRu1tk3UR9-6jZ90CvItjm2neWOUbvFQlelz4q63NRctDM-rSfl0bSRaAV5EIV9aE7ka0U0or5uuTlvu68I6aSE7VnsWBMFLUFRToK6mDmJVHxBBFK9ztDZYSfxcAMaVmIUkFCaAOHPItTkzGJXFdCLs60lPUJp2yLiotBDfMlMsuDyuTUll6Ztrs4m3Vj8YoUgfwCkcXc0kxZzpigQikmbW3FGPQi8p2bgQ2NvJay4AkRznJp9CFRCj47UD/https%3A%2F%2Fgitlab.centralnic.com%2Fcentralnic%2Frdap-web-client%2F-%2Fcompare%2Fba4fd514...c9deae03
>  
> 

Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt

[Jasdip Singh]

Hi.

+1 for this doc being on standards track.

Jasdip

From: regext  on behalf of Antoin Verschuren 

Date: Monday, December 13, 2021 at 10:10 AM
To: "regext@ietf.org" 
Subject: Re: [regext] New Version Notification for 
draft-ietf-regext-rdap-jscontact-04.txt

Hi All,

I’m glad that my bad phrasing at least got some action into this discussion.
I didn’t mean to say that we can’t have 2 standards, but we should at least 
have clarity on the status of this document.
Because the original document title was 
"jcard-deprecation",
 and the introduction still talks about the intent and transition mechanisms to 
replace jCard, we can be a bit clearer that jsContact is a second standard, at 
least until jCard can be deprecated from support in RDAP after jsContact is 
sufficiently supported.

When we all agree jsContact is a second standards track document not intended 
to deprecate jCard just yet today, then that’s fine.
If we don’t get feedback this document should have a different status than 
standards track, then the chairs will add that intended status next week.

Which leaves the remaining questions Mario posted in his original message.

- --
Antoin Verschuren







Op 8 dec. 2021, om 14:53 heeft Gould, James 
mailto:jgould=40verisign@dmarc.ietf.org>>
 het volgende geschreven:

I view the jscontact is a valid use case for a standards track RDAP extension.  
We have many similar use cases for standards track extensions in EPP, where the 
RFCs couldn't envision a feature or an approach that comes up later.  The 
jscontact draft needs to be defined as an RDAP extension that is optional, with 
the appropriate signaling, and with transition considerations to support a 
transition from the jCard defined in RFC 9083 to JSContact defined in the 
extension.  I don't foresee that support for jCard will go away, but that 
JSContact can be become an alternative and potentially a preferred format for 
the RDAP contact data.  As Scott points out, supporting multiple formats can 
add complexity, but I believe that is a known cost to progress.

--

JG



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


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

Verisign.com 

On 12/8/21, 5:31 AM, "regext on behalf of Gavin Brown" 
mailto:regext-boun...@ietf.org> on behalf of 
gavin.br...@centralnic.com> wrote:


   On 8 Dec 2021, at 09:55, Mario Loffredo 
mailto:mario.loffr...@iit.cnr.it>> wrote:




Il 07/12/2021 14:42, Marc Blanchet ha scritto:



Le 7 déc. 2021 à 08:35, Hollenbeck, Scott 
mailto:shollenbeck=40verisign@dmarc.ietf.org>>
 a écrit :

We can *certainly* do that, Mario. It’s the option I support because there is a 
cost to replace a jCard implementation once it’s been implemented and deployed. 
Make it an optional extension and let server operators decide if/when they want 
to make the change.

I note that this will make life more difficult for client implementors because 
they’ll have to support both formats.

But the genie is already out of the bottle… I.e. if one have done a client 
implementation, it has already support for jCard. Adding the JSContact is just 
more code.  There will be only less work if one is implementing a client in the 
future after the whole ecosystem had moved to JSContact, therefore no need to 
implement jCard, which is still a good win, as I guess that many haven’t 
implemented a client yet since whois is still dominant and RDAP is not yet at 
the same level.
+1

Every extension requires an implementation effort and every transition process 
from the old to the new requires a period where both coexist.

If we hadn't been aware of that, we wouldn't have started the process to 
replace Whois with RDAP. And, like Marc pointed out, this process is still at 
the beginning  and we still don't imagine when it will really be completed.

In addition to that, I wonder why some members are so worried about the 
implementation effort done in this case in comparison to other extensions that 
completed the reviewing process.

   Speaking as a client implementer, the amount of work required to update my 
RDAP client to support JSContact was minimal - which speaks to how much easier 
JSContact is to work with than jCard. You can see every change required in 
https://client.rdap.org here:

   
https://secure-web.cisco.com/1_Pf0XRu1tk3UR9-6jZ90CvItjm2neWOUbvFQlelz4q63NRctDM-rSfl0bSRaAV5EIV9aE7ka0U0or5uuTlvu68I6aSE7VnsWBMFLUFRToK6mDmJVHxBBFK9ztDZYSfxcAMaVmIUkFCaAOHPItTkzGJXFdCLs60lPUJp2yLiotBDfMlMsuDyuTUll6Ztrs4m3Vj8YoUgfwCkcXc0kxZzpigQikmbW3FGPQi8p2bgQ2NvJay4AkRznJp9CFRCj47UD/https%3A%2F%2Fgitlab.centralnic.com%2Fcentralnic%2Frdap-web-client%2F-%2Fcompare%2Fba4fd514...c9deae03

   Getting JSContact working in the CentralNic RDAP server took a bit more 
work, but I see it as being worthw

Re: [regext] [Ext] Re: WG LAST CALL: draft-ietf-regext-epp-eai-04

[Gustavo Lozano]

I reviewed version 05, and I think it is ready for publication.

Regards,
Gustavo

On 12/13/21, 5:22 AM, "regext on behalf of Mario Loffredo" 
 wrote:

+1

Mario

Il 06/12/2021 14:45, Antoin Verschuren ha scritto:
> Dear Working Group,
>
> The authors of the following working group document have indicated that 
it is believed to be ready for submission to the IESG for publication as a 
standards track document:
>
> 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/__;!!PtGJab4!rfaLtIIvYVcdmKTjl0qo21eY7JJD3J0IOe16jwChihvCbMvIAyiRbfpswqX9KLRbwfgLs1E1YYo$
 
>
> This WG last call will end at close of business, Monday, 20 December 2021.
>
> Please review this document and indicate your support (a simple “+1” is 
sufficient) or concerns with the publication of this document by replying to 
this message on the list.
>
> The document shepherd for this document is Jody Kolker.
>
> Regards,
>
> Jim and Antoin
>
>
>
>
>
> ___
> regext mailing list
> regext@ietf.org
> 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!rfaLtIIvYVcdmKTjl0qo21eY7JJD3J0IOe16jwChihvCbMvIAyiRbfpswqX9KLRbwfgLbI767N8$
 

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: 
https://urldefense.com/v3/__http://www.iit.cnr.it/mario.loffredo__;!!PtGJab4!rfaLtIIvYVcdmKTjl0qo21eY7JJD3J0IOe16jwChihvCbMvIAyiRbfpswqX9KLRbwfgL5K0tVOU$
 

___
regext mailing list
regext@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!rfaLtIIvYVcdmKTjl0qo21eY7JJD3J0IOe16jwChihvCbMvIAyiRbfpswqX9KLRbwfgLbI767N8$
 


smime.p7s
Description: S/MIME cryptographic signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext