[netconf] Updates to http/nc/rc client-server drafts

[Kent Watsen <[e-mail]>]

Dear NETCONF WG,

Please help me navigate a tricky issue and its cascading impact.

Firstly, be advised that the three drafts in the Subject line have been updated twice in the last week (well, the NC draft was updated just once).  The first round of updates (Feb 4th) addressed IESG comments, as well as a comment from Robert Varga (CC-ed).  The second round of updates (Feb 12th) addressed a lingering Security Considerations item I’d forgotten about, as well as to rework parts of the solution from the first update.   It is this “solution” I wish to discuss.

The issue begins with the original "ietf-http-client" module previously defining a leaf called “uri” as type “string” with no “pattern” statement.   Robert Varga rightly (IMO) noted that the YANG would be better if the URI components (e.g., scheme, host, port, etc.) were broken out into a leaf each.  Robert also noted that the path/query/fragment components in the URI never make sense to configure for a RESTCONF server.  To address this, the Feb 4 update converted the “uri” to a “container” having leafs for the various parts, with the path/query/fragment parts having a common “if-feature” statement sharing a feature called “full-url-supported”.

Yesterday, Mahesh and I met to discuss the impact to the “https-notif” draft, which *does* use the “path” component.  [FWIW, it is easy/convenient for the https-notif draft to do it this way, but it is also possible for the draft to define a path-discovery mechanism, like the XRD used by RESTCONF <https://www.rfc-editor.org/rfc/rfc8040.html#section-3.1>.]  This means that the https-notif draft would need the “full-url-supported” feature be enabled, which we didn’t like.  Brainstorming, we thought of these options, that are broadly partitioned into two categories: SUBTRACTIVE vs ADDITIVE, where these terms regard the impact to importing modules:

SUBTRACTIVE: let ietf-http-client define the path/query/fragment nodes (importing modules remove unwanted leafs)

Using a common  “full-url-supported” feature (this was the Feb 2nd solution)
PROs:
Easy, satisfies common use cases
CONs: 
The https-notif draft would need to both a) require the feature be set (unless using an XRD-like discovery mechanism) and b) define an “if-feature” statement to remove the “query” and “fragment” parts.
The restconf-client-server draft would need to define an “if-feature” statement to remove the path/query/fragment” parts (in case the feature is ever enabled).

Using a unique “feature” for each
PROs:
A little more complicated than (1)
CONs
The https-notif draft would need to both a) require the path-specific feature be set (unless using an XRD-like discovery mechanism) and b) define an “if-feature” statement to remove the “query” and “fragment” parts (in case those features are ever enabled)
The restconf-client-server draft would need to define an “if-feature” statement to remove the path/query/fragment” parts (in case the feature is ever enabled).

Using no “feature” statement, leaving it to other drafts to augment feature statements in if needed (this is the Feb 12 solution)
PROs:
Easier than (1)
Gives maximum flexibility to importing modules
CONs
The https-notif draft would need to define an “if-feature” statement to remove the “query” and “fragment” parts.
The restconf-client-server draft would need to define an “if-feature” statement to remove the path/query/fragment” parts.

ADDITIVE: do not have ietf-http-client define the path/query/fragment nodes at all (importing modules add in missing leafs) 
PROs:
Clean, lowest common denominator
Gives even more flexibility to importing modules than (1.3) above.
No need for importing modules to define “if-feature” statements to remove unwanted leafs
CONs:
The “uri” container is an incomplete definition.
This is the biggest sticky point for me.
It seems that a node called “uri” should be a URI per Section 3 of RFC 3986.  Anything less shouldn’t be called a “uri” (IMO) but I don’t know of a good way to do that.


PS: above mentions defining an “if-feature” statements to remove unwanted leafs.  To be clear, the statement is ‘if-feature “foo and not foo”’, which creates a logical fallacy that can never be satisfied.  See https://github.com/netmod-wg/yang-next/issues/153.


Thoughts?

Kent // author