Subject: [Dots] Data Channel POST challenges

From: "Jon Shallow" <[email-masked]>
Date: Thu, 4 Jan 2018 14:01:59 -0000

Hi there,

With the merge of aliases and filters into a common YANG data model, I think
the POST examples are now incorrect in the data channel draft, but still am
challenged as to what to actually use.  My understanding is below, but open
to correction.

[I also think identifier should be renamed to something like aliases to be
more meaningful - to contrast access-lists]

E.g. 6.1. Create Identifiers

    POST /restconf/data/ietf-dots-data-channel HTTP/1.1

    Host: {host}:{port}

    Content-Type: application/yang-data+json

    {

     "ietf-dots-data-channel:identifier": {

       "client-identifier": [

            "string"

       ],

       "alias": [

         {

           "alias-name": "string",

Should read [RFC8040 4.4.1. Create Resource Mode] as we are defining where
we want to put the resource

    POST /restconf/data HTTP/1.1

    Host: {host}:{port}

    Content-Type: application/yang-data+json

    {

     "ietf-dots-data-channel:identifier": {

       "client-identifier": [

            "string"

       ],

       "alias": [

         {

           "alias-name": "string",

And the returned Location: header would contain
"https://{host}:{port}/restconf/data/ietf-dots-data-channel:identifier"

NOTE:  [RFC8040 4.4.1. Create Resource Mode] "If the data resource already
exists, then the POST request MUST fail

   and a "409 Conflict" status-line MUST be returned."

This means to me that we can only create one alias set using POST when the
resource is /restconf/data, and if we want to update the alias set at
/restconf/data, we must do a DELETE followed by another POST, or use PUT. 

The PUT equivalent would be (I think) for creating or completing replacing
the complete list of aliases [RFC8040 4.5. PUT]

    PUT /restconf/data HTTP/1.1

    Host: {host}:{port}

    Content-Type: application/yang-data+json

    {

     "ietf-dots-data-channel:identifier": {

       "client-identifier": [

            "string"

       ],

       "alias": [

         {

           "alias-name": "string",

Or to create / update a new alias-name (but what happens to
client-identifier ?  I think it is put in the path) - "string" in the URI
will contain the actual value without quotes

    POST
/restconf/data/ietf-dots-data-channel:identifier/client-identifier="string"
HTTP/1.1

    Host: {host}:{port}

    Content-Type: application/yang-data+json

    {

       "ietf-dots-data-channel:alias": [

         {

           "alias-name": "string",

Or ("string" replaced in URI as appropriate)

    PUT
/restconf/data/ietf-dots-data-channel:identifier/client-identifier="string"/
alias="string" HTTP/1.1

    Host: {host}:{port}

    Content-Type: application/yang-data+json

    {

       "ietf-dots-data-channel:alias": [

         {

           "alias-name": "string",

The same thing is needed for the access-lists, but also need to consider
"insert" and "point".

Comments / help needed!

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 4 Jan 2018 15:20:05 +0000

Hi Jon,

Please see inline

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Thursday, January 4, 2018 7:32 PM
To: [email-masked]
Subject: [Dots] Data Channel POST challenges

Hi there,

With the merge of aliases and filters into a common YANG data model, I think the POST examples are now incorrect in the data channel draft, but still am challenged as to what to actually use.  My understanding is below, but open to correction.

[I also think identifier should be renamed to something like aliases to be more meaningful - to contrast access-lists]

Should read [RFC8040 4.4.1. Create Resource Mode] as we are defining where we want to put the resource

And the returned Location: header would contain "https://{host}:{port}/restconf/data/ietf-dots-data-channel:identifier<https://%7bhost%7d:%7bport%7d/restconf/data/ietf-dots-data-channel:identifier>"

[TR] The above examples you provided do not look correct, please see https://tools.ietf.org/html/rfc8040#appendix-B.2.1

-Tiru

NOTE:  [RFC8040 4.4.1. Create Resource Mode] "If the data resource already exists, then the POST request MUST fail
   and a "409 Conflict" status-line MUST be returned."

This means to me that we can only create one alias set using POST when the resource is /restconf/data, and if we want to update the alias set at /restconf/data, we must do a DELETE followed by another POST, or use PUT.

The PUT equivalent would be (I think) for creating or completing replacing the complete list of aliases [RFC8040 4.5. PUT]

Or to create / update a new alias-name (but what happens to client-identifier ?  I think it is put in the path) - "string" in the URI will contain the actual value without quotes

    POST /restconf/data/ietf-dots-data-channel:identifier/client-identifier="string" HTTP/1.1
    Host: {host}:{port}
    Content-Type: application/yang-data+json
    {
       "ietf-dots-data-channel:alias": [
         {
           "alias-name": "string",

    PUT /restconf/data/ietf-dots-data-channel:identifier/client-identifier="string"/alias="string" HTTP/1.1
    Host: {host}:{port}
    Content-Type: application/yang-data+json
    {
       "ietf-dots-data-channel:alias": [
         {
           "alias-name": "string",

The same thing is needed for the access-lists, but also need to consider "insert" and "point".

Comments / help needed!

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 4 Jan 2018 15:36:24 -0000

Hi Tiru,

See inline

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 04 January 2018 15:20
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Data Channel POST challenges

Hi Jon,

Please see inline 

Hi there,

    Host: {host}:{port}

    {

       "client-identifier": [

            "string"

       ],

       "alias": [

         {

           "alias-name": "string",

    Host: {host}:{port}

    {

       "client-identifier": [

            "string"

       ],

       "alias": [

         {

           "alias-name": "string",

And the returned Location: header would contain
"https://{host}:{port}/restconf/data/ietf-dots-data-channel:identifier
<https://%7bhost%7d:%7bport%7d/restconf/data/ietf-dots-data-channel:identifi
er> "

[TR] The above examples you provided do not look correct, please see
https://tools.ietf.org/html/rfc8040#appendix-B.2.1

[Jon] The above example is for the complete replacement of the data
container (B.2.4), or first addition of an entry (POST 4.4.1) (i.e. working
with a datastore resource) that defines everything, the below last 2
examples are in-line with B.2.1 (creating a data resource within a data
resource) as I read the RFC.

-Tiru

    Host: {host}:{port}

    {

       "client-identifier": [

            "string"

       ],

       "alias": [

         {

           "alias-name": "string",

    POST

    Host: {host}:{port}

    {

         {

           "alias-name": "string",

    PUT

    Host: {host}:{port}

    {

         {

           "alias-name": "string",

Comments / help needed!

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 5 Jan 2018 11:57:53 +0000

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Thursday, January 4, 2018 9:06 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Data Channel POST challenges

Hi Tiru,

See inline

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 January 2018 15:20
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data Channel POST challenges

Hi Jon,

Please see inline

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Thursday, January 4, 2018 7:32 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Data Channel POST challenges

Hi there,

[Jon] The above example is for the complete replacement of the data container (B.2.4), or first addition of an entry (POST 4.4.1) (i.e. working with a datastore resource) that defines everything, the below last 2 examples are in-line with B.2.1 (creating a data resource within a data resource) as I read the RFC.

[TR2] I meant if the above example is only supposed to create a new "identifier" resource then the request body should not carry client-identifier and alias parameters (just like the "jukebox" example given in Section 4.4.1).

-Tiru

Comments / help needed!

Regards

Jon