Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

age- > From: Mario Loffredo > Sent: Monday, July 18, 2022 4:40 AM > To: Gould, James ; a...@hxr.us > Cc: Hollenbeck, Scott ; regext@ietf.org > Subject: [EXTERNAL] Re: [regext] OK, What Next? (was RDAP Extensions > Approach Analysis v2) > > Caut

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

rote: James, Comments in-line... On Mon, Jun 27, 2022 at 12:36 PM Gould, James wrote: > > > The question is how we handle versioning, which is an aspect not covered in the existing RFCs. The only version reference is in the RDAP Conformance definition in sec

Re: [regext] Login/Logout Processing (was RE: I-D Action: draft-ietf-regext-rdap-openid-15.txt)

Scott, My preference is option 1, where if the request conflicts with the current state it needs to result in an error. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 7/7/22, 11:02 AM,

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

n.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/27/22, 12:54 PM, "Hollenbeck, Scott" wrote: > -----Original Message- > From: Gould, James > Sent: Monday, June 27, 2022 12:37 PM

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

> Mario > > > Il 27/06/2022 16:03, Hollenbeck, Scott ha scritto: > > I can only disagree. That wasn't the original intent, and the inconsistency is > clearly causing confusion. > > > > Scott > > > >> ---

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

sistency is clearly causing confusion. Scott > -Original Message- > From: Gould, James > Sent: Monday, June 27, 2022 9:57 AM > To: Hollenbeck, Scott ; mario.loffr...@iit.cnr.it; > regext@ietf.org > Subject: [EXTERNAL] Re: Re: [regext] OK, Wh

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

Scott, I don't believe anything needs to be changed in 9083. Where "lunarNIC" is the registered prefix identifier and the RDAP conformance value "lunarNIC_level_0" might be used. This supports the use of the registered prefix identifier and the needed versioning. -- JG James Gould Fe

Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-07.txt

Rick, Thank you for doing a detailed review of the draft. I include responses to your feedback embedded below. -- JG [cid:image001.png@01D887B2.657F4E40] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

I agree with Mario that we need to first consider the approaches presented (approach A, B, and C) prior to determining what changes need to be made to the existing RFCs. I believe that the use of the "lunarNIC_level_0" identifier is appropriate for the RDAP Conformance value in RFC 9083 to sign

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

Scott, I believe the first step is to come to consensus on the desired extension registry approach or approaches. I personally like the use of "lunarNIC_level_0" in the rdapConformance to ensure that versioning of the specification is fully supported. Approach B could be used to allow for th

Re: [regext] Secdir last call review of draft-ietf-regext-epp-eai-12

Chris, Thank you for the review, feedback, and recommended text. You mention an interesting use case of a client or server that signals the support EAI, but that can't meet the obligations defined in section 5.3.1 "EAI Functional Extension Negotiated". The negotiation is handled when the EPP

Re: [regext] I18ndir early review of draft-ietf-regext-epp-eai-10

Yoshiro, Thank you for the review and feedback. I include a response to your minor issue embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 6/1/22, 9:04 PM, "Yoshiro Yoneya

Re: [regext] [IANA #1231867] expert review for draft-ietf-regext-epp-eai (epp-extensions)

Agreed, the following registration needs to be removed from the draft: Registration request for the eai XML Schema: URI: urn:ietf:params:xml:schema:epp:eai-1.0 Registrant Contact: IESG XML: See the "Formal Syntax" section of this document. -- JG James Gould Fello

Re: [regext] Genart last call review of draft-ietf-regext-epp-eai-10

Pete, Thanks for the review and feedback. My responses are embedded below prefixed with "JG - ". -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 6/1/22, 1:14 PM, "Pete Resnick via Data

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

t have been proposed, which is useful but may be getting ahead of defining what we're attempting to solve. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/31/22, 7:13 PM, &quo

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

Tom, I'm not exactly sure where the term 'strict' model is coming from, which I assume is associated with Approach A "Tight Coupling". I believe the RFCs are sufficiently unclear to support all three approaches discussed thus far (A, B, and C). I added “Approach C – decoupled” to the table

Re: [regext] [Last-Call] Last Call: (Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)) to Proposed Standard

Then I'm going to step back from this until/unless others are heard from. --On Friday, May 27, 2022 12:03 + "Gould, James" wrote: > John, > > Thank you for your review and feedback. My responses are > embedded below. >...

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

ier Jasdip On 5/27/22, 10:25 AM, "regext on behalf of Gould, James" wrote: Mario, [ML] My only objection to Approach C is that every new version would result in registering a new extension identifier. I would opt for a less verbose s

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

ld Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/27/22, 10:10 AM, "Mario Loffredo" wrote: Hi james, my comment inline. Il 27/05/2022 14:43, Gould, James ha scritto: > Mario,

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

Mario, Thank you for providing an example of the complexity of versioning that is associated with tightly coupling the RDAP compliance value with the set of prefixes. Unfortunately, RDAP doesn't include the same sort of version negotiation that exists in EPP with the use of XML namespace URIs

Re: [regext] Last Call: (Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)) to Proposed Standard

John, Thank you for your review and feedback. My responses are embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 5/26/22, 2:11 PM, "John C Klensin" wrote: --On Thu

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

ednesday, May 25, 2022 at 9:10 AM To: James Gould , "mario.loffr...@iit.cnr.it" , "t...@apnic.net" Cc: "regext@ietf.org" Subject: RE: [regext] Extension Prefixes, JSON Values, and URI Path Segments From: Gould, James Sent: Wednesday, May 25, 2022 8:49 AM To: Hol

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

eck, Scott" Date: Wednesday, May 25, 2022 at 8:07 AM To: James Gould , "mario.loffr...@iit.cnr.it" , "t...@apnic.net" Cc: "regext@ietf.org" Subject: RE: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments From: Gould, James Sent: Tuesday, M

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

AM To: James Gould , "t...@apnic.net" Cc: "Hollenbeck, Scott" , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments Hi, please find my thoughts below. Il 23/05/2022 21:26, Gould, James ha scritto: Tom,

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

2 at 06:36:59PM +, Gould, James wrote: > On 5/19/22, 2:35 AM, "Tom Harrison" wrote: >> On Wed, May 18, 2022 at 11:59:05AM +, Gould, James wrote: >>> On Wed, May 18, 2022 at 09:12:16AM +1000, Tom Harrison wrote: >>>> T

Re: [regext] Analysis of tight coupling between extension identifier and rdapConformance, versus lack of

Jasdip, How about adding Approach C: decouple the extension identifier in the rdapConformance from the set of path segment, JSON response member, and objectClassName prefix values? The ABNF for an element (path segment, JSON response member, objectClassName), based on the registration of an ex

Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-04.txt

Tom, Thank you for bringing this up, since I was overly focused on the Domain Name Registries (DNRs). Will the Regional Internet Registries (RIRs) redact via draft-ietf-regext-rdap-redacted, and will the Redaction by Replacement Value Method be used? Signaling the replacement of a property

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

Wed, May 18, 2022 at 11:59:05AM +, Gould, James wrote: > On Wed, May 18, 2022 at 09:12:16AM +1000, Tom Harrison wrote: >> The uniqueness aspect of the registry is fine, as is the 'null suffix' >> part. I'm more concerned with the confusing way in which t

Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-04.txt

From: Mario Loffredo Date: Thursday, May 19, 2022 at 9:10 AM To: James Gould , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-04.txt Hi James, please find my comments below. Il 03/05/2022 14:43, Gould, James ha scritto: The draft-ietf-rege

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

"Tom Harrison" wrote: Hi James, On Tue, May 17, 2022 at 04:59:35PM +, Gould, James wrote: > On 5/17/22, 8:56 AM, "Tom Harrison" wrote: >> I think this approach could work in principle, but I don't think it's >> in accordanc

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

2, 8:56 AM, "Tom Harrison" wrote: Hi James, (Replying to the original mail, but taking into account replies to it to date as well.) On Thu, May 05, 2022 at 03:44:01PM +, Gould, James wrote: > Scott and I discussed this offline, and below is a proposal for the

Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-05.txt

The draft draft-ietf-regext-rdap-redacted-05 has been posted that implements the proposal on the list for the RDAP Extension Registry registrations, that includes: 1. Registration of a versioned extension identifier that is used for the “rdapConformance” value, which is “redacted_level_0_3

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

ofile_asn_flat_0 - nro_rdap_profile_asn_hierarchical_0 - rdap_objectTag - redirect_with_content From: regext on behalf of "Gould, James" Date: Thursday, May 5, 2022 at 11:44 AM To: "shollenbeck=40verisign@dmarc.ietf.org" , "regext@i

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

Scott and I discussed this offline, and below is a proposal for the RDAP Extension Registry registrations that meets the language in the RFCs and ensures that there are no conflicts (RFC 7480 “ensure uniqueness of extension identifiers”) with the URI paths or JSON members for new RDAP extensions

Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-04.txt

The draft-ietf-regext-rdap-redacted-04 has been posted that includes the following updates: 1. Added the Redaction by Replacement Value Method in Section 3.3 (https://www.ietf.org/archive/id/draft-ietf-regext-rdap-redacted-04.html#section-3.3) * There is an example of replacing the r

Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

Scott, With the potential impacts to draft-ietf-regext-rdap-redacted, I did a review of the referenced RFC language for the Extension Prefixes, JSON Values, and URI Path Segments. I provide my interpretation embedded below for consideration. To provide a concrete example of the proposed cha

Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

James Gould , "ietf=40antoin...@dmarc.ietf.org" , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search Hi James, thanks a lot for your feeedback. Please find my responses inline. Il 26/04/2022 14:17, Gould, James ha scrit

Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

I did a review of the latest version of the draft (draft-ietf-regext-rdap-reverse-search-10), and below is my feedback: 1. Abstract * It states, “This document describes RDAP query extensions”. Shouldn’t it be “this document describes an RDAP query extension” in the singular form?

Re: [regext] in

+1 on the use 2103/"Unimplemented extension". This is a broader topic with the passing invalid or conflicting extensions (e.g., restore request extension of update along with the sync extension). -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Re

Re: [regext] Document Shepard Review of draft-ietf-regext-epp-eai-07

Jody, I am not aware of any IPR that requires disclosure under the provisions of BCP 78 and BCP 79 for draft-ietf-regext-epp-eai. -- JG [cid:image001.png@01D84F5C.A6C00FE0] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com

Re: [regext] Document Shepard Review of draft-ietf-regext-epp-eai-07

Jody, Thank you for doing the document shepherd review of draft-ietf-regext-epp-eai. I include my responses to your feedback embedded below. -- JG [cid:image001.png@01D845E4.58A55580] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.

Re: [regext] Comments to the feedback about epp-over-http

AM To: James Gould , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http Hi James, my comments are embedded below. Il 29/03/2022 17:50, Gould, James ha scritto: Mario, My responses are embedded below. -- JG [cid:image002.png@01D8441C.

Re: [regext] Comments to the feedback about epp-over-http

AM To: James Gould , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http Hi James, Il 29/03/2022 13:41, Gould, James ha scritto: Mario, My feedback is embedded below. -- JG [cid:image002.png@01D84363.253C6D10] James Gould Fellow Engineer jgo

Re: [regext] Comments to the feedback about epp-over-http

James Gould , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http Hi James, thanks for ypur quick reply. Please find my comments below. Il 25/03/2022 16:45, Gould, James ha scritto: Mario, For #4 “Cookie vs. HTTP Connection”, you asked the q

Re: [regext] Comments to the feedback about epp-over-http

Mario, For #4 “Cookie vs. HTTP Connection”, you asked the question “can you further clarify why we should opt for establishing the cookie at setup of the connection and how should it be possible? For example, what kind of request should be used to start the HTTP connection?”. I implemented plu

[regext] draft-ietf-regext-rdap-redacted Support for Redaction by Replacement Value Method

There was discussion in the ICANN RDAP working group associated with the requirement for the “Registrar MUST publish an email address or a link to a web form for the email value to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address”, based o

Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-06.txt

Hi, I did a detailed review of draft-ietf-regext-simple-registration-reporting-06 and below is my feedback: 1. Introduction * I’m not sure whether there have been “a number of best practice reports that have evolved”, but I do agree that there have been “a number of best practice

Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

Mario, Thank you for sharing the draft. We implemented EPP/HTTPS in parallel with EPP/TLS a while back for many years. In the end, there were very few registrars that chose to use EPP/HTTPS, so it was shutdown. I’m not sure at this point whether there is hunger from the registrars to impleme

Re: [regext] Feedback about rdap-redacted doc

Mario, I believe that your second option is the simpler one. I agree that we should add an entry in section 5 "JSONPath Considerations" to address it. How about the following entry? When there are multiple entities with the same role, include "redacted" members for each entity using the enti

Re: [regext] Redacted implemented server side?

Mario and Marc, It's great to see plans to implement both a production client and server. Receiving implementation feedback would be very valuable. Once you have something in place, please let us know and we can add an Implementation Status section to the draft to include both the client and

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

Scott, Thanks for the review and feedback. I provide responses to your feedback embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 12/6/21, 9:18 AM, "regext on behalf of Hol

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

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

[regext] FW: I-D Action: draft-ietf-regext-rdap-redacted-02.txt

Support for RDAP search responses was added in draft-ietf-regext-rdap-redacted-02. JSONPath (draft-ietf-jsonpath-base ) does not support an up operator to use relative JSONPaths in the "path" member, so draft-ietf-regext-rdap-redacted-02 specifies the use of an absolute path (e.g., "$.domainSe

Re: [regext] [check] always prohibited when avail="1" ?

I would be more concerned about injecting domain names into the check response that were not queried for in the command than the inclusion of the optional reason element to explain why the domain name was added. I looked at the approach taken with a similar extension, which is the Related Domai

Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-01.txt

draft-ietf-regext-rdap-redacted-01 was posted that includes updates associated with feedback from Gustavo Lozano, Marc Blanchet, and Mario Loffredo. This version adds the use of the JSON Values Registry for the registration of redacted name and reason values. One item that was discussed with t

Re: [regext] pass on the lower fee

Martin, If you do return the extension in a poll response it should be included in the greeting services. My recommendation is to fully implement the registry fee extension along with this so not to cause client confusion. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-

Re: [regext] pass on the lower fee

Agreed, for this use case I would go with a renew change poll message with the registry fee extension, such as: S: S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: 2021-08-17T22:00:00.0Z S: Auto renew dis

Re: [regext] [Ext] Re: I-D Action: draft-ietf-regext-epp-eai-02.txt

Scott, Agreed, the title is better as “Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)”. The EPP RFCs have included “Extensible Provisioning Protocol (EPP)” in the title, so it would be most consistent to include the long form. -- JG [cid:image001.png@

Re: [regext] [Ext] Re: I-D Action: draft-ietf-regext-epp-eai-02.txt

Gustavo, Good point, I agree that returning the 2308 “Data management policy violation” error response is the best option for the use case when the client doesn’t support EAI per the login services and the optional e-email response value is an EAI. To map this up to the EPP RFCs with an email

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

emont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/4/21, 4:18 PM, "Taras Heichenko" wrote: Hi James, all. > On 4 Aug 2021, at 15:38, Gould, James wrote: > > Thank you for your perspective for use case #2 (info response of EAI address

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

Aug 2021, at 21:08, Gould, James wrote: > > Thomas, > > For use case #2 (info response of EAI address with non-EAI supporting client), your preference is to return a failure. Is 2308 “data management policy violation” the best error code in your opinion? Do

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

NGO support)" wrote: Hello, On 8/2/21 20:08, Gould, James wrote: > Thomas, > > For use case #2 (info response of EAI address with non-EAI supporting > client), your preference is to return a failure. Is 2308 “data > management policy violati

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/2/21, 2:32 PM, "regext on behalf of Patrick Mevzek" wrote: On Mon, Aug 2, 2021, at 13:22, Gould, James wrote: > You can reply to my reply to > Thomas Corte with your though

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

On Mon, Aug 2, 2021, at 08:50, Gould, James wrote: > I believe the use of a predefined placeholder value is the best > approach to handle this transition corner case in the protocol, but I > would like to hear viable alternates from the working group to > incorporat

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

8/2/21, 11:42 AM, "regext on behalf of Thomas Corte (TANGO support)" wrote: Hello, On 8/2/21 15:50, Gould, James wrote: > 2. EPP Contact Response > (https://secure-web.ci

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

rt EAI and Server not it can only be prohibited. Regards Marco Am 02.08.21 um 15:50 schrieb Gould, James: > Marco, > > > > The issue is associated with a transition state when one side of the > connection (registrar or registry)

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

Marco, The issue is associated with a transition state when one side of the connection (registrar or registry) supports EAI while the other does not, the email element is required by the protocol, and the only value available is an EAI address. The EAI-supporting side can’t pass the EAI valu

Re: [regext] [Ext] FW: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

ethods described in section 5 are insufficient. Regards, Gustavo On 7/14/21, 10:51, "Gould, James" wrote: Gustavo, Thank you for your quick review and feedback. I provide my replies to your feedback embedded below. -- JG

Re: [regext] draft-ietf-regext-epp-eai Predefined Placeholder Email Value

is, that you can use example.com/org/net for that purpose, too, as they are reserved TLDs. empty.as112.arpa has no MX record, too, therefore, I don‘t get the advantage of it. Best, Tobias Am 22.07.2021 um 18:06 schrieb Gould, James : There is one TBD item that exists in section 5.3.2 of draft

[regext] draft-ietf-regext-epp-eai Predefined Placeholder Email Value

There is one TBD item that exists in section 5.3.2 of draft-ietf-regext-epp-eai related the “predefined placeholder email” that is used by the EAI supporting server and EAI supporting client where the opposite party doesn't support EAI. In both cases a valid email value needs to be provided to

Re: [regext] Fwd: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

, 2021 at 3:56 AM To: James Gould Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-gould-regext-rdap-redacted-00.txt Hi James, please find my replies below. Il 15/07/2021 19:40, Gould, James ha scritto: Mario, My responses are embedde

Re: [regext] Fwd: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

for draft-gould-regext-rdap-redacted-00.txt Data: Wed, 14 Jul 2021 14:06:47 +0000 Mittente: Gould, James <mailto:jgould=40verisign@dmarc.ietf.org> A: mario.loffr...@iit.cnr.it<mailto:mario.loffr...@iit.cnr.it> <mailto:mario.loffr...@iit.cnr.it>, marc.blan

Re: [regext] [Ext] FW: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

in: The Redaction by Empty Value Method SHOULD be used only when redacting JSON response fields that use the position in an array to signal the redacted field (e.g., jCard [RFC7095] arrays). Thank you, Gustavo On 7/12/21, 04:03, "regext on behalf of Gould, James" wrote:

Re: [regext] New Version Notification for draft-gould-regext-rdap-redacted-00.txt

io Loffredo" wrote: Hi all, Il 12/07/2021 13:26, Gould, James ha scritto: > Marc, > > Thank you for the quick review and feedback. Below are responses to your early comments: > > - would be good to include specific text about jscontact, so when

Re: [regext] New Version Notification for draft-gould-regext-rdap-redacted-00.txt

gninc.com/> From: Marc Blanchet Date: Monday, July 12, 2021 at 7:41 AM To: James Gould Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] New Version Notification for draft-gould-regext-rdap-redacted-00.txt Le 12 juill. 2021 à 07:26, Gould, James mailto:jgo...@verisign.com>

Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-04.txt

In reviewing the changes made to draft-ietf-regext-simple-registration-reporting-04, I have the following feedback: 1. The sentence "Each report definition MUST use only the data elements defined in the data element aforementioned data element registry, including all future reports." could be

Re: [regext] New Version Notification for draft-gould-regext-rdap-redacted-00.txt

ple languages. Really would like this document to move forward. As RDAP client implementor, I would like to implement it. If some servers are already implementing it, please contact me directly so we can do some interop testing. Marc. > Le 12 juill. 2021 à 07:02, Gould, James

[regext] FW: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

The "Redacted Fields in the Registration Data Access Protocol (RDAP) Response" draft-gould-regext-rdap-redacted has been published. The goal of the draft is to describe an RDAP extension for explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language.

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-secure-authinfo-transfer-06: (with DISCUSS and COMMENT)

"Benjamin Kaduk" wrote: Hi James, My apologies for the again-delayed response. Continuing inline and skipping points that are resolved... On Mon, May 10, 2021 at 09:00:27PM +, Gould, James wrote: > Benjamin, > > I provide respon

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-secure-authinfo-transfer-06: (with DISCUSS and COMMENT)

Also inline. On Mon, Apr 26, 2021 at 09:08:29PM +0000, Gould, James wrote: > Benjamin, > > Thank you for your review and feedback. I provides responses to your feedback embedded below. Updates will be made to draft-ietf-regext-secure-authinfo-transfer-07 that will

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-secure-authinfo-transfer-06: (with DISCUSS and COMMENT)

Benjamin, Thank you for your review and feedback. I provides responses to your feedback embedded below. Updates will be made to draft-ietf-regext-secure-authinfo-transfer-07 that will include changes from all of the feedback. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-

Re: [regext] Roman Danyliw's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Roman, Thank you for your review and feedback. My responses are embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 4/20/21, 9:01 PM, "Roman Danyliw via Datatracker" wrote:

Re: [regext] Francesca Palombini's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Francesca, Thanks for the review and feedback. Good catch on the copy/paste issue in section 5.2. The first paragraph will be removed, since the second paragraph contains everything of the first with additional content. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com

Re: [regext] Martin Duke's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Martin, Thank you for the review and feedback. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 4/9/21, 8:17 PM, "Martin Duke via Datatracker" wrote: Martin Duke has entered the fol

Re: [regext] Robert Wilton's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Robert, Thank you for your review and feedback. I provide responses to your feedback embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 4/19/21, 7:57 AM, "Robert Wilton via

Re: [regext] Lars Eggert's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Lars, Thank you for your review and feedback. Embedded I include responses to your comments. The updates made to the draft will be included in the publishing of draft-ietf-regext-secure-authinfo-transfer-07 after all feedback has been received. Thanks, -- JG James Gould Fellow Enginee

Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-epp-registry-maintenance

Antoin, All of my feedback has been addressed in draft-ietf-regext-epp-registry-maintenance and I support it moving forward. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 3/29/21, 9:2

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

Tobias, Making it unbounded and a list adds some complexity to the implementation, since it's most likely going to be a single element. I understood the reasoning behind it and therefore I'm fine with it. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemo

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

:46 AM, "Tobias Sattler" wrote: Jim, Got it. I guess, I mixed it up with potential(ly). How should we address “none” to avoid that all systems will be listed that aren’t even affected? Tobias > On 7. Apr 2021, at 16:22, Gould, James wrote: > > Tobias,

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

quot;none" would almost be a duplication. And we could save a status to avoid confusion. Tobias > On 7. Apr 2021, at 14:48, Gould, James wrote: > > Jody, > > I replied to Michael previously, but the intent of the "none" impact option i

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

uch in here. Thoughts? Thanks, Jody Kolker. -Original Message- From: regext On Behalf Of Michael Bauland Sent: Wednesday, April 7, 2021 1:26 AM To: Gould, James Cc: regext@ietf.org Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maint

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

Michael, My feedback in embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 4/7/21, 2:26 AM, "Michael Bauland" wrote: Hi Jim, On 06.04.2021 21:

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

PM To: James Gould Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt Thanks, Jim. Please see my comments inline. The updates are done on GitHub for your review. Tobias On 6. Apr 2021, at 18:58, Gould, James m

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

ance.txt> Tobias On 6. Apr 2021, at 14:21, Gould, James mailto:jgould=40verisign@dmarc.ietf.org>> wrote: If the intent is to support a list of description elements, then my recommendation is to update the schema, as previously noted with maxOccurs="unbounded", and upda

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

hn9m_n0q1Aop-LvX59fsy8JV04r9d-NS_iCDZ5x8vZ_ZXeJt2CO7oDXK27hsU8Mr8S_41nsjRPFrjYDAiFveBRZ3ZkF5Nw_uo2v2SnNYXN7rkMl6JYfcd0O3CGnC0_kwrvWmTkqx6cPzh6l4_7icShqr4GYvhj7rqXvmaccBz2M5PDzZm--ziQiAUKihBIGtyIJkMdPi33ApZBYhIAqUSMx1C5YFQyxN622sUqjir77szIdHyTOIdQrMiPLsb6/https%3A%2F%2Fgithub.com%2Fseitsu%2Fregistry-epp-maintenance%2Fblob%2Fmaster%2Fdraft-ietf-regext-epp-registry-maintenance.txt> Tobias On 6.

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

If the intent is to support a list of description elements, then my recommendation is to update the schema, as previously noted with maxOccurs="unbounded", and update the description of the element with something similar to: Zero or more OPTIONAL free-form descriptions of the maintenance... --

Re: [regext] CALL FOR ADOPTION: draft-belyavskiy-epp-eai

Antoin, As a co-author of draft-belyavskiy-epp-eai, I support adoption and I am willing to continue as a co-editor. I anticipate most of the WG discussion to be around the definition of a new form of EPP extension (Functional Extension) and on how to handle the EAI mismatch support cases. I w

Re: [regext] Secdir last call review of draft-ietf-regext-unhandled-namespaces

Tiru, In re-looking at it, it was intended to reference the set of normative EPP RFC’s used in the draft, which originally included RFC 5730, 5731, 3915, 5910, and 8590. We moved all of the EPP RFCs 3915, 5910, and 8590 from normative references to informational references because they’re onl

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-unhandled-namespaces-07: (with COMMENT)

Ben, Thank you for your review and feedback. I provide answers to your feedback below. The referenced updates will be included in the posting of draft-ietf-regext-unhandled-namespaces-08 along with addressing the other feedback. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign

Re: [regext] Murray Kucherawy's No Objection on draft-ietf-regext-unhandled-namespaces-07: (with COMMENT)

Marray, Thank you for your review and feedback. I provide a response to your comment embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 2/18/21, 1:38 AM, "Murray Kucherawy v

<    1   2   3   4   5   6   7   8   >