Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver (was RE: mbj's WGLC comments on subscribed-notifications-10)
Kent Watsen <kwatsen@juniper.net> Wed, 09 May 2018 01:29 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 E4A7D12EB23 for <netconf@ietfa.amsl.com>; Tue, 8 May 2018 18:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 1AOg9z8Js0D7 for <netconf@ietfa.amsl.com>; Tue, 8 May 2018 18:29:48 -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 599FD12E045 for <netconf@ietf.org>; Tue, 8 May 2018 18:29:48 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w491TFGi025277; Tue, 8 May 2018 18:29:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=y+2+x9iLoXjrq+aVM0XOUIqcG+7RgY6TeDCYTPqC8Ws=; b=G5bTFulPFH2Me4+SAnQ7ENuq4lwvDoCD81dNC28U/2SGXoVNZvwTrlLwLFB5zXl9/Mpp Ctlyk2Ef4XzrebS5vGDcQ8w4qAgXUJD3+IKvNT+HXnM3OY+rHdUvtARQEfKjSi5LMN99 2FQu/0hTrvcaZ/CzX+7JaFzPRxJHFY3F7qu+nyV94xADiGwPES3e7RG7ZquDE9qoz9DG xNMYe4QCvRXgoy0DqFPEPx2Rra1GV8qlzKbbRpYw7+c75DuIoqf+35NMUEsW6+/0mVZw 4BXMnsgxx9qN+V+bqO+6BMeqGWd7A0eSgwBO89AT31YuPjNFRPQr4haE/9w5umausWO4 Ng==
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0183.outbound.protection.outlook.com [216.32.180.183]) by mx0a-00273201.pphosted.com with ESMTP id 2hup8n04p0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 08 May 2018 18:29:45 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB3989.namprd05.prod.outlook.com (52.135.199.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.10; Wed, 9 May 2018 01:29:43 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::5c50:c79f:dbd0:7a9a]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::5c50:c79f:dbd0:7a9a%13]) with mapi id 15.20.0755.012; Wed, 9 May 2018 01:29:43 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
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/6xu5QKHJ4qABFLuCwA=
Date: Wed, 09 May 2018 01:29:42 +0000
Message-ID: <F5B7A6D2-2C4C-4E26-8912-A2C7193209E1@juniper.net>
References: <d510ae4b5a8548c096229819f92b04d9@XCH-RTP-013.cisco.com> <3f91777ee1b945a7a770d2fcf9b9d0af@XCH-RTP-013.cisco.com>
In-Reply-To: <3f91777ee1b945a7a770d2fcf9b9d0af@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.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB3989; 7:lI2gDSFIpCJ6q1e1SNJ92crohS1XCSNGCU6FRg8lu22X5Fn3IYAo5WsJj0IjNufoQQa7xcgbAaQKmGN4d60OonFTZxOkRTaMBC253kmTSRq45eSLtV1d9c9tglwbX9QYatx7+J6Q5JgVVnVYo2UwT4Zn7uz8pw4y3lUzWLb94oWJajcoXp5ArJjckL5BMR/a3uj8dpBlPaw25DKHm51wxKbWj34PBC11UQOCzpkfOprwtSKRbqO7SnOnHvuTSYvz
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB3989;
x-ms-traffictypediagnostic: BYAPR05MB3989:
x-microsoft-antispam-prvs: <BYAPR05MB3989B8AC754204602EA7AFBFA5990@BYAPR05MB3989.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(95692535739014);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BYAPR05MB3989; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB3989;
x-forefront-prvs: 0667289FF8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(376002)(396003)(39860400002)(366004)(189003)(199004)(53546011)(26005)(6506007)(6306002)(2616005)(476003)(486006)(6512007)(2900100001)(102836004)(575784001)(11346002)(68736007)(86362001)(446003)(76176011)(6246003)(6436002)(6486002)(478600001)(966005)(2906002)(83716003)(186003)(229853002)(99286004)(53936002)(14454004)(5250100002)(8676002)(81156014)(81166006)(3846002)(5660300001)(97736004)(8936002)(3660700001)(106356001)(316002)(15650500001)(7736002)(2501003)(33656002)(305945005)(59450400001)(105586002)(58126008)(110136005)(36756003)(6116002)(25786009)(3280700002)(82746002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB3989; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: lfebgyL+IRQTVC98SS0GOyPvth1jzN1/9Qju2aAhsCMxIhRFr8Q6QmAcg8Ne+K/gb54vHJHIZCNGKMWrmxKydlNazWPxw/wf1C0DiqIUF/WjSYkM+YpfJgA75b4swPY7YR/e4KVQQPV+X+zLSXby+N/XGq4fwsjaM879Iz7WhAtM4+QmzwIww4Z/iVT16pjm
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <434B60E5CAC9D74AB1476592FD3940EC@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 2558171b-f0b3-46b0-6518-08d5b54c5757
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 2558171b-f0b3-46b0-6518-08d5b54c5757
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2018 01:29:42.9655 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB3989
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-08_09:, , 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-1805090012
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/GfDZmrEg7GlP8rt5j5HUfvGL1LY>
Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver (was RE: mbj's WGLC comments on subscribed-notifications-10)
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: Wed, 09 May 2018 01:30:00 -0000
Sorry, just looking at this now while listening to the minutes. I think we should look at [1] for inspiration. This is the pattern that the various client/server and syslog documents used. For instance, notice in [2]: module: ietf-netconf-server +--rw netconf-server +--rw listen {listen}? ... +--rw call-home {call-home}? +--rw netconf-client* [name] +--rw name string +--rw endpoints +--rw endpoint* [name] +--rw name string +--rw (transport) +--:(ssh) {ssh-call-home}? | +--rw ssh | ... +--:(tls) {tls-call-home}? +--rw tls ... See how there is a 'choice' with a case for each transport? "Endpoint" here is like your "receiver"... [1] https://tools.ietf.org/id/draft-schoenw-netmod-yang-pattern-00.txt [2] https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-05#section-4.1 Kent // contributor > From: Eric Voit, April 3, 2018 8:25 PM > > At IETF 101, during the subscribed-notifications review, everyone in the > room seemed good with having a string which acted as the key for a list of > configured receivers: > https://urldefense.proofpoint.com/v2/url?u=https-3A__youtu.be_KJtg-2DJ-2D6CZM-3Ft-3D27m39s&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=XlKKQ9yScaldHxhsVmnkW8vDLpmTgU_4u2wD_WC6BDQ&e= > What was unresolved was that we still needed to choose the preferred way > to enforce each receiver initiating a call-home using the configured > subscription's transport. > > Further below in the thread, Martin proposes a structure to accomplish > this. Please note however that a natural outcome of Martin's suggestion is > the placing of a small YANG model within draft-ietf-netconf-netconf-event- > notifications which just defines an identity for "NETCONF". Specifically: > > identity netconf { > base sn:transport; > base sn:inline-address; > description > "NETCONF is used as a transport for notification messages and > state change notifications."; > } > > ( For the full min-model with all the boilerplate, see: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netconf-2Dwg_notif-2Dnetconf_blob_master_draft-2Dietf-2D&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=ADVNhk_g5Zew9bG9F48_mtfHGr46qSglpAL4AKzJFNY&e= > netconf-netconf-event-notifications-10.txt ) > > The benefit of having this very short model in draft-ietf-netconf-netconf- > event-notifications is that it is quite easy to enforce the proper call home > mechanism for NETCONF based receivers. Another benefit is that we also > can create additional mini models for the RESTCONF / HTTP draft and for > other transports as they are built out. > > Does anyone have issue with this approach? There hasn't been anyone with an opinion or an alternative to Martin's approach. As a result, above it what I put into v12: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetconf-2Dsubscribed-2Dnotifications&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=Hwcw85WOjJ9Duzi44YtoggL7NZpDaVVRlJVV6HeziKA&e= If you feel strongly for please chime in before the end of the week. If no one chimes in, let's close this issue. Eric > Eric > > > > > From: Martin Bjorklund <mbj@tail-f.com> > > Sent: Thursday, March 22, 2018 3:14 PM > > To: Eric Voit (evoit) <evoit@cisco.com> > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] mbj's WGLC comments on > > subscribed-notifications- > > 10 > > > > Hi, > > > > [pruning to open issues] > > > > > > "Eric Voit (evoit)" <evoit@cisco.com> wrote: > > > Hi Martin, > > > > > > Thanks very much for the comments. Thoughts are in line. Also a > > > few key areas marked with "****" > > > > > > Note that changes shown below are also included in this working > > > version > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-2D&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=Do-8-gNbbkSGICRHwztUIZKhbaErQvFYlrCnmrlKvGQ&e= > > netcon > > > f-subscribed-notifications-11.txt > > > > > > > Martin Bjorklund, March 15, 2018 5:12 AM > > > > > > > > Hi, > > > > > > > > Here are my WGLC comments on > > > > draft-ietf-netconf-subscribed-notifications-10. > > > > > > > > In general, I think ths document has improved a lot, it is now > > > > easier to follow. > > > > > > > > > > > > > > > > Major issue > > > > ----------- > > > > > > > > o list receiver > > > > > > > > In the YANG model, the "receiver" list is indexed by ip and port. > > > > > > > > How is the server supposed to use this simple list of ip/port? > > > > > > > > We get a hint from the document in 2.5.2: > > > > > > > > transport specific > > > > call-home operations will be used to establish the connection > > > > > > > > But it is not clear that this list of ip/port helps. > > > > > > Actually, the address is of type Host. Of course for everyone must > > > eventually resolve to an IP address to make a connection. > > > > > > However what I think what you are ultimately trying to do is make > > > sure the choice of index doesn't preclude future mechanisms for > > > referencing receivers beyond address+Port. And this likely is a good > idea. > > > > > > > The document > > > > draft-ietf-netconf-netconf-client-server provides configuration for > > > > call home for NETCONF. In that document, the receiver is > > > > identified with a "netconf-client" name and an "endpoint" name, not > > > > ip/port. (draft-ietf-netconf-restconf-client-server has a similar > > > > structure for RESTCONF). > > > > > > Yes, having alternative, indirect ways of *ultimately* getting to IP > > > address + port would help flexibility. > > > > > > > The best solution would have been to have leafrefs to these > > > > datamodels, but if we do that now, it would introduce a delay b/c > > > > of the dependency. > > > > > > > > The second best solution (I think) is to change this list to have > > > > just a "name" as the single key, and nothing else, and write that > > > > transport-specific modules can add to this in the future. > > > > > > I am fine with name as a single key. However "nothing else" injects > > > a few problems: > > > > > > (1) our traffic counters are transport agnostic. Displacing them to > > > a transport draft reduces utility. > > > > Yes; my mistake, I didn't mean to exclude the counters / state / > > action. Just host/port. > > > > > (2) forcing the acquisition of host or ip address only from the > > > transport draft creates unnecessary complexity for people who are > > > able to simply configure host+Port, should it be available in that > > > form already? So why not simply leave those in as a transport > > > agnostic option of last resort should it be available to populate? > > > > I think it is a bad idea to include open-ended objects just b/c "maybe > > someone would like to use them for something". For interoperability, > > it is important that all objects we define have clear semantics, and > > that it clear how to use them. > > > > In this case, none of the standard transports will need these nodes > > (unless the client-server models are severly changed). If someone > > defines a transport in the future that needs these objects, it is > > trivial to do, and it will be done in a more robust way. > > > > This said, if the WG strongly believes that these nodes are important, > > here's a design that might work: > > > > identity inline-address { > > description > > "A transport identity can derive from this identity in order > > to allow inline definition of the host address in the > > 'receiver' list"; > > } > > } > > > > ... > > > > leaf address { > > when 'derived-from(../../../transport, "sn:inline-address")'; > > ... > > } > > > > The you can define your transport like this: > > > > identity my-udp-based-transport { > > base sn:transport; > > base sn:inline-address; > > } > > > > I would prefer to simply leave this out though. > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=8_AkMiol4GBodtRocjI8gu0PfaUJP79h_03knfp48GI&e= _______________________________________________ Netconf mailing list Netconf@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=8_AkMiol4GBodtRocjI8gu0PfaUJP79h_03knfp48GI&e=
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- [Netconf] IETF 101 SN Question 1: Proper designat… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)