Re: [Netconf] Anyone want just Configured Subscriptions?

Andy Bierman <andy@yumaworks.com> Tue, 10 July 2018 16:28 UTC

Return-Path: <andy@yumaworks.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 2FFA1126DBF for <netconf@ietfa.amsl.com>; Tue, 10 Jul 2018 09:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 asqPc_1D95NG for <netconf@ietfa.amsl.com>; Tue, 10 Jul 2018 09:28:22 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4099B126CC7 for <netconf@ietf.org>; Tue, 10 Jul 2018 09:28:22 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id u7-v6so14570060lji.3 for <netconf@ietf.org>; Tue, 10 Jul 2018 09:28:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vX9erFhtfcXjseHkaOgp10FdBNpE3LIwFa/B/Ldfx/s=; b=Ey8SeKoAkRSfv9og7EEm8GHXcSeqAyoJWYRxvsDIijXJTCIc0umeYepMSCFwC0ZjYJ 5J/fHj4m1X9bgQjVShW1q6diDG+rEjVSwEJ19QgU1qUiESjYsy/FJhu5SzsXkpObOJ/o zsstBn83UI0gcQAnBENKjmRf2rU1jTbR1z6hwOA/uMVCM015XPY/ml3rHpw40oDieeOy nvKOAjsDXIoRo5EUuRwc0ieITxQ5jdZY8gi26jO5TlbcxFiwwLE5qkOJSKKFvY1Ifi2i +uFIgIBZyg1UgvNh8IXSVfKcpUR7zs07H87uf6p4Y5h6xRMRWhjXtZZaJQ4wauHov4CD 6Sow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vX9erFhtfcXjseHkaOgp10FdBNpE3LIwFa/B/Ldfx/s=; b=MYhoMmh465c9I/UnEviLc13ovOh+Jru/jZAjl8w2mIfEoNw1augTpz5cPddLChweXg VhtFbux8GkfpWS4UtZjKMtgrSptxr6I1F9VtmjYTWpGICGA/oZlwJv4+0EAu3XgKr61y atqpFFVbL+0VOzHQy59Ge7wCi/g1/oj2RvbFkljfY4hC2UbLe/aRReUmndcFWdYLh0Of uBJEsALv8AEsYWu+Kd9qUaGvOUAYK15TJk6bNPWQMZyuHUPIsgr3HNly2Sa8UxW08WeH xziyCCMNAGYhAc06WH9AdYVvxcgKe6/2Ny2oMJfOO4QV/+4UiVqmOh//RWoBDHpamjzp 5Hxg==
X-Gm-Message-State: AOUpUlGYMcB8Vd39NNc7qQwdEMT4nG9kikDeUF8M4fzr7rNpKaUjySSf pRetfORTuSF5JTPclEna5QMxoxR2HSaN2rJMGf0RYQ==
X-Google-Smtp-Source: AAOMgpes9g0e5bfZbKxJBUw3GuYotI7dDQZiIcqYA6DpcK42NO7PVeZ4HV5xq6JjzAbRQ+LKzaGIQ/4QIlMyzNGBFuI=
X-Received: by 2002:a2e:3611:: with SMTP id d17-v6mr7259616lja.31.1531240100405; Tue, 10 Jul 2018 09:28:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 09:28:19 -0700 (PDT)
In-Reply-To: <273f987e3a224411a01a599afb42f25f@XCH-RTP-013.cisco.com>
References: <CABCOCHSfzpj3Kca2RRtNFV6wLLt_6r4p3vfS_j4Hzfai-0Y2gA@mail.gmail.com> <20180708.095807.918450792556408986.mbj@tail-f.com> <20180708100310.gn3xaol66f7c7lo5@anna.jacobs.jacobs-university.de> <20180708.180552.1582913595227099806.mbj@tail-f.com> <CABCOCHQfirYPAVJwLELnqw0VJ=js7aFNX9wB7Xcs6Tkw06w1hw@mail.gmail.com> <9c3799f19cf84b22a3659c04a548ba67@XCH-RTP-013.cisco.com> <CABCOCHT=7-dPzTPYLvVN1J12uwGWh9GoA7r5nu=zYYD1nnFwTQ@mail.gmail.com> <273f987e3a224411a01a599afb42f25f@XCH-RTP-013.cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 10 Jul 2018 09:28:19 -0700
Message-ID: <CABCOCHTF_CHXH68f46mWa1G7LEZzQ8z9m7c+vS8-rq4Ngtc+gQ@mail.gmail.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000040431b0570a79ee0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/fXuZ5yC5ECW1bBSDJVilv7YQH-w>
Subject: Re: [Netconf] Anyone want just Configured Subscriptions?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 10 Jul 2018 16:28:25 -0000

On Tue, Jul 10, 2018 at 8:57 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:

>
>
>
>
> *From:* Andy Bierman, July 9, 2018 11:07 PM
> *...*
>
>
>
> On Sun, Jul 8, 2018 at 8:05 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:
>
> Hi Andy,
>
>
>
> *From:* Andy Bierman, July 8, 2018 12:26 PM
>
> On Sun, Jul 8, 2018 at 9:05 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > On Sun, Jul 08, 2018 at 09:58:07AM +0200, Martin Bjorklund wrote:
> > > Andy Bierman <andy@yumaworks.com> wrote:
> > > >
> > > > You mean <start-all-configured-subscriptions> I think.
> > >
> > > Yes.
> > >
> >
> > If you do this, why does the client, after receiving a call home, not
> > simply create dynamic subscriptions? ;-)
>
> Well, the configured subscription is needed anyway in order for the
> device to call home, so having the client create all configured
> subscriptions as dynamic subscriptions as well doesn't seem quite
> right.
>
>
>
> It is quite possible that multiple RPC operations are needed to get the
> session
>
> started, such as reading the YANG library, and that the client
>
> is not ready to receive notifications as soon as the session is started.
>
> So an <activate-configured-sessions> operation may help.
>
>
>
>
>
> But if the WG agrees that it is ok to send <notification> directly,
> this issue goes away.
>
>
>
> Sitting idle is definitely OK.
>
> Accepting notifications right away is OK as an implementation feature
>
> outside the standard.
>
>
>
> <Eric> If the NETCONF-Notif says that the NETCONF client for a configured
> subscription must be able to handle accepting notifications right away, do
> you see any standardization issue with this behavior in this context?
>
>
>
>
>
> Actually, I think there are issues with configured subscriptions wrt/
> CallHome because
>
> of the text in RFC 8071, 1.3:
>
>
>
> https://tools.ietf.org/html/rfc8071#section-1.3
>
>
>
> The transport and encoding leafs are identityrefs, which means the
> possible values
>
> are unknown and unbounded.
>
>
>
> Do all possible values (including vendor values, which are valid for the
> YANG leaf)
>
> change the protocol enough so separate security analysis are required?
>
> I think a SecDir review may raise concerns wrt/ this issue.
>
>
>
> <Eric> For any IETF defined transport, a “Transport-Notif” draft
> definitely needs to address any issues with Call Home or other such
> mechanism.  At next IETF, perhaps we will see if this can await concurrent
> resolution with the NETCONF client/server work.
>
>
>
> For configured subscriptions with a vendor specified transport identity,
> it would be great to see SecDir sees any issues.  I don’t see anything off
> hand (as it is a vendor transport), but I certainly don’t claim all their
> perspectives.
>
>
>

I think all identityref objects need to document the conformance
requirements as detailed
as the WG can agree on. For this draft:

 1) what values of "transport" MUST/SHOULD be implemented by all servers
that
     advertise the "configured" feature?
 2) what values of "transport" MUST/SHOULD be implemented if CallHome is
used?
 3) Are there any "encoding" value restrictions if CallHome is used?
     Text about XML required, JSON optional exists, but is JSON allowed in
NETCONF?
     Is binary allowed in NETCONF? IMO this is OK if both peers opt-in to
the selected encoding
    (and modify the NETCONF contract)



Eric
>


Andy



>
>
> Eric
>
>
> /martin
>
>
>
> Andy
>
>
>
>
>
> Andy
>
>
>