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

Kent Watsen <kwatsen@juniper.net> Tue, 12 June 2018 00:40 UTC

Return-Path: <kwatsen@juniper.net>
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 216BD130E99 for <netconf@ietfa.amsl.com>; Mon, 11 Jun 2018 17:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 HEvNj5DOfouP for <netconf@ietfa.amsl.com>; Mon, 11 Jun 2018 17:40:22 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B0B130DEE for <netconf@ietf.org>; Mon, 11 Jun 2018 17:40:22 -0700 (PDT)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5C0eK2a001581; Mon, 11 Jun 2018 17:40:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=cEemyfpVlP6r/VMzIYNT+6DJxDlCOWTCErXo5oPCGv0=; b=ARWQ6HCZGy01ylYHWiUGHhM4W8riV4ovBHY05JjIk3R3Snyf3Q3MLFFyU3MgAo7FIq60 DsqdYyaxvYF4SyQI5MtZPHWAyvpsAv//M2OTDsxCkxGhc/Cpn6Pz7HI8/yY3BsZ4ndBZ M9l8RZdSzILInvDgYfff2gWA0shOjv8wSTJVYQIaWGeNWAyIbDpIaJ+ZupgRaIDKIA9Q MRY3Zx0EcsBuviEglZTGQZIV7pW3mld/Q3xSqv9OZ/m8PGZDol8ZEqT10ChN4LSP7+cp iRA34OD0nhHr/8PZlRYq7zbDMy84dWoURH2K7vPEee7wtNJfDycTpB0LUAuVyfD3mWk0 oA==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0079.outbound.protection.outlook.com [207.46.163.79]) by mx0a-00273201.pphosted.com with ESMTP id 2jhu92rx39-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Jun 2018 17:40:20 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4344.namprd05.prod.outlook.com (52.135.202.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.12; Tue, 12 Jun 2018 00:40:16 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc%3]) with mapi id 15.20.0863.010; Tue, 12 Jun 2018 00:40:16 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
Thread-Index: AQHT7qXx6AR0hwD/VEqFVDxs31zp6aQ1kroAgAAEGoCAAA8IgIAAYuSAgCWiwAA=
Date: Tue, 12 Jun 2018 00:40:15 +0000
Message-ID: <ED90F588-9BCC-49C6-B8FF-18554247BD7F@juniper.net>
References: <0c1b4c46d2de4190af83488dff293181@XCH-RTP-013.cisco.com> <20180518.144414.334141005925835002.mbj@tail-f.com> <fbb940135ccb465eb3f5b95d1fb53721@XCH-RTP-013.cisco.com> <20180518.170823.427077888694872498.mbj@tail-f.com> <595D0676-7DBD-4339-A551-374FBED705EC@juniper.net> <4a1e2f7367d54d088e517f7f6614765a@XCH-RTP-013.cisco.com>
In-Reply-To: <4a1e2f7367d54d088e517f7f6614765a@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4344; 7:jdiuDaE8AlrdKSg/exDJMI2N+XS12ypz8c1IZ0aT2oPKwyR8SLwMVW/lxGiQEGAkuc4wySWR6xKja1roDlPEymyqRwJ/BnB0G8JmojvgIt4KUI+a2afDXktP2LRYGfHHI7q0JF2NBtTrZ4L3uto1N7OnGLm5NnMkYG5UkCq8ckvjesXtbL1BJarx/MnAwJUD6k9J/bdqEgnZ71J89DEXiaqYAc4Y4JmP2PcRO0WlyL0mfJ73UtvRIoe+kkEnmUwi
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4344;
x-ms-traffictypediagnostic: BYAPR05MB4344:
x-microsoft-antispam-prvs: <BYAPR05MB4344D4006A4589423CCDE129A57F0@BYAPR05MB4344.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(10436049006162)(192374486261705)(131327999870524)(100405760836317)(95692535739014)(278428928389397);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4344; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4344;
x-forefront-prvs: 07013D7479
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(396003)(39380400002)(346002)(376002)(199004)(189003)(52314003)(51444003)(966005)(33656002)(561944003)(53946003)(6512007)(6246003)(4326008)(53936002)(25786009)(478600001)(6436002)(6486002)(476003)(53546011)(59450400001)(6506007)(8936002)(2616005)(102836004)(81166006)(6116002)(82746002)(3846002)(81156014)(8676002)(66066001)(110136005)(5660300001)(446003)(186003)(99286004)(7736002)(305945005)(58126008)(6306002)(11346002)(36756003)(26005)(486006)(97736004)(229853002)(68736007)(316002)(106356001)(14454004)(93886005)(575784001)(2900100001)(86362001)(105586002)(2906002)(76176011)(83716003)(3660700001)(3280700002)(5250100002)(579004)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4344; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: D1rIWHHxjRrQQdGzFOlDeK27TuSnCi2zWTrVecbl0oZR1+1d0vJQXraetRzAkrvkY8G6lE6Vp+Cz/DNac8jZKmS/YEWkZgEp5iWKUcY63NFjqLeIFihhGcxG1C6nliplmr8q0hhUzSb1fIptBay8kBUAYhf7AlCeTmeJGeWonAhvH4SPd4SV0LQeuyDCkTeM
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <3A3550A2FAE0414EB1F0699B0EDA4CC0@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: d2d6516f-f58f-4040-bfc0-08d5cffd1101
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: d2d6516f-f58f-4040-bfc0-08d5cffd1101
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2018 00:40:16.0858 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4344
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-11_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806120006
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/mVCfToQGXkIti99cvmPtV5BR_q8>
Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 12 Jun 2018 00:40:31 -0000

Hi Eric,

Following-up on this thread after some delay.

K.

===== original message =====

> Kent,
>
>> My proposal is indeed for this draft to rearrange itself to match the "Outbound
>> Connections" pattern described in Section 3 of draft-schoenw-netmod-yang-
>> pattern-00.txt.
>
> While this "outbound connections" pattern is useful in some cases, it doesn't 
> incorporate mechanisms to enforce that each independent receiver for a 
> subscription must use the same transport (per the decision at IETF 100).  So,
> we need to overlay additional mechanisms.

augment-in a "must" expression?


> What is in my proposal is my attempt to bridge that gap.  Even though I prefer
> what is in the current -v12.

Please see about using the outbound connection pattern.  At least model it and 
bring it to the list and perhaps discuss in Montreal, or a virtual interim 
before.  This is a significant decision.  I'm sure it seems like a pain, but
having reworked some of my own models to conform to it, I have to admit that
the models improved.


> In the end, I don't care which answer we choose.  As long as we choose one.

of course.


> You proposed this new mechanism as contributor, which is great.  As WG 
> chair, could you suggest how we close on the selection?  We have already
> have completed a rough consensus call on this design once.  If we do
> re-open, we should follow a plan to swiftly close again as well.

I don't know what rough consensus call you refer to, was this particular
issue discussed?  Regardless, in order to close this issue now, my
recommendation is to model it out and see if there are any problems, 
if no, then it’s a win, otherwise, there will be more discussion.  What
I'm looking for is more detail around how the other transports will 
be configured.  I believe that the plan is to eventually use the
ietf-netconf-server and ietf-restconf-server models, right?  Maybe we
can see how that looks now?

From a chair perspective, Mahesh and I observe that a lot of changes
have occurred during this cycle.  Once the current threads have all
been driven to ground, then we will want to ask the WG if they now
think that the drafts are ready, which may trigger another last call.


>> This enables augmenting in the ietf-netconf-client (initiate) or 
>> ietf-netconf-server (call-home) models and their RESTCONF equivalents.
>> Ultimately, I would expect the netconf-notif and restconf-notif
>> drafts to do this, not this draft, as you say.
>
> I would expect that future iteration of netconf-notif might do this,
> as it is already in WGLC.   Perhaps restconf-notif could incorporate
> if client-server progresses in tandem.

That the draft is in last call is not a problem.  A draft can go 
through more than one, and usually that is needed most when a lot
of changes occurred.  Anyway, just know that the process is more
iterative/agile than waterfall.

To the point as if it's in this version or next, we need to discuss
it more.   For instance, perhaps we could put it in this one and
then use a feature statement to hide all the crypto details when
the feature isn't supported?

Notice already that ietf-netconf-server has feature statements
"ssh-call-home" and "tls-call-home" and, it appears that neither
has to be supported, albeit the "transport" choice is "mandatory
true", but another transport definition (tcp-call-home?) could
be augmented-in.  This seems to give what you want (avoid
configuring crypto now) while also being in-line with these
other drafts.  What do you think?


>> For this draft, we need to discuss the "tcp" transport more.  I'm hoping
>> that it can truly be just plain old TCP, which would require very little
>> explanation, and potentially could be done in this draft (though it would
>> be more consistent there to be another transport-binding draft for it).
>> That said, if you're trying to use "tcp" to really be something like 
>> ietf-netconf-server with all the security configuration left out, then
>> you probably want something else (ietf-netconf-server-with-implicit-csps?)
>> or, perhaps we could discuss modifying the ietf-ssh/tls client/server
>> groupings themselves to make this happen.
>
> If we do reopen this design, my preference would be to drop "tcp", 
> "address", and "port" since we apparently have no consensus.  Vendors
> can then do their own augmentations. where they will just put "address"
> and "port" back in somewhere under receivers. 

In the netconf-notif draft, or this one?  I think we'd want it to be in
netconf-notif, as that's the transport-binding draft.  Okay then, so that
draft would have a note that the additional configuration would need to
be provided by external mechanisms?


>> I'm not tracking the -12 design Martin refers to, but I assume that all
>> this is still inline to having a transport-per-encoding, which I think
>> is what he wants, correct?
>
> Martin has expressed that he is ok with the transport-per-encoding WG
> decision which came out of IETF 100.

Right, but in order to satisfy that, would we need a "must" expression
or something else?


> Eric

Kent // contributor



> "Eric Voit (evoit)" <evoit@cisco.com>; wrote:
> > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > -
> 2Darchive_web_netconf_current_msg13875.html&d=DwIGaQ&c=HAkYuh63rs
> uhr6
> > Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISla
> >
> JdcZo&m=z3XeN5rmsrNHH6Mr6CBN3TfFqPxER3lZG4UdYSAS4y0&s=sxooJCUHG
> 2mSKLd_
> > wXaiEIevsOELvJ2Iw6-6wwvw6yM&e= 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: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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
>