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

From: Michel Veillette <[email-masked]>
Date: Mon, 7 Mar 2016 14:42:08 +0000

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

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?
- should PATCH be replaced by "iPATCH"

More globally, do we really need two methods "PATCH" and "iPATCH"?
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}
  ]

Regards,
Michel Veillette

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: March-07-16 3:37 AM
To: Core <[email-masked]>
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: [email-masked]
Ontvanger: "Peter van der Stok" <[email-masked]>, "Peter Van der Stok" <[email-masked]>, "Andy Bierman" 
<[email-masked]>

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 [email-masked].

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
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: peter van der Stok <[email-masked]>
Date: Tue, 08 Mar 2016 09:16:38 +0100

Hi Michel

see below.

> pvds> will try </pvds>

<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>

> "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>
> - All yang hash text has been removed and the draft refers to
> bierman-core-yang-hash draft. draft refers to managed numbering.
> Ontvanger: "Peter van der Stok" <[email-masked]>, "Peter
> Van der Stok" <[email-masked]>, "Andy Bierman"
> <[email-masked]>
> 
> 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.
> 
> 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: Michel Veillette <[email-masked]>
Date: Tue, 8 Mar 2016 19:38:06 +0000

Hi Peter.

About "don't think so, why?"

An update operation is not always idempotent.
For both  examples, don't we have the following behaviour?
  f(f("x-coord": 256) = f("x-coord": 256) = "x-coord": 45

First example:
  PATCH CoAP://www.example.com/object Content-Type: application/json-patch+json
  [ { "op":"replace","path":"x-coord","value":45} ]

Second example:
  PATCH CoAP://www.example.com/object Content-Type: application/merge-patch+json
  {  "x-coord" : 45 }

So, should we replace the PATCH by an iPATCH?
I just trying to understand how this work.

Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: March-08-16 3:17 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: RE: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt

Hi Michel

see below.

> - should "Content-Type" be replaced by "Content-Format" since it's a 

<pvds>
good remark, In the coap RFC content-Type is used a few times, and content-format mostly.
I will change
</pvds>
<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?
<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>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 09 Mar 2016 09:03:01 +0100

Hi Michel,

see below

>   f(f("x-coord": 256) = f("x-coord": 256) = "x-coord": 45

and if I understand your notation:
f(f("x-coord": 45) = f("x-coord": 45) = "x-coord": 45

showing that the replace op is idem-potent. Independent of the number of 
times that you execute it, the results is the same.
> I just trying to understand how this work.

PATCH invocation do not need to be idem-potent but are allowed to be 
idem-potent.
So both iPATCH and PATCH would be correct here.

Do you have suggestions for clarifications?
Do you think a non-idempotent example would help?

---

From: Michel Veillette <[email-masked]>
Date: Wed, 9 Mar 2016 14:43:58 +0000

Hi Peter

You seem to agree that the replace operation uses in the two examples is idempotent.
"showing that the replace op is idem-potent"
" Do you think a non-idempotent example would help?"

In this case, why these examples use PATCH instead of iPATCH?

I'm still confuse about this notion of PATCH vs. iPATCH.
Regards,

Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: March-09-16 3:03 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: RE: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt

Hi Michel,

see below

showing that the replace op is idem-potent. Independent of the number of times that you execute it, the results is the same.
> I just trying to understand how this work.

PATCH invocation do not need to be idem-potent but are allowed to be idem-potent.
So both iPATCH and PATCH would be correct here.

>> https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-ma
>> p
>> ping-latest.html
> 
>> pvds> will try </pvds>
>>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 09 Mar 2016 16:26:56 +0100

I think the point is you can always use PATCH.
Using iPATCH is a courtesy to the server, *if* the request is indeed
idempotent.  The "i" is just a bit that you can set, everything else
stays the same.

Grüße, Carsten

---

From: Michel Veillette <[email-masked]>
Date: Wed, 9 Mar 2016 15:49:31 +0000

Thanks for the answer Carsten.

Idempotent is an important concept to consider when designing a protocol.
However, I don't things this semantic attribute justify a different CoAP method.
Supporting both PATCH and iPATCH can also lead to some confusion.

Just sharing my opinion, I'm not trying to impose a solution.

Regards

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: March-09-16 10:27 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt

I think the point is you can always use PATCH.
Using iPATCH is a courtesy to the server, *if* the request is indeed idempotent.  The "i" is just a bit that you can set, everything else stays the same.

Grüße, Carsten