Hi Andy,
Il 13/11/2023 19:30, Andrew Newton ha scritto:
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
Speaking as co-Chair and including the responses by Jim Gould and Andy Newton
under separate cover in this thread, I would say these are excellent questions
and they should be resolved by the working group as it considers how to move
forward the functionality described in Section 4.
For the
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
We also implemented the signal in section 5 of
draft-gould-regext-rdap-versioning, using the "versioning" query parameter. We
intend to make draft-gould-regext-rdap-versioning more generic to support
opaque versioning (use of extension identifier only) and semantic versioning
(extension
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?
+1
> On 13 Nov 2023, at 15:53, James Galvin wrote:
>
> Following up from last week’s REGEXT meeting, there was consensus in the room
> that the document:
>
>
Following up from last week’s REGEXT meeting, there was consensus in the room
that the document:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact-16/
Should be split into two documents: the signaling function and the extension.
The signaling function draft would be put on the
Thanks Scott
I just would not like to be the person to tell Mr Duane Wessels about
"wide" and "narrow" Glue.
tim
On Mon, Nov 13, 2023 at 10:26 AM Hollenbeck, Scott
wrote:
> Thanks for the feedback, Tim. The -00 version of the draft had the
> practices grouped as observed practices and
Thanks for the feedback, Tim. The -00 version of the draft had the practices
grouped as observed practices and theoretical practices, perhaps we can look
at that again. We’ll also look at adding a paragraph to Section 3.1 to
describe the wide vs. narrow glue situation.
Scott
From: Tim
Hello James,
Given the feedback during the regext session in Prague, we’ll proceed with your
suggestion of registering 2 additional extension id’s – “ips” and “autnums” –
beside “rir_search”.
Thanks,
Jasdip
From: "Gould, James"
Date: Thursday, November 9, 2023 at 3:35 PM
To: Jasdip Singh ,
James,
This approach seems to me as striking the right balance, while allowing for a
consistent DNS view (with deleted domains not showing up in delegations), and
an eventually consistent registry database (after the purge).
I see no conceptual downsides in this, and I believe it fulfills the
Hi everyone,
just removed the "Description" field from the Reverse Search Mapping
registry and both "Change Log" and "Implementation Status" section.
No action from IANA is needed.
Apart from possible text cleaning, think we are done.
Best,
Mario
Messaggio Inoltrato
Internet-Draft draft-ietf-regext-rdap-reverse-search-26.txt is now available.
It is a work item of the Registration Protocols Extensions (REGEXT) WG of the
IETF.
Title: Registration Data Access Protocol (RDAP) Reverse Search
Authors: Mario Loffredo
Maurizio Martinelli
Name:
13 matches
Mail list logo
