Re: [core] draft-ietf-core-resource-directory

Jim Schaad <ietf@augustcellars.com> Mon, 27 August 2018 16:15 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F1D130E1B; Mon, 27 Aug 2018 09:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR9GocSJ50Wp; Mon, 27 Aug 2018 09:15:31 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3765130E07; Mon, 27 Aug 2018 09:15:30 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 27 Aug 2018 09:11:35 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: consultancy@vanderstok.org
CC: draft-ietf-core-resource-directory@ietf.org, 'core' <core@ietf.org>
References: <029201d43d7a$abf06570$03d13050$@augustcellars.com> <7f97db3d249e03198fd1f5ba10cc3172@bbhmail.nl>
In-Reply-To: <7f97db3d249e03198fd1f5ba10cc3172@bbhmail.nl>
Date: Mon, 27 Aug 2018 09:15:20 -0700
Message-ID: <02ee01d43e21$288ab990$79a02cb0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EF_01D43DE6.7C2D4120"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ4NpOH1XjUYSWbdZYso4m4X/addACuELvvo4ZcqrA=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/6yIFWJ7Cvq7-Z0jYDEOMhJym0zE>
Subject: Re: [core] draft-ietf-core-resource-directory
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2018 16:15:34 -0000

 

 

From: Peter van der Stok <stokcons@bbhmail.nl> 
Sent: Monday, August 27, 2018 12:57 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-core-resource-directory@ietf.org; 'core' <core@ietf.org>
Subject: Re: [core] draft-ietf-core-resource-directory

 

Hi JIm,

thanks for the questions.
some quick reactions to some of your comments

Jim Schaad schreef op 2018-08-26 22:23:

* The term registree-ep is in the document.  This is not a word that I can
find.  I think what you want to say is registrant-ep.

An endpoint can be both a registrant-ep and a being-registered-ep;
With RD an endpoint can only be a being-registered-ep
I thought that being-registered-ep <=> registree-ep
Looked it in vain up in dictionary; What is the correct term here?

 

[JLS]  Registrant refers to “One that registers or is registered” This is the closest work I know to that would reference to an entity currently being registered.  I would probably use registrant if I thought about it.



* Section 5.3 - there is a statement that the endpoint name must be unique
within a sector.  I cannot think of any way that this can be enforced by an
RD.  

Suppose there are registration with the same sector and endpoint name, How do you distinguish them?
In 5.3 the registration procedure to create unique (endpoint name, sector) pairs is described.
Why can this not be enforced? The RD can check all pairs before going to the act of registering.

 

[JLS] The text also says that if a get a new registration request with a sector and endpoint name, that the RD is supposed to replace the current existing registration.  My code can validate that the registrar is permitted to do the registration, but not that the ep/d pair are unique and refer to the same entity.



* Section 6.1 - I am trying to decide if there should be a sentence that
says that only the href is allowed in the body.  Any other properties are
either ignored or an error.

only hrefs of registration resource; I am undecided on this; what about ct unequal 40

 

[JLS] My original thought was that it should be only a list of hrefs, but that is not explicitly stated.  Then I thought that it might be useful to potentially add some of the DNS type properties to a group list such as “priority” to indicate which servers in a group would be preferred over others.



* Section 5.3 - Is it a bad request if there is a 'base' in the content?

Can you explain?
I suspect in the payload things like:
</sensors/temp>;base=my-ip

 

[JLS] Yes that is the type of thing that I had in mind.  The issue is that while the base as a uri-query applies to the whole group this would apply to only the one line.  It would make more sense to require that it be registered as

 

<coap://my-ip/sensors/temp>;ct=40



* Section 5.3 - We seem to have lost the following operations.  Is this
intentional?  Cannot do a get, post or delete to an endpoint.  I probably
only care about the last as the other two are doable in other ways.

May be you want to look at appendix A? management of registrations has been placed in the appendix.



[JLS} I totally missed that – I never read appendixes as a general rule.  They are appendixes and thus are designed to be ignored.  “Appendix – supplementary material usually attached at the end of a piece of writing”.  This does not sound very supplementary to me.


*  I cannot figure out where the base that is assigned in a group would be
used.  For group lookup it would not make any sense as you are returning
endpoints on the RD.  For endpoint lookup again we return pointers to the
RD.  For resource lookups I would expect it to return everything relative to
the base of the endpoint.  It would appear that there is no longer a GET on
/rd/groups 

Appendix A.5 might be useful.

 

[JLS] See above answer.  I was really kind of expecting to be able to do a query along the lines of “Return the resources in a group” and get back something along the lines of the list of resources resolved against the base address of the group if one exists and against the base address of the endpoint if it does not.  Current resource lookups always resolve against the endpoint.



Jim

I am afraid the separation of management to the appendix A has provoked many of your questions.
W thought that separating management from registration and lookup would clarify the differences between registration resources and registered resources.

 

[JLS] I don’t object to the separating of these concepts.  I object to them being in an appendix.  I can now go back and continue making sure my implementation is correct according to the spec.

 

Jim

 



Peter
_______________________________________________
core mailing list
core@ietf.org <mailto:core@ietf.org> 
https://www.ietf.org/mailman/listinfo/core