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] 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] 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] 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)

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] 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)

> 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)

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] 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)

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] 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)

n consistency without the negative side effect of causing interoperability issues when removing support for older versions. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/18

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

Scott, My feedback is 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 7/18/22, 1:49 PM, "Hollenbeck, Scott" wrote: > -Original Message

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

15, 2022 at 8:13 AM Gould, James wrote: > > > In the case of Approach B and C, the values registered in the RDAP Extension Registry guarantee uniqueness, and the RDAP Conformance value has the sole responsibility of signaling the version of the extension without cascadi

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

;Andrew Newton" wrote: On Tue, Jul 19, 2022 at 9:43 AM Gould, James wrote: > > JG - This is defining a new mechanism for auto-discovery. I don't believe it is new as the rdapConformance array has been present from the inception of RDAP. Can you explain your t

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

gn.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/19/22, 11:10 AM, "Andrew Newton" wrote: On Tue, Jul 19, 2022 at 10:58 AM Gould, James wrote: > > Since rdapConformance is defined as an array of string

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

eeds to be addressed? Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/13/22, 11:35 AM, "Gould, James" wrote: Chris, Thank you for the review, feedback, and reco

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

<http://verisigninc.com/> On 6/1/22, 4:23 PM, "Gould, James" wrote: Pete, Thanks for the review and feedback. My responses are embedded below prefixed with "JG - ". -- JG James Gould Fellow Engineer jgo...@verisign.com 703-

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

sign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/26/22, 3:37 PM, "John C Klensin" wrote: --On Tuesday, July 26, 2022 18:37 + "Gould, James" wrote: > Pete, > > We addressed some

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

Takahiro, I wanted to follow-up with the feedback that you’ve provided. For the first minor issue, the proposal for “alternate ASCII address” in the message (https://mailarchive.ietf.org/arch/msg/regext/ljIoGJtWaiLv8gw4SsSQVOs0xsM/ ) is to remove the statements from section 5.3.2 since they a

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

Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/8/22, 10:30 AM, "Gould, James" wrote: 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 saf

Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance

Jim, I support the chair's proposal with two comments that I communicated at the REGEXT meeting during IETF114: 1. Registration of versioned policy (profile) identifiers will continue to be allowed in the RDAP Extensions Registry, such as "icann_rdap_response_profile_0" and " icann_rdap_tech

Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance

uld Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/2/22, 10:12 AM, "James Galvin" wrote: On 2 Aug 2022, at 8:16, Gould, James wrote: > Jim, > > I support the chair

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

Yoshiro YONEYA On Thu, 28 Jul 2022 13:41:49 + "Gould, James" wrote: > Yoshiro, > > I wanted to follow-up on your feedback. I provided clarification in my response below to your feedback. Does this clarification address your feedback, or d

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

eston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/26/22, 12:59 PM, "Gould, James" wrote: Chris, Based on the feedback that you provided, we did add the proposed language below to the security considerations section of draft-ietf-regext-epp-eai-13: When

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

I'm concerned about John's comments (I saw them on the Gen-ART archive as well as here), but I'm sure you will reflect my feedback here in the next update for the time being. Regards, Nemo > 2022/07/28 22:19、Gould, James のメール: > > Takahiro, &g

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

tatus? Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/26/22, 2:37 PM, "Gould, James" wrote: Pete, We addressed some of your feedback (Minor issues and Nits/

Re: [regext] [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12

Verisign.com<http://verisigninc.com/> From: Dmitry Belyavsky Date: Thursday, August 18, 2022 at 7:53 AM To: John C Klensin Cc: "Gould, James" , "a...@ietf.org" , "draft-ietf-regext-epp-eai@ietf.org" , "last-c...@ietf.org" , regext , "i18n...@ietf

Re: [regext] [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12

Partrik, By creating a standard around draft-ietf-regext-epp-eai it should decrease diversity of proprietary extensions with adding EAI support to EPP. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com

Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

John, I will address your point (5), based on the prior thread that we had back in May (https://mailarchive.ietf.org/arch/msg/regext/G08akVkCjnXEPw8k7NiCHbeEamo/), where I stated: I don't agree that section 2.7 of RFC 5730 defines the only forms of extensibility that can ever be supported by

Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

n C Klensin" wrote: --On Monday, 22 August, 2022 12:00 +0000 "Gould, James" wrote: > John, > > I will address your point (5), based on the prior thread that > we had back in Ma

Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

<http://verisigninc.com/> From: Dmitry Belyavsky Date: Tuesday, August 23, 2022 at 2:43 AM To: John C Klensin Cc: James Gould , Patrik Fältström , "Gould, James" , "a...@ietf.org" , "draft-ietf-regext-epp-eai@ietf.org" , "last-c...@ietf.org" , re

Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

John, You claim that the registrant's e-mail address in the registry is critical to the transfer process and therefore an ASCII address must always be provided. The EPP credential used to authorize a transfer is not the e-mail address, but the Authorization Information. I'm aware of the Form

Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

:44 PM, "John C Klensin" wrote: 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. (TL;DR summary at end) --On Tuesday, August 30, 2022 12:18 + "Gould, James&qu

Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

r jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/30/22, 4:11 PM, "Gould, James" wrote: John, To clarify the "we" in the statement "Based on your feedback, we agree to revise the draft to be a com

Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-01.txt

Gavin, Thank you for publishing a new version of the draft. I have the following feedback: 1. Shouldn’t the track be Standards Track instead of Experimental since this seems very straight forward? 2. Shouldn’t the A and TTL apply to the Host object instead of the Domain Name objec

Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

hose "details" can be worked out later. thanks, john --On Wednesday, August 31, 2022 17:26 + "Gould, James" wrote: > John, > > draft-ietf-regext-epp-eai-16 was posted that addresses two of > the issues that you raised, by

Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-01.txt

Gavin, The TTL for the A/ records need to be applied to the host object and the TTL for the NS and DS records need to be applied to the domain object. Setting the A/ TTL at the host object level would apply to registries that implement sibling glue as well as CentralNic and TANGO that

Re: [regext] New Version Notification for draft-regext-brown-epp-ttl-01.txt

properly respecting the limits of the TTL values is also unlikely to be heading a hypothetical warning value. > > So, bottom line, after some thought, I like the way that this works. > > > Thanks > Rick > > > >

Re: [regext] New Version Notification for draft-regext-brown-epp-ttl-01.txt

Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext on behalf of Tim Wicinski Date: Tuesday, September 27, 2022 at 9:22 AM To: "Gould, James" Cc: Gavin Brown , "rwilh...@pir.org" , "thomas.co...@knipp.de" , "regext@ietf.org"

Re: [regext] [EPP] Several commands under the same

+1, the element under the command element is a single element based on the commandType definition in the XML schema, so having several commands under the element is not compliant. I include the relevant element definitions from "epp-1.0.xsd" below for reference:

Re: [regext] [EPP] Several commands under the same

Marc, Here you go, I passed the following XML through a validating XML parser: example.com 2fooBAR ABC-12345 This is the result: XML error: Line: 13 Column..: 13 Message.: :

[regext] FW: New Version Notification for draft-ietf-regext-epp-eai-17.txt

The recommendation "Change Cardinality to One or Two" from the REGEXT meeting has been posted in draft-ietf-regext-epp-eai-17. Please review and provide feedback. Section 8 "SMTPUTF8 Transition Considerations" may be of particular interest. Thanks, -- JG James Gould Fellow Engineer j

[regext] Request WGLC for draft-ietf-regext-rdap-redacted

This is a formal request to start the WGLC for draft-ietf-regext-rdap-redacted. There is a normative reference to draft-ietf-jsonpath-base, which has a JSONPath working group November milestone. draft-ietf-jsonpath-base looks stable and can progress in parallel with draft-ietf-regext-rdap-reda

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

Pawel, Thank you for the detailed review. 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 11/14/22, 12:18 PM, "Pawel Kowalik" wrote:

Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-03.txt

Gavin, How about providing the feature for the client to unset the custom TTL via an empty element instead of adding a new element that would require the server to manage the expiry? This way the client is in complete control over exactly when the custom TTL value is in place. The ability t

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

On 11/16/22, 12:14 PM, "Pawel Kowalik" wrote: Hi James, See my feedback below. Am 15.11.22 um 21:15 schrieb Gould, James: > [...] > > JG - The use of placeholder values for redaction is prohibited based on the second normative sentence. The normative langua

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

, 2022 at 5:58 AM To: James Gould , "draft-ietf-regext-rdap-redac...@ietf.org" Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: Review of draft-ietf-regext-rdap-redacted-09 Hi James, My comments also inline. Am 22.11.22 um 14:18 schrieb Gould, James: [...] [PK] Looki

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

Date: Wednesday, November 23, 2022 at 9:23 AM To: James Gould , "draft-ietf-regext-rdap-redac...@ietf.org" Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: Review of draft-ietf-regext-rdap-redacted-09 Hi James, My comments below. Am 23.11.22 um 14:17 schrieb Gould, James: [.

[regext] Posting of Versioning in the Registration Data Access Protocol (RDAP) - draft-gould-regext-rdap-versioning

Based on the discussion that occurred on the mailing list on RDAP extension versioning, Mario Loffredo, Dan Keathley, and I collaborated on the Versioning in the Registration Data Access Protocol (RDAP), which has been posted as draft-gould-regext-rdap-versioning

Re: [regext] [Errata Verified] RFC9083 (7094)

It is clearer to update section 4.1 to reference "lunarNIC" instead of "lunarNIC_level_0", since changing section 2.1 to use "lunarNIC_level_0" incorrectly encourages embedding versioning into the registered RDAP identifiers. At IETF 114, the “RDAP Extension Identifier and rdapConformance” top

Re: [regext] CDS/CDNSKEY vs. EPP update prohibited

Michael, The prohibited statuses apply to client requests, which matches Case 2. The prohibited statuses can apply to client requests via multiple channels (e.g., EPP or Web UI). The prohibited statuses don't apply to server actions (e.g., auto renew, transitioning RGP statuses). Use of CDS/

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

the “redacted” “rdapConformance” value can be returned in the responses. However, I can live with Option #3 where the RFC acknowledges that placeholder text has been used in the past. Thanks, Jody Kolker. From: Pawel Kowalik Sent: Friday, November 25, 2022 1:50 AM To: Gould, James ; draft-ietf-rege

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

verisigninc.com/> From: Jasdip Singh Date: Friday, December 9, 2022 at 9:02 AM To: "Gould, James" , Jody Kolker , "kowa...@denic.de" , "draft-ietf-regext-rdap-redac...@ietf.org" Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Review of draft-i

Re: [regext] Request WGLC for draft-ietf-regext-rdap-redacted

do, but I don’t believe it should be encouraged. 5.b) I consider this a corner case so feel free to ignore it ;-) The VCard label property (as well as the JSContact fullAddress property) is usually derived from the postal address information. When the postal address is partially redacted,

Re: [regext] Request WGLC for draft-ietf-regext-rdap-redacted

WGLC for draft-ietf-regext-rdap-redacted Hi James, please find my comments below. Il 09/12/2022 19:15, Gould, James ha scritto: Mario, Sorry for the delay in responding to your feedback. Thanks for the feedback and below are the responses to it. -- JG [cid:image002.png@01D90E02.1DB1B8

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

hen it's time. > > Best, > > Mario > > Il 09/12/2022 15:30, Gould, James ha scritto: > > Jasdip, > > > > Agreed. If providing clarity around transitioning to the old w

[regext] draft-ietf-regext-rdap-redacted-10 Posted

Hi, The draft-ietf-regext-rdap-redacted-10 was posted that addresses the feedback from Pawel Kowalik and Mario Loffredo. Paul and Mario, thank you for your valued feedback! Since there are many material changes that have been made, I recommend a fresh review. Thanks, -- JG [cid:image00

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

Pawel, Thank you again for your review and feedback. I provide answers 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/19/22, 2:43 AM, "Pawel Kowalik"

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

uot; wrote: Hi James, Please find my comments embedded below. Am 19.12.22 um 14:54 schrieb Gould, James: > On 12/19/22, 2:43 AM, "Pawel Kowalik" wrote: > > Hi James, > > Thanks for posting the new version incorporating the changes. I r

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

"Pawel Kowalik" wrote: Hi James, Am 22.12.22 um 14:51 schrieb Gould, James: > "This document describes an RDAP extension for specifying methods of >redaction of RDAP responses and explicitly identifying redacted RDAP >response fields, using JSON

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

Mario, I don't see any need to add a dependency between draft-ietf-regext-rdap-jscontact and draft-ietf-regext-rdap-redacted, but this does add an interesting case for draft-ietf-regext-rdap-redacted with redacting a required JSON member. Do you see the requirement to be able to redact the re

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

ssed differently. In addition, there is a requirement from calext about keeping uid mandatory. Best, Mario Il 03/01/2023 17:33, Gould, James ha scritto: > Mario, > > I don't see any need to add a dependency between draft-ietf-regext-rdap-jscon

Re: [regext] RDAP queries based on redacted properties

Mario, The JSContact "uid" and the jCard "handle" may be redacted in the entities member of a domain query response, where the entity is returned as a sub-object. Redaction of the JSContact "uid" and the jCard "handle" in the domain query response doesn't impact the query at all. I don't beli

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

AM To: James Gould , "a...@hxr.us" Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-15.txt Hi James, please find my comments in line. Il 04/01/2023 14:49, Gould, James ha scritto: Mario, The re

Re: [regext] RDAP queries based on redacted properties

James Gould , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] RDAP queries based on redacted properties Hi James, please find my comments below. Il 06/01/2023 14:54, Gould, James ha scritto: Mario, The JSContact "uid" and the jCard "handle" may be redacted

Re: [regext] RDAP queries based on redacted properties

text is needed but also signal to the user agent that the "uid" is not very useful. (maybe use the data: URI). -andy On Mon, Jan 9, 2023 at 7:29 AM Gould, James wrote: > > Mario, > > > > My responses are embedded below.

Re: [regext] RDAP queries based on redacted properties

objection on this way to proceed. Looking foward to your feedback. Best, Mario Il 09/01/2023 18:26, Hollenbeck, Scott ha scritto: >> -Original Message- >> From: regext On Behalf Of Gould, James >> Sent: Monday, January 9, 2023 12:08 P

Re: [regext] RDAP queries based on redacted properties

//verisigninc.com/> On 1/11/23, 12:30 PM, "Mario Loffredo" wrote: HI James, please find my comments below. Il 10/01/2023 17:33, Gould, James ha scritto: > Mario, > > This is the disadvantage of leveraging an existing set of contact drafts / RFCs to sa

Re: [regext] RDAP queries based on redacted properties

n, VA 20190 Verisign.com <http://verisigninc.com/> On 1/16/23, 10:44 AM, "regext on behalf of Pawel Kowalik" wrote: Hi, My comment below. Am 11.01.23 um 19:03 schrieb Marc Blanchet: > >> Le 11 janv. 2023 à 12:43, Gould, James a écrit : &g

Re: [regext] draft-ietf-regext-epp-eai-17

Andy, Sorry for the late response to your message. The updates in -17 were made to address the feedback from John Klensin during the IETF Last Call, which included changing the cardinality to the One or Two (ASCII or SMTPUTF8) Option defined in the IETF-115 presented deck (https://datatracker

Re: [regext] draft-ietf-regext-epp-eai-17

1bis%2F <https://secure-web.cisco.com/1Rwn55zElMR6DcPDJ2wK_VtOP2F2WzHFbafAOxv8XEAWuD-Dofddr3I6AXkNBuAtXk2D6d_Zw_4LXzY1OxvQGooeMOuPh_opniKAuRBKEdzRNxooZbmHeL1llBex6fRU7BCtGKK_ZVkbMkc-x1EsyANc9NYocExYKEzBvgr-W0GlFVYlUZPYVjCOcxkHapOCcregc4M6tslzWzRsBUMv6mRT7I80tU3smrkr5jngZ2zeM8SwpVIG_w2TRgPFjV4l25gquO41Vf5IeNDkXWmo-3jCOOZWEC5z-M5gXBDgpH5U/https%3A%2F%2Fdatatracker.ietf.org%2

Re: [regext] WGLC: draft-ietf-regext-datadictionary-03

I agree with Scott's feedback on the track being changed to Informational and removal of the IANA Registry. Why doesn't this draft match the approach taken io RFC 8499 for DNS Terminology? The Registration System terms can certainly have overlap with the DNS terms in RFC 8499, where the RFC

Re: [regext] WGLC: draft-ietf-regext-datadictionary-03

e existence of a registry of available data elements does not mean that every registry has to use all of the data elements. Thanks, Steve On Tue, Feb 14, 2023 at 11:02 AM Gould, James mailto:40verisign@dmarc.ietf.org>> wrote: I agree with Scott's feedback on the track being changed t

Re: [regext] WGLC: draft-ietf-regext-datadictionary-03

mes I see the value in the registry as I expect this set of information will change over time. Having this structured data/information in one place for all to refer feels simpler than multiple RFCs. tim On Fri, Feb 17, 2023 at 9:02 AM Gould, James mailto:40verisign@dmarc.ietf.org>&g

Re: [regext] WGLC: draft-ietf-regext-datadictionary-03

;Hollenbeck, Scott" , "st...@shinkuro.com" , "regext@ietf.org" Subject: [EXTERNAL] Re: Re: [regext] WGLC: draft-ietf-regext-datadictionary-03 On Fri, Feb 17, 2023 at 10:28 AM Gould, James mailto:jgo...@verisign.com>> wrote: Tim, The terms could change, but I hav

[regext] draft-ietf-regext-epp-eai Path Forward

I’ve discussed the path forward for draft-ietf-regext-epp-eai with some working group participates and I have concern of the current path that the draft is taking with the support for an alternate e-mail address, whether it be either ASCII, SMTPUTF8, or either. There are system and policy impac

Re: [regext] draft-ietf-regext-epp-eai Path Forward

F8 or ASCII address, I can support option #1. That probably means that we need to think about future work to support multiple email addresses. Scott From: regext On Behalf Of Gould, James Sent: Thursday, March 2, 2023 7:50 AM To: regext@ietf.org Subject: [EXTERNAL] [regext] draft-ietf-regext-epp-

Re: [regext] draft-ietf-regext-epp-eai Path Forward

xt@ietf.org" Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-eai Path Forward I support Jim’s proposal – the “cardinality of two” option is unnecessarily complex and would require more work to implement on client and server side for little benefit. G. On Thursday, March 2, 2023 a

[regext] Requesting a WGLC on draft-ietf-regext-rdap-redacted

Hi, I’m requesting a WGLC on draft-ietf-regext-rdap-redacted. There are no remaining work items, and all feedback has been addressed. Thanks, -- JG [cid:image001.png@01D95582.6C0E82A0] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisig

[regext] Change eai references to smtputf8 in draft-ietf-regext-epp-eai

Hi, As we are working on -18 to roll back the approach to -16 (Cardinality of One), one feedback item is associated with changing all eai references to smtputf8, which includes: 1. Change urn:ietf:params:xml:ns:epp:eai-1.0 to urn:ietf:params:xml:ns:epp:smtputf8-1.0 (2 places) 2. Change

Re: [regext] New Version Notification for draft-regext-brown-epp-related-objects-00.txt

Gavin, Upon my first review, I find the extension to be an interesting aggregation concept. I’m not exactly sure why the client wouldn’t just make separate calls to get the same information. With that, I have the following feedback: 1. I don’t see the purpose of the child element of the

Re: [regext] Redacting JSContact uid in RDAP

Mario, Thank you for posting the options to the list. I'll mirror the preference that I stated at the REGEXT meeting, which is option 2 "Making uid optional in RDAP and then redacting by Removal method". Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061

Re: [regext] jCard to JSContact transition

Mario, I have an option 3, which is to leverage the help response to signal what is supported and what the policy is of the server instead of overloading the purpose of the rdapConformance and notices for the transition signaling. Look at section 6.2 "versioning-help" Member of draft-gould-r

[regext] draft-gould-regext-rdap-versioning Feedback Meeting

Based on feedback received on draft-gould-regext-rdap-versioning at the IETF-116 REGEXT meeting, Scott Hollenbeck, Dan Keathley, Andy Newton, Jasdip Singh, and I met to discuss it. The feedback and the results of the meeting include: 1. Ensuring that the versioning extension is an opt-in

Re: [regext] Fwd: [Ext] Re: Redacting JSContact uid in RDAP - Updated

Mario, I agree if you can’t remove the mandatory UID field to comply with the JSContact specification and are forced to use a literal value (placeholder text) than the Redaction by Replacement Value Method is the best route to go for redaction, since it explicitly signals the use of replacement

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

Andy, I used https://jsonpath.com to validate the expressions against the pre-redacted response in the draft. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 4/26/23, 11:56 AM, "reg

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

ninc.com/> On 4/26/23, 12:46 PM, "regext on behalf of Gould, James" mailto:regext-boun...@ietf.org> on behalf of jgould=40verisign@dmarc.ietf.org <mailto:40verisign@dmarc.ietf.org>> wrote: Andy, I use

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

I don't believe we're using advanced features of JSONPath in draft-ietf-regext-rdap-redacted and jsonpath.com has been used to validate the included examples. If there is a better tool to use, please let me know and I'll validate the examples with it. Otherwise, I believe we can continue to l

Re: [regext] creating invalid RDAP with redaction

Andy, Yes, JCard certainly added complexity to the draft __. I believe a statement can be broader than RFC 9083 to state something like the following at the start of Section 3: "Redaction in RDAP can be handled in multiple ways. The resulting redacted RDAP response MUST comply with the RDAP

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

Tom, Thank you for your review and feedback. In relation to the example JSONPath in the draft, they are based on the unredacted RDAP lookup response in Figure 11 and are snippets from the redacted RDAP lookup response in Figure 12. They are not intended to provide an example for a broader

Re: [regext] RFC 5731 and Domain Object Deletion

Scott, I see value with addressing this. I would broaden the scope to also include RFC 5732 language: A host name object SHOULD NOT be deleted if the host object is associated with any other object. For example, if the host object is associated with a domain object, the host object SHOULD

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

:regext-boun...@ietf.org>> On > Behalf Of Tom Harrison > Sent: Thursday, May 4, 2023 8:36 PM > To: Gould, James mailto:jgo...@verisign.com>> > Cc: ietf=40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org>; > regext@ietf.org <mailto:regext@ietf.org>

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

t; wrote: Hi James, On Fri, May 19, 2023 at 12:48:11PM +, Gould, James wrote: > On Fri, May 05, 2023 at 10:36:18AM +1000, Tom Harrison wrote: >> On Wed, May 03, 2023 at 07:50:07PM +, Gould, James wrote: >>> In relation to the example JSONPath in the draft, they are

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

20190 Verisign.com <http://verisigninc.com/> On 5/22/23, 7:07 PM, "Tom Harrison" mailto:t...@apnic.net>> wrote: Hi James, On Mon, May 22, 2023 at 09:08:53PM +, Gould, James wrote: > On 5/22/23, 8:12 AM, "Tom Harrison" mailto:t...@apnic.net> > <mail

Re: [regext] Thoughts on the fundamental premise of JSContact

Andy, I believe creating a simple RDAP extension for contacts (Path-forward #A) is best. jCard and JSContact are much more generic and complex than what is needed. The mandatory UID field of JSContact is a perfect example of how the intended purpose of JSContact does not meet the needs of RDA

Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt

Andy, Thanks for creating the draft, below is my feedback: 1. Section 2 “RDAP Extension Identifier” * It would be better to refer to JSON members instead of JSON attribute names to be more consistent with RFC 9083. * I would make it clear that the extension identifier can pr

Re: [regext] status draft-ietf-regext-rdap-redacted-12

Jim, I missed Jasdip's May 25th e-mail that I'm going through now. Based on what I've reviewed thus far they are editorial changes that should be included in v13. I plan on replying to Jasdip's May 25th e-mail today. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-327

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

Jasdip, Sorry, I must have completed missed your May 25th message. Below are my responses to your feedback. Your feedback would need to be reflected in draft-ietf-regext-rdap-redacted-13. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way

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

nations. Jasdip On 6/26/23, 3:17 PM, "Gould, James" mailto:jgo...@verisign.com> <mailto:jgo...@verisign.com <mailto:jgo...@verisign.com>>> wrote: Section 1: "The redacted JSON fields will either be removed or have empty values in the RDAP response.&qu

  1   2   3   4   5   6   7   8   >