[netconf] Re: Adoption call for notif-yang-04

[Kent Watsen <[e-mail]>]

Hi Alex,

I’m glad you wrote this message, as you have surfaced a number of good issues.


>> For *configured* subscriptions, the "https-notif" and "udp-notif" drafts appear normative.  Currently the https-notif draft says to use string “letf-https-notif”, but this can (should, IMO) be changed to “ietf-notification”.  The udp-notif draft already uses “ietf-notification” but doesn’t have normative text for why.
> 
> I find this statement actually very surprising.

I just meant that udp-notif seems to be missing statements like found in https-notif:
  - when encoding XML, use the format described in RFC 5277
  - when encoding JSON, use the format described in RFC 8040, but replace “ietf-restconf” with “ietf-notification”
  - when encoding CBOR, ...

I understand that you’re purposely trying to not do this (for valid reasons), but what else can we do, and consistency is good...


> But re-reading HTTPS-notif, the draft is defining some constraints for the encoded message for the Application layer, would you agree that we are crossing layers here?

What constraints?  Do you mean what I wrote immediately above?  These could be perceived as crossing layers, but we’re already doing it everywhere, so it's par for the course?


> Also, the scope of both transports are a bit different:

I’ve been meaning to suggest that may want to align the scopes.  I don’t see why we’d want to limit sending YANG-defined notifications over UDP to just RFC 8639.  Be aware that several folks have stated 8639 is too complicated for simple systems.  Do we plan to shutout systems that rather not implement 8639 from being able to sending notifications over UDP?


> Note also that the title of the draft is for "Transport for YANG Notifications" (I would not call RFC5277 YANG notifications).

Perhaps “YANG-defined Notifications” would’ve been clearer?

But I wouldn’t call these messages "NETCONF Event Notification", as that name is only the title of an RFC and, of course, using the string “NETCONF” is incredibly confusing when something isn’t actually NETCONF-specific.   FWIW, RFC 5277 mostly uses the string “event notification”, which is reasonable, but I think YANG-defined Notifications is more descriptive.


> So, on UDP-notif, I don’t like the idea of having normative text stating how my upper layer message should look like. This should be defined in the general architecture document (RFC8639 in this case).

I’m sympathetic to your appeal, I don’t like it either, but it seems that we’re currently in a solution-space where the transports define the envelop.  How to get out of that, or if it’s necessary to get out of, is the question.  This goes to the requirements.

Speaking of requirements, I noticed that the notif-yang posted today has the same YANG model as before, which necessitates two-step validation, but I thought Thomas said single-step validation was a requirement?  Maybe single-step validation isn’t a requirement?

Taking a step back, it seems that the “requirement” in this work is to enable CBOR encoding.  Do I understand right that it is not possible today to CBOR-encode notifications, because there’s no YANG for the envelop?  And the current notif-yang solves that problem, and so is good enough, even though still necessitating two-step validation?


>> If the “https-notif” and “udp-notif” drafts are updated to use “ietf-notification”, normalizing the module name seems mostly resolved.
> 
> I agree both should use the same namespace “ietf-notification” when they are used in NETCONF environments. Since RESTCONF has its own namespace, seems reasonable to me to limit this to NETCONF.

What does "NETCONF environment” mean?   If you mean “NETCONF server”, please note that any *CONF server could be configured to send YANG-defined notifications using any protocol and/or encoding a la https-notif, udp-notif, or some future kafka-notif, rabbitmq-notif, etc.

FWIW, we might want RESTCONF-next to align the namespace as well:  https://github.com/netconf-wg/restconf-next/issues/18



> For a system to work at the end, we need cross-WG documents. If we want to extend HTTPS-notif to be used with CBOR and YANG-SIDs (a draft adding the CBOR encoding to HTTPS-notif and asking for the SIDs), I believe this document belongs to NETCONF WG.

If RFC 9254 is unclear, then one might expect the fix would be in RFC 9254 - right?

The CBOR solution entails SID registrations.  I don’t recall this WG ever registering a SID before.  For that matter, I’m unaware of any WG registering SIDs.  Perhaps CORE WG should write an RFC defining how IANA can auto-gen SIDs for all YANG modules to offload other WGs from having to do this?  [Note: having IANA auto-gen SIDs for IETF RFCs doesn’t help other SDOs defining YANG modules]


> My two cents,

Only two?  Let’s add more  ;)

What are the high-level goals?   (nice-to-have or must-have?)
  1) to have a single/unified definition for envelops
  2) to enable single-step validation 
  3) to enable additional headers (e.g., sysName, sequenceNum) [notif-sequencing]
  4) to enable multiple notifications in a message (only needed for UDP?) [notification-messages, expired]
  5) to enable additional footers (e.g., signature) [notification-messages, expired]
  6) to enable future metadata extensions, since it’s unlikely whatever we define now will last long?
  7) to enable all of the above regardless of encoding (XML, JSON, CBOR, etc.)

If we could start-over, what would we do differently?
  - would we change YANG’s “notification” statement? 
  - would we change the YANG-to-encoding docs (e.g., 7951)?

For this work, and others of its kind, instead of sx:structure, what about defining special YANG-defined notifications to carry the extra metadata?  For instance:

	notification bundled-notification {
		container header {
			…
		}
		list notifications {
			// the “key” statement not required for notifications 
			leaf event-time {
				type yang:data-and-time;
			}
			anydata notification;
		}
	}

PROs:
	- automatically works everywhere
	- validation in every encoding
	- the existing top-level “eventTime” leaf could be ignored/discarded
	- can be augmented
CONs:
	- still entails two-step validation
		- note that, for bundled messages, one-step validation is likely never possible.


> 
> Regards, 
> Alex

K.