Hi Amanda,
thanks a lot for your quick reply.
You're right. I can remove that sentence.
Thanks a lot,
Mario
Il 25/08/2023 00:17, Amanda Baber ha scritto:
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" <iesg-boun...@ietf.org on
behalf of mario.loffr...@iit.cnr.it> 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"
<iesg-boun...@ietf.org on behalf of nore...@ietf.org> 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
>
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!8M_wkeZusApvSDJ_cHdL1CkfX7fOKasFMjYg8XsDCD1b7gx-9xmnX6d_93GTGJNz-4XQDHl3yhQ1FO_jcTlnUJGwE0D4YyQOPcua$
[ietf[.]org]
--
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:
https://urldefense.com/v3/__http://www.iit.cnr.it/mario.loffredo__;!!PtGJab4!8M_wkeZusApvSDJ_cHdL1CkfX7fOKasFMjYg8XsDCD1b7gx-9xmnX6d_93GTGJNz-4XQDHl3yhQ1FO_jcTlnUJGwE0D4YzP1MC9G$
[iit[.]cnr[.]it]
--
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
