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

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Thu, 13 October 2016 04:38 UTC

Return-Path: <cpignata@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 E9C9612987A for <lime@ietfa.amsl.com>; Wed, 12 Oct 2016 21:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.516
X-Spam-Level:
X-Spam-Status: No, score=-17.516 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 9LRDJTsK18UW for <lime@ietfa.amsl.com>; Wed, 12 Oct 2016 21:38:33 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989BE129869 for <lime@ietf.org>; Wed, 12 Oct 2016 21:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22894; q=dns/txt; s=iport; t=1476333513; x=1477543113; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HYu9dplwSHfT2haARkxZhUH6ho6H09lwuXP/bo9Ql2c=; b=JN1KLEFkH5YlF4cmnByCdL8D04L3rfxCykGY7oo5UAZirP5cgJ9BDxmh 6zPTb86kDZ/t11LiJk1GgDMje5RO+1SHLLkrLdoCEmxh6UpE3gnhtBwZ5 53PKRxHKk4lkMtmVeRg25pxvQNd+juCAGDcIsP9vXEvxtJnbhQoHMXAMZ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CPAQDJDv9X/4ENJK1cGgEBAQECAQEBAQgBAQEBgwc1AQEBAQEdV3wHjS2eX4xZggocAQqFegIagVw4FAECAQEBAQEBAV4cC4RiAQEEAQEBIEsLEAIBCDsEAwICAh8GCxQRAgQOBYg2AxcOtjGJBg2DcgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhj2BfYFTgQWCR4IXgm0sgi8FiDyRETUBjHGDC491iGWEFIN+AR42UIMqgTpyh2SBAAEBAQ
X-IronPort-AV: E=Sophos;i="5.31,338,1473120000"; d="scan'208,217";a="157362283"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2016 04:38:32 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u9D4cWQd014901 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Oct 2016 04:38:32 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Oct 2016 00:38:30 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Thu, 13 Oct 2016 00:38:30 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "huubatwork@gmail.com" <huubatwork@gmail.com>
Thread-Topic: [Lime] split draft-kumar-lime-yang-connectionless-oam into two - one on data and one on methods/rpc?
Thread-Index: AQHSJQulfbnkbA3DaUeu4kePA4x+AA==
Date: Thu, 13 Oct 2016 04:38:30 +0000
Message-ID: <72134D0C-EFB1-492B-B8BC-5BFD648478F3@cisco.com>
References: <c1ed48a5f63d4af885d2401c8d868edb@XCH-RCD-008.cisco.com> <2bffd29e-c21b-c24c-ccb0-2e6b491a3923@gmail.com>
In-Reply-To: <2bffd29e-c21b-c24c-ccb0-2e6b491a3923@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.82.237.181]
Content-Type: multipart/alternative; boundary="_000_72134D0CEFB1492BB8BC5BFD648478F3ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/FVH_yBBDcLk-cZLYIKDTLp4f8Zw>
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, 13 Oct 2016 04:38:36 -0000

Hi, WG,

During our interim meeting this week, the main open item that remains is the suggestion to split the CL document into data model vs. retrieval methods.

There were opinions and arguments on both ends of this question.

As we agreed on the interim, let’s take the discussion to the list.

I am therefore re-igniting this thread. See below, and share your thoughts with technical rationales.

Thanks,

— Carlos.

On Jul 29, 2016, at 4:57 AM, Huub van Helvoort <huubatwork@gmail.com<mailto:huubatwork@gmail.com>> wrote:

Hello Frank,

The definition of the model and the retreival method(s) should be in
separate documents.

Best regards, Huub.

--------------------
On 21-07-16 11:16, Frank Brockners (fbrockne) 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
--
================================================================
Always remember that you are unique...just like everyone else...

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