Re: [art] [Uri-review] Re: Alternative representation of URIs in YANG

Mahesh's comment appears to be #4 on my list of options from before, reproduced below:

> Options:
> 
> leave "ietf-uri" as is
> leave "ietf-uri" as is, but add an "applicability" note (recommendations welcome)
> rename "ietf-uri" to "ietf-url", possibly referencing https://url.spec.whatwg.org <https://url.spec.whatwg.org/>
> rename "ietf-uri" to "ietf-http-url" (are URLs ever HTTP-specific?)
> eliminate "ietf-uri" by embedding the fields directly into the "ietf-http-client"


#4 is not bad, IMO, as "ietf-http-url" can clearly state its applicability limitations, which the generic "ietf-uri" would struggle to do, whilst providing a reusable grouping for future use by other YANG modules, if ever such need arises.

That said, surely #5 has got to be the most appealing to all parties, myself included.  #5 does not produce a standalone YANG "grouping" for future consumption, thus eliminating objections raised on this thread.  FWIW, #5 is where the draft started (i.e., had WG consensus) and, frankly, matches the style used by the rest of the suite of client-server drafts.  

Background: in the course of this draft being stuck in DISCUSS state by HTTP ADs (for 2-3 years?), these connection parameter fields were first factored out to a grouping in the same "ietf-http-client" YANG module, and then later, per AD-recommendation, the grouping was moved to its own YANG module, the "ietf-uri" YANG module.

My recommendation is to move the solution back to #5, which had NETCONF WG consensus.   In fact, I will go ahead and make this change later today, betting that there will be no objections by any on the CC.

PS: I still don't think the HTTP folks made their case.

Kent // as author of draft-ietf-netconf-http-client-server