Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT)

From: Christian Amsüss <[email-masked]>
Date: Sun, 7 Mar 2021 18:00:43 +0100

Hello Ben, Carsten,

On Sat, Feb 27, 2021 at 01:37:59PM -0800, Benjamin Kaduk wrote:
> On Sat, Feb 27, 2021 at 10:01:35PM +0100, Carsten Bormann wrote:
> > > use "authoritative" instead of
> > > "authorized" in the couple places I indicated
> > 
> > Authoritative sounds like it is an intrinsic property of the source.
> > Authorized means that the specific policies that apply to the consumer authorize use of the source for the purpose at hand.
> > So I think this substitution should not occur lightly.
> 
> When the data in question is "what resources are available at this host", I
> think authoritative is pretty intrinsically a property of the host itself :)
> 
> Now, if the question was "what resources are supposed to be at this host
> that I'm allowed to use?", your considerations become quite relevant.

After several attempts to phrase the text to reflect that sentiment, I
am now of the opinion that that getting this picture over in a fashion
that is both comprehensible and correct takes more explanation than is
helpful for understanding RD at large.

Distinguishing between what a requires authorization and what is
authoritative information implies making a call on what is factual
information and what is an assertion on a resource, and these depend on
the semantics of the individual attributes which can not be done
universally:

* A statement on a resoure like the attribute <...>;trustworthy=yes is
  an assertion on which the ultimate authority is with the entity defining
  the security policies. 

* An attribute like <...>;rt="...:firmware" is factual in a sense (after
  all, what a malicious party hosts there is *some* firmware) but also
  the prime example of something that needs additional authorization to
  state.

* A statement like the plain "</res/fw>" is factual and can thus
  authoritatively be claimed by the endpoint. Still, some applications
  (not those we define because we adhere to BCP190) may ascribe
  semantics to it that need more authorization than just relaying a
  factual statement.

Pitting all those on the term "authorized" is admittedly pulling in
aspects of authority, but plucking them apart would help neither the
casual nor the careful reader.

Hoping that this contributes to your satisfaction with the
now-to-be-submitted -28
BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 7 Mar 2021 18:05:16 +0100

On 2021-03-07, at 18:00, Christian Amsüss <[email-masked]> wrote:
> 
> Pitting all those on the term “authorized” 

There is no spoon, only ever assertions about it, so I agree with this approach.

(The trick is to find out which assertions a party believes are authoritative/authorized, but this is indeed out of scope for this document.)

Grüße, Carsten

---

From: Christian M. Amsüss <[email-masked]>
Date: Sun, 7 Mar 2021 18:52:09 +0100

Hello Barry, hello authors,

On Fri, Feb 26, 2021 at 10:45:19AM -0500, Barry Leiba wrote:
> Let's just wait until you post a revision, so it's easier on the RFC
> Editor.  It won't make very much difference in publication time.
> 
> Please post as soon as the tool opens again, and I'll make sure I
> process it before I officially leave the AD role.

The -28 version contains fixes for the remaining points of Ben's review
as well as an additional capitalization fix. The latest thread does
contain some remarks he made that did not result in a text alteration,
but I think were adaequately responded to.

For as far as I am concerned, this is good to proceed.

Best regards
Christian

---

   changes from -27 to -28

   *  Security policies / link confidentiality: Point out the RD's
      obligations that follow from such a policy.

   *  Simple registration: clarify term "regular registration" by
      introducing it along with the reference to Section 5

   *  Wording fix in first-come-first-remembered

   *  Wording fixes in RD definition

   *  Capitalization: Consistently using "registration resource"