[regext] RDAP versioning draft feedback

[Jasdip Singh]

Hi James, Daniel, Mario,

I read the latest draft and to help tighten this spec, have few higher-level 
comments.

VCHAR use:

In section 3.1, the ABNF for “versioning” in “extension-version-identifier” is 
“["-" 1*VCHAR]”. Since the extension version identifiers could be passed in the 
“extensions” parameter of the RDAP-X media type in the HTTP accept and/or 
content-type headers, it would be safer to constrict them to what’s allowed in 
those headers. E.g., for the accept header, a parameter value (per section 
5.6.6 of RFC 9110) is “parameter-value = ( token / quoted-string )” where 
“token” is any VCHAR minus the delimiters (section 5.6.2 of RFC 9110). The 
reason AFAIU is to help prevent injection attacks. From security angle, good to 
address this.

Rationale for versioning:

Section 1 says, “The RDAP Conformance values are identifiers with no standard 
mechanism to support structured, machine-parseable version signaling by the 
server.” It’d be good to elaborate with usage scenarios where such structured 
versioning is a value-add for clients beyond what the opaque (no inner meaning) 
extension identifiers from STD 95 afford. Let’s say an extension is “foo1”, 
then “foo99”, and later “foo2” in terms of “versions”. The server announces its 
support for these non-structured extensions, say, on its web site or through 
the “rdapConformance” member in a /help response, and the clients can then 
negotiate a particular non-structured version of this extension using the 
standard HTTP content negotiation methodology (e.g., using the RDAP-X media 
type). In the spirit of what-not-to-do, it is fair for a client to ask: Why 
should I go through the overhead of processing the “versioning_help” member? 
What value-add does it get me? Is it in some way a better discovery and/or 
negotiation method for RDAP extensions? Would be good to beef up the rationale 
for structured versioning.

RDAP-X way:

To help client implementors, beside the “versioning” query parameter examples, 
would be good to include one or more RDAP-X examples.

/help path segment:

Section 3.1.6 of RFC 9082 says, “The help path segment can be used to request 
helpful information (command syntax, terms of service, privacy policy, 
rate-limiting policy, supported authentication methods, supported extensions, 
technical support contact, etc.) from an RDAP server.” Using a new “versioning” 
query parameter for /help, is this spec updating RFC 9082? Not sure but thought 
of asking.

Further, beside the “versioning” extension version identifier itself, are any 
other extension version identifiers allowed in the “versioning” query parameter 
for /help? If not, good to clarify that.

Caution with using “versioning” query parameter in non-help path segments:

It would be good to beef up the security and privacy considerations for the 
risks with using “versioning” query parameters in non-help path segments 
vis-à-vis RDAP redirects and referrals, as the Extensions draft cautions.

Thanks,
Jasdip

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

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

[Tom Harrison]

Hi Pawel,

On Tue, Oct 22, 2024 at 08:51:32AM +0200, kowa...@denic.de wrote:
> On 21.10.24 23:57, Tom Harrison wrote:
>> [...] In the absence of any text permitting partial implementation,
>> this text requires implementers to implement the whole document
>> ("the functionality specified in this document"). [...]
>
> Thanks for clarification.Did the authors consider putting using
> RFC2119 language for that?

No, but we will add some text to make it clearer, since it's only an
editioral change (will upload along with any subsequent feedback that
we get during the rest of the process).

>> As far as the forward domain use case is concerned, the
>> "/domains/rirSearch1/..." specification text can't be relied on
>> as-is, because it's all in terms of reverse domains, and depends on
>> their correspondence with internet number resources.  If somebody
>> wanted similar link relation searches for forward domains, then I
>> think it makes more sense to define that in a separate document,
>> rather than trying to generalise this document to support that use
>> case as well.
> 
> This is I guess a bit the problematic part. Relation search seems to
> be as generic use case as reverse search and having a second
> specification on forward zones looks a potential burden for a
> generic client implementations.  If the path part for the relation
> search would have been kept generic, like /domains/relsearch/ it
> could be extended by other documents to other relation types not
> specified in rir document. This brings me also to a conclusion, that
> an extension prefix would be rather harmful as it would pin the
> functionality and the path segment to rir extension, even if it
> would allow further extensions and as client one would expect the
> path to remain same.

Generalising reverse search makes sense, because it works in exactly
the same way regardless of the underlying object types.  Relation
search is not in the same category, IMHO, because the exact behaviour
of a given relation for a given object type is not a function of the
relation alone.  For example, up/top/etc. don't have obvious
implementations for entities.  As far as path consistency goes, the
client will still have to have foreknowledge of all the relation
searches that are supported anyway, so whether those searches are at
path A or path B doesn't seem like something that would cause much of
a problem implementation-wise.

-Tom

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] draft-ietf-regext-rdap-x-media-type-02 Feedback

[Gould, James]

Upon a re-review of draft-ietf-regext-rdap-x-media-type with 
draft-ietf-regext-rdap-x-media-type-02, I have the following feedback:

Section 2 "RDAP-X: The RDAP With Extensions Media Type"
Needs to be updated to support the Extension Version Identifier implicitly or 
explicitly, defined in Section 3.1 "Extension Version Identifier" of 
draft-ietf-regext-rdap-versioning.  The mailing list feedback 
https://mailarchive.ietf.org/arch/msg/regext/L377YVNleqV7s7tJPWTGBLJIIG4/ 
provided an implicit (compatible) recommendation with 
draft-ietf-regext-rdap-versioning, and below is an explicit recommendation as 
well.

Implicit Support included in 
https://mailarchive.ietf.org/arch/msg/regext/L377YVNleqV7s7tJPWTGBLJIIG4/

  1.  In Section 2: Change "This media type has a parameter of "extensions" 
which is a whitespace-separated list of RDAP extensions as defined in the IANA 
RDAP Extensions registry" to "This media type has a parameter of "extensions" 
which is a whitespace-separated list of RDAP extensions, such as defined in the 
IANA RDAP Extensions registry”.
  2.  In Section 3: Change “the values in the media type's extension parameter 
SHOULD match the values in the rdapConformance array in the return JSON.” to 
“the extension identifier values in the media type's extension parameter SHOULD 
match the values in the rdapConformance array in the return JSON.”
Explicit Support

  1.  Make "I-D.ietf-regext-rdap-versioning" a Normative Reference instead of 
an Informative Reference
  2.  Add RFC5234 as a Normative Reference to leverage ABNF to formally define 
the format of the “extensions” parameter.
  3.  Update Section 2 to be modeled after Section 3.2.1” Versioning Query 
Parameter” in draft-ietf-regext-rdap-versioning, by using ABNF and referencing 
the extension-versioning-identifier ABNF rule from 
draft-ietf-regext-rdap-versioning, as in:

The media type defined by this document is "application/rdap-x+json". This 
media type has a parameter of "extensions" that is a list of one or more 
Extension Version Identifiers, as defined in Section 3.1 of 
[I-D.ietf-regext-rdap-versioning],
 separated by whitespace.  This media type, RDAP with Extensions, is referred 
to as RDAP-X.  The Augmented Backus-Naur Form (ABNF) 
grammar 
[RFC5234] format for the "extensions" 
parameter, using the "extension-version-identifier" rule from Figure 1 of 
[I-D.ietf-regext-rdap-versioning],
 is:

extensions = "extensions=" DQUOTE extension-version-identifier *(WSP 
extension-version-identifier) DQUOTE

Examples of RDAP-X:
applications/rdap-x+json;extensions="rdap_level_0 rdapx"
applications/rdap-x+json;extensions="rdap_level_0 rdapx fred"

Note - It looks like the "rdapx" extension identifier is missing from the 
example, so I added it.

Section 3 "Using The RDAP-X Media Type"
My initial thought upon re-review of this section was to reuse the existing 
"application/rdap+json" media type by adding the optional parameter 
"extensions", or better "rdapx" to the media type registration, but then I got 
to Appendix B.1 that makes a good point with the language in RFC 6838.  I 
really don't want to include RDAP-X in the content-type header of the response, 
since it duplicates the rdapConformance member, and requires updating RFC 7480 
with no real positive value.  Updating RFC 7480 may also trigger the need to 
bump rdap_level_0 to rdap_level_1, which is certainly not desired.  We should 
re-evaluate the language of RFC 6838 in its application to an RDAP extension.  
How about adding support for RDAP-X in the accept header of the request and to 
have the response content-type header remain using the existing media type of 
"application/rdap+json"?  This would meet the need of the client providing the 
RDAP extension hints without the negative side effects of updating RFC 7480 and 
bumping rdap_level_0 to rdap_level_1.

Section 4 "Usage of RDAP Links"
The point of this section is recursing the RDAP extension hints in the links, 
which would also apply to the use of the query parameter of the versioning 
extension.  We can review for this applicability in the versioning draft.

Section 6 "Security Considerations"
You can remove the second paragraph, since that would be covered in an 
extension that supports query parameters, such as the versioning extension.

Section 7 "IANA Considerations"
I would add an RDAP Extensions Registry registration for "rdapx".

Appendix A "Using the Vary Header"
Wouldn't this recommendation be covered in a different draft, such as 
draft-ietf-regext-rdap-extensions since it's not specific to RDAP-X?

Appendix B.1 "Not Reusing the Existing Media Type"
This section helped me out since my thought was to reuse the existing 
"application/rdap+json" media type instead of defining the