Re: [regext] CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of James Galvin
> Sent: Monday, January 18, 2021 9:29 AM
> To: REGEXT WG 
> Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-loffredo-regext-
> rdap-jcard-deprecation-03
> 
> 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.
> 
> This is a formal adoption request for “Using JSContact in Registration Data
> Access Protocol (RDAP) JSON Responses”:

While I understand the motivation for this draft, I'm a little worried that 
it's trying to solve a problem that is no longer a problem for anyone who has 
completed a jCard implementation. At this point, RDAP implementations with 
jCard are quite widespread among registries, registrars, and RIRs.  

Yes, we've heard that jCard can be cumbersome or tedious to implement, but once 
that work is done, an implementer has something that works.  Due to the nature 
of the problem domain, it is stable and doesn't require maintenance. 

While an implementation involving jSContact would certainly be more elegant 
from a technical perspective, I see limited value in developing a specification 
that would imply re-doing what has already been implemented to produce 
something that does basically the same thing. There must be some material 
benefit for implementers (of both servers and then clients) to offset the 
development and deployment cost of re-implementing the contact representation. 
Section 2 of the draft describes differences from jCard - are they enough to 
justify this investment?

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

Re: [regext] CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03

[Jasdip Singh]

Interesting point, Scott. Adopting JSContact (and deprecating jCard eventually) 
seems a tradeoff between ease-of-implementation for future servers/clients and 
diminishing returns for the current servers/clients. Should the latter 
(diminishing returns) prevent the former (easy-of-implementation)? It may help 
to gauge what other protocols have done in the past when presented with such a 
trade-off.

Jasdip  

On 1/29/21, 8:16 AM, "regext on behalf of Hollenbeck, Scott" 
 wrote:

> -Original Message-
> From: regext  On Behalf Of James Galvin
> Sent: Monday, January 18, 2021 9:29 AM
> To: REGEXT WG 
> Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-loffredo-regext-
> rdap-jcard-deprecation-03
> 
> 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.
> 
> This is a formal adoption request for “Using JSContact in Registration 
Data
> Access Protocol (RDAP) JSON Responses”:

While I understand the motivation for this draft, I'm a little worried that 
it's trying to solve a problem that is no longer a problem for anyone who has 
completed a jCard implementation. At this point, RDAP implementations with 
jCard are quite widespread among registries, registrars, and RIRs.  

Yes, we've heard that jCard can be cumbersome or tedious to implement, but 
once that work is done, an implementer has something that works.  Due to the 
nature of the problem domain, it is stable and doesn't require maintenance. 

While an implementation involving jSContact would certainly be more elegant 
from a technical perspective, I see limited value in developing a specification 
that would imply re-doing what has already been implemented to produce 
something that does basically the same thing. There must be some material 
benefit for implementers (of both servers and then clients) to offset the 
development and deployment cost of re-implementing the contact representation. 
Section 2 of the draft describes differences from jCard - are they enough to 
justify this investment?

Scott
___
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] CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03

[Mario Loffredo]

Hi,

the document has a twofold goal:

- introducing an  alternative to jcard as an extension

- defining a deprecation process through which the extension can replace 
jcard progressively


The document doesn't state that replacing jcard with jscontact is an 
absolute must but it provides the means to make it possible.


Whether and when the transition procedure will be fully completed will 
depend on the general consensus among RDAP implementers that jscontact 
is a much more efficient representation of contact information than 
jcard and, consequently, is worthy to be implemented.


Usually, when we propose an EPP or RDAP extension, we are not sure that 
it will be widely adopted. We simply admit that an inefficiency or a 
lack of functionality exists and we agree on a solution that can 
represent a valid guidance for all the implementers. Ultimately, only 
the implementers evaluate our proposals as worthy to be adopted.


Therefore, in my opinion, the main questions are: do we agree that jcard 
is inefficient? do we agree that the solution proposed for fixing such 
inefficiency can become a guidance for all the RDAP implementers?


Finally, I would like to say that I have released an open-source Java 
library supporting the burden of those who are willing to implement the 
proposal. At least in this case and for java developers, the 
implementation effort wouldn't be so strong :-)


Best,

Mario


Il 29/01/2021 15:11, Jasdip Singh ha scritto:


Interesting point, Scott. Adopting JSContact (and deprecating jCard eventually) 
seems a tradeoff between ease-of-implementation for future servers/clients and 
diminishing returns for the current servers/clients. Should the latter 
(diminishing returns) prevent the former (easy-of-implementation)? It may help 
to gauge what other protocols have done in the past when presented with such a 
trade-off.

Jasdip

On 1/29/21, 8:16 AM, "regext on behalf of Hollenbeck, Scott" 
 wrote:

 > -Original Message-
 > From: regext  On Behalf Of James Galvin
 > Sent: Monday, January 18, 2021 9:29 AM
 > To: REGEXT WG 
 > Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-loffredo-regext-
 > rdap-jcard-deprecation-03
 >
 > 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.
 >
 > This is a formal adoption request for “Using JSContact in Registration 
Data
 > Access Protocol (RDAP) JSON Responses”:
 
 While I understand the motivation for this draft, I'm a little worried that it's trying to solve a problem that is no longer a problem for anyone who has completed a jCard implementation. At this point, RDAP implementations with jCard are quite widespread among registries, registrars, and RIRs.
 
 Yes, we've heard that jCard can be cumbersome or tedious to implement, but once that work is done, an implementer has something that works.  Due to the nature of the problem domain, it is stable and doesn't require maintenance.
 
 While an implementation involving jSContact would certainly be more elegant from a technical perspective, I see limited value in developing a specification that would imply re-doing what has already been implemented to produce something that does basically the same thing. There must be some material benefit for implementers (of both servers and then clients) to offset the development and deployment cost of re-implementing the contact representation. Section 2 of the draft describes differences from jCard - are they enough to justify this investment?
 
 Scott

 ___
 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


--
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] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-09

[Gould, James]

Quoc,

I provide feedback to your points below.

--

JG

[cid:image001.png@01D6F65B.5515B0B0]

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

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

Verisign.com

From: regext  on behalf of "Quoc@registry.godaddy" 

Date: Wednesday, January 27, 2021 at 1:40 AM
To: Antoin Verschuren , "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: 
draft-ietf-regext-epp-registry-maintenance-09

Hi Antoin and all,

I apologies for my late contribution on this subject, as a backend that has 
implemented (albeit an older draft) of the maintenance draft, I have the 
following to share on the list of actions posted by James Gould on 2021-01-15 
(that would be my local date in Melbourne, Australia).


3.   Need for a formatted HTML description, since notices currently include 
formatted HTML content.

Quoc: I don’t think this is needed, I see the intent to be a machine to machine 
notification, the presence of an optional URI (maint:detail) provides details 
that are more human friendly which the client server may pass onto their users 
as needed. I assume this comment is in relation to HTML formatted email notices 
sent to Registrars, if this assumption is true, I don’t think that making the 
maintenance object be like for like with an email notice is needed. Often HTML 
formatted email is a decision to format the presentation of the information so 
that it looks “nice” and is formatted to corporate standards. Another use case 
for this to not be required is that in some emails it contains attachments, 
there’s no way in replicating that in the maintenance object.



JG – Since the intent of the draft is to standardize the maintenance notices, 
does it make sense to disallow inclusion of a formatted description in the EPP 
notification.  The description is not meant for machine use in both cases of 
plain text and formatted text, but it’s meant for visualization by users using 
many possible forms.  If formatted notifications are currently supported, why 
not support a smooth transition from e-mail notifications to EPP notifications 
instead of requiring the removal of the formatting or requiring the creation of 
an external accessible URL that is linked to within the EPP notification?  I 
don’t believe there is the need for attachments for the maintenance notices 
generated currently, so I don’t believe that will be an issue.



4.   How to signal the maintenance of an entire system versus the 
maintenance of an individual or set of TLDs on the system

Quoc: I find the use of maint:impact in combination of maint:tld as reasonable. 
Our system supports multiple TLDs from a single end point and so we use this 
combination as needed. For instance if there was maintenance specific for .biz 
we would only report BIZ in the maint:tld list. Also what I would like to share 
is what is being referred to as maintenance? Things of a technical nature is 
pretty straight forward, e.g. software upgrade, so TLDs are hosted on a single 
system then when there is an upgrade to the backend then maintenance will be 
performed on ALL TLDs. However what if there is an UPDATE to a TLD which is not 
software related but more business driven. E.g. if there is a TLD registration 
policy update, this I don’t see as qualifying as a maintenance but today there 
would be an email notification to all Registrars with access to the TLD being 
updated. In spirit of simplicity I only would consider maintenance of a 
technical nature in the maintenance object.



JG – So how do you communicate the maintenance of your backend that brings down 
the VIP for all of your TLDs?  Would you return no TLDs or all TLDs?  A VIP 
being taken down is more impactful than updating a set of TLDs while the VIP is 
up, so it makes sense to signal the entire system is taking a maintenance.  My 
recommendation is to either not include the  element or create an 
empty  element as a choice with the  element.  My 
preference would be to be explicit by creating the empty  element 
as a choice.  If exclusion of the  element is chosen on the signal, 
then the draft should be explicit with description of the  element 
to cover this use case.



5.   Support for courtesy (e.g., 2 weeks, 1 week, 2 days, 1 day prior to 
maintenance) notices and maintenance end notices.

Quoc: Noting that this is a suggestion for a "courtesy", I find this 
unnecessary as the consumer here is a machine. So when a maintenance object is 
created only single object is created and it’s expected that the client server 
stores the date and time reported and set their own reminders. If this was an 
email notification for humans to read then that’s a different matter (not to 
say that reminders are not needed). Of course if the WG thinks it’s good to 
send out service messages at a 2 week, 1 week, 2 day and 1 day before the 
maintenance then I’ll be OK to implement as a courtesy however I would suggest 
that clients th