Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver

[Martin Bjorklund <[e-mail]>]

"Eric Voit (evoit)" <[e-mail]> wrote:
> 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....

Is the idea still to configure the transport (and encoding) per
subscription?  If this is the case, I don't think this new proposal
adds anything.

This said, I would prefer a design that more closely follows the
"Outbound Connection" design pattern:

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


IMO this is a more natural and simpler design.

The argument against this was (IIRC) that it is easier for the server
if the transport + encoding is fixed per subscription, b/c then the
server can prepare one payload that is sent to all subscribers.  But I
don't really buy this argument; if the operator needs different
transports / encodings the current (-12) design forces the operator to
create two subscriptions.  This means that the server has to filter
the data twice, and then still do two different encodings /
transports.

Also, unless there is a document that describes the "tcp" transport, I
strongly think it should be removed.  If not, how can this be
interoperable?


/martin


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