Martin Bjorklund wrote:
> Andy Bierman <andyb@iwl.com> wrote:
>> Hi,
>>
>>
>> I would like to resolve the base:1.1 issues in 4741bis.
>>
>> 1) client and server advertise the base capabilities they support
>>    (base:1.0 and/or base:1.1)
>>
>>      urn:ietf:params:netconf:base:1.0
>>      urn:ietf:params:netconf:base:1.1
>>
>>   The namespace for all base:1.0 and base:1.1 elements are the same
>>
>>      urn:ietf:params:xml:ns:netconf:base:1.0
>>
>>   The client and server will determine which protocol version
>>   (RFC 4741 or 4741bis) is in use, by examining the base URI
>>   string during the <hello> exchange.  If there are no base URIs
>>   in common, then the session is dropped.
>>
>>   The base:1.1 capability will be defined in normative text,
>>   not in the ietf-netconf.yang module (e.g., via extension-stmts).
>>
>>   There seemed to be consensus in Anaheim to make this change to RFC 4741bis.
>>   This is needed to indicate to new clients that the server
>>   is following the more-constrained rules in RFC 4741bis,
>>   not the under-specified rules in RFC 4741.
> 
> I agree with this.
> 
>> 2) Server advertising YANG module ietf-netconf
>>
>>     urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2010-xx-xx
>>
>>   There are problems with replacing NETCONF capabilities with YANG features:
>>   a) capabilities with parameters (e.g. url or with-defaults)
>>      are not translated completely.  All the parameters are lost.
>>   b) base:1.0 needs to be supported for awhile, so implementations
>>      still need to parse the capabilities
>>
>>   Also, advertising module ietf-netconf.yang implies that the server
>>   supports YANG, when in fact the base:1.1 (+ other capabilities)
>>   is the real indication of protocol conformance.
>>
>>   There did not seem to be any consensus on this part of the problem.
> 
> I think it is better to let the server advertise the base capability
> as you describe in (1) above, instead of the normal YANG capability.
> This can be controlled with an extension in ietf-netconf.yang:
> 
>   module ietf-netconf {
>   
>     namespace "urn:ietf:params:xml:ns:netconf:base:1.0";
>     prefix nc;
>     nc:capability "urn:ietf:params:netconf:base:1.1";
>      
>     ...
>   
>     extension capability {
>     argument uri;
>     description
>       "If this extension is present within the 'module' statement,
>        a NECTONF server will adveritise the 'uri' as specified as
>        the argument to this statement instead of the URI as
>        mandated by YANG.
>   
>        This extension is used only to support the versioning mechanism
>        in the NETCONF protocol.";
>   }
> 

I don't like this because it means everyone will have to
special-case this sort of capability.  This does not follow
the rules in the YANG spec.  A client is supposed to be able
to parse the module XML namespace from the capability URI.

A client should not trust the module names, because they
may not be unique.  The XML namespace is much more likely
to be unique.  Clients should use the XML namespace in their
module lookup code, and not rely on the module name.

How is the client supposed to know when a module has decided
to suppress the module namespace and use a capability extension
instead?

This will confuse clients into thinking there is an XML namespace
"urn:ietf:params:netconf:base:1.1" for module ietf-netconf.

I prefer to only get the correct YANG encoding for every YANG module.

The 'base:1.1' capability is sufficient.
The module=ietf-netconf and the revision date are not needed.
The 'base:1.1' is more conceptually correct, because server
conformance in this case is the the entire protocol (as defined
in RFC 4741bis.)  YANG conformance is only for the operations
and content layers, not the other layers,  The 'base:1.1' capability
covers all the layers.


> 
> 3) We should also decide if we want to make any of the base:1.1
>   functions optionally controlled by the client.  Specifically I am
>   thinking of the discussion on capability-change.  My proposal was to
>   let the client decide if it wants the server to ignore capability
>   changes in the session or not, by advertising this info in the
>   capability URI.
> 

This could be a separate URI, or a parameter added to base:1.1

> 
> 
> /martin
> 

Andy