Re: [Netconf] Opinion poll on RESTCONF encoding

Kent Watsen <kwatsen@juniper.net> Thu, 27 August 2015 01:37 UTC

Return-Path: <kwatsen@juniper.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 79D5D1A6F3C for <netconf@ietfa.amsl.com>; Wed, 26 Aug 2015 18:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, 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 wLB9xDQM7_eu for <netconf@ietfa.amsl.com>; Wed, 26 Aug 2015 18:37:35 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272601B2E33 for <netconf@ietf.org>; Wed, 26 Aug 2015 18:37:34 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.231.21; Thu, 27 Aug 2015 01:37:30 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0256.013; Thu, 27 Aug 2015 01:37:30 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Andy Bierman <andy@yumaworks.com>, Mahesh Jethanandani <mjethanandani@gmail.com>
Thread-Topic: [Netconf] Opinion poll on RESTCONF encoding
Thread-Index: AQHQ4Fu1VDdK2ycC2UOA3lddVeqi4J4e/HeA///RngA=
Date: Thu, 27 Aug 2015 01:37:30 +0000
Message-ID: <D203D804.D372C%kwatsen@juniper.net>
References: <1232641A-BE91-4AAD-962D-779E4D85403A@gmail.com> <CABCOCHRkmHw0oy8-AYyin+YaE8-2aS5fjwAmggx_FUOzd1rg5A@mail.gmail.com>
In-Reply-To: <CABCOCHRkmHw0oy8-AYyin+YaE8-2aS5fjwAmggx_FUOzd1rg5A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:IWaGmJqcwjPby64hlxHZqYbIWpKnOBv0el9J6WKfb+HqO/PVh3qXim7hXc3X2iXpiCz9UtpCJ7yRxBXCi++gRfIKJNvIMvS41BuOzanGP2CfnjbXB9H18gVdQ7kTAXqPaXlY4o8RK6+d74YduW1bMA==; 24:gAQkxvukSSvYhegbwVenS/+IhU1ZGDveGcD2GgCsXHZ9/uh5F/QxCyevIlIYusr5LoAf2WqyBmMSUvxkXRvTDpd+e5HCgdn8gPu+xdko8c4=; 20:yXwdZR890DM9BXSDowpOtvl2eQXHf5NuQXzkMFWlJ6Y9rMfhEuguillr5h/oKBvxWdMrZ+mdR2YS4y+F1EZ8KA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: <CO1PR05MB4601403290DD3BB4CD2A50FA56F0@CO1PR05MB460.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460;
x-forefront-prvs: 06818431B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(87936001)(561944003)(97736004)(5001960100002)(40100003)(101416001)(5001830100001)(189998001)(5007970100001)(5001920100001)(99286002)(5001770100001)(5002640100001)(5004730100002)(36756003)(5001860100001)(106116001)(68736005)(76176999)(102836002)(46102003)(83506001)(2900100001)(50986999)(2950100001)(106356001)(77156002)(66066001)(62966003)(105586002)(92566002)(2656002)(4001350100001)(122556002)(10400500002)(4001540100001)(64706001)(54356999)(16236675004)(81156007)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D203D804D372Ckwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 01:37:30.2779 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: <http://mailarchive.ietf.org/arch/msg/netconf/nVOlIdFMPWVIuN7E3dBnh3W8yC0>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Opinion poll on 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: Thu, 27 Aug 2015 01:37:37 -0000

Separately, a secondary question was raised around how the encoding could be or would be discovered. On that we do not seem to have a consensus. Two proposals that were made are:


  1.  Client sends all supported encodings in Accept request-header, with an (optional) preference indication via quality (q). Server responds with one of the encodings or 406 (not supported). The encoding formats would be limited to a small set - XML and JSON with this option to encourage interoperability.
  2.  Server advertises support of encodings using the ./well-known/host-meta file and XRD.

Please indicate your opinion on the discovery of encoding part of the discussion. This opinion will not change the consensus on the poll of RESTCONF encoding.

We have to do #1.   Proposal #2 is a bonus...one that I'm OK with deferring until after we have more operational experience with RESTCONF.

To recap, #2 was to enable the server to proactively state what it supports, but it only works if encodings are universal, never varying between resources.    Making the most of #1, RESTCONF could state in Section 5.3:

  If no Accept header is present, or if none of the passed Accept
  header media types are supported for the given resource, the
  RESTCONF server MUST generate a payload containing a list of
  available representation characteristics and corresponding
  resource identifiers from which the user or user agent can
  choose the one most appropriate.

This is slightly stricter than the wording in RFC 7231, Section 6.5.6.

My opinion is that, if the client is willing to accept any encoding, it should passed "*/*" as one of the values in its Accept header.  Note, testing 5 browsers just now, they all passed "*/*" in a random GET request.  This is important because we likely want to support this common developer action and have the server respond with something reasonable.

Kent