Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt

Hi Michel

see below.

Michel Veillette schreef op 2016-03-07 15:42:
> Hi Peter
> 
> We are correctly in final review process of the mapping draft prior 
> publishing.
> The current version is available at:
> https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-mapping-latest.html

> pvds> will try </pvds>
> 
> If possible, send me your comments before Wednesday to give us some
> time to apply them.
> 
> About "draft-vanderstok-core-patch-02", in the examples:
> - should "Content-Type" be replaced by "Content-Format" since it's a
> CoAP request?

<pvds>
good remark, In the coap RFC content-Type is used a few times, and 
content-format mostly.
I will change
</pvds>
> - should PATCH be replaced by "iPATCH"
<pvds>
don't think so, why?
</pvds>
> 
> More globally, do we really need two methods "PATCH" and "iPATCH"?
<pvds>
people like idem-potent as explained in earlier e_mail by Carsten
other people prefer more freedom by removing idem-potency restriction.
Both camps have valid arguments.
</pvds>

> If both methods are supported, should the client select to proper
> method per request or just
> on the potential for a method to sometime create non-idempotent 
> requests?
> For example, should the client use iPATCH for a "replace" and PATCH
> for a "insert-after"?
> 
>   iPATCH CoAP://www.example.com/object
>         Content-Type: application/json-patch+json
>   [
>     { "op":"replace","path":"/x-coord","value":45}
>   ]
> 
>   PATCH CoAP://www.example.com/object
>         Content-Type: application/json-patch+json
>   [
>     { "op":"insert-after", "insertion-point" : "/y-coord",
> "path":"/z-coord","value":45}
>   ]
<pvds>
My opinion:
Both iPATCH and Patch can be invoked.
When the content suggests a non-idem-potent update (like add an item to 
an array)
- the Patch should execute the update
- and iPatch should return an error and do nothing (atomicity)
</pvds>
> 
> Regards,
> Michel Veillette
> 
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der 
> Stok
> Sent: March-07-16 3:37 AM
> To: Core <core@ietf.org>
> Subject: [core] Fwd: New Version Notification for
> draft-vanderstok-core-comi-09.txt
> 
> Dear all,
> 
> a New version of the comi draft has been submitted.
> 
> - All yang hash text has been removed and the draft refers to
> bierman-core-yang-hash draft. draft refers to managed numbering.
> - All YANG to CBOR mapping has been removed, the draft waits for the
> publication of the yang-cbor draft
> - the draft lists all differences with restconf
> - rpc has been added.
> - and several other editorials.
> 
> Peter
> 
> -------- Oorspronkelijke bericht --------
> Onderwerp: New Version Notification for 
> draft-vanderstok-core-comi-09.txt
> Datum: 2016-03-07 09:30
> Afzender: internet-drafts@ietf.org
> Ontvanger: "Peter van der Stok" <consultancy@vanderstok.org>, "Peter
> Van der Stok" <consultancy@vanderstok.org>, "Andy Bierman"
> <andy@yumaworks.com>
> 
> A new version of I-D, draft-vanderstok-core-comi-09.txt has been
> successfully submitted by Peter van der Stok and posted to the IETF
> repository.
> 
> Name:		draft-vanderstok-core-comi
> Revision:	09
> Title:		CoAP Management Interface
> Document date:	2016-03-07
> Group:		Individual Submission
> Pages:		48
> URL:
> https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-09.txt
> Status:
> https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/
> Htmlized:
> https://tools.ietf.org/html/draft-vanderstok-core-comi-09
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-09
> 
> 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.  The
>     Constrained Application Protocol (CoAP) is used to access 
> management
>     data resources specified in YANG, or SMIv2 converted to YANG.  CoMI
>     use the YANG to CBOR mapping and encodes YANG names to reduce 
> payload
>     size.
> 
> Note
> 
>     Discussion and suggestions for improvement are requested, and 
> should
>     be sent to core@ietf.org.
> 
> 
> 
> 
> 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
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core