Re: [netconf] SN and indirection

[Kent Watsen <[e-mail]>]

>>> (*) An observation: This module introduces a level of indirection for
>>> receivers; something we should have done in the
>>> subscribed-notifications model directly.  Perhaps we should revisit
>>> that model and add the indirection there instead.
>> 
>> What is meant by “revisit”?  SN is in Auth48.  Pull it back or start a
>> bis now?
> 
> I meant a bis.

Excellent.

Back to the adoption call, do you mean as a pre-condition to defining any configured subscription notif transports and, perhaps, multi-stream originators too?    You wrote "perhaps" above, but in the spirit of pinning a plan down, what does the WG want to do here?

FWIW, there are currently no uses of the static configuration defined in SN, as only dynamic subscriptions are currently supported, so changing the static configuration structure defined in SN now should be relatively easy, that is, easier than doing it later.

My personal opinion is that the indirection introduced in https-notif is likely to be desired by all notif transports for configured subscriptions, but it's unclear to me if the leverage to be had by consolidating the pattern into SN is significantly better than the copy/pasting the pattern into each notif draft, especially when considering that we're not likely to ever have more than a few such notif drafts.  It may be that the only justifiable reason for consolidating the pattern into SN would be to enable some cross notif-transport configuration (i.e., the indirection can span notif transports), but I'm struggling to see how this might manifest, some examples would help.  Separately, patching the SN configuration model to support multi-stream originators is an obvious fix for that problem, but hopefully the design team the chairs proposed in Montreal can devise a clever solution that isn't so obtrusive.

Kent