Draft: draft-ietf-core-resource-directory

Commentary: Some small mainly editorial fixes from  's review , to be merged soon . 
 From  's updated ballot : Good point , queued up . 
 From  's updated ballot : : → " The  ( always , but especially here ) then needs to verify any lookup client 's authorization before reveling this information directly ( in resource lookup ) or indirectly ( when using it to satisfy a resource lookup search criterion ) " 
 From follow - up on  's initial DISCUSS : → " regular registrations ( i.e. , per { { registration } } ) " 
 From follow - up on  's initial DISCUSS : It 'd sound like abuse of semicolons to me ; keeping it open to ask RFC editor for their technical writing expertise .
Paragraph (version A):
A web entity that stores information about web resources and
implements the REST interfaces defined in this specification for
discovery, for the creation, the maintenance and the removal of
registrations, and for lookup of the registered resources.
Paragraph (version B):
A web entity that stores information about web resources and
implements the REST interfaces defined in this specification for
discovery, for the creation, maintenance and removal of
registrations, and for lookup of the registered resources.
Paragraph (version A):
The registrant-ep includes the same registration parameters in the
POST request as it would per registration.  The registration base
URI of the registration is taken from the registrant-ep's network
address (as is default with regular registrations).
Paragraph (version B):
The registrant-ep includes the same registration parameters in the
POST request as it would with a regular registration per
registration.  The registration base URI of the registration is
taken from the registrant-ep's network address (as is default with
regular registrations).
Paragraph (version A):
In this case, the endpoint (and not the lookup clients) needs to be
careful to check the RD's authorization.
Paragraph (version B):
In this case, the endpoint (and not the lookup clients) needs to be
careful to check the RD's authorization.  The RD needs to check any
lookup client's authorization before revealing information directly
(in resource lookup) or indirectly (when using it to satisfy a
resource lookup search criterion).
Paragraph (version A):
If the client's credentials indicate any subject name that is
certified by any authority which the RD recognizes (which may be
the system's trust anchor store), all those subject names are
stored.  With CWT or JWT based credentials (as common with ACE),
the Subject (sub) claim is stored as a single name, if it exists.
With X.509 certificates, the Common Name (CN) and the complete
list of SubjectAltName entries are stored.  In both cases, the
authority that certified the claim is stored along with the
subject, as the latter may only be locally unique.
Paragraph (version B):
If the client's credentials indicate any subject name that is
certified by any authority which the RD recognizes (which may be
the system's trust anchor store), all such subject names are
stored.  With CWT or JWT based credentials (as common with ACE),
the Subject (sub) claim is stored as a single name, if it exists.
With X.509 certificates, the Common Name (CN) and the complete
list of SubjectAltName entries are stored.  In both cases, the
authority that certified the claim is stored along with the
subject, as the latter may only be locally unique.
Paragraph (version B):
Security policies / link confidentiality: Point out the RD's
obligations that follow from such a policy.