IETF Logo Mail Archive

Re: [core] Questions/comments on draft-ietf-core-dynlink-02

Christian Groves <cngroves.std@gmail.com> Mon, 13 March 2017 06:19 UTC

Return-Path: <cngroves.std@gmail.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 249A5128B37 for <core@ietfa.amsl.com>; Sun, 12 Mar 2017 23:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.332
X-Spam-Level:
X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 MLWEMPDtCaE5 for <core@ietfa.amsl.com>; Sun, 12 Mar 2017 23:19:00 -0700 (PDT)
Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF1C12953C for <core@ietf.org>; Sun, 12 Mar 2017 23:19:00 -0700 (PDT)
Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:61483 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from <cngroves.std@gmail.com>) id 1cnJJp-000pIN-Dl for core@ietf.org; Mon, 13 Mar 2017 17:18:57 +1100
To: core@ietf.org
References: <zarafa.58c28563.565a.4a1c907d21bf17bc@za.u-blox.com> <9966516C6EB5FC4381E05BF80AA55F77012A8AA931@US70UWXCHMBA05.zam.alcatel-lucent.com>
From: Christian Groves <cngroves.std@gmail.com>
Message-ID: <423e74ab-df2e-e11d-2525-346caee86bc1@gmail.com>
Date: Mon, 13 Mar 2017 17:18:55 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A8AA931@US70UWXCHMBA05.zam.alcatel-lucent.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - msh04.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - gmail.com
X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au
X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/-lANdv--3SeCGod392EN2bxVjIc>
Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Mar 2017 06:19:02 -0000

Hello Mojan and Tim,

For the attribute renaming there was already discussion on the list 
about it and it seemed there was agreement to change the dynlink 
parameter and not the RD parameter. Usage by other SDOs was raised. My 
plan is to raise this issue in the upcoming Chicago meeting to see if we 
can get it resolved there.

Thanks for pointing out the error in the examples. I'll fix it in the 
next version.

Regards, Christian


On 11/03/2017 7:12 AM, Carey, Timothy (Nokia - US) wrote:
> Mojan,
>
> I certainly agree - we should be careful about renaming these attributes; the attributes have been around for a while and are used by OMA for sure.
>
> Yes you are indeed correct the examples do not align with normative language of section 4.2 - this again can cause problems in other SDOs.
>
> BR,
> Tim
>
> -----Original Message-----
> From: Mojan Mohajer [mailto:mojan.mohajer@u-blox.com]
> Sent: Friday, March 10, 2017 4:52 AM
> To: core <core@ietf.org>
> Subject: [core] Questions/comments on draft-ietf-core-dynlink-02
>
> 1)The latest draft has renamed "gt" and "lt" attributes to "gth" and "lth" respectively. Has any consideration been given to the impact of this name change on other SDOs and their specifications where CoAP and these attributes are used. For example, OMA LwM2M v1.0 which has recently been formally released uses CoAP as its application layer protocol and these attributes for notification purposes.
>
> 2) Section 4.2 which covers resource observation attributes (pmin, pmax, st, ...) states that that: ..."These query parameters MUST be treated as resources that are read using GET and updated using PUT, and MUST NOT be included in the Observe request" ....
> However, looking at newly added Annex A which provides observation examples, these observation attributes are passed as query parameters of a Get request with Observe option set to 0. There seems to be some contradiction between the text in section 4.2 and the example in Annex A.
>
> Best Regards,
> Mojan
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

v2.23.0 | Report a Bug | By Email