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

From: Andy Bierman <[email-masked]>
Date: Sun, 28 Feb 2016 09:31:33 -0800

Hi,

The co-authors are working on a new revision of RESTCONF.
We are not adding any new features for I2RS.  There will be
a new section explaining how RESTCONF can be extended.
It is expected that additional RFCs will be needed to support
new functionality related to opstate or I2RS.

Andy

On Fri, Jan 22, 2016 at 7:11 PM, Susan Hares <[email-masked]> wrote:

> 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
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>