Re: [Netconf] netconf-binary-encoding comments

Andy Bierman <andy@yumaworks.com> Fri, 06 July 2018 15:59 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 16D3013104A for <netconf@ietfa.amsl.com>; Fri, 6 Jul 2018 08:59:28 -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 9swE2n5y9bFf for <netconf@ietfa.amsl.com>; Fri, 6 Jul 2018 08:59:25 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 8189A131093 for <netconf@ietf.org>; Fri, 6 Jul 2018 08:59:24 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id m12-v6so10184070lfc.10 for <netconf@ietf.org>; Fri, 06 Jul 2018 08:59:24 -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=n+BOcv5/l3HUcC8fEUnIpeHmg7yjBbAnW0mAMOpgoks=; b=FBsFUkUkDOKnsdEDtQB2bj8CykjCHaq5MDEDiWWE2K/KJlzJ5S3uGIUoH1iCpVQIOo TEWgqm8dWwDSW+P1f8M71Uxupog6bS+mMT4nBUraTdksqoMiZaftWaHK+uS6T+MO7SL5 417aXKRwnjmmUa3tOjED2THYFpiaUdH3dO/8oRL8mbbGokcryTL/J2xOo17FdUdODRVG sbLlYyK4YZqgLbSNuH/bITQ+KHx+SjkYHu2og27ea5d3QgdqCTljhacWd33ltCZ+MIlL s61dcyDupguMq/keelmiOgVvavRrvXje9kpc9WC4EIZTARiYBx4UAGfuYmaQA/t3xkHr iWTA==
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=n+BOcv5/l3HUcC8fEUnIpeHmg7yjBbAnW0mAMOpgoks=; b=htIAvw8h6L6sBlS4a1CxGGSL3UZ1toEX2ixHghLrQ55Q4XmOEBu5O//0pThiSffOzb v7Dh/IQW3Vr746tvbW3h0DzXcY0t6Y5XVxxrc87uWPtntB5nlMDSMFfeaCVOtAk7zObS hq7JpXj97LMbueBY6IMX2n3TcPjmXeVTqPdJ0MbYGlYumi9DscXOr4S2iyX8MEpWzapA jtf/v974ThhmSh7/V0lnXx/3bJ6Blpsqt+4m80EObXNHOJrfD3kkkW4tlzxkLaDxZB6c b8ArG3eW4Oh0P8wBCVeQKQhkP+NxKLPhImA5LHWCGjh4IC9ywtpzK+J7MUbp5ci8pWOH L47A==
X-Gm-Message-State: APt69E1facGcZX+R3AVdE366pN+kZQb69JpWS59ByDYcFyisV2PnVz+T JuzyLDP5OKIOcwoW+gHWDiiKstqKAeFL+RISUBFVoA==
X-Google-Smtp-Source: AAOMgpd8Vbcmn9eU7UVFDEeDkMaqAqD+1CyYmEHgarnJjyy1w6Hnmmok2yZZ+cuMKw56FeTngEM3q6KgnDrkwIkB/TQ=
X-Received: by 2002:a19:e1cc:: with SMTP id l73-v6mr8201987lfk.102.1530892762728; Fri, 06 Jul 2018 08:59:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 08:59:21 -0700 (PDT)
In-Reply-To: <79d3af9b-dd0c-833b-491f-a25a54a38559@cisco.com>
References: <14395e68-eb71-7766-d4d2-4de0ea67681f@ericsson.com> <CABCOCHRJM5vTgTXcNircjcn6DCqK5fzW3E2rjMM6sb3A3Edz_g@mail.gmail.com> <79d3af9b-dd0c-833b-491f-a25a54a38559@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 06 Jul 2018 08:59:21 -0700
Message-ID: <CABCOCHQfwND7uezS_ykQ4G-v_JPNqTx0Pw3hJVqTVB83XqJgzw@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Balazs Lengyel <balazs.lengyel@ericsson.com>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004fde1f057056bfe7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/8v4C7_JpxUUBxR_nPOaUOp6JjMM>
Subject: Re: [Netconf] netconf-binary-encoding comments
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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, 06 Jul 2018 15:59:29 -0000

On Fri, Jul 6, 2018 at 2:17 AM, Robert Wilton <rwilton@cisco.com> wrote:

>
>
> On 05/07/2018 17:07, Andy Bierman wrote:
>
> Hi,
>
> I think the first-order issue is for the WG to decide if there is a
> problem to be
> solved by this WG, and if so, what is the problem scope.
>
> +1.
>
> I actually wonder whether extending RESTCONF wouldn't be a more efficient
> path here.  Adding support for CBOR to RESTCONF looks like it would be much
> easier than adding it to NETCONF.
>

of course, because HTTP already supports content-type negotiation.
There is nothing to add to RESTCONF.
You can use other media types than XML or JSON now.



> But then, it is unclear to me what the long term relationship between
> NETCONF and RESTCONF is meant to be.
>
>
Maybe "let the market decide" and not worry about it too much in the IETF



> Thanks,
> Rob
>
>

Andy


>
>
> Details like the SID assignments for rpc, rpc-reply, etc do not really
> impact that decision.
>
> When I brought up this issue 5 years ago there was zero interest in
> improving the
> efficiency of NETCONF. Maybe YANG Push will change that POV.
>
> https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-00
>
> I think this draft should focus on the protocol mechanisms and not define
> any media types. Definitions of GPB and other formats are not trivial and
> need
> their own RFCs.
>
>
> Andy
>
>
> On Thu, Jul 5, 2018 at 8:07 AM, Balazs Lengyel <
> balazs.lengyel@ericsson.com> wrote:
>
>> Hello,
>> Is this applicable for Restconf? Would a Restconf binary encoding be
>> interesting?
>>
>> Chapter 2)
>>
>> - A more detailed explanation of which parts are encoded would be good.
>> What is the top XML element that will be encoded? <rpc>, <RPC-reply>,
>> <RPC-error>, <notification> ? Just referencing a figure in another draft is
>> not enough.
>>
>> - SHOULD, SHALL or SHALL NOT a client server declare support for the XML
>> encoding? Is that always implicit? State it.
>>
>> 4.2) Shouldn't we also have a JSON encoding here?
>>
>> I would think that all encodings need some official reference, defining
>> how they are used with YANG: RFC, web link
>>
>> Is the Thrift and gpb encoding trivial or is it described somewhere or do
>> we need an RFC about it? Please state whichever is the case.
>>
>> regards Balazs
>>
>>
>>
>>
>>
>> --
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> Mobile: +36-70-330-7909              email: Balazs..Lengyel@ericsson.com
>> <Balazs.Lengyel@ericsson.com>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
>
>
> _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>
>