[Netconf] transport independence (was Re: Opinion poll for the RESTCONF encoding)

Andy Bierman <andy@yumaworks.com> Sat, 15 August 2015 02:47 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C7F1B2BB8 for <netconf@ietfa.amsl.com>; Fri, 14 Aug 2015 19:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 9s6vvyv1f4Vy for <netconf@ietfa.amsl.com>; Fri, 14 Aug 2015 19:47:12 -0700 (PDT)
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 5B0DC1B2BB7 for <netconf@ietf.org>; Fri, 14 Aug 2015 19:47:12 -0700 (PDT)
Received: by labd1 with SMTP id d1so53446503lab.1 for <netconf@ietf.org>; Fri, 14 Aug 2015 19:47:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=7ry/vvp+Z4jMZEvlt8fQVKtHcZof75vePvG8nwY5Cyk=; b=nCT3POrVQxDhuQquhOIXro6Lr2fhadAAFGXwIhB2w/XN9RixtP0KDqUBssuZqA6HdO 9uxTfjA0Of4iYDOFwn0x6cZ6TALUHMgsg8lLsNkIjsGCa1ScPqyvxaByWjtW8AAYsOKF Ahev5gu7n3G4AECh9xvpwDS2elFhDJqkrO6SG9lH17rynmtr2TY3owpYESKJl0p8i3is cZTlqAj59KJRJB09razgxRTZ5gBDsbHxWBCHLF7bve/8GNgLpBithjuv0RPdAqgS3WcY xI35hllZ2ZI153Pi/FeR90O3h2Tq836pyGd2AKyBCvMLb76kK4jFoNGObeII7nIPDupf jb8Q==
X-Gm-Message-State: ALoCoQlbQrXKTBJMaQH8M5gnkx1882Zsov4vOUkOdG3V0chdU6vE8KZKvtoJKN2FqhD5kLgHlk69
MIME-Version: 1.0
X-Received: by 10.112.161.232 with SMTP id xv8mr944639lbb.123.1439606830818; Fri, 14 Aug 2015 19:47:10 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Fri, 14 Aug 2015 19:47:10 -0700 (PDT)
Date: Fri, 14 Aug 2015 19:47:10 -0700
Message-ID: <CABCOCHRV10LQmr8akiH+heWSsHLjQ9RGngTtn6+9R-aLyWWXGw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Robert Wilton <rwilton@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c3c46cc48292051d509506"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netconf/o8MzgUZP6pN5c_02axT47_u3TpI>
Cc: Netconf <netconf@ietf.org>
Subject: [Netconf] transport independence (was Re: Opinion poll for the RESTCONF encoding)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 15 Aug 2015 02:47:16 -0000

Hi,

IMO it is a mistake to couple NETCONF or RESTCONF conformance
to the mandatory transport (and message encoding).

For RESTCONF, there should be a capability URI defined for
restconf:1.0 that should be returned by the server.  This just refers to
the protocol operations and data models, not the transport.
RESTCONF over CoAP (or something else) could identify
its functionality with this URI as well.

For NETCONF, there should really be "base:1.1" and "ssh:1.1" capabilities.
The RFC can still make both mandatory.  IMO "base" should not
also imply "ssh".


Andy

On Fri, Aug 14, 2015 at 7:33 PM, Andy Bierman <andy@yumaworks.com> wrote:

> Hi,
>
> I did not say the CORE WG is going to standardize RESTCONF over CoAP.
> Their charter is being reviewed now. My preference is to keep CoMI as
> lightweight as possible.
>
> A RESTCONF-over-CoAP server would be non-standard.
> IMO it is not unreasonable to expect the server to support JSON
> to work with RESTCONF clients, to claim RESTCONF conformance.
>
> If there was a standard mapping of RESTCONF to CoAP,
> then the server would claim conformance to that RFC, not RESTCONF.
>
>
> Andy
>
>
> On Fri, Aug 14, 2015 at 4:17 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
>>
>> On 13/08/2015 20:03, Kent Watsen wrote:
>>
>>
>> I almost voted "nm" before for this reason and, with the recent info
>> about 406 including supported encodings, I'm now even more open to the
>> idea...
>>
>> I guess that I'm not convinced that either XML or JSON will necessarily
>> end up as the prevalent encoding longer term, I think that one of the more
>> efficient binary encodings will eventually win out.
>>
>> But if RESTCONF mandates XML or JSON now then it seems fairly unlikely
>> that this requirement will be dropped any time in the near future because
>> nobody likes to break backwards compatibility.
>>
>>
>> My only reservation is that I'm torn if interoperability is better
>> achieved by mandate or market forces.
>>
>> Yes, I can emphasise with that view.
>>
>>  If it is outrageously onerous, the CoMI folks can always define
>> "COMICONF" that is a one-line diff to RESTCONF  ;)
>>
>> At the end of the day, I'm also OK with x+j, but felt that nm was
>> slightly better.
>>
>> I guess that what I have proposed really sits between x+j and nm, given
>> that it is weaker than x+j but stronger than nm (i.e. RECOMMENDED rather
>> than OPTIONAL).
>>
>> Thanks,
>> Rob
>>
>>
>>
>> Kent
>>
>> From: Robert Wilton <rwilton@cisco.com>
>> Date: Thursday, August 13, 2015 at 5:31 AM
>> To: " <netconf@ietf.org>netconf@ietf.org" <netconf@ietf.org>
>> Subject: Re: [Netconf] Opinion poll for the RESTCONF encoding
>>
>> I seem to be swimming against the tide, but my vote is for nm.
>>
>> More precisely, I would write "A server SHOULD support either XML or JSON
>> encoding.  For maximum interoperability it is RECOMMENDED that both client
>> and servers support both XML and JSON".
>>
>> Justification: Don't cause a server to be non compliant with RESTCONF if
>> they have a specific reason for requiring a different encoding.
>>
>> As for the client/server compatibility issue - I think that market forces
>> will mean that this isn't an issue in practice.
>>
>> Thanks,
>> Rob
>>
>>
>> On 06/08/2015 21:18, Ersue, Mehmet (Nokia - DE/Munich) wrote:
>>
>> Dear NETCONF WG,
>>
>> last October we had an opinion poll on the RESTCONF encoding, which ended
>> with a close consensus in favor of XML as mandatory.
>> See
>> *https://mailarchive.ietf.org/arch/msg/netconf/YSEbLd-nnI0dlkeiIeGW-z6JqDg*
>> <https://mailarchive.ietf.org/arch/msg/netconf/YSEbLd-nnI0dlkeiIeGW-z6JqDg>
>> Based on the recent discussion on this topic and opinions against
>> mandatory statements in RESTCONF, NETCONF WG co-chairs would like to start
>> a new opinion poll.
>>
>> As stated in the mail for the previous poll, the result of the poll
>> depends on the count of people voting.
>> So, all interested NETCONF WG members, please speak up so that we get a
>> better data to judge on WG (rough) consensus.
>> If the voting result is again close, the WG co-chairs will (again)
>> declare consensus in the sake of progress, based on the “dominant view”
>> determined by the co-chairs and AD.
>>
>> Please do state your opinion with short and concrete reasoning, by August
>> 19, 2015 18:00 PST about the following options:
>>
>> x) XML is mandatory, JSON optional,
>> j) JSON is mandatory, XML optional,
>> x&j) XML and JSON are both mandatory,
>> x+j) Either XML or JSON is mandatory the other one is optional,
>> nm) Both XML and JSON are optional and _*not*_ mandatory.
>>
>> For “x+j” and “nm” please provide a solution for a successful negotiation
>> or determination of the encoding to be used between server and client.
>> For the solution discussion a separate thread will be started and can be
>> finalized also after the poll deadline.
>>
>> You may think that one or the other option is useless from your pov. In
>> this case please ignore it.
>>
>> Looking forward to counting your votes and reading your reasoning.
>> Thank you.
>>
>> Best Regards,
>> Mehmet & Mahesh
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>