Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-05.txt

From: peter van der Stok <[email-masked]>
Date: Tue, 28 Oct 2014 13:19:16 +0100

Dear CoRE WG,

We have submitted a new CoAP Management Interface (CoMI) draft to the 
WG.
Contrary to the former versions, this draft version focusses on YANG 
modules.
Further the draft minimizes the payload by using CBOR and hashing name 
strings.

We are looking forward to hear your opinion on this new approach.
We should also like to hear if you think this work should be done in the 
context of the CoRE wg.

Peter

-------- Oorspronkelijke bericht --------
Onderwerp: New Version Notification for 
draft-vanderstok-core-comi-05.txt
Datum: 2014-10-28 01:25
Afzender: [email-masked]
Ontvanger: Anuj Sehgal <[email-masked]>, "Anuj Sehgal" 
<[email-masked]>, "Juergen Schoenwaelder" 
<[email-masked]>, Juergen Schoenwaelder 
<[email-masked]>, "Peter Van der Stok" 
<[email-masked]>, Peter van der Stok 
<[email-masked]>, Bert Greevenbosch 
<[email-masked]>, "Bert Greevenbosch" 
<[email-masked]>, Andy Bierman <[email-masked]>, "Andy 
Bierman" <[email-masked]>

A new version of I-D, draft-vanderstok-core-comi-05.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Name:		draft-vanderstok-core-comi
Revision:	05
Title:		CoAP Management Interface
Document date:	2014-10-27
Group:		Individual Submission
Pages:		37
URL:            
http://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-05.txt
Status:         
https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/
Htmlized:       http://tools.ietf.org/html/draft-vanderstok-core-comi-05
Diff:           
http://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-05

Abstract:
    This document describes a network management interface for
    constrained devices, called CoMI.  CoMI is an adaptation of the
    RESTCONF protocol for use in constrained devices and networks.  It is
    designed to reduce the message sizes, server code size, and
    application development complexity.  The Constrained Application
    Protocol (CoAP) is used to access management data resources specified
    in YANG, or SMIv2 converted to YANG.  The payload of the CoMI message
    is encoded in Concise Binary Object Representation (CBOR).

Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 Oct 2014 14:09:21 +0100

Nice!

Some minor comments on the CBOR mappings of the data types:

I don’t know how much decimal64 is being used in YANG modules today, but CBOR actually has Tag 4 mirroring that: See section 2.4.3 of RFC 7049.  Of course, you can factor out the fraction-digits and get it from the schema, in that case just sending the mantissa makes sense.

Re smiv2:oid you maybe want to have a look at draft-bormann-cbor-tags-oid — that may be a closer fit.

                        oOo

More importantly, I’m trying to wrap my mind around the hashing concept.  Interesting.  Is that maybe something that should be extracted and made available for a more general use?  (Maybe not now.)

Is the shape of the identifier space stable enough that a client can read /mg/yang-hash once and then be done with it?  Or do you need to observe that resource?

(Nit: I would probably use more than 4 bits per byte in the URIs.)

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Oct 2014 12:50:46 -0700

> Is the shape of the identifier space stable enough that a client can read /mg/yang-hash once and then be done with it?  Or do you need to observe that resource?

It is expected that the hashes and the contents of this table will be
known at boot-time
(maybe even compile-time) for constrained devices.  However, a client that polls
a server periodically cannot really tell the difference between a new module
loaded at runtime or the server rebooting with a new image that has a
new module.
Both events are expected to be very rare, but possible.

> (Nit: I would probably use more than 4 bits per byte in the URIs.)

OK

> Grüße, Carsten

Andy

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core