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

[Martin Bjorklund <[e-mail]>]

"Eric Voit (evoit)" <[e-mail]> wrote:
> > From: Martin Bjorklund, May 18, 2018 8:44 AM
> > 
> > "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.
> 
> The main things it adds is the ability to augment receiver specific
> transport parameters in subsequent drafts.
> 
> Honestly, I don't really like the proposal either.  I believe the
> current draft is adequate.  I was just attempting to bridge Kent's
> proposal with your earlier proposal which was adopted after IETF 100
> discussions.
>  
> > 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.
> 
> Yes, with (v12) design, both the encoding and transport cannot vary by
> subscription.  There were many reasons for this.  Some of these
> reasons were discussed as part of WG review of this topic in IETF 100,
> and during the following rough consensus call:
> https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html 
> I am hoping this issue is not reopened as the in-room and subsequent
> email threads had no dissention.
> 
> > 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?
> 
> With "tcp" I believe Kent is attempting to find some home for receiver
> address info prior to the availability of call home specifications.

If we keep the -12 design, this is not an issue at all...

> Kent's thinking is not unreasonable as per point (1) below,
> OC-telemetry.yang and ietf-syslog.yang seem to have no issue with this
> simple design pattern.

... so I will not comment this for now, assuming we'll keep the -12
design.



/martin


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