[netconf] Re: transport and encodings for configured subscriptions

[Andy Bierman <[e-mail]>]

On Thu, Aug 8, 2024 at 8:01 PM maqiufang (A) <maqiufang1=
[e-mail]> wrote:

> Hi, all,
>
>
>
> The RFC 8639 defines transport and encoding for the configured
> subscription as follows:
>
>     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.";
>
>     }
>
>
>
> For a configured subscription, I think the idea behind this “when”
> statement design inside the encoding leaf is, to have the configurable
> encoding dependent on the transport, i.e., the encoding node can be
> configured only when the transport allows configurable encoding.
>
>
>
> But the description of the configurable-encoding identity confuses me:
>
>   identity configurable-encoding {
>
>     description
>
>       "If a transport identity derives from this identity, it means
>
>        that it supports configurable encodings.  An example of a
>
>        configurable encoding might be a new identity such as
>
>        'encode-cbor'.  Such an identity could use
>
>        'configurable-encoding' as its base.  This would allow a
>
>        dynamic subscription encoded in JSON (RFC 8259) to request
>
>        that notification messages be encoded via the Concise Binary
>
>        Object Representation (CBOR) (RFC 7049).  Further details for
>
>        any specific configurable encoding would be explored in a
>
>        transport document based on this specification.";
>
>     reference
>
>       "RFC 8259: The JavaScript Object Notation (JSON) Data
>
>                  Interchange Format
>
>        RFC 7049: Concise Binary Object Representation (CBOR)";
>
>   }
>
>
>
> I agree that if the transport identity is derived from this identity, then
> a configurable encoding could be supported.
>
> However, for the new encoding identity (e.g., “encode-cbor”), I don’t
> think it makes sense to use “configurable-encoding” as its base, I think it
> should use “sn:encoding” as base so that it can be configured as a value
> for encoding leaf.
>
>
>
> Looking at the udp-notif and https-notif drafts, both https and udp
> identities definition don’t use “configurable-encoding” as their base,
> which I think would cause the encoding cannot be configured.
>
>      identity udp-notif {
>
>        base sn:transport;
>
>        description
>
>          "UDP-Notif is used as transport for notification messages
>
>            and state change notifications.";
>
>      }
>
>
>
>      identity https {
>
>        base sn:transport;
>
>        description
>
>          "HTTPS transport for notifications.";
>
>      }
>
>
>
> Is this intentional?
>
> But the example in appendix A.1 of udp-notif (
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-14#appendix-A.1)
>  shows some (IMO invalid) configuration for encoding, which makes me wonder
> this might be something that is overlooked by folks.
>
>
>
> Am I missing something?
>
>
>


no

I cannot find the thread, but I remember I raised an issue doubting that
these 2 leaves were ever correct.
The when-stmt looks wrong. Maybe it can just be removed or fixed by Errata





>
> Best Regards,
>
> Qiufang
>

Andy


> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>