Subject: [Netconf] read-through comments on draft-ietf-netconf-restconf-09

From: "Susan Hares" <[email-masked]>
Date: Fri, 22 Jan 2016 22:11:43 -0500

Andy, Martin, Ken: 

My read through comments have 4 parts:  status, minor issues, editorial, and
i2rs-related comments.  The I2RS-related comments are only to show that
ephemeral state can be added incrementally to this design.   I hope these
comments will help progress RESTCONF quickly!

Sue 

===================================

Section 1:  Status: Almost Ready to be publish, minor issues/editorial nits

==========

Section 2: Minor issues: 

+2.1 -  what other protocols than TLS are possible for HTTP for RESTCONF

            [Joe Clarke Fri 1/8/2016 2:10 PM also mentions]

+3.4.1 -  This is Edit Collision detection for the {+restconf}/data nodes by
the server for Patch entities

                may be useful for I2RS (see I2RS comments below).  What is
not clear from the text is whether you can 

               have a tree 

                                +--rw data-level-1 time-stamp, Entity-Tag

                                  +--rw data-level-2  Entity-Tag [no time
stamp]

                                    +--rw data-level 3  Time stamp [no
entity]

                                         +--rw data-level 4  Time-stamp,
Entity tag 

                If you must a continuous line of ancestors with time-stamp
(levels 1-3) to have level 4, then this must be explained.

              Likewise if you must have a continuous line of ancestors for
Entity-Tag, then this must be explained. 

+3. Section 4.6 - there is a plain patch, but no mention is made of a more
complicated patch.   Is this on purpose, or did you want to refer to another
draft? 

+4. List actions that apply to all list entries: GET, DELETE, sequence of
PATCHes for a list (multiple entries from Lada (+1 on Lada: Mon 1/11/2016
5:36 AM),

+5 Application of multiple filters in order for Query plus start-time/stop
time.  Is this possible? 

+6 - Does Data timestamp and E-Tag apply to operational state data? 

 +--rw restconf

     +--rw data 

         +--rw config-data

         +--ro  oper-state-data 

     +--rw operations 

+7: You do not mention leaf-lists (this is +1 on Lada Mon 1/1/2016 5:36AM
comment). 

+8: CAN RESTCONF and NETCONF both attach to a data store? 

      If so the question regarding netconf lock (persist-id), and RESTCONF
edit collisions

      Needs to be reference in section n3.4.1.  If not, it needs to be
clearly stated

     (+1 Martin Bjorklund's comment on revising locking 1/8/2016 9:45pm)  

     (see Tom Petch's comment A) on 1/22/2016 at 11:20am) 

+9: +1 on Security review that more needs to be in the security section. 

.         It would be helpful to consider whether the I2RS extensions
suggested below might break the data security of RESTCONF.  I believe
RESTCONF will fulfill the I2RS protocol security requirements minus the
ephemeral state (not created yet). 

.         Note that Tom Petch (comment A on 1/22/2016 at 11:20am) - asks if
"authenticated NETCONF username [MUST] be associated with each request".  

.         NACM is clearly specified in order to allow some filtering of
results, but the link to authenticated NETCONF user name is not as strongly
linked.   Since I2RS has suggested NACM may prevent some DoS attacks, this
may be useful. 

+10- +1 on (Rodney Cummings 1/11/2016 5:30pm) - we should have a capability
that indicates if we can pull module schema if this is optional.  Security
may restrict a full pull of the module schema if there is a module
augmentation by a vendor that has security add-ons. 

+11 - Since insert and point is required for PUT/POST on the server,  can
modules be designed that do not support it?  The comment from Rodney
Cummings 1/11/2016 5:30pm] surprised me.  Can this be explained or defined
some-how?  If modules do not support it for lists, then please explain the
error handling. 

+12 - +1 to Robert Wilton's question on http 1.2?  Section 2.1 specifies
http 1.1 [RFC7230].   Will RESTCONF run over HTTP 1.2?  I did not find any
restrictions on http 1.1 pipelining.  Does this mean that RESTCONF can
access different parts of a tree via two different sessions?   What happens
if overwrites - Last one wins edit collisions - unless you have the model
timestamp and ETAG ID flags on? 

+13 - +1 on the question or edit ordering from Robert Wilton [1/19/2016
5:46am] 

+14 - +1 - where netmod-opsstate-reqs fit into this document? It would be
good to determine if the module that is "read-only" can get a query such as
"op-state-only".   It would be good to query for multiple flags (op-state,
with-default, ephemeral).   Have you considered how you will merge this in?
It would be good if these would be incremental upgrades. 

=========

Section 3: Editorial issues: 

=============================

#1 Multiple places /operational data/operational state data/ 

[+ to Lada: Mon 1/11/2016 5:36am concern, but different resolution] 

#2 p. 6: HATEOAS ( at least deserves an expansion, and a definition) since
it is the scheme you are not choosing.   (+1 on Lada: Mon 1/11/2016 5:36
AM), 

#3 p. 10: ABNF  - first time ABNF is used, it should be expanded.  

#4 p. 25 - In section 3.6.3 in paragraph 2  

/Using the "reset" operation/ Using the "reset" operation from the example
in section 3.6

#5 p. 30 section 4.4.1 paragraph 2

from /The "insert" and the "point query parameters are supported by the POST
method 

for data store and data resource types, as specified in the yang definition
in section 8./

/The "insert (section 4.8.4) and the "point" (section 4.8.5) are supported
by the POST method 

for data store and data resource types, as specified in the yang definition
in section 8./

#6: [Lada's comments] = +1 on most of Lada's editorial comments [Lada Monday
1/10/2016 5:36am] 

=====================================

Section 4 - I2RS and ephemeral state. 

-----------------

#1 - expanding the Query and PUT/PATCH to allow for ephemeral state in Data
Store per node 

a)      Expand Query's "content" and create a "with-ephemeral" to allow for
query of Ephemeral state.  Expanding

b)      Expand PUT content to allow ephemeral 

RESTCONF allows access via API to data (datastore) and operations.  The data
store has 

Allows default data for a node.   If one considers ephemeral to apply to a
node, and 

Entries under it - then the treatment of "default" (section 4.8.9) may be
useful as a template for ephemeral. 

Recently, I have reviewed BGP and found Session ephemeral state (BGP Flow
Specification, and 

BGP QoS SLA state) which terminates if peer goes down.  There are two types
of ephemeral: reboot ephemeral and session ephemeral.  Let me give the
example with packet forwarding filter (a filter) which can have two types of
ephemeral nodes: I2RS FB-RIB filter, BGP Flow Specification filters, as well
a configuration filter (ACL or packet-reception-filter-Condition-Action
rule).

+--rw restconfig

    +--rw data 

        +--rw configuration

            +--filter-list* [name]

               +--rw name 

               +--rw Filter

               |  +--value  

               |  +--rw default-value 

               |  +--rw  config-store-value

               |  +--rw ephemeral-reboot-value 

               |  +--rw ephemeral-session-value 

               |  +--rw value-type - flag on what is in value

               |         default, config-stored-value,

               |         ephemeral-reboot-value, 

               |         ephemeral-session-value 

               |  +--rw precedence-order (default, different order) 

              |       (this provides either a precedence or different order)

         +--ro  oper-state 

              +--ro Filter-1 

              |  +--ro value-type - type currently runing 

              |  +--ro pkt-match-count 

    +--rw operations 

        +---

The value - could be set from default value, config-store value,
ephemeral-reboot-value, or ephemeral-session value.  The "value-type" gives
the type set in the node.  

Expansion of command: 

.         If we expand the Query concepts of "content (section 4.8.1) or
create a "with-ephemeral", you can utilize the Query to get specific
ephemeral state. 

.         If you expand the concepts in PUT/Patch to allow to set the
ephemeral notes. 

#2- RESTCONF Collision handling  vs. I2RS Collision handling 

.         Timestamp and E-Tag - provide the when and who 

.         I2RS collision uses -  when, who, and priority - 

Since 1 user has 1 priority per session, I think

we could simply link the "E-Tag" to a Priority table? 

.         Alternatively, we could just create a third collision resource for
I2RS.

The reason for this discussion is to point out, we could just augment
existing RESTCONF to support I2RS requirements. 

#3 - if you create an ephemeral data store rather than ephemeral nodes, will