Re: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-11

Balázs Lengyel <balazs.lengyel@ericsson.com> Thu, 12 March 2020 16:22 UTC

Return-Path: <balazs.lengyel@ericsson.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 0A4563A0CCF; Thu, 12 Mar 2020 09:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DekbuUh6i6nZ; Thu, 12 Mar 2020 09:22:08 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80073.outbound.protection.outlook.com [40.107.8.73]) (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 89F823A0996; Thu, 12 Mar 2020 09:22:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+7LDYu+O+bj4SSURm8owEGSQiUnvqqE2GpQZnACoaBUq20QzuPw1khr+880fbUMv6JPC2TzfKrxT+Cwn8Em1i+IfFMT8RcW8eDgMVBDG0iFQPWU1lrQ1oHtD/1EzPJ4SajQLS+sucRSRW0P6HpvI4VEOovSP4scqn/2ymCXaGUldWExavOF0LkGrh80Jm+7OucS6+6lamfYnplTB2jciATKIpmva7GMuBkqSVSr75el6wNTbd0Ru5AS1YZKsUoft30aNN3ifwKCece12OFL62XLi+I3DwrS7HIwehvJRYRVzNwG6JIu/jiKVX1B7MOC3n+bk6hSu0XvucS0SJ2S1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=+JNh9JgJ+PO3NTrcTdEYoHp6fjuxl/QPC7Y2rP5w61I=; b=detUJ+H2qmYZnb/WJ7X0tm5IWce0khZrYONXlm660QIgnQS7jSh0WalATLcD7ym5VCO8+NmNkP+wLAN4Rx5zMxn/Hj/shnH/XQhvap5d0aQ9XQQ9z1C5T1HNgbXFiC690CW7OAz01o9NDosXyEKHL2gLGQIHuPskieuNYQ2sxNs4mOhP7S+JznxVl+DlUvhI7wSQ+trgNRyXBX+tXT31GWBYU2q9XANXHtmG1RYVJ0w4vmdduem0V2QGWBTNdlTPoge2ubL036N8AbFW/9hTeyj+hDaQDrxlb1w972D7h52a9edVM0UpYcuQu9JbVyL1Ggei2SHiw3Ds/Y6cZ6OSAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=+JNh9JgJ+PO3NTrcTdEYoHp6fjuxl/QPC7Y2rP5w61I=; b=NQ8GvqLiT88J9F8/PkxbIynBFyZ1+rGad25m9GAxajHKXv7o5MSX4jSPsIG3ieRZiwa9CURaVCBuga2gEE945R2F+T3PuXw+BTrDCeD/v+NHXYp6tra1O0BLd426fPus5v0HNUq7Z1LNIpryZGVQhzt4kEsq+QPayf0y2Wr7Hls=
Received: from DB7PR07MB4011.eurprd07.prod.outlook.com (52.134.97.155) by DB7PR07MB4603.eurprd07.prod.outlook.com (52.135.134.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.6; Thu, 12 Mar 2020 16:22:03 +0000
Received: from DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::15cf:dc81:c6f4:aa0c]) by DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::15cf:dc81:c6f4:aa0c%7]) with mapi id 15.20.2814.007; Thu, 12 Mar 2020 16:22:03 +0000
From: Balázs Lengyel <balazs.lengyel@ericsson.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-notification-capabilities@ietf.org" <draft-ietf-netconf-notification-capabilities@ietf.org>
Thread-Topic: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-11
Thread-Index: AQHV5fT9KP6991uunUyOxSTTpAhfm6ggKT0AgBjpugCAB6OcAIAA/NWwgAM3mICAADvG0A==
Date: Thu, 12 Mar 2020 16:22:03 +0000
Message-ID: <DB7PR07MB4011DC0291E31D7A797CFE52F0FD0@DB7PR07MB4011.eurprd07.prod.outlook.com>
References: <0100017055c347e5-13b624a9-04c0-4ba5-8a53-26a80f079607-000000@email.amazonses.com> <0100017055e833dd-1a2ecac4-53e4-4bb7-aab9-f75516c5fd38-000000@email.amazonses.com> <01000170a78abdde-66112ceb-d466-4c72-ad18-6058ef07ab02-000000@email.amazonses.com> <BY5PR11MB43554B2EDF3D395D2680D9C1B5FE0@BY5PR11MB4355.namprd11.prod.outlook.com> <DB7PR07MB4011F0C718EF704D1B0F5385F0FF0@DB7PR07MB4011.eurprd07.prod.outlook.com> <MN2PR11MB436638F28AAFFB3E19059F65B5FD0@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB436638F28AAFFB3E19059F65B5FD0@MN2PR11MB4366.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-originating-ip: [89.135.192.225]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3bf70449-93b1-4f99-e347-08d7c6a17fb8
x-ms-traffictypediagnostic: DB7PR07MB4603:
x-microsoft-antispam-prvs: <DB7PR07MB460358FFBCC0F1F1AA28BAFEF0FD0@DB7PR07MB4603.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0340850FCD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(199004)(66946007)(71200400001)(66574012)(81156014)(478600001)(7696005)(52536014)(8676002)(81166006)(76116006)(86362001)(186003)(8936002)(33656002)(55016002)(110136005)(5660300002)(316002)(66446008)(15650500001)(9686003)(4326008)(2906002)(6506007)(26005)(64756008)(66476007)(66556008)(66616009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4603; H:DB7PR07MB4011.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0OkTizbGWj9bbpyriAXqTtM4gPcMW9ZsZ67v7wjQla0DDK7WtMEjhNfyzLZFxdV/yBveu9pPO6uurEfQ/0TmoTOUEuac6PbxHGfZCk0YgYHinKKPLSgG4EC2LvCJg1KD/PKV3IG3tl0pBdmesuH6mkIFhXuc0vS+KK9sDKelL31kHkhueokIzwcYpT021Fb5wRzGuf2dSbvgRQANelWjeJ2/dEYT4E8ebCMB6Hqz6Z6jQ+nqHRy9u8SRLPyxCP32wJ6OPPEpTcsCR3ZOCsvxVvZ9LkLWlI9WFNBgiSjAwIXiw+4/vU3RubAFCKsaFVAuAvLWI5wpxp+rENTcz26VcuUeUUWuiF18C42SamjMLCv8siugxCMdp3XoncoF3qMbeyA+1Xrt3lM+4SxcquQm6oNALUtVScFamiDZei4KycBEJ5nG/MYpkqdJRo9GMAVt
x-ms-exchange-antispam-messagedata: Pk3ukVivmIV9oeGYvOQBAal+Qm3rRNXiNvsCXFlhd+rYWUOnOwvIAGjRTrwDuEQraJXgXPVVplCr29HhIwKdfNq0XDxe6j8WwwA4RmZBR9gaheLbIoee47JcfE2kYTQLcA+jRc6mUSk9BLameMhbbg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_016C_01D5F892.BDE765B0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3bf70449-93b1-4f99-e347-08d7c6a17fb8
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 16:22:03.0432 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: o/hQNcVtk+N/48mvLasU+o4NCBGYVrB2kkzpfssu7bGlnxGSetVX/OmkCD9H0vYt3i3oICpKseTT7DIKreJutLoIu7oYfZzSkSoFprxpHH0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4603
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/BypDF-Hd71S_O5xBtCfdwMn9sfE>
Subject: Re: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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: Thu, 12 Mar 2020 16:22:10 -0000

See BALAZS2 below.

-----Original Message-----
From: Rob Wilton (rwilton) <rwilton@cisco.com> 
Sent: 2020. március 12., csütörtök 11:46

> -----Original Message-----
> 
> 4. Section 2:
> Please state that the YANG modules are compliant to NMDA.
> BALAZS: What does it mean that a read-only module is NMDA compliant?
> Please
> explain. I would rather not add text that I do not understand.
>
[RW]
It just means that the model is designed to conform to the architecture, and
work with devices that support such an architecture.  E.g. it also means
that the modules are not called "foo-state".
BALAZS2: I still think the "conform to the architecture" is very vague.
That modules are not called "foo-state" is trivial and can be seen from the
module names.
IMHO if we want such a standard text we should define what it means. It
would fit into a mail and later into the YANG guidelines.
Based on your insistence, for now I propose to add the sentence
" The module can be used both by NMDA and non-NMDA compliant systems."
Are you OK with my sentence ?
Note: as many of today's systems are not NMDA compliant it is equally or
more important to note that the model works with non-NMDA.
Actually I am not 100% sure what "works with non-NMDA" means either: E.g. it
does not hide important information that would only be visible in
operational datastore. 
 
> 
> 5. YANG model:

> - Does "minimum-dampening-period" only apply if dampening is requested, or
> does that mean that dampening is always required?  The text may need to be
> clarified.  Otherwise, I'm concerned about the on-change notification for
> interface statistics ... that could generate a lot of notifications ;-)
> BALAZS: The answer is not trivial. I can see logic in both cases:
> a) if there is a minimum-dampening-period declared  here, that means that
> dampening MUST always be used. Logical because if the publisher can not
> support a smaller than 5 sec dampening period, it is probably incapable to
> support on-change without dampening.
> b) the publisher MAY support on-change without dampening, but if dampening
> is requested the period MUST NOT be smaller than the
> minimum-dampening-period
>BALAZS2: Based on the opinions of Eric, Benoit and myself I will update
following alternative a). Added to description
      leaf minimum-dampening-period {
        description
           If this value is present and greater than zero, 
           that implies dampening is mandatory.";
> 
> 6. Section 6 (Security):
> 
> Is there a risk that the capabilities information, if available offline
> and
> also from a device, could be used to fingerprint the device and gain
> information about what version of software/hardware is being run?
> BALAZS: I t could be used as part of the fingerprinting, as any readable
> data that changes infrequently. IMHO this is a generic problem, to be
> solved
> by proper access control rules. Adding it as a kind of standard boiler
> text
> to every YANG module would not help. Maybe we would need an OAM security
> RFC.
> 
[RW] 
Actually, perhaps this should just be in the security section of the
instance data draft.  That would then seem to apply generally to all YANG
modules used as instance data.
BALAZS2:  IMHO fingerprinting is possible the same way on a live server, it
is not specific to instance data files. Fingerprinting is actually a much
bigger problem on a live server, as there are a lot of standard models
available (yanglib, netconf-monitoring, nacm, etc.) while in instance data
you only have a small set of specific modules (maybe just one). Instance
data is usually only a partial set, which might also hide specifics,
hindering fingerprinting. You many not even be sure which server the
instance data came from: There is no origin parameter in the header part. So
IMHO finger-printing is a FAR bigger problem  on a live server.

Also: This is the second security related issue that effects the whole
YANG/Netconf/Restconf ecosystem, so IMHO it should be dealt with in a
centralized manner, not by each YAM individually.
- fingerprinting
- updates to security mechanisms like the TLS algorithms for factory-reset

I would like to avoid the topic in my draft.
> 
> 
> 8. Appendix A:
> - Your examples look like they probably have some introduced line wrapping
> (e.g. for the description, node-selector, and others).  Perhaps we should
> be
> using the artwork draft for this, or alternatively add a comment that
> linespaces have been introduced in various fields to improve readability.
> BALAZS: I would prefer to wait till  draft-ietf-netmod-artwork-folding
> becomes a full RFC. Even creating/using the folding header without the RFC
> number is problematic.
[RW] 
I don't think that this should really be a problem.

draft-ietf-netmod-artwork-folding is int the RFC editor queue and has no
missing references, i.e. it is going to become an RFC before this draft
does, and the RFC editor will be able fix up the folding header.
BALAZS2: OK