Hi Antoin,
please find my comments below.
Il 19/02/2024 16:41, Antoin Verschuren ha scritto:
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.
[ML] Yes, that is the question.
I would also like to outline that, in this case, the difference between
correcting nits (i.e. , some unnecessary extension identifiers included
in the rdapConformance array as it is shown in some examples) and
changing substantially the draft depends just on the interpretation of
RFC9083 and such a question revealed to be matter for WG discussion when
the different interpretations came up.
Best,
Mario
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://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
--
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
--
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
