Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver (was RE: mbj's WGLC comments on subscribed-notifications-10)

"Eric Voit (evoit)" <evoit@cisco.com> Mon, 16 April 2018 21:14 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 9522E12895E for <netconf@ietfa.amsl.com>; Mon, 16 Apr 2018 14:14:57 -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_MED=-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 NFjaUM0LGuhD for <netconf@ietfa.amsl.com>; Mon, 16 Apr 2018 14:14:55 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E624E127010 for <netconf@ietf.org>; Mon, 16 Apr 2018 14:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7014; q=dns/txt; s=iport; t=1523913294; x=1525122894; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OLqADTlTEi/mr9zHxhIzOMeheKzmGk3QMsVCnw0gcqU=; b=Iu3Nt1ivBmaCvC1MsKu66DVeaPgbNr83kJdVvLWEyrBeeN/U+gEHsUgY /sz+veoPGlvxN7nj6VoOy3FSJqGhCkOZ4OeE6O3bnbLjxlNDmb/scNlTN YkMyZtNKqE3lg2sPLASFupKxIVlfMiF1NS8nfkv8cQw5LgcV+LuUeduqy w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgDoEdVa/5BdJa1UCRsBAQEBAwE?= =?us-ascii?q?BAQkBAQGDQmF6KAqLX40UgXSBD5JogXsLGA2EE0sCgkQhNBgBAgEBAQEBAQJ?= =?us-ascii?q?sHAyFIgEBAQECAQEBODQJBwsCAQgOAwQBAQENEQULJwsdCAIEARIIE4RqCA+?= =?us-ascii?q?oEohBgiAFiAaBVD+BD4MLgUGBUAEBAgEBFoEcFIVqAocuhFaLYAgChVeCHDS?= =?us-ascii?q?GCoE7g1yHPIkshkwCERMBgSQBHDiBUnAVO4JDgiAXEYIWgR6FFIU+b40UgRc?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.48,460,1517875200"; d="scan'208";a="382097674"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2018 21:14:53 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w3GLErv4013235 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Apr 2018 21:14:53 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; Mon, 16 Apr 2018 17:14:51 -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; Mon, 16 Apr 2018 17:14:51 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: 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: AQHT1cf1tFrkEoX4+UOe3DZL/G+0+w==
Date: Mon, 16 Apr 2018 21:14:51 +0000
Message-ID: <3f91777ee1b945a7a770d2fcf9b9d0af@XCH-RTP-013.cisco.com>
References: <d510ae4b5a8548c096229819f92b04d9@XCH-RTP-013.cisco.com>
In-Reply-To: <d510ae4b5a8548c096229819f92b04d9@XCH-RTP-013.cisco.com>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/PddwhggLE3z4dWEkpe4zqkPdlAM>
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: Mon, 16 Apr 2018 21:14:58 -0000

> 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://youtu.be/KJtg-J-6CZM?t=27m39s
> 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://github.com/netconf-wg/notif-netconf/blob/master/draft-ietf-
> 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://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications 

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://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-
> > 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://www.ietf.org/mailman/listinfo/netconf