IETF Logo Mail Archive

[Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity

"Bert Wijnen (IETF)" <bertietf@bwijnen.net> Tue, 02 September 2014 10:23 UTC

Return-Path: <bertietf@bwijnen.net>
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 9A2471A872A for <netconf@ietfa.amsl.com>; Tue, 2 Sep 2014 03:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 xEVVJu4sBYHw for <netconf@ietfa.amsl.com>; Tue, 2 Sep 2014 03:23:41 -0700 (PDT)
Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329FE1A8724 for <netconf@ietf.org>; Tue, 2 Sep 2014 03:23:41 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1XOlFR-00046z-Qf for netconf@ietf.org; Tue, 02 Sep 2014 12:23:38 +0200
Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest108.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1XOlFR-0002HI-NP for netconf@ietf.org; Tue, 02 Sep 2014 12:23:37 +0200
Message-ID: <54059AA9.4080902@bwijnen.net>
Date: Tue, 02 Sep 2014 12:23:37 +0200
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Netconf <netconf@ietf.org>
References: <CABCOCHSt3K4O+9w2bDqq0-OvGZP0JcdnfH8_VHMeZ6umv3pJUA@mail.gmail.com> <53FCA5B7.3030105@cisco.com> <CABCOCHRFhK4h_M2NFX16iHRDCcYgj6kXpO11K2k=Zthod8+kUg@mail.gmail.com> <20140826.223423.176169295.mbj@tail-f.com> <CABCOCHSiYmbYY6SN=jCnkz9UFY6FZA_zEegxErX_fP+gmpET+w@mail.gmail.com>
In-Reply-To: <CABCOCHSiYmbYY6SN=jCnkz9UFY6FZA_zEegxErX_fP+gmpET+w@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41e733cf7edb4856cd60a74be5db18f3f
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2V5cNlyeEpK_zhakP7CI3f3iFnQ
Subject: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity
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: <http://www.ietf.org/mail-archive/web/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, 02 Sep 2014 10:23:42 -0000

On 26/08/14 22:49, Andy Bierman wrote:
>
> Perhaps the co-chairs should decide how to proceed somehow.

Dear NETCONF WG participants, do you have an opinion?

So far I have seen only a few people express their opinion.

Please speak up so that we (WG chairs) have better data to judge if we
do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014.

Please speak your mind about these options:

a) XML is mandatory
b) JSON is mandatory
c) XML and JSON are both mandatory
d) Both XML and JSON mandatory on client,
    server can implement whatever it chooses.
    Not clear yet how the client would find out, but that would of course
    be something to be worked out if we choose this option

Bert

v2.23.0 | Report a Bug | By Email