Re: [regext] WGLC: draft-ietf-regext-epp-ttl-08

I support publication, so +1. Upon a re-review of -08, and I have the following nit feedback: Section 1.2.1.2 “Supported DNS record types” "This eliminates the need to update this document in the event that new DNS records that exist above a zone cut (Section 7 of [RFC9499]) see is

Re: [regext] Registration Protocols Extensions (regext) WG Interim Meeting: 2024-05-07

Andy, We use the unavailable check reason to describe the blocked IDN variant case. We have the Related Domain Extension (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v01.html) that could be used to manage related domain names (e.g., intra-TLD related

Re: [regext] Re-chartering REGEXT?

Andy, REPP is not a transport, but a new provisioning protocol that is not supported in the existing charter. If you believe REPP is a transport, please describe how it complies with section 2.1 of RFC 5730. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com

Re: [regext] EPP evolution and the REGEXT charter

Maarten, The scope of an EPP transport is limited and is specifically defined in Section 2.1 of RFC 5730. Defining a stateless protocol that has additional options for the command and response format is not EPP and not an EPP transport. SMTP being referenced in RFC 5730 doesn't make it a

Re: [regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback

t is safe. Thanks, James. But, to your “use of redaction is a policy decision for a server” point, since this spec would no longer espouse redaction for geofeed files, should it instead say that “server operators SHOULD NOT redact geofeed files given they are public resources already”? Jasdip

Re: [regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback

42 AM To: Jasdip Singh Cc: Gould, James , regext@ietf.org Subject: Re: [regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback > I recommend including a registration of the "Geofeed links" redacted "name" > in the RDAP JSON Values registry with the "redacted name

Re: [regext] EPP evolution and the REGEXT charter

not due to an unorthodox definition of what is > and what is not an EPP extension, be aware that there is plenty of > text in the current RFCs that define more strictly the nature of an > EPP extension. > > > I also take a more inclusive view that REPP could be covered under the

Re: [regext] EPP evolution and the REGEXT charter

m EPP or RDAP. -andy On Fri, Mar 22, 2024 at 8:01 AM Gould, James mailto:jgo...@verisign.com>> wrote: > > Andy, > > It's not a question of fairness, but a question of what is defined in EPP RFC > 5730 as it comes to extensibility of EPP. EPP RFC 5730 includes extensibili

Re: [regext] EPP evolution and the REGEXT charter

mailto:40verisign@dmarc.ietf.org>>, > maarten.wullink=40sidn...@dmarc.ietf.org <mailto:40sidn...@dmarc.ietf.org> > mailto:40sidn...@dmarc.ietf.org>>, > regext@ietf.org <mailto:regext@ietf.org> <mailto:regext@ietf.org>> > Subject: Re: [regext

Re: [regext] EPP evolution and the REGEXT charter

Maarten, The charter refers to EPP extensions, which transports is a form of an EPP extension. RFC 5730 defines the extension points for EPP and includes support for extending the transports based on Section 2.1 “Transport Mapping Considerations”. I don’t believe that there is a need to

Re: [regext] EPP Transport Service Discovery

We can look to add a section on signaling within the EoH and EoQ drafts that leverages the SVCB record. I believe the rate limiting and exclusivity or non-exclusivity on a single transport as server policy and out of scope for the definition of the transports. Thanks, -- JG

Re: [regext] EPP Transport Service Discovery

+1 We’ve had experience of adding and removing transports many years ago and it was done with adequate notice to the registrars. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190

[regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback

Ahead of the REGEXT meeting later today, I took the opportunity to review draft-ietf-regext-rdap-geofeed-02. Overall, I found the extension to cover some useful aspects for implementers. Below is my review feedback that can be further discussed at the meeting: 1. It's interesting that

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-06.txt

Gavin, Thank for posting -06. I have reviewed the draft and updated the implementation of it. Below is my feedback: 1. Nit - The last example in section 2.1.1.1 is mislabeled and should be “Example host response…”. Also, do you want the TTL value for the “A” record to match that of

Re: [regext] Wording suggestion for draft-regext-epp-eai

Arnt, Thank you for your review and input. I believe the content that you propose would be best suited for an Implementation Considerations section. There are many options related to addressing the risk of registry database storage issues, based on the chosen database and persistence

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

Mario, Thanks for posting draft-loffredo-regext-epp-over-http-03. Also, thanks Jiankang for posting draft-yao-regext-epp-quic-01. Dan Keathley and I are working with Mario and Jiankang to add viable options for EPP transports that are fully compliant with RFC 5730 as transports and

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-05.txt

ponse when the ttl has explicitly been set and ttl in in the login services, and provides the option to get the policy information via an extension to the info command, then it would use a mix of option 2 and option 3. Thanks, Gavin. > On 31 Jan 2024, at 15:29, Gould, James <mailto

Re: [regext] CALL FOR ADOPTION: draft-gould-regext-rdap-versioning draft-newton-regext-rdap-extensions draft-newton-regext-rdap-x-media-type

+1 and same goes for reviewing the rdap-extensions and x-media-type drafts. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 2/5/24, 10:15 AM, "regext on behalf of Jasdip Singh"

Re: [regext] CALL FOR ADOPTION: draft-hollenbeck-regext-epp-delete-bcp

Pawel, On the question of whether 5.2.2.4 "Inform Affected Clients" and 5.2.2.5 "Allow Explicit Delete of Domain with Restore Capability" and the need for new EPP extensions to support them, below are my thoughts. The difference between the two options is the object that is deleted (host in

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-05.txt

Gavin, Thanks for making the updates to draft-ietf-regext-epp-ttl-05. I did find one issue with the XML schema, where needs to be . I would prefer making the "policy" attribute optional with a default value of "false", as in: I would then change the description in section 1.3 to be: It

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

"Tom Harrison" mailto:t...@apnic.net>> 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. Hi James, Thanks for your feedback. Comments on non-nits inlin

Re: [regext] WG Adoption Request: draft-hollenbeck-regext-epp-delete-bcp

I support adoption and I will review and provide feedback to the draft. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com From: regext on behalf of

Re: [regext] [Ext] TTL extension for RDAP

Gavin & Andy, The TTL RDAP extension is now getting more complex with no defined value provided for the extension. I have a set of questions included below: 1. Are there any ccTLDs or RIRs (non-EPP) that have the value position for replicating the TTL information in RDAP? Please provide a

Re: [regext] FW: I-D Action: draft-hollenbeck-regext-epp-delete-bcp-02.txt

Scott, I support adoption of the draft since it's important for the community to resolve this in a consistent manner. Below is my feedback to the changes in -02: 1. Section 3.1.1 “Impact of Glue Policies” * I believe this section is interesting, but I don’t see the correlation

Re: [regext] [Ext] TTL extension for RDAP

Jim, > On 3 Jan 2024, at 15:53, Gould, James <mailto:jgo...@verisign.com>> wrote: > > Andy, > > The TTL is an extension to the domain name update, so they are not > independent. The draft explicitly states that TTLs may be changed out-of-band. The Change Poll ext

Re: [regext] [Ext] TTL extension for RDAP

ed": true, "delegationSigned": true, "maxSigLife": 604800, "keyData": [ { "flags": 257, "protocol": 3, "algorithm": 8, "publicKey": "AwEAAa6eDzronzjEDbT...Jg1M5N rBSPkuXpdFE=", "events": [ { "eventAction

Re: [regext] [Ext] TTL extension for RDAP

;> 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. Hi Jim, > On 2 Jan 2024, at 14:52, Gould, James <mailto:jgo...@verisign.com>> wrote: > > Gavin,

Re: [regext] TTL extension for RDAP

Gavin, I question the need for a TTL RDAP extension, since the TTLs are easily assessable in DNS to the public. The management of the TTLs is provisioned in EPP via the TTL EPP extension and can be made available to the registrant by the registrar. There are examples of DNS information

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-04.txt

Gavin, Thanks for making the updates in draft-ietf-regext-epp-ttl-04. I went ahead and implemented draft-ietf-regext-epp-ttl-04 in the Verisign EPP SDK that implements a client and a server. I did find the following issue: The “commandTTLType“ is missing the optional “custom” attribute

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

Antoin, I did my review of draft-ietf-regext-rdap-rir-search-05, and below is my primarily editorial feedback: 1. Section 1.1 “Requirements Language” * Recommend make this Section 2 “Conventions Used in This Document” for consistency with the RDAP RFCs. I also recommend defining

Re: [regext] ACTION REQUESTED: Re: RDAP-X draft adoption

Jim and Antoin, I support having an interim meeting to discuss. I see distinct problems being solved by the three drafts draft-gould-regext-rdap-versioning, draft-newton-regext-rdap-extensions, and draft-newton-regext-rdap-x-media-type. I highlight them below to prime the discussion: 1.

[regext] draft-gould-regext-rdap-versioning-02 Posted

The -02 version of the RDAP Versioning Extension (draft-gould-regext-rdap-versioning) has been posted with substantial changes based on feedback received and to compliment draft-newton-regext-rdap-extensions and draft-newton-regext-rdap-x-media-type. The changes include defining a base set of

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-03.txt

Gavin, Thank you for posting draft-ietf-regext-epp-ttl-03. Below is my review feedback: 1. Section 1.2 “Extension elements” * Nit – I would change “It has a single REQUIRED attribute, for, which specifies the DNS record type to which the TTL value pertains” to “It has a single

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

Tom, Thanks for posting the update. The registered extension identifiers for the extension path segments and members align with the based RFCs. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com

Re: [regext] draft-ietf-regext-rdap-rir-search Feedback

email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi James, On Mon, Nov 20, 2023 at 09:46:32PM +, Gould, James wrote: > Thanks for making the change. The only adjustment I

Re: [regext] draft-ietf-regext-rdap-rir-search Feedback

unless you recognize the sender and know the content is safe. Hi James, On Mon, Nov 13, 2023 at 03:02:34PM +, Jasdip Singh wrote: > On Thu, Nov 09, 2023 at 08:34:57PM +, Gould, James wrote: >> After the IETF-118 REGEXT meeting, I found this message that I >> never

Re: [regext] CALL FOR ADOPTION: draft-jasdips-regext-rdap-geofeed

+1 -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 11/20/23, 11:57 AM, "regext on behalf of Hollenbeck, Scott" mailto:regext-boun...@ietf.org> on behalf of

Re: [regext] Roman Danyliw's No Objection on draft-ietf-regext-rdap-redacted-14: (with COMMENT)

ttp://verisigninc.com/> On 11/10/23, 3:58 AM, "Gould, James" mailto:jgo...@verisign.com>> wrote: Roman, Thank you for the feedback. I provide responses to your feedback embedded below that can be included in -16 prior to moving onto the RFC editor. Let me know whether yo

Re: [regext] I-D draft-latour-pre-registration

Jacques, Very interesting brain teaser. I concur with Jody that for performing the verification in the registration, the pending create model via the 1001 response to the domain create can be used to perform the server-side verification if it cannot be done immediately along with the pending

Re: [regext] RDAP-X draft adoption

ive? Anway, Jasdip already answered your broader question, and now you are asking for discussion on hypotheticals that are likely to meander. For the sanity of the list, perhaps we should take a time-out. -andy On Thu, Nov 16, 2023 at 12:17 PM Gould, James mailto:jgo...@verisign.com>> wro

Re: [regext] RDAP-X draft adoption

environments a local bootstrap service is beneficial as it cuts down on the bandwidth/latency of every client grabbing the bootstrap files. -andy On Wed, Nov 15, 2023 at 2:04 PM Gould, James mailto:jgo...@verisign.com>> wrote: > > Andy, > > You claim that there is an

Re: [regext] RDAP-X draft adoption

drew Newton" mailto:a...@hxr.us>> 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. On Wed, Nov 15, 2023 at 11:19 AM Gould, James mailto:jgo...@verisign.com>>

Re: [regext] RDAP-X draft adoption

; , "a...@hxr.us" Subject: [EXTERNAL] Re: [regext] RDAP-X draft adoption 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. James, Please find below my comments. F

Re: [regext] RDAP-X draft adoption

K7dX0xI/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-newton-regext-rdap-x-media-type-01.html%23name-design-considerations> From: "Gould, James" Date: Tuesday, November 14, 2023 at 7:46 PM To: Jasdip Singh , "regext-cha...@ietf.org" Cc: "regext@ietf.org" ,

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

Andy, I don't believe that RDAP was designed just for redirection services, and I simply don't understand why the redirection services can't preserve the query parameters. Section 5.2 of RFC 7480 makes no mention of query parameters and states that the server "is to hand back a complete URL",

Re: [regext] RDAP-X draft adoption

I don’t support adoption at this point until there is consensus around the use of query parameters for all RDAP queries, including RDAP searches and lookups. This is an item that could be added to a section in draft-newton-regext-rdap-extensions, but I certainly don’t agree with the

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

Andy, I recommend covering the use of query parameters in RDAP in the draft-newton-regext-rdap-extensions, since it's unclear and deserves discussion on the mailing list. I personally don' t see how the use of query parameters would not be compatible in RDAP, since RDAP is simply a REST

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

We also implemented the signal in section 5 of draft-gould-regext-rdap-versioning, using the "versioning" query parameter. We intend to make draft-gould-regext-rdap-versioning more generic to support opaque versioning (use of extension identifier only) and semantic versioning (extension

[regext] draft-hollenbeck-regext-epp-delete-bcp "Allow Explicit Delete of Domain with Restore Capability" option

Based on the desire from Scott Hollenbeck at the IETF-118 REGEXT meeting for discussion on the list with the options defined in draft-hollenbeck-regext-epp-delete-bcp, I’m posting this to discuss the “Allow Explicit Delete of Domain with Restore Capability” option

Re: [regext] Roman Danyliw's No Objection on draft-ietf-regext-rdap-redacted-14: (with COMMENT)

Roman, Thank you for the feedback. I provide responses to your feedback embedded below that can be included in -16 prior to moving onto the RFC editor. Let me know whether you agree with the edits and clarifications. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com

Re: [regext] draft-ietf-regext-rdap-rir-search Feedback

4Hotr-KiTSIS7VqR3NLEDmwI3TneX53e07EEbd02AjS-xdPkvvJNJINtX3vLSiFGxHX2kFJldVqBkmaqsbRi2uRt_uTsyBe-VTxCCa837ksUk7zGfI7EcBtHaXfwsVpMDvBuIkFtLUd8AQcnO4VoCd98ilBnzycPFBBtNulvGSlAbzcXaSt7hkoQJgMJRA2EaRt_fwnMJZWy_CwYiu4xhYA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-extensions%2F> From

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

Andy Newton mentioned an issue with -19, where the rollback to -17 removed the updates made to the Security Considerations section in -18, which is addressed in -20. Thanks Andy! -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext on behalf of "Gould, James" Date: Friday, August 18, 2023 at 3:06 PM To: "gal...@elistx.com" Cc: "beld...@gmail.c

Re: [regext] Paul Wouters' Discuss on draft-ietf-regext-rdap-redacted-14: (with DISCUSS and COMMENT)

Paul, Thank you for the review and feedback. I provide a response to your feedback embedded below. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 9/21/23, 9:09 AM, "Paul

Re: [regext] [IANA #1280008] expert review for draft-ietf-regext-rdap-redacted (rdap-json-values)

@dmarc.ietf.org <mailto:40verisign@dmarc.ietf.org>> 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. > -Original Message- > From: regext mailto:regext-

Re: [regext] [IANA #1280008] expert review for draft-ietf-regext-rdap-redacted (rdap-json-values)

ey can't be added as part of the expert review process. Either 9083 needs to be updated, or the registry needs to be updated to note that additional type values are defined in this RFC-to-be. Updating the registry may be the better option. Scott > -Original Message- > From: r

Re: [regext] [IANA #1280008] expert review for draft-ietf-regext-rdap-redacted (rdap-json-values)

Scott, I foresee the need for defining new JSON Values Registry Type values that are associated with new RDAP extensions. It looks like draft-ietf-regext-rdap-redacted is the first to do this for the three new types "redacted name", "redacted reason", and "redacted expression language".

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

ly two are present they are semantically the same thing. Please help me understand how this is a policy statement? Jim On 18 Aug 2023, at 14:39, Gould, James wrote: Jim, This moves the protocol too far into policy. Let policy define when an ASCII email is needed. Based on the back-and

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

erently. However, this gets us what we need within the model that we have. Jim On 8 Aug 2023, at 16:03, Dmitry Belyavsky wrote: Dear Arnt, On Sun, 6 Aug 2023, 13:39 Arnt Gulbrandsen, mailto:a...@gulbrandsen.priv.no>> wrote: Thursday, 3 August 2023 20:14:41 CEST writes: > On Thu, Aug 3, 202

Re: [regext] Publication has been requested for draft-ietf-regext-rdap-redacted-13

Murray, Thanks for the review. My feedback is included embedded below. We can post draft-ietf-regext-rdap-redacted-14 once you agree with the needed updates. Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

ular context. The mention of transition period would not be needed in this case. Kind Regards, Pawel Am 03.08.23 um 20:14 schrieb Andrew Newton: > On Thu, Aug 3, 2023 at 1:23 PM Gould, James <mailto:jgo...@verisign.com>> wrote: >> So, rollback to draft-ietf-reg

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

So, rollback to draft-ietf-regext-epp-eai-17 with the concept of a transition period removed and inclusion of "at least one of the email values MUST be an ASCII address"? -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

s simple, sound, and ensures that everyone has the option to do things according to their local policy. Jim On 27 Jul 2023, at 9:48, Gould, James wrote: Based on the discussion that occurred at the IETF-117 REGEXT meeting, I took the action item to cover the topic of the alternate ASCII e-m

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

email can fail as well, so this should not change business practices. This sounds good to me, James. -andy On Thu, Jul 27, 2023 at 9:48 AM Gould, James mailto:40verisign@dmarc.ietf.org>> wrote: > > Based on the discussion that occurred at the IETF-117 REGEXT meeting, I took &g

[regext] Proposed update to draft-ietf-regext-epp-eai

Based on the discussion that occurred at the IETF-117 REGEXT meeting, I took the action item to cover the topic of the alternate ASCII e-mail. To address this, I defined a new “Alternate Communication Considerations” section with the following content for consideration: RFC 6530 [RFC6530]

Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

M. On Jul 26, 2023, at 6:22 AM, Gould, James wrote: James, I find your historic EPP server policies to be very interesting. I provide comments embedded with your points below with a “JG – “ prefix. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Rest

Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

com/> On 7/26/23, 1:26 PM, "Peter Thomassen" mailto:pe...@desec.io>> 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. James, On 7/26/23 06:

Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

James, I find your historic EPP server policies to be very interesting. I provide comments embedded with your points below with a “JG – “ prefix. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190

[regext] draft-newton-regext-rdap-simple-contact Feedback

Andy & Tom, Thank you for posting draft-newton-regext-rdap-simple-contact. I prefer having a simple contact extension that meets the minimal needs for DNRs, by being capable of representing contact EPP RFC 5733 data, and the minimum needs for INRs. Below is my initial set of feedback from

[regext] draft-ietf-regext-rdap-rir-search Feedback

Tom & Jasdip, Ahead of the REGEXT meeting this afternoon, I did a review of draft-ietf-regext-rdap-rir-search and below is my feedback: 1. I believe that the search for ips and autnums should have been included in RFC 9082 from the start, but I’m glad that you’re looking at add support in

[regext] draft-ietf-regext-epp-ttl Feedback

Gavin, Ahead of the REGEXT meeting, I did a fresh review of draft-ietf-regext-epp-ttl and below is my feedback: 1. Section 2 "Extension elements" * Nit - "(b) in and commands, that the client wishes to remove a previously set value, in favour of the default value.". I would

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

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. Hi James, Thanks for the review. My response is in-line. On Mon, Jul 24, 2023 at 11:10 AM Gould, James mailto:jgo...@verisign.com>&g

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

Andy, In reviewing draft-newton-regext-rdap-x-media-type-00 ahead of the REXEXT meeting tomorrow, I have the following feedback: 1. Are you saying that RDAP cannot use query parameters due to the cases that you present in the draft? 2. What should be done with the use of query

Re: [regext] client discovery of server features (was Re: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt)

com/> On 7/13/23, 9:00 AM, "Andrew Newton" mailto:a...@hxr.us>> 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. On Thu, Jul 13, 2023 at 8:25 AM G

Re: [regext] client discovery of server features (was Re: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt)

In draft-gould-regext-rdap-versioning, we were looking to provide meta-data about the supported RDAP extensions and their versions, and our interpretation was the same from RFC 9082 to extend the "help" for that purpose. The meta-data can at a minimum help with troubleshooting and can be

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

rganization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi James, > On 30 Jun 2023, at 12:49, Gould, James <mailto:40verisign@dmarc.ietf.org>> wrote: > > Ties, > > That paragraph in section 3.1 is m

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

_ information. Could you clarify the intended behaviour in this case? Kind regards, Ties de Kock > On 29 Jun 2023, at 17:42, Gould, James <mailto:40verisign@dmarc.ietf.org>> wrote: > > Jim, > > Jasdip Singh's feedback has been incorporated into > draft

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

Jim, Jasdip Singh's feedback has been incorporated into draft-ietf-regext-rdap-redacted-13. I believe that all feedback has been addressed. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com

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

ns. 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.&quo

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

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

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

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

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> > <mailto:t.

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

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

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

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

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

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

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 used ht

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,

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

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

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

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

[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

[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

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

  1   2   3   4   5   6   7   >