[netconf] transport and encodings for configured subscriptions

["maqiufang (A)" <[e-mail]>]

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?


Best Regards,
Qiufang