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

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 18 May 2018 14:53 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4864E12DA0D for <netconf@ietfa.amsl.com>; Fri, 18 May 2018 07:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXXOgItiJLOQ for <netconf@ietfa.amsl.com>; Fri, 18 May 2018 07:53:46 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FAF12DA09 for <netconf@ietf.org>; Fri, 18 May 2018 07:53:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23236; q=dns/txt; s=iport; t=1526655225; x=1527864825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AejBczpbAbMC/zgNZobl1ZlBkg2l725jKct+pn0EtiA=; b=U+E5jtrIlbK77oTS9fh4LtNHfOA/QrdohLQYd8gfmkGIwBgBXgXGrtnw CM+UCalbJTFU/HnpMoKXc8CgWWDPH3MiKrBt5Esxje1kMooBdSuXpt+ep vN5HC8+TMTND3sXNex9zJerOlSQAAiMOZH0dA9DX2LAlau1xtXPR0hTnE E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DuAADZ5/5a/4kNJK1SAQkZAQEBAQEBAQEBAQEBBwEBAQEBg0NhfSgKg2qIBIx2gXmBD5M2FIFkCyOEA0YCGoF3ITQYAQIBAQEBAQECbBwMhSgBAQEDASMRRQULAgEGAg4HAwICCRoDAgICMBQBEAIEAQ0FCBODCoF3CA+MMZtDghyIP4IiBYEJhgmBI4FUP4EPgg1/gUGBUAIBgSwBBwEJAgEGAoMWglQChxuFBYwsCQKGaYEehkaBP4Nth1mHTokCAhETAYEkARw4YXFwFYJ+giAXiFmFPm8BjmeBGAEB
X-IronPort-AV: E=Sophos;i="5.49,415,1520899200"; d="scan'208";a="395455449"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2018 14:53:43 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w4IErh51014960 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2018 14:53:43 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 18 May 2018 10:53:42 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Fri, 18 May 2018 10:53:42 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "kwatsen@juniper.net" <kwatsen@juniper.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
Thread-Index: AQHT7qZjKKPiRp7oL0Gw54ItH09w2qQ1f5yA
Date: Fri, 18 May 2018 14:53:42 +0000
Message-ID: <fbb940135ccb465eb3f5b95d1fb53721@XCH-RTP-013.cisco.com>
References: <F056EA5D-0AC2-4441-992D-36081F4E660D@juniper.net> <24641154096f4942841b5b4d678fef12@XCH-RTP-013.cisco.com> <0c1b4c46d2de4190af83488dff293181@XCH-RTP-013.cisco.com> <20180518.144414.334141005925835002.mbj@tail-f.com>
In-Reply-To: <20180518.144414.334141005925835002.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/GFzJtQp4XII7aX60zKEj02P-8w0>
Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 May 2018 14:53:49 -0000

> From: Martin Bjorklund, May 18, 2018 8:44 AM
> 
> "Eric Voit (evoit)" <evoit@cisco.com> 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.  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.  

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:evoit@cisco.com>
> > > 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
> > >
> > >
> > >
> > >
> > >
> >