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

[Jasdip Singh]

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 Should maxSigLife have a more normative reference (RFC 4034) than RFC 
5910?
  4.  5.3 Figure 24: Handle in the entity object is  but it is  in 
links’ URIs.
  5.  5.4 Figure 26: Handle in the entity object is  but it is  in 
links’ URIs. Lastly, RFC 5952 recommends lowercase v6 notation (section 4.3); 
may lowercase (C00) in http://example.net/ip/2001:C00::/23 and likes.
  6.  5.4 Should startAddress be clarified as "a string representing the 
starting…”? Similarly, for endAddress description.
  7.  5.5 Should the "Autonomous System Number Entity Object Class” title be 
“The Autonomous System Number Object Class”?
  8.  5.5 So as to hold 4-byte ASNs (0 to 4294967295), should we clarify the 
JSON number as uint32 (unsigned) (as per 
https://developers.google.com/discovery/v1/type-format)?
  9.  5.5 Should name be clarified as "a string representing an identifier…”?

Thanks,
Jasdip


On Feb 18, 2020, at 7:31 AM, Hollenbeck, Scott 
mailto:shollenbeck=40verisign@dmarc.ietf.org>>
 wrote:

FYI, folks. This is the first version of 7483bis. It contains updates to 
address the known errata, described here:

https://www.rfc-editor.org/errata_search.php?rfc=7483

I need to fix the Unicode characters again, though. I'll do that with the next 
update. In the meantime, I could use help in documenting existing RDAP server 
implementations as described in the Implementation Status section. If you'd 
like to include a description of your implementation, please let me know and 
I'll get it in. I could also use help in confirming that xml2rfc didn't 
inadvertently change anything during the conversion from RFC format back to I-D 
format. Lastly, let's start to talk about any other needed clarifications. Are 
you aware of any? Send 'em to the list for discussion.

Scott

-Original Message-
From: I-D-Announce  On Behalf Of 
internet-dra...@ietf.org
Sent: Tuesday, February 18, 2020 7:21 AM
To: i-d-annou...@ietf.org
Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


   Title   : JSON Responses for the Registration Data Access 
Protocol (RDAP)
   Authors : Scott Hollenbeck
 Andy Newton
   Filename: draft-hollenbeck-regext-rfc7483bis-00.txt
   Pages   : 80
   Date: 2020-02-18

Abstract:
  This document describes JSON data structures representing
  registration information maintained by Regional Internet Registries
  (RIRs) and Domain Name Registries (DNRs).  These data structures are
  used to form Registration Data Access Protocol (RDAP) query
  responses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7483bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-hollenbeck-regext-rfc7483bis-00
https://datatracker.ietf.org/doc/html/draft-hollenbeck-regext-rfc7483bis-00


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 this question. Jasdip? Tom? Anyone?

Yah, it models the reverse relationship. An entity could be an organization or 
a point of contact. When former, “networks" and “autnums" in that entity's 
query response represent the IP and ASN resources the registry has issued to it 
(following the visibility rules in place).

Jasdip
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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: Hollenbeck, Scott 
mailto:shollenb...@verisign.com>>
Cc: regext@ietf.org<mailto:regext@ietf.org>
Subject: [EXTERNAL] 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.)

[SAH] I’m not so sure. I haven’t found a normative style guide that describes 
spacing conventions, and I see inconsistent use of spaces in our own standard 
for JSON data interchange (see Section 13 of RFC 7159). I think I’d like to 
leave these alone.

You are right. :)


  1.  5.3 Should maxSigLife have a more normative reference (RFC 4034) than RFC 
5910?

[SAH] maxSigLife doesn’t appear in RFC 4034, so I think 5910 is the appropriate 
reference.

No, you are right.


  1.  5.3 Figure 24: Handle in the entity object is  but it is  in 
links’ URIs.
  2.  5.4 Figure 26: Handle in the entity object is  but it is  in 
links’ URIs. Lastly, RFC 5952 recommends lowercase v6 notation (section 4.3); 
may lowercase (C00) in http://example.net/ip/2001:C00::/23 and likes.

[SAH] Will fix.

  1.  5.4 Should startAddress be clarified as "a string representing the 
starting…”? Similarly, for endAddress description.

[SAH] Will fix.

  1.  5.5 Should the "Autonomous System Number Entity Object Class” title be 
“The Autonomous System Number Object Class”?

[SAH] Will fix.

  1.  5.5 So as to hold 4-byte ASNs (0 to 4294967295), should we clarify the 
JSON number as uint32 (unsigned) (as per 
https://developers.google.com/discovery/v1/type-format)?

[SAH] will fix.

  1.  5.5 Should name be clarified as "a string representing an identifier…”?

[SAH] Will fix.
Thanks,
Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

Hi. I am fine with this update. Thanks for highlighting and clarifying it, 
James and Mario.

Jasdip

From: regext  on behalf of "Hollenbeck, Scott" 

Date: Monday, October 5, 2020 at 8:53 AM
To: "mario.loffr...@iit.cnr.it" , 
"gal...@elistx.com" , "regext@ietf.org" 
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis


From: regext  On Behalf Of Mario Loffredo
Sent: Saturday, October 3, 2020 5:38 AM
To: James Galvin ; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis



Il 02/10/2020 22:06, James Galvin ha scritto:
The WGLC for this document was scheduled to end today.  While there is support 
to move the document forward there are two minor comments that have been raised 
during the last call.

The chairs would like to hear from other working group members as to what to do 
with these comments.  Rather than close the last call and risk another last 
call, we are extending this last call for another week.  If we can come to a 
consensus as to how to proceed before the end of last call than the document 
can stay on track to be submitted to the IESG after the last call.

The WG last call will end at close of business on Friday, 9 October 2020.



Here are the comments as seen on the mailing list.  Please respond with your 
suggestions regarding these two comments.



James Gould:

I have one item to bring up with draft-ietf-regext-rfc7483bis, which is 
associated with Section 5.1 “The Entity Object Class”.   The jCard "version" 
and "fn" members are required according to RFC 6350, which poses an issue if a 
contact name does not exist or needs to be redacted.  To address this case, I 
recommend adding a sentence to the end of section 3 "Common Data Types":

Contact information is defined using jCards as described in [RFC7095].  The 
“version” and “fn” members are required according to [RFC6350], where an empty 
“fn” member MAY be used when the contact name does not exist or is redacted.

Two response have been offered:

Scott Hollenbeck:

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 clarification is 
necessary?

Jasdip Singh:

Seems if the RDAP profile for the DNRs 
(https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en<https://secure-web.cisco.com/1FxE3-8AUQw4AMA04p2iQVRJh0991-gT1gZXLVQSMAGE7tIRQNXEHKTfHbT8hB5Hh6DzlG-girMWkzLkV72lTk4Z8roLcu5bB8T1cfS56XCwqHHHCAZY_boa6q_s3GO3IWufTUBd7di2-x_W-1_pUctunaV9v5bOUtNuRIA_bSa3p1iqsMLydRI3WQg2z4xHhx8OOkodbwNnUW-FQULjEfcgY99Rggri_FHuPl8aeW-B4Bh8cqaMNy-Y2xpTGGu5gvE3kTjgn4VYoHYJtA5JfQQ/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpages%2Frdap-operational-profile-2016-07-26-en>)
 could clarify this, the spec could be left as-is.



IMHO RFC7095 omits to state something about the "fn" element while it states 
clearly that the "version" element must be set to "4.0".  This omission leaves 
the door open to the interpretation that the empty string is an allowable 
value. In my opinion this interpretation is correct while the "fn" element must 
not be null. Besides, in this way,  RDAP implementers are free to differentiate 
between the case where a value is missing from the case where the value exists 
but isn't displayed for privacy concerns.

That being said, I would write the above sentence as in the following:

Contact information is defined using jCards as described in [RFC7095].  The 
“fn” member is required and MUST NOT be null according to [RFC6350], where an 
empty “fn” member MAY be used when the contact name does not exist or is 
redacted.

[SAH] I’m OK with this. Any objections?

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

Hi.

Section 5.1 of 7483bis ( 
https://tools.ietf.org/html/draft-ietf-regext-rfc7483bis-01#section-5.1 ) 
defines handle as:

  handle -- a string representing a registry-unique identifier of the entity

The phrase 'registry-unique identifier' connotes a unique lookup key for 
entities, irrespective of their type. It puts the onus on a registry to ensure 
so. Does that not suffice?

Jasdip

On 10/5/20, 9:15 AM, "regext on behalf of Gould, James" 
 
wrote:

Scott,

>> I'm still not comfortable with this. If we suggest that the server MUST 
or SHOULD do something to define a scheme, we leave open the issue of how a 
client discovers that scheme - and if we add a processing step to discover the 
scheme, we've changed the protocol from the client's 
>> perspective. I still believe that this is an issue best addressed in an 
implementation profile document and not the protocol specification.

I believe that providing guidance in the protocol to the real-world 
overlapping of entity handles (contact and registrar) as necessary.  The 
protocol would have explicit language on how to handle the case of overlapping 
entity handles.  A discovery mechanism is not needed, since we didn't have a 
need to create one based on the approach taken.  

-- 
 
JG



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 10/5/20, 9:00 AM, "regext on behalf of Hollenbeck, Scott" 
 wrote:

> -Original Message-
> From: regext  On Behalf Of Mario Loffredo
> Sent: Saturday, October 3, 2020 3:18 AM
> To: James Galvin ; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: 
draft-ietf-regext-rfc7482bis
>
>
> Il 02/10/2020 22:15, James Galvin ha scritto:
> > The WGLC for this document was scheduled to end today.  While there 
is
> > support to move the document forward there is one minor comment that
> > has been raised during the last call.
> >
> > The chairs would like to hear from other working group members as to
> > what to do with this comment.  Rather than close the last call and
> > risk another last call, we are extending this last call for another
> > week.  If we can come to a consensus as to how to proceed before the
> > end of last call than the document can stay on track to be submitted
> > to the IESG after the last call.
> >
> > The WG last call will end at close of business on Friday, 9 October 
2020.
> >
> >
> > Here are the comments as seen on the mailing list.  Please respond
> > with your suggestions regarding these two comments.
> >
> >
> > James Gould:
> >
> > Yes, lumping the registrar object with the contact object under a
> > single RDAP entity object interface is the rub.  We solved the 
problem
> > in the RDAP Profile, by supporting entity lookup by IANA ID (number)
> > and registrar name (string) for the registrar objects, and by ROID
> > (“((\w|_){1,80}-\w{1,8}") for the contact objects. Where there is
> > overlap, which is registrar name (string) and ROID
> > ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence.  My
> > recommendation is to provide guidance in the section 3.1.5 "Entity
> > Path Segment Specification" for this real world case:
> >
> > The  parameter represents an entity (such as a contact,
> > registrant, or registrar) identifier whose syntax is specific to the
> > registration provider.  For example, for some DNRs, contact
> > identifiers are specified in [RFC5730] and [RFC5733], and registrar
> > identifiers are specified using the IANA Registrar ID assigned by
> > ICANN.  The server SHOULD define a scheme for the  parameter
> > to differentiate between the supported entity object types (e.g.,
> > 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 is to provide guidance to
> > implementers of the protocol.
> >
> > Two responses have been offered:
> >
> > Jasdip Singh response:
> >
> > One thought is if it could be in th

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

[Jasdip Singh]

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:

> -Original Message-
> From: Gould, James 
> Sent: Monday, September 21, 2020 2:27 PM
> To: Hollenbeck, Scott ; i...@antoin.nl;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: 
draft-ietf-regext-rfc7482bis
>
> Scott,
>
> Yes, lumping the registrar object with the contact object under a single 
RDAP
> entity object interface is the rub.  We solved the problem in the RDAP
> Profile, by supporting entity lookup by IANA ID (number) and registrar 
name
> (string) for the registrar objects, and by ROID (“((\w|_){1,80}-\w{1,8}") 
for
> the contact objects.  Where there is overlap, which is registrar name 
(string)
> and ROID ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence.  My
> recommendation is to provide guidance in the section 3.1.5 "Entity Path
> Segment Specification" for this real world case:
>
> The  parameter represents an entity (such as a contact, 
registrant,
> or registrar) identifier whose syntax is specific to the registration 
provider.
> For example, for some DNRs, contact identifiers are specified in [RFC5730]
> and [RFC5733], and registrar identifiers are specified using the IANA 
Registrar
> ID assigned by ICANN.  The server SHOULD define a scheme for the 
> parameter to differentiate between the supported entity object types 
(e.g.,
> 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 is to provide guidance to
> implementers of the protocol.

I'd like to see some discussion of this suggestion, too. What do people 
think? Is it necessary?

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 Message-
> From: regext  On Behalf Of Gould, James
> Sent: Tuesday, September 22, 2020 10:55 AM
> To: i...@antoin.nl; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: 
draft-ietf-regext-rfc7483bis
>
> I have one item to bring up with draft-ietf-regext-rfc7483bis, which is
> associated with Section 5.1 “The Entity Object Class”.   The jCard 
"version"
> and "fn" members are required according to RFC 6350, which poses an issue
> if a contact name does not exist or needs to be redacted.  To address this
> case, I recommend adding a sentence to the end of section 3 "Common Data
> Types":
>
> Contact information is defined using jCards as described in [RFC7095].  
The
> “version” and “fn” members are required according to [RFC6350], where an
> empty “fn” member MAY be used when the contact name does not exist or
> is redacted.

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 clarification is 
necessary?

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] RDAP reverse search draft feedback

[Jasdip Singh]

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" 
Subject: Re: [regext] RDAP reverse search draft feedback


  1.  Why introduce the keyword “reverse” in the search path? Is it to 
distinguish from the related reverse search scenarios (e.g. domains by nsIp) 
defined in 7843bis? In light of introducing a new extension for this draft, the 
“reverse” keyword may be redundant.
[ML] The main reason is to clearly identify the paths dedicated to reverse 
search so RDAP providers can more easily control the access to reverse search 
services on a per-path basis. Moreover, maybe in the next future, RDAP servers 
might implement additional services and having different paths make the mapping 
between the services and the users more manageable at the implementation level. 
In the REST context, resources can be easily protected according to their path.


  1.  Instead of defining the generic reverse search path 
{resource-type}/reverse/{role}?{property}=, would it be better 
to take a specific search path, say domains versus nameservers versus entities, 
and define the new query parameters (that fill the current search gaps) for 
each of them section-by-section? Please ignore this comment if the intent here 
is to pivot around the roles defined in the IANA RDAP JSON Values registry.

[ML] I'm deeply convinced that specifying the entity role is fundamental for an 
effective implementation of a reverse search feature. For two reasons:

1. to furtherly map the reverse search services against the user profiles: 
searching domains for a technical contact might be allowed to more users than 
searching domains for a registrant

2. to restrict the scope of a reverse search query: a reverse search without 
specifying a role usually takes longer and involves much more objects than 
doing the same for a specific role and I think that rarely a reverse search 
would be requested without considering a role.

Anyway, the draft takes all the scenarios.

I report as a response to the following comment the reasons why I have opted 
for defining the role in the path rather than as a query parameter.

  1.  Knowing that it gets more complex but is it possible that folks may need 
to pass multiple query parameters for conjunctive criteria? If so, 
{resource-type}/reverse/{role}?{property}= may need to evolve 
to account for multiple query parameters.

[ML] Provided that we agree that specifying the role in a reverse search query 
would be useful, I reported here in the following some possible solutions with 
the related pros and cons:

1. replicating the properties used for reverse searching for the possible roles 
in the query parameters (e.g. registrantFn, technicalHandle)

  Pros: very compact in itself and in a conjunctive criteria (e.g. 
registrantFn=X=Y)

  Cons: not very effective because there would be a proliferation of query 
parameters, and, as I wrote above,  the role specification in the path might 
help the implementers' burden in controlling the access to the reverse search 
services. In my opinion, not very neat from the conceptual point of view as 
well.

2. letting role be a query parameter (e.g. fn=X=registrant).

  Pros: simple solution (it was the first solution I proposed)

  Cons: unusable in building conjuntive criteria and, like the soluion 
aforementioned, unpractical for controlling the accesses.

3. specifying the role in the query path:

 Pros: the most effective solution for controlling the accesses and very 
flexible and conceptually neat.

 Cons: unusable in conjunctive criteria, at least in those mentioning two 
reverse search properties.

  Anyway, this is true if we think that GET must be the only HTTP method 
available in RDAP. It is well known that GET allows to specify a query where 
parameters are joined solely in AND. It would be desireable that all boolean 
operators should be allowed and, in my opinion, this could be done only if the 
query is submitted via POST . I have already implemented a draft version of 
this feature. I don't wanna go into much detail on this service here but the 
key aspects are:

  a. a POST can be submitted on the specific path "/query" (e.g. domains/query)

 b. the request body is a JSON map including the parameters normally used in a 
GET query like count, sort, fieldSet plus a parameter named "query"  to deliver 
a complex search predicate as a JSON object. All the boolean operators are 
allowed, likewise predicates at different nesting level. Search properties 
related to RDAP contents are reported as strings: "nsLdhName", 
"reverse/registrant/fn"

 4. any other solution not listed before.
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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:


Il 31/07/2020 16:10, Hollenbeck, Scott ha scritto:
>> -Original Message-
>> From: Mario Loffredo 
>> Sent: Friday, July 31, 2020 9:49 AM
>> To: Hollenbeck, Scott ; regext@ietf.org
>> Subject: [EXTERNAL] Re: [regext] IANA Considerations in 
draft-ietf-regext-
>> rdap-reverse-search
>>
>> Hi Scott,
>>
>> Il 31/07/2020 15:21, Hollenbeck, Scott ha scritto:
 -Original Message-
 From: Mario Loffredo 
 Sent: Friday, July 31, 2020 9:03 AM
 To: Hollenbeck, Scott ; regext@ietf.org
 Subject: [EXTERNAL] Re: [regext] IANA Considerations in
 draft-ietf-regext- rdap-reverse-search

 Hi Scott,

 thanks a lot for your feddback.

 Please find my comments to your feedback below.

 Il 31/07/2020 14:29, Hollenbeck, Scott ha scritto:
> draft-ietf-regext-rdap-reverse-search currently states that "This
> document
 has no actions for IANA".  I believe that's primarily because there's
 nothing new or different being returned in the search results, which
 is where RDAP servers describe the features they support.
 Exactly.
> There is, however, a case to be made for registering a value in the
> RDAP
 extensions registry: a response to a help query (or any other query)
 can be used to indicate that the server supports reverse search. I'd
 like to suggest this change for Section 7:
> OLD:
> This document has no actions for IANA.
>
> NEW:
> IANA is requested to register the following value in the RDAP
> Extensions
 Registry:
> Extension identifier: reverse_search_1_0 (or whatever makes sense)
> Registry operator: Any Published specification: This document.
> Contact: IESG 
> Intended usage: This extension describes reverse search query
> patterns
 for RDAP.
> Scott
 I agree.

 Furthermore, my opinion is that Section 4.1 of RFC7483bis should be
 updated to treat this use case. I mean, a server should signal in
 rdapConformance not only the extensions used in building the response
 but all the supported features.
>>> So maybe this?
>>>
>>> OLD:
>>> The data structure named "rdapConformance" is an array of strings, each
>> providing a hint as to the specifications used in the construction of the
>> response.
>>> NEW:
>>> The data structure named "rdapConformance" is an array of strings, each
>> providing a hint as to the specifications that describe the query and 
response
>> formats supported by the server.
>>> Scott
>> How about "query and response extensions" ?
> That would exclude the core protocol specifications. Is this better?
>
> "The data structure named "rdapConformance" is an array of strings, each 
of which describes a query or response specification supported by the server."

OK. I wrote "extensions" in my previous message to mean "in addition to 
rdap_level_0".

Mario

>
> Scott
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 construction of the response." It is about 
what specifications were used for the returned response. No?

In my opinion, the sentence "specifications used in the construction of 
the response" seems to be limited to those specifications introducing 
some response extensions or complying the response with a specific 
profile. The current reverse search proposal affects only the query 
formats.

[JS] Right, this proposal extends RDAP query scenarios but rdapConformance is 
about response capabilities for various query scenarios, including this one. So 
if a reverse search query is responded to, including the new extension in the 
rdapConformance portion of the response indicates that capability. And, the 
current description of rdapConformance in 7843bis being response-centric seems 
to suffice as-is for the newly proposed extension.

> On 7/31/20, 10:28 AM, "regext on behalf of Mario Loffredo" 
 wrote:
>
>  
>  Il 31/07/2020 16:10, Hollenbeck, Scott ha scritto:
>  >> -Original Message-
>  >> From: Mario Loffredo 
>  >> Sent: Friday, July 31, 2020 9:49 AM
>  >> To: Hollenbeck, Scott ; regext@ietf.org
>  >> Subject: [EXTERNAL] Re: [regext] IANA Considerations in 
draft-ietf-regext-
>  >> rdap-reverse-search
>  >>
>  >> Hi Scott,
>  >>
>  >> Il 31/07/2020 15:21, Hollenbeck, Scott ha scritto:
>  >>>> -Original Message-
>  >>>> From: Mario Loffredo 
>  >>>> Sent: Friday, July 31, 2020 9:03 AM
>  >>>> To: Hollenbeck, Scott ; 
regext@ietf.org
>  >>>> Subject: [EXTERNAL] Re: [regext] IANA Considerations in
>  >>>> draft-ietf-regext- rdap-reverse-search
>  >>>>
>  >>>> Hi Scott,
>  >>>>
>  >>>> thanks a lot for your feddback.
>  >>>>
>  >>>> Please find my comments to your feedback below.
>  >>>>
>  >>>> Il 31/07/2020 14:29, Hollenbeck, Scott ha scritto:
>  >>>>> draft-ietf-regext-rdap-reverse-search currently states that 
"This
>  >>>>> document
>  >>>> has no actions for IANA".  I believe that's primarily because 
there's
>  >>>> nothing new or different being returned in the search results, 
which
>  >>>> is where RDAP servers describe the features they support.
>  >>>> Exactly.
>  >>>>> There is, however, a case to be made for registering a value 
in the
>  >>>>> RDAP
>  >>>> extensions registry: a response to a help query (or any other 
query)
>  >>>> can be used to indicate that the server supports reverse 
search. I'd
>  >>>> like to suggest this change for Section 7:
>  >>>>> OLD:
>  >>>>> This document has no actions for IANA.
>  >>>>>
>  >>>>> NEW:
>  >>>>> IANA is requested to register the following value in the RDAP
>  >>>>> Extensions
>  >>>> Registry:
>  >>>>> Extension identifier: reverse_search_1_0 (or whatever makes 
sense)
>  >>>>> Registry operator: Any Published specification: This document.
>  >>>>> Contact: IESG 
>  >>>>> Intended usage: This extension describes reverse search query
>  >>>>> patterns
>  >>>> for RDAP.
>  >>>>> Scott
>  >>>> I agree.
>  >>>>
>  >>>> Furthermore, my opinion is that Section 4.1 of RFC7483bis 
should be
>  >>>> updated to treat this use case. I mean, a server should signal 
in
>  >>>> rdapConformance not only the extensions used in building the 
response
>  >>>> but all the supported features.
>  >>> So maybe this?
>  >>>
>  >>> OLD:
>  >>> T

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

[Jasdip Singh]

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, Hollenbeck, Scott wrote:
> Note "supported extensions". This is why I'm saying that we need to 
> register all extensions with IANA

I agree.

> and include them in the 
> rdapConformance data structure even if they don't describe a response 
> extension. 

I agree, everything should be listed in the reply to an help query.

I am just saying that for any other reply that is a specific one on a 
specific resource
then the rdapConformance should just list the "extensions" needed to 
understand this
specific response, and not list absolutely all extensions the server knows 
about
(and that are irrelevant for this specific response).

The list of what is written in the response should certainly not be just 
server policy,
especially if there is no automated way to learn about this policy. 
Otherwise if you include
options like that (the list presented might be the list of all server 
extensions OR only the subset needed for this specific response) AND there is 
no way for the client to know which
case he is in, it immediately creates interoperability problems. I prefer 
no such options
and the protocol clearly defining the content. Or if such options are 
really needed
(if help response is always all extensions, and any other response is just 
the specific extensions needed, then nothing more is needed), there should be  
a signal to know which
case we are in.

> The help response should include supported 
> extensions that are available to that client.

Yes, the help response allows to "discover" all possible extensions from a 
specific client.

-- 
  Patrick Mevzek
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] RDAP reverse search draft feedback

[Jasdip Singh]

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 just noting 
that Regional Internet Registries (RIRs) also implement the domains search for 
their reverse DNS zones. :) Something to consider for the Introduction section?
  3.  Why introduce the keyword “reverse” in the search path? Is it to 
distinguish from the related reverse search scenarios (e.g. domains by nsIp) 
defined in 7843bis? In light of introducing a new extension for this draft, the 
“reverse” keyword may be redundant.
  4.  Instead of defining the generic reverse search path 
{resource-type}/reverse/{role}?{property}=, would it be better 
to take a specific search path, say domains versus nameservers versus entities, 
and define the new query parameters (that fill the current search gaps) for 
each of them section-by-section? Please ignore this comment if the intent here 
is to pivot around the roles defined in the IANA RDAP JSON Values registry.
  5.  Knowing that it gets more complex but is it possible that folks may need 
to pass multiple query parameters for conjunctive criteria? If so, 
{resource-type}/reverse/{role}?{property}= may need to evolve 
to account for multiple query parameters.
  6.  Though not directly related with this draft, just an observation from 
7483bis that there the IP Network and Autonomous System Number objects can be 
listed in an entity (an org) lookup response but not the Domain objects. Not 
sure if this was by design?
  7.  May be just me but found the abstract a bit verbose. Move some of it to 
the Introduction section?

Thanks,
Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 in the following:

  -  An OPTIONAL  element that contains the date and
 time of the most recent domain-object modification.  This element
 MUST NOT be present if the domain object has never been modified.

So, should we redefine the "last changed" event accordingly? Should we change 
all the examples where "last changed" date is equal to "registration" date?

[SAH] I think we can leave this one alone. The meaning seems clear to me since 
we also have the registration event. We could change the examples, but before I 
do that I'd like to know what people have implemented. Do servers return this 
value for an object that has been registered, but never updated?

+1

For a registered but never updated scenario, we return the “last change” date 
as well, equal to the “registration” date.

Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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] 
reference needs the correct link. Additionally, in section 8, 
[I-D.ietf-regext-rfc7482bis] has no link.
  *   1.1: Is the trailing period intended for member, object, and object class 
definitions?
  *   2.1: Should lunarNic prefix in the fields match the casing of the 
lunarNIC prefix for the extension in 4.1? I know there was some discussion on 
this but not sure if they are orthogonal or not.
  *   4.5: Looks like extraneous trailing period for eventDate description.
  *   5.3: Does the description of the network member need a trailing period?
  *   5.5: "high-level structure of the autnum object class consists of 
information about the network registration” - should “network” be changed to 
"autonomous system number”?
  *   Should phrase “registry unique” be “registry-unique” to be consistent?
  *   13.2: [RFC7480] needs a link.
  *   Typo “referencce” in the Changes from RFC 7483 section. Also, “00:” used 
twice in the list.

Thanks,
Jasdip
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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, June 11, 2020 2:01 PM
To: regext@ietf.org<mailto:regext@ietf.org>
Subject: [EXTERNAL] [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.

[SAH] OK

  *   1, 5, 5.4, 5.5, 7, 8: Looks like the [I-D.ietf-regext-rfc7482bis] 
reference needs the correct link. Additionally, in section 8, 
[I-D.ietf-regext-rfc7482bis] has no link.

[SAH] I don’t see the issue, Jasdip. I see references to 
[I-D.ietf-regext-rfc7482bis], which is correct. The reference includes the 
correct URL, too. What’s missing?
There is a potential  issue with references to 7482bis due to a limitation with 
xml2rfc. The two documents reference each other, and as soon as you update one 
the bibliography that xml2rfc uses to manage references gets outdated. I have 
to edit the final text file manually to make this fix.

  *   1.1: Is the trailing period intended for member, object, and object class 
definitions?

[SAH] I think those are just editorial artifacts that can be removed for 
consistency.

  *   2.1: Should lunarNic prefix in the fields match the casing of the 
lunarNIC prefix for the extension in 4.1? I know there was some discussion on 
this but not sure if they are orthogonal or not.

[SAH] They should probably be consistent to avoid questions just like this one 

  *   4.5: Looks like extraneous trailing period for eventDate description.

[SAH] I can remove that.

  *   5.3: Does the description of the network member need a trailing period?

[SAH] Probably note, since the other descriptions don’t use a trailing period.

  *   5.5: "high-level structure of the autnum object class consists of 
information about the network registration” - should “network” be changed to 
"autonomous system number”?

[SAH] Yes.

  *   Should phrase “registry unique” be “registry-unique” to be consistent?

[SAH] Yes.

  *   13.2: [RFC7480] needs a link.

[SAH] What link? The reference in the text looks appropriate. If you’re looking 
at an HTML version of the document and there’s a problem with a missing link, 
that’s a bug in the tools that generate the HTML version of the document.

  *   Typo “referencce” in the Changes from RFC 7483 section. Also, “00:” used 
twice in the list.

[SAH] 00 is used twice because there’s been both a -00 version of the 
individual submission and a -00 version of the working group version. I’ll fix 
the typo.  Thanks for the feedback!

Thanks,
Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

+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 
"Internet standard” as described by the process in RFC6410.
We therefor seek specific consensus from reviewers that they are aware of 
the elevation requirements, and that they have reviewed this document with the 
elevation intention in mind.

Please review this document and indicate your support (a simple “+1” is 
sufficient) or concerns with the publication of this document as “Internet 
standard” by replying to this message on the list.

This WG last call will end Sunday, 2 January 2021.


Regards,

Jim and Antoin



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

+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 
"Internet standard” as described by the process in RFC6410.
We therefor seek specific consensus from reviewers that they are aware of 
the elevation requirements, and that they have reviewed this document with the 
elevation intention in mind.

Please review this document and indicate your support (a simple “+1” is 
sufficient) or concerns with the publication of this document as “Internet 
standard” by replying to this message on the list.

This WG last call will end Sunday, 2 January 2021.


Regards,

Jim and Antoin


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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://datatracker.ietf.org/doc/draft-blanchet-regext-rfc7484bis/

Please review this draft to see if you think it is suitable for adoption 
by REGEXT, and comment to the list, clearly stating your view.

Please indicate if you are willing to contribute text, review text, or 
be a document shepherd.

Please also indicate any preference you have for a proposed milestone 
date.

This call for adoption ends Monday, 1 February 2021.

If there are no objections, and we receive enough consensus for 
adoption, the chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Antoin and Jim

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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/draft-loffredo-regext-rdap-jcard-deprecation/

Please review this draft to see if you think it is suitable for adoption 
by REGEXT, and comment to the list, clearly stating your view.

Please indicate if you are willing to contribute text, review text, or 
be a document shepherd.

Please also indicate any preference you have for a proposed milestone 
date.

This call for adoption ends Monday, 1 February 2021.

If there are no objections, and we receive enough consensus for 
adoption, the chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Antoin and Jim

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 will address the concern that 
has been raised.

This document actually covers two distinct issues.

1. A specification for jsContact.
2. A proposal for migrating to jsContact from jCard.

There are words suggesting that jCard would be deprecated as part of 
this and the question has been raised on the list as to whether or not 
this is actually a reality.

The Chairs would like to propose that we separate out the question of 
whether or not jCard will be deprecated.  That is better considered as a 
separate question.

Since there is precedent in the IETF for documenting alternate ways of 
meeting a requirement, here is what we propose.

This CALL FOR ADOPTION is to commit to a specification of jsContact.  
The specification would be permitted to document how one could migrate 
from jCard to jsContact.  The starting point for this work is 
draft-loffredo-regext-rdap-jcard-deprecation-03.

If this document is adopted, then we will need to consider the 
relationship between the use of jsContact and jCard.  The IESG will ask 
us this question as part of considering the publication of any document 
we develop.  This will effect the potential status of the document, 
e.g., Proposed Standard vs Experimental.  More specifically, we will 
need to consider whether there is support to migrate to something new 
given the legacy deployment.  It is appropriate to have this discussion 
within the working group.

With all that in mind, here is the revised, extended CALL FOR ADOPTION:


This is a formal adoption request for “Using JSContact in Registration 
Data Access Protocol (RDAP) JSON Responses”:


https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-jcard-deprecation/

This document will serve as the starting point for documenting 
jsContact.  It may also document how to migrate from jCard to jsContact, 
depending on the consensus of the working group.

Please review this draft to see if you think it is suitable for adoption 
by REGEXT for the stated purpose, and comment to the list, clearly 
stating your view.

If adopted, the document will be renamed as follows: 
draft-ietf-regext-rdap-jscontact.

Please indicate if you are willing to contribute text, review text, or 
be a document shepherd.

Please also indicate any preference you have for a proposed milestone 
date.

This call for adoption ends Monday, 22 February 2021.

If there are no objections, and we receive enough consensus for 
adoption, the chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Antoin and Jim




On 18 Jan 2021, at 9:29, 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/draft-loffredo-regext-rdap-jcard-deprecation/
>
> Please review this draft to see if you think it is suitable for 
> adoption by REGEXT, and comment to the list, clearly stating your 
> view.
>
> Please indicate if you are willing to contribute text, review text, or 
> be a document shepherd.
>
> Please also indicate any preference you have for a proposed milestone 
> date.
>
> This call for adoption ends Monday, 1 February 2021.
>
> If there are no objections, and we receive enough consensus for 
> adoption, the chairs will consider this document adopted.
>
> Thanks,
>
> Your REGEXT co-chairs Antoin and Jim

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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)? It may help 
to gauge what other protocols have done in the past when presented with such a 
trade-off.

Jasdip  

On 1/29/21, 8:16 AM, "regext on behalf of Hollenbeck, Scott" 
 wrote:

> -Original Message-
> From: regext  On Behalf Of James Galvin
> Sent: Monday, January 18, 2021 9:29 AM
> To: REGEXT WG 
> Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-loffredo-regext-
> rdap-jcard-deprecation-03
> 
> Caution: This email originated from outside the organization. Do not 
click links
> or open attachments unless you recognize the sender and know the content
> is safe.
> 
> This is a formal adoption request for “Using JSContact in Registration 
Data
> Access Protocol (RDAP) JSON Responses”:

While I understand the motivation for this draft, I'm a little worried that 
it's trying to solve a problem that is no longer a problem for anyone who has 
completed a jCard implementation. At this point, RDAP implementations with 
jCard are quite widespread among registries, registrars, and RIRs.  

Yes, we've heard that jCard can be cumbersome or tedious to implement, but 
once that work is done, an implementer has something that works.  Due to the 
nature of the problem domain, it is stable and doesn't require maintenance. 

While an implementation involving jSContact would certainly be more elegant 
from a technical perspective, I see limited value in developing a specification 
that would imply re-doing what has already been implemented to produce 
something that does basically the same thing. There must be some material 
benefit for implementers (of both servers and then clients) to offset the 
development and deployment cost of re-implementing the contact representation. 
Section 2 of the draft describes differences from jCard - are they enough to 
justify this investment?

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

Hello Marc,

One input: In section 5.3 (Bootstrap Service Registry for AS Number Space), 
should we add a normative reference to RFC 5396 for AS number format? We have 
such normative references to IPv4 and IPv6 formats in sections 5.1 and 5.2.

Jasdip

On 3/19/21, 4:47 PM, "regext on behalf 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.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

+1

Jasdip

On 4/12/21, 9:20 AM, "regext on behalf of James Galvin" 
 wrote:

The following working group document is believed to be ready for 
submission to the IESG for publication as an Internet Standard:

https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/

Please note: This specification is currently a Proposed Standard.  It is 
advancing to an Internet Standard.  It is important that the working 
group show support for this advancement.  The chairs will be looking for 
this support.

This WG LAST CALL will end at close of business, 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,

Antoin and Jim

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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-regext-rfc7482...@ietf.org; regext-cha...@ietf.org;
> regext@ietf.org; Mario Loffredo 
> Subject: [EXTERNAL] Murray Kucherawy's No Objection on draft-ietf-regext-
> rfc7482bis-02: (with COMMENT)
...
> In Section 4.1:
> 
>If a server receives a search request but cannot process the request
>because it does not support a particular style of partial match
>searching, it SHOULD return an HTTP 422 (Unprocessable Entity)
>[RFC4918] response.
> 
> Why's that only a SHOULD?  What else might an implementer choose to do,
> and why might that be a reasonable thing to do?  Or if there's no good
> answer to this, maybe that should be a MUST?

[SAH] I'm going to blame that on one of the WEIRDS co-chairs ;) who 
reviewed 7482.

I agree that it might help to add some more text to explain the rationale 
for the SHOULD. I don't recall why we used SHOULD here, other than noting that 
there may be some other response code that might be more appropriate based on a 
server's policy settings. A server that doesn't support search at all, for 
example, might instead return a 405 response code. Hmm, might this be an 
appropriate explanation right here?

[JS] Since, per Section 1, returning 501 (Not Implemented) is a MUST for any 
unsupported query types (including search), employing 405 (Method Not Allowed) 
for the unsupported-search scenario to help explain the SHOULD for 422 
(Unprocessable Entity) could be confusing. Just wanted to highlight that. :)


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] rfc7484bis feedback

[Jasdip Singh]

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 good to replace references to RFC 7159 with RFC 8259.

Knowing that this spec allows the http scheme (beside the https scheme) in the 
IANA bootstrap files, wonder if we should at the least discontinue using the 
http scheme in our examples, so as not to inadvertently encourage the http 
scheme use?

Is an Implementation Status section needed for elevating RFC 7484 to Internet 
Standard?

Section 1:


   Querying and retrieving registration data from registries are defined

   in Registration Data Access Protocol (RDAP) 
[RFC7480] 
[RFC7482]

   [RFC7483].

Should we mention RFC 7481 here as well since it covers RDAP security?

Section 2:


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

   document are to be interpreted as described in 
[RFC2119].

For consistency, should we append “ when specified in their uppercase form” (as 
done in rfc7482bis and rfc7483bis)?

Section 4:


The entry for the root of the domain name space is specified as "".

Unless missed, didn’t find such an entry in 
https://data.iana.org/rdap/dns.json. Is this sentence extraneous now?

Section 5.1:

Should we only use the IPv4 space reserved for documentation (RFC 5737) in the 
example here? The IESG review of rfc7482bis and rfc7483bis pointed to using 
number resources (IP address space and AS numbers) reserved for documentation 
purposes in related examples.

For the present example:

   client chooses one of the base URLs from this array; in this example,
   it chooses the only one available, "http://example.org/;.  The
   {resource} specified in [RFC7482] is 
then appended to the base URL to
   complete the query.  The complete query is then "https://example.org/
   ip/192.0.2.1/25".

Is there http/https inconsistency here vis-a-vis "http://example.org/; and 
“https://example.org/ip/192.0.2.1/25”?

Section 5.2:

Should we only use the IPv6 space reserved for documentation (RFC 3849) in the 
example here?

In the present example, should we avoid using extraneous 0 as in the 0200 
hextet in 2001:0200::/23? https://data.iana.org/rdap/ipv6.json seems to avoid 
so.

Section 5.3:

Should we only use the AS numbers reserved for documentation (RFC 5398) in the 
example here?

Section 8:


   In the case of a domain object,…

   …This method may not work

   for all types of RDAP objects.

Could we omit saying “This method may not work for all types of RDAP objects” 
given we are here talking about domain objects only?


   Some authorities of registration data may work together on sharing

   their information for a common service, including mutual redirection

   
[REDIRECT-RDAP].

[REDIRECT-RDAP] refers to an expired draft: 
https://tools.ietf.org/html/draft-ietf-weirds-redirects-04.
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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" : "autnum",
>  "handle" : "-RIR",
>  "startAutnum" : 10,
>  "endAutnum" : 15,
> 
> IIUC AS numbers 10 through 15 are assigned by ARIN, including AS 11 that 
is
> assigned to Harvard University (last updated 2019-08-12) and appears to 
be in
> current use.  Perhaps the reserved ASN 0 would make for a safer example?

[SAH] Perhaps. I'll check with my ARIN colleagues.

[JS] As per RFC 5398 ( https://tools.ietf.org/html/rfc5398 ), IANA's AS numbers 
registry ( https://www.iana.org/assignments/as-numbers/as-numbers.xhtml ) 
reserves couple of ASN ranges for documentation purposes: 64496-64511 and 
65536-65551. We could use them instead in our examples.


>*  type -- a string containing an RIR-specific classification of the
>   autnum
> 
> (nit) is this the RIR's classification of the number itself, or the
> allocation/registration?

[SAH] I'll check with my ARIN colleagues.

[JS] Though this field is not required as per the NRO RDAP profile for RIRs ( 
section 5.5 in 
https://bitbucket.org/nroecg/nro-rdap-profile/raw/v1/nro-rdap-profile.txt ), I 
believe it is intended to indicate the registration hierarchy for those AS 
numbers as per that RIR's registration model. The "type" field also exists in 
section 5.4 for the IP Network objects. If we clarify this field further, would 
be good to do so consistently in both the places.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

+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 regarding draft-gould-regext-rdap-redacted.  Based on this feedback and 
an action item at the meeting, we are asking the working group to adopt the 
draft-gould-regext-rdap-redacted document.  We have identified a document 
shepherd if the draft is adopted.

Please let me know if you have any questions.

Thanks,
Jody Kolker
GoDaddy

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] RDAP JSContact feedback

[Jasdip Singh]

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 for contact information”

Is it possible someone could question the “efficient” part, given the RDAP 
response with JSContact would likely be bigger in size than that with jCard? 
E.g. the sample jscard member in Fig 1 is 2724 characters whereas the 
equivalent vcardArray member in Fig 17 in RFC 9083 is 1842 chars, per this 
word-count tool<https://wordcounter.net/character-count>. May help to elaborate 
what we mean here with efficiency.

[ML] The reasons why the authors considers JSContact more efficient than jCard 
are presented in Section 2 (please see after "JSCard differs from jCard in that 
it:"). Searching for the meaning of "efficient" on the web, I find "performing 
or functioning in the best possible manner with the least waste of time and 
effort" so I might change the sentence as in the following:

" more efficient representation for contact information with regard to time and 
effort saved in processing it."

Would it sound better to you?

[JS] Yes.

3.  Using JSCard objects in RDAP Responses

“The JSCard "uid" property SHOULD contain the same value as the RDAP "handle" 
property.”

Curious why it is not a MUST?

[ML] Well, RDAP "handle" is registry-unique while JSContact "uid" is an 
identifier deigned to be unique across different systems.

That being said, my opinion is: if the contact is used only as part of an RDAP 
response, the two properties will much likely coincide. On the contrary, if the 
contact is used by the registry also outside the RDAP ecosystem, they will 
potentially differ.

Honestly don't know how much the second scenario is realistic but SHOULD leaves 
the door open to possible evolutions.

[JS] Ok.

“To aid interoperability, RDAP providers are RECOMMENDED to use as map keys the 
following string values and labels defined in [RFC5733]”

Should we elaborate upon the consequences if this recommendation is not 
followed? Should this be a MUST?

[ML] This is merely a basic set of map keys related to registry's mostly used 
information items and recalls the basic field sets described in RFC8982.

In that circumstance, the WG decided that, being part of the operational 
aspects, the field set names should be dependent on the RDAP profiles.

Should the WG agree on the provided keys, I would have no problem to change it 
into MUST.

[JS] Agreed. Good to ask.

“"org" in the "organizations" map for either the only or the internationalized 
organization;”

Should we clarify further here? Are we trying to say: use it only when there is 
a single org, whether internationalized or not?
[ML] Use it when there is a single org. If both internationalized and localized 
forms exist, use it for the internationalized form and put the localized one in 
the "localizations" property.

[JS] Like how you elaborated it. Perhaps we can include it for clarity.

“"addr" in the "addresses" map for either the only or the internationalized 
postal address ;”

If we do end up clarifying for org, similar clarification would be needed here.
Nit: extra space before the semi-colon.
[ML] See my previous comment. I'll correct the typo.


“"email" in the "emails" map for the email address;”

Should we address the EAI (email address internationalization) scenario here, 
similar to org and addr i18n?
[ML] Absolutely. I missed that.


“If present, the localized versions of name, organization and postal address 
MUST be inserted into the "localizations" map.”

For clarity, would it help to include an example for the localized versions?
[ML] Agreed.

[JS] Great!


“Implementers MAY use different mapping schemes to define keys for additional 
entries of the aforementioned maps or others.”

Should we elaborate this further with an example? Do we need to discuss client 
implications for this MAY?

[ML] As I wrote above, the provided map keys are related to the contact 
properties described in RFC5733 so they are assumed to be the most commonly 
used by registries.

However, with reference to the Figure 15 of RFC9083, other contact information, 
such as vCard "key" and "url", could be included in other JSContact maps, i.e. 
the "online" map.

Obviously, I can add an example matching this case in the document but I can't 
find a reasonable mapping scheme other than using a trivial sequential number 
(e.g. url-1, url-2, etc.)  that seems very trivial to me.

[JS] Agreed; an example looks like an overkill. Perhaps, for guidance, we could 
add some verbiage around “using a trivial sequential number (e.g. url-1, url-2, 
etc.)“.

4.  Tran

Re: [regext] Fwd: RDAP JSContact feedback

[Jasdip Singh]

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 here, given “uid” would be a non-opaque handle in 
jscard?

[ML] Sorry but I didn't catch this. Did you mean that "uid" in jscard could 
disclose some sensitive contact information?

[JS] That’s an interesting question. In contrast with a UUID for a “uid”, a 
handle might disclose. But, I was simply reacting to the “usually an opaque 
string” phrase given we have a SHOULD for “uid” being a handle. Meaning, in our 
case, it would more likely be a handle (less opaque) than a UUID (more opaque).

[ML] UUID is not the only value accepetd for "uid" in JSContact (see 
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-08#section-2.1.2),
 both URI and free-form text are accepted.

Maybe opaque is not the right term. I'll rearrange the sentence to mean that 
the only required property in JSContact is not a sensitive information as it 
happens with fn for jCard.

[JS] Yes, that’ll clarify.



Thanks,

Jasdip
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] RDAP JSContact feedback

[Jasdip Singh]

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 possible someone could question the “efficient” part, given the RDAP 
response with JSContact would likely be bigger in size than that with jCard? 
E.g. the sample jscard member in Fig 1 is 2724 characters whereas the 
equivalent vcardArray member in Fig 17 in RFC 9083 is 1842 chars, per this 
word-count tool. May help to elaborate 
what we mean here with efficiency.

3.  Using JSCard objects in RDAP Responses

“The JSCard "uid" property SHOULD contain the same value as the RDAP "handle" 
property.”

Curious why it is not a MUST?

“To aid interoperability, RDAP providers are RECOMMENDED to use as map keys the 
following string values and labels defined in [RFC5733]”

Should we elaborate upon the consequences if this recommendation is not 
followed? Should this be a MUST?

“"org" in the "organizations" map for either the only or the internationalized 
organization;”

Should we clarify further here? Are we trying to say: use it only when there is 
a single org, whether internationalized or not?

“"addr" in the "addresses" map for either the only or the internationalized 
postal address ;”

If we do end up clarifying for org, similar clarification would be needed here.
Nit: extra space before the semi-colon.

“"email" in the "emails" map for the email address;”

Should we address the EAI (email address internationalization) scenario here, 
similar to org and addr i18n?

“If present, the localized versions of name, organization and postal address 
MUST be inserted into the "localizations" map.”

For clarity, would it help to include an example for the localized versions?

“Implementers MAY use different mapping schemes to define keys for additional 
entries of the aforementioned maps or others.”

Should we elaborate this further with an example? Do we need to discuss client 
implications for this MAY?

4.  Transition Considerations

4.2.1.6.  Goals

Should we move this sub-section up to the top, so as to upfront give the reader 
a sense of the “requirements” for the transition design?

“the response would always be compliant to [RFC9083];”

What does this mean when 9083 does not know about JSCard?

4.2.1.2.  Stage 2: jCard sunset

“include a description reporting the jCard sunset end time”

Should we clarify that the notice’s description string would contain both the 
time and date, as we do when defining eventDate in RFC 
9083?

“"rel": "deprecation"”

In various examples (Figures 2, 3, 4, and 5), we use this “deprecation” rel 
type. Do we need to register it with the IANA Link Relations 
registry?

“plus the parameter "jscard" set to a true value”

Should we make it consistent with “1/true/yes” from section 4.2.1.3.  Stage 3: 
jCard deprecation?

6.  IANA Considerations

“Extension identifier: jscard”

Should we version this extension as say, jscard_0, in case we need to evolve it 
in the future? That said, we have not always versioned extensions in the IANA 
RDAP 
Extensions
 registry.

7.  Security Considerations

“The only mandatory property, namely "uid", is usually an opaque string.”

Do we need to clarify further here, given “uid” would be a non-opaque handle in 
jscard?

“redacted properties can be merely excluded without using placeholder values”

Now that we have the RDAP redaction 
draft, 
should we elaborate further vis-à-vis the Removal and/or Empty Value redaction 
methods?

General comments:


  1.  Does the portion of the spec for jCard to JSContact transition signaling 
add significant implementation overhead for RDAP servers and clients? Could an 
out-of-band (OOB) method have been employed? (There is a similar transition 
effort happening in the RPKI space, in moving from rsync to 
RRDP, 
but that seems more OOB.) Just wanted to ask in the spirit of “what not to do.” 
:)
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 phrasing at least got some action into this discussion.
I didn’t mean to say that we can’t have 2 standards, but we should at least 
have clarity on the status of this document.
Because the original document title was 
"jcard-deprecation",
 and the introduction still talks about the intent and transition mechanisms to 
replace jCard, we can be a bit clearer that jsContact is a second standard, at 
least until jCard can be deprecated from support in RDAP after jsContact is 
sufficiently supported.

When we all agree jsContact is a second standards track document not intended 
to deprecate jCard just yet today, then that’s fine.
If we don’t get feedback this document should have a different status than 
standards track, then the chairs will add that intended status next week.

Which leaves the remaining questions Mario posted in his original message.

- --
Antoin Verschuren







Op 8 dec. 2021, om 14:53 heeft Gould, James 
mailto:jgould=40verisign@dmarc.ietf.org>>
 het volgende geschreven:

I view the jscontact is a valid use case for a standards track RDAP extension.  
We have many similar use cases for standards track extensions in EPP, where the 
RFCs couldn't envision a feature or an approach that comes up later.  The 
jscontact draft needs to be defined as an RDAP extension that is optional, with 
the appropriate signaling, and with transition considerations to support a 
transition from the jCard defined in RFC 9083 to JSContact defined in the 
extension.  I don't foresee that support for jCard will go away, but that 
JSContact can be become an alternative and potentially a preferred format for 
the RDAP contact data.  As Scott points out, supporting multiple formats can 
add complexity, but I believe that is a known cost to progress.

--

JG



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

On 12/8/21, 5:31 AM, "regext on behalf of Gavin Brown" 
mailto:regext-boun...@ietf.org> on behalf of 
gavin.br...@centralnic.com> wrote:


   On 8 Dec 2021, at 09:55, Mario Loffredo 
mailto:mario.loffr...@iit.cnr.it>> wrote:




Il 07/12/2021 14:42, Marc Blanchet ha scritto:



Le 7 déc. 2021 à 08:35, Hollenbeck, Scott 
mailto:shollenbeck=40verisign@dmarc.ietf.org>>
 a écrit :

We can *certainly* do that, Mario. It’s the option I support because there is a 
cost to replace a jCard implementation once it’s been implemented and deployed. 
Make it an optional extension and let server operators decide if/when they want 
to make the change.

I note that this will make life more difficult for client implementors because 
they’ll have to support both formats.

But the genie is already out of the bottle… I.e. if one have done a client 
implementation, it has already support for jCard. Adding the JSContact is just 
more code.  There will be only less work if one is implementing a client in the 
future after the whole ecosystem had moved to JSContact, therefore no need to 
implement jCard, which is still a good win, as I guess that many haven’t 
implemented a client yet since whois is still dominant and RDAP is not yet at 
the same level.
+1

Every extension requires an implementation effort and every transition process 
from the old to the new requires a period where both coexist.

If we hadn't been aware of that, we wouldn't have started the process to 
replace Whois with RDAP. And, like Marc pointed out, this process is still at 
the beginning  and we still don't imagine when it will really be completed.

In addition to that, I wonder why some members are so worried about the 
implementation effort done in this case in comparison to other extensions that 
completed the reviewing process.

   Speaking as a client implementer, the amount of work required to update my 
RDAP client to support JSContact was minimal - which speaks to how much easier 
JSContact is to work with than jCard. You can see every change required in 
https://client.rdap.org here:

   
https://secure-web.cisco.com/1_Pf0XRu1tk3UR9-6jZ90CvItjm2neWOUbvFQlelz4q63NRctDM-rSfl0bSRaAV5EIV9aE7ka0U0or5uuTlvu68I6aSE7VnsWBMFLUFRToK6mDmJVHxBBFK9ztDZYSfxcAMaVmIUkFCaAOHPItTkzGJXFdCLs60lPUJp2yLiotBDfMlMsuDyuTUll6Ztrs4m3Vj8YoUgfwCkcXc0kxZzpigQikmbW3FGPQi8p2bgQ2NvJay4AkRznJp9CFRCj47UD/https%3A%2F%2Fgitlab.centralnic.com%2Fcentralnic%2Frdap-web-client%2F-%2Fcompare%2Fba4fd514...c9deae03

   Getting JSContact working in the CentralNic RDAP server took a bit more 
work, but I see it as being 

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

[Jasdip Singh]

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 
mailto:shollenbeck=40verisign@dmarc.ietf.org>>
 a écrit :

From: regext mailto:regext-boun...@ietf.org>> On 
Behalf Of Hollenbeck, Scott
Sent: Monday, February 14, 2022 12:12 PM
To: jasd...@arin.net<mailto:jasd...@arin.net>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-rdap-openid-10.txt

Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

From: Jasdip Singh mailto:jasd...@arin.net>>
Sent: Monday, February 14, 2022 10:34 AM
To: Hollenbeck, Scott 
mailto:shollenb...@verisign.com>>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-rdap-openid-10.txt

Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

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 could coalesce them as 
“session/{start|refresh|end}”, with “login” becoming “session/start”, and 
“logout” “session/end”. “device” and “devicepoll” could be appended in the path 
as-n-when needed.

[SAH] What do you all think of this suggestion? The draft currently has 
“login”, logout”, and “session” path segments. Should they be combined?

[SAH] I’m going to make a suggestion in the absence of any feedback. I’d like 
to remove the session path segment and combine it with the login path segment 
such that the draft will describe the following path segments:

/login
/login/status
/login/refresh
/login/device
/login/devicepoll
/logout

This eliminates the session path segment and merges the functionality with the 
“easier to understand” login/logout semantics.

I would prefer to have a single endpoint for the “sessions”, as current 
practice. How about:

/session/login
/session/status
/session/refresh
/session/device
/session/devicepoll
/session/logout

[JS] Like this better if everyone agrees. :)

Regards, Marc.



Any issues?

Scott
___
regext mailing list
regext@ietf.org<mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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: Monday, February 14, 2022 12:12 PM
To: jasd...@arin.net; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-rdap-openid-10.txt


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

From: Jasdip Singh mailto:jasd...@arin.net>>
Sent: Monday, February 14, 2022 10:34 AM
To: Hollenbeck, Scott 
mailto:shollenb...@verisign.com>>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-rdap-openid-10.txt


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

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 could coalesce them as 
“session/{start|refresh|end}”, with “login” becoming “session/start”, and 
“logout” “session/end”. “device” and “devicepoll” could be appended in the path 
as-n-when needed.

[SAH] What do you all think of this suggestion? The draft currently has 
“login”, logout”, and “session” path segments. Should they be combined?

[SAH] I’m going to make a suggestion in the absence of any feedback. I’d like 
to remove the session path segment and combine it with the login path segment 
such that the draft will describe the following path segments:

/login
/login/status
/login/refresh
/login/device
/login/devicepoll
/logout

This eliminates the session path segment and merges the functionality with the 
“easier to understand” login/logout semantics. Any issues?

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 could coalesce them as 
“session/{start|refresh|end}”, with “login” becoming “session/start”, and 
“logout” “session/end”. “device” and “devicepoll” could be appended in the path 
as-n-when needed.

2. Wonder if we would be better-off defining a new RDAP object class called 
“session” instead of overloading the current definition of a notice? IIUC, per 
RFC 9083, “description” (in a notice object) is an array of strings for the 
purposes of conveying any descriptive text. Looks like returning “claims” and 
the session expiration info could use a new, more axiomatic structure instead. 
Further, this should help RDAP clients avoid parsing descriptive text 
(something not recommended) for the session semantics. Defining this new 
“session” object class should also correlate well with the proposed coalescing 
of the 3 new path segments into “session/…”.

Regards,
Jasdip

From: regext  on behalf of "Hollenbeck, Scott" 

Date: Monday, February 14, 2022 at 8:44 AM
To: "mario.loffr...@iit.cnr.it" , "regext@ietf.org" 

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

From: Mario Loffredo 
Sent: Monday, February 14, 2022 2:05 AM
To: Hollenbeck, Scott ; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-rdap-openid-10.txt


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Hi Scott,

here in the following some additional feedback:

1)  In the introductory sections, nothing is written about the fact that an 
RDAP server outsources authentication services to an OP  if the registry trusts 
that OP.

I think that this is a pre-condition to make a federation and for this reason, 
in my opinion, it's worth being mentioned somewhere at the beginning of the 
draft.

[SAH] OK, I’ll see what I can add.

2) It seems from the text of section 3.1.3 that dynamic registration is the 
only method available  to register an RP. Instead, we all know that the most 
commonly used method to do that is manually through an out-of-band procedure. I 
think this alternative should also be mentioned to make section 3.1.3 
consistent with the text in section 3.1.3.1 about the fact that an RDAP server 
can trust a limited number of OPs and out-of-band methods are used to implement 
the discovery process. If an RDAP server supports a limit number of OPs, it 
doesn't make sense that it is registered dynamically.

[SAH] Agreed, I’ll add text to make it clear that out-of-band methods are both 
available and acceptable.

3) It seems from the draft content that the session expiring time is tied to 
the access token lifespan. Instead, in my experience with Keycloak, the session 
max idle time corresponds to the refresh token lifespan.

Honestly, don't know if this happens in other OPs, anyway, I would opt for 
letting the RDAP server choose the basis to calculate the session expiring time 
upon and in Section 4.2 I would omit the sentence "... to refresh the access 
token associated with the current session and ...".

[SAH] Agreed. The expiration value is only RECOMMENDED per the normative 
reference, so it really is up to the RDAP server to determine when things 
expire.

In addition, in general, I would replace "token refresh" with "session 
refresh". After all, the endpoint that should be used for refreshing is called 
"session/refresh" and the final result to the End-User would be that the 
session lifetime is extended.

[SAH] Agreed.

4) It doesn't make sense to me to return the claims in the response to the 
"session/refresh" query. Can they really change during the session?

[SAH] They can’t, but I think it’s a good idea to return them so that the 
client has an easy way to retrieve that information at any time without having 
to logout and then login again.

5) If I understood well, a successful "session/refresh" query don't always 
result in resetting the session expiring time. How can the RDAP server decide 
to do that?

[SAH] As noted above, it’s something that the RDAP server has to manage. I’d 
like to RECOMMEND and make it clear that the RDAP server SHOULD extend the 
duration of a session as part of processing a refresh, otherwise a refresh 
doesn’t do anything. Thanks again for the feedback!

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

+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://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

This WG last call will end at close of business, Monday, 18 April 2022.

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 Tom Harrison.

Regards,

Jim and Antoin





___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 signaling beyond RDAP 
conformance) and thereby, guarantees near-zero breakage (breakage only possible 
if a client ignores the transition time)
- has a simple registration model for each opaque extension identifier

Jasdip

On 5/27/22, 10:25 AM, "regext on behalf of Gould, James" 
 
wrote:

Mario,

[ML] My only objection to Approach C is that every new version would 
result in registering a new extension identifier. I would opt for a 
less 
verbose solution, if any.

I'm not aware of the plan for new versions of the existing extensions, so I 
don't view it as a scalability issue.  While an extension is an Internet Draft, 
the pointed versions will not be registered until the draft becomes an RFC.  
This is similar to what happens with the EPP extensions, where pre-RFC 
implementers can use the pointed version contained in the draft for signaling 
that will eventually become a full registered version (e.g., "0_N" becoming "1" 
or "1_N" becoming "2") in the registry.  When there are multiple versions of an 
extension, I believe it is important to capture those versions in the RDAP 
Extension Registry with a link to the associated specification.  Mixing 
versioning with the prefixes I believe is unnecessary and brittle, so I don't 
support Approach A.  Approach B provides the flexibility to define the full 
RDAP Conformance version in the specification, so it supports versioning 
without the brittle side effects, but I view Approach C as being better since 
the versioning is more explicit in the registry.  If there is the risk of an 
overload of versions in the registry, then I would agree with the concern of 
Approach C, but I don't believe that risk exists. 

-- 

JG



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

On 5/27/22, 10:10 AM, "Mario Loffredo"  wrote:

Hi james,

my comment inline.

Il 27/05/2022 14:43, Gould, James ha scritto:
> Mario,
>
> Thank you for providing an example of the complexity of versioning 
that is associated with tightly coupling the RDAP compliance value with the set 
of prefixes.  Unfortunately, RDAP doesn't include the same sort of version 
negotiation that exists in EPP with the use of XML namespace URIs in the 
greeting and login services.  I view the RDAP Conformance being closer to the 
EPP greeting services.  I'll continue down the EPP line of discussion, where 
EPP leverages the XML namespace URIs for versioning that is tied to XML schemas 
and leverages XML namespace prefixes for grouping of the XML elements.  EPP 
explicitly requires the use of a namespace-aware XML parser, which enables the 
use of any XML namespace prefix.  There is no direct tie in the RFCs to the 
specific XML namespace prefix to use that is linked with the versioned XML 
namespace URIs.
[ML] Agreed. I only meant to make WG see things from a different angle 
beyond the considerations based on what RFCs currently permit 
presenting 
what could be the operational consequences of opting for Approach A.
>
>
> REST and JSON is schema-less, so are we attempting to bring in XML 
concepts into REST and JSON with the tight coupling of extension RDAP 
conformance values and the extension elements?
[ML] Clearly stated that we shouldn't. But what is most important,
> Approach C that is currently implemented in 
draft-ietf-regext-rdap-redacted includes the registration of a full versioned 
identifier for the RDAP Conformance, with "redacted_level_0_3" and the 
registration of the prefix "redacted" to ensure uniqueness with other 
extensions.  The "redacted" prefix looks a lot like "redacted_level_0_3", but 
that is not required.  The tie between the tie is based on the use of the same 
"Published specification" value in the RDAP Extension Registry.  I haven't 
heard of a concrete case to help the client out by having the RDAP Conformance 
value match the prefix with the optional support for versioning in both.  An 
extension should be additive, and the client would first key off the set of 
versioned RDAP conformance values, to determine what is supported based on what 
is defined in the specification.  We have no equivalent of an XML schema, and I 
don't believe we should attempt to model that in RDAP.
[ML] Me too.
> I view attempting to model XML schemas with predefined XML prefixes 
as brittle and unneeded.
[ML] Fully agreed. I'd also say "unpractical" as it would reduce the 
benefits from using 

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

[Jasdip Singh]

Hello James,

Yes, I mean Approach A as the current approach.

As was noted earlier, there is no version semantics for extension identifiers; 
they are opaque. One might as well call "ext0", "ext1", etc for an extension 
"abc", "def", etc.

Agreed we haven't yet had a single case of extension evolution :) but IMHO it 
is important to consider various change scenarios exhaustively and how they 
might introduce collisions and breakages for clients. I had earlier shared a 
side-by-side breakage analysis [1] of the current approach (approach A) and one 
of the proposed approaches (approach B). That informs when collisions and 
breakages are possible. We could add other change scenarios there to make it 
exhaustive. That way we would make a more informed decision if we were to ever 
ditch the current approach.

Thanks,
Jasdip

[1] 
https://docs.google.com/document/d/1iadJc1D2-z_9pSy0PNcl4mhEQglh7dIHhbmRgrCW6mc/edit?usp=sharing
 

On 5/27/22, 10:41 AM, "Gould, James"  wrote:

Jansdip, 

I'm not clear what you mean by the current approach, unless you mean 
Approach A.  The RFCs are consistently unclear when it comes to versioning.  
There are no new versions of extensions that has triggered the use case we're 
discussing.  Approach A doesn't really handle versioning unless the prefixes 
start embedding version numbers, which I consider unneeded and brittle.  The 
registrations have a mix of version numbers and non-version numbers, but I'm 
not aware of new versions needed until new versions of the RDAP Profile 
identifiers are needed.  In the case of the RDAP Profile identifiers, there is 
no brittle side effects with the RDAP elements since they are purely signaling 
identifiers.  

-- 

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 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 signaling beyond 
RDAP conformance) and thereby, guarantees near-zero breakage (breakage only 
possible if a client ignores the transition time)
- has a simple registration model for each opaque extension identifier

Jasdip

On 5/27/22, 10:25 AM, "regext on behalf of Gould, James" 
 
wrote:

Mario,

[ML] My only objection to Approach C is that every new version 
would 
result in registering a new extension identifier. I would opt 
for a less 
verbose solution, if any.

I'm not aware of the plan for new versions of the existing 
extensions, so I don't view it as a scalability issue.  While an extension is 
an Internet Draft, the pointed versions will not be registered until the draft 
becomes an RFC.  This is similar to what happens with the EPP extensions, where 
pre-RFC implementers can use the pointed version contained in the draft for 
signaling that will eventually become a full registered version (e.g., "0_N" 
becoming "1" or "1_N" becoming "2") in the registry.  When there are multiple 
versions of an extension, I believe it is important to capture those versions 
in the RDAP Extension Registry with a link to the associated specification.  
Mixing versioning with the prefixes I believe is unnecessary and brittle, so I 
don't support Approach A.  Approach B provides the flexibility to define the 
full RDAP Conformance version in the specification, so it supports versioning 
without the brittle side effects, but I view Approach C as being better since 
the versioning is more explicit in the registry.  If there is the risk of an 
overload of versions in the registry, then I would agree with the concern of 
Approach C, but I don't believe that risk exists. 

-- 

JG



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 
<http://secure-web.cisco.com/1l0afMm0DSkNmD4odBlYJ6gwW2XdoV_IRhP3O8-eNdjD3ILiqei8amp7uwkJtuwqyO2x1q-OD9PlHwyEN5A_xiAMPafVBDQGmBJ-OhojRk-tkX4nqOtBld0UOz84Khjgwv_sUfOVMfbZXtLig2khCZFumUFPvBHtZgQoNncwmi0ZRT-Y-Oi-oz05aAOQtqGP3FLSEuq1Th8BFOfHONhLSDYV4aN8B_IdIPPS4ap5qa-DYBZgxTMgF6gu0aE2zzCdD/http%3A%2F%2Fverisigninc.com%2F>

On 5/27/22, 10:10 AM, "Mario Loffredo"  
wrote:

Hi james,

my comment inline.

Il 27/05/2022 14:43, Gould, James ha scritto:
> Mario,
&g

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

[Jasdip Singh]

Hi Mario,

Few comments, and one suggestion.

Thanks,
Jasdip

On 5/30/22, 4:50 AM, "Mario Loffredo"  wrote:

Hi Jasdip,

the current approach appears unpractical to me as it results in managing 
all the changes in the same manner regardless their scope.

[JS] Consistency is the key point. Per the Breakage Analysis section in the 
RDAP Extensions Analysis doc I had shared earlier [1], the current approach -- 
tight coupling between extension identifier and rdapConformance value -- seems 
to afford us zero collisions and near-zero breakage for various change 
scenarios, and that should be a good thing, no?. To your point, yes, there are 
few scenarios (especially during transition for an extension vis-à-vis an 
existing path without that extension identifier in it) where sending data for 
both the old and new extension identifier in a response sounds inefficient but 
that's the trade-off with a consistent, collision- and breakage-free extension 
model. 

[1] 
https://docs.google.com/document/d/1iadJc1D2-z_9pSy0PNcl4mhEQglh7dIHhbmRgrCW6mc/edit?usp=sharing
 

A unified apporach is always advisable except in those cases where it 
results in adding complexity where it is unneeded. And I suspect  that 
this would be one of those cases.

Indeed, handling every change (at least reading strictly the RFCs) 
through a transition process would be a mess for server operators.

[JS] It doesn't look like we need any extraneous transition process beside 
listing the from and to extension identifiers in the rdapConformance array. 
Please see below one plausible way for jcard-to-jscontact transition using 
solely the current approach.

Let's imagine, for example, how a possible non-breaking change in 
JSContact representation impacting on the RDAP response could be managed 
while the possible transition from VCARD to JSContact was still in place.

Server operators may have to deal with a transition within another 
transition ?!?!

[JS] One plausible way for jcard-to-jscontact transition using solely the 
current approach (tight coupling):

Phase 1: Only jcard
---

p = entity/

{
  “rdapConformance” : [
“rdap_level_0”
  ],
  {
…,
"vcardArray" : [
  …
]
  }
}

Phase 2: jscard_0 extension (available along with jcard)
---

p = entity/

{
  “rdapConformance” : [
“rdap_level_0”,
“jscard_0”
  ],
  {
…,
"vcardArray" : [
  …
 ],
“jscard_0” : {
  …
}
  }
}

Phase 3: no_jcard extension (jcard data no more in response)
---

p = entity/

{
  “rdapConformance” : [
“rdap_level_0”,
“jscard_0”,
“no_jcard”
  ],
  {
…,
“jscard_0” : {
  …
}
  }
}

Phase 4: jscard_1 extension (has a new field beside the jscard_0 data)
-

p = entity/

{
  “rdapConformance” : [
“rdap_level_0”,
“jscard_0”,
“no_jcard”,
“jscard_1”
  ],
  {
…,
“jscard_0” : {
  …
},
“jscard_1” : {
  …,
  “new_field” : …
}
  }
}

Phase 5: Transition from jscard_0 to jscard_1 after a sufficient grace period 
for clients
---

p = entity/

{
  “rdapConformance” : [
“rdap_level_0”,
“no_jcard”,
“jscard_1”
  ],
  {
…,
“jscard_1” : {
  …
}
  }
}

Non-breaking changes can be more easily managed and signaled by server 
operators by adding a minor version in rdapConformance array and an 
optional link to the related documentation in the response. That's it.

[JS] One suggestion. To help settle and/or move forward the discussion 
vis-a-vis if we should stick with the current approach (tight coupling), or 
evolve using the proposed approach (lack of tight coupling), it would be great 
if we could review and discuss the Breakage Analysis section 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 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 signaling beyond 
RDAP conformance) and thereby, guarantees near-zero breakage (breakage only 
possible if a client ignores the transition time)
> - has a simple registration model for each opaque extension identifier
>
   

Re: [regext] Feedback about breakage analysis

[Jasdip Singh]

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.

I mean, some of the scenarios presented merge breaking and non-breaking 
changes.

I would classify the scenarios reflecting the basic breaking and 
non-breaking changes as in the following.

Possible breaking changes that can occur in the RDAP context include:

 Removing a response field
 Modifying a path URI
 Modifying a field name or type
 Modifying a required query parameter

While non-breaking changes include:

 Adding a path
 Adding a response field
 Adding an optional query parameter

Any combination of breaking changes should be treated as one 
non-breaking change while any combination including at least one 
breaking change should be treated as one breaking change (e.g., 
"Replacing jCard with JSCard" is equal to "Removing jCard " + "Adding 
JSCard").

That being said, anyone can realize that Approach A (at least as is for 
now) transforms the non-breaking changes in breaking ones. For example, 
defining a new version of a request extension by adding an optional 
query parameter to a given path implies that the path URI gets modified 
(@Jasdip, this scenario corresponds to the second one presented in your 
breakage analysis but limited only to the assumption "Query parameter q1 
added"). Likewise, adding a new member to a response extension would 
result in modifying the name of the response extension as well (@Jsdip, 
this seems to me not included in your breakage analysis).

For that reasons, I wouldn't opt for Apporach A.


Cheers,

Mario


-- 
Dr. Mario Loffredoto a
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 the thread below, I'll summarize my thoughts below that goes along 
with my response with Approach C to Jasdip:



  1.  It looks like there is consensus that the existing language in the RDAP 
RFCs is unclear and there is a mix of cases that exist in the RDAP Extension 
Registry.  Creating something like the Guidelines for Extending the Extensible 
Provisioning Protocol (EPP), in RFC 3735, is needed for RDAP.



[JS] IMO, we could first identify errata for the current set of STD 95 RFCs to 
help clarify the current approach and if that doesn’t suffice, create a 
separate doc. Per the discussion, we at the least need clarifications (read: 
more normative language) vis-a-vis:

a) The registered extension identifier is an opaque identifier with no 
explicit versioning semantics.

b) There is a tight coupling between the extension identifier registered 
with IANA and the rdapConformance value.

c) New data members (including new object classes) and path segments 
(including query parameters) for a newly registered extension identifier are 
prefixed with that identifier in order to prevent collisions.



RIRs are working on evolving RDAP search in order to cover all current Whois 
use cases, and that helped identify the need for one more clarification:

d) How to extend some aspect of the base spec that overarches all 
extensions? Say, the need to search entities by the email property 
(“entities?email=”).



  1.  It looks like there is consensus that the RDAP Extension Registry ensures 
uniqueness of the identifiers and prefixes used by the extensions for the 
rdapConformance, URI path segments, and JSON response members.  I believe the 
values of the “objectClassName” needs to be included as well to support the 
definition of new RDAP objects.



[JS] Yes.



  1.  It doesn’t look like there was an explicit attempt to define a namespace 
feature in RDAP, like what exists with XML namespace URIs and XML namespace 
prefixes.  The only version signaling is handled by the rdapConformance member 
of the JSON response.  Based on the practice that we followed with EPP 
extensions, we’ve been using pointed version numbers (“0.1”, “0.2”, “0.N”) for 
the namespace URIs up until the draft passed WGLC, resulting in bumping the 
version to “1.0”.  Supporting pointed version numbers has proven to be useful 
during the development of the EPP extensions, but since the ABNF in RFC 7480 
doesn’t support the use of a ‘.’, the ‘_’ needs to be used instead for pointed 
version numbers.



[JS] As we know, JSON’s grammar is simpler than XML’s -- only objects, arrays, 
strings, numbers, and 3 literals (true, false, and null). To guarantee 
collision-free naming, the current approach registers with IANA an opaque 
extension identifier along with a spec. Then uses that identifier as 
rdapConformance to signal server capability, and as a prefix in new JSON data 
member names and path segments for that extension. If the extension evolves, 
above process is repeated with a new identifier. And, this rather simple 
process seems to achieve the effect equivalent to XML namespace URI and prefix 
for name collision prevention.



  1.  For draft-ietf-regext-rdap-redacted, I view the registration of the 
extension identifier “redacted_level_0_3” (target of “redacted_level_1” after 
WGLC) that is returned in RDAP Conformance as meeting the signaling needs.  The 
registration of the prefix “redacted” ensures uniqueness of the member included 
in the JSON response.  This could be addressed with the single RDAP Extension 
Registry registration of “redacted”, where the specification formally defines 
the full version included in the rdapConformance member, but I feel inclusion 
of the separate full identifier registration as being more explicit for 
signaling.  What happens when there is version 2 of the redacted extension, 
should the RDAP Extension Registry only reference the latest specification for 
the “redacted” prefix used in the “rdapConformance”, or would it be better to 
include two versioned identifiers (“redacted_level_1” and “redacted_level_2”) 
that link to the associated specification in the RDAP Extension Registry?  I 
believe having both versions in the RDAP Extension Registry provides benefit to 
the client.  I recommend updating the registered prefixes for the extension 
with the latest specification.



Thanks,



--



JG







James Gould

Fellow Engineer

jgo...@verisign.com 




703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 5/19/22, 8:44 PM, "Tom Harrison"  wrote:



Hi James,



On Thu, May 19, 2022 at 06:36:59PM +, Gould, James wrote:

> On 

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

[Jasdip Singh]

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 identifier and rdapConformance

Extension identifier = []   [ ] means optional
  Registered in the IANA RDAP Extensions registry
  A new spec provided for each new version of the extension
rdapConformance = []

Extension identifier used in new data members, and in new path segments 
(including any new query or matrix parameters)

Approach B: Lack of tight coupling between extension identifier and 
rdapConformance

Extension identifier = 
  Registered in the IANA RDAP Extensions registry
rdapConformance = [] [ ] means optional
  Registered in the IANA RDAP Extensions registry (or perhaps another registry 
for rdapConformance)
  A new spec provided for each new version of rdapConformance

Extension identifier used in new data members, and in new path segments 
(including any new query or matrix parameters)

Comparing the two approaches:

Aspect

Approach A - tight coupling

Approach B - lack of tight coupling

Providing a new spec to IANA for a new version

Registry stays as-is

Registry needs to evolve for:

  *   Versioned rdapConformance
  *   Tying spec to versioned rdapConformance

Risk of breaking changes for RDAP clients

Yes, if the server now only supports the new version and a client hasn’t evolved

Data member names and path segments change with each new version but not an 
issue if clients have re-programmed a priori

Clients would knowingly call the versioned path segments — no guesswork

Even if a path segment is not affected by a new version but only a newly 
versioned data sub-object is added in the response, that could break clients

Yes, when a field is removed, or a required field is added, in a new version

When a call is made using a non-versioned path segment, the newly versioned 
rdapConformance would be checked after the fact and could break the client for 
above field additions and subtractions if not re-programmed a priori

Clients would call non-versioned path segments but could be broken by the new 
responses

Cost of reprogramming clients for the next version of an extension

There is cost but not as high as it seems — replacing version in multiple 
places and accounting for field and query parameter additions and subtractions

There is cost but could be higher than it seems - client finds after the fact 
about a field removal or a required field addition

Cost of reprogramming servers for the next version of an extension

There is cost but not as high as it seems — replacing version in multiple 
places and accounting for field and query parameter additions and subtractions

There is cost for a field removal or a required field addition

Server-side signaling of the next version of an extension

Add the new version of the rdapConformance in the help response and related 
responses

Make URIs for new versions of path segments available

Add the new version of the rdapConformance in the help response and related 
responses

No change in URIs for the new version of the rdapConformance

Potential confusion for clients

Zero since the new version is explicitly marked in data members and URIs

Not zero since the new version is not marked in data members and URIs

Aesthetics (should not matter to a machine but could to a human)

Less

More


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

Hi.

Honed the analysis a bit more.

Jasdip

---

Approach A: Tight coupling between extension identifier and rdapConformance

Extension identifier = []   [ ] means optional
  Registered in the IANA RDAP Extensions registry
  A new spec provided for each new version of the extension
rdapConformance = []

Extension identifier used in new data members, and in new path segments 
(including any new query or matrix parameters)

Approach B: Lack of tight coupling between extension identifier and 
rdapConformance

Extension identifier = 
  Registered in the IANA RDAP Extensions registry
rdapConformance = [] [ ] means optional
  Registered in the IANA RDAP Extensions registry (or perhaps another registry 
for rdapConformance)
  A new spec provided for each new version of rdapConformance

Extension identifier used in new data members, and in new path segments 
(including any new query or matrix parameters)

Comparing the two approaches:

Aspect

Approach A - tight coupling

Approach B - lack of tight coupling

Providing a new spec to IANA for a new version

Registry stays as-is

Registry needs to evolve for:

  *   Versioned rdapConformance
  *   Tying spec to versioned rdapConformance

Risk of breaking changes for RDAP clients

Yes, if the server now only supports the new version and a client hasn’t 
evolved yet

Data member names and path segments change with each new version but not an 
issue if clients have re-programmed a priori

Clients would knowingly call the versioned path segments — no guesswork

If a path segment is not affected by a new version and only a newly versioned 
data sub-object is added in the response, that could break clients

Yes, when a field is removed, or a required field is added, for a new version

When a call is made using a non-versioned path segment, the newly versioned 
rdapConformance would be checked after the fact and that could break the client 
for above field additions and subtractions if not re-programmed a priori

Clients would call non-versioned path segments but could be broken by the new 
responses

Cost of reprogramming clients for the next version of an extension

There is cost but not as high as it seems — replacing version in multiple 
places and accounting for field and query parameter additions and subtractions

Longer grace period for clients to reprogram if the server supports multiple 
versions during transition

There is cost — accounting for a field removal or a required field addition

Reprogramming could become exigent for clients if the server switches to the 
new version without supporting the previous version

Cost of reprogramming servers for the next version of an extension

There is a higher cost — if multiple versions are simultaneously supported 
during a transition period, replicating code from the previous version and 
replacing version in multiple places and accounting for field and query 
parameter additions and subtractions

Eventually retiring code for the previous version

There is a lower cost — if only the latest version is supported, accounting for 
a field removal or a required field addition vis-a-vis the previous version

Server-side signaling of the next version of an extension

Add the new version of the rdapConformance in the help response and related 
responses

Make URLs for new versions of path segments available

Add the new version of the rdapConformance in the help response and related 
responses

No change in URLs for the new version of the rdapConformance

Potential confusion for clients

Zero since the new version is explicitly marked in data members and URLs

Not zero since the new version is not marked in data members and URLs, and 
would only be discovered through the rdapConformance value in a response

Aesthetics (does not matter to a machine but could for human friendliness)

Less

More



From: regext  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 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 identifier and rdapConformance

Extension identifier = []   [ ] means optional
  Registered in the IANA RDAP Extensions registry
  A new spec provided for each new version of the extension
rdapConformance = []

Extension identifier used in new data members, and in new path segments 
(including any new query or matrix parameters)

Approach B: Lack of tight coupling between extension identifier and 
rdapConformance

Extension identifier = 
  Registered in the IANA RDAP Extensions registry
rdapConformance = [] [ ] means optional
  Registered in the

Re: [regext] RDAP Extensions Approach Analysis v2

[Jasdip Singh]

Hello Andy,

On 7/1/22, 8:29 AM, "Andrew Newton"  wrote:

This is very impressive work, Jasdip. I've been trying to follow this
conversation, and this doc is very helpful.

Thanks. :) Glad it is helpful.

I note that in the analysis there are references to "put the new
extension value in the help" (or something). What does this mean?

IIUC what you are referring to is in aspect #5 (Server-side signaling of the 
next iteration of an extension) of the analysis [1]: "Add the new value of the 
rdapConformance in the help response and related responses". What I simply 
meant here is how an extension identifier registered with IANA shows up in RDAP 
responses -- in the rdapConformance string array in the "help" and other (e.g. 
"domain/") responses -- as a server-capability signal.

First, /help is a query unto itself. Second, putting additional
information in a "notice" without proper guidance of what to actually
do may be kicking the ambiguity-can down the road. Is it part of the
title for the notice? Is there a textual description, and if so how
does that work with I18N issues? Does it go into a relative link
structure?

The aspect analysis section is interesting as it helps us to evaluate
the trade-offs. In my opinion, interoperability is paramount otherwise
we'll just be repeating this conversation again in a year. I view
on-the-wire efficiency as the least-compelling objective for this
protocol. And cost to clients should be given higher consideration
than cost to servers given there are many more clients than servers.

I believe this puts me in camp A even if it means we sacrifice some of
the on-the-wire aesthetic.

This is where 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 current approach (A) and 
the 2 newly proposed approaches (B and C) for RDAP extensions [1]. Hopefully, 
the considered change scenarios are now granular enough ( @Mario :) ).
>
> My high-level observations:
>
> Approach C is much better than Approach B.
> That said, would still go with Approach A since it consistently prevents 
naming collisions for all change scenarios and affords sufficient transition 
time for clients to “upgrade” to the next iteration of an extension. The latter 
-- graceful upgrade -- could be quite important to most, if not all, customers 
of the RDAP service at an RIR or a DNR, to the point of being an operational 
requirement. The former – consistently preventing naming collisions – helps 
keep the model simple, albeit at the expense of occasionally sending more data 
in responses.
> Approach C is closer to Approach A than to Approach B but requires a 
careful scenario-by-scenario analysis to determine the need for a new 
prefix(es), and that could be problematic at times. I think it’d come down to 
(sunk) cost versus benefit when choosing between sticking with Approach A or 
moving to Approach C.
>
> Please feel free to rectify this analysis. :) Hopefully, the discussion 
could converge for the considered change scenarios.
>
> Thanks,
> Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 proposed one (approaches B and C).

Jasdip

On 6/15/22, 2:23 PM, "Hollenbeck, Scott"  wrote:

Jim, I didn't say that "lunarNIC_level_0" isn't supported. What I *am* 
saying is that both authors of the document agree that the existing text 
contains an editorial error that should be fixed such that the two sections of 
9083 are consistent. We could just as easily change all instances of "lunarNIC" 
to "lunarNIC_level_0". That is the simplest path forward that doesn't require 
changing the original intention of the text. With the editorial error corrected 
we can decide if something else needs to be done to clarify how extensions are 
identified.

Don't forget that the WG did, in fact, reach consensus on the existing text 
when we went through the process to publish it as a Standard. "come to 
consensus on the desired extension registry approach or approaches" implies 
more significant changes to the existing text that can't be addressed with 
errata.  If that's what the WG wants to do, fine, but we'd better make our mind 
up about that sooner rather than later.

Scott

> -Original Message-
> From: Gould, James 
> Sent: Wednesday, June 15, 2022 1:59 PM
> To: Hollenbeck, Scott ; jasd...@arin.net;
> regext@ietf.org
> Subject: [EXTERNAL] Re: Re: [regext] OK, What Next? (was RDAP Extensions
> Approach Analysis v2)
>
> Caution: This email originated from outside the organization. Do not 
click links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> Scott,
>
> I believe the first step is to come to consensus on the desired extension
> registry approach or approaches.  I personally like the use of
> "lunarNIC_level_0" in the rdapConformance to ensure that versioning of the
> specification is fully supported.  Approach B could be used to allow for 
the
> registered prefix "lunarNIC" to support the versioned rdapConformance
> value of "lunarNIC_level_0".  Approach C decouples the prefixes from the
> identifier, so both the prefixes and the versioned identifier would be
> registered.  Updating "lunarNIC_level_0" to "lunarNIC" in RFC 9083 doesn't
> address the versioning issue.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com  B4BA42740803/jgo...@verisign.com>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com  d5tRNZLs8IMVwvIdRLWAsc8s3x5kUlfPvUAfGG1R9VSZZNwwpUgsNKglJCpiDP
> eFwBSZBKI4YSrEii3FEBUQowZ7sug1iltQCyWun0NzZ3J2Pc5cpHefSd6Rsyxb_od
> LmFg4jwJvB3kGsuwS_jHfZ3B2gS6K-OggLd3TEZVliRULU1rLr9-
> 6T9WbPHS2B3HnX6HNavcu67j9491BURhFuYYYd8bvMlMFUrQ5GURBZwxvue
> _-c/http%3A%2F%2Fverisigninc.com%2F>
>
> On 6/15/22, 1:27 PM, "regext on behalf of Hollenbeck, Scott"  boun...@ietf.org on behalf of shollenbeck=40verisign@dmarc.ietf.org>
> wrote:
>
> Thanks for doing all this work, Jasdip. Now we have to decide what to 
do
> with
> all of this information.
>
> As a first step, I think we need to submit errata to address issues 
with the
> existing RFC(s). RFC 9083 uses both "lunarNIC" and 
"lunarNIC_level_0".  At
> a
> minimum, Andy and I agree that "lunarNIC_level_0" should be replaced
> with
> "lunarNIC".
>
> Rationale: Section 2.1 of RFC 9083 describes "lunarNIC" as an example 
of an
> identifying prefix and includes examples of this value being used as 
an
> extension prefix. Section 4.1 says "For example, if the fictional 
Registry of
> the Moon wants to signify that their JSON responses are conformant 
with
> their
> registered extensions, the string used might be "lunarNIC_level_0". We
> believe
> that 4.1 and 2.1 are inconsistent and that they can be made 
consistent by
> changing "lunarNIC_level_0" with "lunarNIC" in 4.1.
>
> Additional errata may be needed. If so, where, and what else needs to 
be
> done?
>
> Scott
> ___
> regext mailing list
> regext@ietf.org
> https://secure-web.cisco.com/1YfJ-
> 5LkVa3_5e2919NGv3HEyQy1AoEJ85v6gRz0tFZA0RXar6_Be-
> zQoFAL0wMeZscZWEZJviAtI80kqxbdAVGXbuyEWNIIHNvaf4rRa-
> WfawQjzoVSkJsMFmkxcrbEHSLKsRFsj63qrJ8fTXUta2zy5yiiuXzsiQAmJFxKCiJu
> dRDLfaCI_02bRNSDyvOwEWBccERhzp9KGqZgjvPpQrbcCOauHRjWfg-
> ipxnTEVxEhOAE-
> djs02lBSoMdQN6nJ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%
> 2Fregext
>

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

[Jasdip Singh]

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 RDAP Extension Registry ensures 
uniqueness of the identifiers and prefixes used by the extensions for the 
rdapConformance, URI path segments, and JSON response members.  I believe the 
values of the “objectClassName” needs to be included as well to support the 
definition of new RDAP objects.
[ML] Agreed. I'm a bit doubtful about including query parameters as proposed by 
Jasdip since it would break RFC8977 and RFC8982. This is another reason why I 
don't support Approach A.

[JS] IIRC, so far we have seen this in the “roidc1” extension only ( 
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-openid-13 ). But, 
a good point about how far we go with prefixing for name collision prevention. 
Perhaps, this should mimic how we only use the prefix in a new object class 
name and not for its sub-data, and having the prefix in the path segment before 
the query parameters might suffice. Clearly, this all needs to be spelled out. 
:)



…



Jasdip
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 reverse search, I thought it best to start another topic.

Section 6 of RFC 7480 introduces the concept of "an IANA registry for 
prefixes 
used in JSON [RFC7159] data serialization and URI path segments (see 
Section 
8)". "lunarNic" is given as an example in Section 8. I cannot, though, find 
any mention of a MUST when it comes to using these prefixes for data 
structures or URI path segments, though Section 8.1 says this:

"The extension identifier is used as a prefix in JSON names and as a prefix 
of 
path segments in RDAP URLs."

RFC 9083 is more definitive. From Section 4.1:

"When custom JSON values are inserted into responses, conformance to those 
custom specifications MUST use a string prefixed with the appropriate 
identifier from the IANA RDAP Extensions registry specified in [RFC7480].  
For 
example, if the fictional Registry of the Moon wants to signify that their 
JSON responses are conformant with their registered extensions, the string 
used might be "lunarNIC_level_0"."

Note the use of MUST here. Section 5 of RFC 9082 contains similar text:

"Custom path segments can be created for objects not specified here using 
the 
process described in Section 6 of "HTTP Usage in the Registration Data 
Access 
Protocol (RDAP)" [RFC7480].

Custom path segments can be created by prefixing the segment with a unique 
identifier followed by an underscore character (0x5F). For example, a 
custom 
entity path segment could be created by prefixing "entity" with "custom_", 
producing "custom_entity"."

After re-reading all of this, my take is that extensions MUST tag new data 
structures and path segments with the prefix that's registered with IANA. 
That 
means I'm going to have to change the data structures and path segments in 
draft-ietf-regext-rdap-openid (I'm probably going to change the prefixes to 
something shorter to make them a bit less clunky). Other extension 
authors/editors should review their documents and provide their own 
assessments.

[JS] Want to test-drive the phrase "new data structures and path segments " in 
the "extensions MUST tag new data structures and path segments with the prefix 
that's registered with IANA" suggestion. :)

A new data structure could be an entirely new object class (e.g. for a session 
in RDAP OpenID), or a change in the member set for an existing object class 
(say, for a domain). Is it correct to assume that for the former, the extension 
prefix would be applied to the overall object name (e.g. "< RDAP OpenID 
extension>_session") in the response whereas for the latter, only the new 
members would be prefixed with the extension identifier (including version)?

As for using a new extension in a related new path segment (e.g. for reverse 
search), we seem ok with having path segments like ".../_0/...", 
".../_1/...", and so on for each subsequent new version of that 
extension and not concerned about inadvertently introducing "brittleness" in 
URLs for RDAP clients. Right?

Since this subject has engendered discussion/confusion over time, looks like a 
good idea to detail it further in a new doc.


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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’t match the proposed to-be-registered 
extension “redacted”.

Further, shouldn’t the new fields and paths be prefixed with that exact same 
registered extension identifier? If not, then what happens to the “redacted” 
member name when the rdapConformance jumps to the next version, say, from 
redacted_level_1_0 to redacted_level_2_0, with a new child member (beside 
“name”, “path”, “pathLang”, “method”, and “reason”) ?

Lastly, discounting strict “semantic versioning” and understanding how a minor 
version might help during the development of an extension, won’t simply 
registering a new extension with the major version help keep things simple for 
our purposes? Also, the “_level” sub-string in an extension identifier seems 
extraneous, no?

Trying to reconcile various inputs thus far. :)

Thanks,
Jasdip

[1] From Tom’s earlier note:

- 1.
- rdapConformance is an exact match for the extension identifier
- 1.1
- New fields are prefixed with the extension identifier
- New paths are prefixed with the extension identifier
- arin_originas0
- 1.2
- New fields are prefixed with the extension identifier
- No new paths are defined
- cidr0
- paging
- sorting
- subsetting
- 1.3
- rdapConformance is an exact match for the extension identifier
- No new fields are defined
- No new paths are defined
- icann_rdap_response_profile_0
- icann_rdap_technical_implementation_guide_0
- nro_rdap_profile_0
- nro_rdap_profile_asn_flat_0
- nro_rdap_profile_asn_hierarchical_0
- rdap_objectTag
- redirect_with_content

From: regext  on behalf of "Gould, James" 

Date: Thursday, May 5, 2022 at 11:44 AM
To: "shollenbeck=40verisign@dmarc.ietf.org" 
, "regext@ietf.org" 
Subject: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

Scott and I discussed this offline, and below is a proposal for the RDAP 
Extension Registry registrations that meets the language in the RFCs and 
ensures that there are no conflicts (RFC 7480 “ensure uniqueness of extension 
identifiers”) with the URI paths or JSON members for new RDAP extensions.


  1.  Register any URI path or JSON member prefixes added by the extension.  
The value may have a null suffix, so the exact value can be registered.
 *   Supporting language in the RFCs

  i.  RFC 7480

1.  Prefixes and identifiers SHOULD only consist of the alphabetic US-ASCII 
characters A through Z in both uppercase and lowercase, the numerical digits 0 
through 9, and the underscore character, and they SHOULD NOT begin with an 
underscore character, numerical digit, or the characters “xml”.  The following 
describes the production of JSON names in ABNF [RFC5234]:

a.   name = ALPHA *( ALPHA / DIGIT / “_” )


  i.  I would more 
clearly define a custom element (custom URI path or custom JSON member) using 
the ABNF, which does meet the existing RFC 7480 ABNF:

1.  element = prefix [ suffix ]

2.  prefix = name

3.  suffix = “_” name

ii.  RFC 9083

1.  When custom JSON values are inserted into responses, conformance to those 
custom specifications MUST use a string prefixed with the appropriate 
identifier from the IANA RDAP Extensions registry specified in [RFC7480]

a.   This normative language is contained in the RDAP Conformance section 
of RFC 9083, but it does cover the JSON members use of the format defined above 
in RFC7480.

 *   Plan for draft-ietf-regext-rdap-redacted

  i.  
Registration of “redacted” 
(https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted#section-6.1)
 and the definition of the “redacted” member 
(https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted#section-4.2)

  1.  Register a versioned identifier for use as an RDAP conformance value.
 *   Supporting language in the RFCs

  i.  RFC 9083

1.  When custom JSON values are inserted into responses, conformance to those 
custom specifications MUST use a string prefixed with the appropriate 
identifier from the IANA RDAP Extensions registry specified in [RFC7480]

a.   This normative language is contained in the RDAP Conformation section 
of RFC 9083.  The 

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

[Jasdip Singh]

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 Jasdip Singh 

Date: Thursday, May 5, 2022 at 1:53 PM
To: "regext@ietf.org" 
Subject: [EXTERNAL] 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’t match the proposed to-be-registered 
extension “redacted”.

JG – Based on my read of the RFC language, I don’t believe the rdapConformance 
string needs to exactly match the list of URI path segments and JSON members 
associated with the extension.

[JS] Though this is not explicitly written anywhere in the standard but the 
“majority” precedence turns out to be an exact match between a registered 
extension identifier and the related rdapConformance string (per Tom’s earlier 
note, all in section “-1” there follow this tight coupling whereas those in 
section “-2” (fred, artRecord, platformNS, and regType for centralnic) don’t. 
Further, section 8.1. RDAP Extensions Registry in RFC 7480 says: “The extension 
identifier is used as a prefix in JSON names and as a prefix of path segments 
in RDAP URLs.” That’s the most definitive guidance I could find. :)

  As Tom’s earlier note highlights there is really a mix of prefixes and 
identifiers currently registered in the RDAP Extension Registry.

[JS] That’s fair but fortunately it seems to me that the ones where the 
rdapConformance string does not match the extension identifier (section “-2” 
(fred, artRecord, platformNS, and regType) in Tom’s note are for one only 
entity (centralnic). The rest (section “-1” in that note) have an exact match 
between the extension identifier and the rdapConformance string.

  Mixing the signaling in the rdapConformance member, which I believe can and 
should include versioning, with the naming of the URI path segments and JSON 
members is unnecessary coupling.

[JS] Yah, this I believe is at the heart of our discussion. So far, the 
“majority” precedence seems to point to tighter coupling between the extension 
identifier and the rdapConformance string.

  For example, what if there is an extension that contains multiple URI path 
elements and JSON members.

[JS] Turns out we have an exhibit for this precise use case: 
https://bitbucket.org/arin-specs/arin-rdap-originas/src/master/arin-rdap-originas.txt
 . “arin_originas0” though only is for one entity’s purposes (ARIN) but seems 
like a good example to emulate IMO.

  We need to ensure that there is signaling of supporting the extension in the 
rdapConformance member and we need to ensure that there is no conflict with the 
URI path segments and the JSON members defined in the extension with other 
extensions.  This can be handled by having registrations for the prefix(es) and 
for the identifier used in the RDAP conformance .

[JS] Totally agree with avoiding conflicts but AFAIK only extension identifiers 
are registered with IANA and rdapConformance strings “re-use” that registered 
string, exactly in case of tight coupling.

Further, shouldn’t the new fields and paths be prefixed with that exact same 
registered extension identifier? If not, then what happens to the “redacted” 
member name when the rdapConformance jumps to the next version, say, from 
redacted_level_1_0 to redacted_level_2_0, with a new child member (beside 
“name”, “path”, “pathLang”, “method”, and “reason”) ?

JG - The rdapConformance value would reflect “redacted_level_2_0” that would 
then signal support for the new child member.  The “redacted” member name 
itself does not need to change since the version change is signaled with the 
RDAP Conformance value.

Lastly, discounting strict “semantic versioning” and understanding how a minor 
version might help during the development of an extension, won’t simply 
registering a new extension with the major version help keep things simple for 
our purposes? Also, the “_level” sub-string in an extension identifier seems 
extraneous, no?

JG – Are you proposing the use of the RDAP Conformance value of 
“redacted_level_1” instead of “redacted_level_1_0”?

[JS] Yah, no minor version in extension identifier and thereby, in 
rdapConformance string.

  Yes, I agree that the “_level” substring is somewhat extraneous, but it is 
consistent with the scheme used for RDAP with “rdap_level_0”.

[JS] True but emulating “rdap_level_0” is somewhat tricky since AFAIK it is not 
considered an extension, per the IANA RDAP Extensions registry ( 
https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml )

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

[Jasdip Singh]

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: “there is really a mix of prefixes and identifiers currently registered in 
the RDAP Extension Registry”.

That’s true, and unfortunately it could be an indication of an error on the 
part of the reviewers (me and Andy) that IANA asks to review the registration 
requests. If we’ve made mistakes, we shouldn’t repeat them.

Scott

From: regext  On Behalf Of Gould, James
Sent: Thursday, May 5, 2022 2:47 PM
To: jasd...@arin.net; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Extension Prefixes, JSON Values, and URI Path 
Segments


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Jasdip,

Thank you for your concise set of comments and questions.  My feedback is 
embedded below.

--

JG

[cid:image001.png@01D86090.273E48A0]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://secure-web.cisco.com/1itEaLJzQKWH2dbrCRJp-txXjt00zhTcMZ24RNcT1Tt7v69hcp_ioTvKnyxwXk0znuO_p6rd3oumCLVzeRmDtL8ZywEFUBSxYSVvEtoBk6NSHsSZY_UByjkurDTmLE7rXx4-Z9m4n096B_BnYn0pYBM5J3vu4YYw6OcV795aHd5X0IaFXIb-Rvq5imL782zEJ9xXivQV9oAJueYQcRh7pIdyP1anPm5YR7IoGiIRcDtfAqCU6rqPIHJl_NIV0KfS4/http%3A%2F%2Fverisigninc.com%2F>

From: regext mailto:regext-boun...@ietf.org>> on 
behalf of Jasdip Singh mailto:jasd...@arin.net>>
Date: Thursday, May 5, 2022 at 1:53 PM
To: "regext@ietf.org<mailto:regext@ietf.org>" 
mailto:regext@ietf.org>>
Subject: [EXTERNAL] 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’t match the proposed to-be-registered 
extension “redacted”.

JG – Based on my read of the RFC language, I don’t believe the rdapConformance 
string needs to exactly match the list of URI path segments and JSON members 
associated with the extension.  As Tom’s earlier note highlights there is 
really a mix of prefixes and identifiers currently registered in the RDAP 
Extension Registry.  Mixing the signaling in the rdapConformance member, which 
I believe can and should include versioning, with the naming of the URI path 
segments and JSON members is unnecessary coupling.  For example, what if there 
is an extension that contains multiple URI path elements and JSON members.  We 
need to ensure that there is signaling of supporting the extension in the 
rdapConformance member and we need to ensure that there is no conflict with the 
URI path segments and the JSON members defined in the extension with other 
extensions.  This can be handled by having registrations for the prefix(es) and 
for the identifier used in the RDAP conformance .

Further, shouldn’t the new fields and paths be prefixed with that exact same 
registered extension identifier? If not, then what happens to the “redacted” 
member name when the rdapConformance jumps to the next version, say, from 
redacted_level_1_0 to redacted_level_2_0, with a new child member (beside 
“name”, “path”, “pathLang”, “method”, and “reason”) ?

JG - The rdapConformance value would reflect “redacted_level_2_0” that would 
then signal support for the new child member.  The “redacted” member name 
itself does not need to change since the version change is signaled with the 
RDAP Conformance value.

Lastly, discounting strict “semantic versioning” and understanding how a minor 
version might help during the development of an extension, won’t simply 
registering a new extension with the major version help keep things simple for 
our purposes? Also, the “_level” sub-string in an extension identifier seems 
extraneous, no?

JG – Are you proposing the use of the RDAP Conformance value of 
“redacted_level_1” instead of “redacted_level_1_0”?  Yes, I agree that the 
“_level” substring is somewhat extraneous, but it is consistent with the scheme 
used for RDAP with “rdap_level_0”.

Trying to reconcile various inputs thus far. :)

Thanks,
Jasdip

[1] From Tom’s earlier note:

- 1.
- rdapConformance is an exact match for the extension identifier
- 1.1
- New fields are prefixed with the extension identifier
- New paths are prefixed with the extension identifier
- arin_originas0
- 1.2
- New fields are prefixed with the extension identifier
- No new paths are defined
- cidr0
- paging
- sorting

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

[Jasdip Singh]

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 about 6 months ago that resulted in quite some 
extended discussion, and as a result it did not pass WGLC.

Mario has produced a revised document but there has not been any discussion 
on the list about these changes.

The Chairs would like for those who had concerns the last time to indicate 
on the list that their concerns have been addressed before we start another 
WGLC on this document.

Please, if you had questions last time, indicate if your questions have 
been answered in the latest version of the document.

The Chairs must see this before we can start a WGLC.

Thanks,

Antoin and Jim

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

This WG last call will end at close of business, Monday, 26 September 2022.

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.
This document had a WGLC earlier with no conclusion about consensus, so 
please resubmit your views as we will need them.

The document shepherd for this document is Tom Harrison.

Regards,

Jim and Antoin
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 server operator with the consent of the user in 
order to help the server operator make access control decisions" is the 
intent.

[JS] Got it. Perhaps we can further clarify as above.

> 4.1.1: "An OPTIONAL "userClaims" object that contains the set of claims
> associated with the End-User's identity as used/requested by the RDAP 
server
> to make access control decisions." ... For consistency with other field
> definitions, should we mention that it is an array of strings?

[SAH] It's not necessarily an array of strings (see the example where the 
set 
of claims includes a URL, for example) , so I don't think so. I'd prefer to 
leave that description as-is, noting that "The set of possible values is 
determined by OP policy".

[JS] Aha, you are right!

> 4.7: "RDAP servers MUST reject queries that include identification 
> information
> that is not associated with a supported OP by returning an HTTP 501 (Not
> Implemented) response." ... Should this not be a 401 (Unauthorized) 
instead? 
> ...
> I know Andy suggested a 400 (Bad Request). :)

[SAH] I prefer 401. "Unauthorized" would imply that an attempt was made to 
authorize the user, but that can't be done because the OP isn't supported.

[JS] I think you meant to say 400? :) Yes, that rationale makes sense.

> 4.8: "If a client sends any request that includes an unknown HTTP cookie, 
> the
> server MUST return an HTTP 409 (Conflict) error." ... Should this not be 
a 
> 401
> (Unauthorized) instead?

[SAH] I think that 400 that Andy suggested is the better response for the 
same 
reason noted above.

[JS] OK.

Thanks,
Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 identification 
information, and that information can be shared with the consent of the user." 
... Not clear who that information could be shared with.

3.1.2: "The RDAP server sends the RDAP client and Authentication Request" 
…Minor: Should "and" be "an"?

3.1.3.2: "as described in Section 3.1.2.2 of the OpenID Connect Core protocol 
[OIDCC]" ... Minor: Just in case, noticed that such section links to the Open 
ID documentation either point to within this doc (read the "htmlized" version), 
or go nowhere.

4.1.1: "An OPTIONAL "userClaims" object that contains the set of claims 
associated with the End-User's identity as used/requested by the RDAP server to 
make access control decisions." ... For consistency with other field 
definitions, should we mention that it is an array of strings?

4.1.3: ""iss": (MANDATORY) a string value equal to Issuer Identifier of the OP 
as per OpenID Connect Core specification [OIDCC]" ... Should it be clarified 
that "iss" is a URI value?

4.7: "RDAP servers MUST reject queries that include identification information 
that is not associated with a supported OP by returning an HTTP 501 (Not 
Implemented) response." ... Should this not be a 401 (Unauthorized) instead? 
... I know Andy suggested a 400 (Bad Request). :)

4.8: "If a client sends any request that includes an unknown HTTP cookie, the 
server MUST return an HTTP 409 (Conflict) error." ... Should this not be a 401 
(Unauthorized) instead?

5: In some operational scenarios (such as a client that is providing a proxy 
service), an RP can receive tokens with an "aud" value that does not include 
the RP's client_id." ... Should we further elaborate "a client that is 
providing a proxy service"? ... Not clear to me. :)

8.3: "Value: academicPublicInterestDNSRResearch" … Minor: Is there an extra 'R' 
in "DNSRResearch"?

Thanks,
Jasdip

On 9/26/22, 10:03 AM, "regext on behalf of James Galvin" 
 wrote:

The document editors have indicated that the following document is ready 
for submission to the IESG to be considered for publication as a Proposed 
Standard:

Federated Authentication for the Registration Data Access Protocol (RDAP) 
using OpenID Connect
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/17/

Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the the publication of 
this document please respond on the list with your concerns by close of 
business everywhere, Monday, 10 October 2022.  If there are no objections the 
document will be submitted to the IESG.

The Document Shepherd for this document is Zaid Al Banna.

Thanks,

Antoin and Jim
WG Co-Chairs

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance

[Jasdip Singh]

+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.

Three options were proposed on the mailing list and unfortunately the 
Chairs do not believe there was a consensus on the mailing list as to how to 
proceed.  So, the Chairs developed a proposal for how to proceed and presented 
that at the IETF114 meeting.

Since all decision must be made on the mailing list, the purpose of this 
message is to state the proposal and ask for support or objections, similar to 
how we handle WGLC for documents.  Please indicate your support by replying to 
this message with a “+1” or explaining any objection you have.

This CONSENSUS CALL will close in two weeks on 15 August 2022 at close of 
business everywhere.

This proposal had consensus during the IETF114 meeting and is summarized as 
follows.

1. Given that both RFC7480 and RFC9083 are Internet Standards, the bar for 
changes is quite high.

2. There is a generally accepted consensus for how rdapConformance is to be 
used and it is widely deployed today.

3. Although any one of the three options could be a reasonable choice, none 
of them has a broad consensus sufficient to justify changing the Standard.

4. The proposal has two parts as follows:

A. Accept that the RDAP protocol and RDAP Extensions Registry do not 
directly support versioning of extensions and that both support unique 
extension identifiers.

B. Submit Errata to the appropriate RFC in STD95 to harmonize the example 
usage of the extension identifiers “lunarNIC” and “lunarNIC_level_0” to improve 
clarity on the uniqueness of identifiers.

For additional details working group members are referred to the slides 
used by the Chairs during the discussion and recording of the meeting:

SLIDES: 
https://datatracker.ietf.org/doc/slides-114-regext-rdap-extension-identifier-and-rdapconformance/

RECORDING: https://www.meetecho.com/ietf114/recordings#REGEXT

Thanks,

Antoin and Jim

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

Hello Mario, Pawel,

Thanks for eliciting the rationale behind the proposed discovery and IANA 
registration of reverse search properties. I defer to the majority view that 
the benefits outweigh the implementation cost. We can proceed with the WGLC. :)

Regards,
Jasdip

From: Mario Loffredo 
Date: 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 that the we have been discussing about 
their structure for some days and two versions were published.

Anyway, I do believe that the help extension is appropriate in this case and 
seems to me in line with the current WG trend (see other ongoing documents such 
as rdap-openid and rdap-versioning) to provide clients with guidance about both 
pre-defined and custom optional features a server supports.

Furthermore, the additonal implementation effort needed in this case to extend 
the help response is worthwhile if compared to the benefit.

Finally, looking back to the past, this is not the first time we address the 
discovery topic; we have already accomplished it in other RFCs (i.e. 8977 and 
8982), though as a recommendation and according to a different approach.

With hindsight, think it could be useful to follow always the same way whereas 
it makes sense in the future and, in the event of bis-versions, to review the 
existing RFCs accordingly.



Similar considerations can be made with regard to the usage of an ad-hoc IANA 
registry.

Have already said that I don't prefer to use centralized registries but I don't 
strongly object to them. So if, as it seems to be emerged from the discussion, 
there is a prevailing opinion that an IANA registry about the reverse search 
prioperties improves the interoperability, I agree.



Best,

Mario


Il 19/12/2022 16:18, Jasdip Singh ha scritto:
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:

  1.  Is the newly proposed "reverse_search_properties" member in the help 
response (section 5) needed?
  2.  Is the newly proposed "RDAP Reverse Search Properties" registry (section 
9.2) needed?

Thanks,
Jasdip

[1] https://mailarchive.ietf.org/arch/msg/regext/baN_jHO32rRLTbzef6B5Rtep29g/


From: regext <mailto:regext-boun...@ietf.org> on 
behalf of Antoin Verschuren 
<mailto:ietf=40antoin...@dmarc.ietf.org>
Date: Monday, December 19, 2022 at 10:04 AM
To: "regext@ietf.org"<mailto:regext@ietf.org> 
<mailto:regext@ietf.org>
Subject: Re: [regext] New version of rdap-reverse-search

Hi all, can all people that commented on draft-ietf-regext-rdap-reverse-search 
since the start of the previous last call (Tom, Pawel, Jasdip) confirm that all 
their issues are now addressed in version 17, so that the document shepherd can 
confirm there are no new changes to be expected during WGLC?

Once we have confirmation, we will issue a 3th WGLC when the document is stable.

Regards,

Jim and Antoin





Op 1 dec. 2022, om 14:24 heeft Mario Loffredo 
mailto:mario.loffr...@iit.cnr.it>> het volgende 
geschreven:

Hi Chairs,

this is to inform you that I'm ready to submit the new rdap-reverse-search 
version addressing the feedback provided during the LC, i.e. reverse searech 
properties discovery and registration.

Hopefully, no futher feedback will be provided.

Would like to know how to proceed now.

Should I ask for a new WGLC?

Will you do that?


Best,

Mario

--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org<mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext






___

regext mailing list

regext@ietf.org<mailto:regext@ietf.org>

https://www.ietf.org/mailman/listinfo/regext

--

Dott. Mario Loffredo

Technological Unit “Digital Innovation”

Institute of Informatics and Telematics (IIT)

National Research Council (CNR)

via G. Moruzzi 1, I-56124 PISA, Italy

Phone: +39.0503153497

Web: http://www.iit.cnr.it/mario.loffredo
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 switches to the 
new way. That said, perhaps, we could add a section concerning the transition 
from the old way to the new way if that helps clarify.

Thanks,
Jasdip

From: regext  on behalf of "Gould, James" 

Date: Friday, December 9, 2022 at 8:38 AM
To: "jkol...@godaddy.com" , "kowa...@denic.de" 
, "draft-ietf-regext-rdap-redac...@ietf.org" 

Cc: "regext@ietf.org" 
Subject: Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

Jody,

I thought adding the transition period to the MUST NOT would provide for some 
flexibility for those that need to transition from placeholder redaction to 
draft-ietf-regext-rdap-redacted, but I believe a server would implement a hard 
cutover (e.g., supporting the draft with no other form of redaction).  With 
that in mind, I’ll modify option 1 to be simply MUST NOT without any reference 
to a transition period.


1.  Keep MUST NOT – The Section 3 sentence is “The use of placeholder text 
for the values of the RDAP fields, such as the placeholder text "", MUST 
NOT be used for redaction.”.

2.  Change MUST NOT to SHOULD NOT – This enables the draft to recommend that 
placeholder text not be used for redaction, but still enable the server to 
support it in parallel with the redaction methods defined in the extension.  
The Section 3 sentence would become “The use of placeholder text for the values 
of the RDAP fields, such as the placeholder text "", SHOULD NOT be used for 
redaction.”.

3.  Remove the normative language – Change the Section 3 sentence to “The use 
of placeholder text for the values of the RDAP fields, such as the placeholder 
text "", has been used for redaction.”.

4.  Remove reference to placeholder text use for redaction – Just lead Section 
3 with the sentence “This section covers the redaction methods that can be used 
with the redaction signaling defined in Section 
4.2.”.

My preference is option 1 (“Keep MUST NOT”), and I agree that if the normative 
language cannot remain that option 3 (“Remove the normative language”) is the 
best alternative.

Can others from the working group provide their preferred option to address 
Pawel’s last open feedback item?  All of Pawel’s feedback will be incorporated 
in draft-ietf-regext-rdap-redacted-10.

Thanks,

--

JG

[cid:image001.png@01D90BAC.E8B00330]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Jody Kolker 
Date: Friday, December 2, 2022 at 2:27 PM
To: Pawel Kowalik , James Gould , 
"draft-ietf-regext-rdap-redac...@ietf.org" 

Cc: "regext@ietf.org" 
Subject: [EXTERNAL] RE: Review of draft-ietf-regext-rdap-redacted-09

My preference would be that if the server is supporting this draft that 
placeholder text is not allowed to be returned for any redacted field.  I'm not 
sure what a transition period would look like.  It seems to me that a server is 
either supporting the draft with an "rdapConformance" value of "redacted" or 
it's not supporting the draft and does not return the "redacted" value in the 
“rdapConformance” value.  If "redacted" is returned, placeholder text should 
not be used.

I would support option #1 without a transition period.  Servers are free to 
continue with the responses used today that do not include the “redacted”  
“rdapConformance” value if the server is returning placeholder text.  One the 
draft is supported without placeholder text, the “redacted” “rdapConformance” 
value can be returned in the responses.

However, I can live with Option #3 where the RFC acknowledges that placeholder 
text has been used in the past.

Thanks,
Jody Kolker.

From: Pawel Kowalik 
Sent: Friday, November 25, 2022 1:50 AM
To: Gould, James ; draft-ietf-regext-rdap-redac...@ietf.org
Cc: regext@ietf.org
Subject: Re: Review of draft-ietf-regext-rdap-redacted-09

Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.



Hi James,



Thanks for that.

My preference would be 3 or 4, to focus the draft on signaling, allowing the 
clients to recognize redacted fields.



Kind Regards,

Pawel


Am 23.11.22 um 16:57 schrieb Gould, 

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

[Jasdip Singh]

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" , 
Jasdip Singh , "draft-ietf-regext-rdap-redac...@ietf.org" 
, "regext@ietf.org" 
Subject: Re: Re: [regext] Review of draft-ietf-regext-rdap-redacted-09


Thanks everyone that provided their preference for the options on the use of 
redaction by placeholder text.  The following is a breakdown of the preferences 
(first - #1, second - #2, and third - #3) based on the responses received:



  1.  Keep MUST NOT
 *   Jim Gould #1
 *   Jody Kolker #1
 *   Jasdip Singh #1 – Please confirm this is your true #1, since elements 
of option 5 were also referenced in your response
 *   Mario Loffredo #1
 *   Andy Newton #1
 *   Dan Keathley #1
  2.  Change MUST NOT to SHOULD NOT
 *   None
  3.  Remove the normative language
 *   Pawel Kowalik #1
 *   Jody Kolker #2
 *   Jim Gould #3
  4.  Remove reference to placeholder text use for redaction
 *   Pawel Kowalik #2
  5.  Keep MUST NOT with Transition Considerations section
 *   Jim Gould #2
 *   Jasdip Singh #2



At this point draft-ietf-regext-rdap-redacted-10 will keep the MUST NOT 
language, pending any additional responses or options.  
draft-ietf-regext-rdap-redacted-10 will be posted that includes Pawel Kowalik’s 
feedback and Mario Loffredo’s feedback.  The new “Redaction by Partial Value 
Method” will be added based on Mario Loffredo’s feedback.



Thanks,





--



JG







James Gould

Fellow Engineer

jgo...@verisign.com 




703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 12/14/22, 4:57 PM, "Keathley, Daniel"  wrote:



+1 for option 1.



--Dan



On 12/13/22, 9:31 AM, "regext on behalf of Andrew Newton" 
 wrote:



Caution: This email originated from outside the organization. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.



I think Jody captured my thoughts. Option 1 is my preference.



-andy





On Fri, Dec 9, 2022 at 12:33 PM Mario Loffredo

 wrote:

>

> Hi James and others,

>

> I prefer option 1 too.

>

> With regard to the transition period, think it can't really be 
implemented since this specification doesn't describe features for a server to 
swtich from one way to and back from the other on demand until the old way is 
completely deprecated. As opposed to the replacement of jCard with JSContact, 
in this case it's not worth it because basically it doesn't make much 
difference for a client if an RDAP field is missing or contains a placeholder 
value.

   >

> What a server can do is to notify the clients about the imminent 
change of redaction strategy and then make the switch when it's time.

>

> Best,

>

> Mario

>

> Il 09/12/2022 15:30, Gould, James ha scritto:

>

> Jasdip,

>

>

>

> Agreed.  If providing clarity around transitioning to the old way to 
the new way makes sense to keep the MUST NOT language, then that can certainly 
be done.  The transition considerations section could include an overlap period 
that supports a soft cutover.  A similar kind of section can be found for the 
Secure Authorization Information for Transfer RFC 9154 
(https://secure-web.cisco.com/1W2fXVOH_5_TikpsQ6Z8tBYK_87TJMLAKMNijY5Q1PGkDrUWmCrx8F9cJt5du66V0ULUGUpdgkMTOSUBoDaPsh6htrVn6XxNJYcqcqnu_nMBKp8ASBJGsDg8KX82CO3_EK6UbxXDf-XNDIoosqRc5Nh_TigXNN58U5lg9nevht7BmHW6YWjIbTMWsuV_sc7JIUZOaPmegkJ7S2vYWtq--wN4BFB-Kf3Wr_UrIcvCRJSrsdI-sIk_V0poe945FEcJiRg7LpTIoc2R8rvPsCSoX2iRYEmEcnH0NEkDcTfODYSE/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9154%23section-6);
 although the redaction transition section would be much simpler.  With that 
I’ll add back in inclusion of the MUST NOT language and the transition 
considerations section to the list of options, as option 5.

>

>

>

> 1.  Keep MUST NOT – The Section 3 sentence is “The use of 
placeholder text for the values of the RDAP fields, such as the placeholder 
text "", MUST NOT be used for redaction.”.

>

> 2.  Change MUST NOT to SHOULD NOT – This enables the draft to 
recommend that placeholder text not be used for redaction, but still enable the 
server to support it in parallel with the redaction methods defined in the 
extension.  The Section 3 sentence would become “The use of placeholder text 
for the values of the RDAP fields, such as the placeholder t

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

[Jasdip Singh]

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 proposed "RDAP Reverse Search Properties" registry (section 
9.2) needed?

Thanks,
Jasdip

[1] https://mailarchive.ietf.org/arch/msg/regext/baN_jHO32rRLTbzef6B5Rtep29g/


From: regext  on behalf of Antoin Verschuren 

Date: Monday, December 19, 2022 at 10:04 AM
To: "regext@ietf.org" 
Subject: Re: [regext] New version of rdap-reverse-search

Hi all, can all people that commented on draft-ietf-regext-rdap-reverse-search 
since the start of the previous last call (Tom, Pawel, Jasdip) confirm that all 
their issues are now addressed in version 17, so that the document shepherd can 
confirm there are no new changes to be expected during WGLC?

Once we have confirmation, we will issue a 3th WGLC when the document is stable.

Regards,

Jim and Antoin




Op 1 dec. 2022, om 14:24 heeft Mario Loffredo 
mailto:mario.loffr...@iit.cnr.it>> het volgende 
geschreven:

Hi Chairs,

this is to inform you that I'm ready to submit the new rdap-reverse-search 
version addressing the feedback provided during the LC, i.e. reverse searech 
properties discovery and registration.

Hopefully, no futher feedback will be provided.

Would like to know how to proceed now.

Should I ask for a new WGLC?

Will you do that?


Best,

Mario

--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 
future) for reverse search clearly defines in its spec the 
searchable-resource-type/related-resource-type/search property combinations, 
should that not suffice? Especially if keeping the RDAP client implementations 
simpler is a foremost goal for us, and since such metadata would seemingly tax 
RDAP clients (and servers) with more complex implementations. For the existing, 
implemented search scenarios in RDAP (RFCs 9082 and 9083), we have managed to 
avoid introducing such metadata so far. It would be good to be certain if the 
proposed discovery and IANA registration of reverse search properties is truly 
a need for the RDAP clients.

However, if we were to proceed with the reverse search metadata discovery, then 
looks like a new IANA registry for this purpose would be better than 
overloading the current RDAP JSON Values registry, given the proposed metadata 
has a richer data structure than what the latter offers.

Thanks,
Jasdip

On 11/28/22, 5:36 PM, "regext on behalf of Tom Harrison" 
 wrote:

Hi Mario,

On Mon, Nov 28, 2022 at 07:19:20PM +0100, Mario Loffredo wrote:
> Il 27/11/2022 22:49, Tom Harrison ha scritto:
>> On Fri, Nov 25, 2022 at 02:18:35PM +0100, Mario Loffredo wrote:
>>> Even now there is no real way to prevent collisions since
>>> extension identifiers and JSON values are normally used for long
>>> before they are registered.
>>> 
>>> Currently, only when an extension is considered stable, the
>>> related identifier is registered.
>>> 
>>> Think that preventing RDAP operators to provide temporary reverse
>>> search properties is incompatible with registries'policy of
>>> releasing features on test platforms for a limited period before
>>> running them in the live environment.
>>
>> I can see the argument here, but the document doesn't say e.g.
>> "custom properties may only be used temporarily, or for testing
>> purposes", so it doesn't prevent two servers from having two custom
>> properties with the same name and different behaviour, each of
>> which is intended to be used long-term (i.e. neither server intends
>> to register the property, for whatever reason).  If support for
>> custom properties is omitted from the document, then a server
>> wanting to support a new reverse search property temporarily or for
>> testing can still do that, but the lack of in-protocol support for
>> that makes it clear that it's not meant to be a long-term solution.
> 
> Would like to reach the largest consensus on this point too.
> 
> Therefore, my proposal is to rearrange the
> "reverse_search_properties" extension by removing "type" and keeping
> "links" anyway.
> 
> The "links" member could be used to provide additional information
> about unregistered properties.
> 
> Would it work for you?

If a server has implemented a custom reverse search property
temporarily, or for testing, then there will (should) be a defined
audience for that property, and that audience should be aware of the
behaviour of that property due to documentation provided out of band.
Providing documentation about unregistered properties by way of a
'links' member facilitates discovery/use of those properties by any
RDAP client, which works against the aim of the registry, so I'd
prefer that 'links' be omitted for that reason.  I think
'rdapPropertyPath' should be omitted for similar reasons.

(Although providing reverse_search_properties in-band at all
"facilitates discovery/use of properties" that might be unregistered,
each of the other elements is necessary even in the case of registered
properties, because servers are not required to implement every
possible combination of reverse search that is defined in the
document.)

-Tom

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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" 
mailto:regext-boun...@ietf.org> on behalf of 
shollenbeck=40verisign@dmarc.ietf.org 
> wrote:

> >>> Yes, it's more work for servers, but it makes things easier for clients.
> >> [JB] I agree that the server development should follow Postel's law
> >> but why not adding this as a capability in the
> >> farv1_openidcConfiguration structure, so what is implemented would be
> clear and won't break the principle.
> >> This concern is based on feedback I got from developers, including
> >> people maintaining RDAP servers. I think we may end up with partial
> >> implementations without a way to be aware that only one client type is
> supported.
> > [SAH] I'd really like to hear what others have to say about this. A server 
> > that
> only supports one type of client won't be accessible to some number of end
> users. That doesn't sound like a good thing.
>
> [ML] I support Julien's proposal.
>
> The token-based approach will be implemented with little to no effort while 
> the
> session-based approach will take much more time.
>
> IMO, separating the implementation of the two approaches would enable
> implementers to easily comply with the spec.
>
> In addition, the token-based approach might be the only one practicable due 
> to
> the server policy of accepting the authenticated requests from trusted 
> clients
> only.

[SAH] Thanks for the feedback, Mario. I still don't think this is a good idea, 
but if mine is a minority opinion I'll update the text to remove the MUST and 
include config info so a server can describe the type(s) of clients it 
supports. Please folks, share an opinion now if you have one. Should a server 
be able to support one type of client only?

[JS] As much as we want to be liberal in accepting various usage scenarios from 
clients, I think there is a merit in considering the implementation cost for 
RDAP servers. Tend to agree with Mario and Julien; allowing a server to signal 
the type of clients it supports should help speed up the server implementations 
for this proposal. 


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

Hello Mario,

The way you explain "unregistered" below indicates an entry that is presently 
not in the IANA registry. Perhaps we could evolve that statement as:

  Servers MUST NOT provide or implement reverse searches or reverse search 
mappings that are not registered with IANA.

The dictionary definition of "unregistered" returns "not officially recognized 
and recorded." So, in that sense, you are spot on with the original statement. 
The "un" prefix in "unregistered" threw me off, as in an act of undoing 
something. I'd be good with 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 Loffredo" mailto:mario.loffr...@iit.cnr.it> <mailto:mario.loffr...@iit.cnr.it 
<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, or simply marking 
>> them as deprecated? If the latter, do we need a status field in these 
>> registries to differentiate the active entries from the deprecated ones? Not 
>> clear about it.
> [ML] Unregistered means merely not included in the registries and the
> sentence looks clear to me. Don't think the registries' entries should
> be removed or deprecated as well.
>
> Registries can decide on their own to deprecate either properties or
> mappings and how long should be the deprecation period. Obviously,
> deprecations can be finally achieved de facto but we cannot be
> completely sure that some entries are no more active.
>
> [JS] Perhaps, we are here conflating the proposed RDAP Reverse Search and 
> RDAP Reverse Search Mapping IANA registries with the DNRs (Domain Name 
> Registries) and RIRs (Regional Internet Registries)? :) My question is about 
> the lifecycle of an entry in the RDAP Reverse Search and RDAP Reverse Search 
> Mapping IANA registries and how an entry there is "unregistered". (Assuming 
> the word "unregistered" is being used above for such entries.)

[ML] Personally, the entries of both the registries can never be 
updated. As I said in my previous reply, unregistered doesn't mean 
removed/deprecated once registered but just not yet included in the 
registry.

[JS] just not yet included in the registry" ... Do we mean here not including 
that unregistered entry on the RDAP server side (DNRs and RIRs)?

Neither I see a particular need for specifying in the registry that an 
entry gets obsolete. In that case, the property or the mapping will not 
be included in the reverse_search_properties or 
reverse_search_properties_mapping, respectively.

Hope I clarified my previous comment.

[JS] It might help to clarify further in the doc what "unregistered" means, 
using the above verbiage. But then it could just be me getting confused by that 
term. :) Your call in the end.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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, or simply marking 
>> them as deprecated? If the latter, do we need a status field in these 
>> registries to differentiate the active entries from the deprecated ones? Not 
>> clear about it.
> [ML] Unregistered means merely not included in the registries and the
> sentence looks clear to me. Don't think the registries' entries should
> be removed or deprecated as well.
>
> Registries can decide on their own to deprecate either properties or
> mappings and how long should be the deprecation period. Obviously,
> deprecations can be finally achieved de facto but we cannot be
> completely sure that some entries are no more active.
>
> [JS] Perhaps, we are here conflating the proposed RDAP Reverse Search and 
> RDAP Reverse Search Mapping IANA registries with the DNRs (Domain Name 
> Registries) and RIRs (Regional Internet Registries)? :) My question is about 
> the lifecycle of an entry in the RDAP Reverse Search and RDAP Reverse Search 
> Mapping IANA registries and how an entry there is "unregistered". (Assuming 
> the word "unregistered" is being used above for such entries.)

[ML] Personally, the entries of both the registries can never be 
updated. As I said in my previous reply, unregistered doesn't mean 
removed/deprecated once registered but just not yet included in the 
registry.

[JS]  just not yet included in the registry" ... Do we mean here not including 
that unregistered entry on the RDAP server side (DNRs and RIRs)?

Neither I see a particular need for specifying in the registry that an 
entry gets obsolete. In that case, the property or the mapping will not 
be included in the reverse_search_properties or 
reverse_search_properties_mapping, respectively.

Hope I clarified my previous comment.

[JS] It might help to clarify further in the doc what "unregistered" means, 
using the above verbiage. But then it could just be me getting confused by that 
term. :) Your call in the end.

Jasdip



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 Jasdip,

can you please confirm that all of your remarks have been addressed ?

Thanks a lot,

Mario
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 "resorce" in "triple ".
- 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, or simply marking them 
as deprecated? If the latter, do we need a status field in these registries to 
differentiate the active entries from the deprecated ones? Not clear about it.
- Section 8: "The presence of a predicate on the reverse search property "role" 
means that the RDAP response property "roles" must contain at least the 
specified role." ... Should "must" be changed to "MUST"?
- Section 12.1: "Intended usage: This extension identifier is used for reverse 
search URI path segments." ... Should we elaborate here that this extension 
identifier is also used as a prefix in the "reverse_search_properties" and 
"reverse_search_properties_mapping" data members' names?
- Section 13: "Since reverse search requests and responses could contain 
Personally Identifiable Information (PII), reverse search functionality SHOULD 
be available over HTTPS only." ... Should "SHOULD" be changed to "MUST"? IIRC, 
we strongly discourage using HTTP (versus HTTPS) in RDAP.
- Appendix A: Just curious if the reason why the "Federated Authentication for 
the Registration Data Access Protocol (RDAP) using OpenID Connect" draft is not 
mentioned in this draft is because we think that the latter would be on the 
standards track before the former?

Overall, this work has evolved pretty well. :)

Thanks,
Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] JSContact issues

[Jasdip Singh]

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 20/03/2023 12:06, Andrew Newton ha scritto:

On Fri, Mar 17, 2023 at 10:45 AM Mario Loffredo

 wrote:

1) Section 3 has some strong MUST language regarding JSContact and

EPP. As I'm reading it, I am trying to deduce what interoperability

problem is being mitigated but, at least to me, it is not apparent. If

there is some cardinality issue, I think the rules should be

generalized because RDAP is used by more than just the EPP registries,

most notably the RIRs but also Marc's space debris proposal.



If an EPP mapping is truly necessary, I think putting it in a separate

EPP mapping section would be better. Also, unless things will truly

break, the normatives should be SHOULD and not MUST.

[ML] No problem. I can remove the reference to the RFC5733 labels and

generally talk about the unique or the preferred value for each contact

property.

For clarity, I don't think a 5733 mapping is a bad thing. I just want

to be sure we accommodate those servers where it has no relevance.

[ML] Me neither. But I think there would be no more need to clearly refer to 
RFC5733 properties if I talked more generally about mostly used properties in 
RDAP  and their related unique/preferred values.

The bigger contains the smaller. :-)

Would like to know if there are other possible commonly used contact properties 
in addition to those mentioned currently.

[JS] Just checked RFC 9083, and there is no explicit mention of RFC 5733 
vis-à-vis defining the Entity Object class. So, agree that no need to tie 
closely with RFC 5733 here.

As for the non-DNR actors, just looking at what ARIN returns for an entity 
response, what’s currently listed in this draft should suffice.

I would be inclined to leave MUST to provide clients and servers with a

pre-defined set of map keys for the mostly used contact properties.

If left as a MUST, the document should be clear about what

interoperability problem will occur if that MUST is violated. At least

to me it is not clear.

[ML] I refer to the interoperability issues coming from using different JSON 
labels to identify the same logical JSON object.

Let's take, for example, how a JSContact collection can be handled. If it gets 
deserlized to a map,  you can leverage the map capability to access an entry by 
its key rather than looping on the entries to find out the desire entry.

I mean, you can access the unique/preferred fax number by getting the right 
entry of the "phones" map by the "fax" key instead of looping on all the 
"Phone" objects to find out the one whose "features" include "fax" and "pref"  
equals to 1.

Through the capabilities of the JSON libraries, it is easy to implement a mixed 
deserialization strategy: "phones" is an object having two Phone members, 
namely "voice" and "fax", and additional Phone members are put on a map.

All above is possible so long as the map keys are pre-defined.

In addition, I would define a general mapping scheme that SHOULD

(instead of MAY) be used for the additional entries of the mostly used

maps or others.



The scheme could merely consist in appending a sequential number to the

map name in the singular (e.g. "phone-1", "phone-2" for the additional

entries of the "phones" map to those identified by "voice" and "fax" ).



The other option is to always apply the general scheme to any map key.



Which way do you and others consider the most suitable ?

Conceptually this sounds good. I would need to see a few examples to

wrap my brain around it though. :)

[ML] Here in the following an example of how the "phones" map could be.

Option 1:

"phones": {

  "voice" : {

"@type": "Phone",

"contexts": {

  "work": true

},

"features": {

   "voice": true

},

"pref": 1,

"number": "tel:+1-555-555-1234"

  },



  "phone-1" : {

"@type": "Phone",

"contexts": {

  "work": true

},

"features": {

   "voice": true

},

"pref": 2,

"number": "tel:+1-555-555-5678"

  },

  "fax" : {

"@type": "Phone",

"contexts": {

  "work": true

},

"features": {

   "fax": true

},

"number": "tel:+1-555-555-9012"

  }



},

Option 2:

"phones": {

  "phone-1" : {

"@type": "Phone",

"contexts": {

  "work": true

},

"features": {

   "voice": true

},

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

[Jasdip Singh]

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 them, or simply marking them 
> as deprecated? If the latter, do we need a status field in these registries 
> to differentiate the active entries from the deprecated ones? Not clear about 
> it.

[ML] Unregistered means merely not included in the registries and the 
sentence looks clear to me. Don't think the registries' entries should 
be removed or deprecated as well.

Registries can decide on their own to deprecate either properties or 
mappings and how long should be the deprecation period. Obviously, 
deprecations can be finally achieved de facto but we cannot be 
completely sure that some entries are no more active.

[JS] Perhaps, we are here conflating the proposed RDAP Reverse Search and RDAP 
Reverse Search Mapping IANA registries with the DNRs (Domain Name Registries) 
and RIRs (Regional Internet Registries)? :) My question is about the lifecycle 
of an entry in the RDAP Reverse Search and RDAP Reverse Search Mapping IANA 
registries and how an entry there is "unregistered". (Assuming the word 
"unregistered" is being used above for such entries.)

> - Section 12.1: "Intended usage: This extension identifier is used for 
> reverse search URI path segments." ... Should we elaborate here that this 
> extension identifier is also used as a prefix in the 
> "reverse_search_properties" and "reverse_search_properties_mapping" data 
> members' names?

[ML] Are you OK with the following?

Intended usage: This extension identifier is used for both URI path segments 
and response extensions related to the reverse search in RDAP.

[JS] Yes, that's comprehensive now.

> - Appendix A: Just curious if the reason why the "Federated Authentication 
> for the Registration Data Access Protocol (RDAP) using OpenID Connect" draft 
> is not mentioned in this draft is because we think that the latter would be 
> on the standards track before the former?

[ML] Not just because of it.

As said in the previous point, RDAP providers are free to implement 
their security measures as they see fit. Using OpenID is an option. 
Registries could implement additional OpenID measures that are not 
described in rdap-openid such as those presented in Appendix A, 
specifically time-based and attribute-based access control features.

That being said, I can't find a valid reason to keep a dependency on an 
ongoing document included in the informative references.

[JS] Agreed.

Thanks,
Jasdip






___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

+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 the IESG to be considered for publication as a Proposed Standard:

Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/ 


Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 1 May 2023. 

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Gustavo Lozano Ibarra.

Thanks,

Jim and Antoin
REGEXT WG Co-Chairs
___
regext mailing list
regext@ietf.org 
https://www.ietf.org/mailman/listinfo/regext 




___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 7:21 AM
To: "mario.loffr...@iit.cnr.it" , "regext@ietf.org" 

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

Mario,

I agree if you can’t remove the mandatory UID field to comply with the 
JSContact specification and are forced to use a literal value (placeholder 
text) than the Redaction by Replacement Value Method is the best route to go 
for redaction, since it explicitly signals the use of replacement value to the 
client.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext  on behalf of Mario Loffredo 

Date: Thursday, April 20, 2023 at 2:00 AM
To: "regext@ietf.org" 
Subject: [EXTERNAL] [regext] Fwd: [Ext] Re: Redacting JSContact uid in RDAP - 
Updated


Hi all,

willing to finalize the discussion about how to redact JSContact uid in RDAP, I 
first would like to thank everyone who has provided feedback. Really 
appreciated it.

SInce it seems to me that no option has collected the largest consensus, I 
would like to make a new proposal that hopefully will be more widely shared.

The proposal preserves the mandatory constraint on uid and doesn't introduce 
new redaction methods.

Assuming that an RDAP operator should be free to use any of the uid formats 
allowed, the redaction method might differ accordingly.

In particular, I envisage two methods could be used.

If an RDAP operator opted for the free-text format, the Empty Value method 
would work better.

If the UUID format is selected,  the Replacement Value method using the nil 
UUID as replacing value is the most appropriate in my opinion. Don't find a 
reason to register a specific URN value when an unspecified value already 
exists and considering that what really matters is not the returned value but 
rather that a related item is added to the redacted array. Neither we really 
need to add specific redaction methods because "Replacement Value" already fits 
the case of replacing the original value with another one.

An URI value could be redacted by using any of the two methods above.

For example, if the uid was usually set to the URL of the RDAP entity related 
to the contact (e.g. 
"https://example.com/rdap/entity/XYZ12345;),
 the redaction could consist in replacing the entity handle with a fixed 
literal (e.g 
"https://example.com/rdap/entity/X;).

Still believe that overriding the mandatory constraint is the most correct 
approach from the conceptual perspective but couldn't be natively supported by 
libraries handling the JSContact format and strictly adhering to the 
specification.



If there are no objections, I'll incorporate the proposal into rdap-jscontact.
Best,
Mario


 Messaggio Inoltrato 
Oggetto:

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

Data:

Tue, 4 Apr 2023 12:44:17 +0200

Mittente:

Mario Loffredo 

A:

Gustavo Lozano Ibarra 
, Andrew Newton 


CC:

Hollenbeck, Scott 
,
 regext@ietf.org 




Hi Gustavo,

thanks for you comment.


For the sake of limiting the implications of rdap-jscontact on rdap-redacted, 
just checked on some web sites providing UUID generators that "nil UUID" and 
"empty UUID" are synonyms.

Since rdap-redacted defines "redaction by Empty Value" (rather than empty 
string), wonder if we could consider the setting of the uid property to an 
Empty/nill UUID (i.e. "----") as an usage of 
such a method.

As a result, the same redaction method could be used to redact uid values in 
both free-text and UUID formats.


Another possible solution is to define in rdap-redacted a registry including 
the redaction methods.

New 

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

[Jasdip Singh]

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, Jasdip Singh ha scritto:

On 3/22/23, 5:44 PM, "regext on behalf of Andrew Newton" 
mailto:regext-boun...@ietf.org> 
<mailto:regext-boun...@ietf.org><mailto:regext-boun...@ietf.org> on behalf of 
a...@hxr.us<mailto:a...@hxr.us> <mailto:a...@hxr.us><mailto: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 of RFC 9082 says, "Servers MUST return an HTTP 501 (Not 
Implemented) [RFC7231] response to inform clients of unsupported query types." 
If that strictly applies to the query types listed in RFC 9082, then an 
explicit mention in this draft makes sense.

Sorry but it's not clear to me the meaning of "unsupported query types".

In RFC7231 HTTP 501 is used to signal a client that it requested a method on a 
given resource the server doesn't implement :

Section 4.1

   The set of methods allowed by a target resource can be listed in an

   Allow header field (Section 7.4.1).  However, the set of allowed

   methods can change dynamically.  When a request method is received

   that is unrecognized or not implemented by an origin server, the

   origin server SHOULD respond with the 501 (Not Implemented) status

   code.



and Section 6.6.2

   The 501 (Not Implemented) status code indicates that the server does

   not support the functionality required to fulfill the request.  This

   is the appropriate response when the server does not recognize the

   request method and is not capable of supporting it for any resource.

The only HTTP method available on RDAP search endpoints is GET so I don't think 
we need to add text to clarify it.

In the case the client requests for an endpoint that is not supported, the HTTP 
code to be used is 404 (Not Found).

Section 6.5.4.

   The 404 (Not Found) status code indicates that the origin server did

   not find a current representation for the target resource or is not

   willing to disclose that one exists.

The remaining case to handle is when the client requests for a supported 
endpoint but the server policy restricts the usage of the predicates in the 
reverse search and the draft have already addressed it.

Which "unsupported query types" are you thinking about ?

[JS] From Section 1 of RFC 9082:

“The intent of the patterns described here is to enable queries of:

  *   networks by IP address;
  *   Autonomous System (AS) numbers by number;
  *   reverse DNS metadata by domain;
  *   nameservers by name; and
  *   entities (such as registrars and contacts) by identifier.

Server implementations are free to support only a subset of these features 
depending on local requirements. Servers MUST return an HTTP 501 (Not 
Implemented) [RFC7231] response to inform clients of unsupported query types.”

IIUC, "unsupported query types" seems to apply to the above list of queries 
via-a-vis returning HTTP 501.

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 HTTP 501 to unsupported request methods 
seems right. Not to muddle but wonder if we missed applying HTTP 501 correctly 
in RFC 9082?
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 of RFC 9082 says, "Servers MUST return an HTTP 501 (Not 
Implemented) [RFC7231] response to inform clients of unsupported query types." 
If that strictly applies to the query types listed in RFC 9082, then an 
explicit mention in this draft makes sense.

Jasdip


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 server could simply 
send back a notice as to when jCard would be sunset from its side. As was 
mentioned previously, agree that a server couldn’t definitively measure when 
the client demand for jCard goes to zero by looking at the proposed query 
parameters. Instead, the server would decide unilaterally with sufficient 
forewarning to clients.

Jasdip

From: regext  on behalf of Mario Loffredo 

Date: Monday, April 3, 2023 at 5:32 AM
To: Rick Wilhelm , Andy Newton 
Cc: Marc Blanchet , "regext@ietf.org" 

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


Hi Rick,

please find my comments below.
Il 01/04/2023 03:03, Rick Wilhelm ha scritto:
I think that I’m leaning towards Andy’s approach, but I haven’t soak this 
thinking for very long.

Perhaps it’s useful to go back to one of the original motivations for the draft.

As I recall, programmers, especially client-side, have been known to have 
difficulty with JCard (for various reasons).

Therefore, a “more modern” approach using JSContact is being proposed.

So… A server presently has to support JCard and theoretically MAY support 
JSContact.

If a client encounters such a server, and detects that the server supports 
JSContact, then it would be able to reliably ignore the JCard that is returned 
and instead use code that parses JSContact and be on its merry way.

A key difference between Mario’s (2) and Andy(3) is basically a negotiation 
step.  While I understand the benefit of “smaller response” proposed by (2), it 
seems that the negotiation step (with its round trips) would overwhelm that.  
And perhaps lead to odd situations (race conditions?) if the server is 
responding inconsistently.

On balance, to me the cost of some extra bytes on the wire is cheap compared to 
the additional client and server code complexity, and the server load of the 
extra connection.

Interested in others thoughts.

[ML] Up to now, we have always followed the philosophy that an addtional 
feature must be provided by the server on demand.

I would keep it also in this case so I would make the submission of jscard 
parameter the condition to receive JSContact.

In my opinion, it's useless to provide the same information twice in two 
different formats simultaneously because the client will always use only one.
Furthermore, providing the contact information in two formats increases the 
risk of inconsistencies between them.



Please take a look at the change on the current approach I proposed  to Andy 
and say if it works for you too.

Best,

Mario



Thanks
Rick


From: regext  on 
behalf of Andrew Newton 
Date: Saturday, April 1, 2023 at 6:27 AM
To: Mario Loffredo 
Cc: Marc Blanchet 
, 
regext@ietf.org 

Subject: [EXTERNAL] Re: [regext] jCard to JSContact transition
CAUTION: This email came from outside your organization. Don’t trust emails, 
links, or attachments from senders that seem suspicious or you are not 
expecting.

I really don't understand this decision tree. JCard is in the standard
today while JSContact is not. Any transition that aims to be as
non-disruptive as possible would need to start at serving JCard today,
serving both JCard and JSContact, and then phasing out JCard.

-andy

On Thu, Mar 30, 2023 at 8:37 PM Mario Loffredo
 wrote:
>
> Hi Marc,
>
> thanks for your quick reply.
>
> Think it's always better to reduce the response payload when you can
> through a low implementation effort. But it's just my opinion.
>
> So now we have 3 proposals on the table :-))
>
>
> Best,
>
> Mario
>
>
> Il 30/03/2023 13:09, Marc Blanchet ha scritto:
> >
> >> Le 30 mars 2023 à 19:47, Mario Loffredo 
> >>  a écrit :
> >>
> >> Hi folks,
> >>
> >> this is a post to resume the discussion about how to execute the 
> >> transition from jCard to JSContact.
> >>
> >> Up to now, there are two approaches on the table:
> >>
> >>
> >> 1) Returning JSContact in place of jCard (current proposal)
> >>
> >> Until transition is ended, a server returns one of the two formats by 
> >> default and returns the other on request.
> >>
> >> Each server can decide that it's time to stop supporting jCard based on 
> >> the evidence that it's no more requested.
> >>
> >>
> >> 2) Returning JSContact in addition to jCard
> >>
> >> Until transition is ended, a server returns jCard by default and adds 
> >> JSContact to the response on request.
> >>
> >> Each server arbitrarily decides when it's time to stop supporting jCard.
> >>
> > Sorry Mario, I’ve been 

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

[Jasdip Singh]

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 PM, "Mario Loffredo" 
mailto:mario.loffr...@iit.cnr.it> 
<mailto:mario.loffr...@iit.cnr.it><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 invalid method. If the operative text is “the server does not

support the functionality required to fulfill the request”, the

response can be returned for

*any* condition in which the server does not support the

functionality required to fulfill the request. It doesn’t say that

“the server does not support the requested method”. I still believe that

501

would be the best response.

After rereading the text, I agree with Scott.

[ML] Just to understand better, daes it mean that an RDAP server

should support additional lookups and searches to those really

implemented with the only purpose of returning an error ?

[SAH] No. The point I'm trying to make is that if a client sends a valid

request

to an RDAP server, and that request can't be processed because the requested

functionality isn't supported, then a 501 response is appropriate.



[ML] It's unclear to me what "functionality" (as well as "unsupported query

type") means.



Excluding the HTTP methods and the endpoints, what remains is a

functionality

requested by clients through either a query parameter or an header but

unsupported/unknown parameters/headers are simply ignored.



Is there something else ?

[SAH] A path segment? Imagine sending something like this to a domain name

registry:



https://example.com/rdap/autnum/12 
<https://example.com/rdap/autnum/12><https://example.com/rdap/autnum/12>



It's RDAP-valid, but a domain name registry probably doesn't support

autonomous system number lookup functionality.



[ML] Don't know if I'm the only one but I think it's an unpractical

recommendation.



I admit that 501 is more explanatory because, taking your example, 404

would be returned when the autnum lookup is unsupported and when

autnum/12 is not found but a server can provide the clients with

information about the supported features by other means.



Conversely, exposing useless endpoints on the web means not only to

require an unnecessary implementation effort but also to enlarge the

surface of cyberattacks.



Definitely, the servers need only to handle the endpoints they really

listen at and the query parameters or request headers they really support.



That said, if I'm the only dissonant voice in discussion, I'll add that

recommendation to rdap-reverse-search.



[JS] Mario, I think it would be a good idea to add verbiage for 501 (Not 
Implemented) in this draft since we have a precedence in RFC 9082 and that does 
not seem to cover new query types like reverse search. Then, the draft can 
proceed to the next step. :)

No worries, Jasdip. I'll update the document as soon as the WGLC is ended.

Does it work the following ?

Servers MUST return an HTTP 501 (Not Implemented) [RFC9110] response to inform 
clients of unsupported reverse searches.

[JS] Yes, that should do it.



Thanks,

Jasdip
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 invalid method. If the operative text is “the server does not
 support the functionality required to fulfill the request”, the
 response can be returned for
 *any* condition in which the server does not support the
 functionality required to fulfill the request. It doesn’t say that
 “the server does not support the requested method”. I still believe that
 501
>> would be the best response.
> After rereading the text, I agree with Scott.
 [ML] Just to understand better, daes it mean that an RDAP server
 should support additional lookups and searches to those really
 implemented with the only purpose of returning an error ?
>>> [SAH] No. The point I'm trying to make is that if a client sends a valid
>>> request
>> to an RDAP server, and that request can't be processed because the requested
>> functionality isn't supported, then a 501 response is appropriate.
>>
>> [ML] It's unclear to me what "functionality" (as well as "unsupported query
>> type") means.
>>
>> Excluding the HTTP methods and the endpoints, what remains is a
>> functionality
>> requested by clients through either a query parameter or an header but
>> unsupported/unknown parameters/headers are simply ignored.
>>
>> Is there something else ?
> [SAH] A path segment? Imagine sending something like this to a domain name
> registry:
>
> https://example.com/rdap/autnum/12 
>
> It's RDAP-valid, but a domain name registry probably doesn't support
> autonomous system number lookup functionality.

[ML] Don't know if I'm the only one but I think it's an unpractical 
recommendation.

I admit that 501 is more explanatory because, taking your example, 404 
would be returned when the autnum lookup is unsupported and when 
autnum/12 is not found but a server can provide the clients with 
information about the supported features by other means.

Conversely, exposing useless endpoints on the web means not only to 
require an unnecessary implementation effort but also to enlarge the 
surface of cyberattacks.

Definitely, the servers need only to handle the endpoints they really 
listen at and the query parameters or request headers they really support.

That said, if I'm the only dissonant voice in discussion, I'll add that 
recommendation to rdap-reverse-search.

[JS] Mario, I think it would be a good idea to add verbiage for 501 (Not 
Implemented) in this draft since we have a precedence in RFC 9082 and that does 
not seem to cover new query types like reverse search. Then, the draft can 
proceed to the next step. :)

Cheers,
Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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
> mailto:shollenb...@verisign.com>>
> Cc: jasd...@arin.net ; regext@ietf.org 
> 
> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-
> 20
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content is
> safe.
>
> Hi Scott and Andy,
>
> Il 04/04/2023 18:33, Andrew Newton ha scritto:
> > 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 7231, but I don’t think it’s 
> >> limited to
> an invalid method. If the operative text is “the server does not support the
> functionality required to fulfill the request”, the response can be returned 
> for
> *any* condition in which the server does not support the functionality 
> required
> to fulfill the request. It doesn’t say that “the server does not support the
> requested method”. I still believe that 501 would be the best response.
> >>
> > After rereading the text, I agree with Scott.
>
> [ML] Just to understand better, daes it mean that an RDAP server should
> support additional lookups and searches to those really implemented with the
> only purpose of returning an error ?

[SAH] No. The point I'm trying to make is that if a client sends a valid 
request to an RDAP server, and that request can't be processed because the 
requested functionality isn't supported, then a 501 response is appropriate.

Precisely. Let's take an example. Say, a client sends a 
"nameservers/reverse_search/entity?..." query but the server has not 
implemented the "nameservers?..." search path segment (section 3.2.2 from RFC 
9082) to start with. Then, a 501 (Not Implemented) is a more appropriate 
response for this reverse search query; 400 (Bad Request) won't work here 
because that client query is well-formed to begin with. Right?

Jasdip


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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



Il 04/04/2023 17:37, Jasdip Singh ha scritto:

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 HTTP 501 to unsupported request methods 
seems right. Not to muddle but wonder if we missed applying HTTP 501 correctly 
in RFC 9082?



That is what I meant, but perhaps 405 is the more appropriate

response. Kinda annoying that 9082 went through 2 IETF last calls and

this wasn't caught.



-andy


AFAIU, RFC 7231 states that:

- 404 must be returned to signal that the target resource is unknown to the 
server;

   The 404 (Not Found) status code indicates that the origin server did

   not find a current representation for the target resource or is not

   willing to disclose that one exists

- 405 must be returned to signal that an HTTP method is unsupported on the 
target resource but known to the server;

   The 405 (Method Not Allowed) status code indicates that the method

   received in the request-line is known by the origin server but not

   supported by the target resource

- 501 must be returned to signal that an HTTP method is unknown to the server

   The 501 (Not Implemented) status code indicates that the server does

   not support the functionality required to fulfill the request.  This

   is the appropriate response when the server does not recognize the

   request method and is not capable of supporting it for any resource.

Based on it, don't think rdap-reverse-search should add text to address these 
cases.

As I wrote in my previous reply, the document had only to define the server 
operation when the client includes in the request an unsupported reverse search 
property or combination of reverse search properties.

In this case, the server must return 400 (Bad Request).
With regard to RFC 9082, my proposal is to remove  the sentence in subject.



[JS] If the intent vis-à-vis error codes is to differentiate a feature that is 
not implemented on the server side versus a bad request for an implemented 
feature, 400 (Bad Request) does not look like a good fit for the former since 
it is not a client error when a feature is not supported. Thanks to Mario, we 
learnt 501 (Not Implemented) is also not a good fit for the former since it is 
at the HTTP method level (GET in our case). That seems to leave 405 (Method Not 
Allowed) as a viable alternative to 501 since per RFC 9110, “The 405 (Method 
Not Allowed) status code indicates that the method received in the request-line 
is known by the origin server but not supported by the target resource.” 
Irrespective, 501 looks like an errata for Section 1 in RFC 9082.



[ML] Sorry Jasdip, but I didn't catch if your comment (or which part) is about 
the reverse search document or RFC 9082.

With regard to the reverse search document, 400 looks to me the only one 
fitting the case.
Surely it's a client error if the client includes in the query string either an 
unsupported or an invalid  combination of reverse search properties.

Just for example, .it RDAP server requires the client to always include "role"  
along with another supported reverse search property in a reverse search.

The server may restrict the use of the reverse search feature based on its 
policy and the client must comply with those restrictions.



Best,

Mario

Thanks,

Jasdip



___

regext mailing list

regext@ietf.org<mailto:regext@ietf.org>

https://www.ietf.org/mailman/listinfo/regext

--

Dott. Mario Loffredo

Technological Unit “Digital Innovation”

Institute of Informatics and Telematics (IIT)

National Research Council (CNR)

via G. Moruzzi 1, I-56124 PISA, Italy

Phone: +39.0503153497

Web: http://www.iit.cnr.it/mario.loffredo
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 7231, but I don’t think it’s limited 
> to an invalid method. If the operative text is “the server does not support 
> the functionality required to fulfill the request”, the response can be 
> returned for *any* condition in which the server does not support the 
> functionality required to fulfill the request. It doesn’t say that “the 
> server does not support the requested method”. I still believe that 501 would 
> be the best response.
>

After rereading the text, I agree with Scott.

[JS] I think it is the second sentence in RFC 9110's description of 501 "The 
501 (Not Implemented) status code indicates that the server does not support 
the functionality required to fulfill the request. This is the appropriate 
response when the server does not recognize the request method and is not 
capable of supporting it for any resource." that probably threw us off since an 
RDAP server does recognize the GET method and could serve a subset of the REST 
endpoints (resources) for an extension. But, if we want to just go by the first 
sentence, I agree we can stick with 501.

Jasdip



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 HTTP 501 to unsupported request methods 
seems right. Not to muddle but wonder if we missed applying HTTP 501 correctly 
in RFC 9082?



That is what I meant, but perhaps 405 is the more appropriate

response. Kinda annoying that 9082 went through 2 IETF last calls and

this wasn't caught.



-andy


AFAIU, RFC 7231 states that:

- 404 must be returned to signal that the target resource is unknown to the 
server;

   The 404 (Not Found) status code indicates that the origin server did

   not find a current representation for the target resource or is not

   willing to disclose that one exists

- 405 must be returned to signal that an HTTP method is unsupported on the 
target resource but known to the server;

   The 405 (Method Not Allowed) status code indicates that the method

   received in the request-line is known by the origin server but not

   supported by the target resource

- 501 must be returned to signal that an HTTP method is unknown to the server

   The 501 (Not Implemented) status code indicates that the server does

   not support the functionality required to fulfill the request.  This

   is the appropriate response when the server does not recognize the

   request method and is not capable of supporting it for any resource.

Based on it, don't think rdap-reverse-search should add text to address these 
cases.

As I wrote in my previous reply, the document had only to define the server 
operation when the client includes in the request an unsupported reverse search 
property or combination of reverse search properties.

In this case, the server must return 400 (Bad Request).
With regard to RFC 9082, my proposal is to remove  the sentence in subject.



[JS] If the intent vis-à-vis error codes is to differentiate a feature that is 
not implemented on the server side versus a bad request for an implemented 
feature, 400 (Bad Request) does not look like a good fit for the former since 
it is not a client error when a feature is not supported. Thanks to Mario, we 
learnt 501 (Not Implemented) is also not a good fit for the former since it is 
at the HTTP method level (GET in our case). That seems to leave 405 (Method Not 
Allowed) as a viable alternative to 501 since per RFC 9110, “The 405 (Method 
Not Allowed) status code indicates that the method received in the request-line 
is known by the origin server but not supported by the target resource.” 
Irrespective, 501 looks like an errata for Section 1 in RFC 9082.



Thanks,

Jasdip
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

+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 publication as a Proposed Standard:

Registration Data Access Protocol (RDAP) Reverse Search
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/20/ 


Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 10 April 2023. Note that the WGLC has been extended by 1 
week because it is scheduled during IETF116.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Tom Harrison.

Thanks,
Antoin and Jim
REGEXT WG Co-Chairs
___
regext mailing list
regext@ietf.org 
https://www.ietf.org/mailman/listinfo/regext 




___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 
Registries/Registrars), should it not include data elements that cover the RIRs 
(Regional Internet Registries) side semantics as well? If so, including the IP 
Address and Autonomous System (AS) Number data elements would be a good start.

Further, unless the "A security principle to keep in mind as new reports are 
developed is that it is considered a bad practice to report or disclose 
security information." statement in the Security Considerations section is the 
reason why we have presently no elements related with the DNSSEC, would be good 
to include the DNSSEC related elements. EPP has a related extension mapping 
([1]), and the RIRs have related payloads in their registration APIs (e.g. [2]).

Similarly, specific to the RIRs, the registration APIs have RPKI related 
payloads (e.g. [3]). If the DNSSEC related elements are defined, would be good 
to include relevant RPKI related elements for the RIRs side.

Some minor feedback for the current content:

Section 1. Introduction: "The Registration Data Dictionary provides a common 
set of names and definitions for data element that may be used in any 
registration protocol, including the DNS." Should it be "data elements"? 
Further, should it be "including for the DNS" since DNS is itself not a 
registration protocol, AFAIK?

Section 2.13. Element name: Source & Method: Do we need to elaborate on the 
"Method" part here?

Section 2.15. Element name: Name: Since role entities exist in registries, do 
we need to expand the definition to account for a role name, or create another 
data element for it?

Section 3.1.2.1.1. Data Element Definition: Is "Name of data element type" moot 
now, per the "-02: Removed all format syntax guidance." change log? If not, the 
description for "Name of data element type" reads the same as that for "Name of 
data element"; is that intended?

Section 3.2.1. Data Element Definition in IANA Registry: Is the "This RFC 
Section 2.1." in the first "BEGIN FORM/END FORM" section intended? Further, why 
2 "BEGIN FORM/END FORM" sections?

Regards,
Jasdip

[1] https://www.rfc-editor.org/rfc/rfc5910
[2] 
https://www.arin.net/resources/manage/regrws/payloads/#delegation-key-payload
[3] 
https://www.arin.net/resources/manage/regrws/payloads/#route-origin-authorization-roa-payload


On 2/13/23, 9:03 AM, "regext on behalf of James Galvin" 
mailto:regext-boun...@ietf.org> on behalf of 
gal...@elistx.com > wrote:

This is a reminder to please indicate your support or no objection to the 
publication of this document.

The Document Shepherd should take note that the WGLC for this document was 
noted on the DNSOP mailing list. Thanks to Scott Hollenbeck for doing this and 
making it relevant for them to consider.

The WGLC is scheduled to end on Monday, 20 February 2023.

Thanks,

Antoin and Jim
REGEXT WG Co-Chairs


On 6 Feb 2023, at 9:40, James Galvin wrote:

> The document editors have indicated that the following document is ready for 
> submission to the IESG to be considered for publication as a Proposed 
> Standard:
>
> Registration Data Dictionary
> https://datatracker.ietf.org/doc/draft-ietf-regext-datadictionary/03/ 
> 
>
> Please indicate your support or no objection for the publication of this 
> document by replying to this message on list (a simple “+1” is sufficient).
>
> If any working group member has questions regarding the the publication of 
> this document please respond on the list with your concerns by close of 
> business everywhere, Monday, 20 February 2023. If there are no objections the 
> document will be submitted to the IESG.
>
> The Document Shepherd for this document is Stéphane Bortzmeyer.
>
> Thanks,
>
> Antoin and Jim
> REGEXT WG Co-Chairs


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 variable name, AFAIK?

Jasdip

[1] 
https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-11.html#name-patchobject

On 6/9/23, 11:41 AM, "Andrew Newton" mailto:a...@hxr.us>> wrote:
...
TBH, it was the JSContact patchobject that made me re-examine this
space. I don't know the requirements for CalExt, but the necessity to
implement a JSON patching framework to parse postal addresses seems to
me to be beyond what is reasonable for RDAP. James has also pointed
out several times that the JSContact UID may not be a good fit for
RDAP.
...

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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.org" , 
"regext@ietf.org" , Tom Harrison , George 
Michaelson , Andy Newton 
Subject: Re: [regext] Thoughts on the fundamental premise of JSContact


Hi Jasdip,
Il 12/06/2023 22:24, Jasdip Singh ha scritto:

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 variable name, AFAIK?

It depends on how you deserialize the JSON content. A suggestion about how to 
implement the PatchObject in Java can be derived from its definition in 
JSContact:

   A PatchObject is of type String[*], and represents an unordered set

   of patches on a JSON object. Each key is a path represented in a

   subset of JSON pointer format [RFC6901].

Terms such as "unordered se" and "key" may suggest that the use of a Java Map 
can be the way to go to implemet PatchObject. After all, since you can localize 
every JSContact value no matter if its type is primitive, an object or an array 
and if the property to localize is a standard property or an extension, it 
would be inefficient to deserialize a PatchObject in an object whose members 
are fixed in adavance.

In jscontact-tools, the "localizations" property is defined as in the following:

Map> localizations;

where JsonNode is the base class for all JSON nodes in jackson library.

Serialization/deserialization takes place straightforwardly without 
customizations.



FYI, you can find some examples of localizations handling by jscontact-tools at 
https://github.com/consiglionazionaledellericerche/jscontact-tools/blob/master/src/test/java/it/cnr/iit/jscontact/tools/test/localizations/LocalizationsTest.java
 .



Hope it could be helpful.

Yesterday I talked with Robert Stepanek and we agreed the PatchObject is more 
difficult to formally describe than to implement ;-)



Best,

Mario







Jasdip



[1] 
https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-11.html#name-patchobject



On 6/9/23, 11:41 AM, "Andrew Newton" mailto:a...@hxr.us> 
<mailto:a...@hxr.us><mailto:a...@hxr.us>> wrote:

...

TBH, it was the JSContact patchobject that made me re-examine this

space. I don't know the requirements for CalExt, but the necessity to

implement a JSON patching framework to parse postal addresses seems to

me to be beyond what is reasonable for RDAP. James has also pointed

out several times that the JSContact UID may not be a good fit for

RDAP.

...



--

Dott. Mario Loffredo

Technological Unit “Digital Innovation”

Institute of Informatics and Telematics (IIT)

National Research Council (CNR)

via G. Moruzzi 1, I-56124 PISA, Italy

Phone: +39.0503153497

Web: http://www.iit.cnr.it/mario.loffredo
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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, given it may not survive a redirect?

Not really. Too much hassle and complexity just to support a de facto non RDAP 
client. RDAP clients will know how to send headers. Web apps running in browser 
can do it as well.

[JS] Glad to know. :)

Jasdip



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 opinion about how relevant is making an RDAP server
> easily accessible by a web browser.

[SAH] It's important to support *all* types of clients if possible. Anything 
less can lead to inconsistent user experiences, and that's bad for RDAP's 
long-term viability.

[JS] Agreed. As long as we are talking HTTPS between clients and servers, be it 
browser-based interaction or otherwise, the "application/rdap-x+json" media 
type should work fine for negotiating RDAP extensions (most of the time content 
types or profiles, and sometime the lack of a particular content type (for 
example, noJCard extension)) using AFAIK well-known, well-implemented, and 
interoperable HTTP Accept and Content-Type headers. And it would afford us the 
granularity to negotiate content at each HTTP request/response level. Even a 
preflight HTTP OPTIONS request could be leverage for this media-type if needed.

Thanks,
Jasdip






___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 like to know
>> the current WG's opinion about how relevant is making an RDAP server
>> easily accessible by a web browser.
> [SAH] It's important to support *all* types of clients if possible. Anything 
> less can lead to inconsistent user experiences, and that's bad for RDAP's 
> long-term viability.

[PK] if usage of only web browser is concerned, it would likely never 
support application/rdap-x+json out of the box and send appropriate 
headers with the request. Maybe with an extension, then not being a pure 
browser anymore, but more a dedicated RDAP client.

An end user just operating the web browser won't be able to set 
arbitrary http headers. Query parameters would be possible, but are not 
considered by the authors (Appendix A.2).

So the choice is between not supporting pure web browser as a client 
with this method, or allow for alternative with query parameters on top 
of http headers (a bit like http-equiv but for request rather than for 
response).

[JS] This is a fair point, Pawel. Would you suggest considering the latter 
method (query parameters) as well, given it may not survive a redirect?

Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 in an RDAP response has not been considered an issue so far even
> in case of handling large amounts of data. Most of us (not me) have
> considered too complex for both clients and servers to imlement the
> negotiation of the contact representation to be returned in the
> response. In addition, in this case, the negotiation is made through
> two extension identifiers while in rdap-jscontact setting the jscard
> parameter to 1/true means that jCard is not returned.

For most lookups, returning both will not matter much. However, for
searches yielding many more than one result it could be a definite
bandwidth savings.
The implementation would most likely be up to server policy on the server side.

[JS] Mario, sorry if I sound a bit biased here but IMO using the "noJCard" 
extension along with the RDAP-X based content negotiation looks like a rather 
neat idea whether used for Simple Contact or JSContact. It avoids the query 
parameter-based issues when negotiating content, as explained in the RDAP-X 
draft.

Jasdip

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 have partial value and 
replacement methods as well?

Section 3:

"The redaction of RDAP fields fall into the three categories defined in the 
following sub-sections." ... Should it not be four categories now?

Section 3.1:

"The Redaction by Removal Method is when the RDAP field is removed from the 
RDAP response, which is the preferred method." ... Why is it preferred? It just 
happens to be for optional fields’ redaction, no? As-is, it seems to connote: 
prefer redacting optional fields. Perhaps "default method" is a better phrase 
than "preferred method".

Section 3.2:

"The Redaction by Empty Value Method is when a redacted field is not removed, 
but its value is set to an empty value, such as "" for a jCard [RFC7095] Text 
("text") property or null for a non-Text property." ... Found "null for a 
non-Text property" to be a bit confusing given a string JSON type can also be 
set to null, AFAIK.

"The Redaction by Empty Value Method SHOULD be used only when redacting JSON 
response fields that use the position in an array to signal the redacted field" 
… Why just that? Why not for a required field that needs to be emptied (instead 
of a non-empty replacement) for redaction?

Section 4.2:

"The "redacted" member is included as a member of the object class in a lookup 
response, such as the object classes defined in [RFC9083], and as a member of 
the object instances in a search response, such as the object instances defined 
in [RFC9083]." ...  Found the "object class" and "object instance" use a bit 
confusing here. Would it be better to say: "The "redacted" member is included 
as a member of the object instance in a lookup response, for the object classes 
defined in [RFC9083], and as a member of the array of object instances in a 
search response."?

"name" ... Is it a REQUIRED member of a child object of the "redacted" array? 
Is so, good to mark it as REQUIRED given we mark other fields as OPTIONAL.

"pathLang" … Knowing JSONPath is the only query expression lang mentioned in 
this draft, wonder if some folks would ask why JSONPointer [1] was not chosen 
as a pathLang, or if it could be a pathLang? Do we want to provide any 
guidance/clarification via-a-vis JSONPointer?

"method" ... "The default value is "removal" when not provided." ... Why not 
always provide "method" (read: no default) in order to avoid confusion 
vis-a-vis other fields in a child object of the "redacted" array? Apparently 
there is not much space optimization to be gained by not setting this field. If 
so, we can do away with the "which is the preferred method" phrase in section 
3.1.

Thanks,
Jasdip

[1] https://www.rfc-editor.org/rfc/rfc6901








___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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: Re: [regext] [EXTERNAL] Re: jCard to JSContact transition

Hello Mario,

No worry. :)

Firstly, thank you for sharing this analysis. The JSContact versus jCard size 
comparison is particularly interesting, and kinda expected given the map versus 
the jagged arrays respectively for them.

Though one could appreciate the rationale for using query parameters for 
reduced response sizes, as well as a graceful API sunset mechanism for retiring 
jCard, IMO the simplicity of implementing option 3 (both jCard and JSContact in 
a response for some time) is still a good tradeoff for increased response size. 
Given both jCard and JSContact are optional 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 
Cc: Marc Blanchet , "regext@ietf.org" 

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

Hi Jasdip and others,

I strongly apologize for replying to this post with big delay but I have been 
very busy with JSContact and reverse search docs and other business from .it.

After having concluded the discussion on how to redact the uid property, would 
like to resume and finalize the discussion on this topic.

As I promised, have made some tests to estimate the size increase of the RDAP 
response when JSContact is returned along with jCard.

Think it could be helpful to have a comprehensive overview.

For the sake of obtaining an accurate measure, I purged the responses of 
notices, remarks and extensions and compacted the JSON content to exclude 
unnecessary characters (i.e. spaces, nelines) from the bytes count.

First I found out that jscard is twice as big as jcard on average. In .it RDAP 
responses, the size of a jscard is a about 800 bytes whilst jcard is about 400 
bytes long.
This shouldn't sound weird. In fact, as opposed to JSContact, jCard doesn't 
include the property names because basically it's a JSON transliteration of a 
positional notation.

I could not test other RDAP servers implementing JSContact but I don't think 
the results would be much different since in general RDAP makes use of the same 
subset of JSContact data.

Then I took a domain with five contacts (i.e. one registrant, one admin and 
three techs) which  corresponds to a common .it case.
The response including only jCard was long about 3,5 Kb. This means that 
providing both the formats together makes the RDAP response larger more than 
twice.

Maybe the size increment can't be a concern but I'm still convinced that it 
would sound pretty unusual to the client to get more than twice the response as 
before without negotiation.

What do you think ?

Best,

Mario
Il 04/04/2023 00:18, Jasdip Singh ha scritto:
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 server could simply 
send back a notice as to when jCard would be sunset from its side. As was 
mentioned previously, agree that a server couldn’t definitively measure when 
the client demand for jCard goes to zero by looking at the proposed query 
parameters. Instead, the server would decide unilaterally with sufficient 
forewarning to clients.
Jasdip
From: regext <mailto:regext-boun...@ietf.org> on 
behalf of Mario Loffredo 
<mailto:mario.loffr...@iit.cnr.it>
Date: Monday, April 3, 2023 at 5:32 AM
To: Rick Wilhelm <mailto:rwilh...@pir.org>, Andy Newton 
<mailto:a...@hxr.us>
Cc: Marc Blanchet 
<mailto:marc.blanc...@viagenie.ca>, 
"regext@ietf.org"<mailto:regext@ietf.org> 
<mailto:regext@ietf.org>
Subject: Re: [regext] [EXTERNAL] Re: jCard to JSContact transition

Hi Rick,

please find my comments below.
Il 01/04/2023 03:03, Rick Wilhelm ha scritto:
I think that I’m leaning towards Andy’s approach, but I haven’t soak this 
thinking for very long.
Perhaps it’s useful to go back to one of the original motivations for the draft.
As I recall, programmers, especially client-side, have been known to have 
difficulty with JCard (for various reasons).
Therefore, a “more modern” approach using JSContact is being proposed.
So… A server presently has to support JCard and theoretically MAY support 
JSContact.
If a client encounters such a server, and detects that the server supports 
JSContact, then it would be able to reliably ignor

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

[Jasdip Singh]

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, one 
question to ask would be: Would it be short-sighted in precluding future user 
cases for entities in other registries (say, RDAP use for space related 
registration data)?

Jasdip

On 6/8/23, 8:52 AM, "regext on behalf of Hollenbeck, Scott" 
mailto:regext-boun...@ietf.org> on behalf of 
shollenbeck=40verisign@dmarc.ietf.org 
> wrote:


I kinda prefer option A, too. Anything we can do to make this easier will be 
time well spent.


Scott


> -Original Message-
> From: regext mailto:regext-boun...@ietf.org>> On 
> Behalf Of Gould, James
> Sent: Thursday, June 8, 2023 8:14 AM
> To: a...@hxr.us ; regext@ietf.org 
> Subject: [EXTERNAL] Re: [regext] Thoughts on the fundamental premise of
> JSContact
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content is
> safe.
>
> Andy,
>
> I believe creating a simple RDAP extension for contacts (Path-forward #A) is
> best. jCard and JSContact are much more generic and complex than what is
> needed. The mandatory UID field of JSContact is a perfect example of how the
> intended purpose of JSContact does not meet the needs of RDAP. For EPP there
> is a EPP Contact Mapping in RFC 5733 that doesn't carry any extra weight of a
> more general-purpose contact / address book XML representation. The JSON
> should be straight forward to process in RDAP. The RDAP Contact Extension
> can directly support the contact information contained in the EPP Contact
> Mapping along with additional features needed for the RIRs, without the need
> for added bloat and complexity of a general-purpose contact representation.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com  
>  B4BA42740803/jgo...@verisign.com >
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com  web.cisco.com/1AQ0PwiCZE6GyMJuDkvNZnO7kEZE7QUyFQUzzJhALD20VD5mP
> LMPQVlYIIvBIYT_gftye4v7KQKeOO1_wLBqvq7ejTHY4Y3vvgQdSoSvxGPczxeWuT
> tDEgMXtZrVDpqR9w-
> VyCV_B69qpyQvw7n8VTFxlB8S5lDMFs4BfxRE792dYJXe0ODoKoqfI29wzIvFaM1g
> MbPg_pnhWZY2bWx5MG9eXTFg4Z8LrFVvdjjoDUALhmEbdDBHkKuByQL4GG3Sh
> NvsoadHyeSw9BOlVrC0sJOVr1yxxUvwA4_3mkAVUeIQ/http%3A%2F%2Fverisigni
> nc.com%2F>
>
>
>
>
> On 6/7/23, 2:26 PM, "regext on behalf of Andrew Newton"  boun...@ietf.org   > on behalf of a...@hxr.us 
> 
> >> wrote:
>
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content is
> safe.
>
>
> Hi All,
>
>
> Very recently I have had the displeasure of implementing jCard for an RDAP
> client, and in so doing have taken a closer look at JSContact and have talked 
> to
> a few people privately about it. Both I and they believed that JSContact would
> be much better than jCard. However, after looking at the JSContact spec, I 
> don’t
> believe it is better and in some ways it is far more problematic. Therefore, I
> want to share my thoughts for discussion purposes.
>
>
> #1 JSContact uses JSON objects and is therefore better than jCard.
>
>
> Both I and a few people with whom I have discussed this issue have held this
> thought. It is true that JSContact uses JSON objects instead of the nested 
> arrays
> found in jCard, but it does not use them in a way that makes JSContact easier 
> to
> handle. Let me explain.
>
>
> Most of RDAP is straightforward JSON as would be found in very typical REST
> APIs. This makes serializing and deserializing JSON to and from data 
> structures
> easy in most programming languages using well-known toolkits. I offer the
> following Java example, but these things exist in most programming languages:
>
>
> public class Link {
> private String href;
> private String value;
> @JsonProperty("type")
> private String mediaType;
> }
>
>
> Here, an RDAP link structure is represented. Some of the properties can be
> automatically serialized/deserialized and others are easy to use with simple
> annotations.
>
>
> By contrast, JSContact JSON objects are much more than simple JSON objects
> as found in RDAP. Here is an example of JSContact person
> titles:
>
>
> "titles": {
> "le9": {
> "kind": "title",
> "name": "Research Scientist"
> },
> "k2": {
> "kind": "role",
> "name": "Project Leader"
> }
> }
>
>
> What should be an array of strings (e.g. “List titles”) is instead an
> object of 

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

[Jasdip Singh]

Hello Mario,

Your answer made my day! :) I'm still LOL about your "it wouldn't be 
short-sighted but completely blind" point. Yah, good to think this through 
before we as a WG take the next step. I recall one of the laws of simplicity 
[1]: law 9 which says that some things can never be made simple. May be, 
JSContact falls into that category. Trusting that the CalExt WG thought through 
about not unnecessarily introducing implementation complexity for JSContact.

Regards,
Jasdip

[1] http://lawsofsimplicity.com/

On 6/9/23, 5:02 AM, "Mario Loffredo" mailto:mario.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 number object classes that are specific to 
> these registries' business. However, before abandoning the JSContact effort, 
> one question to ask would be: Would it be short-sighted in precluding future 
> user cases for entities in other registries (say, RDAP use for space related 
> registration data)?
>
> Jasdip

[ML] Would like to answer your question trying at the same time to recap 
the reasons why 3 years ago we didn't bring on Gavin's proposal about "a 
straight mapping of RFC5733 contact objects into JSON".

I remember that at ROW 2019 George Michaelson from APNIC gave a 
presentation 
(https://regiops.net/wp-content/uploads/2019/05/ROW8-RDAPPanel-In-defence-of-jCard%E2%80%99s-goals-George-Michaelson.pdf
 
<https://regiops.net/wp-content/uploads/2019/05/ROW8-RDAPPanel-In-defence-of-jCard%E2%80%99s-goals-George-Michaelson.pdf>)
 
about which requirements a contact representation aiming to replace 
jCard was supposed to meet according to his experience.

In that circumstance, it was clear to everyone that the EPP contact 
representation was pretty unfit to handle non-western registry data in 
general.

Think that hopefully all of those requirements are matched by JSContact 
(e.g. we have recently updated the spec to better model non-western 
addresses but the work is still ongoing).

Tom and George, can you please say your word on this matter ?

Definitively, I believe that embracing the proposal of a contact data 
format based on RFC 5733 would be a huge step backwards in facing this 
problem.

Jasdip, answering your question, I would say that it wouldn't be 
short-sighted but completely blind :-)

Best,

Mario

>
> On 6/8/23, 8:52 AM, "regext on behalf of Hollenbeck, Scott" 
> mailto:regext-boun...@ietf.org> 
> <mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>> on behalf 
> of shollenbeck=40verisign@dmarc.ietf.org 
> <mailto:40verisign@dmarc.ietf.org> <mailto:40verisign@dmarc.ietf.org 
> <mailto:40verisign@dmarc.ietf.org>>> wrote:
>
> I kinda prefer option A, too. Anything we can do to make this easier will be 
> time well spent.
>
> Scott
>
>> -Original Message-
>> From: regext mailto:regext-boun...@ietf.org> 
>> <mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>>> On Behalf 
>> Of Gould, James
>> Sent: Thursday, June 8, 2023 8:14 AM
>> To: a...@hxr.us <mailto:a...@hxr.us> <mailto:a...@hxr.us 
>> <mailto:a...@hxr.us>>; regext@ietf.org <mailto:regext@ietf.org> 
>> <mailto:regext@ietf.org <mailto:regext@ietf.org>>
>> Subject: [EXTERNAL] Re: [regext] Thoughts on the fundamental premise of
>> JSContact
>>
>> Caution: This email originated from outside the organization. Do not click 
>> links
>> or open attachments unless you recognize the sender and know the content is
>> safe.
>>
>> Andy,
>>
>> I believe creating a simple RDAP extension for contacts (Path-forward #A) is
>> best. jCard and JSContact are much more generic and complex than what is
>> needed. The mandatory UID field of JSContact is a perfect example of how the
>> intended purpose of JSContact does not meet the needs of RDAP. For EPP there
>> is a EPP Contact Mapping in RFC 5733 that doesn't carry any extra weight of a
>> more general-purpose contact / address book XML representation. The JSON
>> should be straight forward to process in RDAP. The RDAP Contact Extension
>> can directly support the contact information contained in the EPP Contact
>> Mapping along with additional features needed for the RIRs, without the need
>> for added bloat and complexity of a general-purpose contact representation.
>>
>> --
>>
>> JG
>>
>> James Gould
>> Fellow Engineer
>> jgo...@verisign.com <mailto:jgo...@verisign.com> <mailto

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

[Jasdip Singh]

Hello Mario,

No worry. :)

Firstly, thank you for sharing this analysis. The JSContact versus jCard size 
comparison is particularly interesting, and kinda expected given the map versus 
the jagged arrays respectively for them.

Though one could appreciate the rationale for using query parameters for 
reduced response sizes, as well as a graceful API sunset mechanism for retiring 
jCard, IMO the simplicity of implementing option 3 (both jCard and JSContact in 
a response for some time) is still a good tradeoff for increased response size. 
Given both jCard and JSContact are optional 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 
Cc: Marc Blanchet , "regext@ietf.org" 

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

Hi Jasdip and others,

I strongly apologize for replying to this post with big delay but I have been 
very busy with JSContact and reverse search docs and other business from .it.

After having concluded the discussion on how to redact the uid property, would 
like to resume and finalize the discussion on this topic.

As I promised, have made some tests to estimate the size increase of the RDAP 
response when JSContact is returned along with jCard.

Think it could be helpful to have a comprehensive overview.

For the sake of obtaining an accurate measure, I purged the responses of 
notices, remarks and extensions and compacted the JSON content to exclude 
unnecessary characters (i.e. spaces, nelines) from the bytes count.

First I found out that jscard is twice as big as jcard on average. In .it RDAP 
responses, the size of a jscard is a about 800 bytes whilst jcard is about 400 
bytes long.
This shouldn't sound weird. In fact, as opposed to JSContact, jCard doesn't 
include the property names because basically it's a JSON transliteration of a 
positional notation.

I could not test other RDAP servers implementing JSContact but I don't think 
the results would be much different since in general RDAP makes use of the same 
subset of JSContact data.

Then I took a domain with five contacts (i.e. one registrant, one admin and 
three techs) which  corresponds to a common .it case.
The response including only jCard was long about 3,5 Kb. This means that 
providing both the formats together makes the RDAP response larger more than 
twice.

Maybe the size increment can't be a concern but I'm still convinced that it 
would sound pretty unusual to the client to get more than twice the response as 
before without negotiation.

What do you think ?

Best,

Mario
Il 04/04/2023 00:18, Jasdip Singh ha scritto:
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 server could simply 
send back a notice as to when jCard would be sunset from its side. As was 
mentioned previously, agree that a server couldn’t definitively measure when 
the client demand for jCard goes to zero by looking at the proposed query 
parameters. Instead, the server would decide unilaterally with sufficient 
forewarning to clients.
Jasdip
From: regext <mailto:regext-boun...@ietf.org> on 
behalf of Mario Loffredo 
<mailto:mario.loffr...@iit.cnr.it>
Date: Monday, April 3, 2023 at 5:32 AM
To: Rick Wilhelm <mailto:rwilh...@pir.org>, Andy Newton 
<mailto:a...@hxr.us>
Cc: Marc Blanchet 
<mailto:marc.blanc...@viagenie.ca>, 
"regext@ietf.org"<mailto:regext@ietf.org> 
<mailto:regext@ietf.org>
Subject: Re: [regext] [EXTERNAL] Re: jCard to JSContact transition

Hi Rick,

please find my comments below.
Il 01/04/2023 03:03, Rick Wilhelm ha scritto:
I think that I’m leaning towards Andy’s approach, but I haven’t soak this 
thinking for very long.
Perhaps it’s useful to go back to one of the original motivations for the draft.
As I recall, programmers, especially client-side, have been known to have 
difficulty with JCard (for various reasons).
Therefore, a “more modern” approach using JSContact is being proposed.
So… A server presently has to support JCard and theoretically MAY support 
JSContact.
If a client encounters such a server, and detects that the server supports 
JSContact, then it would be able to reliably ignore the JCard that is returned 
and instead use code that parses JSContact and be on its merry way.
A key difference between Mario’s (2) and Andy(3) is basically a negotiation 
step.  While I understand the benefit of “smaller response” proposed by (2), it 
seems that the negotiation step (with its round trips) would overwhelm that.  
And perhaps lead to 

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

[Jasdip Singh]

Hi.

The RFC 9092 Update [1] hints at using RDAP for accessing the IP geolocation 
feed data through the remarks (comments) field (beside how to access it through 
IRR). Tom and I worked on defining a proper new RDAP extension for geofeed data 
to afford us a purposed RDAP field for it. We did a preview of this work with 
the RFC 9092 authors, and it was well-received. We intend presenting it in 
regext at the next IETF and would appreciate your feedback whenever convenient.
 
Thanks,
Jasdip

[1] https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/

On 7/29/23, 3:55 PM, "internet-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-geofeed
Revision: 00
Title: An RDAP Extension for Geofeed Data
Document date: 2023-07-29
Group: Individual Submission
Pages: 5
URL: https://www.ietf.org/archive/id/draft-jasdips-regext-rdap-geofeed-00.txt 
<https://www.ietf.org/archive/id/draft-jasdips-regext-rdap-geofeed-00.txt>
Status: https://datatracker.ietf.org/doc/draft-jasdips-regext-rdap-geofeed/ 
<https://datatracker.ietf.org/doc/draft-jasdips-regext-rdap-geofeed/>
Html: https://www.ietf.org/archive/id/draft-jasdips-regext-rdap-geofeed-00.html 
<https://www.ietf.org/archive/id/draft-jasdips-regext-rdap-geofeed-00.html>
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-jasdips-regext-rdap-geofeed 
<https://datatracker.ietf.org/doc/html/draft-jasdips-regext-rdap-geofeed>

Abstract:
This document defines a new RDAP extension geofeedv1 for including a
geofeed file URL in an IP Network object.


The IETF Secretariat







___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 of 
a...@hxr.us > wrote:
On Mon, Jun 26, 2023 at 9:49 AM James Galvin mailto:gal...@elistx.com>> wrote:
> The Chairs would also like to note that given the new discussion regarding 
> jCard vs jsContact vs SimpleContact, that we will be delaying the actual 
> submission of this document to the IESG until that discussion resolves. It 
> seems prudent to make sure there is no impact to the “redacted” document as a 
> result of the format discussion before we submit it to the IESG.

I appreciate the prudence, and practically it may not matter if
submission to the IESG is delayed given the dependency on JSONPath and
IESG workload. That said, I do not believe this is necessary. Let me
explain.

Much of the complexity in the RDAP redaction spec has to do with
getting around weird things in jCard, but as Marc has pointed out,
jCard will be with us for the foreseeable future. Though I strongly
suspect redaction will be easier with a theoretical SimpleContact, it
could be quite some time before we know that. And the RDAP redaction
spec covers more than contact data, so it is useful outside of the
contact data discussions.

The complications with redaction with regard to JSContact center
around client processing of JSContact patch objects before, after or
during client processing of the redaction directives. This is
something the JSContact drafts could specify without need to modify
the RDAP redaction, IMHO. I believe the UID issue has been resolved.
Finally, JSContact may take some time to get to the publication point
considering its dependency.

That's my opinion. Maybe others see it differently.

-andy

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

+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 for publication as a Proposed Standard:

Federated Authentication for the Registration Data Access Protocol (RDAP) using 
OpenID Connect
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/ 


Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 10 July 2023.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Zaid AlBanna.

Thanks,

Jim and Antoin
REGEXT WG Co-Chairs

___
regext mailing list
regext@ietf.org 
https://www.ietf.org/mailman/listinfo/regext 




___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

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 incomplete, now that we have partial value and 
replacement methods as well?

JG - Yes, you are correct that this sentence is now incomplete. How about the 
following:

"The redacted JSON fields will either be removed, have empty values, have 
partial values, or be replaced in the RDAP response."

Section 3:

"The redaction of RDAP fields fall into the three categories defined in the 
following sub-sections." ... Should it not be four categories now?

JG - Yes, you are correct there are four categories, so it should read "The 
redaction of RDAP fields fall into the four categories defined in the following 
sub-sections." 

Section 3.1:

"The Redaction by Removal Method is when the RDAP field is removed from the 
RDAP response, which is the preferred method." ... Why is it preferred? It just 
happens to be for optional fields’ redaction, no? As-is, it seems to connote: 
prefer redacting optional fields. Perhaps "default method" is a better phrase 
than "preferred method".

JG - I believe the preferred language was based on comparison to the empty 
value method, but it is the default (and most common) redaction method. We can 
replace ", which is the preferred method" with ", which is the default method" 
to correctly reflect it as the default method instead of the preferred method. 
The sentence would be "The Redaction by Removal Method is when the RDAP field 
is removed from the RDAP response, which is the default method". This will 
match what is indicated for the "method" member in section 4.2. 

Section 3.2:

"The Redaction by Empty Value Method is when a redacted field is not removed, 
but its value is set to an empty value, such as "" for a jCard [RFC7095] Text 
("text") property or null for a non-Text property." ... Found "null for a 
non-Text property" to be a bit confusing given a string JSON type can also be 
set to null, AFAIK.


JG - That same language was brought up my Mario with my response in the mail 
message 
https://mailarchive.ietf.org/arch/msg/regext/-TpQ9tS_PN5d9IqMcg4Ke6-ZNq4/. The 

 empty string can be used for redaction of a jCard Text ("text") property, but 
the other jCard types that are mapped to JSON strings include additional format 
requirements that would not be met with an empty string, which is the reason 
why null is used for non-Text ("text") properties. I believe it's important to 
clarify what to do for redaction with Text and non-Text jCard properties. A 
jCard Text ("text") property is redacted using an empty string. 

"The Redaction by Empty Value Method SHOULD be used only when redacting JSON 
response fields that use the position in an array to signal the redacted field" 
… Why just that? Why not for a required field that needs to be emptied (instead 
of a non-empty replacement) for redaction?

JG - We added the Redaction by Empty Value Method specifically to address the 
issues of redaction with jCard. The SHOULD reflects the intent of the redaction 
method and it's not defined as a MUST to cover corner cases such as an RDAP 
member that needs to be redacted being defined as required. I hope that future 
RDAP extensions don't overuse required members causing an issue for redaction. 

Section 4.2:

"The "redacted" member is included as a member of the object class in a lookup 
response, such as the object classes defined in [RFC9083], and as a member of 
the object instances in a search response, such as the object instances defined 
in [RFC9083]." ... Found the "object class" and "object instance" use a bit 
confusing here. Would it be better to say: "The "redacted" member is included 
as a member of the object instance in a lookup response, for the object classes 
defined in [RFC9083], and as a member of the array of object instances in a 
search response."?

JG - Yes, that sounds better. The second sentence would then read ""The 
"redacted" member is included as a member of the object instance in a lookup 
response, for the object classes defined in [RFC9083], and as a member of the 
array of object instances in a search response.".

"name" ... Is it a REQUIRED member of a child object of the "redacted" array? 
Is so, good to mark it as REQUIRED given we mark other fields as OPTIONAL.

JG - The members are required by default, but there is no problem being 
explicit for the "name" member with "REQUIRED logical name for the redacted 
field". The change will be made.

"pathLang" … Knowing JSONPath is the only query expression lang mentioned in 
this draft, wonder if some folks would ask why JSONPointer [1] was not chosen 
as a pathLang, or if it could be a pathLang? Do we want to provide any 

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

[Jasdip Singh]

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@dmarc.ietf.org" , 
"regext@ietf.org" , Tom Harrison , George 
Michaelson , Andy Newton 
Subject: Re: [regext] Thoughts on the fundamental premise of JSContact


Hi Jasdip,
Il 13/06/2023 16:01, Jasdip Singh ha scritto:
Cool, so looks like the Jackson library affords a seamless way to deal with 
JSPointer’s as keys. Thanks for pointing to that test.

It's not a feature provided only by Jackson library. As I wrote in my previous 
reply, it all depends on the object of the programming language you want the 
JSON content to be deserialized into/serialized from.

If you need to deserialize a JSON object into an instance of a Java class, you 
can:

-  use the basic features provided by your JSON library if all of the member 
names in the JSON object are already valid in Java;

- customize the deserialization to obtain valid Java member names.  
Customization can be accomplished through commonly provided methods such as 
using annotations, overriding the basic deserialization methods, and others.

With regard to my implementation of PatchObject, a Java map key can contain a 
JSONPointer expression so it's an example of the first use case.
An example of the second use case is the handling of the JSContact @type and 
@version properties: their names are not valid in Java but can easily be turned 
into valid ones by using the Jackson @JsonProperty annotation (see the 
following excerpt from the Card class)

@NotNull

@JsonProperty("@version")

@VersionValueConstraint

@Builder.Default

String _version = "1.0";



Best,

Mario



Jasdip

From: Mario Loffredo 
<mailto:mario.loffr...@iit.cnr.it>
Date: Tuesday, June 13, 2023 at 4:30 AM
To: Jasdip Singh <mailto:jasd...@arin.net>
Cc: "Hollenbeck, Scott" 
<mailto:shollenbeck=40verisign@dmarc.ietf.org>,
 
"jgould=40verisign@dmarc.ietf.org"<mailto:jgould=40verisign@dmarc.ietf.org>
 
<mailto:jgould=40verisign@dmarc.ietf.org>,
 "regext@ietf.org"<mailto:regext@ietf.org> 
<mailto:regext@ietf.org>, Tom Harrison 
<mailto:t...@apnic.net>, George Michaelson 
<mailto:g...@algebras.org>, Andy Newton 
<mailto:a...@hxr.us>
Subject: Re: [regext] Thoughts on the fundamental premise of JSContact


Hi Jasdip,
Il 12/06/2023 22:24, Jasdip Singh ha scritto:

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 variable name, AFAIK?

It depends on how you deserialize the JSON content. A suggestion about how to 
implement the PatchObject in Java can be derived from its definition in 
JSContact:

   A PatchObject is of type String[*], and represents an unordered set

   of patches on a JSON object. Each key is a path represented in a

   subset of JSON pointer format [RFC6901].

Terms such as "unordered se" and "key" may suggest that the use of a Java Map 
can be the way to go to implemet PatchObject. After all, since you can localize 
every JSContact value no matter if its type is primitive, an object or an array 
and if the property to localize is a standard property or an extension, it 
would be inefficient to deserialize a PatchObject in an object whose members 
are fixed in adavance.

In jscontact-tools, the "localizations" property is defined as in the following:

Map> localizations;

where JsonNode is the base class for all JSON nodes in jackson library.

Serialization/deserialization takes place straightforwardly without 
customizations.



FYI, you can find some examples of localizations handling by jscontact-tools at 
https://github.com/consiglionazionaledellericerche/jscontact-tools/blob/master/src/test/java/it/cnr/iit/jscontact/tools/test/localizations/LocalizationsTest.java
 .



Hope it could be helpful.

Yesterday I talked with Robert Stepanek and we agreed the PatchObject is more 
difficult to formally describe than to implement ;-)



Best,

Mario







Jasdip



[1] 
https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-11.html#name-patchobject



On 6/9/23, 11:41 AM, "Andrew Newton" mailto:a...@hxr.us> 
<mailto:a...@hxr.us><mailto:a...@hxr.us>> wrote:

...

TBH, it was the JSContact patchobject that made me re-examine this

space. I don't know the requirements for CalExt, but the necessity to

implement a JSON patching framework to parse postal addresses seems to

me to be beyond what is reasonable for RDAP. James has also pointed

out several 

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

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

[Jasdip Singh]

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",
  "ips", "ipSearchResults", ... ],
  ...
  "ipSearchResults": [
{
  "objectClassName": "ip network",
  "handle": "-RIR",
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.127",
  ...
  "links": [
...,
   {
 "value": "https://rdap.example.com/ip/192.0.2.0/25;,
 "rel": "up",
 "href": "https://rdap.example.com/ips/rirSearch1/up/192.0.2.0/25;,
 "type": "application/rdap+json"
  },
   {
 "value": "https://rdap.example.com/ip/192.0.2.0/25;,
 "rel": "down",
 "href": "https://rdap.example.com/ips/rirSearch1/down/192.0.2.0/25;,
 "type": "application/rdap+json"
   },
  {
 "value": "https://rdap.example.com/ip/192.0.2.0/25;,
 "rel": "top",
 "href": "https://rdap.example.com/ips/rirSearch1/top/192.0.2.0/25;,
 "type": "application/rdap+json"
   },
   {
 "value": "https://rdap.example.com/ip/192.0.2.0/25;,
 "rel": "bottom",
 "href": "https://rdap.example.com/ips/rirSearch1/bottom/192.0.2.0/25;,
 "type": "application/rdap+json"
  }
 ]
},
{
  "objectClassName": "ip network",
  "handle": "-RIR",
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.255",
  ...
}
  ]
}

Though the specification defines 5 extension identifiers (“rirSearch1 “, “ips”, 
“ipSearchResults”, “autnum”, and “autnumSearchResults”), note how the example 
only includes “rirSearch1 “, “ips”, and “ipSearchResults”:

  *   “ipSearchResults” for the "ipSearchResults" member.
  *   “ips” and “rirSearch1“ for the construction of the “href” values in the 
“links” member of an IP network object for link relations.

IMO, this presently points to Option 2 from the choices Mario posed for the WG. 
Per the “construction of response” guidance from RFC 9083, is that OK in your 
opinion?

Jasdip

From: regext  on behalf of Hollenbeck, Scott 

Date: Tuesday, February 20, 2024 at 12:31 PM
To: a...@hxr.us 
Cc: i...@antoin.nl , mario.loffr...@iit.cnr.it 
, regext@ietf.org 
Subject: Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
Andy, I agree that that's an incorrect interpretation. Content is part of the 
response, too, and as such it has to be included when the response is 
constructed/formed/assembled/whatever.

Scott

> -Original Message-
> From: Andrew Newton (andy) 
> Sent: Tuesday, February 20, 2024 12:23 PM
> To: Hollenbeck, Scott 
> Cc: ietf=40antoin...@dmarc.ietf.org ;
> mario.loffredo=40iit.cnr...@dmarc.ietf.org ;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-
> search
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content is
> safe.
>
> "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.
>
> -andy
>
>
> On Tue, Feb 20, 2024 at 10:20 AM Hollenbeck, Scott
>  wrote:
> >
> > I don’t understand the confusion regarding the text in 9083. It might not
> include BCP 14 key words, but I believe the intention is clear. Looking at the
> two sentences:
> >
> >
> >
> > “A response to a "help" request will include identifiers for all of the
> specifications supported by the server.”
> >
> >
> >
> > *will include* isn’t a BCP 14 MUST, but I don’t think it’s ambiguous.
> >
> >
> >
> > “A response to any other request will include only identifiers for the
> specifications used in the construction of the response.”
> >
> >
> >
> > Similarly, *will include only identifiers for the specifications used in the
> construction of the response* describes the identifiers that are to be 
> included
> in any other response. If a client needs to implement something other than
> 9083 to correctly interpret and process a response, any identifier that
> describes a specification that’s needed to “understand” the response will be
> included. If that’s not clear, what am I missing?
> >
> >
> >
> > Scott
> >
> >
> >
> > From: regext  On Behalf Of Antoin Verschuren
> > Sent: Monday, February 19, 2024 10:42 AM
> > To: Mario Loffredo 
> > Cc: regext 
> > Subject: [EXTERNAL] Re: [regext] WG LAST CALL
> > draft-ietf-regext-rdap-rir-search
> >
> >
> >
> > Caution: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> >
> > So, if I 

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

[Jasdip Singh]

+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 draft adoption

Agreed.

Mario
Il 11/12/2023 15:24, Gould, James ha scritto:
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-media-type. 
 I highlight them below to prime the discussion:


  1.  draft-newton-regext-rdap-extensions – Provide clarification of the 
creation of RDAP extensions, where we can address much of the clarification 
issues that we’ve struggled with on the mailing list.
  2.  draft-newton-regext-rdap-x-media-type – Provide an alternative mechanism 
to the use of a query parameter that does not pose an issue with RDAP 
redirection servers.
  3.  draft-gould-regext-rdap-versioning – Provide support for an extensible 
set of RDAP extension versioning types with Opaque Versioning and Semantic 
Versioning initially defined that will work in unison with 
draft-newton-regext-rdap-extensions and draft-newton-regext-rdap-x-media-type.

Thanks for catching up on the thread and setting up an interim meeting.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <mailto:regext-boun...@ietf.org> on 
behalf of James Galvin <mailto:gal...@elistx.com>
Date: Monday, December 11, 2023 at 9:09 AM
To: Jasdip Singh <mailto:jasd...@arin.net>
Cc: "regext-cha...@ietf.org"<mailto:regext-cha...@ietf.org> 
<mailto:regext-cha...@ietf.org>, 
"regext@ietf.org"<mailto:regext@ietf.org> 
<mailto:regext@ietf.org>, Andy Newton 
<mailto:a...@hxr.us>
Subject: [EXTERNAL] [regext] ACTION REQUESTED: Re: RDAP-X draft adoption


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


The Chairs have caught up on this thread and have the following proposal for 
the working group

We suggest that the working group take on the problem space of considering 
negotiation, signaling, and versioning in RDAP.

To properly consider this problem space we should adopt as working group 
documents the following three drafts, all of which address at least part of 
this problem space:

https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/<https://secure-web.cisco.com/1QCHC-8xG9hJOoNbDI71pTXPcfNXNxXahQ0yAk0Kh8n3TXFaZLQfStyi73ETpLrp_VAHHTyrIcEJ1weZ5qZK0_cMTDTToIZEXQTyVvz1nTTW2OeinyEGs8qLf6H8JMh4D95TGSm8YxgqIGgdjwc44vpZ1HlC681iv-gRwvPf44zqTfXU7Ea2Y0kdFm3MdTltH9A-lyRa62J8JCOpzibzxwuOlV9nyEZRbgGx-igLxtkEXJx9YuGuT4b4hIrWyi9BEyLDDhYIUsv1VHWfnOXcZ98-fW-vSrVZhf4yJVDKmywc/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-gould-regext-rdap-versioning%2F>
 (-02 just posted)
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/<https://secure-web.cisco.com/1tXp4Qvx3ZwxG_JflI4RWAyuNSLesY6v6F5e9PHM3ctG7AuM03M1XKq6jWKNaM2yzhJjFAloK2L8Oe1aJQeTz-uEOhhJhNghoaikvt1cM1fxGnP0im7Jni_CBtXgmhabRX8d0RI66AXRxn3eKUilGE1ly_u8FQtP2KRPDAfTKn1D8d1zqDbAumaroM7OwHBkjxv8Zx55y57aKLDNy3qfUdIsWItVWPTlsFF1w3Gi7lncjGoKkbPpLE4Dfl-bV0NMH_G0teF32FxJ1_qT8GeyW1lhG_fX3KGqySJLYWyhuerQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-extensions%2F>
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/<https://secure-web.cisco.com/1vynEGONnD6c3jpzASNi5JktCxoaatpSGQAe_7sPbWti_DS6KBeAEzmjYodzPnMkGJFZSes0qKsvlXGLTvk-UM4ES8robG3bVG0wp-U5YLKrqMw3XHYqIhzRzlozE3u9f2BfrayUT6rMVulRSqQAaCpGb082NbSazOzqabjjrN0TMq5GEyFK712UYoAAj1z3Xkr2dm9i0MKG8qfQduKAv5EBZ5mR6GZBz8gbqkp_OQ70hqPpAGjQO1L05zXkNRAksLsw4fQINAQ3vk1cINy1G1snWMle58uKD22RAzuGnyLo/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-x-media-type%2F>

In general, our goal as a working group is to have one solution on the 
standards track to a problem. After we have adopted these documents the working 
group will have to answer at least two questions:

1. Is there one problem to be solved or more than one?
2. Is there one solution or, if there are multiple problems, do we need 
multiple solutions?

These are technical questions based on use cases that have been discussed. The 
Chairs also suggest that we have an interim meeting, perhaps in late January or 
early February, during which we have a focused discussion seeking answers to 
those two questions, studying the value and benefits of each of the proposals 
in the documents above. The Chairs will address the logistics of an interim 
meeting after we have adopted these documents.

In addition, there is 

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

[Jasdip Singh]

+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 
most recent feedback provided by Jim Gould. With this update, we’d like to 
request working group adoption of the draft. The authors believe it’s in good 
shape given the feedback received to date and it may be close to ready for 
working group last call if the working group agrees with our descriptions of 
the documented practices and recommendations for those that we consider “best”.

https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jasdip Singh]

Hi.

Tom and I have updated this draft to address Gavin's suggestion of using a web 
link instead of a simple URL string. Please review at your convenience. Thanks, 
and happy new year. :)

Jasdip

On 12/17/23, 6:05 PM, "regext on behalf of internet-dra...@ietf.org 
<mailto:internet-dra...@ietf.org>" mailto:regext-boun...@ietf.org> on behalf of internet-dra...@ietf.org 
<mailto:internet-dra...@ietf.org>> wrote:

Internet-Draft draft-ietf-regext-rdap-geofeed-01.txt is now available. It is a
work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.

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 datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/ 
<https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-geofeed-01.html 
<https://www.ietf.org/archive/id/draft-ietf-regext-rdap-geofeed-01.html>

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-01 
<https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-01>

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

___
regext mailing list
regext@ietf.org <mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext 
<https://www.ietf.org/mailman/listinfo/regext>



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext