Hello Andy, Scott,
Let’s take a specific example from the RIR search draft (a specification with
multiple extension identifiers defined) to test-drive these options. Say, an IP
network search response:
{
"rdapConformance": [ "rdap_level_0", "rirSearch1",
"ips", "ipSearchResults", ... ],
...
"ipSearchResults": [
{
"objectClassName": "ip network",
"handle": "XXXX-RIR",
"startAddress": "192.0.2.0",
"endAddress": "192.0.2.127",
...
"links": [
...,
{
"value": "https://rdap.example.com/ip/192.0.2.0/25";,
"rel": "up",
"href": "https://rdap.example.com/ips/rirSearch1/up/192.0.2.0/25";,
"type": "application/rdap+json"
},
{
"value": "https://rdap.example.com/ip/192.0.2.0/25";,
"rel": "down",
"href": "https://rdap.example.com/ips/rirSearch1/down/192.0.2.0/25";,
"type": "application/rdap+json"
},
{
"value": "https://rdap.example.com/ip/192.0.2.0/25";,
"rel": "top",
"href": "https://rdap.example.com/ips/rirSearch1/top/192.0.2.0/25";,
"type": "application/rdap+json"
},
{
"value": "https://rdap.example.com/ip/192.0.2.0/25";,
"rel": "bottom",
"href": "https://rdap.example.com/ips/rirSearch1/bottom/192.0.2.0/25";,
"type": "application/rdap+json"
}
]
},
{
"objectClassName": "ip network",
"handle": "YYYY-RIR",
"startAddress": "192.0.2.0",
"endAddress": "192.0.2.255",
...
}
]
}
Though the specification defines 5 extension identifiers (“rirSearch1 “, “ips”,
“ipSearchResults”, “autnum”, and “autnumSearchResults”), note how the example
only includes “rirSearch1 “, “ips”, and “ipSearchResults”:
* “ipSearchResults” for the "ipSearchResults" member.
* “ips” and “rirSearch1“ for the construction of the “href” values in the
“links” member of an IP network object for link relations.
IMO, this presently points to Option 2 from the choices Mario posed for the WG.
Per the “construction of response” guidance from RFC 9083, is that OK in your
opinion?
Jasdip
From: regext <regext-boun...@ietf.org> on behalf of Hollenbeck, Scott
<shollenbeck=40verisign....@dmarc.ietf.org>
Date: Tuesday, February 20, 2024 at 12:31 PM
To: a...@hxr.us <a...@hxr.us>
Cc: i...@antoin.nl <i...@antoin.nl>, mario.loffr...@iit.cnr.it
<mario.loffr...@iit.cnr.it>, regext@ietf.org <regext@ietf.org>
Subject: Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
Andy, I agree that that's an incorrect interpretation. Content is part of the
response, too, and as such it has to be included when the response is
constructed/formed/assembled/whatever.
Scott
> -----Original Message-----
> From: Andrew Newton (andy) <a...@hxr.us>
> Sent: Tuesday, February 20, 2024 12:23 PM
> To: Hollenbeck, Scott <shollenb...@verisign.com>
> Cc: ietf=40antoin...@dmarc.ietf.org <i...@antoin.nl>;
> mario.loffredo=40iit.cnr...@dmarc.ietf.org <mario.loffr...@iit.cnr.it>;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-
> search
>
> Caution: This email originated from outside the organization. Do not click
> links
> or open attachments unless you recognize the sender and know the content is
> safe.
>
> "construction of the response" can be interpreted strictly to mean only the
> JSON structure of the response. IMHO, that is an incorrect interpretation nor
> does it track with RDAP as it is used because profile extensions such as the
> ICANN and NRO extensions also dictate content not just structure.
>
> -andy
>
>
> On Tue, Feb 20, 2024 at 10:20 AM Hollenbeck, Scott
> <shollenbeck=40verisign....@dmarc.ietf.org> 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 <regext-boun...@ietf.org> On Behalf Of Antoin Verschuren
> > Sent: Monday, February 19, 2024 10:42 AM
> > To: Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org>
> > Cc: regext <regext@ietf.org>
> > Subject: [EXTERNAL] Re: [regext] WG LAST CALL
> > draft-ietf-regext-rdap-rir-search
> >
> >
> >
> > Caution: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> >
> > 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
> <mario.loffredo=40iit.cnr...@dmarc.ietf.org> 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 authors asked me to add the
> following note (please Tom and Jasdip elaborate, if you think I missed
> something or didn't present correctly your point of view):
> >
> > "documents may mandate specific behaviour around identifiers for the
> purposes of signalling, and it's fine for this sort of thing to override the
> requirement above. (nro_rdap_profile_asn_flat_0 and
> nro_rdap_profile_asn_hierarchical_0 are examples of this, where the
> document itself requires implementations to pick one or the other, and that's
> fine.)"
> >
> >
> >
> >
> >
> > Best,
> >
> > Mario
> >
> >
> >
> > Il 05/02/2024 15:35, Antoin Verschuren ha scritto:
> >
> > Hi All,
> >
> >
> >
> > After some prolonged discussion, the chairs will now close this working
> group last call that should have ended 11 December 2023.
> >
> > We have had comments and approval during WGLC from 4 working group
> participants and the document shepherd and no objections.
> >
> > That has lead to 2 new versions of the document during WGLC that started
> with version 05.
> >
> >
> >
> > The document shepherd for this document is Mario Loffredo.
> >
> >
> >
> > In order for the document to progress and sent to the IESG, the document
> shepherd will need to do a final review of the following:
> >
> >
> >
> > 1. Please confirm all suggested changes have been addressed in version 07.
> >
> > 2. Please ask James Gould to confirm his changes have been addressed as he
> promised to do another review.
> >
> > 3. Make sure the Nits are addressed.
> >
> > 4. Confirm that all changes between version 05 and version 07 are editorial
> and not substantive.
> >
> > 5. When all the above concerns are addressed, please write the document
> shepherd writeup.
> >
> >
> >
> > Thanks to everyone that contributed to this review!
> >
> >
> >
> > Regards,
> >
> >
> >
> > Jim and Antoin
> >
> > REGEXT WG Co-Chairs
> >
> >
> >
> >
> >
> > Op 27 nov. 2023, om 15:51 heeft Antoin Verschuren
> <ietf=40antoin...@dmarc.ietf.org> het volgende geschreven:
> >
> >
> >
> > 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://secure-
> web.cisco.com/1aRHex_IkhlvhcngHtfTqhMihpaDNXSofjCvrnjGt
> > QMqBFCRwGiZ4QCyMvPbtu7UnrfiOhZpDo6N3T1GhT1saLnyEcQTnS5Mb-
> iJJh-a67AdziM
> > IfBhYnpPfnVTkoB3Ro_-K-
> NR4iDDwMtpumc5MtAHaD4yMabD339m6crnCcgZUL9bmk2FBr
> >
> DEiEAI9FE5Fkco9VxNIBLpPxatQoMX8ULYqUBrDJSs3MJEaDDuJp_8NcAe5FiYoI
> n6jKcm
> > V0kXWpYV0onfL2OMPoPo_-r28KHVMTb57M8nDUEkEQUW5gc-
> yK_vKKQ2AeN6H4vMiyKgLl
> > /https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-rir
> > -search%2F05%2F
> >
> >
> >
> >
> >
> > 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://secure-web.cisco.com/1XXENLm7ayVnYl_0DoXxrulXmswCsE7Tiy-
> eBRNPZ
> > 6g67J7Jgj043VzUTsL49iOYB-d-
> gk7_xlrAnVfYvWQTE5jHkqdPQkxZoFSOuQVErAT5b5r
> >
> OilhXtJMXQItgOR_nPRe1y9Ya2cumBjJe51jO0ywyc1ElcY0eSkkcnITMH_6eIvEp
> v5con
> > adzqV5Rnh8PMP3vGfBmxCO8yKeQz765C4N3L-L-Fw6dpZNvqkBRf8oH-
> J9ujRRtwmBUFkK
> > hAfurq5dkigzHEzqfTFYVmP5BZg9-
> I5GMvXq1aJKVt6kWdTpRr_7hOlMW6lqkACBgWI4vV
> > /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
> >
> > _______________________________________________
> >
> > regext mailing list
> >
> > regext@ietf.org
> >
> > https://secure-web.cisco.com/1XXENLm7ayVnYl_0DoXxrulXmswCsE7Tiy-
> eBRNPZ
> > 6g67J7Jgj043VzUTsL49iOYB-d-
> gk7_xlrAnVfYvWQTE5jHkqdPQkxZoFSOuQVErAT5b5r
> >
> OilhXtJMXQItgOR_nPRe1y9Ya2cumBjJe51jO0ywyc1ElcY0eSkkcnITMH_6eIvEp
> v5con
> > adzqV5Rnh8PMP3vGfBmxCO8yKeQz765C4N3L-L-Fw6dpZNvqkBRf8oH-
> J9ujRRtwmBUFkK
> > hAfurq5dkigzHEzqfTFYVmP5BZg9-
> I5GMvXq1aJKVt6kWdTpRr_7hOlMW6lqkACBgWI4vV
> > /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
> >
> > --
> >
> > 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://secure-web.cisco.com/1vVb829HGCwPxZxHtbhAYqvDJ-
> krBWHW5hpLiS0Y9F
> > 4lEaRfebXO4jocI3n3-
> 9EdNt2D9tBcLsnRPWSO88NgGxGFpUEtfUp4GPHGyGAE0S2IMSpY
> >
> _CmHmFI6McAIteydKlpqa5nTXdGT3T4m7NRfatY4kRc7mUYTGT1D1tlAshmX
> hrYMOP0efV
> > -
> aE4SE31j_ITd7SIHvxpgXP_pumeHia2Bxg9sxgJSghjHzfwSkkLXiZehYoFMFwkMI
> wn7v
> > cEONAIVortYg9GXEciG-MT3NRZFqRvPwj4p-2CBBJ-
> eDXj0DnmnHvqN0JHj17NGeapyUr/
> > http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo
> >
> >
> >
> > _______________________________________________
> > regext mailing list
> > regext@ietf.org
> > https://secure-web.cisco.com/1XXENLm7ayVnYl_0DoXxrulXmswCsE7Tiy-
> eBRNPZ
> > 6g67J7Jgj043VzUTsL49iOYB-d-
> gk7_xlrAnVfYvWQTE5jHkqdPQkxZoFSOuQVErAT5b5r
> >
> OilhXtJMXQItgOR_nPRe1y9Ya2cumBjJe51jO0ywyc1ElcY0eSkkcnITMH_6eIvEp
> v5con
> > adzqV5Rnh8PMP3vGfBmxCO8yKeQz765C4N3L-L-Fw6dpZNvqkBRf8oH-
> J9ujRRtwmBUFkK
> > hAfurq5dkigzHEzqfTFYVmP5BZg9-
> I5GMvXq1aJKVt6kWdTpRr_7hOlMW6lqkACBgWI4vV
> > /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________
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
