Hi,
The discussion is ongoing but I will try to summarise the status.
In the current state the draft is supporting pretty good the use cases
of RDAP user interacting directly with RDAP server via the browser or
using command line tools.
The draft is not supporting the use cases of RDAP use
please explain these issues in a bit more detail? For
example, how does adding support for the redirect_uri and state query
parameters help? What do they do? What's the cookie issue?
Scott
-Original Message-
From: regext On Behalf Of Pawel Kowalik
Sent: Thursday, October 6, 202
Comment inline
On Thu, Oct 6, 2022 at 8:22 AM Pawel Kowalik wrote:
In my opinion the WG shall get the consensus around whether these web
application related use-cases shall be supported in order to move
forward with the WGLC.
Can you elaborate on what you mean by "web application&quo
Am 07.10.2022 um 14:49 schrieb Hollenbeck, Scott :
From: regext On Behalf Of
Pawel Kowalik
Sent: Thursday, October 6, 2022 7:24 PM
To: Andrew Newton
Cc: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17
Caution
Hi Mario,
Am 11.10.22 um 16:38 schrieb Mario Loffredo:
Il 11/10/2022 15:04, Andrew Newton ha scritto:
On Tue, Oct 11, 2022 at 8:16 AM Mario Loffredo
wrote:
my humble opinion is that this document shouldn't deal with any kind
of RDAP client other than a browser.
Looking at the chapter 1 of
Am 12.10.22 um 14:56 schrieb Hollenbeck, Scott:
[SAH] Since the draft already includes text that describes support for two
different types of clients, I'm OK with the idea of adding (or re-adding) text
that describes support for web service clients, too. The challenge is in
deciding how to supp
Am 12.10.22 um 19:07 schrieb Hollenbeck, Scott:
For the token revocation RFC 7009 can be used as-is, all we'd need to
specify
would be the path segment like farv1_token_revocation and add signalling if
the RDAP server supports it or not in the /help response.
[SAH] 7009 describes the interacti
Am 13.10.22 um 14:24 schrieb Hollenbeck, Scott
For the token revocation RFC 7009 can be used as-is, all we'd need to
specify would be the path segment like farv1_token_revocation and add
signalling if the RDAP server supports it or not in the /help
response.
[SAH] 7009 describes the interaction
Am 17.10.22 um 15:32 schrieb Hollenbeck, Scott:
[SAH] This update addresses most of the feedback received during the recent WG
last call. There are still a few open issues for which I'm hoping to see WG
discussion:
Thank you Scott.
1. How do we address web service clients?
[PK] I think the
Am 17.10.22 um 15:32 schrieb Hollenbeck, Scott:
[SAH] This update addresses most of the feedback received during the recent WG
last call. There are still a few open issues for which I'm hoping to see WG
discussion:
Thank you Scott.
1. How do we address web service clients?
[PK] I think the
Am 17.10.22 um 15:32 schrieb Hollenbeck, Scott:
[SAH] This update addresses most of the feedback received during the recent WG
last call. There are still a few open issues for which I'm hoping to see WG
discussion:
Thank you Scott.
1. How do we address web service clients?
[PK] I think the
I'm really sorry for flooding the list. Connection issues in the train
made my email client send it 3 times unnoticed.
Kind Regards,
Pawel
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Am 19.10.22 um 14:13 schrieb Hollenbeck, Scott:
[SAH] If the PII data you're referring to is what's included in the
userClaims, this might not be an issue if the claims aren't returned,
correct?
Correct
Kind Regards,
Pawel
___
regext mailing lis
Hi Scott,
Am 20.10.22 um 21:02 schrieb Hollenbeck, Scott:
Am 19.10.22 um 14:13 schrieb Hollenbeck, Scott:
[SAH] If the PII data you're referring to is what's included in the
userClaims, this might not be an issue if the claims aren't returned,
correct?
Correct
[SAH] Does anyone object to remo
Am 21.10.22 um 15:46 schrieb Hollenbeck, Scott
[SAH] OK, if we keep the "userClaims" I probably need to add text to the
Security Considerations section. How about this:
"Some of the responses described in this specification return information to a client from an
RDAP server that is intended to
Am 26.10.22 um 15:48 schrieb Mario Loffredo:
[ML] Before going into detail with technical aspects, think we should
address some privacy implications connected with the following sentence:
RDAP server SHOULD merge the scopes requested by the client with the
scopes needed for authorization pu
Am 27.10.22 um 14:11 schrieb Hollenbeck, Scott:
1. How do we address web service clients?
[PK] Please find attached my draft on Web Service Clients. Most of it is
based
on the concepts of the version 9. Scope "feature" is also included in the
proposal.
[SAH] I've been testing the proposed a
Am 28.10.22 um 11:35 schrieb Mario Loffredo:
[PK] The text was proposed in the way which does not exclude certain
valid use-cases but still allows the RDAP server to set its own
policy on sharing data.
This is clear that RDAP server is acting as sort of Identity Provider
towards its clients,
Hi Mario,
Am 28.10.22 um 16:36 schrieb Mario Loffredo:
[PK] There is quite relevant drawback from this scenario, that there
is no assurance the identity provided to the RDAP client by the IdP
would be the same as the one used towards the RDAP server if there is
no relation. An IdP may hold m
Hi Mario,
Am 29.10.22 um 16:41 schrieb Mario Loffredo:
Apart from that, based on my interpretation of GDPR, a generic
third-party client application processing the PII coming from the
RDAP server as claims should be authorized by the end user through a
specific request for consent.
[PK]
Hi,
If anyone is interested in discussing this draft and the current issues
in more depth than than the WG session time would allow on Thursday
Scott and I will be setting up a public side meeting during IETF 115.
Wednesday 9 November 16:30 - 17.00 (UTC +0) in Richmond 6.
Online Link
http
Hi Mario,
Am 07.11.22 um 11:27 schrieb Mario Loffredo:
I'm very busy Wednesday but, hopefully, I should be free for that time.
Great you can make it.
After a quick reading, a first big doubt from my side is about what is
stated in section 4 regarding "redirect URIs".
Browser-based appli
escribed, but just want to make
sure we properly cover the mobile app RDAP client (I wrote one… and
intend to implement openid)
Regards, Marc.
Le 9 nov. 2022 à 18:09, Pawel Kowalik a écrit :
Hi,
Thanks for the participation in the meeting today.
There are not yet any conclusions, which would be d
Am 09.11.22 um 18:47 schrieb Marc Blanchet:
There was a very good presentation today in the OAuth group about it,
along the lines "don't use multi-device flows on the same device" and
I think there is a point about it.
In my eyes a mobile app is more like a web app.
Yes. It is an http clien
Hi,
I would opt to work on the option 2, at least to the point we can see
how much both types of clients have in common and how much do they go
split ways.
Based on this the WG could take more educated decision whether to break
it into 2 drafts or remain with one.
Kind Regards,
Pawel
Am
Hi,
As an action item after IETF 115 I reviewed
draft-ietf-regext-rdap-redacted-09 before WG LC and have the following
questions / remarks:
Section 3, first paragraph:
> Redaction in RDAP can be handled in multiple ways. The use of
> placeholder text for the values of the RDAP fields, such
Hi Scott,
Am 15.11.22 um 14:54 schrieb Hollenbeck, Scott:
[SAH] Based on the testing you and I've been doing, we already know that web
service clients require token processing features that aren't currently
specified. That's fixable; earlier versions of the draft included text that
was demonstra
lman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Pawel Kowalik
Head of Product Management
--
DENIC eG, Kaiserstraße 75 - 77, 60329 Frankfurt am Main, GERMANY
E-Mail:pawel.kowa...@denic.de, Fon: +49 173 3087096
https://w
Hi Scott,
Am 15.11.22 um 17:54 schrieb Hollenbeck, Scott:
[...]
A "pure OAuth2" solution is probably way more warrant of future, IMHO.
Marc.
[SAH] ...but it's not OpenID Connect, which is the focus of the current draft.
Incorporating these concepts into the current draft could mean significant
Hi Mario,
My feedback below.
Am 15.11.22 um 19:58 schrieb Mario Loffredo:
Hi Pawel,
thanks a lot for your review.
Please find my comments inline.
Il 15/11/2022 17:28, Pawel Kowalik ha scritto:
Hi Mario,
I reviewed this draft and have 2 questions:
- Reverse search property - the draft
Hi James,
See my feedback below.
Am 15.11.22 um 21:15 schrieb Gould, James:
[...]
JG - The use of placeholder values for redaction is prohibited based on the second normative
sentence. The normative language is needed to implement the redaction defined by the RDAP
extension. I agree that s
Hi Scott,
Am 17.11.22 um 15:47 schrieb Hollenbeck, Scott:
Is this a correct sequence of steps for a web service client flow?
The RDAP Web Service Client sends an RDAP "help" query to an RDAP server to
determine the type and capabilities of the OpenID Providers (Ops) that are
used by the RDAP se
Hi Scott,
Am 17.11.22 um 20:26 schrieb Hollenbeck, Scott:
The RDAP Web Service Client sends queries that require user
identification, authentication, and authorization to an RDAP server
that include the ID Token in an HTTP bearer authorization header.
[PK] The client should never be sending ID
Hi Scott,
Am 18.11.22 um 14:01 schrieb Hollenbeck, Scott:
[...]
I would strongly opt for this scenario, as most of the frameworks for
resource server do not go well with multiple token issuer schema, so
the implementation would be a way more complex RDAP server side.
+ 1
[SAH] Me too. This is
Hi James,
My comments also inline.
Am 22.11.22 um 14:18 schrieb Gould, James:
[...] [PK] Looking at the Abstract and the Introduction of the draft
it reads "This document describes an RDAP extension for explicitly
identifying redacted RDAP response fields, using JSONPath as the
default expres
Hi James,
My comments below.
Am 23.11.22 um 14:17 schrieb Gould, James:
[...]
JG3 – What triggered the creation of this extension was a proposal to
use placeholder text for redaction, which in my opinion is an
anti-pattern that needs to be directly addressed. I believe that you
see the nee
*Fellow Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
*From: *Pawel Kowalik
*Date: *Wednesday, November 23, 2022 at 9:23 AM
*To: *James Gould ,
"draft-ietf-regext-rdap-redac...@ietf.org"
*Cc: *"re
Hi,
My comments below.
Am 27.11.22 um 22:49 schrieb Tom Harrison:
[...]
I still think that custom properties are useful for the reasons above.
On the other hand, their possible misuse should be ruled somehow.
Here in the following a possible statement limiting the scope of custom
properties:
Hi Mario,
My comment inline.
Am 28.11.22 um 21:20 schrieb Mario Loffredo:
"A custom reverse search property MUST NOT collide with a
registered reverse
search property and MUST NOT match an RDAP property, or any of its
variants,
matched by a registered reverse search property."
[PK] not sure a
Hi Mario,
Am 29.11.22 um 07:46 schrieb Mario Loffredo:
Hi Pawel,
Il 28/11/2022 22:02, Pawel Kowalik ha scritto:
Hi Mario,
My comment inline.
Am 28.11.22 um 21:20 schrieb Mario Loffredo:
"A custom reverse search property MUST NOT collide with a
registered reverse
search property and
Hi Scott,
I have a bit of difficulty with those definitions.
I think this starts with the definition of a client.
RFC 2616 defines it as follows:
client
A program that establishes connections for the purpose of sending
requests.
user agent
The client which initiates a
Hi Scott,
Am 30.11.22 um 17:39 schrieb Hollenbeck, Scott:
-Original Message-
From: Pawel Kowalik
Sent: Wednesday, November 30, 2022 11:15 AM
To: Hollenbeck, Scott ; mario.loffr...@iit.cnr.it;
regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Web Service Client Flow
Caution: This email
ation system would make it easier to
operate and use RDAP without the need to maintain server-specific
client credentials. This document describes a federated
authentication system for RDAP based on OpenID Connect.
[SAH] This is my first attempt for text that addresses token-oriented
Hi Scott,
Feedback below.
Am 06.12.22 um 15:23 schrieb Hollenbeck, Scott:
Thanks for the feedback. More below...
- we discussed that we do not care that much about remote OPs, however the
issue of access_token coming from an unknown OP remains. My proposal for a
simple solution would be just
Hi James,
Thanks for posting the new version incorporating the changes. I reviewed
it and have few comments on that:
1. As the WG consensus seems to be to keep normative language in the
form "placeholder text , MUST NOT be used for redaction" I would
recommend to extend Abstract and Intr
Hi James,
Please find my comments embedded below.
Am 19.12.22 um 14:54 schrieb Gould, James:
On 12/19/22, 2:43 AM, "Pawel Kowalik" wrote:
Hi James,
Thanks for posting the new version incorporating the changes. I reviewed
it and have few comments on that:
1.
Hi,
The current draft addresses all the points I've brought up.
One of the points was actually the discoverability. The draft describes
4 predefined search properties: fn, handle, email, role.
The support for all of them is optional, so the client would not know if
the query is supported or no
I support the adoption.
Kind Regards,
Pawel
Am 19.12.22 um 15:33 schrieb Antoin Verschuren:
This is the formal adoption request for RDAP RIR Search:
https://datatracker.ietf.org/doc/draft-harrison-regext-rdap-rir-search/
Please review this draft to see if you think it is suitable for
Hi James,
Am 22.12.22 um 14:51 schrieb Gould, James:
"This document describes an RDAP extension for specifying methods of
redaction of RDAP responses and explicitly identifying redacted RDAP
response fields, using JSONPath as the default expression language."
This change will be incorpora
Hi Scott,
Responses below.
Am 04.01.23 um 13:58 schrieb Hollenbeck, Scott:
- in the Section 3.1.3 the Sequence diagram for session-oriented client
should
also contain RDAP server <-> OP interactions to correspond to the sequence
diagram of token-oriented clients
[SAH] What exactly is missing
Hi,
My comment below.
Am 11.01.23 um 19:03 schrieb Marc Blanchet:
Le 11 janv. 2023 à 12:43, Gould, James a
écrit :
Mario,
I'm assuming that JSContact will define an expected format for the "uid" field that we must comply with in RDAP, which is not needed for
RDAPs use case. Use of redac
Hi Marc,
Comment below
Am 16.01.23 um 16:49 schrieb Marc Blanchet:
Le 11 janv. 2023 à 12:43, Gould, James a
écrit :
Mario,
I'm assuming that JSContact will define an expected format for the "uid" field that we must comply with in RDAP, which is not needed for
RDAPs use case. Use of reda
Hi Julien,
Answer embedded.
Am 16.01.23 um 20:33 schrieb Julien Bernard:
- section 4.1
I'm not that familiar with OIDC and that's might be the issue but I
don't really understand the need for
additionalAuthorizationQueryParams. Is there a way to clarify this or
a reference that would help?
tocol.
Let's wait for a response and then we'll be able to make a definitive
proposal about this matter.
Meantime, thanks everyone who has joined the discussion thus far.
Best,
Mario
Il 16/01/2023 23:33, Marc Blanchet ha scritto:
Le 16 janv. 2023 à 16:18, Pawel Kowalik a é
Hi,
Am 26.01.23 um 20:33 schrieb Jasdip Singh:
[SAH] Thanks for the feedback, Mario. I still don't think this is a good idea,
but if mine is a minority opinion I'll update the text to remove the MUST and
include config info so a server can describe the type(s) of clients it
supports. Please folk
Hi Scott,
It looks good, I have few minor points:
1. The new paragraph in Section 3 uses a term "bearer token". I suggest
to use "Access Token" as a defined term (same in 6.2).
Also the "session" in this case can go beyond the lifespan of the Access
Token if token refresh is possible.
2. I
Hi Scott,
Feedback inline.
Am 02.02.23 um 13:56 schrieb Hollenbeck, Scott:
Also the "session" in this case can go beyond the lifespan of the Access Token
if
token refresh is possible.
[SAH] Yes, the concept of the session is directly related to the existence and
validity of an Access Token,
+1
Am 20.03.23 um 14:40 schrieb James Galvin:
The document editors have indicated that the following document is ready for
submission to the IESG to be considered for publication as a Proposed Standard:
Registration Data Access Protocol (RDAP) Reverse Search
https://datatracker.ietf.org/doc/d
+1
Am 17.04.23 um 15:27 schrieb Antoin Verschuren:
The document editors have indicated that the following document is ready for
submission to the IESG to be considered for publication as a Proposed Standard:
Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://data
+1
I support the publication of the document.
Kind Regards,
Pawel
Am 26.06.23 um 16:02 schrieb James Galvin:
The document editors have indicated that the following document is ready for
submission to the IESG to be considered for publication as a Proposed Standard:
Federated Authentication
Hi Andy,
Just to be sure - the comments refer to
draft-newton-regext-rdap-extensions-00, not to
draft-newton-regext-rdap-x-media-type-00, right?
I just got confused as the comment are in the thread of the latter.
Kind Regards,
Pawel
Am 26.06.23 um 15:32 schrieb Gould, James:
Andy,
Thank
Hi Andy,
Thanks for putting down this draft. A method for the client to signal
supported or wanted extensions is really needed.
A remark to the Section 3: I think all cases should be covered by this
section. Currently I'm missing, the case when the server would support
more extensions than r
Hi Andrew,
Answers inline.
Am 12.07.23 um 16:12 schrieb Andrew Newton:
/help is used by humans, if at all.
-andy
If there are valid use cases, I'd like to hear them. But computing
history is full of discovery failures up and down the stack. CORBA.
UDDI. DDDS.
RDAP OpenID is one of promine
Hi Andrew,
Answers inline.
Am 12.07.23 um 15:35 schrieb Andrew Newton:
Another remark to the media type. RFC7480 specifies the usage of
'application/json', 'application/rdap+json' or both. Why the draft
changes the requirement to require only 'application/rdap+json'? Is this
change required
Hi,
> Am 17.07.2023 um 17:32 schrieb Jasdip Singh :
>
> [JS] This is a fair point, Pawel. Would you suggest considering the latter
> method (query parameters) as well, given it may not survive a redirect?
Not really. Too much hassle and complexity just to support a de facto non RDAP
client. RD
Hi,
Reading the feedback from John Klensin again, the main problem seems to
be that only 1 address does not leave any room for policy choices by all
actors in the chain (mainly registries and registrars) whether to
support a "backup" all-ASCII address or not. This is a fair point.
Now, if we
l 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
Hi,
Some comments below.
Am 31.08.23 um 19:56 schrieb 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
Hi Andy,
Am 25.09.23 um 16:04 schrieb Andrew Newton:
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.
[PK] Makes sense to me to be able to have
I copy on that. It was a topic of wider interest during the last CENTR
Tech meeting and it would be good to have a wider IETF community view on
this in terms of standards.
Kind Regards,
Pawel
Am 20.10.23 um 10:13 schrieb Maarten Wullink:
Andy,
Thank you for your kind offer to give up your a
Hi Gavin,
Am 20.10.23 um 14:23 schrieb Gavin Brown:
Hi Pawel,
On 19 Oct 2023, at 06:04, Pawel Kowalik wrote:
Hi Gavin,
Am 18.10.23 um 13:57 schrieb Gavin Brown:
Question on 2.2 element. Why is this element not OPTIONAL? What am I
overseeing by thinking it should be optional, as is with
issue to proceed let’s discuss what is the best way to
address it. I am still of an opinion that this WG is the best group of people
with the right expertise to move this topic forward.
Kind regards
Pawel Kowalik
> Am 22.03.2024 um 01:18 schrieb Maarten Wullink
> :
>
>
> RFC5
Hi,
Thank you for a valuable feedback in the session in Vancouver on Domain
Connect.
As mentioned there is a renewed draft. I would appreciate more feedback
from the working group on the content of the document itself, even if
not adopted.
https://datatracker.ietf.org/doc/draft-kowalik-rege
is no obligation for id to match.
[1] https://datatracker.ietf.org/doc/draft-sanz-openid-dns-discovery/
[2] https://datatracker.ietf.org/doc/draft-bertola-dns-openid-pidi-architecture/
Kind Regards,
Pawel Kowalik
Expert Domain Processes and Identity
Domain Services
1&1 IONOS SE | Hinterm Hauptbahnh
Hi Scott,
Responses inline below.
> > 3.1.2. Overview
[...]
> [SAH] I'm open to specific suggestions when you say "make /session/login a
> fully interactive flow for humans, without any RESTful elements, or make it
> fully RESTful without the interactive part". However, I believe that some
>
On Tue, 12 Apr 2022 at 15:09, Hollenbeck, Scott
wrote:
>
> > -Original Message-
> > From: Pawel Kowalik
> > Sent: Tuesday, April 12, 2022 3:32 AM
> > To: Hollenbeck, Scott
> > Cc: regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] Feedback t
Hi Scott,
> [PK] sure, not insisting on dynamic registration. How do you want to
> proceed
> > with drafting the text update?
> > Do you maintain the test somewhere on github or alike where I could chip
> in
> > a proposal?
>
> [SAH] Please send proposed text to the list. I'm still doing this draf
On Mon, 25 Apr 2022 at 14:09, Hollenbeck, Scott
wrote:
> Thanks, I’ll take a look. One question, though: why keep the “id” query
> parameter? If used, we’re always going to have to do issuer discovery. It
> may be simpler to just not use that parameter.
>
>
[PK] in case "remote_iss" is specified,
> Personally, I'm not in favor of the exact match between all the
aforementioned names and in a
> previous mail I had expressed my opinion about excluding the version
information from that match.
> It seemed to me that such approach could result in better versioning the
RDAP extensions,
> especial
Hi Andrew,
On 12.02.25 15:09, Andrew Newton (andy) wrote:
On Wed, Feb 12, 2025 at 1:42 AM Pawel Kowalik wrote:
[PK] I am typically of an opinion that simple is better than complicated.
In this case however I have my concerns that even though new rules would be
defined
the specifications not
Hi,
As a preliminary work for analysis of commonly used EPP elements and
extensions we launched a TLD registry survey over CENTR and other ccTLD
organisations to get some quantifiable insights.
Just in case you are not aware of if so far, I forward it here as well,
so you may provide your in
Hi,
As extensions draft is the first to get through the WG doors and
dependency for others
I took it for a more detailed review. Sorry it is quite long.
If responding to a particular issue, I would appreciate separate email
threads
with distinct subject if the issues are not related. This wou
Hi,
Thinking of interactions between the client and server that versioning
draft assumes I think we are heading towards 2-RTT model for every request.
Step 1: The client makes an HTTP GET request to the /help endpoint of
the RDAP server.
Step 2: The response is processed to extract rdapConfo
Hi,
I am not against adopting this document on the merits of it. Especially
if there would be folks joining the WG to support its progress.
On the other hand I am concerned the WG has still a lot of WIP drafts,
which are having moderate traction. We agreed to have "Extension" draft
out of th
Hi Andy,
On 12.02.25 17:06, Andrew Newton (andy) wrote:
Allowing bare identifiers still leave the choice open for extensions which have
a potential of generic use.
Why does requiring a prefix preclude generic use?
Of course technically nothing, because syntactically a prefixed
identifier is
Hi Andy,
On 05.02.25 21:41, Andrew Newton (andy) wrote:
Hi all,
We, the author team, have posted a new version of this draft. This
reflects 22 closed issues from the tracker, and these are noted in the
draft text with an aside.
All that said, I think our efforts to do carve-outs based on exist
ng guidance, would it be more productive if we held an interim
> meeting before the next IETF to focus on ironing out any disagreements,
> especially the one about bare identifiers?
>
> Jim/Antoin/Orie, please advise on this matter.
>
> Thanks,
> Jasdip
>
>
>
Hi Andy,
On 02.04.25 16:31, Andrew Newton (andy) wrote:
[...]
In fact "the rules" set in 2.1 of RFC9083 are no rules, but a
recommendation (SHOULD) itself. So I argument actually to keep the
status quo of RFC9083 as opposed to defining new rules as now the
change of -05 proposes.
I agree t
one
about bare identifiers?
Jim/Antoin/Orie, please advise on this matter.
Thanks,
Jasdip
*From:* Pawel Kowalik
*Date:* Tuesday, April 1, 2025 at 12:11 PM
*To:* Andrew Newton (andy) , regext@ietf.org
*Subject:* [regext] Re: simplifying the extensions rules
Hi Andy,
On 31.03.25 16:50, Andrew Newton (andy) wrote:
Hi all,
At IETF 122, Pawel brought up the lack of time to discuss the
simplification of the extension rules as outlined in the email below.
From what I can tell, the working group agrees with the simplification
of rules on writing RDAP
90 matches
Mail list logo
