Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT)

[Barry Leiba <[e-mail]>]

Ping...

On Fri, Jan 29, 2021 at 10:05 AM Barry Leiba <[e-mail]> wrote:
>
> Ben, can you check version -26 and see how much of your ballot is
> addressed there?
>
> Christian, do you think you've addressed all of Ben's issues in -26?
>
> Barry
>
> On Tue, Nov 3, 2020 at 12:28 PM Christian Amsüss <[e-mail]> wrote:
> >
> > (This is one of the point-to-point follow-up mails on the RD -25
> > reviews; for the preface, please see the preceding mail on "The various
> > positions on draft-ietf-core-resource-directory-25" at
> > <https://mailarchive.ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>).
> >
> > As DISCUSS:
> >
> > > I agree with Roman that the authorization model seems under-developed.
> > > While I recognize that there is need for flexibility across various
> > > deployments, I think that we should be providing a default model (and
> > > procedures for it) that will apply in many cases, and let
> > > deployments specify alternate models if needed.  This stuff is hard
> > > enough to get right that we should have a secure option that people can
> > > use if they don't need to have customized details.  (To be clear, I
> > > agree with the change of focus from -24 to -25 on the properties that a
> > > security policy needs to provide and/or consider, as that is
> > > fundamentally the important thing.  I just want a fallback/default
> > > option that "does something reasonable in most cases" in addition.
> > > Doing that by reference to some other existing thing would be fine, if
> > > such a thing exists.)
> >
> > response:
> >
> > There is no external policy we could reference, so a new section was created.
> > The First-Come-First-Remembered policy implements one of the candidates that
> > were considered for this role, and was picked because unlike its "endpoint name
> > comes from the certificate" it is a mode which an implementation can use
> > without any further configuration whatsoever.
> >
> > The related changes can be viewed in
> > https://github.com/core-wg/resource-directory/issues/258.
> >
> > > In particular, the current text seems to rely on the authorization
> > > model including:
> > >
> > > (1) the RD knowing how clients will be using it (and thus what
> > > properties the RD needs to enforce), which in the general case cannot be
> > > known (though for static networks it could be), yet I don't see any
> > > discussion that indicates this as a prerequisite; and
> > >
> > > (2) the client either knowing out-of-band that an entity is authorized
> > > to act as a RD or just blindly trusting any of the unauthenticated (*)
> > > advertisement mechanisms.  (* Yes, there may be some protection in the
> > > network on subscribing to the relevant multicast address, DNS-SD, etc.,
> > > but the client cannot a priori know that such protections are in place.)
> > >
> > > Relatedly, the naming model and naming authority should have some
> > > clearer discussion.  We do mention in Section 7 the possibility for a
> > > weak naming model where the RD is responsible for enforcing uniqueness
> > > of names but otherwise link attributes are the primary authorization
> > > criteria (vs. a traditional scheme with a naming authority and naming
> > > hierarchy), but with naming as a fundamental prerequisite of any
> > > authentication/authorization scheme, I think clearer discussion of how a
> > > naming model is to be selected (and, perhaps more importantly, that it
> > > must be fixed as part of a given deployment) for a given network is
> > > needed.
> >
> > respond:
> >
> > The responsibilities are the other way around. The RD does not need to know the
> > clients' expectations, the clients may only expect things they know to be true
> > of the RD.
> >
> > See GENERIC-WHOPICKSMODEL.
> >
> > > If I understand correctly, we have some codepoint squatting going on in
> > > the examples (e.g., for resource types).
> >
> > response:
> >
> > The rt=temperature-c, rt=light-lux and if=sensor are used where endpoints
> > mimick the examples of RFC6690; it is a point here to have things look just
> > like in direct discovery.
> >
> > The if=core.a and if=core.p use values from the expired and partially abandoned
> > core-interfaces -- given its future is unclear, they've been replaced by
> > examples with tag URIs, as has the et=oic.d.sensor (a value that's registered,
> > but not to for et but for rt) and rt="light"; rt=sensor was dropped as it was
> > not essential to the example.
> >
> > The individual changes are listed in
> > https://github.com/core-wg/resource-directory/pull/266.
> >
> > > We should talk about the security properties of the various RD discovery
> > > mechanisms that are defined.
> >
> > response:
> >
> > A section was added in the security considerations on this topic (see
> > https://github.com/core-wg/resource-directory/pull/275 for text
> > changes). It does not go into the properties of each mechanism, as the host
> > discovery steps are generally unprotected; instead, it emphasizes the
> > importance of checking the RD's authorization for any security properties the
> > client would expect. In the context of the server authorization topic (see
> > OPEN-SERVER), it was added that if the authorization is conditional on the
> > resources being advertised with a particular resource type, that authorization
> > already needs to be checked during the discovery phase (details in
> > https://github.com/core-wg/resource-directory/pull/306).
> >
> > As COMMENT:
> >
> > > My apologies for where these comments diverge off into rambling
> > > incoherency, or where I'm misunderstanding something that's clearly laid
> > > out; this document had the misfortune of being the last one I got to
> > > this week.
> > >
> > > Section 1
> > >
> > >    [RFC6690] only describes how to discover resources from the web
> > >    server that hosts them by querying "/.well-known/core".  In many
> > >    constrained scenarios, direct discovery of resources is not practical
> > >    due to sleeping nodes, disperse networks, or networks where multicast
> > >    traffic is inefficient.  These problems can be solved by employing an
> > >    entity called a Resource Directory (RD), which contains information
> > >    about resources held on other servers, allowing lookups to be
> > >    performed for those resources.
> > >
> > > nit(?): I'd consider specifying that the RD is "a trusted entity".
> > > (Even when the resources themselves are authenticated, a hostile RD can
> > > still deny existence of a given resource, so by choosing to use an RD
> > > there is some level of trust involved.)
> >
> > response:
> >
> > Putting it in there as a trusted entity would give the reader a wrong
> > impression of the general case. Any trust placed in the RD must be earned by a
> > security policy backed by the RD's credentials.
> >
> > > Section 2
> > >
> > >    Resource Directory (RD)
> > >       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.
> > >
> > > nit: the list structure is not parallel here.  Maybe "for discovery,
> > > creation, maintenance, and removal of registrations, and for lookup of
> > > the registered resources"?
> >
> > response:
> >
> > The intended structure that's linearized into the sadly untreeish structure of
> > written language was
> >
> > * discovery
> > * of registrations
> >   - creation
> >   - maintenance
> >   - removal
> > * lookup
> >
> > I think this is what the current text expresses, whereas the proposed one
> > groups discovery with "of registrations", while it's more a top-level thing.
> >
> > >    Commissioning Tool
> > >       Commissioning Tool (CT) is a device that assists during the
> > >       installation of the network by assigning values to parameters,
> > >       naming endpoints and groups, or adapting the installation to the
> > >       needs of the applications.
> > >
> > > Is "the installation of the network" a one-time event?   (Might a CT be
> > > involved when adding a new device to a network at a later time?)
> >
> > response:
> >
> > CTs can come back to help new devices into the network; the text has been
> > clarified to that point in
> > https://github.com/core-wg/resource-directory/pull/295.
> >
> > There are remaining questions about how long a network can operate autonomously
> > while the CT is absent and can thus not refresh registrations, but those exceed
> > the scope of the document. (Discussed at
> > https://github.com/core-wg/resource-directory/issues/290).
> >
> > > Section 3.1
> > >
> > >    Information SHOULD only be stored in the RD if it can be obtained by
> > >    querying the described device's /.well-known/core resource directly.
> > >
> > > When might that not be the case?
> >
> > response:
> >
> > The prime example here is with devices that don't even have a copy of what they
> > might want to (but can't for resource constraints) express there; those use a
> > CT to do their work.
> >
> > The second example I can come up with is when devices have complex
> > confidentiality requirements on the links, but rely on the RD and thus publish
> > data to an authorized RD of which they don't even know who precisely might be
> > authorized to read them.
> >
> > > Section 3.2
> > >
> > >    The RD architecture is illustrated in Figure 1.  An RD is used as a
> > >    repository of registrations describing resources hosted on other web
> > >    servers, also called endpoints (EP).  An endpoint is a web server
> > >    associated with a scheme, IP address and port.  A physical node may
> > >
> > > (side note) hmm, I feel like in the HTTP world an endpoint is more
> > > likely to be associated with a DNS name than an IP address, in common
> > > usage.  Also, we later go on to assert that the endpoint's name has
> > > primacy and that the IP address/port can be ephemeral.
> >
> > response:
> >
> > This is leading the reader from the CoAP definition of endpoints to the
> > endpoints as registrants as used in the RD.
> >
> > >    An endpoint uses specific interfaces to register, update and remove a
> > >    registration.  It is also possible for an RD to fetch Web Links from
> > >    endpoints and add their contents to its registrations.
> > >
> > >    At the first registration of an endpoint, a "registration resource"
> > >    is created, the location of which is returned to the registering
> > >    endpoint.  The registering endpoint uses this registration resource
> > >    to manage the contents of registrations.
> > >
> > > Does the "RD fetches links unilaterally" case count as a "first
> > > registration of an endpoint"?  I'm having a hard time seeing how these
> > > two statements are consistent with each other, and a naive reading
> > > admits the possibility that a given endpoint could be "locked out" of
> > > the ability to manage the contents of its registrations.
> >
> > response:
> >
> > The act of the endpoint triggering the RD to fetch links from it is the
> > creation. And the "locking out" is the correct reading -- a client that uses
> > simple client has no way of managing the contents. If it were capable enough to
> > do that, it'd go the regular registration route.
> >
> > > Section 4
> > >
> > >    REST clients (registrant-EPs and CTs during registration and
> > >    maintenance, lookup clients, RD servers during simple registrations)
> > >    MUST be prepared to receive any unsuccessful code and act upon it
> > >    according to its definition, options and/or payload to the best of
> > >    their capabilities, falling back to failing the operation if recovery
> > >    is not possible.  In particular, they should retry the request upon
> > >
> > > "MUST be prepared [...] to the best of their abilities" seems
> > > non-actionable.  The stuff after "In particular", on the other hand, is
> > > actual concrete guidance that could be mandated using normative
> > > language.
> >
> > response:
> >
> > Right; fixed in https://github.com/core-wg/resource-directory/pull/276.
> >
> > > Section 4.1
> > >
> > >    1.  In a 6LoWPAN, just assume the Border Router (6LBR) can act as an
> > >        RD (using the ABRO option to find that [RFC6775]).  Confirmation
> > >        can be obtained by sending a Unicast to "coap://[6LBR]/.well-
> > >        known/core?rt=core.rd*".
> > >
> > > nit(?): I was unaware that "Unicast" was a proper noun.
> >
> > response:
> >
> > Addressed in https://github.com/core-wg/resource-directory/pull/277.
> >
> > > Section 4.3
> > >
> > >    "core.rd" in the query string.  Likewise, a Resource Type parameter
> > >    value of "core.rd-lookup*" is used to discover the URIs for RD Lookup
> > >    operations, core.rd* is used to discover all URI paths for RD
> > >    operations.  [...]
> > >
> > > Is the distinction between URIs (for RD Lookup) and URI paths (for RD)
> > > important here?
> >
> > response:
> >
> > No, it isn't. Fixed in https://github.com/core-wg/resource-directory/pull/277.
> >
> > >    While the link targets in this discovery step are often expressed in
> > >    path-absolute form, this is not a requirement.  Clients of the RD
> > >    SHOULD therefore accept URIs of all schemes they support, both as
> > >    URIs and relative references, and not limit the set of discovered
> > >    URIs to those hosted at the address used for URI discovery.
> > >
> > > I'm not sure I see how the "not limit [...] to those hosted at the
> > > address used for URI discovery" follows from the non-requirement for
> > > expression of the link-targets from discovery in path-absolute form.
> > > (Given the ability to send the discovery query to a multicast address,
> > > the guidance seems okay; it's just the "therefore" that is puzzling me.)
> >
> > response:
> >
> > If it was a requirement on the server, the clients could rely on it and thus
> > implicitly limit the set by failing to parse the full URIs.
> >
> > (It could say "explicitly or implicitly limit", but only the "implicitly
> > limit" case justifies the "therefore".)
> >
> > >    It would typically be stored in an implementation information link
> > >    (as described in [I-D.bormann-t2trg-rel-impl]):
> > >
> > >    Req: GET /.well-known/core?rel=impl-info
> > >
> > > This seems to be depicting a link-relation type that is not registered
> > > at https://www.iana.org/assignments/link-relations/link-relations.xhtml
> > > , i.e., codepoint squatting.  Please put in a stronger disclaimer that
> > > this is an example link relation type, not just an example exchange.
> >
> > response:
> >
> > A note has been added that the type is just proposed in a WIP document (in
> > https://github.com/core-wg/resource-directory/pull/278).
> >
> > > Section 5
> > >
> > > These first few paragraphs give the impression that this is
> > > first-come-first-served with minimal authentication or authorization
> > > checking.  Mentioning that there are authorization checks, with a
> > > forward-reference, might be helpful.
> >
> > response:
> >
> > It's more a last-come-longest-remembered, but even the most minimal security
> > policies would ensure that the registration resources belong to the "same"
> > device (for whatever the policy defines as same).
> >
> > Clarified in https://github.com/core-wg/resource-directory/pull/292.
> >
> > >    further parameters (see Section 9.3).  The RD then creates a new
> > >    registration resource in the RD and returns its location.  The
> > >
> > > Is this returned "registration resource" expected to function as a
> > > "capability URL" (https://www.w3.org/TR/capability-urls/) that would
> > > need to contain an appropriate amount of entropy to be reasonably
> > > unguessable by parties other than the registrant-ep/CT responsible for
> > > it?
> >
> > response:
> >
> > No, it is not a capability URL -- it will be discoverable through the endpoint
> > lookup interface.
> >
> > Note that around ACE, bearer tokens (which capability URLs are) are generally
> > discouraged in favor of proof-of-possession tokens.
> >
> > >    The registration request interface is specified as follows:
> > >
> > >    Interaction:  EP -> RD
> > >
> > > I thought that the CT could be a requestor as well as the EP.
> >
> > response:
> >
> > Yes it can be. The expression in the interaction tables is an artifact of the
> > CTs being a not-even-special case of EPs, but as we have both of them in the
> > rest of the text, so do we now in those lists. (Changes in
> > https://github.com/core-wg/resource-directory/pull/309).
> >
> > >          well.  The endpoint name and sector name are not set when one
> > >          or both are set in an accompanying authorization token.
> > >
> > > What should the RD do if they are set but also present in the
> > > accompanying authorization token?
> >
> > response:
> >
> > The wording has been updated in
> > https://github.com/core-wg/resource-directory/pull/273; it now (by
> > construction, but also explicitly) explains conflict handling.
> >
> > >    Req: POST coap://rd.example.com/rd?ep=node1
> > >    Content-Format: 40
> > >    Payload:
> > >    </sensors/temp>;ct=41;rt="temperature-c";if="sensor",
> > >
> > > (side note) XML for the sensors, not SenML?  With Carsten as an author,
> > > even? ;)
> >
> > response:
> >
> > This is clearly a mistake, and got removed in an emergency update in
> > https://github.com/core-wg/resource-directory/pull/279.
> >
> > More seriously, though, these examples are from RFC6690 (which does not have
> > ct= entries for reasons of chronology), and keeping them aligned is a good
> > thing.
> >
> > >    An RD may optionally support HTTP.  Here is an example of almost the
> > >    same registration operation above, when done using HTTP.
> > >
> > >    Req:
> > >    POST /rd?ep=node1&base=http://[2001:db8:1::1] HTTP/1.1
> > >    Host: example.com
> > >
> > > Wouldn't "Host: rd.example.com" be closer to "almost the same
> > > registration"?
> >
> > response:
> >
> > Fixed in https://github.com/core-wg/resource-directory/pull/277.
> >
> > (I had brief qualms about introducing a protocol-negotiation situation here,
> > but performing "almost the same registration" over two protocols already
> > necessarily does that).
> >
> > > Section 5.1
> > >
> > > I'm a little uneasy about specifying new behavior for POST to the
> > > existin /.well-known/core that was defined by RFC 6690 for other uses.
> > > What factors go into using the same well-known URI vs. defining a new
> > > one for this usage?
> >
> > response:
> >
> > It-always-having-been-that-way, primarily. As no large deployments are known,
> > this is fixed in https://github.com/core-wg/resource-directory/pull/259
> > by switching to a standalone /.well-known/rd.
> >
> > >    The sequence of fetching the registration content before sending a
> > >    successful response was chosen to make responses reliable, and the
> > >    caching item was chosen to still allow very constrained registrants.
> > >
> > > I'm not sure what "the caching item" is supposed to be (if it's not a
> > > typo/misordering of words).
> >
> > response:
> >
> > Now phrased as "the point about caching" (in
> > https://github.com/core-wg/resource-directory/pull/277) which should
> > be easier to read. A few lines up we recommend that the RD caches the .wk/c,
> > and this provides the rationale.
> >
> > > Section 5.3
> > >
> > >    queries concerning this endpoint.  The RD SHOULD continue to provide
> > >    access to the Registration Resource after a registration time-out
> > >    occurs in order to enable the registering endpoint to eventually
> > >    refresh the registration.  The RD MAY eventually remove the
> > >    registration resource for the purpose of garbage collection.  If the
> > >    Registration Resource is removed, the corresponding endpoint will
> > >    need to be re-registered.
> > >
> > > (This MAY is actually a MUST for the simple registration case, per §5.1,
> > > right?)
> >
> > response:
> >
> > No, it's a choice there as well. One server may keep them around forever, and
> > when the simple client comes back it'll show with the same registration
> > resource in the resource lookup. Another server may GC it and assign a
> > different registration resource when it returns.
> >
> > > Section 5.3.1
> > >
> > >    An update MAY update the lifetime or the base URI registration
> > >    parameters "lt", "base" as in Section 5.  Parameters that are not
> > >
> > > What about the "extra-attrs"; are they inherently forbidden from
> > > updates?
> >
> > response:
> >
> > The introduction paragraph was overly specific and fixed in
> > https://github.com/core-wg/resource-directory/pull/294.
> >
> > >                             base :=  Base URI (optional).  This
> > >          parameter updates the Base URI established in the original
> > >          registration to a new value.  If the parameter is set in an
> > >          update, it is stored by the RD as the new Base URI under which
> > >          to interpret the relative links present in the payload of the
> > >          original registration, following the same restrictions as in
> > >          the registration.  If the parameter is not set in the request
> > >
> > > nit: is it the interpretation of relative links that is following the
> > > same restrictions as in the registration, or the new value of the
> > > parameter being supplied in the update?
> >
> > response:
> >
> > The restrictions apply to the new value, and were moved up there in
> > https://github.com/core-wg/resource-directory/pull/294.
> >
> > >    The following example shows how the registering endpoint updates its
> > >    registration resource at an RD using this interface with the example
> > >    location value: /rd/4521.
> > >
> > > The path component "4521" contains a worryingly small amount of
> > > unpredictableness; I would prefer examples that used longer random
> > > locations, as for capability URLs.  (Throughout the document, of
> > > course.)  See also draft-gont-numeric-ids-sec-considerations, that I'm
> > > AD sponsoring, though I do not see any clear issues on first glance.
> >
> > response:
> >
> > See comment on the original capability URL question -- they are not.
> >
> > > (Also, it might be worth another sentence that this update is serving
> > > just to reset the lifetime, making no other changes, since this might be
> > > expected to be a common usage.)
> >
> > response:
> >
> > Stating purpose rather than mechanism now (since
> > https://github.com/core-wg/resource-directory/pull/294).
> >
> > > Section 6
> > >
> > > With "Resource Lookup" and "Endpoint Lookup" as (apparent) top-level
> > > siblings, would it make sense to put 6.2, or at least 6.3, as
> > > subsections under 6.1?
> >
> > response:
> >
> > It would from a hierarchical table-of-contents point of view, but given the
> > focus of lookup is on resource lookup, the existing sequence captures the
> > narrative of "With an RD, you can look up resources, here is how you use it,
> > here is what it looks like, and by the way if you really need it you can even
> > look at the registrations themselves".
> >
> > > Section 6.1
> > >
> > >    Resource lookup results in links that are semantically equivalent to
> > >    the links submitted to the RD.  The links and link parameters
> > >    returned by the lookup are equal to the submitted ones, except that
> > >    the target and anchor references are fully resolved.
> > >
> > > Are the "submitted ones" the submissions at registration time, or during
> > > the lookup query itself?  (I assume registration-time, but being
> > > explicit costs little.)
> >
> > response:
> >
> > Some words added for clarity in
> > https://github.com/core-wg/resource-directory/pull/294.
> >
> > >    If the base URI of a registration contains a link-local address, the
> > >    RD MUST NOT show its links unless the lookup was made from the same
> > >    link.  The RD MUST NOT include zone identifiers in the resolved URIs.
> > >
> > > Same link as what?
> >
> > response:
> >
> > The link the endpoint sits on; clarified in
> > https://github.com/core-wg/resource-directory/pull/294.
> >
> > > Section 6.2
> > >
> > >    The page and count parameters are used to obtain lookup results in
> > >    specified increments using pagination, where count specifies how many
> > >
> > > (We haven't introduced the page and count parameters yet.)
> >
> > response:
> >
> > Wording has been enhanced in
> > https://github.com/core-wg/resource-directory/pull/294.
> >
> > >    operator as in Section 4.1 of [RFC6690].  Attributes that are defined
> > >    as "link-type" match if the search value matches any of their values
> > >
> > > Where is it specified how an attribute might be "defined as
> > > 'link-type'"?  This is the only instance of the string "link-type" in
> > > this document, and it does not appear in RFC 6690 at all...
> >
> > response:
> >
> > That should have said "relation-types"; it does now, and also refers to
> > the 6690 ABNF (since
> > https://github.com/core-wg/resource-directory/pull/294.
> >
> > >    references) and are matched against a resolved link target.  Queries
> > >    for endpoints SHOULD be expressed in path-absolute form if possible
> > >    and MUST be expressed in URI form otherwise; the RD SHOULD recognize
> > >    either.  The "anchor" attribute is usable for resource lookups, and,
> > >    if queried, MUST be for in URI form as well.
> > >
> > > I don't see how it can be only a SHOULD to recognize either given these
> > > generation criteria.
> >
> > response:
> >
> > If the URI is on a different scheme/host, I assert things are clear. (Just to
> > ensure I didn't get your point wrong.)
> >
> > Otherwise, in practice there can happen mistakes where server and client
> > disagree about the default values of the Uri-Scheme, Uri-Host and Uri-Port
> > options -- as anyone who's ever tried to set up an HTTP reverse proxy for a
> > WebDAV server can attest to. We're trying to avoid creating these situations,
> > but when they do happen. We don't automatically declare the offending party
> > broken by putting a MUST here, but encourage the peer to assist it. The client
> > can help by providing the relative reference (for then, disagreement passses
> > unnoticed), and the server by recognizing the full URI (for the client may have
> > obtained it and not know that it'd match what the server thinks is its Uri-Host
> > name).
> >
> > (The "and MUST be expressed in URI form otherwise" sounds like a factual
> > necessity, but it is here to rule out the corner case of a client handing out
> > //hostname/path style references).
> >
> > > Section 6.3
> > >
> > >    The following example shows a client performing a lookup of all
> > >    resources of all endpoints of a given endpoint type.  It assumes that
> > >    two endpoints (with endpoint names "sensor1" and "sensor2") have
> > >    previously registered with their respective addresses
> > >    "coap://sensor1.example.com" and "coap://sensor2.example.com", and
> > >    posted the very payload of the 6th request of section 5 of [RFC6690].
> > >
> > > Er, the 6th request is a GET; do we mean to say the response to the 6th
> > > request?
> >
> > response:
> >
> > Yes. Fixed in https://github.com/core-wg/resource-directory/pull/294.
> >
> > > Section 6.4
> > >
> > >    The endpoint lookup returns registration resources which can only be
> > >    manipulated by the registering endpoint.
> > >
> > > This seems to leave it unclear whether the endpoint lookup is expected
> > > to return resources that the requestor will not have permission to
> > > manipulate (in addition to those it does have permission for).
> >
> > response:
> >
> > Clarified in https://github.com/core-wg/resource-directory/pull/294.
> >
> > >    While Endpoint Lookup does expose the registration resources, the RD
> > >    does not need to make them accessible to clients.  Clients SHOULD NOT
> > >    attempt to dereference or manipulate them.
> > >
> > > But why expose them at all if they're not going to be accessible?
> >
> > response:
> >
> > They serve as identifiers (think URI rather than URL), and may additionally be
> > used in implementation defined operations on the resource that could be allowed
> > for administrators. Last but not least, link-format (unlike the upcoming CoRAL)
> > does not have means of talking about something without naming it.
> >
> > (I do see the point, and if we started RD anew with the benefit of having
> > CoRAL, chances are this would look a bit different, and the names would not be
> > exposed to just any lookup client).
> >
> > The WG discussion of this did, however, lead to a point added to the security
> > considerations about the RD's choice of what to put in there (change in
> > https://github.com/core-wg/resource-directory/pull/267).
> >
> > >    An RD can report endpoints in lookup that are not hosted at the same
> > >    address.  [...]
> > >
> > > The "same address" as what?
> >
> > response:
> >
> > Sharpened in https://github.com/core-wg/resource-directory/pull/294.
> >
> > > Section 7.1
> > >
> > >    Whenever an RD needs to provide trustworthy results to clients doing
> > >    endpoint lookup, or resource lookup with filtering on the endpoint
> > >
> > > How will the RD know whether the client is expecting trustworthy
> > > results?  (When would a client *not* expect trustworthy results?)
> >
> > response:
> >
> > It won't per-client, it is configured for one. See GENERIC-WHOPICKSMODEL.
> >
> > >    name, the RD must ensure that the registrant is authorized to use the
> > >    given endpoint name.  This applies both to registration and later to
> > >    operations on the registration resource.  It is immaterial there
> > >    whether the client is the registrant-ep itself or a CT is doing the
> > >    registration: The RD can not tell the difference, and CTs may use
> > >
> > > I suppose there might be plausible authorization models where a
> > > return-routability check to a given address constitutes authorization to
> > > use that address as an endpoint name, in which case the RD can tell the
> > > difference between a registrant-ep and a CT attempting to act on its
> > > behalf.
> >
> > WGF-6
> > response:
> >
> > The RD might do such checks, but then again the EP might just be using
> > different network interfaces simultaneously. At that point where the EP uses a
> > different (and usually dormant) network interface for registration, the line
> > between EP and the CT gets blurry; we tolerate that blurriness because the
> > distinction is not so much a technical one (the REST server does not care
> > whether the request originates at its network peer, is proxied through there or
> > sent from there on behalf of someone completely different) as long as the
> > credentials are good.
> >
> > Frankly, I'm personally not too happy with distinguishing CTs in the first
> > place; it is more reflective of what I understand to be an industry practice
> > than a distinction in this CoAP application.
> >
> > >    When certificates are used as authorization credentials, the
> > >    sector(s) and endpoint name(s) can be transported in the subject.  In
> > >    an ACE context, those are typically transported in a scope claim.
> > >
> > > As Russ noted in the Gen-ART review, "transported in the subject" is
> > > sufficiently vague to not really be actionable.  It might be better to
> > > say that the holder of the private key corresponding to the public key
> > > certified in the certificate is generally considered authorized to act
> > > on behalf of any identities (including endpoint names) contained in the
> > > certificate's subject name.
> >
> > response:
> >
> > See GENERIC-SUBJECT.
> >
> > > Section 7.1.1
> > >
> > >    Conversely, in applications where the RD does not check the endpoint
> > >    name, the authorized registering endpoint can generate a random
> > >    number (or string) that identifies the endpoint.  The RD should then
> > >
> > > How much entropy/randomness in the random name?  Does a CSPRNG need to
> > > be used?  (I do see the follow-up about doubling the length in case of
> > > failure or starting with a UUID if that's not possible, but some
> > > guidance on where to start still seems appropriate.)
> >
> > respond:
> >
> > There is no requirement here as collisions only result in retries.
> >
> > For those cases where the client implementer thinks they can get away with not
> > implementing retry, UUID URNs are pointed to, which themselves cover the topic.
> >
> > > Section 7.2
> > >
> > >    When lookup clients expect that certain types of links can only
> > >    originate from certain endpoints, then the RD needs to apply
> > >    filtering to the links an endpoint may register.
> > >
> > > As before, how will the RD know what behavior clients are relying on?
> >
> > response:
> >
> > It will not. It may, however, advertise it explicitly. If, for example, an
> > application like LwM2M always ensures trusted endpoint names, the RD may
> > advertise as rt="core.rd-lokup-ep example.lwm2m", and then clients that trust
> > that metadatum (which they'll want to verify from some claim) know they can
> > trust the RD to have checked ep names.
> >
> > See also GENERIC-WHOPICKSMODEL
> >
> > >    An RD may also require that only links are registered on whose anchor
> > >    (or even target) the RD recognizes as authoritative of.  One way to
> > >
> > > I don't think I can parse this sentence (especially "the RD recognizes
> > > as authoritative of").
> >
> > response:
> >
> > Rephrased to "require that links are only registered if the registrant is
> > authorized to publish information about the anchor [...] of the link." in
> > https://github.com/core-wg/resource-directory/pull/294.
> >
> > > Section 8
> > >
> > > In contexts where we discuss DTLS and TLS as being generally comparable,
> > > we typically will state that DTLS replay protection is required in order
> > > to provide equivalent levels of protection.
> >
> > response:
> >
> > This item rippled quite a bit beyond the original response of "Huh? CoAP
> > doesn't already do this? Well, here we need it".
> >
> > As things stand, requiring replay protection make it harder to exploit the
> > issue described at OPEN-REPLAY-FRESHNESS, but once that is addressed for good,
> > replay protection should not be necessary any more for the RD, as all its
> > operations are becoming long-term idempotent.
> >
> > > We might also want to reiterate or refer back to the previous discussion
> > > of the potential for attributes or resource/endpoint names, link
> > > relations, etc. that may need to be confidential, the relevant access
> > > control/filtering, and the avenues by which disclosure of resource names
> > > can occur even when access to those resources will not be permitted.  (I
> > > think some of this overlaps with 8288 and 6690, but don't mind repeating
> > > it.)
> >
> > response:
> >
> > There is a pointer back saying that the necessary access control depends on the
> > protection objectives set in the policies (since
> > https://github.com/core-wg/resource-directory/pull/250).
> >
> > > Section 8.1
> > >
> > > It's probably worth reiterating that all name comparisons must be done
> > > at sector scope (since failing to do so can lead to attacks).
> >
> > response:
> >
> > It is; fixed since https://github.com/core-wg/resource-directory/pull/296.
> >
> > >    Endpoint authentication needs to be checked independently of whether
> > >    there are configured requirements on the credentials for a given
> > >    endpoint name (Section 7.1) or whether arbitrary names are accepted
> > >    (Section 7.1.1).
> > >
> > > I think this is more properly authorization than authentication.
> >
> > response:
> >
> > Yes; fixed in https://github.com/core-wg/resource-directory/pull/271.
> >
> > > Section 8.3
> > >
> > >    attacks.  There is also a danger that NTP Servers could become
> > >    implicated in denial-of-service (DoS) attacks since they run on
> > >    unprotected UDP, there is no return routability check, and they can
> > >    have a large amplification factor.  The responses from the NTP server
> > >    were found to be 19 times larger than the request.  An RD which
> > >
> > > (It's not clear to me why the specific discussion of NTP numbers is
> > > relevant here, since RD is not NTP.)
> >
> > response:
> >
> > The section has been shortened in
> > https://github.com/core-wg/resource-directory/pull/249.
> >
> > > Section 9.3
> > >
> > > Should we also include "rt" in the initial entries?  I see it is used as
> > > a query parameter for resource lookup in the examples in Section 6.3.
> >
> > response:
> >
> > It's used as is any other link attribute. There's no registry for them, and
> > while there's been talk over ond over that it would be nice, I don't think
> > there will be any until linkformat-CoRAL conversion is defined (and even then
> > it may not be comprehensive). Selectively picking some distinguished common
> > link attributes into this registry won't make things less messy.
> >
> > The prime line of defense against this getting messy is the expert guidance
> > that for some types of parameters their short names should be checked against
> > "commonly used target attributes".
> >
> >
> > >    *  indication of whether it can be passed as a query parameter at
> > >       registration of endpoints, as a query parameter in lookups, or be
> > >       expressed as a target attribute,
> > >
> > > (Since this text does not clarify about lookup of endpoints vs.
> > > resources...
> > >
> > >    Review" as described in [RFC8126].  The evaluation should consider
> > >    formal criteria, duplication of functionality (Is the new entry
> > >    redundant with an existing one?), topical suitability (E.g. is the
> > >    described property actually a property of the endpoint and not a
> > >    property of a particular resource, in which case it should go into
> > >    the payload of the registration and need not be registered?), and the
> > >
> > > ... and this text suggests that query parameters for *resource* lookups
> > > need not be registered.)
> > >
> > >    potential for conflict with commonly used target attributes (For
> > >    example, "if" could be used as a parameter for conditional
> > >    registration if it were not to be used in lookup or attributes, but
> > >    would make a bad parameter for lookup, because a resource lookup with
> > >    an "if" query parameter could ambiguously filter by the registered
> > >    endpoint property or the [RFC6690] target attribute).
> > >
> > > Then why do we use it as an example of lookup filtering in Section 6.2?
> >
> > response:
> >
> > The text suggests that target attributes for registered resources need not be
> > registered. These unregistered wild-west attribute names can be used both with
> > resource lookups (matching only resources which), and in endpoint lookups
> > (matching endpoints that contain any resource which).
> >
> > If `if` were to be put in for use in an RD parameter used with lookup, that
> > would not per se create ambiguous queries (the rules would still say "matches
> > either"), but the results would be prone to causing confusion.
> >
> > > Section 10.1.2
> > >
> > > Should we really be using unregistered resource types (i.e., codepoint
> > > squatting) in the examples?
> >
> > response:
> >
> > Addressed together with the earlier code squatting comments in
> > https://github.com/core-wg/resource-directory/pull/266.
> >
> > >    After the filling of the RD by the CT, the application in the
> > >    luminaries can learn to which groups they belong, and enable their
> > >    interface for the multicast address.
> > >
> > > Just to check: the luminaries are learning their own group membership by
> > > querying the resource directory?
> >
> > response:
> >
> > Not directly. They (in this very particular example that seems to be based on
> > industry process but which I'd not necessarily recommend for imitation) use a
> > heuristic to find any multicast URI they might possibly provide, and join that
> > group.
> >
> > > Section 10.2.2
> > >
> > > Please expand MSISDN.
> >
> > response:
> >
> > Taking a step back from this and other comments led to a drastical shortening
> > of the example.
> >
> > See also GENERIC-ODDEXAMPLES
> >
> > > Section 13.2
> > >
> > > I think RFC 7252 should probably be normative.
> > >
> > > Likewise for RFC 8288 ("the query parameter MUST be [...] a token as
> > > used in [RFC8288]").
> >
> > response:
> >
> > RFC7252 (CoAP) and RFC7230 (HTTP) were promoted to a normative reference.
> > (RFC7641 (CoAP observe) wasc left as informative because while they are
> > optional components, RD is not so much specified using them but more happens to
> > combine with them).
> >
> > RFC8288 was also promoted, but not due to the quoted line (that's not
> > implementation relevant but merely setting out rules for the registry
> > operation), but because we explicitly pull it in in terminology and the
> > information model.
> >
> > (Changes in https://github.com/core-wg/resource-directory/pull/307).