[netconf] overview of updates and current issues

[Kent Watsen <[e-mail]>]

For all drafts:

  - Collapsed all the inner groupings into the top-level grouping.
  - Added a top-level "demux container" inside the top-level grouping.
    By "demux", I'm referring to the namespace problem discussed @104.
  - Added NACM statements and updated the Security Considerations section.
  - Added "presence" statements on the "keepalive" containers, as was
    needed to address a validation error that appeared after adding the
    "must" statements into the NETCONF/RESTCONF client/server modules.
  - Updated the boilerplate text in module-level "description" statement
     to match copyeditor convention.

For the http draft:
  - removed "keepalive" node
  - added "proxy-server" node
  - added "protocol-version" node
  - added "server-name" node

For the netconf/restconf drafts:
  - Adjusted for the top-level "demux container" added by groupings
    imported from other modules.
  - Added "must" expressions to ensure that keepalives are not
    configured for "periodic" connections.
  - Moved "groupings-expanded" tree diagrams to the Appendix.



Current Issues:

1. Regarding the "demux containers":

     Pros:
       - now NC/RC models look better
       - a convenient place to have a nacm:default-deny-write

     Cons:
       - seems overbearing for general use

   Question:

     Would it be better to revert and instead wrap each "uses"
     statement in the NC/RC models with a container?

        Pros: maximum flexibility
        Cons: less consistency?
       


2. Only in the RESTCONF draft, http proxy-server weirdness

   a) in the "ietf-restconf-client", there's an unwanted "proxy-server"
      definition  (middle of page 43):

      /restconf-client/listen/endpoint/https/http-client-parameters/proxy-server

      An HTTP client that receives a call-home connection does NOT need
      to initiate a connection and therefore there never is a desire to
      configure a proxy server, but here it is!

      It's here because the "ieft-http-client" grouping defines it, but
      when that grouping is used, neither "refine" nor "augment" can
      remove the definition.

      Sure, a "must" could disable it, but it still shows in the tree
      diagram, which is undesirable...


  b)in the "ietf-restconf-server", there's a missing "proxy-server"
      definition  (bottom of page 48 ):

      /restconf-server/call-home/restconf-client/endpoints/endpoint/\
      https/http-client-parameters/<missing:proxy-server/>

      An HTTP server that establishes a call-home connection needs
      to initiate a connection and therefore there is a desire to
      configure a proxy server, but the config node is missing!

      This is because the "ieft-http-server" grouping doesn't
      defines a proxy-server node (because servers typically
      never need to go through a proxy so, when that grouping
      is used, the definition is missing.

      Sure, we could augment it in, but coupled with the above,
      maybe there's a better answer?

  What to do?


3. In either the NETCONF and RESTCONF drafts, does it matter at all
   where a 'must' statement is located, especially if they refer to
   nodes that are conditional by "if-feature" statements?

      i.e., search for "case periodic-connection"

   Should the "must" statements be located somewhere else?



4) Only in the NETCONF draft, Section 5 contains the old  "Design
   Considerations" text from ~5 years ago.

   The idea of removing is was discussed a while back, and someone
   said it was worth keeping...

   I'm thinking again to remove it, but rather to deleting it, I'm
   now thinking maybe we could *move* it to an Informational draft:

     "Architecture for the Collection of Client and Server Models"

   that could also contain a picture like this:

                                        crypto-types
                                          ^      ^
                                         /        \
                                        /          \
                              trust-anchors       keystore
                                 ^      ^------+    ^
                                 |              \   |
                                 |      +-----------+
                                 |     /          \
 tcp-client-server     ssh-client-server      tls-client-server     http-client-server
       ^      ^              ^                  ^           ^               ^
       |      |              |                  |           |               |
       |      |              |       +----------+           |               |
       |      |              |       |                      |               |
       |      |              |       |                      |               |
       |      +--------------|-------|------------+         |               |
       |                     |       |            |         |               |
       |                     |       |            |         |               |
       +--------------+      |       |            |         |      +--------+
                      |      |       |            |         |      |
                      |      |       |            |         |      |
                   netconf-client-server        restconf-client-server




  If there is desire, it would be best to do it now so that all of
  the client/server drafts could reference it.  Thus, whichever draft
  a reader begins with, their attention is drawn to the collection and
  thus they can see how the part fits into the whole.

  Someone else can write it.

  Thoughts?



Kent // contributor