Re: [Lime] split draft-kumar-lime-yang-connectionless-oam into two - one on data and one on methods/rpc?

"Srihari Raghavan (srihari)" <srihari@cisco.com> Thu, 21 July 2016 14:14 UTC

Return-Path: <srihari@cisco.com>
X-Original-To: lime@ietfa.amsl.com
Delivered-To: lime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D9512D5B2 for <lime@ietfa.amsl.com>; Thu, 21 Jul 2016 07:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.787
X-Spam-Level:
X-Spam-Status: No, score=-15.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 7YggukOAM5Ih for <lime@ietfa.amsl.com>; Thu, 21 Jul 2016 07:14:07 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCF412D5FC for <lime@ietf.org>; Thu, 21 Jul 2016 07:13:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18549; q=dns/txt; s=iport; t=1469110431; x=1470320031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L3E7UubbF59vlCjyfZNyTevMILginX+7jybgn5MJbtY=; b=DBnN8nfeHAZZszGXOCjNvreEhGrU6shoJGl5rJ3R9aZ4SdCcdEJNCga0 576cylXkmxBfliHFCmsJT6AycfzVRvhCfF4g5x8UQTowPwGEUeTNh8QMj S35gJwXgejunFgM8sqT7wOQ6F2qg8cOObeT4cImRSOtqFaMOai3h61T6z M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BDAgBF2JBX/5pdJa1dgnFOVnwGrESMHIF7IoV4AoEtOBQBAQEBAQEBZSeEXAEBBQEBK0ELEAIBCA4DAwECJAQHIQYLFAkIAQEEAQ0FiBYDFw65AA2DdQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFineCQ4IdhTsFjkWKLTQBjEaCJI86iCaHegEeNoI+gTVuhk9/AQEB
X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208,217";a="131979059"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 14:13:50 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6LEDoBX008263 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2016 14:13:50 GMT
Received: from xch-rtp-008.cisco.com (64.101.220.148) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 10:13:49 -0400
Received: from xch-rtp-008.cisco.com ([64.101.220.148]) by XCH-RTP-008.cisco.com ([64.101.220.148]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 10:13:49 -0400
From: "Srihari Raghavan (srihari)" <srihari@cisco.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
Thread-Topic: [Lime] split draft-kumar-lime-yang-connectionless-oam into two - one on data and one on methods/rpc?
Thread-Index: AdHjLe4nZn8FkD+dRSqk7LxlFtLo/wAQZkQAAA6oQ4A=
Date: Thu, 21 Jul 2016 14:13:49 +0000
Message-ID: <D3B6D6AF.32768%srihari@cisco.com>
References: <c1ed48a5f63d4af885d2401c8d868edb@XCH-RCD-008.cisco.com> <52B851E4-DC9B-4F4F-B3F0-0AF364BAEBB0@gmail.com>
In-Reply-To: <52B851E4-DC9B-4F4F-B3F0-0AF364BAEBB0@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.81.229]
Content-Type: multipart/alternative; boundary="_000_D3B6D6AF32768srihariciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/u-I_PsrnEGUMrHNQiedGM3Ega6c>
Cc: "lime@ietf.org" <lime@ietf.org>
Subject: Re: [Lime] split draft-kumar-lime-yang-connectionless-oam into two - one on data and one on methods/rpc?
X-BeenThere: lime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." <lime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lime>, <mailto:lime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lime/>
List-Post: <mailto:lime@ietf.org>
List-Help: <mailto:lime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lime>, <mailto:lime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2016 14:14:12 -0000

My 2c.  +1 for splitting the document into two, considering the pros of doing that.

Thanks
Srihari

From: Lime <lime-bounces@ietf.org<mailto:lime-bounces@ietf.org>> on behalf of Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Date: Thursday, 21 July 2016 at 6:17 PM
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com<mailto:fbrockne@cisco.com>>
Cc: "lime@ietf.org<mailto:lime@ietf.org>" <lime@ietf.org<mailto:lime@ietf.org>>
Subject: Re: [Lime] split draft-kumar-lime-yang-connectionless-oam into two - one on data and one on methods/rpc?

Frank,

The models (including RPC definitions) are supposed to be protocol and encoding format independent. Retrieval methods are therefore model independent and should always be defined separate from the model.

P.s BTW, a gRPC draft was presented in the rtgwg(?) in this ietf.

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>

On Jul 21, 2016, at 11:16 AM, Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com>> wrote:

Hello,

per the ask from Carlos as WG chair in the meeting: Would it make sense to break the draft-kumar-lime-yang-connectionless-oam into two separate documents?

·       One on the data model itself

·       One on methods for data retrieval (the rpc definitions)

Pros:

·       Yang models in the current document are already structured this way, i.e. one on data and one on methods/rpc

·       Enable clean reference in case additional retrieval methods get defined which are not netconf rpc based. E.g. one could think of retrieving data via IPFIX, Kafka, gRPC, etc. - but one would obviously still want to use the same data formats. Those additional retrieval methods would likely be defined in separate drafts, which would mean that longer term, we would have a clean document reference structure:

o   Data model doc

§  Current set of rpcs doc

§  Additional retrieval method 1 doc

§  Additional retrieval method 2 doc ..

Cons:

·       Splitting the draft requires shepherding two drafts in lockstep - which requires additional work/supervision.

·       Updates to the documents would also need to make sure that data model and method documents (which might be multiple moving forward) are kept in synch.

Thoughts?

Thanks, Frank






_______________________________________________
Lime mailing list
Lime@ietf.org<mailto:Lime@ietf.org>
https://www.ietf.org/mailman/listinfo/lime