Re: [netmod] WG adoption poll
Robert Wilton <rwilton@cisco.com> Tue, 09 October 2018 11:19 UTC
Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDBD1312D3; Tue, 9 Oct 2018 04:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.956
X-Spam-Level:
X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 aKUmrHmumnYA; Tue, 9 Oct 2018 04:19:54 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFFD1312BB; Tue, 9 Oct 2018 04:19:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2821; q=dns/txt; s=iport; t=1539083994; x=1540293594; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=90BvInPbtdtZGWZoTtZqRiwvvxFEQp+CLmShYjgsjqI=; b=AG+LGZEROkOgIfYI4q2D/C3Py8I/w8anbY2VZCdXDg9mBA1yw5w1mHVd Bqk8IvdAEf5wdPL/E5P7JnFmazlIPsEXPrG5TiutDQpVPhH2aYe+UOeY6 0ydx+dwRGvnWa2NpktDMDFxPSDc4ulkmSab8xWSLMJY0OVMbLHRQZRida A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A9AABhjbxb/xbLJq1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBZYJsfyiDdYh0jWCXA4FmDRgLhANGAoRpOBYBAwEBAgEBAm0cDIU6AQEBAwEBIQ8BBTYLEAsOCgICJgICJzAGAQwGAgEBgx0BggEPo3+BLoR3hR4FgQuKRYFBP4ESJ4JrgxsBAYEuARIBCYMXglcCnXYJiSeHHQYXgU6EZ4JoJoY8j0mGLoFZIWRxMxoIGxU7gmyLF4U/PjCKFII+AQE
X-IronPort-AV: E=Sophos;i="5.54,360,1534809600"; d="scan'208";a="7047681"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 11:19:51 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w99BJpoY026452; Tue, 9 Oct 2018 11:19:51 GMT
To: Martin Bjorklund <mbj@tail-f.com>, lberger@labn.net
Cc: netmod-chairs@ietf.org, netmod@ietf.org
References: <b8f163ea-ea33-53a6-3fac-944b8d6c03ec@labn.net> <20181009.125822.1764836266889190398.mbj@tail-f.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <5b4af910-5bdd-2cb6-64fb-d19977004ab1@cisco.com>
Date: Tue, 09 Oct 2018 12:19:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181009.125822.1764836266889190398.mbj@tail-f.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NqmIfYGz_rKoaJckhz_dxn6EJfI>
Subject: Re: [netmod] WG adoption poll
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2018 11:19:56 -0000
+1 to Martin's comments. I think that I made similar comments at the mic at IETF 102. I strongly support the idea of documenting YANG instance data. If the WG timing works out I would like this to cover CBOR as well. I also strongly support the idea of documenting server capabilities. But I'm opposed to conflating these two separate concerns in the same draft. I also think that that there should be a optional mechanism to embed the list of module revisions (and perhaps features) that are required to correctly decode the instance data. E.g., the example in section 3 contains YANG library data, but I don't know which version or YANG library I need to read in the instance data. It might have been constructed assuming the format from RFC 7895, or it might have been constructed using the format from YANG library bis, which could easily fail if my tool attempts to interpret the instance data against the schema in RFC 7895. So I think that this information is critical for tools to be able to interpret the instance data in a reliable fashion. Thanks, Rob On 09/10/2018 11:58, Martin Bjorklund wrote: > Hi, > > I still think that this draft should either be split into two, one for > specifiying the generic file format (ok with examples), and one for > "Documenting Server Capabilities", or the document should just be > about the file format (+ *examples*). > > [The current document mixes the two; it's a bit as if we had "The > YANG language and a model for interfaces" as one doc...] > > It is clear that the document specifies a file format for YANG > instance data, which is good. But it is not clear if the document > intends to specify how a server should document its capabilities. > > The Introduction mainly talks about why it is important to document > server capabilities. But then AFAICT there is no normative > specification of how a server would document its capabilities. > > > /martin > > > Lou Berger <lberger@labn.net> wrote: >> All, >> >> This is start of a two week poll on making >> draft-lengyel-netmod-yang-instance-data-04 a working group >> document. Please send email to the list indicating "yes/support" or >> "no/do not support". If indicating no, please state your reservations >> with the document. If yes, please also feel free to provide comments >> you'd like to see addressed once the document is a WG document. >> >> The poll ends Oct 22. >> >> Thanks, >> >> Lou (and co-chairs) >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . >
- [netmod] WG adoption poll Lou Berger
- Re: [netmod] WG adoption poll Alexander Clemm
- Re: [netmod] WG adoption poll Xufeng Liu
- Re: [netmod] WG adoption poll Tianran Zhou
- Re: [netmod] WG adoption poll Qin Wu
- Re: [netmod] WG adoption poll - draft-lengyel-net… Balázs Lengyel
- Re: [netmod] WG adoption poll Ladislav Lhotka
- Re: [netmod] WG adoption poll Martin Bjorklund
- Re: [netmod] WG adoption poll Robert Wilton
- Re: [netmod] WG adoption poll Ladislav Lhotka
- Re: [netmod] WG adoption poll - instance-data Balázs Lengyel
- Re: [netmod] WG adoption poll Joe Clarke
- Re: [netmod] WG adoption poll - instance-data Martin Bjorklund
- Re: [netmod] WG adoption poll - instance-data Balázs Lengyel
- Re: [netmod] WG adoption poll - instance-data Robert Wilton
- Re: [netmod] WG adoption poll Reshad Rahman (rrahman)
- Re: [netmod] WG adoption poll Susan Hares
- Re: [netmod] WG adoption poll - instance-data Kent Watsen
- Re: [netmod] WG adoption poll - instance-data Juergen Schoenwaelder
- Re: [netmod] WG adoption poll - instance-data Balazs Lengyel
- [netmod] Server Capabilities [was: Re: WG adoptio… Balázs Lengyel
- Re: [netmod] WG adoption poll (draft-lengyel-netm… Lou Berger