[netconf] Re: transport and encodings for configured subscriptions

[Alex Huang Feng <[e-mail]>]

Dear Qiufang, Andy, Kent, NETCONF,

Thank you Qiufang for spotting this issue in UDP-Notif (and the gap on RFC8639). This was not intended, I based the YANG on the HTTPS-Notif draft to have the same way of configuring a “Configured Subscription” for both transports. The example in RFC8639 is misleading for “Configured Subscriptions”.

I added “base sn:configurable-encoding;” to the "udp-notif" identity to solve this issue (-15 iteration in https://github.com/netconf-wg/udp-notif/blob/main/draft-ietf-netconf-udp-notif-15.txt#L972)

  identity udp-notif {
    base sn:transport;
    base sn:configurable-encoding;
    description
      "UDP-Notif is used as transport for notification messages
        and state change notifications.";
  }

I think this “base sn:configurable-encoding” also needs to be added to the identity "https" from ietf-https-notif-transport.yang to allow HTTPS-Notif to be configured with specific encodings.

From a past mail thread (https://mailarchive.ietf.org/arch/msg/netconf/wI6akVDCqd9kHv6OsuD2l8nwHi8/) I see that this was the way it was intended to be implemented:
>>>>> thread
> There have been requests for an establish-subscription RPC to request
> an alternative encoding (e.g., binary with CBOR).  Since there are
> lots of instances for which this is possible, trying not to exclude
> it.

Hmm, ok.  It would have been nice to not have this leaf for transports
that don't support it, and even better if the encoding would depend on
the transport.  This *can* be done with some new identities:

  identity configurable-encoding {
    description
      "If a transport identity derives from this identity, it means
       that it supports configurable encodings.";
  }

  identity http-2 {
    base transport;
    base configurable-encoding;
  }

  leaf encoding {
    when 'derived-from(../transport, "sn:configurable-encoding")';
  }

You can also have transport-specific encodings, instead of generic
encondings, in order to make it impossible to set e.g. "xml" encoding
on a comi transport (if that is a transport…).
<<<<<end thread
So even though I like Andy’s errata (https://www.rfc-editor.org/errata/eid8073) I think not adding the “transport" base to “configurable-encoding” was intentional.

@Qiufang, would you agree that, with this new identify in the YANG module, the examples in the appendix are valid now? 

Regards,
Alex

> On 13 Aug 2024, at 16:54, Andy Bierman <[e-mail]> wrote:
> 
> Hi,
> 
> It is possible the fix is simpler:
> 
> 
> 
>   identity udp-notif {
>     base sn:transport;
>     base sn:configurable-encoding;
>     description
>       "UDP-Notif is used as transport for notification messages
>         and state change notifications.";
>   }
> 
> The identityref requires the 'transport' match.
> The when-stmt requires the 'configurable-encoding' match.
> The Errata I submitted would not be needed.
> 
> 
> Andy
> 
> On Tue, Aug 13, 2024 at 7:38 AM Andy Bierman <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> On Tue, Aug 13, 2024 at 7:22 AM Kent Watsen <[e-mail] <mailto:[e-mail]>> wrote:
>>> Hi Andy,
>>> 
>>>> Look at configurable-encoding.
>>>> Look at the when-stmt in the 'encoding' leaf.
>>>> 
>>>> Note that is not possible to have the when-stmt be true if the sibling 'transport' leaf is set.
>>>> 
>>>> The 'configurable-encoding' identity is not a valid transport.
>>>> The YANG module has been incorrect for configured subscriptions from the start.
>>> 
>>> My implicit question is if the issue in 8639 affects the https-notif and udp-notif drafts?
>>> 
>>> Do their identities need to inherit from configurable-encoding instead, once it is fixed?
>>> 
>> 
>> 
>>   identity udp-notif {
>>     base sn:transport;
>>     description
>>       "UDP-Notif is used as transport for notification messages
>>         and state change notifications.";
>>   }
>> 
>>   identity encode-cbor {
>>     base sn:encoding;
>>     description
>>       "Encode data using CBOR as described in RFC 9254.";
>>     reference
>>       "RFC 9254: CBOR Encoding of Data Modeled with YANG";
>>   }
>> 
>> 
>> Set the leaves:
>> 
>>     transport = udp-notif  
>>     encoding = encode-cbor
>> 
>> 
>> 
>> If the udp-transport is set for the 'transport' leaf it will be accepted since the base is correct (transport)
>> but the when-stmt for the encoding leaf is false because udp-notif is not derived from 'configurable-encoding.
>> 
>> So change udp-notif to be base 'configurable-encoding' so the when-stmt is true.
>> But now the base 'transport' is not met so it is not a valid value for transport.
>> 
>> 
>>    leaf transport {
>>       if-feature "configured";
>>       type transport;
>>       description
>>         "For a configured subscription, this leaf specifies the
>>          transport used to deliver messages destined for all
>>          receivers of that subscription.";
>>     }
>>     leaf encoding {
>>       when 'not(../transport) or derived-from(../transport,
>>       "sn:configurable-encoding")';
>>       type encoding;
>>       description
>>         "The type of encoding for notification messages.  For a
>>         dynamic subscription, if not included as part of an
>>          'establish-subscription' RPC, the encoding will be populated
>>          with the encoding used by that RPC.  For a configured
>>          subscription, if not explicitly configured, the encoding
>>          will be the default encoding for an underlying transport.";
>>     }
>> 
>> If the configurable-encoding identity was fixed then udp-transport could be declared with that base.
>> 
>> If the encoding leaf when-stmt was simply removed, the base 'transport' would be correct.
>> 
>>  
>>> K.
>>> 
>> 
>> Andy
>>  
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]