Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver (was RE: mbj's WGLC comments on subscribed-notifications-10)

["Eric Voit (evoit)" <[e-mail]>]

Hi Kent,
Hi Martin,

Kent's underlying desire in the thread below is to insert a transport case under /subscriptions/subscription/receivers/receiver to match design patterns used elsewhere.    If we really want to do this, the way this could be done with the current design with Kent's proposal would be something like:

       +--rw subscriptions
          +--rw subscription* [identifier]
             +--rw identifier                       
             +--rw transport                        transport   {configured}?
             +--rw receivers
                +--rw receiver* [name]
                   +--rw name                      string
                    +--rw (transport)                                    {configured}?
                           +--:(tcp)?
                           |   +--rw address                  inet:host
                           |    +--rw port?                        inet:port-number
                           +--------future transport case augmentations....

Benefits of this approach:

(1) The tcp case provides an initial option for of an easy equivalence to the capability of "destination-address" and "destination-port" which appears in OC-telemetry.yang.   And it follows the design pattern as it appears in the UDP case leaf "address" and "port" of ietf-syslog.yang.   Just placing an address and port into these models has proven simple and effective.  

(2) While we await ietf-netconf-server.yang, linkage to receiver details such security credentials that are held elsewhere on the publisher *can* initially be done using "address" within the tcp case.  (I.e., I don't see any issue with having as undefined how the authentication association is done in the transport independent draft.)  Note: per the thread below, it is important not have security credentials in this part of the subscription model as could be dozens of configured subscriptions aimed at the same receiver, and it would be confusing to the other users of these credentials to look them up within this configured subscriptions model.

(3) From this starting point, future case augmentations would allow us to augment cases to "(transport)" for the placement of call-home leafrefs to modules like ietf-netconf-server.yang.  This would allow model users and applications the ability to shift to using the leafref.

More in-line.   In the end, I will gladly salute whatever the WG decides.  It would be great to find a way complete this discussion. 

> From: Eric Voit, May 14, 2018 5:26 PM
> 
> From: Kent Watsen, May 14, 2018 4:19 PM
> 
> On 5/9/18, 4:17 PM, "Eric Voit (evoit)" <mailto:[e-mail]> wrote:
> 
> >> From: Kent Watsen, May 9, 2018 1:49 PM
> >>
> >> Listening to the audio from 101, it seemed that Martin's objection
> >> was primarily that the current draft didn't follow the pattern that
> >> other drafts are using [1].
> >
> > Martin's point in and post IETF 101 was that address and port was not
> > a good key for a receiver. Plus, where we have address, that we
> > shouldn't use port because that connection information shouldn't be
> repeated (possibly with errors) across independent subscriptions.
> 
> Yes, he mentioned issues related to keys, but he also mentioned the pattern
> [1] used by other drafts, which is what I'm more focused on now…
> 
> 
> > In the end, the final proposal embodied in the draft was one made by
> >Martin.  This proposal does  allow for a very clean match to your
> >client-server drafts as both the endpoints and receivers are  keyed by
> >name.  I.e.,
> >    +--rw endpoint* [name]          +--rw receiver* [name]
> >       +--rw name    string            +--rw name    string
> 
> My focus is not on the name so much as the lack of a
> 'choice'  statement.  Please see Section 3 in [1].
> 
> 
> >> Without actually understanding the proposal below, I'll only state
> >> that my thought is not to push this work towards [2] today, but more
> >> to ensure it follows the pattern.
> >>
> >> FWIW, in the syslog draft, we used to have a "tcp" transport type,
> >> which was really just an address/port pair, so maybe something like:
> >>
> >>        +--rw subscriptions
> >>           +--rw subscription* [id]
> >>                +--rw id
> >>                +--rw receivers
> >>                   +--rw receiver* [name]
> >>                        +--rw name    string
> >>                        +--rw (transport)
> >>                          +--:(tcp) {tcp-call-home}?
> >>                              +--rw tcp
> >
> > Per IETF 100, transport is no longer under receivers.  It is under the
> > subscription.  This is the current tree, with transport high up...
> >
> >      +--rw subscriptions
> >         +--rw subscription* [identifier]
> >            +--rw identifier                       subscription-id
> >            +--rw transport                        transport   {configured}?
> >            +--rw receivers
> >               +--rw receiver* [name]
> >                  +--rw name                      string
> >                  +--rw address?                  inet:host
> 
> I see "transport" under subscription, but it is using an identity (not a
> choice).   Also, back to "receiver", it's the configurable "address" leaf that I'm
> thinking needs to be under a 'choice'.   I see you have an interesting 'when'
> expression referencing the "inline-address" identity, which appears to address
> some of the "what if the transport doesn't support IP" issue…

Yes, this was one of Martin's proposals to cover the "what if.."

> >> Wait, now I'm confused, how is only specifying an "address"
> >> sufficient for configuration.  I thought the receiver needed to
> authenticated.  -12 says:
> >
> > Receivers need to be authenticated.  But this draft does not attempt
> > configure the keys and mechanisms to perform that step.  Other sources of
> data are needed.
> 
> I don't like publishing a data model that hand-waves over parts of the
> configuration, and it was this line of thinking that caused update to the syslog
> draft. 

This draft does not attempt to configure call home, and it shouldn't considering that:
 
(a) specific call home technologies need to be associated with specific transport 
(b) there is already adopted call home with this objective of configuring this info
(c) when the call home drafts are ready, we can augment a leafref under /subscriptions/subscription/receivers/receiver.


> Also, I don't recall seeing anywhere in this document a statement that
> the configuration model is incomplete - did I miss it?

As configuration can vary transport, such a statement on configuration if needed wouldn't be here.   If you look at draft-ietf-netconf-netconf-event-notifications Section 6.2, the description of the call home process is described there.   If you think it helpful, I can put in an informative reference to draft-ietf-netconf-netconf-client-server there.

> > There are two ways to do this:
> > (1) The "address" is of type inet:host which when used with the
> > configured subscription's transport
> > *CAN* provide the requisite information needed to look up the remote
> > host authentication and proper call home information for that
> > receiver.   (Note: address is one simplistic option to get to this
> > information today without integrating useful but complex structures.)
> 
> An address by itself may not a sufficient lookup key, as the server may have
> different services running on different ports and, of course, all sorts of security
> parameters can vary.

I liked having port as well.  Martin requested its removal as it could be populated with something which contradicts what is in the call home configuration.

With the tree proposal at the top, I think we could have "port" be optional.  And we would say in the description that it is only populated only if it is different than a call home value if it exists, or a default port number for the transport protocol.  This should provide clarity on when it would or wouldn't be populated.

> > (2) When the client-server drafts are ready, a leafref can be augmented into:
> >      +--rw netconf-client
> >         +--rw initiate {initiate}?
> >            +--rw netconf-server* [name]
> >               +--rw name                  string
> >               +--rw endpoints
> >                  +--rw endpoint* [name]
> >                     +--rw name    string
> 
> yes, this is what I'm thinking about.  The pattern described in [1] was designed
> to allow for such augmentations, but I don't understand how it would work
> here.   Can this draft follow the pattern now with, perhaps, only a "tcp"
> transport?  But even then, I don't see how the receiver can be authenticated
> (per requirement), maybe that requirement should be removed so that an
> unauthenticated "tcp" transport can be fully configured?

I see no issue with requiring authentication for the transport, without explicitly storing the keys in this model, or pointing to the keys in a different model.   

> > All the transport specific complexities/variations here emphasize the
> > need for separate the subscription model as all the details for such
> > authentication and transport configuration.  This complexity need not be
> replicated and repeated under each and every subscription.
> 
> I'm not sure exactly what this means (maybe a tree diagram or example would
> help), but note that each instance of ietf-tcp-client fully specifies its security
> parameters, though a *lot* of the really redundant stuff is factored out via
> leafrefs to ietf-trust-anchors and ietf-keystore (assuming that draft comes
> back).

I believe the proposal at the top of this email helps avoid configuration redundancy.  

> >>    For both configured and dynamic subscriptions the publisher MUST
> >>    authenticate and authorize a receiver via some transport level
> >>    mechanism before sending any updates.
> >>
> >> How is the crypto and auth configured?
> >
> > Yes this is absolutely a need.  But not specific to subscriptions.   In the end, a
> lot of protocols need
> > these specifics.   I am certainly looking to your keystore related drafts to
> standardize such mechanisms.
> 
> True, and I do think that this document (or the transport-binding documents)
> will ultimately depend
> on the various client/server drafts the WG has been working on.  There is no
> other game in town, so
> to speak.  Though the question remains if this is now or later thing.

The structures are proposed here to allow for growth into a later solution.
 
> >> Maybe this draft should leave the
> >> "transport" choice node empty,
> >
> > There isn't any transport choice node.  Just the identity.
> 
> True, but then how is just an identity sufficient?   Let's say we finally get the
> netconf-client-server draft to
> RFC, and so someone creates an identity for "netconf", but where would the
> "uses" grouping statement
> go?

A place now exists in the proposal above.

> >> and let the netconf-notif and restconf-notif
> >> modules augment in their respective transport-specific config into the
> >> "transport" choice node here?
> >
> > While it could be augmented, I believe “out of scope” awaiting the client-
> server drafts is a cleaner path.
> > Especially as we shouldn’t repeat this info for each and every subscription.
> 
> I'm okay with us coming up with an unauthenticated "tcp" transport now,
> leaving the crypto stuff
> out for now, so long as we have a pattern that we can follow to augment in
> what we need later.
> That said, note that the IESG made RFC 6587 HISTORIC and may not have much
> appetite for an
> unauthenticated transport again…

Per above, I believe we can identify the tcp address and port, with an expectation that leafrefs are later augmentable to elements that are not currently modeled.
 
> BTW, restconf-notif defines bindings for RESTCONF, HTTP2, and HTTP1.1, but
> the restconf-client-server
> draft only defines a binding for RESTCONF, have you put thought to how
> HTTP2 and HTTP1.1 can be
> supported?  for all intents and purposes, I think that it's the same config, but I
> haven't looked into the
> details either.

Configured subscriptions only use HTTP2.   The working plan is for the other identities to be used for operational datastore exposure.

Eric
 
> Kent  // contributor
> 
> 
> 
> 
>