Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

Hello Scott, Here is my (mostly minor) feedback: 1. 4.8 For consistency with other examples, add spaces before and after ‘:’ in the publicIds example. 2. 5.1 Similarly, add spaces before and after ‘:' in the entity example. (There could be other places in the whole doc.) 3. 5.3

Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

Section 5.1: I wonder which kinds of relationships model both the entity properties "networks" and "autnums". I mean, do they model the reverse relationships between, respectively, a network or an autnum and the related entities or something else? [SAH] Maybe one of the RIR guys can address

Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

I agree with your comments, Scott. Thanks. Jasdip On May 6, 2020, at 12:11 PM, Hollenbeck, Scott mailto:shollenb...@verisign.com>> wrote: Thanks for the feedback, Jasdip. More below… From: Jasdip Singh mailto:jasd...@arin.net>> Sent: Tuesday, February 18, 2020 11:28 AM To: Holle

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

uch 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 is to provide guidance to

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

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] IANA Considerations in draft-ietf-regext-rdap-reverse-search

IMHO, the current wording in 7843bis seems clear enough, especially the phrase "specifications used in the construction of the response." It is about what specifications were used for the returned response. No? Jasdip On 7/31/20, 10:28 AM, "regext on behalf of Mario Loffredo" wrote:

Re: [regext] IANA Considerations in draft-ietf-regext-rdap-reverse-search

Hello Mario, Please find my comment below. Jasdip On 7/31/20, 12:21 PM, "Mario Loffredo" wrote: Il 31/07/2020 16:35, Jasdip Singh ha scritto: > IMHO, the current wording in 7843bis seems clear enough, especially the phrase "specifications used in the constructi

Re: [regext] IANA Considerations in draft-ietf-regext-rdap-reverse-search

Agree with Patrick's points about rdapConformance in the help response informing about all capabilities and rdapConformance being more specific for a particular query response. Jasdip On 7/31/20, 12:29 PM, "regext on behalf of Patrick Mevzek" wrote: On Fri, Jul 31, 2020, at 11:21,

[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] I-D Action: draft-ietf-regext-rfc7483bis-00.txt

On Jun 17, 2020, at 9:23 AM, Hollenbeck, Scott mailto:shollenbeck=40verisign@dmarc.ietf.org>> wrote: 7) Section 10.2.3 - The definition of "last changed" event type seems to be inconsistent with "upDate" defined in RFC 5731,5732,5733. For example, I report an extract from RFC5731 here

[regext] Minor feedback on draft-ietf-regext-rfc7483bis-00

Hello Scott. While doing the shepherd writeup, noted few minor things which may help polish the doc further. * 5.5: Add “The” to the "Autonomous System Number Object Class” section title to be consistent with others. * 1, 5, 5.4, 5.5, 7, 8: Looks like the [I-D.ietf-regext-rfc7482bis]

Re: [regext] Minor feedback on draft-ietf-regext-rfc7483bis-00

Yah, those missing links could be because of the HTML version of the doc. Please ignore that. Jasdip On Jun 11, 2020, at 2:40 PM, Hollenbeck, Scott mailto:shollenb...@verisign.com>> wrote: From: regext mailto:regext-boun...@ietf.org>> On Behalf Of Jasdip Singh Sent: Thursday, J

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

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

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

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

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

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

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

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

[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

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

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

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

[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

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

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

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

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

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

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 the proposed approach(es), curre

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

oogle.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 the proposed approach(es

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.

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

[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

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] RDAP Extensions Approach Analysis v2

here the analysis landed for me as well. Jasdip [1] https://docs.google.com/document/d/1e3QD8z01KpYRd5LwdLBWjHHDoFVAVEL8u7Y52zsDdx0/edit?usp=sharing On Mon, Jun 6, 2022 at 10:05 PM Jasdip Singh wrote: > > Hi. > > Please find below the revised analysis of the curr

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

Hi. Agree with Scott that we first fix the errata per the original intent of the authors, in order to have the STD 95 docs in a clearer state for the current approach (approach A). Once that's out of the way, we can discuss the merits of the current approach (approach A) versus the 2 newly

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

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

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”

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

Re: [regext] status of draft-ietf-regext-rdap-reverse-search

Hi. +1 for input addressed. Thanks, Jasdip On 8/29/22, 9:45 AM, "regext on behalf of James Galvin" wrote: Mario Loffredo has asked for WGLC for the RDAP reverse search document: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ This document had a WGLC

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

+1 Jasdip On 9/12/22, 9:54 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:

Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17

Hello Scott, > 1.2: "It can also provide the ability to collect additional user > identification > information, and that information can be shared with the consent of the > user." > ... Not clear who that information could be shared with. [SAH] "shared with the RDAP

Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17

Hi. Overall, +1. While reviewing the latest draft, wanted to share few comments (sorry, if a bit late): 1.2: "willing to share more information about them self" ... Minor: wouldn't "themselves" read better than "them self"? 1.2: "It can also provide the ability to collect additional user

Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance

+1 Thanks, Jasdip On 8/1/22, 9:49 AM, "regext on behalf of James Galvin" wrote: As everyone knows there has been quite some discussion on the mailing list regarding how to implement rdapConformance. This was a significant topic of discussion at the REGEXT meeting during IETF114.

Re: [regext] New version of rdap-reverse-search

: Tuesday, December 20, 2022 at 4:50 AM To: Jasdip Singh , Antoin Verschuren , "regext@ietf.org" Subject: Re: [regext] New version of rdap-reverse-search Hi Jasdip, seems to me that the majority was so much in favor of both the help response extension and the ad-hoc IANA registry t

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

Hello James, Since we are trying to get away for the placeholder text "" with this standards-track proposal, agree option #1 makes sense to discourage such practice. Further, agree with Jody that returning the "redacted" rdapConformance should make it ample clear when an RDAP server

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

James, +1 for option #1. :) Jasdip From: "Gould, James" Date: Thursday, December 15, 2022 at 3:33 PM To: "Keathley, Daniel" , Andy Newton , "mario.loffr...@iit.cnr.it" Cc: "jkol...@godaddy.com" , "jgould=40verisign@dmarc.ietf.org&quo

Re: [regext] New version of rdap-reverse-search

Hi. Per the comments in [1], it would be good to settle if the proposed discovery and IANA registration of reverse search properties is an overkill or not. Specifically: * Is the newly proposed "reverse_search_properties" member in the help response (section 5) needed? * Is the newly

Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

Hi. Very interesting discussion. :) Couple of inputs regarding the proposed discovery and IANA registration of reverse search properties: In the spirit of what-not-to-do, is it really necessary to evolve reverse search this way? As long as each registered extension identifier (current and

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

Hello Scott, Firstly, thank you for including both session-oriented and token-oriented client scenarios in this doc. Makes it easier for comparison. Please find my input to your question below. Regards, Jasdip On 1/26/23, 2:10 PM, "regext on behalf of Hollenbeck, Scott"

Re: [regext] I-D Action: draft-ietf-regext-rdap-reverse-search-19.txt

the original statement now but wonder if it could confuse someone else. Thanks, Jasdip On 3/9/23, 12:51 PM, "regext on behalf of Jasdip Singh" mailto:regext-boun...@ietf.org> on behalf of jasd...@arin.net <mailto:jasd...@arin.net>> wrote: On 3/9/23, 12:34 PM, "Mario

Re: [regext] I-D Action: draft-ietf-regext-rdap-reverse-search-19.txt

On 3/9/23, 12:34 PM, "Mario Loffredo" mailto:mario.loffr...@iit.cnr.it>> wrote: >> - Section 3: "Servers MUST NOT provide or implement unregistered reverse >> searches or unregistered reverse search mappings." ... Does "unregistering" >> entries from these IANA registries mean removing them,

Re: [regext] Fwd: Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-20.txt

Thank you, Mario. Yes, they have been. Regards, Jasdip From: regext on behalf of Mario Loffredo Date: Friday, March 10, 2023 at 4:02 AM To: "regext@ietf.org" , Jasdip Singh Subject: [regext] Fwd: Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-20.txt Hi Ja

Re: [regext] I-D Action: draft-ietf-regext-rdap-reverse-search-19.txt

Hello Mario, Please find below my comments on this draft: - Title: Would it be better to re-title the doc as simply "Registration Data Access Protocol (RDAP) Reverse Search" since we tend to mention it in discussions as "reverse search" and not "reverse search capabilities"? - Section 3: Typo

Re: [regext] JSContact issues

Hi. Just wanted to inject couple of inputs, marked [JS]. Thanks, Jasdip From: regext on behalf of Mario Loffredo Date: Tuesday, March 21, 2023 at 5:40 AM To: Andy Newton Cc: Registration Protocols Extensions Subject: Re: [regext] JSContact issues HI Andy, again my comments below. Il

Re: [regext] I-D Action: draft-ietf-regext-rdap-reverse-search-19.txt

Hi Mario, On 3/9/23, 5:41 AM, "Mario Loffredo" mailto:mario.loffr...@iit.cnr.it>> wrote: > - Section 3: "Servers MUST NOT provide or implement unregistered reverse > searches or unregistered reverse search mappings." ... Does "unregistering" > entries from these IANA registries mean removing

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

+1 Thanks, Jasdip On 4/17/23, 9:27 AM, "regext on behalf of Antoin Verschuren" mailto:regext-boun...@ietf.org> on behalf of ietf=40antoin...@dmarc.ietf.org > wrote: The document editors have indicated that the following document is ready for submission to

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

Hi. Agree with James’ input -- not violating the JSContact spec for the mandatory uid, and using the redaction-by-replacement method. Using a nil UUID as a replacement string for uid looks elegant. Thanks, Jasdip From: regext on behalf of "Gould, James" Date: Thursday, April 20, 2023 at

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

Hello Mario, Please find my comment below. Thanks, Jasdip From: Mario Loffredo Date: Monday, April 3, 2023 at 6:18 AM To: Jasdip Singh , Andy Newton , "regext@ietf.org" Subject: Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20 Hi Jasdip, Il 01/04/2023 23:55, Jasdi

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

On 3/22/23, 5:44 PM, "regext on behalf of Andrew Newton" mailto:regext-boun...@ietf.org> on behalf of a...@hxr.us > wrote: Ok. I did find one small issue. Should the draft give explicit mention of returning an HTTP 501 for searches not supported by a server? [JS] Section 1

Re: [regext] [EXTERNAL] Re: jCard to JSContact transition

Hi. If the response size increase is not a concern when both jCard and JSContact objects are returned for some time, it seems Andy’s proposal (option 3) is the way to go. IMO, it keeps things simple without having to worry about which query parameter to set on the client side. Additionally, a

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

From: Mario Loffredo Date: Friday, April 7, 2023 at 1:28 PM To: Jasdip Singh , "Hollenbeck, Scott" , Andy Newton Cc: "regext@ietf.org" Subject: Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20 Il 07/04/2023 18:56, Jasdip Singh ha scritto: On 4/5/23, 12:56

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

On 4/5/23, 12:56 PM, "Mario Loffredo" mailto:mario.loffr...@iit.cnr.it>> wrote: >> [SAH] Nit: as alluded to by Jasdip above, RFC 7231 has been >> obsoleted by RFC 9110. >> >> The 501 text is 9110 is consistent with 7231, but I don’t think >> it’s limited to an

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

On 4/5/23, 8:40 AM, "Hollenbeck, Scott" mailto:shollenb...@verisign.com>> wrote: > -Original Message- > From: Mario Loffredo > > Sent: Wednesday, April 5, 2023 4:24 AM > To: Andrew Newton mailto:a...@hxr.us>>; Hollenbeck, Scott >

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

Hello Mario, I have attached my comment to Scott’s comment in the other thread. :) Thanks, Jasdip From: Mario Loffredo Date: Wednesday, April 5, 2023 at 4:07 AM To: Jasdip Singh , Andy Newton Cc: "regext@ietf.org" Subject: Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-2

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

On 4/4/23, 12:33 PM, "Andrew Newton" mailto:a...@hxr.us>> wrote: On Tue, Apr 4, 2023 at 9:20 AM Hollenbeck, Scott mailto:shollenb...@verisign.com>> wrote: > > [SAH] Nit: as alluded to by Jasdip above, RFC 7231 has been obsoleted by RFC > 9110. > > > > The 501 text is 9110 is consistent with

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

On Mon, Apr 3, 2023 at 7:57 AM Jasdip Singh <mailto:jasd...@arin.net> wrote: What I gather from Andy’s suggestion is that 501 could also be returned for the reverse search queries that are not implemented (supported) on the server side. That said, your observation of applying HT

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

+1 Jasdip On 3/20/23, 9:41 AM, "regext on behalf of James Galvin" mailto:regext-boun...@ietf.org> on behalf of gal...@elistx.com > wrote: The document editors have indicated that the following document is ready for submission to the IESG to be considered for

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

Hello Heather, Steve, Overall, this doc should prove useful to anyone embarking on creating or evolving a registration protocol. While reviewing the latest draft, had some observations/feedback (sorry for the delay): Unless this doc, as-is, is intended for just the DNRs (Domain Name

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

Hello Mario, After reviewing the PatchObject data type [1] in JSContact, one question: How would the JSON serialization/deserialization work for a JSONPointer as a key (read: member name) in a PatchObject, given a programming language like Java does not allow a forward slash ( '/' ) in a

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

Cool, so looks like the Jackson library affords a seamless way to deal with JSPointer’s as keys. Thanks for pointing to that test. Jasdip From: Mario Loffredo Date: Tuesday, June 13, 2023 at 4:30 AM To: Jasdip Singh Cc: "Hollenbeck, Scott" , "jgould=40verisign@dmarc.ietf.

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

On 7/17/23, 3:47 PM, "Pawel Kowalik" mailto:kowa...@denic.de>> wrote: Am 17.07.2023 um 17:32 schrieb Jasdip Singh mailto:jasd...@arin.net>>: > > [JS] This is a fair point, Pawel. Would you suggest considering the latter > method (query parameters) as well, give

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

Hi. On 7/17/23, 7:36 AM, "regext on behalf of Hollenbeck, Scott" mailto:regext-boun...@ietf.org> on behalf of shollenbeck=40verisign@dmarc.ietf.org > wrote: > As an aside note of the considerations at point 1, would like to know > the current WG's

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

On 7/17/23, 11:01 AM, "regext on behalf of kowa...@denic.de " mailto:regext-boun...@ietf.org> on behalf of kowa...@denic.de > wrote: Am 17.07.23 um 13:36 schrieb Hollenbeck, Scott: > >> As an aside note of the considerations at point 1, would

Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-simple-contact-00.txt

On 7/5/23, 3:44 PM, "regext on behalf of Andrew Newton" mailto:regext-boun...@ietf.org> on behalf of a...@hxr.us > wrote: > 5) I'm very curious to know the WG reaction about the use of "noJCard" > extension. AFAIK, providing an alternative represention along with > jCard

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

Hi. Reviewed this latest draft. Overall, still +1 for the next step. :) But, in case it helps clarify further, wanted to share these observations: Section 1: "The redacted JSON fields will either be removed or have empty values in the RDAP response." ... Isn't that incomplete, now that we

Re: [regext] [EXTERNAL] Re: jCard to JSContact transition

Sorry, missed the original proposer of option 3 – Marc. Obviously, agree with him! :) Jasdip From: regext on behalf of Jasdip Singh Date: Wednesday, May 31, 2023 at 7:57 PM To: Mario Loffredo , Rick Wilhelm , Andy Newton Cc: Marc Blanchet , "regext@ietf.org" Subject: R

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

True, we could define an entity object class that serves the DNR and RIR purposes with a simpler JSON, just like we chose to define domain, IP network, and autonomous system number object classes that are specific to these registries' business. However, before abandoning the JSContact effort,

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

.loffr...@iit.cnr.it>> wrote: Hi Jasdip, Il 08/06/2023 15:39, Jasdip Singh ha scritto: > True, we could define an entity object class that serves the DNR and RIR > purposes with a simpler JSON, just like we chose to define domain, IP > network, and autonomous system numb

Re: [regext] [EXTERNAL] Re: jCard to JSContact transition

to start with, an RDAP client could cleanly ignore the data type it does not understand at any point. (Re-read what Andy and Rick said below, and still concur with their inputs.) Thanks, Jasdip From: Mario Loffredo Date: Wednesday, May 31, 2023 at 8:34 AM To: Jasdip Singh , Rick Wilhelm , Andy Newton

[regext] FW: New Version Notification for draft-jasdips-regext-rdap-geofeed-00.txt

ernet-dra...@ietf.org <mailto:internet-dra...@ietf.org>" mailto:internet-dra...@ietf.org>> wrote: A new version of I-D, draft-jasdips-regext-rdap-geofeed-00.txt has been successfully submitted by Jasdip Singh and posted to the IETF repository. Name: draft-jasdips-regext-rdap-geof

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

Hi. I agree with Andy that there is no benefit in holding back this I-D from the IESG submission. If possible, would like my previous note on this subject addressed though. :) Thanks, Jasdip On 6/26/23, 10:39 AM, "regext on behalf of Andrew Newton" mailto:regext-boun...@ietf.org> on behalf

Re: [regext] WGLC: draft-ietf-rdap-opened-22

+1 Thanks, Jasdip On 6/26/23, 10:02 AM, "regext on behalf of James Galvin" mailto:regext-boun...@ietf.org> on behalf of gal...@elistx.com > wrote: The document editors have indicated that the following document is ready for submission to the IESG to be considered

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

Hello James, I'm fine with all the changes you propose. Thanks for the explanations. Jasdip On 6/26/23, 3:17 PM, "Gould, James" mailto:jgo...@verisign.com>> wrote: Section 1: "The redacted JSON fields will either be removed or have empty values in the RDAP response." ... Isn't that

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

Indeed, was not concerned about keys starting with ‘@’, given they are deterministic unlike the dynamic JSONPointer strings as keys. Thanks, Jasdip From: Mario Loffredo Date: Tuesday, June 13, 2023 at 12:30 PM To: Jasdip Singh Cc: "Hollenbeck, Scott" , "jgould=40verisign

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

ok forward to feedback from others. Jasdip [1] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/ From: "Gould, James" Date: Tuesday, July 25, 2023 at 2:53 PM To: "t...@apnic.net" , Jasdip Singh , "regext@ietf.org" Subject: draft-ietf-regext-rdap-r

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

Hello Andy, Scott, Let’s take a specific example from the RIR search draft (a specification with multiple extension identifiers defined) to test-drive these options. Say, an IP network search response: { "rdapConformance": [ "rdap_level_0", "rirSearch1",

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

+1 Jasdip From: Mario Loffredo Date: Tuesday, December 12, 2023 at 3:09 AM To: "Gould, James" , "gal...@elistx.com" , Jasdip Singh Cc: "regext-cha...@ietf.org" , "regext@ietf.org" , Andy Newton Subject: Re: [regext] ACTION REQUESTED: Re: RDAP-X draf

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

+1 for adoption. Jasdip From: regext on behalf of "Hollenbeck, Scott" Date: Thursday, January 18, 2024 at 7:59 AM To: "regext@ietf.org" Subject: [regext] WG Adoption Request: draft-hollenbeck-regext-epp-delete-bcp draft-hollenbeck-regext-epp-delete-bcp was updated yesterday to address the

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

F. Title: An RDAP Extension for Geofeed Data Authors: Jasdip Singh Tom Harrison Name: draft-ietf-regext-rdap-geofeed-01.txt Pages: 10 Dates: 2023-12-17 Abstract: This document defines a new RDAP extension "geofeed1" for including a geofeed file URL in an IP Network object. The IETF dat

  1   2   >