Subject: Re: [lmap] New Version Notification for draft-liu-lmap-rest-03.txt

From: "Vic Liu(CMCC)" <[email-masked]>
Date: Mon, 11 May 2015 16:15:27 +0800

Dear Juergon

Please see inline. Thank you

Vic

-----邮件原件-----
发件人: lmap [mailto:[email-masked]] 代表 Juergen Schoenwaelder
发送时间: 2015年5月11日, 星期一 13:50
收件人: Vic Liu(CMCC)
抄送: 'Romascanu, Dan (Dan)'; [email-masked]
主题: Re: [lmap] New Version Notification for draft-liu-lmap-rest-03.txt

On Mon, May 11, 2015 at 12:51:16PM +0800, Vic Liu(CMCC) wrote:
> Hi Dear Juergen
> 
> 1)For one example:
> in Information Model of Report: (Four element are defined)
>      object {
>          datetime            ma-report-date;
>         [uuid                ma-report-agent-id;]
>         [string              ma-report-group-id;]
>         [ma-report-task-obj  ma-report-tasks<0..*>];
>      } ma-report-obj;
> 
> In the data model, there are two questions, firstly the four element is
not defined as the same name as information model.

There is no requirement that the same name is used. That said, I think

>       +---n report
>          +--ro date        yang:date-and-time
>          +--ro agent-id?   yang:uuid
>          +--ro group-id?   string
>          +--ro task* [name]

is a very close match.

> Secondly, the ro header and re raw is not defined in information model.

Yes, but there is no requirement that there must be a 1:1 translation. We
found that separating header information from row information adds clarity.
Note also that the result rows are actually in a separate ma-report-row-obj;
so I could argue that for rows the separation is even in the information
model.

[(Vic:)we suggest that it should be that same of both information and data
model, because it's easier for people to understand and follow.  :)  ]
 
> 2)What I mean the subset of RESTconf is that we used PUT/POST/GET function
which is subset of all RESTconf function.

You need to provide a reason why this is useful. For example, leaving out
HEAD is I think a major problem.

[(Vic)I'm kind of confused that HEAD method is for retrieve the header. I
read the draft-ietf-netconf-restconf
   The access control behavior is enforced as if the method was GET
   instead of HEAD.  The server MUST respond the same as if the method
   was GET instead of HEAD, except that no response message-body is
   included.
Could you please explain for an HEAD example? Thank you!] 

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 May 2015 11:00:35 +0200

> model, because it's easier for people to understand and follow.  :)  ]

I disagree with this as a principle. A data model has to work with the
constraints of the data modeling language. If we expose them to the
information mode, then the information model becomes data model
specific and at the end becomes pointless.

> Could you please explain for an HEAD example? Thank you!] 

The general question is why do you think it is appropriate to define a
subset of RESTCONF. If you believe RESTCONF is too complex for LMAP,
then I think you should speak up on the NETCONF WG to make sure
RESTCONF is defined in such a way that it is suitable for something
like LMAP. Concerning the HEAD operation: REST applications often need
to validate whether cached information is current. The HEAD operation
gives you exactly that. Leaving HEAD out means you will not be able to
validate caches in an efficient manner. I also find the notion of two
response codes you proposed way too limiting. I am strongly in favor
of using RESTCONF and if there are justified concerns that RESTCONF is
too complex, make sure that RESTCONF gets fixed. RESTCONF is not 100%
cast into stone yet.

/js