Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Regarding the use of a brief description in the registry itself as the "Specification" in "Specification Required": I missed it this time, but we ran into this same question with draft-ietf-calext-jscalendar-21, and FWIW, Barry Leiba recommended to the author that the registration procedure be changed to Expert Review. Thanks, Amanda On 8/23/23, 6:07 AM, "iesg on behalf of Robert Wilton via Datatracker" wrote: Robert Wilton has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTv8R0bod8$ [ietf[.]org] for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTvYBEfpd4$ [datatracker[.]ietf[.]org] -- DISCUSS: -- Hi, Flagging part of the IANA considerations as a DISCUSS, but I think that this should be easy to resolve: (1) p 11, sec 12.2.1. Creation of the RDAP Reverse Search Registries These registries follow the Specification Required process as defined in Section 4.5 of [RFC8126]. The designated expert should prevent collisions and confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability. References are not limited only to RFCs and simple definitions could be described in the registries themselves. I'm not sure that "simple definitions could be described in the registries themselves" is consistent with the "Specification Required" policy chosen above. -- COMMENT: -- [I support John's discuss on normative references.] I also have some other comments that you may wish to consider: (2) p 14, sec 12.2.4.2. Initial Content +==+==+ | Property | Property Path| +==+==+ | fn | $.entities[*].vcardArray[1][?(@[0]=='fn')][3]| +--+--+ | handle | $.entities[*].handle | +--+--+ | email| $.entities[*].vcardArray[1][?(@[0]=='email')][3] | +--+--+ | role | $.entities[*].roles | +--+--+ Would it be helpful for this table to include the "Description" and "Reference" properties? Minor level comments: (3) p 3, sec 1. Introduction The protocol described in this specification aims to extend the RDAP query capabilities and response to enable reverse search based on the relationships defined in RDAP between an object class for search and a related object class. The reverse search based on the domain- entity relationship is treated as a particular case of such a generic model. This introduction text seems to immediately jump into a defense as to why it is okay to standardize this functionality in an RDAP extension. This is okay, but I wonder whether it wouldn't be better if the introduction only included the last paragraph (i.e., that is stating what extension is defined in this document), and the rest of the text was moved into a "Background" subsection of the introduction. (4) p 7, sec 8. Reverse Searches Based on Entity Details Reverse search property: fn RDAP member path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3] Reference: Section 6.2.1 of [RFC6350] A minor issue, but it wasn't immediately obvious to me what 'fn' is - I initially presumed that it meant function, so I was wondering if some more text would be helpful here, and/or perhaps in the IANA registry that you are creating. Regards, Rob smime.p7s Description: S/MIME crypt
Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Hi Mario,
I see that the new text is "References are not limited only to RFCs but can
also locate document published outside of the RFC path, including informal
documentation." For IANA's purposes, this sentence isn't necessary, as the
Specification Required policy was specifically meant to encompass non-RFC
documentation (see Section 4 of RFC 8126 for registration procedure
definitions), but no problem at all with including it.
Thanks,
Amanda
On 8/24/23, 9:18 AM, "iesg on behalf of Mario Loffredo" wrote:
Hi Amanda,
Il 23/08/2023 19:51, Amanda Baber ha scritto:
> Regarding the use of a brief description in the registry itself as the
"Specification" in "Specification Required": I missed it this time, but we ran
into this same question with draft-ietf-calext-jscalendar-21, and FWIW, Barry
Leiba recommended to the author that the registration procedure be changed to
Expert Review.
Please see my response to Robert Wilton's remarks.
Think that changing the text as I proposed could solve the problem.
I'm sure that Andy and Scott as DEs would like to receive a
specification supporting a request for the registration of new reverse
search properties or new mappings.
Therefore, I would like to make the IANA Considerations section
compliant to the Specification Required policy.
Best,
Mario
>
> Thanks,
> Amanda
>
> On 8/23/23, 6:07 AM, "iesg on behalf of Robert Wilton via Datatracker"
wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-regext-rdap-reverse-search-24: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
this
> introductory paragraph, however.)
>
>
> Please refer to
https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTv8R0bod8$
[ietf[.]org]
> for more information about how to handle DISCUSS and COMMENT
positions.
>
>
> The document, along with other ballot positions, can be found here:
>
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTvYBEfpd4$
[datatracker[.]ietf[.]org]
>
>
>
>
--
> DISCUSS:
>
--
>
>
>
> Hi,
>
> Flagging part of the IANA considerations as a DISCUSS, but I think
that this
> should be easy to resolve:
>
> (1) p 11, sec 12.2.1. Creation of the RDAP Reverse Search Registries
>
> These registries follow the Specification Required process as
defined
> in Section 4.5 of [RFC8126].
>
> The designated expert should prevent collisions and confirm that
> suitable documentation, as described in Section 4.6 of [RFC8126],
is
> available to ensure interoperability. References are not limited
> only to RFCs and simple definitions could be described in the
> registries themselves.
>
> I'm not sure that "simple definitions could be described in the
registries
> themselves" is consistent with the "Specification Required" policy
chosen above.
>
>
>
--
> COMMENT:
>
--
>
> [I support John's discuss on normative references.]
>
> I also have some other comments that you may wish to consider:
>
> (2) p 14, sec 12.2.4.2. Initial Content
>
>+==+==+
>| Property | Property Path|
>+==+==+
>| fn | $.entities[*].vcardArray[1][?(@[0]=='fn')][3]|
>+--+--+
>| handle | $.entities[*].handle |
>+--+--+
>| email| $.ent
[regext] [IANA #1046536] misspelled value in the RDAP JSON values registry
Hi Andy, Thanks for catching this. The RDAP JSON Values entry for "administrative" is now spelled correctly: https://www.iana.org/assignments/rdap-json-values Best regards, Amanda Baber Lead IANA Services Specialist On Fri Jan 19 21:17:00 2018, a...@hxr.us wrote: > Hello, > > I believe the role value of "adminstrative" is misspelled (missing > second 'i') in the RDAP JSON values registry ( > https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml). > > It should be "administrative". I checked RFC 7483 to verify. > > -andy > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] [IANA #1050124] Re: misspelled value in the RDAP JSON values registry
Dear Bernhard, Thank you for catching this. The typo has been corrected: https://www.iana.org/assignments/rdap-json-values Best regards, Amanda Baber Lead IANA Services Specialist On Wed Feb 14 12:34:22 2018, rep.dot@gmail.com wrote: > On 23 January 2018 at 20:32, Amanda Baber via RT mat...@iana.org> wrote: > > The description of "result set truncated due to authorization" has a > typo: > > s/thaadt/that/ > > according to https://tools.ietf.org/html/rfc7483#section-10.2.1 > > In > "... to some clients thaadt proper authorization ..." > replace "thaadt" with "that" > > thanks, ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] [IANA #1411725] expert review for draft-ietf-regext-epp-eai (epp-extensions)
Dear EPP extensions experts (cc: regext) It looks like the name of the EPP extension being registered by draft-ietf-regext-epp-eai was changed in version -27, after the IESG telechat (the last time IANA reviewed the document). Given that Scott's one of the authors, can another expert confirm that this change is OK? https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-eai-27 thanks, Amanda Baber IANA Operations Manager On Tue Jan 28 12:01:13 2025, gavin.br...@icann.org wrote: > Hi David, > > As requested by Scott, I have reviewed the registration request in > this document and it looks good to me. It meets the criteria for > registration laid out in RFC 7451. > > Regards, > > Gavin. > > > On 27 Jan 2025, at 19:49, Hollenbeck, Scott > > wrote: > > > > Fellow experts, I need to ask one of you to review and approve the > > request described below since I'm one of the authors of the draft. > > Would one of you please confirm that the request to register the > > extension in IANA's EPP extension registry is valid? > > > > David/IANA, I believe it's OK to use the first response received. > > > > Scott > > > >> -Original Message- > >> From: David Dong via RT > >> Sent: Sunday, January 26, 2025 1:13 AM > >> Cc: Hollenbeck, Scott ; draft-ietf-regext- > >> epp- > >> eai@ietf.org; regext@ietf.org > >> Subject: [EXTERNAL] [IANA #1411725] expert review for draft-ietf- > >> regext- > >> epp-eai (epp-extensions) > >> > >> 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. > >> > >> Dear Scott (cc: regext WG), > >> > >> Could you request for the designated secondary experts for the > >> Extensions for > >> the Extensible Provisioning Protocol (EPP) registry to review the > >> proposed > >> registration in draft-ietf-regext-epp-eai-23 for us? As you're a co- > >> author on > >> this draft, we would need one of the secondary experts to approve > >> this > >> request. > >> > >> Please see: > >> > >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > >> ietf-regext-epp- > >> eai/__;!!PtGJab4!9p9qxFJOYDi2XbXTMtS2MPK4QQ4n9OvCevuZezEZcoiD8gXBJlQCyZQ3iVEErP1umL1pWLC2UiPNxKBPcJZv12CrbNxP9UA$ > >> [datatracker[.]ietf[.]org] > >> > >> The due date is February 8th. > >> > >> If this is OK, when the IESG approves the document for publication, > >> we'll make > >> the registration at: > >> > >> https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml > >> > >> Unless you ask us to wait for other reviewers, we’ll act on the > >> first response > >> we receive. > >> > >> With thanks, > >> > >> David Dong > >> IANA Services Sr. Specialist > > -- > Gavin Brown > Principal Engineer, Global Domains & Strategy > Internet Corporation for Assigned Names and Numbers (ICANN) > > https://www.icann.org > ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
