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"
<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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
