[regext] RDAP reverse search draft feedback

Hello Mario, Scott, Please find my feedback on https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ below: 1. Agree with the overall usefulness of this draft to cover the missing/needed search scenarios. 2. Not sure if we need to specifically mention in the draft but

Re: [regext] RDAP reverse search draft feedback

Thanks for explaining various options, Mario. That’s a reasonable justification for a role to be in the path segment, especially for access control and search efficiency. Jasdip From: Mario Loffredo Date: Monday, August 3, 2020 at 5:51 AM To: Jasdip Singh , "regext@ietf.org" S

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

Hello Scott, James. One thought is if it could be in the RDAP profile doc for the DNRs (https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en). That way no need to update the spec. Jasdip On 9/24/20, 12:31 PM, "regext on behalf of Hollenbeck, Scott" wrote: >

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis

Hello Scott, James. Seems if the RDAP profile for the DNRs (https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en) could clarify this, the spec could be left as-is. Jasdip On 9/24/20, 12:30 PM, "regext on behalf of Hollenbeck, Scott" wrote: > -Original Messag

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis

I'd like to see some discussion of this suggestion. If one understands the normative references, the suggestion is already implicitly addressed. There may be some value in describing this situation explicitly since it came up in the ICANN gTLD implementation context, but so others think this

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

> contact and registrar), such as using different formats, > > using a precedence order, or a combination of formats and > > precedence order. > > > > The SHOULD could be a MUST, but the point

Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-rfc7482bis

+1 Jasdip On 12/8/20, 2:54 PM, "regext on behalf of Antoin Verschuren" wrote: This is a special second working group last call for: https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/ This document is suggested to be elevated from “proposed standard” to "Inte

Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-rfc7483bis

+1 Jasdip On 12/8/20, 2:54 PM, "regext on behalf of Antoin Verschuren" wrote: This is a special second working group last call for: https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/ This document is suggested to be elevated from “proposed standard” to "Inte

Re: [regext] CALL FOR ADOPTION: draft-blanchet-regext-rfc7484bis-00

Hi. I support the adoption of this draft. I can be the document shepherd if needed. Thanks, Jasdip On 1/18/21, 9:28 AM, "regext on behalf of James Galvin" wrote: This is a formal adoption request for “Finding the Authoritative Registration Data (RDAP) Service”: https://dat

Re: [regext] CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03

Hi. I support the adoption of this draft. Thanks, Jasdip On 1/18/21, 9:28 AM, "regext on behalf of James Galvin" wrote: This is a formal adoption request for “Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses”: https://datatracker.ietf.org/doc/draf

Re: [regext] CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03

Interesting point, Scott. Adopting JSContact (and deprecating jCard eventually) seems a tradeoff between ease-of-implementation for future servers/clients and diminishing returns for the current servers/clients. Should the latter (diminishing returns) prevent the former (easy-of-implementation)?

Re: [regext] EXTENDED: Re: CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03

Hi. +1 for adoption. Jasdip On 2/10/21, 2:33 PM, "regext on behalf of James Galvin" wrote: The Chairs would like to extend this CALL FOR ADOPTION because we’d like to separate out an issue that has come up in the discussion of this adoption. We are hoping that this clarity wil

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-rfc7483bis-04: (with COMMENT)

Hello Scott, Please find below my input on couple of points. Jasdip On 2/18/21, 11:52 AM, "regext on behalf of Hollenbeck, Scott" wrote: > Section 5.5 > >The following is an example of a JSON object representing an autnum. > >{ > "objectClassName" : "au

Re: [regext] Murray Kucherawy's No Objection on draft-ietf-regext-rfc7482bis-02: (with COMMENT)

Hello Scott, Please find my comment below. Jasdip On 2/18/21, 11:13 AM, "regext on behalf of Hollenbeck, Scott" wrote: > -Original Message- > From: Murray Kucherawy via Datatracker > Sent: Thursday, February 18, 2021 3:30 AM > To: The IESG > Cc: draft-ietf-regex

[regext] rfc7484bis feedback

Hello Marc, I reviewed rfc7484bis for the shepherd doc and noted the following. Thanks, Jasdip --- Overall: Should we mention in both the Abstract and Introduction sections that this doc obsoletes RFC 7484? RFC 8259 obsoletes RFC 7159 for the JSON format. Throughout the doc, it would be goo

Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rfc7484bis-02.txt

lf of Marc Blanchet" wrote: Hello, new version: - added Scott Hollenbeck comments - added ARIN implementation info from Jasdip Singh Ready for wglc to me. Regards, Marc. ___ regext mailing list regext@ietf

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7484bis-03

Monday, 26 April 2021. Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. The document shepherd for this document is Jasdip Singh. Regards, Anto

Re: [regext] Adoption of draft-gould-regext-rdap-redacted Document

+1 Jasdip From: regext on behalf of Jody Kolker Date: Friday, August 6, 2021 at 4:03 PM To: regext Subject: [regext] Adoption of draft-gould-regext-rdap-redacted Document Hello RegExt Group Members, Thank you for the feedback received on the mailing list and at IETF-111 RegExt meeting rega

[regext] RDAP JSContact feedback

Hello Mario, Gavin, Please find below the initial shepherd feedback for the latest 03 draft. Thanks, Jasdip --- * Rationale “provides a simpler and more efficient representation for contact information” Is it

Re: [regext] RDAP JSContact feedback

Hello Mario, Please find my comments below. Thanks, Jasdip From: Mario Loffredo Date: Monday, November 8, 2021 at 1:09 PM To: Jasdip Singh , "regext@ietf.org" Subject: Re: [regext] RDAP JSContact feedback 1. Rationale “provides a simpler and more efficient representation f

Re: [regext] Fwd: RDAP JSContact feedback

Mario, From: regext on behalf of Mario Loffredo Date: Tuesday, November 9, 2021 at 7:46 AM To: "regext@ietf.org" Subject: [regext] Fwd: RDAP JSContact feedback 7. Security Considerations “The only mandatory property, namely "uid", is usually an opaque string.” Do we need to clarify further

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

Hi. +1 for this doc being on standards track. Jasdip From: regext on behalf of Antoin Verschuren Date: Monday, December 13, 2021 at 10:10 AM To: "regext@ietf.org" Subject: Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt Hi All, I’m glad that my bad phrasi

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

Hello Scott, I like the overall direction of this draft to help simplify things for RDAP clients and facilitate adoption, but wanted to share couple of observations: 1. There are 3 newly proposed RDAP path segments, starting with “login”, “session”, and “logout”. Looks like, for simplicity, we

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

Scott, That simplifies. Thanks. Jasdip From: "Hollenbeck, Scott" Date: Thursday, February 17, 2022 at 8:24 AM To: Jasdip Singh , "regext@ietf.org" Subject: RE: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt From: regext On Behalf Of Hollenbeck, Scott Sent:

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

My comment below. Jasdip From: Marc Blanchet Date: Thursday, February 17, 2022 at 10:17 AM To: "Hollenbeck, Scott" Cc: Jasdip Singh , "regext@ietf.org" Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt Le 17 févr. 2022 à 08:24, Hollenbeck, Scott

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

+1 Jasdip On 4/4/22, 9:18 AM, "regext on behalf of Antoin Verschuren" wrote: Dear Working Group, The authors of the following working group document have indicated that it is believed to be ready for submission to the IESG for publication as a standards track document: https:/

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

Hello Scott, Please find my comments below. Thanks, Jasdip P.S. Thanks to Tom for his analysis of all current extensions. :) On 4/28/22, 10:27 AM, "regext on behalf of Hollenbeck, Scott" wrote: Since this topic is coming up in the reverse search discussion, but isn't unique to reve

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

Hello James, Scott, Should the rdapConformance string not to be an exact match for the extension identifier registered with IANA? Per Tom’s earlier note [1], that seems to be the case for most, if not all, well-known extensions. If so, then the proposed rdapConformance “redacted_level_1_0” won’

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

Hello James, Please find my comments below. Thanks, Jasdip From: "Gould, James" Date: Thursday, May 5, 2022 at 2:46 PM To: Jasdip Singh , "regext@ietf.org" Subject: Re: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments From: regext on behalf of

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

Totally agree, Scott. Jasdip From: "Hollenbeck, Scott" Date: Thursday, May 5, 2022 at 2:55 PM To: "jgould=40verisign@dmarc.ietf.org" , Jasdip Singh , "regext@ietf.org" Subject: RE: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments Re: “the

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

Hi. Not sure if it is totally correct but wanted to input a strawman analysis of the two approaches -- tight coupling between extension identifier and rdapConformance, versus lack of -- to our discussion. Hope this is useful. Thanks, Jasdip --- Approach A: Tight coupling between extension ide

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

on behalf of Jasdip Singh Date: Thursday, May 19, 2022 at 2:15 PM To: "regext@ietf.org" Subject: [regext] Analysis of tight coupling between extension identifier and rdapConformance, versus lack of Hi. Not sure if it is totally correct but wanted to input a strawman analysis o

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

Hi. Please find my input below. Thanks, Jasdip From: regext on behalf of "Gould, James" Date: Monday, May 23, 2022 at 3:27 PM To: "t...@apnic.net" Cc: "Hollenbeck, Scott" , "regext@ietf.org" Subject: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments Tom, In reviewing

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

From: regext on behalf of Mario Loffredo Date: Tuesday, May 24, 2022 at 7:02 AM To: "Gould, James" , "t...@apnic.net" Cc: "Hollenbeck, Scott" , "regext@ietf.org" Subject: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments … 2.It looks like there is consensus that the RDA

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

Hi. I'd contend that unlike the proposed approach(es), current approach: - guarantees no collisions under every change scenario (not just optional new field) - guarantees sufficient transition time for clients when moving to the next version of an extension (without requiring any additional sign

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

-- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/27/22, 10:31 AM, "Jasdip Singh" wrote: Hi. I'd contend that unlike th

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

n in https://docs.google.com/document/d/1iadJc1D2-z_9pSy0PNcl4mhEQglh7dIHhbmRgrCW6mc/edit?usp=sharing and decide whether the breakage points matter for various change scenarios or not. Cheers, Mario Il 27/05/2022 16:31, Jasdip Singh ha scritto: > Hi. > > I'd contend that unlike th

Re: [regext] Feedback about breakage analysis

Thank you, Mario. Let me review your feedback, and adjust the analysis accordingly. Probably, early next week. :) Jasdip On 6/1/22, 12:33 PM, "regext on behalf of Mario Loffredo" wrote: Hi Jasdip, I would suggest to add Approach C and split some scenarios into smaller changes.

<    1   2