[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt

q0aAlYzlnN1pxx53pQFlcxZeQ/https%3A%2F%2Fgithub.com%2Fanewton1998%2Fdraft-regext-rdap-extensions%2Fpull%2F30%2Ffiles> Let me know what you think. -andy On 8/23/24 10:00, Gould, James wrote: > Andy, > > It may be useful to include guidance for RDAP extensions use of the RDAP JSON >

[regext] Re: Review of draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions

stay. Since the Versioning draft introduces a new term “extension version identifier” beside the standard “extension identifier” term, as part of the normative language beefing up, that would need addressing in the other drafts. Thanks, Jasdip From: Gould, James Date: Tuesday, August 20, 20

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt

ization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 8/20/24 09:15, Gould, James wrote: > Andy, > > In reviewing the updates to draft-ietf-regext-rdap-extensions, I believe that > we need to reconsider the criteria for t

[regext] Re: ccTLDs using EPP

I agree that changing the EPP XML URIs or customizing the XML schema files, where backward compatibility is not maintained, is not EPP. I had to modify the EPP XML schemas a couple times (e.g., support I-D RGP "(pre/post)Whois" elements and the RGP RFC "(pre/post)Data" elements during a transit

[regext] Re: Review of draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions

*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: "Gould, James" Date: Monday, July 22, 2024 at 10:59 AM To: "regext@ietf.org" Subject: [EX

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt

Andy, In reviewing the updates to draft-ietf-regext-rdap-extensions, I believe that we need to reconsider the criteria for the RDAP JSON Registry values. Based on the types initially defined, the use of lowercase only values may make sense, but for the recently registered values from the RDAP

[regext] Re: I-D Action: draft-ietf-regext-rdap-geofeed-06.txt

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, On Wed, Jul 31, 2024 at 03:02:50PM +, Gould, James wrote: > Thanks for removing the RECOMMENDED for i

[regext] Re: I-D Action: draft-ietf-regext-rdap-geofeed-06.txt

Jasdip, Thanks for removing the RECOMMENDED for inclusion of the “geofeed1” extension identifier. I’m not clear whether requiring the inclusion of the “geofeed1” extension identifier aligns with the paragraph in the same section: Extension identifier inclusion is not mandatory, because RDAP doe

[regext] Re: [Ext] DSYNC in EPP

There are a couple EPP Extension RFCs that may be of use with the Organization Mapping in RFC 8543 and Organization Extension in RFC 8544 that do support the definition and linkage of multiple organization types to registry objects, such as Resellers and DNS Providers. The Organization Mapping

[regext] Re: RESTful EPP Charter side meeting Thursday 13:00

h in my mind. And yes the Design Considerations require further work to be more specific and reflect what was discussed yesterday and what will be for sure further discussed in regext or in to-be-WG. Kind Regards, Pawel On 25.07.24 08:26, Gould, James wrote: Pawel, It relates since there is a qu

[regext] Re: RESTful EPP Charter side meeting Thursday 13:00

13:00 Yes Jim, I am only not sure how this relates to what I've written. Kind Regards, Pawel On 25.07.24 07:37, Gould, James wrote: Pawel, REPP is clearly not EPP and not an EPP extension (not a transport compliant with RFC 5730 section 2.1, not any of the EPP extension types defined in RF

[regext] Re: RESTful EPP Charter side meeting Thursday 13:00

P is not going anywhere so this is a reasonable approach to assume the implementers would take. Actually it is even expressed in Design Considerations section of draft-wullink-restful-epp already, just maybe not that straightforward and got lost in the discussion. Kind Regards, Pawel On 25.07.24 0

[regext] Re: RESTful EPP Charter side meeting Thursday 13:00

I view two options for meeting the goals of REPP, which I believe is to have a more Cloud-friendly provisioning protocol: 1. Incremental Approach * Implement incremental changes to EPP that make it more Cloud-friendly, which does need to be fully compliant with the EPP RFCs. This inc

[regext] Re: Review of draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions

n of that second question. Please come prepared on Wednesday to discuss the first question. There will be Chair slides later today with more details. Thanks, Jim co-Chair REGEXT On 22 Jul 2024, at 7:59, Gould, James wrote: Hi, I did a detailed review of the three drafts draft-ietf-regext

[regext] Review of draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions

Hi, I did a detailed review of the three drafts draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions for alignment. The following are my findings: 1. draft-ietf-regext-rdap-versioning includes support for draft-ietf-regext-rdap-x-me

[regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05

I've reviewed the draft again, and below is my only review feedback: Section 2.3 "Extension Identifier": The inclusion of the "geofeed1" extension identifier in the "rdapConformance" should be a MUST instead of RECOMMENDED when the RDAP server returns geofeed link objects in accordance with the

[regext] Re: Does section 3.7 of RFC 8748 forbid standard fees for non-standard (aka premium) domains?

Thomas, I agree that the class is at the domain-level attribute and not at the command-level attribute, that why it's placed as a sibling element of the objID element. The "standard" attribute was added at the command-level to support a mix of standard and non-standard fees for a non-standard

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

we should not ignore this. Jasdip From: Gould, James Date: Monday, June 17, 2024 at 10:38 AM To: Jasdip Singh , mario.loffr...@iit.cnr.it Cc: regext@ietf.org Subject: Re: Re: [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt From: Gould,

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

e the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi James, Please find my comments below. Thanks, Jasdip From: Gould, James Date: Monday, June 17, 2024 at 7:47 AM To: Jasdip Singh , mario.loffr...@iit.cnr.it Cc: re

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

(andy)" 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 6/14/24 14:59, Hollenbeck, Scott wrote: >> -Original Message- >&

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

Jasdip, I have option 5, which is to get more implementation experience with RFC 9537. I believe that the ICANN clients can implement RFC 9537 using the required “name” and “method” members in the redacted extension, as I demonstrated with the simple JSON clients. There will be many server im

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

linear style (rdap.org, search.arin.net/rdap, etc...). When time permits, I'll update the draft to more thoroughly cover this topic. -andy On 6/14/24 13:22, Gould, James wrote: > > Andy, > > To help, I provide a couple simple example clients that leverage the > required

[regext] Re: Request for draft-loffredo-regext-epp-over-http (EoH) and draft-yao-regext-epp-quic (EoQ) Review

ike “Look for a record for this new transport, and if you don’t find one, assume EoT”. That may be easier and it’s one less document to write. Scott From: Gould, James Sent: Thursday, June 13, 2024 4:05 PM To: Hollenbeck, Scott ; regext@ietf.org Subject: [EXTERNAL] Re: RE: Request for draft-lof

[regext] Re: Request for draft-loffredo-regext-epp-over-http (EoH) and draft-yao-regext-epp-quic (EoQ) Review

bes how to use the DNS for service discovery by publishing an appropriate SRV or SVCB record. Scott From: Gould, James Sent: Tuesday, June 11, 2024 9:16 AM To: regext@ietf.org Subject: [EXTERNAL] [regext] Request for draft-loffredo-regext-epp-over-http (EoH) and draft-yao-regext-epp-quic (EoQ) Re

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

Gavin, In reviewing -13, the update in Section 1.2.1.2 can be changed to be singular, as in: To facilitate forward compatibility with future changes to the DNS protocol, this document does not enumerate or restrict the DNS record types that can be included in the "custom" attribute of ele

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

2024 at 10:37 AM To: James Gould , "orie@transmute.industries" Cc: "regext@ietf.org" , "regext-cha...@ietf.org" Subject: RE: [EXTERNAL] [regext] Re: draft-ietf-regext-epp-eai update From: Gould, James Sent: Wednesday, June 12, 2024 8:41 AM To: orie@transmute.indu

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

Orie, The draft has implemented multiple approaches to address the feedback from John Klensin, related to the desire to have an all-ASCII email address. I include the approaches below for summary. I believe the protocol should support either an ASCII email address or an SMTPUTF9 email address

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

Andy, The redacted extension provides information to the client of what has been redacted and it's up to the client to determine how to display it. The implementer needs to leverage the entire specification of the RFC, where in section 4.2 ""redacted" Member", it fully defines which of the mem

[regext] Request for draft-loffredo-regext-epp-over-http (EoH) and draft-yao-regext-epp-quic (EoQ) Review

Hi, The draft-loffredo-regext-epp-over-http (EoH) and draft-yao-regext-epp-quic (EoQ) drafts were introduced at the IETF-119 REGEXT meeting. Please review the drafts and provide your feedback on the mailing list or privately. Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Go

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

We evaluated the possible set of JSON expression languages when starting the draft. JSONPointer did not have enough features to meet the need. I still believe that JSONPath is the best expression language to use, but other expression languages can come on the scene and the extension added expr

[regext] Re: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

Newton , Registration Protocols Extensions Subject: [EXTERNAL] Re: [regext] New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Since I’m named below, response inline. Le 29 mai 2024 à 08:57, Gould, James a écrit : Andy, Thank you for providing information on the

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

Andy, Thank you for providing information on the client implementation experience. I will review all the content in detail to provide my thoughts on how to address the issues. Much of your feedback is associated with the complexities of processing the JSONPath expressions, which provides an

[regext] Re: Fwd: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt

Gavin, I mirror the other feedback with the concern over duplicating the link information in the response header that is included in the response body for the HTTP GET. It would be best just to support the HTTP HEAD, but the question I have is whether the use of the HTTP HEAD is appropriate,

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 speci

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 domain

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 703-948-3271

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 true

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

are > in charter but REPP is 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

Re: [regext] EPP evolution and the REGEXT charter

extraction from 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

Re: [regext] EPP evolution and the REGEXT charter

c.ietf.org> <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>> >

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 revis

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 [cid87442*image0

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 Verisign.com

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

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 toolki

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 therefor

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

in the response 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

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" mailt

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 ha

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

PM, "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

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 "Hollenbec

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 co

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 o

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

Hi 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 P

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

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

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

g>> 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: > &

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 duplic

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 fro

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 R

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 would mak

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

nts 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 >> nev

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 shollenbeck=40verisign@

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

isign.com <http://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

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 a

Re: [regext] RDAP-X draft adoption

smissive? 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>> w

Re: [regext] RDAP-X draft adoption

nly non-trivial. For constrained 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, > &g

Re: [regext] RDAP-X draft adoption

, "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 Wed, Nov 15, 2023 at 11:19 AM Gould, James mailto:jgo...@verisign.c

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" , And

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 prohibitio

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 interf

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 identi

[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 (https://datatracker.ietf.org/

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 Veri

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 W

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)

nd they 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- &g

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". With

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

y. 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 Bluemont

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

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 Verisign.c

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

://verisigninc.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,

  1   2   3   4   5   6   7   8   >