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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 12 March 2020 16:53 UTC

Return-Path: <rwilton@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 155593A0BB6; Thu, 12 Mar 2020 09:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 header.b=kNacOJRK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zW29z+zr
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 qHvq95HbMXLL; Thu, 12 Mar 2020 09:53:33 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D133A0CCE; Thu, 12 Mar 2020 09:53:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6137; q=dns/txt; s=iport; t=1584032013; x=1585241613; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9+yccHruSUkk5yjqD5YDBV/R6lhm3BsYn7l21S4F1sE=; b=kNacOJRKEmnPaI6TIECostltyH2WsmDf/COMoMF00l0ikg6URsE4e4Gw ahgjy63aw4ZHS7K7hyr8FNa0CyGmdqSich5v4ELCffVvqB8NfLlvGdsLE cbZLwLISvoHXr+WKT8Cyk4HlHM1jt7a47hZtO7XM8ZcWb8VXl+oZMjsuS M=;
IronPort-PHdr: =?us-ascii?q?9a23=3ALd/zfhME6NXOIugALXMl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBQA1aGpe/4wNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFgUQgBAsqCodQA4pugl+YFoFCgRADVAkBAQEMAQEtAgQ?= =?us-ascii?q?BAYFPgnQCghYkOBMCAwEBCwEBBQEBAQIBBQRthVYMhWMBAQEBAgEMBi4BASo?= =?us-ascii?q?KAQIBCwQCAQgRAQMBAS8yFwYIAgQBDQUIGoVPAw4gAQOgdgKBOYhigieCfwE?= =?us-ascii?q?BBYUrGIIMCYE4jC8agUE/gRFHgk0+hCkBAQcBGoNBgiyNU1OJSZhKCoI8iFa?= =?us-ascii?q?ONIJKiCaET4t/jwGBTpoLAgQCBAUCDgEBBYFpIoFYcBWDJ1AYDYEajQODc4p?= =?us-ascii?q?VdIEpjAEBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.70,545,1574121600"; d="scan'208";a="460834771"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2020 16:53:32 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 02CGrWvs000345 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Mar 2020 16:53:32 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Mar 2020 11:53:32 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Mar 2020 11:53:32 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Mar 2020 12:53:31 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DVBdr0Jl3UU14uIvLtZJyOaT6fKN0LQDbLTDl0kWqQ7FE7OaDRI7tMHvEKZnn+?= =?utf-8?q?oJkyP1eDmXJPIxFFovVJo8lAzgKUgzBRb83ClUsSOZdF2VtZpXn6HWGfVousYf5p0?= =?utf-8?q?4Gwq0b9LUuJG8VjXez0X0+3f3kQDTHLj8Ato0scq2K5AgDrHdev8b3czb1Bd1KtWt?= =?utf-8?q?gJHYD6VtQkvk6dBteaKxV1hPfmGziDfbSpzRMGdvH9LHO/kC3w+fXXKlOmvnzXODJ?= =?utf-8?q?6M+Xbiw66UnV1XqDgfSK2UBfI9DxpjSonmMXVC+8GET5xH0R/bny2Opi85YL8hv/d?= =?utf-8?q?S6xTk3kn+jWOD7E4MqS1Q=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DGt3RTeQaXsX49b+QTvo8N/eG8709ABf0tD9Zt33HmsU=3D=3B_b=3DKUoBIs?= =?utf-8?q?peoHzsnJhnNBzZNkodZrf9oByN6er6ii/55K40rwClQK0b9tPpVVPZRCBo+sAd06P?= =?utf-8?q?zq2FcK80/jPa06ZRHhWoodGMMsctFOY889tKMt6yRxTCivSLCXKSE/bV01LV8hUBr?= =?utf-8?q?OoIoRduEqHuK2Thd9nuA43lMguUyjWLvF7aerbBkKf10EBYtFoslzsEOdJ6aWN88k?= =?utf-8?q?ZBplwgKwzalDPaF0QNNqQJJVADwb+PBhQABuvca4A+5nnzO1iEoyN1Zf3C28/cfaU?= =?utf-8?q?rlHG46rZdfOCBiFntkstfJa+ccPdSF4WnwfiW/gkyWkNNuZ+jUDxg0zdOPLkQsNnN?= =?utf-8?q?2No6nQk5Ayg=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AM?= =?utf-8?q?essage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADC?= =?utf-8?q?heck=3B_bh=3DGt3RTeQaXsX49b+QTvo8N/eG8709ABf0tD9Zt33HmsU=3D=3B_b?= =?utf-8?q?=3DzW29z+zr2Tpn1thkZjSBJv+V3cpkXAxWIW5zTot+KplGDNYlPnoBo39uNLg0iq?= =?utf-8?q?J4skKgDFfH6KRzbA0FnYqiV2X2J9YqZIEu04npCi0n8i880Usduupq4tFiqXRHxP7?= =?utf-8?q?TAO4XthTP6PrEwzpPUjjQduxFxY89VToqekftkNVhn8o=3D?=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4414.namprd11.prod.outlook.com (2603:10b6:208:17b::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.16; Thu, 12 Mar 2020 16:53:30 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3%5]) with mapi id 15.20.2814.007; Thu, 12 Mar 2020 16:53:30 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= <balazs.lengyel@ericsson.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: AQHV5fT97GQMgsC5TEuE1GmMKTxx36ggKT0AgBjpugCAB5/HwIABLu8AgAL3rkCAAG91gIAAB/8g
Date: Thu, 12 Mar 2020 16:53:30 +0000
Message-ID: =?utf-8?q?=3CMN2PR11MB43669B25DE5791ADA3F19828B5FD0=40MN2PR11MB4?= =?utf-8?q?366=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: =?utf-8?q?=3C0100017055c347e5-13b624a9-04c0-4ba5-8a53-26a80f0796?= =?utf-8?q?07-000000=40email=2Eamazonses=2Ecom=3E_=3C0100017055e833dd-1a2eca?= =?utf-8?q?c4-53e4-4bb7-aab9-f75516c5fd38-000000=40email=2Eamazonses=2Ecom?= =?utf-8?q?=3E_=3C01000170a78abdde-66112ceb-d466-4c72-ad18-6058ef07ab02-0000?= =?utf-8?q?00=40email=2Eamazonses=2Ecom=3E_=3CBY5PR11MB43554B2EDF3D395D2680D?= =?utf-8?q?9C1B5FE0=40BY5PR11MB4355=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E_=3C?= =?utf-8?q?DB7PR07MB4011F0C718EF704D1B0F5385F0FF0=40DB7PR07MB4011=2Eeurprd07?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E_=3CMN2PR11MB436638F28AAFFB3E19059F65B5?= =?utf-8?q?FD0=40MN2PR11MB4366=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E_=3CDB7PR?= =?utf-8?q?07MB4011DC0291E31D7A797CFE52F0FD0=40DB7PR07MB4011=2Eeurprd07=2Epr?= =?utf-8?q?od=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CDB7PR07MB4011DC0291E31D7A797CFE52F0FD0=40DB7PR07MB?= =?utf-8?q?4011=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 662c0c6c-e98e-4f55-2001-08d7c6a5e4cd
x-ms-traffictypediagnostic: MN2PR11MB4414:
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR11MB4414A3B1A71E96246B50AAA1B5F?= =?utf-8?q?D0=40MN2PR11MB4414=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0340850FCD
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzOTg2MDQwMDAwMikoMTM2MDAzKSgzOTYwMDMpKDM0NjAwMikoMzc2?= =?utf-8?b?MDAyKSgzNjYwMDQpKDE5OTAwNCkoNjQ3NTYwMDgpKDk2ODYwMDMpKDUyNTM2?= =?utf-8?b?MDE0KSgzMTYwMDIpKDU1MDE2MDAyKSg2NjQ3NjAwNykoODYzNjIwMDEpKDg2?= =?utf-8?q?76002=29=2881156014=29=2866574012=29=2876116006=29=2866446008=29?= =?utf-8?q?=2866556008=29=2866946007=29=288936002=29=2881166006=29=281101360?= =?utf-8?b?MDUpKDI5MDYwMDIpKDQzMjYwMDgpKDcxMjAwNDAwMDAxKSg2NTA2MDA3KSg3?= =?utf-8?q?696005=29=2833656002=29=285660300002=29=2815650500001=29=2826005?= =?utf-8?q?=29=28186003=29=2853546011=29=28478600001=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4414; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?5VjjmKK1IuUZH14i38RdSt6LQ6HTUFv?= =?utf-8?q?gNivTnmDeMkTxHLY1LY58TgD1yLuTpBetqUYdczdfEovv3TUUo8BPvZJy6q8rvwXf?= =?utf-8?q?ZxZCsfwMel2dyAWKXVKczzGeGnorTEu9n8JlGfybMh9cffBhlEkIY8S/ijjyHQDy0?= =?utf-8?q?O2pdfUnfHcb6T5TT+TdYvhYGl3ckn0ePXPd9SeMvrhyWODxEWXAXTh3CpywtLoY2D?= =?utf-8?q?e0uL4CkjBfz+yMC/BSMJQJ+maCqIiY2IP4wXHzrn4ePipwuIkQlwNbknv4Wap8yhc?= =?utf-8?q?p4kNO81xWkmLJoxNMBR/VShB8xOOfrdMaF8s4FcKQELsK/RxrDAwyf2bnFkqtp5lE?= =?utf-8?q?fAPJym88EYreWRxl0vI49Li0zvGk6UbEkHJHLAuOMYtJf37uVlArobYI18tXF8GSM?= =?utf-8?q?+EoYLu4WSybxW2uIOPYrZ+/YgHG?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?/KJeIFoL2DmtyWgvJIcA8EoqLGAHFt?= =?utf-8?q?5X2tC/n6CwP5FXJj/GcRXbv7GufDws5GjMxRJVaGF+068zEodiS+K4WpTRoYHg38i?= =?utf-8?q?MqXfxp/seIEANrHPh7HzV5pr659XamkP2o5Lzs/6Zm/JczJuY/KA/Vg=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 662c0c6c-e98e-4f55-2001-08d7c6a5e4cd
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 16:53:30.5597 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?M3HSwCYUBKYKr0iinYIwG?= =?utf-8?q?WDsEkae4134JwmEcjQXT3VebU7B31nU8G9gEs5izGXLDB8R0KinrFdADKdHH5Xy1w?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4414
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/8cAHxBoK7RvgMC2FCIzSY71Ug8Y>
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:53:36 -0000


> -----Original Message-----
> From: Balázs Lengyel <balazs.lengyel@ericsson.com>
> Sent: 12 March 2020 16:22
> To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; netconf@ietf.org; draft-
> ietf-netconf-notification-capabilities@ietf.org
> Cc: Kent Watsen <kent+ietf@watsen.net>
> Subject: RE: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-
> 11
> 
> 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.
[RW] 
I think that most recent standards just use this:

   The YANG data model in this document conforms to the Network
   Management Datastore Architecture (NMDA) defined in RFC 8342.

Often it goes in the abstract, but I think that putting it in the Introduction should be fine.



> 
> >
> > 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.";
[RW] 
Okay, thanks for clarifying.


> >
> > 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
[RW] 
Yes, okay for this draft.

Thanks,
Rob


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