Re: [Netconf] subscribed-notifications-12

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 20 April 2018 17:24 UTC

Return-Path: <evoit@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 45FDE12D7F8 for <netconf@ietfa.amsl.com>; Fri, 20 Apr 2018 10:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 772fPE4G6Na1 for <netconf@ietfa.amsl.com>; Fri, 20 Apr 2018 10:24:02 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D583B12785F for <netconf@ietf.org>; Fri, 20 Apr 2018 10:24:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6844; q=dns/txt; s=iport; t=1524245042; x=1525454642; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6hHlxnMU7h18lLE4WCVfLvhpK8XXuT+wMyb5IjMCYy8=; b=aAiCdU8iVxLDB0OtU3MXJ8n5yFDZFSL+uoNbBg+LOxXuEEEPSFPjQNj3 WKeya2rGdGyqtUcXT5h0p+8l4ECDA35TQ2Fkz+WP2gZDGO1ZyuwmkpTbO +tg308Gvg8MxIYzAGz4uS+WbPPEgqMR8nI3kSUvZwy35jQ9JPDPL9T2V2 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQCNIdpa/4ENJK1SCRsBAQEBAwE?= =?us-ascii?q?BAQkBAQGDQmF6KAqDYIgCjHiBdIEPkngUgWQLJ4N8RgIagishNBgBAgEBAQE?= =?us-ascii?q?BAQJsHAyFIgEBAQECASMRQwIFBwQCAQgRBAEBAwIJHQICAjAVCAgCBA4FCBO?= =?us-ascii?q?EaggPpl6CHIhBgiQFgQmGfYFUP4EPgwuDEQIBgSQRCgEBgx6CVAKXcQgChVm?= =?us-ascii?q?IXIxWiTSGTgIREwGBJAEcOIFScBWCfoV8hRSFPm8BjS6BH4EYAQE?=
X-IronPort-AV: E=Sophos;i="5.49,302,1520899200"; d="scan'208";a="101677867"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2018 17:24:01 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w3KHO0Mg025864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Apr 2018 17:24:01 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Apr 2018 13:24:00 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Fri, 20 Apr 2018 13:24:00 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "t.petch" <ietfc@btconnect.com>
CC: Kent Watsen <kwatsen@juniper.net>, Alexander Clemm <ludwig@clemm.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: subscribed-notifications-12
Thread-Index: AQHT19OSvBCDfpubJUuCjcsotTnR4KQIExlQgAFcu3KAACfUoA==
Date: Fri, 20 Apr 2018 17:23:59 +0000
Message-ID: <52324706692049ad9ffee9e88a8f15ce@XCH-RTP-013.cisco.com>
References: <17B884BF-0BB8-4B7C-BFBB-0AAFBEA857F6@juniper.net> <aedeb7390d0b4faa9f2bf12c2fe45cd2@XCH-RTP-013.cisco.com> <040a01d3be9f$09700490$1c500db0$@clemm.org> <2089023D-DA09-48E9-8F37-8FE459DC4F49@juniper.net> <dfc78f2b1062498388824b1f6dd97ff6@XCH-RTP-013.cisco.com> <1EC2E732-C524-4552-A3AD-27507239F763@juniper.net> <2b788c22f7ee4af889813b805348d69a@XCH-RTP-013.cisco.com> <067301d3d7d3$71bc1820$4001a8c0@gateway.2wire.net> <7e405392a4be49abbba13bfa2fb6d38e@XCH-RTP-013.cisco.com> <014f01d3d88f$9bf4a1e0$4001a8c0@gateway.2wire.net>
In-Reply-To: <014f01d3d88f$9bf4a1e0$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/wHQjZuJnh7asJvpE1nIovPDnESM>
Subject: Re: [Netconf] subscribed-notifications-12
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: Fri, 20 Apr 2018 17:24:04 -0000

Hi Tom,

> From: t.petch, April 20, 2018 6:09 AM
> 
> Eric
> 
> OK so far.
> 
> I am puzzled by the features for encoding.
> 
> I can see four cases for a publisher; no features, encode-xml and encode-json,
> encode-xml only, encode-json only.
> 
> The first case seems clear; the stream uses the encoding of the subscription.
> 
> The second also seems clear; the subscriber can choose either encoding.
>
> The third and the fourth puzzle me.  If only encode-xml is present, and the
> subscription is in xml, then the stream will be in xml, whether or not the
> encoding is specified.  If the subscription is in json, and the encoding is not
> specified, then the stream will be in json.  If the subscription is in json and the
> encoding is specified as xml, then the stream will be in xml.
> 
> If only encode-json is present, then it is vice versa, mutatis mutandis.
> 
> I find this an odd combination to specificy.

The ability to specify a particular encoding also is a function of  valid combinations of transport+encoding.  Independently of subscription, this general issue was recently articulated by Juergen:
https://www.ietf.org/mail-archive/web/netconf/current/msg14395.html 

To handle this in subscribed-notifications, a subscription is unable to select an encoding when alternative encodings are not supported on a selected transport.  The solution to this was proposed by Martin in:
https://www.ietf.org/mail-archive/web/netconf/current/msg14402.html
(search for "configurable-encoding")

So here are the specifics:

    leaf encoding {
      when 'derived-from(../transport, "sn:configurable-encoding")';
          ...
    }

This means that leaf encoding can only be set when the transport allows for configurable encodings.  So getting back to your third and fourth cases, the transport identity "netconf" does not have "configurable-encoding"*.  So these cases are explicitly not allowed for NETCONF.   Where there are transports where multiple encodings are possible (how often we will see this is TBD), we add a new error identity to the transport specific YANG model stating that this encoding is not available.

* To see the "netconf" identity, go to the YANG model in draft-ietf-netconf-netconf-event-notifications:
https://github.com/netconf-wg/notif-netconf/blob/master/draft-ietf-netconf-netconf-event-notifications-09.txt 
(the only reason this version isn't posted yet is that it is pending Einar's script tests on the appendix examples.)

Thanks,
Eric


> Tom Petch
> 
> ----- Original Message -----
> From: "Eric Voit (evoit)" <evoit@cisco.com>
> To: "t.petch" <ietfc@btconnect.com>
> Sent: Thursday, April 19, 2018 3:48 PM
> 
> 
> > Hi Tom,
> >
> > Thanks for the review.  You can see the updated draft at:
> >
> https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-
> subscribed-notifications-13.txt
> >
> > Some details inline...
> >
> > > -----Original Message-----
> > > From: t.petch, April 19, 2018 7:42 AM
> > > To: Eric Voit (evoit) <evoit@cisco.com>om>; Kent Watsen
> <kwatsen@juniper.net>et>;
> > > Alexander Clemm <ludwig@clemm.org>rg>; netconf@ietf.org
> > > Subject: subscribed-notifications-12
> > >
> > > Eric
> > >
> > > I see some quirks in this I-D that I think need fixing
> > >
> > > It lacks a note to the RFC Editor asking that XXXX be replaced with
> the number
> > > assigned to the I-D
> >
> > Placed this at the front of the section leading in to the YANG model
> >
> > > It lacks a note to the RFC Editor asking that the two dates in the
> YANG module
> > > be replaced with the date of publication
> >
> > Placed this at the front of the section leading in to the YANG model
> >
> > > I see no Copyright in the YANG module
> > >
> > > The YANG module references
> > >
> > > 6991
> > > 7223  (which is  superseded)
> > > 7951
> > > 7540
> > > none of which I see in the References of the I-D
> >
> > Fixed.
> >
> > > Good practice is to have a section just before the YANG module
> itself which
> > > lists the documents from whiuch imports are made or to which
> references are
> > > made (if you simply add RFC6991 as a Reference, you will get an
> unused
> > > Reference error).  See, for example, RFC8344
> >
> > Done.
> >
> > > There are a number of Informative References which I think should be
> > > Normative namely
> > > 8040
> >
> > Done.  Agree this should be Normative based on the use of yang-data.
> >
> > > 5246
> >
> > Done.
> >
> > > 6241
> >
> > Done
> >
> > > 6242
> >
> > Done
> >
> > > 7950
> >
> > I believe this one is an informative reference.  I.e., the reference
> in the YANG model is to an example of analogous behavior from HTTP2.  My
> reading of rfc7950 section 7.21.4 doesn't seem to require a reference to be
> normative.  If it does, I can move the information into the description.
> >
> > Thanks again,
> > Eric
> >
> >
> > > Tom Petch
> >
> >