Re: [Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)

Kent Watsen <> Mon, 25 June 2018 12:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E1F7130DE6 for <>; Mon, 25 Jun 2018 05:45:25 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZrrbPL6jmRJb for <>; Mon, 25 Jun 2018 05:45:23 -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 8C367130DDF for <>; Mon, 25 Jun 2018 05:45:23 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w5PCiTjP017786; Mon, 25 Jun 2018 05:45:21 -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=qxYlx5lvj+FRsNJEtlibBJge1RgVF4QhwBaDMQfJd5c=; b=tTuAi6inJsRQxXWVvM2D5HsuDzCl12oZoOKxnjwq4m2u1+dHC82dLPb5+SZJAYBuc6qO ntHYyT0S5Q2cAo++GpXfXySyUDo6wDOJ99aWnZrORWm4iWYeLCVwdtgM4SLM54SdjiIC tUIpyOFtiqbu5fPznDk1brHPH8d8sAnxcIvCLfYY3oT1kR+uPtnoMQR1aLHp5mmj3+UJ 9FnThT5KZ0/8NmezjT7k8LxGc83q5Wmi9n4fnb6wI3JMDML6B2O40qNx3DK2VPHlGQgt fANKA+ozRnsmSg0Xgn4PWwQoKntxql6KvrSG7atmbvp1CvdfMytOhQpeNYVxGciFNdAf 3w==
Received: from ( []) by with ESMTP id 2jtut5gf14-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Jun 2018 05:45:20 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.15; Mon, 25 Jun 2018 12:45:18 +0000
Received: from ([fe80::959d:9fbe:90e4:3cc]) by ([fe80::959d:9fbe:90e4:3cc%4]) with mapi id 15.20.0906.018; Mon, 25 Jun 2018 12:45:18 +0000
From: Kent Watsen <>
To: Henk Birkholz <>
CC: "" <>, "Eric Voit (evoit)" <>
Thread-Topic: [Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)
Thread-Index: AQHUC7BkQt4kuIAVBU+dNFAZwz7Ja6Rw7V0Q
Date: Mon, 25 Jun 2018 12:45:18 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4008; 7:qewvItS+f4Rgv0lqyhPES6uzj0t4APMtxIufvukNoF7Nl6zJ2JLeAoYNCBa36NX+X05r6y1sgX0VYLjzkgfiYlRFuvSLpNw4s+hFJt8VnURr5hGOqluKhTRbHdGMvSnPQ5NO2BHUx+LuDVM+zNMc7DkOLghgBEebjgmpJz/90so8AIhoYTXFCZIVQSj7yhD+a4NCRr0xi06a3Qle9a/7OXX3pUmo5f/InfpihFMozD2hYxg/amu+zFaI4BNzqJIH
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 684764d5-ca40-4fb6-615a-08d5da9981b0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4008;
x-ms-traffictypediagnostic: BYAPR05MB4008:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4008; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4008;
x-forefront-prvs: 0714841678
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(346002)(376002)(39860400002)(396003)(53754006)(199004)(189003)(86362001)(106356001)(606006)(105586002)(186003)(8936002)(66066001)(54906003)(102836004)(81166006)(8676002)(81156014)(97736004)(26005)(486006)(11346002)(53936002)(7736002)(476003)(2616005)(6512007)(6306002)(54896002)(446003)(99286004)(5660300001)(83716003)(236005)(14454004)(68736007)(6246003)(3660700001)(4326008)(36756003)(790700001)(6116002)(3846002)(76176011)(59450400001)(2900100001)(6916009)(25786009)(6436002)(6486002)(229853002)(82746002)(316002)(2906002)(53546011)(5250100002)(3280700002)(33656002)(6506007)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4008;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: g6wqkAftQegbZUta9IP/0e0z4NOrt1p5zPnyVY1ORu3Nh0JheM9Bhc+DC2H/ASZ643koPfJcLPMFdfTRocBNIUy4rPBq5F+zessXLDvb4X0jTuBBc6Fai7rPU/8uiGvzxmFGdDO5+NC/2vmT8pt5ae+AH+Zz46aijpzRVKJwTX9s8MhZx7d26qPl7AwgqewKDIv0GzcqX4dVoZ+n+PiyLU1p46P/N/LNkYfbQThyR34aUGlmTrkzZp0hUjfrb3kz8tbGCJRUSsG21Uyr/Ko5RtjwbkjPdICFA96vgJNnxS9fApVMdnNxh/TCOrEwlx2odjdeOCel++HIzNhELf5XbZEqlZUZg9tck3xcbb2yp8Y=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_858F63BA37A24925B3404DD79CEBEEF9junipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 684764d5-ca40-4fb6-615a-08d5da9981b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2018 12:45:18.2674 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4008
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-25_06:, , 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-1806210000 definitions=main-1806250149
Archived-At: <>
Subject: Re: [Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Jun 2018 12:45:26 -0000

To be clear, we’re discussing conformance requirements.  Options are:

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

I don’t really care, as long as there is a good reason for it.

Kent // contributor

On Jun 24, 2018, at 7:42 AM, Henk Birkholz <<>> wrote:

Hello all,

this poll seems to ask only for "yes" votes, but maybe I am missing something obvious here, but I am also new to the domain of netconf.

In any case, I would like to voice a strong no wrt "only Configured Subscriptions". In complement, I would like to voice a strong yes wrt "Dynamic Subscriptions are not turned into an optional feature".

Drop-shipping or enrollment of YANG datastores should support resilient rendezvous, join or discovery prodedures. I am aware of call home and this seems to be an excellent lightweight basis to build more complex solutions on that will benefit significantly from available dynamic subscription features.

Viele Grüße,


On June 23, 2018 7:50:33 AM GMT+02:00, "Eric Voit (evoit)" <<>> wrote:
Per below, Kent is interested to know if anyone wants to support a Publisher of just Configured Subscriptions.   This would turn Dynamic Subscriptions into an optional feature.

So does anyone want this?  If a few people say yes, I will tweak the document.


<Kent8> I understand that supporting dynamic subscriptions is currently a requirement.  I am challenging that requirement.  Why is it a requirement?  Does it have to be a requirement?

What if an IoT device only wants to support configured subscriptions and having code to support dynamic is wasting space?    FWIW, I realize that not supporting dynamic subscriptions also means that it would be impossible to filling in gaps introduced by a reboot, but maybe that's a decision that the vendor can/should make for themselves?

<Eric9> In RFC-5277, all you have is dynamic subscriptions.  So support for that older spec by definition makes dynamic subscriptions mandatory.  Beyond that, newer specifications like RFC-7923 as well as sections of other documents like RFC-7921, section 7.6 identify dynamic subscriptions as mandatory for a subscription service.  So at least some use cases exist where such dynamic support is mandatory.

<Kent9> Does it?   I mean, this draft doesn't obsolete 5277, so it seems that server can optionally support one or the other or both, and when it supports this draft, can't it use a feature statement to limit dynamic subscriptions?

<Eric10> Per below, I am ok to make dynamic subscription support optional (even if I don’t believe this is the right decision).  Part of the fix in the YANG Model description text would be to note that either dynamic or configured must be supported.

With your IoT publisher use case above you are asserting that dynamic subscriptions are not needed for configured subscription only publishers – i.e., there are a class of publishers which have been driven by use cases not considered by the documents referenced above.  So who has documented the need configured subscription only publishers?   I can’t point to such documentation (beyond IoT case above).  Is such a possibility worth slowing down this spec?     In the end making the fix for this specification which you seem to want is itself really quite trivial: we can make both dynamic and configured subscriptions optional.  The reason I have been resisting it is that this solution (a) leads to more complexity for implementers as yet another feature would have to be advertised as optional, (b) this waters down the mandatory capabilities support of the YANG module, and (c) we would need to include some a constraint that at least one of the two optional features needs to be supported.  Also for (c) AFAIK, features don’t support the application of such constraints, so it would have to be done in the feature descriptions themselves.

I guess the text above is a long way of saying that if you assert the optional dynamic subscription is mandatory to progress the document, I will make the change.  But the change will impose complexity costs which to me are hard to justify.

<Kent10> why don't you ask the WG?  "Should we support servers having only configured subscriptions (i.e. no dynamic subscriptions)?"  FWIW, the ietf-*conf-server modules have features around both the "listen" and "call-home" subtrees.  Heck, you might think "listen" would be mandatory (per RFC 6241), but still we support the possibility of a server only supporting call-home…

<Kent9> that's a reasonable answer, but mind you that it was your IoT use-case originally.   I'd like to get other opinions.  Yes, trivial to add now, hard to add later, more flexibility for servers, almost no additional effort for clients.  FWIW, I'm planning to add a feature statement for "periodic connections" in the ietf-[net|rest]conf-client-server drafts for similar reasons, that the server just might not want to support them, and I don't want the minimal bar to be higher than needed.

<Eric10> Lets go with whatever opinions people have.  I will adapt accordingly.   Do you want me to start an independent thread?

<Kent10> yes, please ask the WG

Sent from my Android device with K-9 Mail. Please excuse my brevity.