Subject: [core] FW: Review draft-tiloca-core-oscore-discovery-04

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Nov 2019 15:03:23 +0800

Need to go here as well.

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Wednesday, November 20, 2019 3:03 PM
To: [email-masked]'
<[email-masked]>
Subject: Review draft-tiloca-core-oscore-discovery-04

* Should this document be re-written to only use CoRAL-reef?

* Introduction - You have the statement that generally one application group
uses one OSCORE group.  I don't know that I agree with this statement.  It
depends to a large extent of how you define an application group.  For
example, if you are looking at both administration and usage as being in the
same App group then this is not a true statement.

* Section 2 - If you want ACE-KEY-GROUPCOMM-OSCORE to be an information
reference, then the definition for 'name' needs to be changed.

* Section 2 - Just replace and use the correct terms for countersignature
algorithm info and countersignature key info structures.

* Section 3 - For 'app-gp' - the MAY is confusing to me.  Better to say MUST
occur once for each application group and MUST contain only a single
application group.  

* Section 5 - I don't care if you specify the same application group
multiple times.   I don't want to have to figure out how to check this one
thing and error.  Plus the end result will always be the same anyway

* Section 5.1 - I think the anchor in the response is supposed to be absent.

* Section 6 - It looks like you are registering [2001:db8:4::4] twice - that
looks like it will mess things up.

* Section 6 - I am not sure why you are registering the app-grp on the
individual device rather than on the group itself.  That means that If I go
in reverse, from the app group to the address of the app group, then I get
the individual endpoints rather than the group multicast address.  This
might be done for somebody who wants to get the messages in the group and
would be permitted to do so.

---

From: Christian M. Amsüss <[email-masked]>
Date: Wed, 20 Nov 2019 11:07:34 +0100

Hello Jim,

> Need to go here as well.
This too.

> * Should this document be re-written to only use CoRAL-reef?

I don't think so in general for time line reasons. (There's no concrete
pressure on this as far as I know of, but CoRAL still has no forseeable
timeline).

What I could see us do is having both in examples, and possibly even
accept that some features are not as optimized or usable in link-format
but can be in CoRAL. (The link from the join resource to the
authorization server, on which there was the comment today from
proxy-Klaus, comes to mind.)

> thing and error.  Plus the end result will always be the same anyway

Considering the paragraph below that, the app-gp paragraph can be vastly
simplified anyway, and I think we already have an item about making this
less normative. (The link's content is normative; how it's looked up in
an RD is just a description of the combined steps).

> * Section 5.1 - I think the anchor in the response is supposed to be absent.

The anchor needs to be there because it's an RD lookup result, and the
RD needs to fill in the anchor because it could be relevant for
interpreting the implied "hosts" relation or any non-target link
attributes (which I usually claim should not be registered, but that's
what we arrived at RD for 6690 compatibility).

Thanks for your input
c

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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 21 Nov 2019 04:19:05 +0800

-----Original Message-----
From: core <[email-masked]> On Behalf Of Christian M. Amsüss
Sent: Wednesday, November 20, 2019 6:08 PM
To: [email-masked]
Subject: Re: [core] Review draft-tiloca-core-oscore-discovery-04

Hello Jim,

This too.

[JLS] It is not clear to me that there is a timeline for this document as
well.

What I could see us do is having both in examples, and possibly even accept
that some features are not as optimized or usable in link-format but can be
in CoRAL. (The link from the join resource to the authorization server, on
which there was the comment today from proxy-Klaus, comes to mind.)

[JLS] That would be helpful

Considering the paragraph below that, the app-gp paragraph can be vastly
simplified anyway, and I think we already have an item about making this
less normative. (The link's content is normative; how it's looked up in an
RD is just a description of the combined steps).

> * Section 5.1 - I think the anchor in the response is supposed to be
absent.

The anchor needs to be there because it's an RD lookup result, and the RD
needs to fill in the anchor because it could be relevant for interpreting
the implied "hosts" relation or any non-target link attributes (which I
usually claim should not be registered, but that's what we arrived at RD for
6690 compatibility).

[JLS] Rats - I guess I need to go back and read the RD draft again.  The
last thing that I remember was that everything came back as fully resolved
and thus anchor did not mean anything.

Jim

Thanks for your input
c

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