[regext] request for wglc [was Re: I-D Action: draft-ietf-regext-rdap-extensions-03.txt]

[Andrew Newton (andy)]

Hello chairs,

Version -03 of draft-ietf-regext-rdap-extensions incorporates the last
discussions regarding this draft on this mailing list.
We, the draft authors, believe this draft is ready for working group last call.

-andy

On Thu, Sep 19, 2024 at 1:11 PM  wrote:
>
> Internet-Draft draft-ietf-regext-rdap-extensions-03.txt is now available. It
> is a work item of the Registration Protocols Extensions (REGEXT) WG of the
> IETF.
>
>Title:   RDAP Extensions
>Authors: Andy Newton
> Jasdip Singh
> Tom Harrison
>Name:draft-ietf-regext-rdap-extensions-03.txt
>Pages:   22
>Dates:   2024-09-19
>
> Abstract:
>
>This document describes and clarifies the usage of extensions in
>RDAP.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-regext-rdap-extensions-03.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-extensions-03
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org

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

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt

[Andrew Newton (andy)]

On 9/5/24 07:54, Gould, James wrote:

Andy,

That language looks better.  I believe it would be good for draft-ietf-regext-rdap-extensions to 
cover how new RDAP JSON Values types are defined.  The RDAP JSON Values registry can be extended by 
Type and by Value.  The definition of a new RDAP JSON Values type could include the expected format 
of the values.  Should clients do an exact match of the values or a case insensitive match of the 
value?  I believe there should be no conflicting values based on case in the registry and clients 
should implement a case insensitive match instead of an exact match.  Some values may benefit from 
the use of case and some values may not.  The values for the "notice and remark type" and 
the "redacted reason" could benefit from the use of mixed case since they're not 
identifiers but use sentence form.

Thanks,


James,

Good additions.

WRT to the expected format for types, the current language says that a 
new type MUST be registered with a stable reference (actually, the 
language has a double negative which needs to be fixed). If we are to 
have the DE's looking at values and evaluating if they meet an expected 
format of a type, I think types should only be added via IETF action. 
That is, the DE's should not be expected to evaluate formats that are 
poorly specified.


Thoughts?

-andy

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

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt

[Andrew Newton (andy)]

Hi James and Scott,

I posted a PR to address your discussion points.

https://github.com/anewton1998/draft-regext-rdap-extensions/pull/30/files

Let me know what you think.

-andy

On 8/23/24 10:00, Gould, James wrote:

Andy,

It may be useful to include guidance for RDAP extensions use of the RDAP JSON Values registry in the extensions draft.  I believe that new RDAP extensions should be encouraged to 
support standard values to increase interoperability, where extending the RDAP JSON Values registry is better than creating a new registry specific to the RDAP extension and 
certainly better than not leveraging the RDAP JSON Values registry at all.  The Redacted Extension did this to define three new types with "redacted name", 
"redacted reason", and "redacted expression language", and the language used in the first paragraph of section 6.2 supported the extension of the types.  We 
could look to have any new types define the expected format of the values to help support the review by the DEs, where some types may be more freeform than others (e.g., support 
mixed case).  For example, the "redacted name" values did use mixed case to match the source policy and I believe the "redacted reason" values would be in more 
sentence form with mixed case and potentially punctuation.  The "redacted expression language" is more of an identifier, so it could be predefined as being only 
lowercase.  The Versioning Extension has a similar extension of the RDAP JSON Values registry types with the "versioning" type and registration of the values of 
"opaque" and "semantic".  I view the "versioning" type as more of an identifier, where being lowercase makes sense.

The extensions draft could clarify the expected value format for the predefined 
types in the RDAP RFCs and provide the guidance for how to define new types 
with the expected value format for future RDAP extensions.


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

[regext] Re: Review of draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions

[Andrew Newton (andy)]

Hi James,

On 8/26/24 11:58, Gould, James wrote:
I have an issue with the “Query Parameters Considered Harmful” section 
in draft-ietf-regext-rdap-x-media-type, where query parameters are 
used in the base RDAP RFCs as well as other RDAP extensions including 
the Versioning Extension.  If use of query parameters should be 
discouraged in RDAP, it should be moved from 
draft-ietf-regext-rdap-x-media-type to 
draft-ietf-regext-rdap-extensions.  I personally don’t agree that the 
use of query parameters in RDAP should be considered “harmful”, but it 
can be pointed out in draft-ietf-regext-rdap-extensions that query 
parameters may not be preserved via redirects.  An author of an RDAP 
extension that has the need for client input can take into 
consideration that query parameters may not be presented via redirects 
while creating the extension.  I don’t view this as unique to the 
passing of the desired set of extensions in the RDAP query.


I see your point here. That language should be changed because it is too 
broad. I put an issue for that in the tracker [1]. Also, it needs to 
point to the language in the rdap-extensions draft.


WRT to normative use of the versioning extension, I have a tracking 
issue here [2].



-andy



[1] 
https://github.com/anewton1998/draft-regext-ext-json-media-type/issues/30


[2] 
https://github.com/anewton1998/draft-regext-ext-json-media-type/issues/31
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt

[Andrew Newton (andy)]

On 8/22/24 10:19, Hollenbeck, Scott wrote:
[SAH] Andy, I'd very much prefer that we discuss changes like this 
BEFORE they appear in a working group draft. I don't necessarily 
disagree with the suggestions, but if we assume that a working group 
draft is a reflection of working group consensus it makes more sense 
to discuss significant change proposals on this mailing list before 
they're committed to the draft. Now I have to read it very carefully 
to make sure I don't miss something important... 😊


Of course, all of it is up for review even in draft form as is IETF 
tradition. But we'll try to be better, especially with posting links to 
PRs. That said, a lot of these things are quite detailed and need "words 
on paper" for actual review.



Some of what the draft proposes requires updates to RFCs 9082 and 9083. They're 
full standards. Doesn't that raise a process question that we need to discuss?


I am open to discussion. It should be noted that this was adopted as an 
update doc and we noted the transition from informational awhile back.


One of the things we could add is a summary section of the changes, such 
as can be found in RFC 9582 [1]. What do you think?


FYI, I did ask Google AI if we could do this, and it says yes [2].   :)

More seriously, there are quite a lot of ambiguities in the RDAP RFCs 
around extensions as this draft points out and a lesson we all learned 
from the list traffic here circa 2 years ago.



I do like the idea of adding additional reviewers and guidance for their 
responsibilities. I'll share more feedback after I re-read it all again, this 
time very carefully.


Let me know how many "easter eggs" you find. :)

-andy



[1] https://datatracker.ietf.org/doc/html/rfc9582#name-changes-from-rfc-6482

[2] https://fosstodon.org/@rcode3/113007009405667680

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

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt

[Andrew Newton (andy)]

On 8/20/24 09:15, Gould, James wrote:

Andy,

In reviewing the updates to draft-ietf-regext-rdap-extensions, I believe that we need to 
reconsider the criteria for the RDAP JSON Registry values.  Based on the types initially 
defined, the use of lowercase only values may make sense, but for the recently registered 
values from the RDAP Profile for redaction includes mixed case to exactly match the 
values in the source policy.  The use of lowercase is a non-normative "should", 
so would future registration requests that have justification for mixed case run into an 
issue and be considered a violation of the criteria?  Should we consider updating the 
criteria in RFC 9083 based on the implementation experience of the recent registrations 
or provide additional clarity in draft-ietf-regext-rdap-extensions?

Thanks,


James,

Those are all good points, and I am unaware of any impact on 
implementations from the mixed case registrations. I think the need to 
match text from another document is a good use case and overrides any 
desired "style". I'll change this section in a PR and pass the link when 
it is up. Until then I have created this tracking issue. 
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/29


Thanks for the input.

-andy

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

[regext] Re: a list of RDAP clients

[Andrew Newton (andy)]

On 8/20/24 13:46, pmev...@godaddy.com wrote:


> [SAH] This is something you're maintaining, Andy? How did you manage 
to find them all?


The genesis of it is explained at

https://blog.rcode3.com/blog/a-guide-to-rdap/

The referenced paper at 
https://pam2024.cs.northwestern.edu/pdfs/paper-89.pdf


does list various clients.




To answer Scott's question, yes. Some of the original information came 
from the academic papers listed in the "other documents" section but 
also from Gavin Brown's Stealth RDAP presentation. Also, searching 
GitHub and the various language repositories such as crates.io, PyPi, 
etc... Googling often got me "Residential Drug Abuse Program". :)


Some of the proprietary ones built into intrusion detection systems, 
SEIMs, and other network intelligence systems are harder to identify but 
references to them in forums do pop up in some places.


-andy

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

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt

[Andrew Newton (andy)]

Hi all,

This new version of the draft has a couple of new sections.

Two of the new sections call for the addition of more expert reviewers 
for the IANA RDAP registries and for the reviewers to check each others 
work.


And the other two sections regard security considerations and privacy 
considerations.


Let us know what you think.

-andy

On 8/20/24 08:19, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-regext-rdap-extensions-02.txt is now available. It
is a work item of the Registration Protocols Extensions (REGEXT) WG of the
IETF.

Title:   RDAP Extensions
Authors: Andy Newton
 Jasdip Singh
 Tom Harrison
Name:draft-ietf-regext-rdap-extensions-02.txt
Pages:   22
Dates:   2024-08-20

Abstract:

This document describes and clarifies the usage of extensions in
RDAP.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-extensions-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-extensions-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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


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

[regext] a list of RDAP clients

[Andrew Newton (andy)]

During the last wg session, there was a question about how many RDAP 
clients exist.


Well, there is now a list of the known implementations.

There are, at least, 21 known RDAP clients (not including all the custom 
scripts) and 20 client libraries:


https://rdap.rcode3.com/client_implementations/index.html

-andy

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

[regext] Re: normative language and references in draft-ietf-regext-delete-bcp

[Andrew Newton (andy)]

On 8/12/24 13:25, Hollenbeck, Scott wrote:

-Original Message-
From: Andrew Newton (andy) 
Sent: Wednesday, July 31, 2024 11:08 AM
To: regext@ietf.org
Subject: [EXTERNAL] [regext] normative language and references in draft-ietf-
regext-delete-bcp

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,

During the shepherd's review, some questions were raised regarding
normative references and normative language. This has resulted in a revamped
section 6.

The chairs have asked that this version be confirmed with the working group
before being handed off to our AD.

[SAH] Are we finished with this discussion?


With the changes to the "EPP server" language, yes as far as I can tell.

-andy

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

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

[Andrew Newton (andy)]

On 8/7/24 09:08, kowa...@denic.de wrote:

This is not my point.

I'm missing an equivalent to the following part of -06, in particular 
the 2nd sentence: The "Best Proposed Practices" have not been observed 
in operation. The analysis presented in this document suggests that 
they could become best practices if deployed.


My proposal would be to add the following sentence before proposals 
2&3 in the -07 variant:
"The following practices have not yet been observed in operation 
however the analysis presented in this document suggests that they 
could become best practices if deployed:"




The authors can determine if they want to insert that sentence, but in 
my opinion it is unnecessary and may cause more document churn as the 
point of a BCP is that it documents a best practice via the consensus of 
the IETF even if not yet deployed. The "if deployed" creates a circular 
dependency where it is not a best practice until deployed but there is 
no incentive to deploy until it is a best practice. Additionally, the 
practices that have and have not been observed are documented in section 5.



-andy

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

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

[Andrew Newton (andy)]

My preference is that a BCP have something to enforce, therefore I like 
your suggested change but do think Scott's change to the server language 
is needed.


-andy

On 8/1/24 13:09, Orie Steele wrote:

Hi,

I'm happy to hear from the group on this.

If the working group thinks my change request doesn't make sense 
please let me know.


Regards,

OS, ART AD

On Thu, Aug 1, 2024 at 7:18 AM Hollenbeck, Scott 
 wrote:


> -Original Message-
> From: kowa...@denic.de 
> Sent: Wednesday, July 31, 2024 4:46 PM
> To: Andrew Newton (andy) ; regext@ietf.org
> Subject: [EXTERNAL] [regext] Re: I-D Action:
draft-ietf-regext-epp-delete-bcp-
> 07.txt
>
> Hi Andy,
>
> On 31.07.24 22:16, Andrew Newton (andy) wrote:
> > Pawel,
> >
> > The issues you have raised about changes necessary for either
or both
> > the EPP client and EPP server appear to me to go beyond normative
> > language. Given this type of language  is not in any version
of the
> > draft, does this mean you are not supportive of this document
> > regardless of the -05 or -07 version?
> >
> > -andy
>
> -05 and -06 were fine and I'm supportive of those. If it's
SHOULD or MUST or
> we remove normative language entirely would not be substantial
change
> IMHO.
>
> -07 restructured the section 6 so that the 2 issues appeared:
>
>      1) removed preamble and paragraphs so that current and proposed
> practices were set as equal choice to implementers

[SAH] This was done to address feedback we received from Orie
after he read -06. It's based this text found in Section 5 of RC 2026:

"A BCP document is subject to the same basic set of procedures as
standards track documents and thus is a vehicle by which the IETF
community can define and ratify the community's best current
thinking on a statement of principle or on what is believed to be
the best way to perform some operations or IETF process function."

Note that it says "what is believed to be". There is no
requirement for "best current practices" to be something that's
being done at the moment the document is written.

>      2) added normative text which means the changes are only to be
> implemented by servers

[SAH] That's my mistake, and it's an easy fix. Change "AN EPP
server MUST" to "EPP clients and servers MUST", or "must", or
"can", if people have issues with a normative MUST.

As I said above, Orie requested changes to the text he saw in
Section 6 of -06. We think we addressed his feedback with the
change noted above, but only he can say for sure. I don't want to
revert to -05 or -06 only for him to give us the same "please
change this" feedback during his formal AD review.

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



--


ORIE STEELEChief Technology Officerwww.transmute.industries

<https://transmute.industries>
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

[Andrew Newton (andy)]

On 7/31/24 15:06, kowa...@denic.de wrote:


Just on this one topic.

On 31.07.24 19:30, Andrew Newton (andy) wrote:
Would you be satisfied if the first recommendation was labeled with 
"This practice has been observed in use." and the other two 
recommendations are labeled with "This practice has not been 
observed in use."?


This is already stated with each single practice and it would be 
logically inconsistent the way Section 6 is written now ("MUST 
implement one of the following practices...").


For me the BCP shall tell like "SHOULD implement practice 1 if 
existing and operationally proved practices are preferred or MAY 
consider experimenting with practice 2 or 3 in the future".


I don't understand this. A SHOULD and MAY means a practitioner can 
say they adhere to the BCP without doing anything. Also "the future" 
is subjective. 


Yes, "the future" is subjective. That's right. However touches on one 
important point.


If the goal is to eliminate those bad existing practices in a 
foreseeable near future, then practice 1 is the only that is 
practicable and can be implemented by only one party - the clients. 
This is by the way also an inconsistency in the current text - it 
tells now that EPP MUST servers implement practices, which is not 
right for this one. At least the description does not mention any of 
server changes needed. For others both servers and clients must 
implement collectively.


Practice 2 has a lot of moving parts that needs to change both by 
servers and the clients, so nothing one party can implement on the 
spot to improve the situation in any way. It maybe recommended as a 
target picture, but will take loads of time to implement. Is it then 
an equal recommendation referring to the goal?


Practice 3 also require both servers and clients to change, but likely 
is easier to implement. Easier does not mean easy, as clients tend to 
be reluctant to solutions that work only with selection of registries, 
so servers would have to move first and allow for sacrificial.invalid 
or alike. I'm not an expert in ICANN policies, but maybe it's even 
needed to change those. Also quite broad tests are likely required if 
with all those conditions mentioned in 5.1.4.3 are indeed fulfilled in 
the wild.


So I don't feel right to put an equal mark within Best Current 
Practice document for those three. Whatever "current" means.


Kind Regards,

Pawel Kowalik



Pawel,

The issues you have raised about changes necessary for either or both 
the EPP client and EPP server appear to me to go beyond normative 
language. Given this type of language  is not in any version of the 
draft, does this mean you are not supportive of this document regardless 
of the -05 or -07 version?


-andy

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

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

[Andrew Newton (andy)]

Inline...

On 7/31/24 12:03, kowa...@denic.de wrote:

Comments inline

On 31.07.24 17:20, Andrew Newton (andy) wrote:

[...]

These changes are a result of the shepherd review in checking 
normative references and normative language (see my other email, 
which was likely sent when you sent this :) ).


Yes, E-mails crossed.

I am still not sure how useful it is to have normative language as 
such in BCP, especially if it's only used in the section 6, which 
refers to other sections like 5.1.4.3 which in turn does not contain 
any normative language at all. Whether it's a MUST or SHOULD is likely 
a secondary concern and here at least I would like to learn the logic 
behind the change.




I think that is a fair point. Normative language pointing to procedural 
steps that do not have normative language can be ambiguous.





Would you be satisfied if the first recommendation was labeled with 
"This practice has been observed in use." and the other two 
recommendations are labeled with "This practice has not been observed 
in use."?


This is already stated with each single practice and it would be 
logically inconsistent the way Section 6 is written now ("MUST 
implement one of the following practices...").


For me the BCP shall tell like "SHOULD implement practice 1 if 
existing and operationally proved practices are preferred or MAY 
consider experimenting with practice 2 or 3 in the future".


I don't understand this. A SHOULD and MAY means a practitioner can say 
they adhere to the BCP without doing anything. Also "the future" is 
subjective.


Repeating in this section, that people using practices highlighted as 
"This practice MUST NOT be used" shall stop and use any of above 
instead may be also an idea.


In other words, explicitly rule out practices instead of explicitly 
allowing them. If this document is to do that, some of the document 
practices would need to be updated, such as 5.1.3.2 ("renaming to 
as112.arpa"), which has no prohibitive text even though the document say 
the practice is detrimental. At the very least, 5.1.3.2 is a SHOULD NOT 
practice if it has detriment.


What do others think?


-andy

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

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

[Andrew Newton (andy)]

On 7/31/24 11:08, kowa...@denic.de wrote:
I am a bit concerned about this draft. We finished WG LC with version 
-05, then both -06 and -07 appeared without any discussion on the 
mailing list.


It would be ok if there would be just nits, but -06 changed normative 
language and -07 now reshaped the recommendation section effectively 
putting all practices into the same bucket. I think it was correct in 
the previous version to make a clear distinction that only the first 
practice is clear to have "minimal undesired side effects". The other 
two are proposed practices, which are neither implemented nor tested 
by anyone, therefore IMHO shall be clearly marked as such.


Kind Regards,

Pawel



Hi Pawel,

These changes are a result of the shepherd review in checking normative 
references and normative language (see my other email, which was likely 
sent when you sent this :) ).


Would you be satisfied if the first recommendation was labeled with 
"This practice has been observed in use." and the other two 
recommendations are labeled with "This practice has not been observed in 
use."?


-andy

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

[regext] normative language and references in draft-ietf-regext-delete-bcp

[Andrew Newton (andy)]

Hi all,

During the shepherd's review, some questions were raised regarding 
normative references and normative language. This has resulted in a 
revamped section 6.


The chairs have asked that this version be confirmed with the working 
group before being handed off to our AD.


The specific section is here: 
https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-delete-bcp-07#name-recommendations


Comments and questions are welcomed.


Thank you for your time.

-andy

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

[regext] Re: RESTful EPP Charter side meeting Thursday 13:00

[Andrew Newton (andy)]

I agree with this. Furthermore, if a greenfield approach is desired it
would help if the protocol is not called EPP or a variation otherwise there
will be confusion.

-andy

On Thu, Jul 25, 2024 at 4:57 AM Gould, James  wrote:

> I view two options for meeting the goals of REPP, which I believe is to
> have a more Cloud-friendly provisioning protocol:
>
>
>
>1. Incremental Approach
>   1. Implement incremental changes to EPP that make it more
>   Cloud-friendly, which does need to be fully compliant with the EPP RFCs.
>   This includes adding support for the HTTP transport that is handled by 
> EoH,
>   support for client-side state that can be handled via an EPP command
>   response extension (e.g., leverage something like JWT, extend the login
>   command and login response to create the token, and have the extension 
> pass
>   the token with each EPP command to propagate the state) that can be used
>   with any EPP transport (EoT, EoH, and EoQ), and create an EPP URL 
> routing
>   layer that optimizes the routing decisions to the EPP services.  This is
>   certainly not REST but it would be fully compliant with the EPP RFCs and
>   would not require a rebuild of the existing EPP services, since the
>   extensions are optional.  This work could be done by REGEXT, where the 
> only
>   question mark is the definition of the EPP URL routing layer in the
>   existing charter.  Other aspects of REPP could be considered for the
>   Incremental Approach, where this list is what I’ve thought of thus far.
>2. Greenfield Approach
>   1. Define a new provisioning protocol that does not attempt to
>   extend EPP, but instead takes the lessons learned from RDAP for REST and
>   the lessons learned from EPP for the data model and extensibility to 
> define
>   a new RESTful provisioning protocol.  EPP is more than RFC 5730 but
>   includes all the extensions that have been created over the past 20 
> years,
>   so creating a new provisioning protocol that can support a similar set 
> of
>   features will be a very large undertaking.  This large task is best 
> suited
>   for a new working group with a defined set of requirements.  Attempting 
> to
>   do this work in REGEXT would need to de-prioritize the extension work,
>   since it will consume most if not all the focus.  All the EPP services 
> and
>   extensions would need to be re-implemented and transitioned from EPP.  I
>   personally worked on the development of EPP and the transition from RRP,
>   and the effort and impact should not be underestimated.
>
>
>
> What is currently defined in REPP is more Greenfield but is attempting to
> maintain some compatibility with EPP.  I would go with the fully compatible
> Incremental Approach or a pure Greenfield Approach.
>
>
>
> --
>
>
>
> JG
>
>
> [image: cid87442*image001.png@01D960C5.C631DA40]
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *Orie Steele 
> *Date: *Wednesday, July 24, 2024 at 9:00 PM
> *To: *Maarten Wullink 
> *Cc: *Registration Protocols Extensions 
> *Subject: *[EXTERNAL] [regext] Re: RESTful EPP Charter side meeting
> Thursday 13:00
>
>
>
> *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,
>
>
>
> I said that we heard 2 paths forward:
>
>
>
> - recharter / expand existing charter
>
> - new working group
>
>
>
> If you feel strongly about this topic, I welcome any comments on this list
> or to me or the chairs privately.
>
>
>
> There seems to be energy to do this work, I'll work with you all to find
> the right approach.
>
>
>
> Thanks to the authors and chairs for the presentation in today's meeting.
>
>
>
> Regards,
>
>
>
> OS, ART AD
>
>
>
> On Wed, Jul 24, 2024, 3:35 PM Maarten Wullink 
> wrote:
>
> Hi All,
>
>
>
> Thank you all, for the comments and suggestions during our discussion
> earlier today about RESTful EPP.
>
> The Area Director suggested we create a new working group for this and
> similar work.
>
>
>
> If you are interested in joining us, to discuss and write a concept
> charter for this new WG, we have organised a side meeting for this on
> Thursday.
>
> Online participation is also an option, the URL will be added to the wiki
> shortly.
>
>
>
> Room: Tennyson
>
> Time: 1300-14:00
>
> URL: https://wiki.ietf.org/en/meeting/120/sidemeetings
> 

[regext] Re: WGLC: draft-ietf-regext-rdap-rir-search-09

[Andrew Newton (andy)]

Hi Jasdip and Tom,

I think this is a really well done draft.

I have the following comments:

1. The registrations in the IANA section run together. I would be
easier to distinguish the individual registrations if they were
numbered and the bullet points were nested, or some other visual
property that separates them.

2. The mention of "lookup URL" in Section 5 and Section 7 could use a
reference to Section 3.1 of RFC 9082 as you have done section 4.1 of
your draft.

3. The search pattern for autnums?handle in section 2.3 says that the
pattern is up to each "registration provider". Does that mean each
RIR? This does not seem to be very predictable for a client in that it
needs to know, somehow, the search pattern of the server. Could you
define the search pattern, as is specified in Section 4.1 of RFC 9082?
Or maybe reference Section 4.1 of RFC 9082?

-andy

On Fri, Jul 12, 2024 at 2:18 PM 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 Best Current 
> Practice:
>
> RDAP RIR Search
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/09/
>
> This document has been through WGLC previously.  However, a number of 
> questions arose and changes were made that are considered material and thus 
> we are proceeding with this additional WGLC.
>
> 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, Friday, 2 August 2024.  This WGLC has been extended to 3 weeks 
> because of the IETF120 meeting.
>
> If there are no objections the document will be submitted to the IESG.
>
> The Document Shepherd for this document is Mario Loffredo.
>
> Thanks,
>
> Antoin and Jim
> REGEXT WG Co-Chairs
>
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org

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

[regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05

[Andrew Newton (andy)]

Hi Jasdip,

Can you point to the spot in opsawg-9022-update that states clients
are to ignore non-standard data?

Also, I see this in the opsawg-9022-update:

"When reading data from an unsigned geofeed file, one MUST ignore data
outside the referring inetnum: object's address range."

That to me indicates that clients should not process any geofeed link
found in anything other than an "ip network", but it also means the
should not process any geofeed link data in an "ip network" where the
geofeed data is outside the network boundary of the "ip network"
object.

-andy

On Sat, Jul 20, 2024 at 9:20 AM Jasdip Singh  wrote:
>
> Hi Andy,
>
>
>
> Thanks for these insightful questions. Tom and I discussed them. Let me try 
> answering. :)
>
>
>
> Tom, please add/subtract if needed.
>
>
>
> Jasdip
>
>
>
> From: Andrew Newton (andy) 
> Date: Thursday, July 18, 2024 at 3:19 PM
> To: REGEXT Working Group , Jasdip Singh , 
> t...@apnic.net 
> Subject: [regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05
>
> Hi Jasdip and Tom,
>
> I like this draft, but I do have a couple of questions.
>
> 1. This draft mentions the ip network object class but none of the other
> object classes. Are those not allowed by this extension? What happens if
> a server uses a geofeed link in a domain object? Should that be covered
> under a different extension? What if bigisp.com wants to allow other
> network operators to find their geofeeds just by looking up bigisp.com
> in RDAP? That seems like it might be a useful thing. If not, are clients
> to ignore processing the link if found any object other than an ip network?
>
>
>
> [JS] Since the goal of this extension has been to complement the RFC 9092 
> Update [1] semantics by providing a point of presence in RDAP, we’d like to 
> keep the spec limited to IP network objects, given some of the RIRs are 
> already enabling geofeed link additions as part of network registrations. The 
> bigisp.com domain scenario is interesting, and some verbiage could have been 
> added to allow geofeed links for other object classes if the authority of the 
> holder of these non-network objects extended over the networks in question. 
> That might be possible for reverse domains in the RIRs but not sure how that 
> authority could be ascertained for forward domains in the DNRs when the 
> network data is in another registry. We think that a more focused, new 
> extension for such a scenario would do a better job from spec angle.
>
>
>
> To your “If not, are clients to ignore processing the link if found any 
> object other than an ip network?”, we think yes since clients are expected to 
> ignore non-standard data.
>
>
>
> [1] https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-9092-update-11
>
>
>
> 2. Do the IPs in the geofeed file have to be in the IP boundaries of the
> ip network object class where the link is found? That doesn't look to be
> a requirement, but perhaps this should be explicitly stated.
>
>
>
> [JS] From what we are noticing at the RIR level is that the service providers 
> generally create a geofeed file with a one-to-many relationship with multiple 
> networks. Requiring IP boundaries would impede how it is presently done.
>
>
>
> 3. What is a client to do if it finds the geofeed link in a response
> without a "geofeed1" extension? Is it suppose to treat the link as if
> the response had a "geofeed1" extension? The expectation of client
> processing should be more explicit in this allowable corner case.
>
>
>
> [JS] Glad you noted this edge case. After seeing James’ feedback on replacing 
> RECOMMENDED with MUST for the extension id inclusion, we think MUST would be 
> better since it 1) helps eliminate any confusion on RECOMMENDED being 
> misconstrued as optional, and 2) brings this extension more in line with the 
> new “marker” extension definition from the RDAP Extensions draft [2]. If MUST 
> is acceptable, that still leaves the scenario of a server returning a geofeed 
> link without this extension id in the response but that would not be in line 
> with this spec and the client is free to proceed as it would for any 
> non-standard data in a response; most likely, ignore.
>
>
>
> [2] 
> https://github.com/anewton1998/draft-regext-rdap-extensions/blob/main/draft-regext-rdap-extensions.md
>
>
>
>

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

[regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05

[Andrew Newton (andy)]

Hi Jasdip and Tom,

I like this draft, but I do have a couple of questions.

1. This draft mentions the ip network object class but none of the other 
object classes. Are those not allowed by this extension? What happens if 
a server uses a geofeed link in a domain object? Should that be covered 
under a different extension? What if bigisp.com wants to allow other 
network operators to find their geofeeds just by looking up bigisp.com 
in RDAP? That seems like it might be a useful thing. If not, are clients 
to ignore processing the link if found any object other than an ip network?


2. Do the IPs in the geofeed file have to be in the IP boundaries of the 
ip network object class where the link is found? That doesn't look to be 
a requirement, but perhaps this should be explicitly stated.


3. What is a client to do if it finds the geofeed link in a response 
without a "geofeed1" extension? Is it suppose to treat the link as if 
the response had a "geofeed1" extension? The expectation of client 
processing should be more explicit in this allowable corner case.


-andy

On 7/12/24 17:12, 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:

An RDAP Extension for Geofeed Data
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/

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, Friday, 2 August 2024.  This WGLC has been extended to 3 weeks 
because of the IETF120 meeting.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Gavin Brown.

Thanks,

Antoin and Jim
REGEXT WG Co-Chairs

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


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

[regext] ICANN gTLD Profile

[Andrew Newton (andy)]

Hi all,

If you are attending IETF 120 in Vancouver and work for a gTLD registry 
operator or registrar or current or potential Registry Service Provider 
and have questions about the ICANN gTLD Profile 
(https://www.icann.org/gtld-rdap-profile), including the new version of 
the profile, send me a private message and I will arrange a meeting time 
to help answer any questions you might have. If there is enough 
interest, I can also look into getting one of the rooms the IETF has for 
side meetings.


Also to help with common issues, we have been adding to the wiki for the 
RDAP Conformance Tool which includes explanations and examples. You can 
find that wiki here: https://github.com/icann/rdap-conformance-tool/wiki


-andy

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

[regext] Re: [Ext] AD Evaluation: draft-ietf-regext-epp-ttl-14

[Andrew Newton (andy)]

On 7/12/24 05:41, Gavin Brown wrote:

### DELEG as example

```
298   3600
```

Consider a record that is already registered with IANA, TLSA for example.

As I understand it, TLSA is not appropriate for publication at a delegation 
point, so using TLSA here would not make any more sense than DELEG. Perhaps 
this should just be some placeholder value, such as MYCUSTOMTYPE?



DS maybe?

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

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

[Andrew Newton (andy)]

+1.


-andy

On 6/24/24 09:26, James Galvin wrote:

The Chairs have decided to extend this WGLC last call for two weeks, one more 
week from the date of this message.  There has only been on indication of 
support and two different threads discussing some minor changes.  We would like 
these discussion to resolve and for there to be more indications of support for 
this document.

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 July 2024.

Thanks,

Antoin and Jim


On 3 Jun 2024, at 10:56, 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 Best Current 
Practice:

Best Practices for Deletion of Domain and Host Objects in the Extensible 
Provisioning Protocol (EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/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 publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 17 June 2024.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Andy Newton.

Thanks,

Antoin and Jim
REGEXT WG Co-Chairs

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


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

[regext] Re: Simple Redaction

[Andrew Newton (andy)]

On 6/21/24 09:32, kowa...@denic.de wrote:

Hi Andy,

Taking into account that this proposal is a result of considerations 
on rfc9537 I think this draft takes the issue too simplified or easy, 
just by removing the difficult part of the problem in rfc9537.


If you are saying that this draft is the result of experience with rfc 
9537, I 100% agree. I did not think of it until after realizing that, 
with few exceptions, the redaction methods in 9537 can only apply to 
strings.


Actually it dictates allowed methods how redaction is done by the 
server, practically eliminating the possibilities foreseen in rfc9537 
which lead to removal of properties, objects or array elements (mainly 
"Redaction by Removal" and one mode of "Redaction by Replacement 
Value"). If you'd remove these methods from rfc9537, you'd actually 
fix the issues with prePath as well because prePath would never occur.


If redaction by removal was instead redaction by placeholder, then the 
items being redacted could be identified by JSONPath (assuming JSONPath 
is usable). I believe you proposed placeholder values but the 9537 
authors rejected it.


The group consensus was however that these methods exist and are in 
use by the servers, so not taking them into account in rfc9537 would 
have too much of an implication on the servers. This would result in 
servers still doing the same thing (ergo removing properties, objects 
or array elements) and not having a way to signal it.


I am struggling to understand the logic that a server has the adequate 
knowledge to redact by empty value or redact by partial value but cannot 
substitute values for keys.




postPath does not pose such an issue, because even if more than one 
path is selected it is clear which elements of the response have been 
redacted any why. If an overlap happens the client can display both 
reasons fo the redaction.


Overlaps are problematic to clients (and users) when they are signaled 
by multiple redaction methods. I cannot think of a compelling reason why 
they should be allowed.


A feature that your proposal adds is a possibility to mark exactly 
which part of partial redaction have been replaced. It didn't appear 
to me as a goal for rfc9537 to have information specific to that 
extend, especially in an unstructured data. The clients processing 
such response may still mark the whole field as redacted leaving the 
interpretation to the user. If this feature is deemed to be important 
it can be still added on top of rfc953, using a method you've proposed 
or any other suitable mean.


Being able to differentiate the parts of a string that are redacted is 
particularly acute when it comes to things like unstructured postal 
addresses (see section 4.1 of my draft) and tel URIs (see section 2.2 of 
my draft).


-andy


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

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

[Andrew Newton (andy)]

On 6/20/24 16:39, rcar...@godaddy.com wrote:


I was not sure if I should reply to this thread or the "Simple" thread 
but as the "Simple" thread appears to be a product of this one, I 
thought I would post here.


Several years ago, there were many discussions (in the REGEXT WG, the 
RDAP WG and others) on how to handle redaction in the RDAP response 
and using placeholder text was an option that was discussed. Through 
those discussions it was determined that using placeholder text was 
not fit for purpose (typed data, different types of redactions, varied 
server implementations, etc) and was deemed as an engineering "hack" 
and called for an original solution. Not using placeholder text was 
exactly what drove us to the creation and eventual publication of RFC 
9537.



Roger,

It is not simple placeholder text but patterned keys that retain 
syntactic validity. I did search the archives and did not find any 
discussion of this approach. However, if you can point us to the those 
technical discussions or, better, recite them here that would be very 
helpful. While some may pejoratively refer to it as a "hack", there is 
another saying often used by engineers, "the best is the enemy of the good."


This solution also has some clear benefits.

1. It can cleanly deal with JSContact UIDs, whereas we had many 
discussions on the list regarding the interaction between JSContact and 
9537.


2. It can distinguish the parts of a string that are redacted from the 
parts that are not.


3. Even if the client doesn't support the extension and passes the data 
onto the user, there is some chance that the user will understand that 
the data has been redacted.


-andy

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

[regext] Re: Fwd: using experimental to move items forward

[Andrew Newton (andy)]

On 6/20/24 03:35, Mario Loffredo wrote:

Hi Andy,


[snip]



On 6/18/24 04:29, Mario Loffredo wrote:


Hi Andy,

what does it mean "interoperable implementation" in RegExt context ?

Best,

Mario


It means the protocol/extension works as expected. If Bob were to 
create a client with extension Foo and Alice were to create a server 
with extension Foo, but the expected features of extension Foo did 
not work between then they do not interoperate. Of course, "did not 
work between them" can be a bit subjective but that is why a written 
report is required to pull out the ambiguities.


[ML] Is it the same as requiring the "Implementation Status" section 
to include at least one client and one server implementation?





We could do that, or some combination thereof. RFC 7942 which covers the 
implementation status section list the use of the wiki as an 
alternative. The benefit of the wiki is that the information doesn't get 
lost when the document turns into an RFC. The benefit of the 
implementation status section is that it is with draft as it is reviewed 
by the various reviews of the IETF. We could opt to do one or the other 
or both or a hybrid (link in the implementation status section pointing 
to the wiki report). One benefit the wiki seems to have is that the 
implementers can update their reports and the information does not need 
to go through the draft authors. The wiki is also probably easier to format.


If we go with the implementation status section, we should require the 
"coverage" and "implementation experience" parts be more thorough, 
including a list of the type of interoperability tests conducted and how 
they were performed. If we use the wiki, I think the reports should 
include the same information that would go into the implementation 
status section.


-andy

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

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

[Andrew Newton (andy)]

On 6/17/24 08:11, Gould, James wrote:

JG - I agree that this language in the abstract could be better, but the 
abstract does not override the content of the entire specification and is 
factual.  The extension explicitly identifies the redacted RDAP response fields 
and JSONPath is the default expression language.  The working group, the 
co-editors, and you as the document shepherd could have made this sentence 
better.



James, I don't think this type of comment is appropriate. It is 
accusatory in nature and sets the wrong tone, especially if we want 
others to volunteer as document shepherds. I did take over as document 
shepherd from another participant on this RFC as I wanted to see it 
published (and I have volunteered as shepherd on multiple documents 
since). I have spent a considerable amount of time on RFC 9537, creating 
a GitHub repository of test cases, overseeing two development teams for 
two clients, and adding 9537 capabilities to a server. The issues I have 
brought forward are not trivial, and the finger-pointing is not appreciated.



Regarding some of the other arguments made in the various emails:

1. It is true that section 4.2 states as OPTIONAL the various JSONPath 
attributes, but this is also from Section 4.2:


The "postPath" member MUST be set when the redacted field does exist in 
the redacted response for the Redaction by Empty Value Method (Section 
3.2), the Redaction by Partial Value Method (Section 3.3), and the 
Redaction by Replacement Value Method (Section 3.4).


Section 4.2 is clearly describing a data structure that takes different 
forms based on the redaction method because the various paths only have 
meaning in certain contexts. The OPTIONALs are there to allow the 
structure to be re-used. This is reflected in EVERY example in the RFC.



2. You have stated the JSONPath expressions may or may not be useful and 
that we need to rely on implementation experience to determine their 
utility (this is paraphrasing, but it is also implied given the argument 
that they are completely optional). From this very thread:


On 6/17/24 08:11, Gould, James wrote:


JG - There may be servers and clients that do decide to implement the JSONPath 
expressions, but time will tell.  A new JSON expression language may be defined 
that is better suited as well, where JSONPath is the best match right now.

If this is true, their defined usage with respect to redaction should 
not be in a standards track document. That is more appropriate for the 
Experimental track.



3. You state above the extension "explicitly identifies" the redacted 
response fields. Explicitly means "fully revealed or expressed without 
vagueness, implication, or ambiguity : leaving no question as to meaning 
or intent." If the JSONPath is optional, how can that be explicit?



-andy

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

[regext] Re: Fwd: using experimental to move items forward

[Andrew Newton (andy)]

On 6/18/24 08:41, Hollenbeck, Scott wrote:



Because the RDAP extensions seem to be piling up and we seem to have
differing views about their implementations. I think RFC 9537 is a good
example of this... an implementation report would have been very beneficial
as we are now being told the JSONPath portions are completely optional
though the RFC doesn't read that way at all.

[SAH] I agree that an implementation report would have been helpful. The 
JSONPath portions are marked as OPTIONAL, but experience is showing us that the 
text could be clearer about what that means. We could address that issue with a 
-bis draft once we have a better handle on all needed updates.

Scott


A -bis or something is needed. But as for JSONPath being OPTIONAL, this 
is from Section 4.2:


The "postPath" member MUST be set when the redacted field does exist in 
the redacted response for the Redaction by Empty Value Method (Section 
3.2), the Redaction by Partial Value Method (Section 3.3), and the 
Redaction by Replacement Value Method (Section 3.4).


Section 4.2 is clearly describing a data structure that takes different 
forms based on the redaction method because the various paths only have 
meaning in certain contexts. The OPTIONALs are there to allow the 
structure to be re-used.


I realize you asked me about this in another thread and I gave you an 
answer to a different issue. My apologies.


-andy

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

[regext] Re: Fwd: using experimental to move items forward

[Andrew Newton (andy)]

Responding to multiple people

On 6/17/24 18:40, George Michaelson wrote:

I have two competing views

1) get rid of time-wasting. If documents something novel in
implementations but there are no implementations, it's not very useful
work. Experimental and Informational are kind of different.

2) de-facto VETO from incumbency. I am concerned in other WG this is
being used by what I can only call a "cabal" of friendship, to oppose
things "the bad person" suggests could or should be done.


RE 1) I agree that Informational is different, but this is exactly one 
of the use cases for Experimental.


https://www.ietf.org/process/process/informational-vs-experimental/

RE 2) I don't want that, though we do have people who pop up at our 
sessions to oppose things without giving a technical reason. I also 
don't understand how setting an objective criteria enables a cabal. In 
fact, I would think it does the opposite. Also note that I explicitly 
lowered the bar set by IDR/SIDROPS. This isn't about gate keeping, but 
about getting back to "rough consensus, running code".


On 6/18/24 06:42, Maarten Wullink wrote:

Hi,

+1 for optimizing the process where possible.

But i wonder why this new process is limited to RDAP extensions only?
What is the distinction between RDAP extensions and other work done in REGEXT 
such as EPP extensions?


-
Maarten


Because the RDAP extensions seem to be piling up and we seem to have 
differing views about their implementations. I think RFC 9537 is a good 
example of this... an implementation report would have been very 
beneficial as we are now being told the JSONPath portions are completely 
optional though the RFC doesn't read that way at all.


But we could extend this to EPP, though I suspect most EPP proposals 
would meet this criteria more easily as many of them have both server 
and SDK implementations (see the recent EPP TTL draft).



On 6/18/24 04:29, Mario Loffredo wrote:


Hi Andy,

what does it mean "interoperable implementation" in RegExt context ?

Best,

Mario


It means the protocol/extension works as expected. If Bob were to create 
a client with extension Foo and Alice were to create a server with 
extension Foo, but the expected features of extension Foo did not work 
between then they do not interoperate. Of course, "did not work between 
them" can be a bit subjective but that is why a written report is 
required to pull out the ambiguities.


-andy

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

[regext] Re: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt

[Andrew Newton (andy)]

On 6/17/24 11:02, Gavin Brown wrote:
Servers of RDAP data should already have various caching mechanisms 
(if not, they are in big trouble…) so the hit to a server is 
insignificant.

In my experience, cache hit rates for RDAP is quite low (20-30%), because a 
common usage pattern is:

listOfDomains.forEach((domain) => doRDAPQuery(domain));

Therefore you don't get a lot of repeat queries, meaning that you have to 
generate fresh responses each time. Therefore substituring an expensive GET for 
a cheap HEAD has the potential to be quite helpful.

I don’t understand your point. RDAP objects are relatively long-live. So one 
can subscribe to a caching service and have its data cached.

That's one way to implement RDAP but I suspect probably not the most common 
one. A much more likely implementation is live generation + a caching reverse 
proxy like Squid/Varnish/$CDN, just like every other web app. Those front-end 
servers will not keep warm caches, and their caches are probably not shared 
between instances, AZs or regions. And many RDAP server operators are required 
to invalidate their cache every so often in order to ensure that changes to 
registration data become visible within a time dictated by an SLA.



I agree with Gavin here. There are cases where some RDAP objects can be 
long lived but most are not. In my experience, the most effective are 
application-aware caches like LRUs. Being able to pull from cache and 
throw the answer on the wire is as few packets as possible is a benefit 
to servers.


I think I misunderstood you when you said "asynchronous", I took that 
to mean "in parallel". Obviously an RDAP client cannot do query to the 
registrar RDAP server in parallel to the query to the registry RDAP 
server, as it needs to the registry response in order to learn the URL 
of the registrar server.

But again, the use case you're basing your argument from is that of an 
interactive client, where the benefits of my proposal will not be all that 
great. That is not the only use case for RDAP.


And the vast bulk of both Whois and RDAP queries come from automation, 
not people.


-andy

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

[regext] Re: using experimental to move items forward

[Andrew Newton (andy)]

On 6/17/24 10:25, Hollenbeck, Scott wrote:

-Original Message-
From: Andrew Newton (andy) 
Sent: Friday, June 14, 2024 6:23 AM
To: regext@ietf.org
Subject: [EXTERNAL] [regext] using experimental to move items forward

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,

When I look at the DNSOP working group I see items like CDS bootstrapping
and generalized NOTIFY are nearing completion. They have even spun off
another working group recently. Comparing that to the progress here, it seems
that in REGEXT we don’t make as much progress.

Given the different perspectives, I’d like to propose a change in our working
group process inspired by mailmaint [1], sidrops [2], and idr [3]. The basic
proposal is to adopt the SIDROPS/IDR thresholds but with a lower bar for all
RDAP extensions: before publication on the standards track there must be at
least one interoperable server and client implementation documented with an
implementation report published on the working group wiki [4]. Otherwise
the extension may be published as experimental with the proviso that it could
be put back on the standards track once interoperability between a client and
a server is documented.
And in special circumstances, the chairs could waive this requirement.

Note that in the SIDROPS and IDR examples above, there's nothing in the
working group charter that requires these interoperable implementations.
We might be able to do this in REGEXT without a charter change, too.
Following their lead, we would publish this proposal to the REGEXT wiki [4].

[SAH] This proposal is worth discussing. Can we put it on the agenda for 
IETF-120?

Scott


I'd be happy to put some slides together or happy to let the chairs lead 
such a discussion.


-andy


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

[regext] Simple Redaction

[Andrew Newton (andy)]

Hi all,

I spent some time thinking about how to make the redaction problem less 
complex by focusing on the places where redaction is most likely to to 
be found, in "personal data". Within RDAP, that appears to always be 
conveyed in JSON strings. Reducing the scope reduces the complexity, at 
least in my opinion.


Included is an example with the ICANN redaction policies, which are the 
only published redaction policies that I know of. If others are 
published, please send me a link and I'll see about working up an example.


Anyway, I am curious what people think.

-andy



 Forwarded Message 
Subject: 	New Version Notification for 
draft-newton-regext-rdap-simple-redaction-00.txt

Date:   Mon, 17 Jun 2024 05:51:39 -0700
From:   internet-dra...@ietf.org
To: Andy Newton 



A new version of Internet-Draft
draft-newton-regext-rdap-simple-redaction-00.txt has been successfully
submitted by Andy Newton and posted to the
IETF repository.

Name: draft-newton-regext-rdap-simple-redaction
Revision: 00
Title: RDAP Simple Redaction
Date: 2024-06-17
Group: Individual Submission
Pages: 19
URL: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-redaction-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-redaction/
HTML: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-redaction-00.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-simple-redaction



Abstract:

This document defines a simple redaction extension for the
Registration Data Access Protocol (RDAP).



The IETF Secretariat


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

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

[Andrew Newton (andy)]

On 6/14/24 14:59, Hollenbeck, Scott wrote:

-Original Message-
From: Andrew Newton (andy) 
Sent: Friday, June 14, 2024 2:42 PM
To: Gould, James ; kowa...@denic.de; regext@ietf.org
Subject: [EXTERNAL] [regext] Re: Fwd: New Version Notification for draft-
newton-regext-rdap-considerations-on-rfc9537-00.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.

James,

Thanks for this. I think I covered this in section 10 of the draft, though
probably not in as much detail as needed.

Yes, this is one path forward but it does not provide the functionality as
advertised in the RFC and is a lot machinery just to replicate the "remarks"
feature of core RDAP, albeit with less functionality as "remarks" can be
associated directly with an RDAP object and can provide descriptive text in
multiple languages (unlike "redaction").

As Gavin pointed out, such an approach does not work well with clients that
do not present the data in a linear style (rdap.org, search.arin.net/rdap, 
etc...).

When time permits, I'll update the draft to more thoroughly cover this topic.

[SAH] Andy, with the various JSONPath elements being OPTIONAL, are you saying 
that the clients you described above can't process a redacted response using 
only the name value? Could you point me to Gavin's explanation?


Scott,

Gavin's email is here: 
https://mailarchive.ietf.org/arch/msg/regext/FlDF-Hcmf_4vPwU8ULqiBaThRCE/


I outline the use of the name value here: 
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-considerations-on-rfc9537-00#name-redaction-by-removal


The name value can have two forms, one with a "type" and one with a 
"description". "description" holds an unregistered value and "type" 
holds an IANA registered value. The non-normative guidance in Section 
5.1 does not say what to do in either case.


In the code James provided where the "name" is the value of "type" if 
present otherwise it is the value of "description", the client is left 
to displaying that value somewhere unspecified (see my email to James 
above).


Now, if the client implementer determines that they are, at the time of 
writing the client, to cross-reference "type" with the IANA registry and 
hard-code the redaction based on the description in that registry, there 
are a couple of problems:


a) the RFC doesn't say that so we cannot expect implementers to do it,

b) it treats each IANA registry entry as a psuedo-specification,

c) that goes counter to how the RFC describes the process which (from 
the RFC abstract) states "This document describes a Registration Data 
Access Protocol (RDAP) extension for specifying methods of redaction of 
RDAP responses and explicitly identifying redacted RDAP response fields, 
using JSONPath as the default expression language."


d) clients must be updated every time the IANA registry is updated 
(unlikely),


and e) renders the need for all the complexity in the RFC as unnecessary.

Hopefully that adds more clarity, and if so I can update this section of 
the draft with this text.


-andy

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

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

[Andrew Newton (andy)]

val";

  }

publicstaticvoidmain(String[] args) {

try{

JsonNoderootNode=newObjectMapper().readTree(newFile(args[0]));

JsonNoderedactedExt=rootNode.get("redacted");

List removedRedactions=newArrayList();

List partialRedactions=newArrayList();

List replacedRedactions=newArrayList();

// Map redacted member

if(redactedExt !=null&&redactedExt.isArray()) {

for(JsonNoderedactedNode:redactedExt) {

Redactedredacted=newRedacted();

// Name

redacted.name=redactedNode.get("name").get("description").asText();

if(redacted.name==null) {

redacted.name=redactedNode.get("name").get("type").asText();

}

// Method

if(redactedNode.get("method") !=null) {

redacted.method=redactedNode.get("method").asText();

}

if(redacted.method.equals("removal") 
||(redacted.method.equals("emptyValue"))) {


removedRedactions.add(redacted);

}

elseif(redacted.method.equals("partialValue")) {

partialRedactions.add(redacted);

}

elseif(redacted.method.equals("replacementValue")) {

replacedRedactions.add(redacted);

}

}

}

// Print redactions grouped by method

if(!removedRedactions.isEmpty()) {

System.out.println("Redacted by Removal:\n");

for(Redactedredacted:removedRedactions) {

System.out.println(redacted.name);

}

  }

if(!partialRedactions.isEmpty()) {

System.out.println("Partially Redacted:\n");

for(Redactedredacted:partialRedactions) {

System.out.println(redacted.name);

}

  }

if(!replacedRedactions.isEmpty()) {

System.out.println("Redacted by Replacement:\n");

for(Redactedredacted:replacedRedactions) {

System.out.println(redacted.name);

}

  }

} catch(IOExceptione) {

System.err.println("Exception: "+e);

}

  }

}

Output:

Redacted by Removal:

Registry Domain ID

Registrant Name

Registrant Organization

Registrant Street

Registrant City

Registrant Postal Code

Registrant Email

Registrant Phone

Technical Name

Technical Email

Technical Phone

Technical Fax

Administrative Contact

Billing Contact

--

JG

James Gould

Fellow Engineer

jgo...@verisign.com 



703-948-3271

12061 Bluemont Way

Reston, VA 20190

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

On 6/11/24, 2:02 PM, "Gould, James" <mailto:jgo...@verisign.com>> wrote:


Andy,

The redacted extension provides information to the client of what has 
been redacted and it's up to the client to determine how to display 
it. The implementer needs to leverage the entire specification of the 
RFC, where in section 4.2 ""redacted" Member", it fully defines which 
of the members are required and optional. I agree that the abstract 
could have been better worded. It's not up to section 3.1 "Redaction 
by Removal Method" to define the "prePath" as optional since that's 
covered in section 4.2 ""redacted" Member". The inclusion of an 
optional member in the example does not change the normative language 
in section 4.2.


Is it possible to display the list of redactions to the users using 
the required "name" and "method" members? The registered "redacted 
name" values should help the clients provide additional visual 
indicators if required.


Thanks,

--

JG

James Gould

Fellow Engineer

jgo...@verisign.com <mailto:jgo...@verisign.com> 
<mailto:jgo...@verisign.com>>


703-948-3271

12061 Bluemont Way

Reston, VA 20190

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

On 6/11/24, 10:59 AM, "Andrew Newton (andy)" <mailto:a...@hxr.us> <mailto:a...@hxr.us <mailto: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.


On 6/11/24 07:57, kowa...@denic.de <mailto:kowa...@denic.de> 
<mailto:kowa...@denic.de <mailto:kowa...@denic.de>> wrote:


>

> Hi,

>

> I think the issue of JSONPath not being easy/possible to interpret in

> case of removed paths was brought up on the mailing list and the

> conclusion was to key off the "redacted name" rather than base on

> JSONPath [1].

>

> This is also what has been covered in 5.1.1 with a clear

> recommendation for the client implementers. Not enough?

>

> [1]

> 
https://secure-web.cisco.com/13EK5pT1XZj4x6yjYjnZ_zLex4bki3NGhJbBSsKe9nSP7lApyLcWFL5KLe93xmfHQXF5B_VVpCG10_frgBqZa8dSFH_P2Mq-ltn9GWApbm3LsiRN5SeeugfyofTnr6wOa9w4tpIiF_3RSGrRkWCAKYEvIN7aEVNmBB_pjsTGOsV7Ap1aRObLzqp4o-RQ6rTRchaaokaYz0XYGQYrlm_p5t38RvHglH2pS62WCMkXQCCqEI-W50CWZWJt6fHH60h-w8tkEZ2HZQnKHyB0SkdAUANirvrAQAih-5Ila-_rVBrQ/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FnP9BZFbwhOkgiMim9s5upRqCYRs%2F 
<https://secure-web.cisco.com/13EK5pT1X

[regext] using experimental to move items forward

[Andrew Newton (andy)]

Hi all,

When I look at the DNSOP working group I see items like CDS 
bootstrapping and generalized NOTIFY are nearing completion. They have 
even spun off another working group recently. Comparing that to the 
progress here, it seems that in REGEXT we don’t make as much progress.


Given the different perspectives, I’d like to propose a change in our 
working group process inspired by mailmaint [1], sidrops [2], and idr 
[3]. The basic proposal is to adopt the SIDROPS/IDR thresholds but with 
a lower bar for all RDAP extensions: before publication on the standards 
track there must be at least one interoperable server and client 
implementation documented with an implementation report published on the 
working group wiki [4]. Otherwise the extension may be published as 
experimental with the proviso that it could be put back on the standards 
track once interoperability between a client and a server is documented. 
And in special circumstances, the chairs could waive this requirement.


Note that in the SIDROPS and IDR examples above, there's nothing in the 
working group charter that requires these interoperable implementations. 
We might be able to do this in REGEXT without a charter change, too. 
Following their lead, we would publish this proposal to the REGEXT wiki [4].


-andy


[1] https://datatracker.ietf.org/wg/mailmaint/about/
[2] https://wiki.ietf.org/en/group/sidrops
[3] https://wiki.ietf.org/group/idr
[4] https://wiki.ietf.org/group/regext


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

[regext] Re: draft-ietf-regext-epp-eai update

[Andrew Newton (andy)]

On 6/12/24 10:37, Hollenbeck, Scott wrote:


*/If "mail system support for SMTPUTF8 addresses isn't ubiquitous" 
isn't a given, then both use cases can be approached differently. If 
it is a given, we have a requirement to continue to support exchange 
of all-ASCII email addresses. An extension can be defined to add 
support for the exchange of an optional SMTPUTF8 address, but we can’t 
eliminate the need for an all-ASCII address./*




I would use the word "reliable" instead of "ubiquitous". It does not 
seem reasonable for us to create complexity for something that hasn't 
and likely will not happen, so this seems right to me.


I was under the impression that we had decided this or a similar path 
was the way to go back in August.


https://mailarchive.ietf.org/arch/msg/regext/6R0bkJM0I3lMJf8kH3d8s4TqEiQ/

-andy

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

[regext] Re: sacrificial hosts in epp-delete bcp

[Andrew Newton (andy)]

On 6/11/24 10:40, Hollenbeck, Scott wrote:

Thanks for the feedback, Andy. More below.


-Original Message-
From: Andrew Newton (andy) 
Sent: Monday, June 10, 2024 4:58 AM
To: regext@ietf.org; Hollenbeck, Scott 
Subject: [EXTERNAL] sacrificial hosts in epp-delete bcp

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,

Section 6.2 of the EPP Delete BCP discusses the proposed best practices, with
section 6.2.2 referencing back to 5.1.7. However, 5.1.7 mentions possible
names such as sacrificial.invalid or a proposed new reserved TLD such as
.sacrificial. For implementation purposes, I think 6.2.2 should be a little more
prescriptive in the name to use, especially since .sacrificial is not currently 
a
special-use TLD nor does this document make it one. In other words, I think
6.2.2 should RECOMMEND a name or name pattern. I don't know if we always
want the practice to be "sacrificial.invalid" or allow "my-special-
stuff.sacrificial.invalid" or "i-delete-domains.invalid", but allowing each
registrar to make up their own name may have a downside (speculation on my
part).

[SAH] Yes, we could make a specific recommendation in 6.2.2. What should that 
recommendation be, though? I'm leaning towards a recommendation for community 
action to identify the most appropriate special use domain.


My preference would be to recommend "sacrificial.invalid" as getting a 
special-use TLD would take time and I don't know what it offers over 
"sacrificial.invalid". But I don't have a strong preference other than 
we should be more specific about what to use.






If there is no specific SLD such as "sacrificial.invalid", then it might make 
sense
to also have a new EPP and RDAP status of "sacrificial" to help identify these
hosts.

[SAH] We could do that for RDAP, but EPP status values are defined in the 
associated RFCs. They're not registered with IANA.


Good point, and this doesn't seem worth the effort without an EPP 
component. We can always revisit this later if it matters.


-andy


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

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

[Andrew Newton (andy)]

On 6/11/24 07:57, kowa...@denic.de wrote:


Hi,

I think the issue of JSONPath not being easy/possible to interpret in 
case of removed paths was brought up on the mailing list and the 
conclusion was to key off the "redacted name" rather than base on 
JSONPath [1].


This is also what has been covered in 5.1.1 with a clear 
recommendation for the client implementers. Not enough?


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


Section 5 is not normative. And the text says "The client can key off 
the "name" member for display logic related to the redaction." But there 
is no explanation of how to do it. And the words "display logic" imply 
it can be used for an algorithmic method, such as bold red text saying 
"REDACTED" where the information would have been placed.


I think any fair reading of this RFC implies the extension provides a 
programmatic means using algorithms to "explicitly specify which RDAP 
fields are not included in the RDAP response due to redaction" (that is 
from section 1, paragraph 1).


The very first prose of this RFC, the abstract, says:

This document describes a Registration Data Access Protocol (RDAP) 
extension for specifying methods of redaction of RDAP responses and 
explicitly identifying redacted RDAP response fields, using JSONPath as 
the default expression language.


WRT to redaction by removal, section 3.1 describes it but does not state 
that prePath is optional (that is in section 4.2), and the example given 
in 3.1 uses prePath.


-andy


p.s. I just reread the archived message above, and it looks like you 
identified these issues two years ago. My apologies for a lack of 
understanding back then.


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

[regext] confirmation of changes to draft-ietf-regext-epp-ttl during WGLC

[Andrew Newton (andy)]

Hi all,

As document shepherd, the chairs have asked me to confirm on this list 
that all comment received during WGLC, including the DNSDIR comments, 
have been addressed and to confirm on the list that all changes from #08 
to #11 are not material.


I note that the following editorial changes from James Gould are not 
reflected in the current document, probably due to other edits in these 
areas during WGLC. In my opinion, these editorial edits are helpful and 
I suggest they be added when next this document is revised.


Item 1:

Text in 1.2.1.2.1 paragraph 3, proposed by James Gould:

CURRENT:

A server which implements host objects which receives a command which 
attempts to set TTL values for A and  records on a domain object 
MUST respond with a 2004 "Parameter value range" error.


PROPOSED:

A server supporting host objects which receives a command that attempts 
to set TTL values for A and  records on a domain object MUST respond 
with a 2004 "Parameter value range" error.


Item 2:

Text in 2.1.1.1 paragraph 1, James Gould proposed quoting the word 
"policy". Additionally, the phrase "EPP response contain MUST contain" 
should probably be "EPP response MUST contain".


Item 3:

Text in 2.1.1.2 paragraph 1, same issue as Item 2.



Regarding material changes, I note the following in Section 5.2 of the 
additional sentence to the end of paragraph 2:



The latency between receipt of the  command and the actual 
publication of the changes in the DNS should also be taken into 
consideration in this calculation.



As this sentence nor this section contain normative language, in my 
opinion this is not a material change.



-andy

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

[regext] sacrificial hosts in epp-delete bcp

[Andrew Newton (andy)]

Hi Scott,

Section 6.2 of the EPP Delete BCP discusses the proposed best practices, 
with section 6.2.2 referencing back to 5.1.7. However, 5.1.7 mentions 
possible names such as sacrificial.invalid or a proposed new reserved 
TLD such as .sacrificial. For implementation purposes, I think 6.2.2 
should be a little more prescriptive in the name to use, especially 
since .sacrificial is not currently a special-use TLD nor does this 
document make it one. In other words, I think 6.2.2 should RECOMMEND a 
name or name pattern. I don't know if we always want the practice to be 
"sacrificial.invalid" or allow "my-special-stuff.sacrificial.invalid" or 
"i-delete-domains.invalid", but allowing each registrar to make up their 
own name may have a downside (speculation on my part).


If there is no specific SLD such as "sacrificial.invalid", then it might 
make sense to also have a new EPP and RDAP status of "sacrificial" to 
help identify these hosts.


-andy

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

[regext] Re: regext - New Meeting Session Request for IETF 120

[Andrew Newton (andy)]

On 6/5/24 04:58, Mario Loffredo wrote:
- in light of Andy's feedback on RFC9537 and repeating what I had 
already written in this thread 
, 
do believe that representing collections in contact data through maps 
instead of arrays (or worse arrays of arrays) would greatly simplify 
the JSONPath expressions used in redaction as the name selector would 
be mostly used in place of index selectors and filters



And so I request time to discuss 
draft-newton-regext-rdap-considerations-on-rfc9537-00.


As this is a very complicated topic, I think it would require enough 
time to both present it and have enough time for a proper Q&A.


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

[regext] Re: regext - New Meeting Session Request for IETF 120

[Andrew Newton (andy)]

Given the interims that never materialized, the discussions on EPP over 
REST/HTPP/QUIC, the drafts on IDNS that are expected, and the recent 
issues on RDAP redaction, would it be wise to also ask for an additional 
1 hour slot?


-andy

On 6/3/24 10:40, IETF Meeting Session Request Tool wrote:


A new meeting session request has just been submitted by Antoin Verschuren, a
Chair of the REGEXT Working Group.


-
Working Group Name: Registration Protocols Extensions
Area Name: Applications and Real-Time Area
Session Requester: Antoin Verschuren


Number of Sessions: 1
Length of Session(s): 2 Hours
Number of Attendees: 50
Conflicts to Avoid:
  Chair conflict: dnsop dance saag sidrops savnet grow deleg
  Key participant conflict: dispatch secdispatch





Participants who must be present:

Resources Requested:

Special Requests:
   
-



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


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

[regext] Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

[Andrew Newton (andy)]

Hi all,

Over the past several months, we have been implementing the RDAP 
redaction extension, RFC 9537.


This I-D describes the issues we have encountered.

-andy



 Forwarded Message 
Subject: 	New Version Notification for 
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

Date:   Wed, 29 May 2024 03:45:43 -0700
From:   internet-dra...@ietf.org
To: Andy Newton 



A new version of Internet-Draft
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt has been
successfully submitted by Andy Newton and posted to the
IETF repository.

Name: draft-newton-regext-rdap-considerations-on-rfc9537
Revision: 00
Title: Considerations on RFC 9537
Date: 2024-05-29
Group: Individual Submission
Pages: 12
URL: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-considerations-on-rfc9537/
HTML: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-considerations-on-rfc9537



Abstract:

This document discusses client implementation issues relating to RFC
9537, “Redacted Fields in the Registration Data Access Protocol
(RDAP) Response”. The considerations in this document have arisen
from problems raised by two separate teams attempting to implement
RFC 9537 in both an RDAP web client and an RDAP command line client.
Some of these problems may be insurmountable, leaving portions of RFC
9537 non-interoperable between clients and servers, while other
problems place a high degree of complexity upon clients.



The IETF Secretariat

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

[regext] redacted examples

[Andrew Newton (andy)]

Hi all,

For those doing development for RFC 9537, I have a github repository 
with some examples that may be useful.


https://github.com/anewton1998/redacted_examples

-andy

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

[regext] Re: [Ext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-02.txt

[Andrew Newton (andy)]

On 5/9/24 15:33, Hollenbeck, Scott wrote:
[SAH] The context is given in the Section title and the included back 
references. They're proposed best practices. The back-referenced text 
that describes each practice notes that they haven't been observed in 
operation. We could add something like "The practices in this section 
are described as "best practices" because they address the operational 
risk and have been observed in operation" to 6.1 and "The practices in 
this section are described as "proposed best practices" because they 
address the operational risk and haven't been observed in operation" 
to 6.2. Would that help?



Thanks for this clarification.

But now for the big question: while the practice described in 5.1.9. 
"Renaming to a Host Object Maintained by the Client" is a current 
practice, is it really a "best" current practice? As the text suggests, 
it is the breakdown of this practice that leads to Risky-Bizness domain 
hijacks.



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

Re: [regext] Registration Protocols Extensions (regext) WG Interim Meeting: 2024-05-07

[Andrew Newton (andy)]

On Fri, May 3, 2024 at 1:57 PM Hollenbeck, Scott
 wrote:
>
> > My rough, rough understanding is that EPP needs extensions for registrars to
> > know if an IDN variant is available, blocked but unallocated to another
> > registrant, or actually available.
>
> [SAH] OK, but that doesn't explain why a topic for which there's been no 
> prior on-list discussion is on the agenda for an interim meeting. Would 
> whomever asked to have it added please give us some information so we can 
> prepare?

I agree that presentation material should be made available ahead of time.

If I am correct regarding the topic, I believe Gavin Brown gave a
presentation at IETF-last-Praque.

-andy

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

Re: [regext] Registration Protocols Extensions (regext) WG Interim Meeting: 2024-05-07

[Andrew Newton (andy)]

My rough, rough understanding is that EPP needs extensions for
registrars to know if an IDN variant is available, blocked but
unallocated to another registrant, or actually available.

-andy

On Fri, May 3, 2024 at 10:25 AM Hollenbeck, Scott
 wrote:
>
> > -Original Message-
> > From: regext  On Behalf Of IESG Secretary
> > Sent: Wednesday, May 1, 2024 11:37 AM
> > To: IETF-Announce 
> > Cc: regext@ietf.org
> > Subject: [EXTERNAL] [regext] Registration Protocols Extensions (regext) WG
> > Interim Meeting: 2024-05-07
> >
> > 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 Registration Protocols Extensions (regext) WG will hold an interim 
> > meeting
> > on 2024-05-07 from 10:45 to 12:30 Europe/Paris (08:45 to 10:30 UTC).
> > Meeting Location: Paris, FR
> >
> >
> > Agenda:
> > 1. IDN Variants - soon to be new work in REGEXT, an extension for EPP and
> > RDAP
>
> [SAH] Would someone please explain what this  is?
>
> 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

[regext] quasi-technical terms (was Re: [Ext] Re-chartering REGEXT?)

[Andrew Newton (andy)]

On 4/25/24 08:10, Maarten Wullink wrote:
Improved scalability is one the stated goals and It’s true that just 
by adding HTTP support, EPP would be able to leverage all of the 
scalability features provided by HTTP.


However, by using named resources in the URL (as is a feature of REST) 
it would also be possible to include more advanced forms of load 
balancing, such as routing requests based on the request URL pattern. 
An example would be a configuration where informational requests such 
the CHECK and INFO are separated from the creational requests such as 
CREATE and UPDATE.


And there’s also the other benefits linked to using RESTful APIs as 
described.


To add to this point, cloud providers have many managed services geared 
towards helping smaller organizations that use REST-like services such 
as REPP. For example, REPP would allow a registry to use Web Application 
Firewalls (WAF) and Application Load Balancers (ALB). The separation of 
concerns also allows using managed security services for more granular 
control. And finally, the long-running TCP (or HTTP) sessions can't take 
advantage of the elastic container services in the same way REPP can.


While current industry players have already built out their 
infrastructure, for new entrants the ability to use these managed 
services greatly reduces overhead costs thus encouraging new market 
entrants.


Yes, you are correct that REST is an architectural style and nothing 
more, i should not have used “layered” for REST, only for HTTP


Adding HATEOS was something we considered, the idea behind HATEOS is 
to allow a server to be able to change the resource names without 
breaking a client implementation, which may be useful in 
non-standardized API’s. We decided that it would not be useful in the 
context of EPP because when URL resources are defined in an IETF 
standard, they are not very likely to change very often (if ever),
And adding HATEOS would make the implementation more complex and bloat 
server responses, also the vast majority of "RESTful” APIs do not 
implement HATEOS.


for those interested here is an interesting blog about this topic:
https://www.ben-morris.com/pragmatic-rest-apis-without-hypermedia-and-hateoas/


Excellent link. Everybody should read that.

I agree with the decision to avoid HATEOS. We did that for RDAP as well, 
and RDAP is frequently described as "RESTful". I actually prefer the 
term "REST-like" but I also don't know if it really matters.



Agree, and it is our goal to be 100% compatible with “standard EPP” on 
this point.


This is a good goal. The hardest part about adopting a new protocol will 
not be the bits over the wire (call it a transport if you want) but 
changing data models and business practices. By re-using EPP, those 
problems can be avoided.



-andy

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

Re: [regext] Re-chartering REGEXT?

[Andrew Newton (andy)]

Thanks George. I agree.

-andy

On Mon, Apr 15, 2024 at 4:14 PM George Michaelson  wrote:
>
> I don't think the new protocol is just a new transport *LAYER* but I
> also do support re-charter to include consideration of this protocol
> suite.
>
> My reasoning is that we're the people who are going to wind up having
> to talk about it. Of course it's irritating from a perspective of RDAP
> and EPP proponents to see more work jammed into this WG and I actually
> generally dislike charter extension, but the context is clear:
>
> The protocol is in the registry-registrar and client-registrar
> interaction space we work on.
>
> G
>
> On Tue, Apr 16, 2024 at 3:37 AM Gould, James
>  wrote:
> >
> > Andy,
> >
> > REPP is not a transport, but a new provisioning protocol that is not 
> > supported in the existing charter.  If you believe REPP is a transport, 
> > please describe how it complies with section 2.1 of RFC 5730.
> >
> > Thanks,
> >
> > --
> >
> > JG
> >
> >
> >
> > James Gould
> > Fellow Engineer
> > jgo...@verisign.com 
> > 
> >
> > 703-948-3271
> > 12061 Bluemont Way
> > Reston, VA 20190
> >
> > Verisign.com <http://verisigninc.com/>
> >
> >
> >
> >
> > On 4/15/24, 1:20 PM, "regext on behalf of Andrew Newton (andy)" 
> > mailto:regext-boun...@ietf.org> on behalf of 
> > a...@hxr.us <mailto: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.
> >
> >
> > Maarten,
> >
> >
> > I think proposing some charter text is a good idea.
> >
> >
> > And I support this if the charter is to be used to exclude some
> > proposals for EPP transports but not others, as has been argued.
> >
> >
> > -andy
> >
> >
> > On Thu, Apr 11, 2024 at 11:59 PM Maarten Wullink
> >  > <mailto:40sidn...@dmarc.ietf.org>> wrote:
> > >
> > > Hello everyone,
> > >
> > > The REGEXT WG charter seems to be limited to only allow work on EPP 
> > > extensions?
> > >
> > > The WG preliminary consensus is that updating the charter for new 
> > > transports (requires RFC5730, sec 2.1 compliance) is not required.
> > > Because a new transport is regarded as a type of extension, so for 
> > > anything else we would need to update the charter?
> > >
> > > This means there is no defined process anywhere, currently, for EPP 
> > > related work, such as RESTful EPP (or anything else that is not a 
> > > extension),
> > > which according to some in this WG is not a transport but something else.
> > >
> > > RESTful EPP does not require modification of the EPP RFCs, it does 
> > > include support for alternative data representations such as JSON.
> > >
> > > The participants of this WG are the experts in this area, and the right 
> > > people to also work on improvements and/or enhancements of the EPP 
> > > protocol and new work such as RESTful EPP.
> > >
> > > Therefore, I propose that we expand the charter of this WG to also 
> > > include the above-mentioned activities e.g. not strictly limiting the WG 
> > > to extensions only.
> > >
> > > I’m willing to help in updating the charter if this something we agree on 
> > > doing.
> > >
> > > Best,
> > >
> > > Maarten
> > >
> > > --
> > > ps:
> > >
> > > The previous version of the charter included text, that did allow work on 
> > > more than extensions only:
> > >
> > > “The working group may also, in consultation with its responsible area
> > > director, take on work related to the operation of Internet identifier
> > > registries, beyond the EPP and RDAP protocols.”
> > >
> > > See: 
> > > https://secure-web.cisco.com/1pZ9xY4B2hhezD1LASpYU9C9QLU_I8ijwDhrAONiX2WujSy1_vkXH6R3dC-XOs3hs8GhnjSqn4hoIrURMcauciMp2aW9yObvXrtcQfNn5y39QAI_y_nrDueqrchdGrckElb2y8uY6jnSOVocfgGUy3JGWGYYRDY4eaaVGYW4p0HCiWXl_U-V5l_hWGXcSEavgzX-crhYmdNvhH-u2THur7He9dDY47ixzEm4kaOgHenXF4Mjj6Xw63FB7TA6StLsEn1cH4ZzXrkRso6sqhMOPIxW0M12SiAp3Az1rqdgYd_E/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-regext%2F01-00%2F
> > >  
> > > <https://secure-web.cisco.com/1pZ9xY4B2hhezD1LASpYU9C9QLU_I8ijwDhrAONiX2WujSy1_vkXH6R3dC-XOs3hs8

Re: [regext] Re-chartering REGEXT?

[Andrew Newton (andy)]

Maarten,

I think proposing some charter text is a good idea.

And I support this if the charter is to be used to exclude some
proposals for EPP transports but not others, as has been argued.

-andy

On Thu, Apr 11, 2024 at 11:59 PM Maarten Wullink
 wrote:
>
> Hello everyone,
>
> The REGEXT WG charter seems to be limited to only allow work on EPP 
> extensions?
>
> The WG preliminary consensus is that updating the charter for new transports 
> (requires RFC5730, sec 2.1 compliance) is not required.
> Because a new transport is regarded as a type of extension, so for anything 
> else we would need to update the charter?
>
> This means there is no defined process anywhere, currently, for EPP related 
> work, such as RESTful EPP (or anything else that is not a extension),
> which according to some in this WG is not a transport but something else.
>
> RESTful EPP does not require modification of the EPP RFCs, it does include 
> support for alternative data representations such as JSON.
>
> The participants of this WG are the experts in this area, and the right 
> people to also work on improvements and/or enhancements of the EPP protocol 
> and new work such as RESTful EPP.
>
> Therefore, I propose that we expand the charter of this WG to also include 
> the above-mentioned activities e.g. not strictly limiting the WG to 
> extensions only.
>
> I’m willing to help in updating the charter if this something we agree on 
> doing.
>
> Best,
>
> Maarten
>
> --
> ps:
>
> The previous version of the charter included text, that did allow work on 
> more than extensions only:
>
> “The working group may also, in consultation with its responsible area
> director, take on work related to the operation of Internet identifier
> registries, beyond the EPP and RDAP protocols.”
>
> See: https://datatracker.ietf.org/doc/charter-ietf-regext/01-00/
>
> This was modified for the current charter, but still not very specific and 
> may allow for work on RESTful EPP?
>
> "The working group may also take on work to develop specifications that
> describe the following types of information exchanged between entities
> involved in Internet identifier registration that are using the RDAP or
> EPP protocols:
> • Uniform representation formats for publishing local policy or
> configuration options regarding EPP and RDAP use.
> • Data formats for files exchanged between registration entities that
> need insertion in or extraction from EPP or RDAP.
> • Technical guidance for registration processes that are supported by
> EPP or RDAP.”
>
>
> ___
> 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] using subdomains in RDAP bootstrap

[Andrew Newton (andy)]

Hi Dmitry,

You can use redirects as described by section 5.2 of RFC 7480:

https://datatracker.ietf.org/doc/html/rfc7480#section-5.2

Redirects are commonly used in the RIR/INR space for IP addresses and 
ASNs and, as you have pointed out, the domain space for zones below the 
TLD level.


I hope this helps.

-andy

On 4/8/24 11:09, Dmitry Kohmanyuk wrote:

Hello everyone,

As a long-time lurker on regext@ and an infrequent participant in IETF 
meetings, I apologize if I missed something.  We have a practical issue with 
RDAP.

My registry, Hostmaster.UA have implemented RDAP for UA (URL: 
https://rdap.hostmaster.ua/, as included into IANA bootstrap.) Similarly to say 
UK we have multiple public suffixes where domains are registered, such as 
com.ua net.ua odesa.ua etc.

The trouble is, some of these domains are not managed by us;  let’s say that 
alice.ua would have rdap.alice.ua,  and bob.ua, rdap.bob.ua whereas com.ua 
would use IANA bootstrap element. Now, I want RDAP service to be as seamless as 
possible.

How can we implement this?  IANA JSON registry only has TLDs.  I can of course 
create my own bootstrap file but I cannot imagine practical way of informing 
RDAP clients of it’s existence.  I can use HTTP codes “moved permanently” when 
answering RDAP queries on our server.  (I can query the other server myself and 
serve the response; bad idea.)

Is there a most effective way to do it? Thanks!


___
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] draft-ietf-regext-rdap-geofeed-02 Review Feedback

[Andrew Newton (andy)]

Hi Jasdip,

Comments in-line

On Mon, Mar 25, 2024 at 7:25 PM Jasdip Singh  wrote:
>
> [JS] It seems the “marker” extension type from the RDAP Extensions draft [1] 
> should cover this extension since marker extensions “exist to denote the 
> usage of values placed into an IANA registry” and we are doing so for the new 
> geofeed link with new IANA registry values for link relation type and media 
> type, and would for redaction as well (per your suggestion below). However, 
> it might be helpful to expand the definition of a marker extension in that 
> draft to include this use case where an extension is simply based on new 
> links, instead of new fields and/or paths.

I agree with this.

>
>
>
> I'm curious whether the "geo" type could be used for other RDAP objects 
> (existing or new).
>
>
>
> [JS] If you meant the “geo” link relation type, then yes, it could be used to 
> define new geographical web links. But one would need to define a new RDAP 
> extension with a new media type (say, representing location information for 
> an organization).
>
>
>
> Should the draft be made more generic to apply to any RDAP object, inclusive 
> of the IP Network object class?
>
>
>
> [JS] That’s an interesting idea but since this extension aligns with RFC 
> 9092bis [2] and the geofeed semantics are closely tied with IP networks, only 
> the IP Network object class is extended here. However, that doesn’t impede 
> such semantics from getting imported into other object classes if an IP 
> Network object is included within. For example, “networks” within an Entity 
> object. But that’s the extent of it.
>
>
>
> Wouldn't it be better to have the extension identifier set to "geo" to match 
> the new "rel" type used by the extension?
>
>
>
> [JS] We went back-n-forth on this and settled on “geofeed1” for extension 
> identifier, “geo” for rel type, and “geofeed” subtype for the new media type. 
> Both the extension identifier and media type have the “geofeed” literal in 
> them because they tightly connote the geofeed semantics. However, per our 
> interpretation of the guidance from section 2.1.1 of RFC 8288 [3], the rel 
> type is intentionally set to a more generic “geo” name to connote “a lint 
> context having a resource with some geographic information at the link 
> target”, thereby allowing other geofeed media types, or media types 
> representing some other geographic information, to be registered in the 
> future.
>
>
>
> (For the record, Massimo Candela (one of the RFC 9092bis authors) suggested 
> using the “geofeed” rel type to avoid any confusion and tightly tie the rel 
> type to the media type. We explained the rationale for using “geo” and there 
> was no further discussion on this.)

Also agreed.

>
>
>
> I'm unsure whether there is the need to redefine the "links" JSON values that 
> is defined in Section 4.2 of RFC 9083 other than the use of the "rel" value 
> of "geo" and the recommendation to use "application/geofeed+csv" for the 
> "type" value.
>
>
>
> [JS] OK, we can remove the “value” and “hreflang” explanations here and 
> instead start with pointing to section 4.2 of RFC 9083 and then explaining 
> “rel”, “href”, and “type” since they detail the constitution of a geofeed 
> link.
>
>
>
> I recommend including a registration of the "Geofeed links" redacted "name" 
> in the RDAP JSON Values registry with the "redacted name" type field.  If 
> registered, the "description" member can be changed to a "type" member.
>
>
>
> [JS] Good idea. Will do.

Is this really necessary? Under what conditions will a network
operator be publishing this public CSV file that then requires an RIR
to redact the link to it?

-andy

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

Re: [regext] EPP evolution and the REGEXT charter

[Andrew Newton (andy)]

James,

If you wish to persist this line of reasoning whereby your drafts are
in charter but REPP is not due to an unorthodox definition of what is
and what is not an EPP extension, be aware that there is plenty of
text in the current RFCs that define more strictly the nature of an
EPP extension.

I also take a more inclusive view that REPP could be covered under the
latter section of the regext charter, specifically in that it defines
XML and/or JSON files, exchanged over HTTP, between registration
entities that need insertion in or extraction from EPP or RDAP.

-andy

On Fri, Mar 22, 2024 at 8:01 AM Gould, James  wrote:
>
> Andy,
>
> It's not a question of fairness, but a question of what is defined in EPP RFC 
> 5730 as it comes to extensibility of EPP.  EPP RFC 5730 includes 
> extensibility of transport, as reflected in Section 2.1.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
>
> On 3/22/24, 7:40 AM, "Andrew Newton (andy)"  <mailto: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.
>
>
> I am against any logic that creates different gating factors for the
> different, competing solutions. Any contortion of the concept of an
> EPP "extension" that results in the favor of one set of drafts over
> the other is obviously unfair.
>
>
> -andy
>
>
> On Fri, Mar 22, 2024 at 5:33 AM Mario Loffredo
>  <mailto:40iit.cnr...@dmarc.ietf.org>> wrote:
> >
> > Hi Jasdip,
> >
> >
> > IMO, REPP is not an "EPP extension" as defined by RFC5730. It provides 
> > neither just a switch of transport (like EoH and EoQ) nor an extension to 
> > EPP comands and responses.
> >
> > Instead, it presents a full revision of EPP that maps some EPP features 
> > onto HTTP features.
> >
> > Moreover, the current proposal is incompatible with some existing or future 
> > documents including extensions to EPP query commands (see Jody's question 
> > at last meeting about REPP compatibility with the Fee Extension).
> >
> > On the contrary, in the spirit of achieving a full compliance with RFC5730, 
> > .it is going to update its EPP implementation that has been working since 
> > 2009.
> >
> >
> > With regard to a possible RegExt rechartering, I also don't think we need 
> > it.
> >
> > RFC5730 already allows for implementing EPP over multiple transports. But 
> > it does even more, it makes some examples of possible alternatives to TCP.
> >
> > Therefore, leaving aside for the moment the debate about considering a new 
> > transport as an extension or not, it would be paradoxical if the protocol 
> > itself admitted other transports than TCP but it wouldn't be allowed to 
> > standardize them just like it has been done for TCP :-(
> >
> >
> > Best,
> >
> > Mario
> >
> >
> > Il 22/03/2024 01:12, Jasdip Singh ha scritto:
> >
> > Hi.
> >
> >
> >
> > Curious if the newly proposed “RESTful EPP” is considered a new protocol 
> > that is different from EPP, or is it an “extension” of EPP? (AFAICT, the 
> > former seems outside the current regext charter.)
> >
> >
> >
> > Thanks,
> >
> > Jasdip
> >
> >
> >
> > From: regext mailto:regext-boun...@ietf.org>> on 
> > behalf of Hollenbeck, Scott  > <mailto:40verisign@dmarc.ietf.org>>
> > Date: Friday, March 22, 2024 at 9:56 AM
> > To: jgould=40verisign@dmarc.ietf.org 
> > <mailto:40verisign@dmarc.ietf.org> 
> >  > <mailto:40verisign@dmarc.ietf.org>>, 
> > maarten.wullink=40sidn...@dmarc.ietf.org <mailto:40sidn...@dmarc.ietf.org> 
> >  > <mailto:40sidn...@dmarc.ietf.org>>, regext@ietf.org 
> > <mailto:regext@ietf.org> mailto:regext@ietf.org>>
> > Subject: Re: [regext] EPP evolution and the REGEXT charter
> >
> > From: regext mailto:regext-boun...@ietf.org>> On 
> > Behalf Of Gould, James
> > Sent: Thursday, March 21, 2024 7:49 PM
> > To: maarten.wullink=40sidn...@dmarc.ietf.org 
> > <mailto:40sidn...@dmarc.ietf.org>; regext@ietf.org <mailto:regext@ietf.org>
> > Subject: [EXTERNAL] Re: [regext] EPP evolution and the REGEXT charter
> >
> >
> >
> &g

Re: [regext] EPP evolution and the REGEXT charter

[Andrew Newton (andy)]

I am against any logic that creates different gating factors for the
different, competing solutions. Any contortion of the concept of an
EPP "extension" that results in the favor of one set of drafts over
the other is obviously unfair.

-andy

On Fri, Mar 22, 2024 at 5:33 AM Mario Loffredo
 wrote:
>
> Hi Jasdip,
>
>
> IMO, REPP is not an "EPP extension" as defined by RFC5730. It provides 
> neither just a switch of transport (like EoH and EoQ) nor an extension to EPP 
> comands and responses.
>
> Instead, it presents a full revision of EPP that maps some EPP features onto 
> HTTP features.
>
> Moreover, the current proposal is incompatible with some existing or future 
> documents including extensions to EPP query commands (see Jody's question at 
> last meeting about REPP compatibility with the Fee Extension).
>
> On the contrary, in the spirit of achieving a full compliance with RFC5730, 
> .it is going to update its EPP implementation that has been working since 
> 2009.
>
>
> With regard to a possible RegExt rechartering, I also don't think we need it.
>
> RFC5730 already allows for implementing EPP over multiple transports. But it 
> does even more, it makes some examples of possible alternatives to TCP.
>
> Therefore, leaving aside for the moment the debate about considering a new 
> transport as an extension or not, it would be paradoxical if the protocol 
> itself admitted other transports than TCP but it wouldn't be allowed to 
> standardize them just like it has been done for TCP :-(
>
>
> Best,
>
> Mario
>
>
> Il 22/03/2024 01:12, Jasdip Singh ha scritto:
>
> Hi.
>
>
>
> Curious if the newly proposed “RESTful EPP” is considered a new protocol that 
> is different from EPP, or is it an “extension” of EPP? (AFAICT, the former 
> seems outside the current regext charter.)
>
>
>
> Thanks,
>
> Jasdip
>
>
>
> From: regext  on behalf of Hollenbeck, Scott 
> 
> Date: Friday, March 22, 2024 at 9:56 AM
> To: jgould=40verisign@dmarc.ietf.org 
> , 
> maarten.wullink=40sidn...@dmarc.ietf.org 
> , regext@ietf.org 
> Subject: Re: [regext] EPP evolution and the REGEXT charter
>
> From: regext  On Behalf Of Gould, James
> Sent: Thursday, March 21, 2024 7:49 PM
> To: maarten.wullink=40sidn...@dmarc.ietf.org; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] EPP evolution and the REGEXT charter
>
>
>
> 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.
>
> Maarten,
>
>
>
> The charter refers to EPP extensions, which transports is a form of an EPP 
> extension.  RFC 5730 defines the extension points for EPP and includes 
> support for extending the transports based on Section 2.1 “Transport Mapping 
> Considerations”.  I don’t believe that there is a need to revise the REGEXT 
> charter to support the additional of new EPP transports.
>
> [SAH] Agreed. New transport mappings are just another type of extension as 
> long as they preserve the data model described in RFC 5730.
>
>
>
> Scott
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
> --
> Dott. Mario Loffredo
> Senior Technologist
> 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] EPP Transport Service Discovery

[Andrew Newton (andy)]

Registries have a financial incentive to make sure registrars are kept
up to date, so your experience is almost certainly the norm. And I
agree that any service discovery mechanism that gets complicated is
not worth the effort in the registry/registrar space.

That said, George's idea of using an SVCB record seems pretty
straightforward and is low effort.

-andy


On Wed, Mar 20, 2024 at 9:14 PM Tobias Sattler
 wrote:
>
> +1
>
> During my 14-year tenure on the registrar side, where we implemented almost 
> every gTLD and many ccTLDs, I always felt well-informed by registries if they 
> intended to make substantial changes. While this feature seems nice, I don’t 
> know if the effort is worth it.
>
> Best,
> Tobias
>
> On 20. Mar 2024, at 12:59, Jody Kolker  
> wrote:
>
> Just adding my 2 cents.
>
>
>
> It seems that designing and implementing a discovery system seems to be a bit 
> complicated and will take some time to design and complete.  Every registry 
> will be contacting registrars when a new system is enabled, or at least 
> should be.  I don’t see a huge benefit of adding a service discovery system 
> compared to the amount of time it will take to design and implement.  I would 
> rather we spend our time defining the separate transport system than 
> designing a discovery system.
>
>
>
>
>
> Thanks,
> Jody Kolker
> 319-329-9805  (mobile)
>
>
>
> Please contact my direct supervisor Scott Courtney (scourt...@godaddy.com) 
> with any feedback.
>
> This email message and any attachments hereto is intended for use only by the 
> addressee(s) named herein and may contain confidential information. If you 
> have received this email in error, please immediately notify the sender and 
> permanently delete the original and any copy of this message and its 
> attachments.
>
>
>
> From: regext  On Behalf Of Steve Crocker
> Sent: Wednesday, March 20, 2024 5:11 AM
> To: Hollenbeck, Scott 
> Cc: regext@ietf.org
> Subject: Re: [regext] EPP Transport Service Discovery
>
>
>
> 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@.
>
>
>
> Scott, et al,
>
>
>
> This seems to me an excellent idea, but let me suggest adding a bit more 
> content.
>
>
>
> And before doing so, let me acknowledge that a registry will likely inform 
> its registrars well in advance of any changes and will likely provide a test 
> system for registers to use in advance of a cutover to a new transport 
> system.  But rather than depending on this alone, an automated process for 
> discovering the transport will be very helpful.
>
>
>
> And now for the added content:
>
>
>
> If a registry upgrades to a new transport method, it will likely operate both 
> the old and new transport for a period of time.  Indeed, it might even 
> support three or more transport methods during some periods.  Accordingly, 
> the response to a service discovery query will likely contain multiple 
> answers.  Each answer should also include a flag indicating whether it is a 
> preferred method.
>
>
>
> But wait, there's more.
>
>
>
> Each transport method will go through a lifecycle.  The transport method 
> lifecycle has the following states.
>
>
>
> A. Announcement that the method will be supported in the future.  (Including 
> the anticipated date is a good idea, but the date should be interpreted as a 
> guess, not a certainty.)
>
>
>
> B. Announcement that the method is now supported.  Include the date it became 
> supported.  (A transport method in this state is "preferred."  There should 
> be at least one method in this state, but there could be more than one.)
>
>
>
> C. Announcement that the method that has been supported is scheduled to be 
> removed.  Include the estimated date of removal.  This will serve as notice 
> that any registrar still using the transport should move to another available 
> method that has reached state B.  (And, of course, there should indeed 
> already be at least one method in state B.)
>
>
>
> D. Announcement that the method will become unavailable on a specific date.  
> (All use of a method in this state should have ceased.  However, if the 
> method is still in use by a registrar, it will work.  The registry's system 
> or other monitoring systems can take note and escalate attention to the 
> appropriate managers,)
>
>
>
> E. Removal of the transport method from the set of answers.
>
>
>
> Extension of the proposal to include these states is easy.  Just add a flag 
> to indicate whether the transport method is in state A, B, C or D, and 
> include the date.
>
>
>
> Comments?
>
>
>
> Steve
>
>
>
>
>
> On Tue, Mar 19, 2024 at 7:11 PM Hollenbeck, Scott 
>  wrote:
>
> As noted during this morning’s regext session, we need to consider how a 
> client can discover the transport services provided by an EPP server. 
> Opportunistic probing is one method, another is server capability p

[regext] redacted implementation

[Andrew Newton (andy)]

Hi all,

For those implementers looking for something to test their RDAP
redaction implementations against, we just released v0.0.16 of the
ICANN RDAP packages.

https://github.com/icann/icann-rdap/releases/tag/v0.0.16

The icann-rdap-srv package can serve redacted RDAP information from
JSON files, and the icann-rdap-cli package will display redaction
policies. This is our initial release with redaction features. There
is more to come.

-andy

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

Re: [regext] [Ext] Re: RDAP and link context

[Andrew Newton (andy)]

On Tue, Mar 5, 2024 at 3:42 PM James Mitchell  wrote:
>

>
> The server can’t pre-compute a response where multiple URIs map to one object 
> – one has to patch any pre-computed response prior to sending back on the 
> wire. This is a use of compute resources for what seems to be no benefit. I 
> could have the response link the request.path to a canonical path, and anchor 
> links of that canonical path, but this seems like busywork.
>


Got it. Given that the only place that seems to define a link context
for RDAP is in a profile extension, I think you are free to set it to
any value you want absent your server signaling compliance with such
an extension. We can add some text to the RDAP extensions draft
regarding this.

But as Scott noted, 9083 is the successor of 7483 and a client may
regard your server's JSON as ill-formed without the presence of the
value.

-andy

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

Re: [regext] [Ext] Re: RDAP and link context

[Andrew Newton (andy)]

On Fri, Mar 1, 2024 at 6:57 PM James Mitchell  wrote:
>
>
> The new gTLD Response profile 
> (https://www.icann.org/en/system/files/files/rdap-response-profile-21feb24-en.pdf)
>  says … “a value with the RDAP lookup path that generated the RDAP 
> response.”, requirements 2.6.3 and 2.10. Unless you are referring to another 
> document, this is quite different from the RDAP base URL. I would interpret 
> requests under this profile for /domains/EXAMPLE.COM and /domains/example.com 
> to set the link context to /domains/EXAMPLE.COM and /domains/example.com 
> respectively (or less contrived, lookups for /domain/xn--bcher-kva and 
> /domain/b%C3%BCcher to have different link contexts)
>

I was thinking of 2.4.6 which sets the link context to the Base URL of
the registrar, which seems mighty useful. I agree with your
interpretation of 2.6.3 and 2.10

>
>
> It seems a shame that the spec did not allow the undefined link context to be 
> interpreted as the request URI. However we are where we are and the link 
> context is now mandatory. If someone can shed some light on the utility of 
> the link context then I can look to support that with our server. Otherwise 
> I’ll likely hold onto on the RFC 7483 requirements for links.
>

What's the issue with setting it to the request URI?

-andy

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

Re: [regext] [Ext] Re: Adding the DNS root to the bootstrap file

[Andrew Newton (andy)]

On Fri, Mar 1, 2024 at 6:36 PM James Mitchell  wrote:
>
> I’d say the matching logic is arguably incorrect – matching should begin with 
> the parent of the supplied domain name. However, I acknowledge this arguably 
> affects only queries for TLDs themselves, as a TLD’s RDAP server could 
> redirect down to a more specific registry where necessary.
>

It does need clarification.

>
>
> A second consideration is that the root entry will match domains where there 
> is no published RDAP server for that TLD. This will affect the behaviour 
> described in RFC 9224, Section 7 Non-existent Entries or RDAP URL Values 
> provides.
>
>
>
> I’m interested in your thoughts to whether the matching logic needs updating, 
> and whether guidance or changes to the bootstrap file can reduce lookups for 
> “non-existent entries” to the root, e.g. publishing an empty RDAP URL for 
> delegated TLDs.
>
>

I am not comprehending what you are asking with regard to non-existent
entries. Can you elaborate?
Also, if we are taking the time to fix up the matching logic, we
should probably reword section 7 as well.

-andy

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

Re: [regext] RDAP and link context

[Andrew Newton (andy)]

Hi James,

RFC 7483 did not require the 'value' attribute, however when the
standard was revised in RFC 9083 this attribute became required.

I believe you are correct that a link context is not well defined. It
is supposed to be the scope in which a link is to be understood. In a
JSON response full of all sorts of other things (such as an RDAP
response), that scope could be seen as the request URI that got that
JSON response. However, that is just one interpretation. The new gTLD
Response profile makes use of the 'value' attribute as the RDAP base
URL for registrars, which I think is also a fair interpretation of the
context of a link since the href is a specific URL that is a subset of
a large group of URLs in which the base URL is the parent.

If we want to start more strictly defining what that value should be,
I think the rdap-extensions document is a better place than the rdap-x
document. I don't know about making it optional again. Hopefully
others who have a clearer recollection of the 7483 -> 9083 transition
can provide better context - pun intended. :)

-andy

On Tue, Feb 27, 2024 at 6:56 PM James Mitchell  wrote:
>
> Hi all,
>
>
>
> What is the purpose of the context URI in the links structure? From 9083:
>
> The "value" JSON value is the context URI as described by [RFC8288]. The 
> "value", "rel", and "href" JSON values MUST be specified.
>
>
>
> My understanding is that the context URI is the request URI that generated 
> the JSON response. Implementing this correctly presents problems for a valid 
> server implementations given caching is non-trivial because one object can be 
> located from more than one URI. For example, /domain/EXAMPLE.COM, 
> /domain/example.com, /domain/eXaMpLe.cOm are all different context URIs even 
> though we understand they will return the same object. For a less trivial 
> example, consider a domain object matched by A-labels, U-labels, and any 
> other labels that identify an object via UTS46 or variant processing.
>
>
>
> I’ve surveyed a few registries and noted inconsistent implementations of the 
> spec:
>
> .org – link context is identical to the target for all links
> .com – link context is present for a singular self link and the context and 
> relation type are absent for links in notices
> .xyz – link context is absent from all links
>
>
>
> I am not aware of any specifications where the link context is explicitly 
> defined with the creation/definition of a link (e.g. HTTP link header, w3c 
> HTML5 spec, Atom).
>
>
>
> Is the link object’s context/value used at all? Is it possible for a future 
> update the RDAP spec to remove the link context, perhaps in RDAP-X?
>
>
>
> Thanks,
>
> James
>
> ___
> 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-loffredo-regext-epp-over-http-03.txt

[Andrew Newton (andy)]

I am not in favor of weakening the security posture of EPP. If one
security mechanism is to be downgraded from a MUST to a SHOULD, there
needs to be a replacement of it with another security mechanism that
is a MUST which keeps the security posture of EPP at the same or
greater level.

-andy


On Thu, Feb 22, 2024 at 1:56 AM Mario Loffredo
 wrote:
>
> Hi Scott,
>
> thanks for your quick reply.
>
> Please find my comment below.
>
> Il 21/02/2024 13:47, Hollenbeck, Scott ha scritto:
>
> Tanks for posting the draft, Mario. One quick question: RFC 5734 (Extensible 
> Provisioning Protocol (EPP) Transport over TCP) states that “Mutual client 
> and server authentication using the TLS Handshake Protocol is REQUIRED”. 
> Section 8 of the draft weakens this requirement, stating that “servers SHOULD 
> require clients to present a digital certificate”. HTTPS requires both TCP 
> and TLS, so why weaken the requirement?
>
> [ML] There are technical (1-2),  ethical (3) and practical (4) reasons. With 
> regard to reasons 3-4, I can speak on behalf of .it but I'm pretty sure the 
> situation is quite the same in other ccTLDs.
>
> 1) In TLS (RFC 5246), servers must provide clients with a certificate but 
> clients may provide servers with a certificate if it is requested by servers. 
> It all depends on the application protocol built on top of HTTPS. If the 
> purpose of requiring clients to issue a certificate is implementing a kind of 
> 2FA to enforce EPP client authentication in addition to client's credentials, 
> that is not the only way to go. For example, .it requires that  a client ip 
> address could be used by one only registrar where a registrar can use 
> multiple client ip addresses. The association between them is created 
> out-of-band, stored in the underlying db and recorded in the HTTP session, 
> once it is started . Therefore, at any request, the server (i.e. one of the 
> backend server cited below) is able to verify that noone is trying to 
> impersonate someone else. Definitvely, I wouldn't say that using SHOULD 
> instead of MUST weakens the requirement of enforcing client authentication as 
> long as alternative measures could be as secure as client certificates.
>
> 2) In an L7 load balancer (LB), clients  issue the requests over HTTPS and 
> the LB forwards the requests to the backend servers (BSs) over HTTP.  This is 
> to speed up the communication between the LB and the BSs. There is no need to 
> set up an SSL channel between them because the LB is normally exposed on the 
> border of a protected network while the BSs are inside that network. A 
> firewall filters the access by  allowing only the communication on port 443 
> and only from a selected list of ip addresses. The LB logic for routing the 
> incoming requests is very simple, hence you can easily forward a client ip 
> address but it would be much harder to extract the client identity from a 
> certificate (i.e. either CN or SAN) and forward it through an ad-hoc HTTP 
> request header field to let the BS verifies the client identity.
>
> 3) Most of .it registrars (~ 1100) are italian SMEs managing only .it 
> domains. When, in 2009, .it migrated from the old registration system, based 
> on issuing fax, to the new one, based on issuing EPP commands over HTTP, the 
> mission of that transition was to reduce as much as possible the 
> technological effort required to registrars to comply with the new rules and 
> avoid to discriminate small players who could not be as technologically 
> powerful as the big ones. To make that transition as smooth as possible, we 
> provided some measures to support them in everything.  At that time, we 
> evaluated client certificates could appear a practice increasing that 
> technological divide. Then we opted for other fairer and as effective 
> practices.
>
> 4) .it domain names market is very dynamic. Companies merge and, as a result 
> of changing the company names, new registrars are registered with new 
> credentials and new client certificate would be needed. Client IP addresses 
> looks more stable. For sure, updating the set of allowed IP addresses per 
> registrar doesn't cost a thing.
>
>
> I'm aware that talking about ethical reasons in a technical forum like RegExt 
> might seem inappropriate but nonetheless think that often non-technical 
> aspects have somewhat an influence on making technical decisions.
>
> My apologizes for the long post. Did my best to answer synthetically.
>
>
> Best,
>
> Mario
>
>
>
>
> Scott
>
>
>
> From: regext  On Behalf Of Mario Loffredo
> Sent: Wednesday, February 21, 2024 2:15 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] [regext] Fwd: New Version Notification for 
> draft-loffredo-regext-epp-over-http-03.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 all,
>
> just submitted a new version of  draft-loffredo-regext-

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

[Andrew Newton (andy)]

"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 understand this correctly, the chairs asked the document shepherd to 
> declare that there were no substantial changes made during WGLC between 
> versions 05 and 07 and all raised issues were addressed.
>
>
>
> The answer below I interpret as: We would like the permission from the WG to 
> not only substantially change draft-ietf-regext-rdap-rir-search in a next 
> version that we want to send to the IESG, but on top of that also clarify or 
> even change the interpretation of RFC 9083.
>
>
>
> If this is the question, then we need to have a discussion what this will 
> mean to other documents and it’s interpretation of RFC 9083 first, and 
> perhaps even write this clarification down in a separate document if that is 
> needed.
>
> When that is done and consensus is reached,  we must issue a new WGLC for  
> the next version of draft-ietf-regext-rdap-rir-search if that will contain 
> these substantial changes suggested by the WG.
>
>
>
> In order to reach consensus, all comments and support during a complete WGLC 
> must be for a stable document. Otherwise we don’t know if people agree with 
> what version of the document and which interpretation of RFC 9083.
>
>
>
> Regards,
>
>
>
> Antoin
>
>
>
>
>
> Op 19 feb. 2024, om 13:07 heeft Mario Loffredo 
>  het volgende geschreven:
>
>
>
> Hi Antoin,
>
> after a private discussion between  James, Tom, Jasdip and me, we agreed on 
> the following:
>
> 1) Some minor edits that don't substantially change the draft but clarify the 
> meaning of some sentences will be done in next version
>
> 2) We would like the WG members express their own opinions on the substantial 
> matter below.
>
> RFC 9083 states the following for rdapConformance included in non-“help” RDAP 
> responses:
>
> · 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.
>
> · A response to any other request will include only identifiers for 
> the specifications used in the construction of the response.
>
> There is no normative language that specifies exactly what identifiers are 
> included in the response, where there is the language of “hints” and “used in 
> construction of the response”.  Below are options for what identifiers are 
> included in the “rdapConformance” array that could be captured in the RDAP 
> Extensions draft:
>
> Option 1) only the extension identifiers used to build the response with 
> regard to the fields
>
> Option 2) all of the extension identifiers that impact the build of the 
> response, hence with regard to fields, values, and query members / query 
> parameters used for the response (i.e. Option 1 + extension query identifiers 
> and extension identifiers impacting response values)
>
> Option 3)  all of the extension identifiers defined by specs used to build 
> the response (i.e. Option 2 + any extension identifier defined by referenced 
> specs)
>
>
>
> Option 1 corresponds to a literal interpretation of normative language in RFC 
> 9083, while Option 2 extends its meaning.
>
> Option 3 is further extensive and corresponds to the interpretation used in 
> rir-search. To better explain their position, the author

Re: [regext] CALL FOR ADOPTION: draft-gould-regext-rdap-versioning draft-newton-regext-rdap-extensions draft-newton-regext-rdap-x-media-type

[Andrew Newton]

+1, obviously.

-andy

On Mon, Feb 5, 2024 at 9:37 AM James Galvin  wrote:
>
> This is the formal adoption request for the following package of Internet 
> Drafts:
>
> Versioning in the Registration Data Access Protocol (RDAP)
> https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/
>
> RDAP Extensions
> https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/
>
> An RDAP With Extensions Media Type
> https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/
>
>
> Please review these drafts to see if you think they are suitable for adoption 
> by REGEXT and comment to this message on the list, clearly stating your view.
>
> This Call For Adoption will close on Monday, 19 February.
>
> If there are no objections, the chairs will consider these documents 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-hollenbeck-regext-epp-delete-bcp

[Andrew Newton]

+1. And restating my previous email... I'm willing to shepard.

-andy

On Mon, Jan 29, 2024 at 10:19 AM Antoin Verschuren
 wrote:
>
> This is the formal adoption request for Best Practices for Deletion of Domain 
> and Host Objects in the Extensible Provisioning Protocol (EPP):
>
> 
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/
>
> Please review this draft to see if you think it is suitable for adoption by 
> REGEXT and comment to this message on the list, clearly stating your view.
> Andy Newton already volunteered to be a document shepherd this item will be 
> adopted.
>
> This Call For Adoption will close on Monday 12 February.
>
> If there are no objections, the chairs will consider this document adopted.
>
> Thanks,
>
> Your REGEXT co-chairs 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] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Andrew Newton]

Thanks Tom. Looks good to me.

-andy

On Thu, Jan 25, 2024 at 10:28 PM Tom Harrison  wrote:
>
> Hi Andy,
>
> Thanks for your feedback.
>
> On Thu, Dec 07, 2023 at 02:55:21PM -0500, Andy Newton wrote:
> > 1. The elidation in figure 2 (section 3.4) should be pointed out. At
> > first I mistook the hrefs as some sort of relative URLs.
>
> These have been updated to use concrete URLs now.
>
> > 2. It would be helpful if section 4 noted that the object instances
> > returned in the arrays are defined in RFC 9083. IMHO, the beginning
> > words of "As with RFC 9083" don't make that clear.
>
> This has been updated.
>
> > 3. Perhaps this is beyond the scope of the draft, but is the intent to
> > have the links for up/down/bottom/top be placed in responses for IP
> > and autumn lookups as well?
>
> Yep, that's right.  The intent here is that each object will include
> at most one link for each type of relation, and each link will be
> relative to the object itself, per the example in section 3.4.  (It's
> not mandatory that these links be included in all objects, either.)
>
> > And using the example tree in figure 1, if a search of
> > /ips/rirSearch1/up/192.0.2.0/25 returns 192.0.2.0/24, would that
> > returned object then have all the child and bottom links in that
> > tree?
>
> It would have a single child link and a single bottom link.  The child
> link href would resolve to a search that returned 192.0.2.0/25 and
> 192.0.2.128/25, while the bottom link href would resolve to a search
> that returned 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32,
> 192.0.2.128/26, and 192.0.2.192/26.
>
> > 4. It took me some time to figure out the purpose of the rirSearch1
> > extension identifier (it's because of /domains in RFC 9083).
>
> That's true.  It's also present in order to facilitate future updates
> (by incrementing the number at the end of the identifier).
>
> > Considering this document registers 5 extension identifiers, this
> > draft presents the use case for allowing IETF extensions to forgo
> > the need of using identifier prefixes if there is a good reason.
> > That said, have you considered registering one extension identifier
> > and using a prefix because "rirSearch1" appears in all paths and
> > ruins the aesthetic symmetry with 9083 anyway? Something like "rs1"
> > for RIR Search 1 and then paths of /rs1_autnums/..., /rs1_ips/...,
> > and /rs1_domains/...
>
> The paths for the basic searches do not include rirSearch1, which
> means that their forms are consistent with those from 9082/9083.  On
> the more general question: if we rely on a single identifier only,
> then that means that the reverse search definitions end up with
> "searchable resource type" values like "rs1_ips" and "rs1_autnums".
> Apart from being confusing, given the reverse search document's
> definition of corresponding unprefixed "related resource type" values
> and use of unprefixed "searchable resource type" values for the other
> object classes, it also means that the search definitions would need
> to be updated whenever a new version of the RIR search document was
> completed.  Although using multiple identifiers comes with its own
> costs, we think the benefits outweigh those costs here.
>
> -Tom

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

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

[Andrew Newton]

I support this. Also, I volunteer to be doc shephard if that is
acceptable to the chairs and if the doc is adopted.

-andy

On Thu, Jan 18, 2024 at 7:59 AM Hollenbeck, Scott
 wrote:
>
> 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

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

[regext] status of draft-ietf-regext-epp-eai

[Andrew Newton]

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/

What is the status of this draft? I know the authors churned out
another version rolling back some of the changes based on
conversations on this list. Does it need to take another spin in WGLC?

-andy

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

Re: [regext] [Ext] TTL extension for RDAP

[Andrew Newton]

On Fri, Jan 5, 2024 at 8:04 AM Gavin Brown  wrote:
> So something like this? I've also thrown in min/default/max values as well:
>
> "ttl": [
> {
> "types": ["NS", "DELEG"],
> "value": 3600,
> "min": 60,  // optional
> "default": 86400,   // optional
> "max": 172800,  // optional
> "remarks": [ ... ], // optional
> "events": [ ... ]   // optional
> },
> {
> "types": ["DS"],
> "value": 3600,
> "remarks": [ ... ],
> "events": [ ... ]
> },
> ...
> ],
> ...
>
> So each RRtype could have a remark which provides the policy (or a link to 
> the policy) and some events.
>
> G.

+1

-andy

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

Re: [regext] [Ext] TTL extension for RDAP

[Andrew Newton]

On Wed, Jan 3, 2024 at 10:20 AM Gavin Brown  wrote:
>
> Do you think the ttl_values object needs an events array then?
>
> To support this I would change the ttl_values object as follows:
>
> "ttl": {
> "values": {
> "NS": 3600,
> "DS": 60,
> },
> "events": [
> {
> "eventAction": "lastChanged",
> "eventDate": "2012-07-23T05:15:47Z",
> "eventActor": "registry-operator"
> }
> ]
> }

I was thinking that "ttl" would be an array of objects, with each
object containing an array of DNS RR names, a TTL, an array of events
and an array of links. This keeps it similar to the DNSSEC data. I
know the links thing seems silly, but it could be used to point to TTL
policies given some registrars, INRs, etc have TTL policies.

To address the JG's point, there are registries that are not run by
EPP (ccTLDs, RIRs) and registrars don't necessarily have to follow the
EPP data model in their own RDAP servers as far as I know. I think
this is generally useful and I know there have been times where I need
to know what a registrar had as a TTL vs what I was seeing in DNS.

-andy

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

Re: [regext] [Ext] TTL extension for RDAP

[Andrew Newton]

Given that the TTL can be updated independently of the domain name,
there is utility in exposing TTLs in RDAP especially if that
information can be given with the events & links as is done with the
DNSSEC data in RDAP. I know I have had times in the past when I needed
to know when a TTL was last changed.

Here is the example from 9083:

"secureDNS":
  {

 "zoneSigned": true,
 "delegationSigned": true,
 "maxSigLife": 604800,
 "keyData":
 [
   {
 "flags": 257,
 "protocol": 3,
 "algorithm": 8,
 "publicKey": "AwEAAa6eDzronzjEDbT...Jg1M5N rBSPkuXpdFE=",
 "events":
 [
   {
 "eventAction": "last changed",
 "eventDate": "2012-07-23T05:15:47Z"
   }
 ]
   }
 ]
  }

-andy

On Wed, Jan 3, 2024 at 7:17 AM Gould, James
 wrote:
>
> Gavin,
>
> Agreed that the base RDAP RFCs include DNS information, but in the case of 
> nameservers they are standard provisioning objects with the host EPP mapping 
> in RFC 5733 and with additional attributes.  I don't believe that there is 
> value in replicating DNS information in RDAP that is not related to other 
> information (e.g., creation date, updated date, transfer date, sponsorship) 
> that may have value to the public.  My recommendation is to focus management 
> of TTL in EPP with its impact on DNS and leave RDAP alone.  Let's not go down 
> the slippery slope of bloating RDAP by replicating DNS information when there 
> is no perceived value.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
>
> On 1/3/24, 4:44 AM, "Gavin Brown"  > 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 Jim,
>
>
> > On 2 Jan 2024, at 14:52, Gould, James  > > wrote:
> >
> > Gavin,
> >
> > I question the need for a TTL RDAP extension, since the TTLs are easily 
> > assessable in DNS to the public. The management of the TTLs is provisioned 
> > in EPP via the TTL EPP extension and can be made available to the 
> > registrant by the registrar. There are examples of DNS information 
> > duplicated in RDAP, such as the DNSSEC information in RFC 9083, but I'm 
> > concerned with setting the pattern of duplicating additional DNS 
> > information with no perceived value.
> >
>
>
> RDAP domain objects contain other information that can also be obtained in 
> the DNS, such as nameservers, glue, and DS records. Evidently there is value 
> in providing this information via an alternate channel (such as to debug DNS 
> resolution issues). Providing TTL information via RDAP is consistent with 
> that approach and will also be helpful in the same scenarios.
>
>
> G.
>
>
> > Thanks,
> >
> > --
> >
> > JG
> >
> >
> >
> > James Gould
> > Fellow Engineer
> > jgo...@verisign.com  
> >  > >
> >
> > 703-948-3271
> > 12061 Bluemont Way
> > Reston, VA 20190
> >
> > Verisign.com 
> >  >  
> > 
> >  [verisigninc[.]com]>
> >
> >
> >
> >
> > On 1/2/24, 9:03 AM, "regext on behalf of Gavin Brown" 
> > mailto:regext-boun...@ietf.org> 
> > > on behalf 
> > of gavin.br...@icann.org  
> > >> wrote:
> >
> >
> >
> > Hi all,
> >
> >
> > As a complement to the EPP extension, I've just uploaded a first draft of 
> > an RDAP extension:
> >
> >
> > https://secure-web.cisco.com/1khfl7WVPWF-jsGK6Nxqwpdr3f-7zS-IMW2fy2UbmOBdDxFAso7MbjPz8VXKRq0aKCyklcAbOVTwl3-v1Sj3ZbN_hKbmdfMCh__EipHieNvm5-I92wmnx5ws0ZMai6ilhvxRlPMTmOA3Vd2dZhxiJLZ9BoFxIR6aj8fH0e2-N7pjb6j6_0WNcS4ko3gaB4oUJYXmusur7WWhL8wLPMG9Cci8s3YDe

Re: [regext] Redacted registry implementations

[Andrew Newton]

Hi Marc,

We're trying to work it into our CLI as well, and as such will likely
put it into our server so we have something to test against
(https://github.com/icann/icann-rdap/tree/main/icann-rdap-srv). I'll
ping you when the work becomes usable.

-andy

On Fri, Dec 15, 2023 at 7:55 AM Marc Blanchet  wrote:
>
>
>
> > Le 15 déc. 2023 à 02:34, Alexander Mayrhofer  a 
> > écrit :
> >
> > Hello Marc,
> >
> > we're working on an implementation for our gTLD registries, but there's no 
> > "running service" available yet. We might have something available in 2-3 
> > months time, at which point I'm happy to come back to you again to run your 
> > clients against our "test" implementation.
>
> Great. Looking forward to it.
>
> Marc.
>
> >
> > Best,
> > Alex
> >
> >
> > -Ursprüngliche Nachricht-
> > Von: regext  Im Auftrag von Marc Blanchet
> > Gesendet: Donnerstag, 14. Dezember 2023 17:48
> > An: REGEXT Working Group 
> > Betreff: [regext] Redacted registry implementations
> >
> > Hello,
> > As I’m currently working on a new version of RDAP Browser (a mobile RDAP 
> > client on iOS and Android), I would like to know if some registries (either 
> > domain or RIR) have or are about to implement draft-ietf-regext-redacted as 
> > it is on its way to RFC. I would like to test my client on their registry 
> > implementation. The test could be done against your beta version too. 
> > Please contact me offline or on this list as you wish.
> >
> > Regards, Marc.
> > ___
> > 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 mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Andrew Newton]

On Fri, Dec 8, 2023 at 3:57 AM Mario Loffredo  wrote:
>
> [ML] I would prefer "only express the items which are more likely used in 
> RDAP". After all, SimpleContact is not an RFC and, as such, could be subject 
> to changes resulting from the WG discussion.
>
> In this respect, have still retained the use of JSContact name components to 
> represent structured names.
>
> Apart from it and the language property, this version doesn't include extra 
> information.

I am good with this compromise, however my memory of the IETF 117
session was that items such as structured names were not desired.

>
> - clarify the use of 5733's "sp" (examples suggest it is a region
> code, but it is a string)
>
> [ML] Don't think that we need to further clarify this. Appendix A already 
> clarifies that the region JSContact address component corresponds to the 
> region VCard ADR component.
> Hence, the region JSContact address component is a string.

I should have been clearer in my request. I don't think normative text
is needed, but rather some informative text to remind the reader of
this as the 5733 example shows what can easily be mistaken as a region
code.

>
> - define RFC 8605 CONTACT-URI is a JSContact link of type "contact"
>
> [ML] Done.
>
> - more specificity of the 5733 int/loc mapping (use of und-Latn and
> some clarity around the keys).
>
> [ML] Can you please elaborate this by providing some examples ?

The idea is to specify 5733 "int" data as und-Latn.

Yes, I'll work up some examples and provide them to you.

>
> - restrict localizations from using patch objects (it looks like this
> is the case in the latest drafts).
>
> [ML] Sorry if I miss the meaning of this. What should be the alternative 
> mechanism to represent localizations without using the "localizations" 
> property.

My apologies. I meant to convey that I believe this is no longer an issue.

>
> In line with the use of int/loc in RFC5733, we could use the same types for 
> both localizations and localized objects (e.g. we can add two addresses to 
> the "addresses" map) but we'd loose the information about the localization 
> language.

I agree. Let's not do that. Hopefully the examples I provide will be better.

> - clarity on hybrid address types (found in 5733 but also in other
> registry models)
>
> [ML] Can you please clarify which kind of hybrid address types you meant ?

Hybrid types are where parts of the address are structured and other
parts are not. For example, locality and country may be structured but
the rest of the address is not.

>
> - make signaling survive redirects
>
> [ML] It seems to me that the WG hasn't yet taken a final position on this, 
> discussion is still ongoing. So, at least for this version, I retained the 
> jscard query parameter.

I am not willing to compromise on this especially as there is a
workable solution. Any IETF authored RDAP extension MUST be compatible
with the current RDAP ecosystem in its intended usage.

-andy

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

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

[Andrew Newton]

+1

On Mon, Dec 11, 2023 at 9:24 AM Gould, James  wrote:

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

Re: [regext] JSContact - SimpleContact discussion follow up

[Andrew Newton]

On Wed, Nov 29, 2023 at 5:12 AM Mario Loffredo
 wrote:
>
>
> Let's take for example the possible link between the uid property and the 
> unique and persistent identifier as defined by the European eIDAS regulation 
> for the purposes of cross-border identification and validation of domain 
> registrants as explained in a CENTR white paper.

I'd still prefer they create an eIDAS extension instead of this
working group speculating what they will need. Doing so will be easy
because they would only need to state what additional JSContact data
is in their extension and then register it with the IANA.

-andy

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

Re: [regext] Fwd: ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Andrew Newton]

On Tue, Nov 28, 2023 at 5:39 AM Mario Loffredo
 wrote:
>
> [ML] Since it talks about "content negotiation", rdap-x regards clients
> signaling their preferences about response extensions or, at most,
> extensions involving both the response and the request.
>
> With regard to pure request extensions, clients should signal
> preferences by using query parameters prefixed by opaque extension
> identifiers as defined in rdap-extensions.
>
> This in turn implies that, on one hand, rdap-x is strictly bound to
> rdap-extensions and, on the other hand, instead of what is stated in
> Section 6 of rdap-extensions, even the extensions created by IETF MUST
> use the extension identifier as a prefix.
>
>   Do you agree ?

The important part is that extensions have identifiers. The use of the
identifiers as prefixes for JSON names or URL paths or query
parameters is a separate issue.

> [ML] It could be an issue if we decide to start using content
> negotiation.  The media type has not influenced the RDAP response so far.

With all due respect, that is incorrect. Current RDAP does do content
negotiation. Section 4.2 of RFC 7480 says the accept header can have
either application/rdap+json, application/json, or both and the
content-type header must have application/rdap+json.

-andy

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

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

[Andrew Newton]

This is a great draft, and I'm glad that this work is going forward. I
do have a few comments.

1. The elidation in figure 2 (section 3.4) should be pointed out. At
first I mistook the hrefs as some sort of relative URLs.

2. It would be helpful if section 4 noted that the object instances
returned in the arrays are defined in RFC 9083. IMHO, the beginning
words of "As with RFC 9083" don't make that clear.

3. Perhaps this is beyond the scope of the draft, but is the intent to
have the links for up/down/bottom/top be placed in responses for IP
and autumn lookups as well? And using the example tree in figure 1, if
a search of /ips/rirSearch1/up/192.0.2.0/25 returns 192.0.2.0/24,
would that returned object then have all the child and bottom links in
that tree?

4. It took me some time to figure out the purpose of the rirSearch1
extension identifier (it's because of /domains in RFC 9083).
Considering this document registers 5 extension identifiers, this
draft presents the use case for allowing IETF extensions to forgo the
need of using identifier prefixes if there is a good reason. That
said, have you considered registering one extension identifier and
using a prefix because "rirSearch1" appears in all paths and ruins the
aesthetic symmetry with 9083 anyway? Something like "rs1" for RIR
Search 1 and then paths of /rs1_autnums/..., /rs1_ips/..., and
/rs1_domains/...

-andy


On Mon, Nov 27, 2023 at 9:51 AM Antoin Verschuren
 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:
>
>
> RDAP RIR Search
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/
>
>
> 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, 11 December 2023.
>
> If there are no objections the document will be submitted to the IESG.
>
> The Document Shepherd for this document is Mario Loffredo.
>
> 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: ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Andrew Newton]

My comments are inline:

On Fri, Nov 17, 2023 at 7:18 AM Mario Loffredo
 wrote:
>
> [ML] Per what is stated in RFC 9083 Section 4.1, a pure request extension 
> doesn't have to be included in the rdapConformance array of the related 
> response when it is used in a query because the rdapConformance array is used 
> to signal to the client only the extensions used in building the response.
>
> Per what is stated in Section3 of rdap-x draft, clients SHOULD give 
> preference to the rdapConformance array in order to determine which 
> extensions (including those requested ) were used to build the response.
>
> Let's suppose to use farv1_dnt in a query within an authenticated session. 
> Have some questions:
>
> Should farv1 be included in the extensions parameter ?

Good question. My inclination is to say that farv1 is about
authentication and not content negotiation and therefore does not need
to be in the extensions parameter.

>
> What should be the server response when it's not included in the extensions 
> parameter but is used in the query string ?

It should continue processing the query parameters.

>
> Supposing that farv1 has to be included in the extensions parameter when 
> farv1_dnt is used, how should a client interpret that farv1 is missing in 
> rdapConformance ?

I'm confused. Isn't this what the SHOULD above is about. Or are you
suggesting that SHOULD is to be a MUST?

> - AFAIK caches generally ignore Accept by default, so when content 
> negotiation is first introduced, clients often get the wrong response type. 
> In this case, it would result in getting the default response by the RDAP 
> server. Implementers should add Accept to Vary. Should it be addressed by 
> rdap-x draft ?
>
> We can add language deferring to RFC 9110 guidance on this.
>
> [ML] Do you mean that servers should implement Vary too ?

If that is what they need to do. I don't think this changes any
current caching strategies and deference to RFC 9110 is the proper
guidance. My understanding of the current state of the Vary header is
that it is mostly used by servers. That said, I have yet to see this
as a real-world issue in the RDAP space.

-andy

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

Re: [regext] JSContact - SimpleContact discussion follow up

[Andrew Newton]

Mario,

Many thanks for this message.

On Fri, Nov 17, 2023 at 5:57 AM Mario Loffredo
 wrote:
>
> 2) Chapter "Make it simpler"
>
> Prefer "Make it better". I mean, simplicity cannot be the only parameter used 
> within IETF to evaluate a technical solution. IMO there are other parameters 
> that are more important: flexibility, estensibility, efficiency.
>
> In addition, no one in their right mind deliberately makes a proposal 
> inherently complex. JSContact started as simple as possible and get more 
> complex to meet the requirements.

As I recall, this is also what happened with jCard. What it ended up
being was nothing like how it started.

My original message on the concept of SimpleContact was born out of
shock at just how complex JSContact had become. In that message, I
proposed multiple paths, one of which was scoping down JSContact usage
in RDAP to its simple parts. However, the thread turned into
SimpleContact vs JSContact, arrays vs objects, us vs them, etc..
etc... etc... and that's how we got here.

But it is not too late to explore that path. If you are willing, I'd
be happy to work with you on "SimpleContact expressed in JSContact".
The basic premise would be to define a default RDAP extension profile
of JSContact. Others may define their own extension profiles if they
need more from JSContact, but the default profile would limit
JSContact to expressing only that which is in SimpleContact.

In more detail, We (because I talked to Tom about this) think the
default profile would do the following:
- only express the items in SimpleContact
- clarify the use of 5733's "sp" (examples suggest it is a region
code, but it is a string)
- define RFC 8605 CONTACT-URI is a JSContact link of type "contact"
- more specificity of the 5733 int/loc mapping (use of und-Latn and
some clarity around the keys).
- restrict localizations from using patch objects (it looks like this
is the case in the latest drafts).
- restricting to JSContact 1.0.
- clarity around JSContact links vs RDAP links
- define a more concrete scheme on sequenced IDs (and some examples)
- clarity on hybrid address types (found in 5733 but also in other
registry models)
- make signaling survive redirects

Again, others would be able to provide profiles that do more such as
offering cryptocurrency wallets and avatars, etc But by providing
a default profile, RDAP client implementers need not guess at which
parts of JSContact are needed and which parts are not. While I still
believe SimpleContact is much simpler, this approach would make
JSContact much more well defined when used in RDAP and provide better
guidance to both server and client implementers.

-andy

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

Re: [regext] RDAP-X draft adoption

[Andrew Newton]

Jim,

I offered two very concrete examples of the problem and you have once
again called it a "claim". And you don't see how that can be perceived
as dismissive?

Anway, Jasdip already answered your broader question, and now you are
asking for discussion on hypotheticals that are likely to meander. For
the sanity of the list, perhaps we should take a time-out.

-andy

On Thu, Nov 16, 2023 at 12:17 PM Gould, James  wrote:
>
> Andy,
>
> I didn't mean to be dismissive of the existence or need of redirection 
> services.  I just don't view the redirection services as the primary use case 
> for RDAP servers and the RDAP protocol itself.  We can agree to disagree on 
> this.
>
> The reason for the word "claim" is to address a gap that I see in the scope 
> of RDAP-X and the breadth of the issue that you claim there is with query 
> parameters in RDAP.  If you're going to create a new media type to pass 
> client-side preferences to an RDAP server, why wouldn't you address the 
> broader case of all query parameters in RDAP instead of focusing on a new 
> feature of extension signaling that overlaps with 
> draft-gould-regext-rdap-versioning?
>
> Please clarify the cases in RDAP where query parameters can and can't be 
> used.  One redirection use case is associated with TLD transitions, where 
> both lookup and search queries need to be properly supported.  Do you have a 
> similar concern with the retention of query parameters for the TLD transition 
> use case?
>
> Thanks,
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
>
> On 11/16/23, 10:35 AM, "Andrew Newton" mailto: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.
>
>
> Jim,
>
>
> You are now stating that redirection is a "special case" and using the
> word "claim" which I perceive as you being dismissive of the validity
> of their need. As I have repeatedly written on this list and these
> threads, redirection is very much used when dealing with the transfer
> of number resources between the INRs. That is why I specifically
> referenced Appendix C of RFC 7480 because figure 3 describes the use
> case.
>
>
> As another example, if you were to query
> https://secure-web.cisco.com/1ByyQSpniIqHtnsxRXDx81unODISe0eQ3YJ9qlLZaEVNJNwOYI8C5f6YzQskn9bOb8V8omhSkbDI-W3hNw5bVZjh1CYPd6sKlNJj9VEbHRxj-63dXAlwxfV3zVPUhzVBy3hkgRcXZ0oNsMNX1uYF8yA27uOHUNmiSe3I7SrNTMjhF-uECKRYJYUrTmtjuiaqCWJYPfhiGLdkjmA0Yf8ZAvng2c8hH6-aHC6nCsQ9UX53hfCLMF5rB5R6kI3kuQ1uv3B9wR2L_iepWcu5wY8lFO_Wby5-7Wwu78RBubCs9heo/https%3A%2F%2Frdap.lacnic.net%2Frdap%2Fip%2F190.211.150.1
>  
> <https://secure-web.cisco.com/1ByyQSpniIqHtnsxRXDx81unODISe0eQ3YJ9qlLZaEVNJNwOYI8C5f6YzQskn9bOb8V8omhSkbDI-W3hNw5bVZjh1CYPd6sKlNJj9VEbHRxj-63dXAlwxfV3zVPUhzVBy3hkgRcXZ0oNsMNX1uYF8yA27uOHUNmiSe3I7SrNTMjhF-uECKRYJYUrTmtjuiaqCWJYPfhiGLdkjmA0Yf8ZAvng2c8hH6-aHC6nCsQ9UX53hfCLMF5rB5R6kI3kuQ1uv3B9wR2L_iepWcu5wY8lFO_Wby5-7Wwu78RBubCs9heo/https%3A%2F%2Frdap.lacnic.net%2Frdap%2Fip%2F190.211.150.1>
>  you will get back an
> HTTP 307 with the location header value of
> "https://secure-web.cisco.com/1Uy8YoZ4y85z7qF77jUZaqauEzcfKKBNsYtpCjJ6h4y3DTWBiyULTvRJBcCegzJzb8wmBiTvDavfsH7-NEqq5bNp3MuQ1GKky0e7ybl_UZZ5eUz8MZJ0IZpWib7tsa8Rye6w9-bgeAiYiDOtCUgYvx8RN8MPkDauPGv7f_dBxV3HpzCaEUsHxKiHCKIoq85WQzFoobWNj_4ZUxcpE3hGCReMlR_TzsPOYSXu1QPvnAmlB-Krphu9_VWQ1IESBMc0at42i8uHqdo12TV2rTa594KfAoTgc1gcfhuSHDlxiMEg/https%3A%2F%2Frdap.arin.net%2Fregistry%2Fip%2F190.211.150.1";
>  
> <https://secure-web.cisco.com/1Uy8YoZ4y85z7qF77jUZaqauEzcfKKBNsYtpCjJ6h4y3DTWBiyULTvRJBcCegzJzb8wmBiTvDavfsH7-NEqq5bNp3MuQ1GKky0e7ybl_UZZ5eUz8MZJ0IZpWib7tsa8Rye6w9-bgeAiYiDOtCUgYvx8RN8MPkDauPGv7f_dBxV3HpzCaEUsHxKiHCKIoq85WQzFoobWNj_4ZUxcpE3hGCReMlR_TzsPOYSXu1QPvnAmlB-Krphu9_VWQ1IESBMc0at42i8uHqdo12TV2rTa594KfAoTgc1gcfhuSHDlxiMEg/https%3A%2F%2Frdap.arin.net%2Fregistry%2Fip%2F190.211.150.1";>.
>  Yet if you look in
> the bootstrap files you will see that 190/8 points to
> https://secure-web.cisco.com/1GI1Tol_m1slbyjjwTH-J2Uby2aPfvNjtyJfAu78hvagrbF9bd-J9wGYrUVDR0cDkpavFaj2v9j42ONQW9pUw32FcaEpDTiDejnH9lT_P9Z9E0Vqx_uoPGVG-rIOTNpxcFu59tcFuZTAmnFENfxd7fcDtpzWfb15gh5C6d9XF_R-Py0aoVO8LAXp340QIlaSpedEkRNEk8x6uP1UvMoDESu1r3q3I9D5_dpwRvszN-Y-89oxEfM8wVmCVIC7Qn-bhvSxJKV7dplGkkYHHArQit5dWVvRk3mp6eAiJK4JXN0I/https%3A%2F%2Frdap.lacnic.net%2Frdap
>  
> <https://secure-web.cisco.com/1GI1Tol_m1slbyjjwTH-J2Uby2aPfvNjtyJfAu78hvagrbF9bd-J9wGYrUVDR0cDkpavFaj2v9j42

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Andrew Newton]

Mario,

On Thu, Nov 16, 2023 at 9:28 AM Mario Loffredo
 wrote:
>
>
> Also, since you (and JG) have been arguing vehemently on your
> position, did you find a technical flaw in the rdap-x draft? Have you
> found a scenario where it does not work?
>
> [ML] Am not "arguing vehemently", I'm quietly explaining what does not 
> completely convince me. Your proposal would have many implications on 
> existing implementations and as many of them in the future, hence, it should 
> be carefully evaluated.
>

My apologies. I did not mean to offend.

> Here in the following  some remarks/objections from my side sorted by 
> relevance:
>
> - RDAP extensions are not only response extensions. So, even assuming that 
> signaling preferences about response extensions is a matter of content 
> negotiation, pure request extensions wouldn't theoretically be covered. How 
> would they be manged ?

Given that today there is no standardized means for a client to signal
what extensions it prefers, I don't foresee a problem. They should
probably be managed the same way as the others. Can you provide an
example?

>
> - AFAIK caches generally ignore Accept by default, so when content 
> negotiation is first introduced, clients often get the wrong response type. 
> In this case, it would result in getting the default response by the RDAP 
> server. Implementers should add Accept to Vary. Should it be addressed by 
> rdap-x draft ?

We can add language deferring to RFC 9110 guidance on this.

>
> - Requiring HTTP headers with media types makes it more difficult to test and 
> explore the API using a browser. During development, you can launch the 
> browser and easily see what the server is responding by simply using the 
> address bar. When relying on content negotiation it's a bit more tricky, and 
> you have to leverage plugins or cURL or anything else that can manipulate the 
> headers.

There are other very good development tools as well. I see people use
Postman a lot, and httpie looks good as well.

>
> - (Minor) I wonder how much tricky it could be to get the value of the 
> extensions parameter. At a quick glance, it doesn't look to me as 
> straightforward as getting the value of a query parameter. I'd be curious to 
> know if someone in the WG has already implemented it.

This would depend on the server framework. But I can see about putting
some code in the test server referenced in the draft.

>
> If not, then why do you insist on a path with known interoperability
> issues over a path without them?
>
> [ML] Because I personally see drawbacks in such an approach as well as 
> possible inconsistencies in implying that lookup queries should not include 
> query parameters.
>
> Anyway, if the WG agreed on this way to go,  some normative language should 
> be added somewhere to make it clear when query parameters are forbidden or 
> unrecommended.

I'm fine with that. I don't think the rdap-x draft is the right place.
Perhaps the rdap-extensions draft.

-andy

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

Re: [regext] RDAP-X draft adoption

[Andrew Newton]

Jim,

You are now stating that redirection is a "special case" and using the
word "claim" which I perceive as you being dismissive of the validity
of their need. As I have repeatedly written on this list and these
threads, redirection is very much used when dealing with the transfer
of number resources between the INRs. That is why I specifically
referenced Appendix C of RFC 7480 because figure 3 describes the use
case.

As another example, if you were to query
https://rdap.lacnic.net/rdap/ip/190.211.150.1 you will get back an
HTTP 307 with the location header value of
"https://rdap.arin.net/registry/ip/190.211.150.1";. Yet if you look in
the bootstrap files you will see that 190/8 points to
https://rdap.lacnic.net/rdap. What this means is that the bootstrap
files are not granular enough to direct clients to the appropriate
server and the RIRs are using redirection to get clients to the
correct place.

Also, you have been dismissive of the RDAP redirection services which
are a valid part of the ecosystem and serve a purpose for the simpler
clients and for constrained environments. Consider a network operator
writing a shell script using curl and jq to find the most specific
covering networking of an IP. Using the bootstrap files requires
downloading the appropriate file (there are different ones for v4 and
v6), sorting the service hosts by "http" scheme, and using an advanced
dsa such as a trie or modified bst. Plus to be a good netizen, they
need to deal with the cache-control of the bootstrap file. Or they can
point curl at a redirect service and not worry about all that. That
is, the bootstrap process is doable but it is certainly non-trivial.

For constrained environments a local bootstrap service is beneficial
as it cuts down on the bandwidth/latency of every client grabbing the
bootstrap files.

-andy


On Wed, Nov 15, 2023 at 2:04 PM Gould, James  wrote:
>
> Andy,
>
> You claim that there is an issue with redirection and query parameters.  A 
> client is not required to use the redirection service or a redirection at all 
> and can directly query the target servers, so I view this as a special case 
> that you say is best solved with RDAP-X.  What I'm requesting is to ensure 
> that RDAP fully supports query parameters for the existing and future RDAP 
> extensions and to address the redirection issue in general with use of RDAP-X 
> as an alternative to query parameters.  An RDAP extension can provide 
> additional client specified options using query parameters and those query 
> parameters could be passed using RDAP-X as an alternative?  The RDAP-X is 
> focused on signaling of the extensions that should be returned in the 
> response, which is already being addressed by 
> draft-gould-regext-rdap-versioning.  Address the broader issue instead of 
> targeting a problem that is already being worked on and let's get past the 
> query parameter vs. RDAP-X debate.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
>
> On 11/15/23, 1:44 PM, "Andrew Newton" mailto: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.
>
>
> On Wed, Nov 15, 2023 at 11:19 AM Gould, James  <mailto:jgo...@verisign.com>> wrote:
> >
> > How about making the RDAP-X hedgehog broader into a super hedgehog by 
> > solving the more general query parameter issue with redirection services?
>
>
>
>
> You have understated the problem. The issue is not with redirection
> services but with redirects in general.
>
>
> Are you suggesting we add a query parameter that mirrors the
> functionality of the media type's extension parameter? If so, does
> this work for you?
>
>
> ---
> This document defines a URL query parameter named "rdapx_extensions". This 
> query
> parameter has the same syntax as the extension parameter of the RDAPX
> media type.
> Use of this query parameter is NOT RECOMMENDED as such usage has known
> interoperability problems in popular use cases. There is no guarantee servers
> will preserve this query parameter when issuing redirects. Clients
> SHOULD NOT use
> this query parameter unless they are operating in an environment in
> which this query
> parameter will be preserved in an HTTP redirect.
> ---
>
>
> -andy
>
>
>

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

Re: [regext] RDAP-X draft adoption

[Andrew Newton]

On Wed, Nov 15, 2023 at 11:19 AM Gould, James  wrote:
>
> How about making the RDAP-X hedgehog broader into a super hedgehog by solving 
> the more general query parameter issue with redirection services?


You have understated the problem. The issue is not with redirection
services but with redirects in general.

Are you suggesting we add a query parameter that mirrors the
functionality of the media type's extension parameter? If so, does
this work for you?

---
This document defines a URL query parameter named "rdapx_extensions". This query
parameter has the same syntax as the extension parameter of the RDAPX
media type.
Use of this query parameter is NOT RECOMMENDED as such usage has known
interoperability problems in popular use cases. There is no guarantee servers
will preserve this query parameter when issuing redirects. Clients
SHOULD NOT use
this query parameter unless they are operating in an environment in
which this query
parameter will be preserved in an HTTP redirect.
---

-andy

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

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Andrew Newton]

Mario (and JG),

On Wed, Nov 15, 2023 at 5:17 AM Mario Loffredo
 wrote:
>
> [ML] About preserving query parameters in HTTP redirection, my opinion
> is that it depends on each application protocol built over HTTP.
>
> There are a ton of protocols on the web preserving query parameters in
> redirection and AFAIU there is nothing in RFC9110 stating that query
> parameters must be purged.
>
> On the contrary, RFC 9110 itself admits that a POST could be redirected
> and changed into a GET and I cannot imagine how it could be done without
> using query parameters.

There is no disagreement on that. However, RFC 9110 does state that
content negotiation is done with accept and content-type headers.

>
> If RDAP rules out preserving query parameters in redirection, this ought
> to be explicitly stated in section 5.2 of RFC 7480.

The counter to that is that nowhere is it specified that they do
generally survive redirects, there exists RFC language to instruct
servers to ignore unknown query parameters, and there exist current
deployments that do not preserve them.

>
> Anyway, I wouldn't welcome such a policy for the following reasons:
>
> - RDAP is a relatively young protocol not yet largely used. At present,
> I couldn't exclude such a feature from being useful in future developments.
>
> - It would result in a sort of confusion between using query parameters
> in lookups and searches and also between different lookups. To be noted
> that rdap-openid, just gone through the WGLC, allows to specify two
> parameters which can be used in RDAP queries.
>
> - Bootstrapping is an optional feature. Would an RDAP provider be
> allowed to define a request custom lookup extension incuding query
> parameters if that kind of query will never be redirected ?

The issue isn't that they are forbidden, the issue is that to use them
in any scenario involving redirection, all servers participating in
that redirection must behave in the same manner. At present, that is
demonstrably untrue.

>
>
> With regard to the content negotiation,  I personally interpreted that
> Accept header is used to negotiate a format involving the overall
> response rather than a portion, i.e. the contact information.
>
> Just to give an example: at last meeting, you mentioned CBOR. The use of
> CBOR would not be restricted to only the contact information.
>
> Anyway, I admit that this depends on different point of views.
>
> Instead, I am a bit doubtful about how the "extension" parameter is
> defined in the rdap-x draft but I confess that I'm not knowledgeable
> about media types so I asked an expert for a clarification.

I'd be curious who he is and what he has to say.

Also, since you (and JG) have been arguing vehemently on your
position, did you find a technical flaw in the rdap-x draft? Have you
found a scenario where it does not work?

If not, then why do you insist on a path with known interoperability
issues over a path without them?

-andy

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

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Andrew Newton]

On Tue, Nov 14, 2023 at 3:00 PM Marc Blanchet  wrote:
>
> The fact that some people are willing to provide services in addition to the 
> standard track RFCs for bootstrapping RFC9224) does not mean that it should 
> influence how we design our protocols. I have a hard time thinking that we 
> are limiting our design space by not supporting all HTTP semantics, such as 
> query parameters. Hence, I disagree with this argument.
>
> Marc.

Marc,

Please read sections 5.2 and 4.3 of RFC 7480. Those semantics are used
in redirects in the ecosystem, and redirects are quite heavily used in
the RIRs as the RDAP bootstrap cannot account for inter-RIR transfers.

Also, we should very much be influenced by the services deployed based
on concepts in our own RFCs, especially since they are compliant with
our own RFCs.

But I do agree with "I have a hard time thinking that we are limiting
our design space by not supporting all HTTP semantics". That's why the
RDAP-X media type has been proposed. Have you read the draft? Because
it solves the problem using HTTP semantics.

-andy

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

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Andrew Newton]

On Tue, Nov 14, 2023 at 9:02 AM Gould, James  wrote:
>
> Andy,
>
> I recommend covering the use of query parameters in RDAP in the 
> draft-newton-regext-rdap-extensions, since it's unclear and deserves 
> discussion on the mailing list.  I personally don' t see how the use of query 
> parameters would not be compatible in RDAP, since RDAP is simply a REST 
> interface.  Query parameters provide options in a REST request, so I don't 
> see how RDAP is so unique to disallow the use of query parameters.  The net 
> of what you have stated is that query parameters can be used for RDAP search 
> but not for RDAP lookup based on implementation of the existing redirection 
> services that are only used for RDAP lookup.  I believe a redirection service 
> should not filter any query parameters and I'm not aware of any language in 
> RFCs that would support redirection services filtering the query parameters.  
> If there is an issue with the use of query parameters in RDAP, then it should 
> apply to both RDAP search and lookup.  If query parameters cannot be used in 
> RDAP, then we'll need to address the use of query parameters in RFC 9082 for 
> RDAP search.
>

James,

Unfortunately this is not an academic argument. In the link I provided
to this thread, there is a real-world example. Like it or not, there
are deployments that follow the advice in RFC 7480 and do perform the
services given in Appendix C, and there are very good reasons for
doing so (also in the RFC).

As to query parameters in searches, see the thread here:
https://mailarchive.ietf.org/arch/msg/regext/e-x5CCXxXXFYlM_E6KXMcdxyEXc/

-andy

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

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Andrew Newton]

On Tue, Nov 14, 2023 at 2:53 AM Mario Loffredo
 wrote:
>
> > The technical problems with the signaling have been discussed at
> > length on this mailing list. A better and more generic solution has
> > been proposed in the rdap-x-media-type draft. We never really
> > discussed signaling during the session because the discussion was
> > focused on the data model. The signaling proposed in rdap-jscontact
> > section 3 cannot go forward as either standards track or experimental
> > as it is incompatible with the current ecosystem.
>
> Why is it incompatible ?
>

As first discussed, with you, on this mailing list:
https://mailarchive.ietf.org/arch/msg/regext/k31GiGnrB4_Xu8c1pvatoT0oP9k/

-andy

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

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Andrew Newton]

On Mon, Nov 13, 2023 at 12:28 PM  wrote:
>
> Hi James,
>
> Likely I missed this part about splitting in the meeting - sorry for
> that. Can you be more specific? It is the mechanism described in 4.
> Transition Considerations? Shall it be only referring to jscontact or
> contact representation or to any transition of output representations?
>
> Here we also have draft-newton-regext-rdap-x-media-type-01 which would
> fulfil the same purpose, wouldn't it?
>
> Kind Regards,
>
> Pawel

I too share the same confusion. My understanding was that both
SimpleContact and RDAP JSContact would go experimental. I don't
remember any talk about the signaling.

The technical problems with the signaling have been discussed at
length on this mailing list. A better and more generic solution has
been proposed in the rdap-x-media-type draft. We never really
discussed signaling during the session because the discussion was
focused on the data model. The signaling proposed in rdap-jscontact
section 3 cannot go forward as either standards track or experimental
as it is incompatible with the current ecosystem.

-andy

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

Re: [regext] RDAP over DTLS

[Andrew Newton]

Nope. RDAP is intrinsically tied to HTTP.

-andy

On Thu, Nov 9, 2023 at 6:00 PM Rubens Kuhl
 wrote:
>
>
> I was reviewing a documentation that mentioned RDAP over DTLS… was that ever 
> defined ? I always thought of RDAP thru TCP-based TLS and remember ideas of 
> using RDAP over QUIC, but DTLS was not a transport I’ve heard of being used 
> with RDAP.
>
> If defined, is it a SHOULD or a MUST ?
>
>
> Rubens
>
>
> ___
> 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 agenda items IETF 118

[Andrew Newton]

Antoin,

I'm willing to give up agenda items 6.iv. (rdap-extensions) and 6.v.
(rdap-x-media-type) to give Maarten 10 minutes to discuss restful EPP.
To me that seems like a better use of face-to-face time as both of my
drafts got time at the last IETF.

-andy

On Tue, Oct 17, 2023 at 3:27 PM Antoin Verschuren
 wrote:
>
> Hi Maarten,
>
> Unfortunately, our agenda for IETF 118 is already fully booked with no space 
> to overrun.
> Perhaps we should consider a 2 hour meeting request for next IETF 119.
>
> Regards,
>
> Antoin
>
> > Op 16 okt. 2023, om 17:52 heeft Maarten Wullink 
> >  het volgende geschreven:
> >
> > Hi Antoin,
> >
> > Maybe a bit late, but would it be possible to add a few minutes for a 
> > discussion about the usefulness of REST enabled EPP.
> >
> > Thanks!
> >
> > Maarten
> >
> >
> > see below for my motivation from a mail to the list last week:
> >
> >
> > Seeing that more and more registries are moving their infrastructure into 
> > the cloud, it might be a good time to take look again at the transport used 
> > for EPP.
> > Adding a method for easily running EPP services in the cloud could make 
> > things easier for registries and registrars.
> >
> > some of the advantages i see are:
> >
> > - scaling epp services will be easier, run many stateless epp services
> > - rate limiting HTTP is easy compared to EPP TCP session and can use 
> > standard tooling for this
> > - more in line with modern web development (restful APIs)
> > - good support for monitoring of http based services
> >
> > 11 years ago we proposed to add a restful transport option (see url to 
> > draft below), at the time it got no traction but things haven changed quiet 
> > a bit since then, is this something worthy of our time to look into again?
> >
> >
> > https://datatracker.ietf.org/doc/html/draft-wullink-restful-epp-00
> >
> > ___
> > 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 mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

[Andrew Newton]

In the interest of keeping forward momentum, I think this is a good
idea. But to set expectations, with such large changes there may be a
need for a -20 to settle on the smaller details.

-andy

On Mon, Oct 2, 2023 at 4:03 PM Gould, James  wrote:
>
> Are there any concerns if we post draft-ietf-regext-epp-eai-19 as proposed 
> below, which is to revert to draft-ietf-regext-epp-eai-17 with the support 
> for one or two email addresses using either ASCII or SMTPUTF8, remove any 
> reference to the requirement for an ASCII email address, and remove the 
> concept of a transition period?  This will leave the decision related to what 
> combination of e-mail addresses to support to server policy.  If there are no 
> concerns, Dmitry and I will post draft-ietf-regext-epp-eai-19 as proposed.
>
>
>
>

___
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-01.txt

[Andrew Newton]

On Thu, Sep 21, 2023 at 6:46 AM Mario Loffredo
 wrote:
>
> [ML] Why doesn't the postal address include a property representing the city 
> ? The country code and the city are required information in RFC5733 while the 
> postal code is optional.

This is a good point. It was dropped in an exercise of simplification,
but given a lot of registries do collect it discreetly, then it should
be added back. Thanks.

>
> Last, since the RDAP implementers have already mapped the RFC5733 "addr" 
> elements to the related vCard ADR elements, why  should they change that 
> mapping instead of simply replacing the target properties with new ones ?
>
> An unstructured address can be represented through a seprated property.

As the introductory paragraph mentions, this is not about structured
addresses but about providing those elements that are often used in
non-postal contexts. We can change the text to stress the
representation of unstructured addresses.

-andy

___
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-01.txt

[Andrew Newton]

Hi Pawel,

This is a very interesting idea. Even in non-EPP registries, it is
unlikely that more than one representation of a name, etc.. will be
collected. Therefore, this reduction makes sense to me. I disagree
with wrapping name and role in the postal information as those
elements are used for non postal reasons and there are definitely
non-EPP registries that do not model this the same way.

-andy

On Wed, Sep 20, 2023 at 12:34 PM Pawel Kowalik  wrote:
>
> Hi Andrew,
>
> The new draft goes in the right direction, but for me there are still few 
> elements, that seem to be too complex for the purpose.
>
> For all fields there is an assumed plurality with lists of values, where 
> theoretically the only differentiator should be the localization, however 
> actually the data structure does not exclude that there are several values 
> with the same localization or without any localization, which might be 
> confusing and also requires a complex processing by the clients to always 
> iterate the whole list in order to find out if there is a certain 
> localization present in the response.
>
> Lists have still the issue of addressing the list elements with JSON Pointers 
> in redaction process.
>
> As localization is a specific use case and would used on a need basis, the 
> case of single value being the main use-case, I would rather see the values 
> to be singular international value, with a localization being a separate 
> optional dictionary.
>
> Using the example from 2.8 of a draft it would be something like this:
>
> {
>
>   "individualName": "Yomada Taro",
>
>   "individualNameLoc": {
>
> "ja": "山田太郎"
>
>   }
>
> }
>
> This approach allows a very compact representation if there is no 
> localization provided, and also a deterministic data structure if the 
> localization is necessary. It matches also EPP model in RFC 5733, where 
> actually max 2 postalInfo objects are allowed, one in internationalized and 
> one in local version.
>
> An access to the localization can be also very easily be implemented by the 
> clients by looking up if the "Loc" key is present and then by dictionary 
> lookup of the needed localization.
>
> I also suggest to stick to the field names and structure as defined in RFC 
> 5733, rather than defining new names or partially reusing existing ones..
>
> addr instead of postalAddress
>
> streets instead of address
>
> postalInfo as a wrapping object etc.
>
>
> Example of complete simple contact (without localization):
>
> {
>   "objectClassName" : "entity",
>   "handle":"",
>   "sc_data": {
> "kind" : "individual",
> "postalInfo": {
>   "individualName" : "Yomada Taro",
>   "roleName" : "Registration Services Help Desk",
>   "organizationName" : "ACME",
>   "addr" : {
> "streets" : [
> "Sunny Mansion #203",
> "4-7 Hommachi 2-choume",
> "Shibuya-ku, TOKYO 150-2345"
>   ],
>   "cc" : "JP-13",
>   "pc" : "150-2345"
> }
> },
> "email" : "yamada.t...@example.net",
> "voice" : ["+81(03) 1234-5678"],
> "fax:" : ["tel:+810312345679"],
> "webContacts" : ["https://example.net/contact-me";]
>   }
>   ...
> }
>
> Kind Regards,
>
> Pawel
>
>
> Am 31.08.23 um 12:02 schrieb Andrew Newton:
>
> Hi all,
>
> We have posted an update to Simple Contact. Here are the summary of the 
> changes:
>
> * removed structured names
> * removed structured addresses
> * fixed ISO-3166-2 usage
> * removed the "masked" property
> * updated the example
> * added a section on linking to vcard / jcard / jscontact
>
> Overall, this simplifies the draft significantly, which was the
> overall feedback from IETF 117.
>
> -andy
>
> -- Forwarded message -
> From: 
> Date: Thu, Aug 31, 2023 at 5:56 AM
> Subject: New Version Notification for
> draft-newton-regext-rdap-simple-contact-01.txt
> To: Andy Newton , Tom Harrison 
>
>
> A new version of Internet-Draft draft-newton-regext-rdap-simple-contact-01.txt
> has been successfully submitted by Andy Newton and posted to the
> IETF repository.
>
> Name: draft-newton-regext-rdap-simple-contact
> Revision: 01
> Title:RDAP Simple Contact
> Date: 2023-08-31
> Group:Individual Submi

Re: [regext] JSON Schema for RDAP RFC-9083

[Andrew Newton]

On Thu, Sep 21, 2023 at 6:55 AM Pawel Kowalik  wrote:
>
> 4. Schema languages give a false sense of conformance. Conformance
> tools are far more important.
>
> Schema won't replace the conformance tools for sure, as not every constraint 
> or relation can be covered with schema. But it makes it a lot of easier for 
> the implementer to have a solid base for a conforming implementation.

It is true that DDL can make things easier, especially for code
generation to start creating a codebase. But it is certainly not
enough as the industry found out with SOAP and UDDI. A number of years
ago, Pete Cordell and I put a good bit of thought into this:
https://datatracker.ietf.org/doc/html/draft-newton-json-content-rules-09
https://datatracker.ietf.org/doc/draft-cordell-jcr-co-constraints

> Therefore the default position became "use CDDL".
>
> Tooling for CDDL is like almost non existent and JSON seems to be 2nd class 
> citizen in this specification. Do you really believe it would have a take off 
> outside of CBOR?

That was never my position, but it does seem to be the prevailing
attitude of the IETF. Maybe with time we can now show CDDL was not the
answer for JSON.

-andy

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

Re: [regext] [IANA #1280008] expert review for draft-ietf-regext-rdap-redacted (rdap-json-values)

[Andrew Newton]

On Fri, Sep 8, 2023 at 8:24 AM Hollenbeck, Scott
 wrote:
> [SAH] I'm somewhat embarrassed to admit this since both Andy and I have
> reviewed this document during its development in the regext working group, but
> I think I've found a small issue. RFC 9083 defines a set of "type" values for
> use in the RDAP JSON values registry. draft-ietf-regext-rdap-redacted defines
> three additional type values, which means it's updating RFC 9083 and the set
> of type values allowed for use in the registry. The document needs to be clear
> about the fact that it's updating 9083, which it doesn't currently do. This
> would also mean that the registry itself will need to be update to note that
> this RFC-to-be is one of the references that defines the structure of the
> registry.
>
> Having said that, the requested addition to the registry looks fine to me.
>
> Scott

Doh! I did mentally recognize the extension of the registry but
neglected to think about the RFC mechanics.

I concur with Scott.

-andy

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

Re: [regext] [IANA #1280004] expert review for draft-ietf-regext-rdap-redacted (rdap-extensions)

[Andrew Newton]

David,

I have reviewed the registrations of this document and believe them to
be correct.

-andy

On Thu, Aug 31, 2023 at 4:47 PM David Dong via RT
 wrote:
>
> Dear Andy and Scott (cc: regext WG),
>
> As the designated experts for the RDAP Extensions registry, can you review 
> the proposed registration in draft-ietf-regext-rdap-redacted-14 for us? 
> Please see:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/
>
> The due date is September 14th.
>
> If this is OK, when the IESG approves the document for publication, we'll 
> make the registration at:
>
> https://www.iana.org/assignments/rdap-extensions/
>
> Unless you ask us to wait for the other reviewer, we’ll act on the first 
> response we receive.
>
> With thanks,
>
> David Dong
> IANA Services Sr. Specialist

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

Re: [regext] JSON Schema for RDAP RFC-9083

[Andrew Newton]

On Thu, Aug 31, 2023 at 1:05 PM Mario Loffredo
 wrote:
>
> AFAIU, the definition of a standard JSON data description language has been a 
> controversial matter for long. To my knowledge,  the only DDL published as 
> RFC that could work is CDDL [RFC8610]. It was primarily created for CBOR but 
> it works for JSON too.
>

Mario basically summed up the issue. I was involved in trying to get
the IETF to do something here but there was no movement. There were
many reasons:
1. JSON Schema seemed to be a moving target.
2. Something something about Yang.
3. At the time (and it may still be true), RDAP was by far the most
complex example of JSON in the IETF. Everything else was much, much
simpler and did not need a schema language.
4. Schema languages give a false sense of conformance. Conformance
tools are far more important.

Therefore the default position became "use CDDL".

My experience with RDAP mirrors #4. Most conformance issues aren't
about the JSON unless we're talking about jCard, for which schema
languages are basically useless anyway.

I would recommend using a conformance tool such as this one:
https://github.com/icann/rdap-conformance-tool

Also, ARIN's NicInfo had an RFC 7483 checker for JCR, which is
superior to JSON Schema (or at least was).

-andy

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

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

[Andrew Newton]

Hi all,

We have posted an update to Simple Contact. Here are the summary of the changes:

* removed structured names
* removed structured addresses
* fixed ISO-3166-2 usage
* removed the "masked" property
* updated the example
* added a section on linking to vcard / jcard / jscontact

Overall, this simplifies the draft significantly, which was the
overall feedback from IETF 117.

-andy

-- Forwarded message -
From: 
Date: Thu, Aug 31, 2023 at 5:56 AM
Subject: New Version Notification for
draft-newton-regext-rdap-simple-contact-01.txt
To: Andy Newton , Tom Harrison 


A new version of Internet-Draft draft-newton-regext-rdap-simple-contact-01.txt
has been successfully submitted by Andy Newton and posted to the
IETF repository.

Name: draft-newton-regext-rdap-simple-contact
Revision: 01
Title:RDAP Simple Contact
Date: 2023-08-31
Group:Individual Submission
Pages:11
URL:  
https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-01.txt
Status:   
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/
HTML: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-01.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-simple-contact
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-newton-regext-rdap-simple-contact-01

Abstract:

   This document describes an extension to the Registry Data Access
   Protocol for entity contact data using basic JSON values, objects,
   and arrays.  The data model defined by this document is purposefully
   limited to the data in-use by Internet Number Registries and Domain
   Name Registries and does not attempt to model the full data-set that
   can be expressed with other contact models such as jCard or
   JSContact.



The IETF Secretariat

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

[regext] Fwd: New Version Notification for draft-newton-regext-rdap-extensions-01.txt

[Andrew Newton]

Hi all,

Tom, Jasdip and I have put together a new version of the draft based
on feedback from the list and IETF 117.

In summary, the changes are:
* status changes from an informational to an update
* reserves two consecutive underscores for IETF definition at later
time (such as in a versioning draft)
* provides instruction on collisions of identifiers and recommends
against further use of underscores in extension identifiers
* codifies the use of query parameters with extension identifiers
* codifies the use of bare extension identifiers
* recommends the use of extension identifiers for IETF owned extensions
* clarifies that the document is not defining a versioning scheme
* discusses backward compatible and incompatible extensions
* notes current extensions that do not follow the extension guidance


-andy

-- Forwarded message -
From: 
Date: Thu, Aug 31, 2023 at 5:38 AM
Subject: New Version Notification for draft-newton-regext-rdap-extensions-01.txt
To: Andy Newton , Jasdip Singh , Tom
Harrison 


A new version of Internet-Draft draft-newton-regext-rdap-extensions-01.txt has
been successfully submitted by Andy Newton and posted to the
IETF repository.

Name: draft-newton-regext-rdap-extensions
Revision: 01
Title:RDAP Extensions
Date: 2023-08-31
Group:Individual Submission
Pages:11
URL:  
https://www.ietf.org/archive/id/draft-newton-regext-rdap-extensions-01.txt
Status:   https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/
HTML: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-extensions-01.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-extensions
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-newton-regext-rdap-extensions-01

Abstract:

   This document describes and clarifies the usage of extensions in
   RDAP.



The IETF Secretariat

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

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

[Andrew Newton]

We have created a new version of this draft incorporating feedback we
received, which can be summarized as:

1. Discussion of qvalue
2. Creation of the rdapx marker extension.

-andy

-- Forwarded message -
From: 
Date: Tue, Aug 29, 2023 at 6:55 AM
Subject: New Version Notification for
draft-newton-regext-rdap-x-media-type-01.txt
To: Andy Newton , Jasdip Singh 


A new version of Internet-Draft draft-newton-regext-rdap-x-media-type-01.txt
has been successfully submitted by Andy Newton and posted to the
IETF repository.

Name: draft-newton-regext-rdap-x-media-type
Revision: 01
Title:An RDAP With Extensions Media Type
Date: 2023-08-29
Group:Individual Submission
Pages:10
URL:  
https://www.ietf.org/archive/id/draft-newton-regext-rdap-x-media-type-01.txt
Status:   
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/
HTML: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-x-media-type-01.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-x-media-type
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-newton-regext-rdap-x-media-type-01

Abstract:

   This document defines a media type for RDAP that can be used to
   describe RDAP content with RDAP extensions.  Additionally, this
   document describes the usage of this media type with RDAP.



The IETF Secretariat

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

Re: [regext] [IANA #1279352] expert review for draft-ietf-regext-rdap-openid (rdap-extensions)

[Andrew Newton]

David,

This looks good to me.

-andy

On Tue, Aug 22, 2023 at 3:53 PM David Dong via RT
 wrote:
>
> Dear Andy and Scott (cc: regext WG),
>
> As the designated experts for the RDAP Extensions registry, can you review 
> the proposed registration in draft-ietf-regext-rdap-openid-24 for us? Please 
> see:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/
>
> The due date is September 5th.
>
> If this is OK, when the IESG approves the document for publication, we'll 
> make the registration at:
>
> https://www.iana.org/assignments/rdap-extensions/
>
> Unless you ask us to wait for the other reviewer, we’ll act on the first 
> response we receive.
>
> With thanks,
>
> David Dong
> IANA Services Sr. Specialist

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