Re: [netconf] SN and indirection

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 
> >>> (*) 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?

I didn't mean as a pre-condition, but if the WG thinks it can be done
I'm all for it.

> 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

I agree.

> 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.

If we don't have a generic indirection, I would like the current
https-notif solution better if it didn't put 'receivers' at the
top-level, but instead augmented it into '/sn:subscribers', and
renamed it to 'https-receivers'.  Further, the 'receiver-ref' should
probably be called 'https-receiver-ref' or something.


> 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.

I watched the session on youtube, but I must admit that I don't
understand the problem.  Is there a description of the problem
somewhere?  If not, this belongs to a separate thread.


/martin