[regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04

On 10/9/24 12:02, Hollenbeck, Scott wrote: Are you suggesting we acknowledge this was done in the past, but bar it from the future? What harm do you think is being done here? */[SAH] If we allow every extension to create it’s own rules about how that extension is identified, we’re adding un

[regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04

On 10/8/24 11:12, Jasdip Singh wrote: [SAH] Yes, that's what I'm advocating for. I'd rather change the non-conforming Proposed Standard extensions than update an Internet Standard to validate them. Updating the Proposed Standard will be far more disruptive than updating the optional extensio

[regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search

Scott, This was discussed in this working group on this list by me and others. I even proposed something similar. However, absent some functional deficiency or harm, I do not favor re-opening this issue post WGLC. It may not have been the way I would have done it, but to my knowledge it works

[regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04

Hi James, I think your summation is better than what we have in Section 1.1. We'll work to incorporate this and make other changes. Many thanks for your contribution and review. WRT to other extensions types, I am unfamiliar with any others. -andy On 10/8/24 16:00, Gould, James wrote: Jas

[regext] Re: Questions about draft-ietf-regext-rdap-x-media-type

Mario, Snipping a bunch of stuff :) ... On 10/9/24 03:53, Mario Loffredo wrote: Hi Andy, But, provided that some custom and standard specifications allow a server to return response extensions by itself, I do believe that the document should clarify what the server is expected to do when

[regext] Re: Questions about draft-ietf-regext-rdap-x-media-type

On 10/4/24 04:44, Mario Loffredo wrote: [ML] I was talking about "unrequested extensions" which can be different from "unknown extensions". I remind you that: 1) some custom extensions reported in the RDAP Extensions registry are returned by default, most likely to make the RDAP response cons

[regext] Re: Questions about draft-ietf-regext-rdap-x-media-type

On 10/3/24 13:15, Mario Loffredo wrote: Il 03/10/2024 14:39, Gould, James ha scritto: Andy & Mario, As far as how to handle “rdap_level_0”, this is applicable to both draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-versioning, where we should be consistent.  Based on the p

[regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04

On 10/3/24 08:26, Gould, James wrote: Andy, I view updating the base RFCs as being a material change that would trigger the need for signaling for interoperability via use of “rdap_level_1”. If what is defined maintains backward compatibility with what is defined in the base RFCs, then can

[regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04

On 10/3/24 10:57, Hollenbeck, Scott wrote: On 10/2/24 11:06, Hollenbeck, Scott wrote: I've read draft-ietf-regext-rdap-extensions-04 completely and have several comments to share. An overarching comment is that any update to Standard 95 responses means that the modified responses will not

[regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04

On 10/2/24 11:06, Hollenbeck, Scott wrote: I've read draft-ietf-regext-rdap-extensions-04 completely and have several comments to share. An overarching comment is that any update to Standard 95 responses means that the modified responses will not be consistent with "rdap_level_0". A new identi

[regext] Re: Questions about draft-ietf-regext-rdap-x-media-type

On 10/2/24 12:33, Mario Loffredo wrote: Hi Andy, please find my comments below. Il 02/10/2024 16:24, Andrew Newton (andy) ha scritto: On Tue, Oct 1, 2024 at 3:53 AM Mario Loffredo wrote: Hi Andy and Jasdip, have some questions about draft-ietf-regext-rdap-x-media-type: 1) rdap_level_0

[regext] Re: Questions about draft-ietf-regext-rdap-x-media-type

On Tue, Oct 1, 2024 at 3:53 AM Mario Loffredo wrote: > > Hi Andy and Jasdip, > > > have some questions about draft-ietf-regext-rdap-x-media-type: > > 1) rdap_level_0 is included in "extensions" parameter, but it's not an > extension, i.e. it's not included in the RDAP Extensions registry. Should

[regext] Re: Call for agenda items IETF 121

Hi, Could we have some time to discuss the rdap-extensions draft? -andy On Mon, Sep 30, 2024 at 9:45 AM Antoin Verschuren wrote: > > Dear REGEXT WG, > > This is a call for agenda items for IETF 121. > Just as last time, we will have 2 slots in Dublin. > 1 hour for administrative items and a 2 h

[regext] Re: request for wglc

On Mon, Sep 30, 2024 at 3:36 PM Hollenbeck, Scott wrote: > > I am myself guilty of not providing recent feedback. I'll take care of that > soon. Many thanks, Scott. Given our close proximity to IETF 121, do you think this deserves agenda time? -andy

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

Hi, This version re-organizes the content and rewards some text for readability purposes. The only material change is the removal of the reserved double underscore syntax since it is not being utilized by the versioning draft. The authors believe this draft is ready for working group last call.

[regext] Re: request for wglc [was Re: I-D Action: draft-ietf-regext-rdap-extensions-03.txt]

Hi Chairs, As this WGLC has not been called, the author team requests that WGLC occur after the next update. We are reordering some of the document to make it more readable. Thank you. -andy On Thu, Sep 19, 2024 at 12:16 PM Andrew Newton (andy) wrote: > > Hello chairs, > > Ve

[regext] request for wglc [was Re: I-D Action: draft-ietf-regext-rdap-extensions-03.txt]

Hello chairs, Version -03 of draft-ietf-regext-rdap-extensions incorporates the last discussions regarding this draft on this mailing list. We, the draft authors, believe this draft is ready for working group last call. -andy On Thu, Sep 19, 2024 at 1:11 PM wrote: > > Internet-Draft draft-ietf-

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

On 9/5/24 07:54, Gould, James wrote: Andy, That language looks better. I believe it would be good for draft-ietf-regext-rdap-extensions to cover how new RDAP JSON Values types are defined. The RDAP JSON Values registry can be extended by Type and by Value. The definition of a new RDAP JSON

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

Hi James and Scott, I posted a PR to address your discussion points. https://github.com/anewton1998/draft-regext-rdap-extensions/pull/30/files 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 RD

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

Hi James, On 8/26/24 11:58, Gould, James wrote: I have an issue with the “Query Parameters Considered Harmful” section in draft-ietf-regext-rdap-x-media-type, where query parameters are used in the base RDAP RFCs as well as other RDAP extensions including the Versioning Extension.  If use of q

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

On 8/22/24 10:19, Hollenbeck, Scott wrote: [SAH] Andy, I'd very much prefer that we discuss changes like this BEFORE they appear in a working group draft. I don't necessarily disagree with the suggestions, but if we assume that a working group draft is a reflection of working group consensus i

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

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 the RDAP JSON Registry values. Based on the types initially defined, the use of lowercase only values may make sense, but for the r

[regext] Re: a list of RDAP clients

On 8/20/24 13:46, pmev...@godaddy.com wrote: > [SAH] This is something you're maintaining, Andy? How did you manage to find them all? The genesis of it is explained at https://blog.rcode3.com/blog/a-guide-to-rdap/ The referenced paper at https://pam2024.cs.northwestern.edu/pdfs/paper-89.p

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

Hi all, This new version of the draft has a couple of new sections. Two of the new sections call for the addition of more expert reviewers for the IANA RDAP registries and for the reviewers to check each others work. And the other two sections regard security considerations and privacy cons

[regext] a list of RDAP clients

During the last wg session, there was a question about how many RDAP clients exist. Well, there is now a list of the known implementations. There are, at least, 21 known RDAP clients (not including all the custom scripts) and 20 client libraries: https://rdap.rcode3.com/client_implementation

[regext] Re: normative language and references in draft-ietf-regext-delete-bcp

On 8/12/24 13:25, Hollenbeck, Scott wrote: -Original Message- From: Andrew Newton (andy) Sent: Wednesday, July 31, 2024 11:08 AM To: regext@ietf.org Subject: [EXTERNAL] [regext] normative language and references in draft-ietf- regext-delete-bcp Caution: This email originated from

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

On 8/7/24 09:08, kowa...@denic.de wrote: This is not my point. I'm missing an equivalent to the following part of -06, in particular the 2nd sentence: The "Best Proposed Practices" have not been observed in operation. The analysis presented in this document suggests that they could become be

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

ge request doesn't make sense please let me know. Regards, OS, ART AD On Thu, Aug 1, 2024 at 7:18 AM Hollenbeck, Scott wrote: > -Original Message- > From: kowa...@denic.de > Sent: Wednesday, July 31, 2024 4:46 PM > To: Andrew Newton (andy) ; re

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

On 7/31/24 15:06, kowa...@denic.de wrote: Just on this one topic. On 31.07.24 19:30, Andrew Newton (andy) wrote: Would you be satisfied if the first recommendation was labeled with "This practice has been observed in use." and the other two recommendations are labeled with &quo

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

Inline... On 7/31/24 12:03, kowa...@denic.de wrote: Comments inline On 31.07.24 17:20, Andrew Newton (andy) wrote: [...] These changes are a result of the shepherd review in checking normative references and normative language (see my other email, which was likely sent when you sent this

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

On 7/31/24 11:08, kowa...@denic.de wrote: I am a bit concerned about this draft. We finished WG LC with version -05, then both -06 and -07 appeared without any discussion on the mailing list. It would be ok if there would be just nits, but -06 changed normative language and -07 now reshaped

[regext] normative language and references in draft-ietf-regext-delete-bcp

Hi all, During the shepherd's review, some questions were raised regarding normative references and normative language. This has resulted in a revamped section 6. The chairs have asked that this version be confirmed with the working group before being handed off to our AD. The specific sec

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

I agree with this. Furthermore, if a greenfield approach is desired it would help if the protocol is not called EPP or a variation otherwise there will be confusion. -andy On Thu, Jul 25, 2024 at 4:57 AM Gould, James wrote: > I view two options for meeting the goals of REPP, which I believe is

[regext] Re: WGLC: draft-ietf-regext-rdap-rir-search-09

Hi Jasdip and Tom, I think this is a really well done draft. I have the following comments: 1. The registrations in the IANA section run together. I would be easier to distinguish the individual registrations if they were numbered and the bullet points were nested, or some other visual property

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

rk" object. -andy On Sat, Jul 20, 2024 at 9:20 AM Jasdip Singh wrote: > > Hi Andy, > > > > Thanks for these insightful questions. Tom and I discussed them. Let me try > answering. :) > > > > Tom, please add/subtract if needed. > > > > Jasdip &

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

Hi Jasdip and Tom, I like this draft, but I do have a couple of questions. 1. This draft mentions the ip network object class but none of the other object classes. Are those not allowed by this extension? What happens if a server uses a geofeed link in a domain object? Should that be covered

[regext] ICANN gTLD Profile

Hi all, If you are attending IETF 120 in Vancouver and work for a gTLD registry operator or registrar or current or potential Registry Service Provider and have questions about the ICANN gTLD Profile (https://www.icann.org/gtld-rdap-profile), including the new version of the profile, send me

[regext] Re: [Ext] AD Evaluation: draft-ietf-regext-epp-ttl-14

On 7/12/24 05:41, Gavin Brown wrote: ### DELEG as example ``` 298 3600 ``` Consider a record that is already registered with IANA, TLSA for example. As I understand it, TLSA is not appropriate for publication at a delegation point, so using TLSA here would not make any more sense than DELE

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

+1. -andy On 6/24/24 09:26, James Galvin wrote: The Chairs have decided to extend this WGLC last call for two weeks, one more week from the date of this message. There has only been on indication of support and two different threads discussing some minor changes. We would like these discu

[regext] Re: Simple Redaction

On 6/21/24 09:32, kowa...@denic.de wrote: Hi Andy, Taking into account that this proposal is a result of considerations on rfc9537 I think this draft takes the issue too simplified or easy, just by removing the difficult part of the problem in rfc9537. If you are saying that this draft is t

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

On 6/20/24 16:39, rcar...@godaddy.com wrote: I was not sure if I should reply to this thread or the "Simple" thread but as the "Simple" thread appears to be a product of this one, I thought I would post here. Several years ago, there were many discussions (in the REGEXT WG, the RDAP WG and

[regext] Re: Fwd: using experimental to move items forward

On 6/20/24 03:35, Mario Loffredo wrote: Hi Andy, [snip] On 6/18/24 04:29, Mario Loffredo wrote: Hi Andy, what does it mean "interoperable implementation" in RegExt context ? Best, Mario It means the protocol/extension works as expected. If Bob were to create a client with extension

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

On 6/17/24 08:11, Gould, James wrote: JG - I agree that this language in the abstract could be better, but the abstract does not override the content of the entire specification and is factual. The extension explicitly identifies the redacted RDAP response fields and JSONPath is the default

[regext] Re: Fwd: using experimental to move items forward

On 6/18/24 08:41, Hollenbeck, Scott wrote: Because the RDAP extensions seem to be piling up and we seem to have differing views about their implementations. I think RFC 9537 is a good example of this... an implementation report would have been very beneficial as we are now being told the JSONP

[regext] Re: Fwd: using experimental to move items forward

Responding to multiple people On 6/17/24 18:40, George Michaelson wrote: I have two competing views 1) get rid of time-wasting. If documents something novel in implementations but there are no implementations, it's not very useful work. Experimental and Informational are kind of different.

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

On 6/17/24 11:02, Gavin Brown wrote: Servers of RDAP data should already have various caching mechanisms (if not, they are in big trouble…) so the hit to a server is insignificant. In my experience, cache hit rates for RDAP is quite low (20-30%), because a common usage pattern is: listOfDoma

[regext] Re: using experimental to move items forward

On 6/17/24 10:25, Hollenbeck, Scott wrote: -Original Message- From: Andrew Newton (andy) Sent: Friday, June 14, 2024 6:23 AM To: regext@ietf.org Subject: [EXTERNAL] [regext] using experimental to move items forward Caution: This email originated from outside the organization. Do not

[regext] Simple Redaction

Hi all, I spent some time thinking about how to make the redaction problem less complex by focusing on the places where redaction is most likely to to be found, in "personal data". Within RDAP, that appears to always be conveyed in JSON strings. Reducing the scope reduces the complexity, at l

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

On 6/14/24 14:59, Hollenbeck, Scott wrote: -Original Message- From: Andrew Newton (andy) Sent: Friday, June 14, 2024 2:42 PM To: Gould, James ; kowa...@denic.de; regext@ietf.org Subject: [EXTERNAL] [regext] Re: Fwd: New Version Notification for draft- newton-regext-rdap-considerations

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

nt 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 members are required and optional. I agree that the abstract could have been better worded. It

[regext] using experimental to move items forward

Hi all, When I look at the DNSOP working group I see items like CDS bootstrapping and generalized NOTIFY are nearing completion. They have even spun off another working group recently. Comparing that to the progress here, it seems that in REGEXT we don’t make as much progress. Given the diff

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

On 6/12/24 10:37, Hollenbeck, Scott wrote: */If "mail system support for SMTPUTF8 addresses isn't ubiquitous" isn't a given, then both use cases can be approached differently. If it is a given, we have a requirement to continue to support exchange of all-ASCII email addresses. An extension c

[regext] Re: sacrificial hosts in epp-delete bcp

On 6/11/24 10:40, Hollenbeck, Scott wrote: Thanks for the feedback, Andy. More below. -Original Message- From: Andrew Newton (andy) Sent: Monday, June 10, 2024 4:58 AM To: regext@ietf.org; Hollenbeck, Scott Subject: [EXTERNAL] sacrificial hosts in epp-delete bcp Caution: This email

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

On 6/11/24 07:57, kowa...@denic.de wrote: Hi, I think the issue of JSONPath not being easy/possible to interpret in case of removed paths was brought up on the mailing list and the conclusion was to key off the "redacted name" rather than base on JSONPath [1]. This is also what has been c

[regext] confirmation of changes to draft-ietf-regext-epp-ttl during WGLC

Hi all, As document shepherd, the chairs have asked me to confirm on this list that all comment received during WGLC, including the DNSDIR comments, have been addressed and to confirm on the list that all changes from #08 to #11 are not material. I note that the following editorial changes f

[regext] sacrificial hosts in epp-delete bcp

Hi Scott, Section 6.2 of the EPP Delete BCP discusses the proposed best practices, with section 6.2.2 referencing back to 5.1.7. However, 5.1.7 mentions possible names such as sacrificial.invalid or a proposed new reserved TLD such as .sacrificial. For implementation purposes, I think 6.2.2 s

[regext] Re: regext - New Meeting Session Request for IETF 120

On 6/5/24 04:58, Mario Loffredo wrote: - in light of Andy's feedback on RFC9537 and repeating what I had already written in this thread , do believe that representing collections in contact data through maps instead of

[regext] Re: regext - New Meeting Session Request for IETF 120

Given the interims that never materialized, the discussions on EPP over REST/HTPP/QUIC, the drafts on IDNS that are expected, and the recent issues on RDAP redaction, would it be wise to also ask for an additional 1 hour slot? -andy On 6/3/24 10:40, IETF Meeting Session Request Tool wrote:

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

Hi all, Over the past several months, we have been implementing the RDAP redaction extension, RFC 9537. This I-D describes the issues we have encountered. -andy Forwarded Message Subject: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00

[regext] redacted examples

Hi all, For those doing development for RFC 9537, I have a github repository with some examples that may be useful. https://github.com/anewton1998/redacted_examples -andy ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to re

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

On 5/9/24 15:33, Hollenbeck, Scott wrote: [SAH] The context is given in the Section title and the included back references. They're proposed best practices. The back-referenced text that describes each practice notes that they haven't been observed in operation. We could add something like "Th

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

On Fri, May 3, 2024 at 1:57 PM Hollenbeck, Scott wrote: > > > My rough, rough understanding is that EPP needs extensions for registrars to > > know if an IDN variant is available, blocked but unallocated to another > > registrant, or actually available. > > [SAH] OK, but that doesn't explain why a

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

My rough, rough understanding is that EPP needs extensions for registrars to know if an IDN variant is available, blocked but unallocated to another registrant, or actually available. -andy On Fri, May 3, 2024 at 10:25 AM Hollenbeck, Scott wrote: > > > -Original Message- > > From: regext

[regext] quasi-technical terms (was Re: [Ext] Re-chartering REGEXT?)

On 4/25/24 08:10, Maarten Wullink wrote: Improved scalability is one the stated goals and It’s true that just by adding HTTP support, EPP would be able to leverage all of the scalability features provided by HTTP. However, by using named resources in the URL (as is a feature of REST) it woul

Re: [regext] Re-chartering REGEXT?

..@verisign.com > > > > > > 703-948-3271 > > 12061 Bluemont Way > > Reston, VA 20190 > > > > Verisign.com <http://verisigninc.com/> > > > > > > > > > > On 4/15/24, 1:20 PM, "regext on behalf of Andrew Newton (andy)&qu

Re: [regext] Re-chartering REGEXT?

Maarten, I think proposing some charter text is a good idea. And I support this if the charter is to be used to exclude some proposals for EPP transports but not others, as has been argued. -andy On Thu, Apr 11, 2024 at 11:59 PM Maarten Wullink wrote: > > Hello everyone, > > The REGEXT WG char

Re: [regext] using subdomains in RDAP bootstrap

Hi Dmitry, You can use redirects as described by section 5.2 of RFC 7480: https://datatracker.ietf.org/doc/html/rfc7480#section-5.2 Redirects are commonly used in the RIR/INR space for IP addresses and ASNs and, as you have pointed out, the domain space for zones below the TLD level. I hope

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

Hi Jasdip, Comments in-line On Mon, Mar 25, 2024 at 7:25 PM Jasdip Singh wrote: > > [JS] It seems the “marker” extension type from the RDAP Extensions draft [1] > should cover this extension since marker extensions “exist to denote the > usage of values placed into an IANA registry” and we are

Re: [regext] EPP evolution and the REGEXT charter

gt; JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > > On 3/22/24, 7:40 AM, "Andrew Newton (andy)" <

Re: [regext] EPP evolution and the REGEXT charter

I am against any logic that creates different gating factors for the different, competing solutions. Any contortion of the concept of an EPP "extension" that results in the favor of one set of drafts over the other is obviously unfair. -andy On Fri, Mar 22, 2024 at 5:33 AM Mario Loffredo wrote:

Re: [regext] EPP Transport Service Discovery

Registries have a financial incentive to make sure registrars are kept up to date, so your experience is almost certainly the norm. And I agree that any service discovery mechanism that gets complicated is not worth the effort in the registry/registrar space. That said, George's idea of using an S

[regext] redacted implementation

Hi all, For those implementers looking for something to test their RDAP redaction implementations against, we just released v0.0.16 of the ICANN RDAP packages. https://github.com/icann/icann-rdap/releases/tag/v0.0.16 The icann-rdap-srv package can serve redacted RDAP information from JSON files,

Re: [regext] [Ext] Re: RDAP and link context

On Tue, Mar 5, 2024 at 3:42 PM James Mitchell wrote: > > > The server can’t pre-compute a response where multiple URIs map to one object > – one has to patch any pre-computed response prior to sending back on the > wire. This is a use of compute resources for what seems to be no benefit. I > c

Re: [regext] [Ext] Re: RDAP and link context

On Fri, Mar 1, 2024 at 6:57 PM James Mitchell wrote: > > > The new gTLD Response profile > (https://www.icann.org/en/system/files/files/rdap-response-profile-21feb24-en.pdf) > says … “a value with the RDAP lookup path that generated the RDAP > response.”, requirements 2.6.3 and 2.10. Unless you

Re: [regext] [Ext] Re: Adding the DNS root to the bootstrap file

On Fri, Mar 1, 2024 at 6:36 PM James Mitchell wrote: > > I’d say the matching logic is arguably incorrect – matching should begin with > the parent of the supplied domain name. However, I acknowledge this arguably > affects only queries for TLDs themselves, as a TLD’s RDAP server could > redire

Re: [regext] RDAP and link context

Hi James, RFC 7483 did not require the 'value' attribute, however when the standard was revised in RFC 9083 this attribute became required. I believe you are correct that a link context is not well defined. It is supposed to be the scope in which a link is to be understood. In a JSON response ful

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

I am not in favor of weakening the security posture of EPP. If one security mechanism is to be downgraded from a MUST to a SHOULD, there needs to be a replacement of it with another security mechanism that is a MUST which keeps the security posture of EPP at the same or greater level. -andy On T

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

"construction of the response" can be interpreted strictly to mean only the JSON structure of the response. IMHO, that is an incorrect interpretation nor does it track with RDAP as it is used because profile extensions such as the ICANN and NRO extensions also dictate content not just structure. -

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

+1, obviously. -andy On Mon, Feb 5, 2024 at 9:37 AM James Galvin wrote: > > This is the formal adoption request for the following package of Internet > Drafts: > > Versioning in the Registration Data Access Protocol (RDAP) > https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ >

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

+1. And restating my previous email... I'm willing to shepard. -andy On Mon, Jan 29, 2024 at 10:19 AM Antoin Verschuren wrote: > > This is the formal adoption request for Best Practices for Deletion of Domain > and Host Objects in the Extensible Provisioning Protocol (EPP): > > > https

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

Thanks Tom. Looks good to me. -andy On Thu, Jan 25, 2024 at 10:28 PM Tom Harrison wrote: > > Hi Andy, > > Thanks for your feedback. > > On Thu, Dec 07, 2023 at 02:55:21PM -0500, Andy Newton wrote: > > 1. The elidation in figure 2 (section 3.4) should be pointed out. At > > first I mistook the hr

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

I support this. Also, I volunteer to be doc shephard if that is acceptable to the chairs and if the doc is adopted. -andy On Thu, Jan 18, 2024 at 7:59 AM Hollenbeck, Scott wrote: > > draft-hollenbeck-regext-epp-delete-bcp was updated yesterday to address the > most recent feedback provided by J

[regext] status of draft-ietf-regext-epp-eai

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/ What is the status of this draft? I know the authors churned out another version rolling back some of the changes based on conversations on this list. Does it need to take another spin in WGLC? -andy

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

On Fri, Jan 5, 2024 at 8:04 AM Gavin Brown wrote: > So something like this? I've also thrown in min/default/max values as well: > > "ttl": [ > { > "types": ["NS", "DELEG"], > "value": 3600, > "min": 60, // optional > "default": 86400, // optional > "max": 172800, // opt

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

On Wed, Jan 3, 2024 at 10:20 AM Gavin Brown wrote: > > Do you think the ttl_values object needs an events array then? > > To support this I would change the ttl_values object as follows: > > "ttl": { > "values": { > "NS": 3600, > "DS": 60, > }, > "events": [ > { > "eventAction": "lastChang

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

Given that the TTL can be updated independently of the domain name, there is utility in exposing TTLs in RDAP especially if that information can be given with the events & links as is done with the DNSSEC data in RDAP. I know I have had times in the past when I needed to know when a TTL was last ch

Re: [regext] Redacted registry implementations

Hi Marc, We're trying to work it into our CLI as well, and as such will likely put it into our server so we have something to test against (https://github.com/icann/icann-rdap/tree/main/icann-rdap-srv). I'll ping you when the work becomes usable. -andy On Fri, Dec 15, 2023 at 7:55 AM Marc Blanch

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

On Fri, Dec 8, 2023 at 3:57 AM Mario Loffredo wrote: > > [ML] I would prefer "only express the items which are more likely used in > RDAP". After all, SimpleContact is not an RFC and, as such, could be subject > to changes resulting from the WG discussion. > > In this respect, have still retaine

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

+1 On Mon, Dec 11, 2023 at 9:24 AM Gould, James wrote: > 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

Re: [regext] JSContact - SimpleContact discussion follow up

On Wed, Nov 29, 2023 at 5:12 AM Mario Loffredo wrote: > > > Let's take for example the possible link between the uid property and the > unique and persistent identifier as defined by the European eIDAS regulation > for the purposes of cross-border identification and validation of domain > regis

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

On Tue, Nov 28, 2023 at 5:39 AM Mario Loffredo wrote: > > [ML] Since it talks about "content negotiation", rdap-x regards clients > signaling their preferences about response extensions or, at most, > extensions involving both the response and the request. > > With regard to pure request extension

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

This is a great draft, and I'm glad that this work is going forward. I do have a few comments. 1. The elidation in figure 2 (section 3.4) should be pointed out. At first I mistook the hrefs as some sort of relative URLs. 2. It would be helpful if section 4 noted that the object instances returned

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

My comments are inline: On Fri, Nov 17, 2023 at 7:18 AM Mario Loffredo wrote: > > [ML] Per what is stated in RFC 9083 Section 4.1, a pure request extension > doesn't have to be included in the rdapConformance array of the related > response when it is used in a query because the rdapConformance

Re: [regext] JSContact - SimpleContact discussion follow up

Mario, Many thanks for this message. On Fri, Nov 17, 2023 at 5:57 AM Mario Loffredo wrote: > > 2) Chapter "Make it simpler" > > Prefer "Make it better". I mean, simplicity cannot be the only parameter used > within IETF to evaluate a technical solution. IMO there are other parameters > that ar

Re: [regext] RDAP-X draft adoption

a > similar concern with the retention of query parameters for the TLD transition > use case? > > Thanks, > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 &

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

Mario, On Thu, Nov 16, 2023 at 9:28 AM Mario Loffredo wrote: > > > Also, since you (and JG) have been arguing vehemently on your > position, did you find a technical flaw in the rdap-x draft? Have you > found a scenario where it does not work? > > [ML] Am not "arguing vehemently", I'm quietly exp

Re: [regext] RDAP-X draft adoption

arameter vs. RDAP-X debate. > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > > On 11/15/23,

Re: [regext] RDAP-X draft adoption

On Wed, Nov 15, 2023 at 11:19 AM Gould, James wrote: > > How about making the RDAP-X hedgehog broader into a super hedgehog by solving > the more general query parameter issue with redirection services? You have understated the problem. The issue is not with redirection services but with redire

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

Mario (and JG), On Wed, Nov 15, 2023 at 5:17 AM Mario Loffredo wrote: > > [ML] About preserving query parameters in HTTP redirection, my opinion > is that it depends on each application protocol built over HTTP. > > There are a ton of protocols on the web preserving query parameters in > redirect

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

On Tue, Nov 14, 2023 at 3:00 PM Marc Blanchet wrote: > > The fact that some people are willing to provide services in addition to the > standard track RFCs for bootstrapping RFC9224) does not mean that it should > influence how we design our protocols. I have a hard time thinking that we > are

  1   2   3   >