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

Kent Watsen <> Mon, 14 May 2018 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8D2112D95B for <>; Mon, 14 May 2018 13:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aPbN2P8GMHzM for <>; Mon, 14 May 2018 13:18:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55C13126DFB for <>; Mon, 14 May 2018 13:18:36 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w4EKISdW000360; Mon, 14 May 2018 13:18:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=PHghNoQ+lSURl9dVmGad3f6xflo59Z2frAiwnMYgk+8=; b=a7e3NrZ/NfphhQncYJSuQFB4nwr8Zhc408BuTllX67j0vB8h07bzKwrOeP/a6pnWheg+ 55Jr7O0IqTDuO50r2GXYTL1+P87F6HGkDJYoPFdcR4Gfjpnf4vzKM0NM6RZUHnydoB+T XtTuJCDo83iY4SU7NbxrzuOJi3pmLGiu+cusiv/uL8hHS9At3LKKq/2qRXfGiURXddEj paPstSsBPOFEMT3erP5MUwGhodMZGSzJC30D0t24hL6wZjhtzRUvDxWT3iaAHuBqtlXy aksVHWblou4RFlW5QEGLGHEtqbkfyN2kQJNPI1EQZW3nE6Tm3EjZQksi5bpfXRHs6q01 vQ==
Received: from ( []) by with ESMTP id 2hyg6084a1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 May 2018 13:18:34 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.776.4; Mon, 14 May 2018 20:18:31 +0000
Received: from ([fe80::5c50:c79f:dbd0:7a9a]) by ([fe80::5c50:c79f:dbd0:7a9a%13]) with mapi id 15.20.0776.008; Mon, 14 May 2018 20:18:31 +0000
From: Kent Watsen <>
To: "Eric Voit (evoit)" <>
CC: "" <>, Martin Bjorklund <>
Thread-Topic: [Netconf] IETF 101 SN Question 1: Proper designation of receiver (was RE: mbj's WGLC comments on subscribed-notifications-10)
Thread-Index: AdPLq1bdbG0V/cUiRq+xx5f8/6xu5QKHJ4qABFLuCwAAJ7APgP//1AsAgABspYCAB5jZAA==
Date: Mon, 14 May 2018 20:18:31 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4471; 7:fnuw/1Itok2Ft7SPFMqsTw72mTdAWcVbJbYKPwDchTaV9yYcBnCEg3CzWwkw6gki8zKBOUZgawOds3d0wQ0Ff1EotLz9g8WqmacxyDT7qjtxGNGmmbrgII2X9tpNyKbp7NAo5r7/vxrMYR0uMkDt58sKR3YR90scRtBHLCeAcOq12H2HBA7kVt9FKjE++6cy/1bWGNbJoERDmy21aNqytBOwUGsyCcA8EGpiZXPcRYjAnjgriWuVI+XujEadY713
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4471;
x-ms-traffictypediagnostic: BYAPR05MB4471:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(95692535739014)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BYAPR05MB4471; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4471;
x-forefront-prvs: 067270ECAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(376002)(346002)(39380400002)(39860400002)(366004)(396003)(51444003)(189003)(199004)(7110500001)(66066001)(476003)(2616005)(81156014)(186003)(8676002)(478600001)(81166006)(106356001)(3846002)(11346002)(105586002)(59450400001)(6506007)(53546011)(26005)(6116002)(14454004)(486006)(229853002)(93886005)(76176011)(7736002)(102836004)(4326008)(2420400007)(99286004)(83716003)(36756003)(2906002)(68736007)(6916009)(86362001)(236005)(6486002)(3660700001)(97736004)(54906003)(58126008)(5250100002)(33656002)(316002)(3280700002)(6436002)(10710500007)(6306002)(54896002)(446003)(6246003)(82746002)(8936002)(6512007)(2900100001)(15650500001)(5660300001)(25786009)(53936002)(561944003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4471;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: HUr7l8vv8M5HAHpJYojr59l2BSGPf92fPwz8yoBLIiD6/IYHHabSrXb55/1KTNmjrJ9IbBAvb+ry6DtG8+Xd26xQ2be6cuKf6+kgQkav+2APNIbh0muPd6yqhL3E4ZFX4dO8zXOXa50TPKWALNVpY4kanKw4LQl/0+F9SB4XoTicJIy9R+Z6tzGFnvJ67woT
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_F056EA5D0AC24441992D36081F4E660Djunipernet_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: d7f7eb3b-643c-4d5f-5215-08d5b9d7dcda
X-MS-Exchange-CrossTenant-Network-Message-Id: d7f7eb3b-643c-4d5f-5215-08d5b9d7dcda
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2018 20:18:31.6570 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4471
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-14_04:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805140204
Archived-At: <>
Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver (was RE: mbj's WGLC comments on subscribed-notifications-10)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 May 2018 20:18:40 -0000

On 5/9/18, 4:17 PM, "Eric Voit (evoit)" <<>> 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…

>> 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.  Also, I don't recall seeing anywhere in this document

a statement that the configuration model is incomplete - did I miss it?

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

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

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

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

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


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

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.

Kent  // contributor