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

[Jasdip Singh]

Thanks for your feedback, James. And, sorry for the late reply.

As for point #2, Section 6 gives the rationale for choosing “ips” over 
“_ips” (and similarly, “autnums” over ““_autnums”) 
for these new search path segments:

“Because IP network objects and autonomous system number objects are part of 
the original set of object types defined for use in RDAP, it may be unintuitive 
or confusing for users if the basic searches and associated responses defined 
here include the "rir_search" extension prefix, since the searches and 
associated responses for the other original object types do not include a 
prefix.”

Agreed that this would be an exception to the prefix rule but from the RIRs’ 
perspective, a reasonable one. If there is sufficient WG support for this 
exception for these new basic searches, perhaps we could clarify it in the 
“RDAP Extensions” draft [1]. Look 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-rir-search Feedback

Tom & Jasdip,

Ahead of the REGEXT meeting this afternoon, I did a review of 
draft-ietf-regext-rdap-rir-search and below is my feedback:


  1.  I believe that the search for ips and autnums should have been included 
in RFC 9082 from the start, but I’m glad that you’re looking at add support in 
this draft.
  2.  My biggest issue is the extension identifier and the lack of using it in 
the path segments (“ips” and “autnums”)
 *   First, I want to say that I don’t see that the use of “ips” and 
“autonums” will cause any confusion or conflict, but I can’t see getting past 
the normative language defined in the base RFCs.  Section 6 “RDAP Conformance” 
attempts to get around the normative language, but I don’t believe it will 
address the requirement.  I see two options for this:

   i.  Use a 
shorter extension identifier as a prefix for the new path segments, such as 
“rir” with the path segments “rir_ips” and “rir_autnums”

   *   This would result in a single entry in the rdapComformance 
element for the draft but will require the use of the non-optimal path 
segments.  You could stick with the “rir_search” identifier, but that will make 
the path segments even worse with “rir_search_ips” and “rir_search_autonums”.

 ii.  Define an 
identifier for “ips” and an identifier for “autnums”, which would be 
represented independently in the rdapConformance.

   *   There is no requirement to include the “_suffix”, so this will 
result in optimal path segment values (“ips” and “autnums”) and provides for 
separation by object.
 *   The use of “rir_search” may still be needed or something like it for 
the relation search defined in section 3.1 “Path Segments”.  You could leverage 
the first option above with the prefix “rir” and the suffix “_search” to 
perform the relation search.  The second option adds some complexity to support 
a crosscutting search function like “rir_search”, where you could use 
“ips_search” and “autnums_search” values or do without them since “ips” and 
“autnums” are registered identifiers.  The “rir_search” under the domain path 
segment is more of an issue that needs to be considered, potentially by adding 
a third identifier (“rir”) to support it.

--

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 mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Murray S. Kucherawy]

AD evaluation:

Thanks, Andy, for a good shepherd writeup.  It would be helpful, even if it
seems redundant or obvious, to include an answer to the question about why
Proposed Standard is the right status for this document.

The first paragraph of Section 3 is a bit confusing; it says you MUST NOT
use any placeholder text as a replacement for a redacted value, and then I
read the next sentence to suggest that there might actually be valid
replacement placeholder text although it might not conform to the expected
syntax.  But on a second read, I think you're telling me that the reason
it's MUST NOT is because there could be a syntax mismatch which could upset
parsers.  If that's correct, I suggest combining the sentences with
"because" or "since".

In Section 3.2, why are these two SHOULDs not MUSTs?  What's the choice
being offered here, and what guidance should we provide?  Same question for
the one in Section 3.3.

Doesn't the method of Section 3.4 directly conflict with the MUST NOT in
Section 3 (referenced above)?

Also in Section 3.4, s/alternate/alternative/

In Section 4.2, for "prePath" and "postPath", this is a JSON path
expression, not a JSON expression, correct?

In Section 6.2, I suggest being precise: You're talking about the "RDAP
JSON Values" registry.

Thanks for including Section 7.

-MSK, ART AD



On Mon, Aug 7, 2023 at 7:24 AM James Galvin via Datatracker <
nore...@ietf.org> wrote:

> James Galvin has requested publication of
> draft-ietf-regext-rdap-redacted-13 as Proposed Standard on behalf of the
> REGEXT working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/
>
>
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Publication has been requested for draft-ietf-regext-rdap-openid-23

[Murray S. Kucherawy]

AD review:

I note that the shepherd writeup's last question points out the creation of
a registry using Specification Required rules, and thus doesn't need a
designated expert, referencing RFC 8126 Section 4.6.  However, that section
of that RFC says:

   This policy is the same as Expert Review, with the additional
   requirement of a formal public specification.  In addition to the
   normal review of such a request, the designated expert will review
   the public specification and evaluate whether it is sufficiently
   stable and permanent, and sufficiently clear and technically sound to
   allow interoperable implementations.


So yes, we do need to appoint designated expert(s) and this document needs
to include any advice that they should have when reviewing specifications.
Such advice is missing here.  Do you want to add any?

I also note from the writeup that you attempted to get OAUTH WG input but
were not successful.  I will raise this to the SEC ADs and ask them for
advice as soon as I've sent this.  For that matter, you might want to
trigger an early SECDIR review, although there's going to be one as part of
Last Call anyway.

In Section 3.1.2, what is a "given period of interaction"?

In Section 3.1.3, bullet 1, "OpenID OpenID Providers".

In Section 3.1.3, bullet 1, why is that only a SHOULD?  Why might I not do
this?

In Section 3.1.4, why is that only a SHOULD?  Why might I not do this?

In Section 3.1.4.1, same question.

In Section 5.1.1, the entire object is OPTIONAL.  This doesn't seem right.
Would there be any practical use to such a thing?

In Section 5.5, why is that SHOULD not a MUST?

In Section 9.2, at least in the HTML version I looked at, the two
registrations are run together.  It would be helpful to readers to separate
them somehow, at least with a blank line, though you could also make each a
subsection.

Thanks for including Section 10.

-MSK, ART AD

On Mon, Aug 7, 2023 at 6:36 AM James Galvin via Datatracker <
nore...@ietf.org> wrote:

> James Galvin has requested publication of draft-ietf-regext-rdap-openid-23
> as Proposed Standard on behalf of the REGEXT working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/
>
>
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext