Re: [Lime] split draft-kumar-lime-yang-connectionless-oam into two

Hi, WG, and authors of the CL model,

After looking at the original and this second request for input on the list, we believe there is support for splitting the document, and no identified drawbacks on doing so.

Consequently, authors, please split draft-ietf-lime-yang-connectionless-oam into draft-ietf-lime-yang-connectionless-oam (data) and draft-ietf-lime-yang-connectionless-oam-methods (methods).

Thanks!

Carlos & Ron.

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Oct 13, 2016, at 02:24, Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> wrote:

Hi, Carlos:
Thank for bringing up this issue again. In the interim meeting, we discussed the strength and drawback of splitting CL model into data model and retrieval method model,
The data model which is separated from CL document comprises both config data and operation state data.
The benefit of splitting, is to make separated model more reusable and extensible.
The drawback, which I am not sure, is whether the data in the retrieval model is still coupled with operation state data in the data model.
e.g., whether cc-ipv4-sessions-statistics parameter and cc-ipv6-sessions-statistics parameter defined in the separated data model will be correlated with retrieval model.
In my understanding, retrieval method model serves as some kind of query which allows the management system to retrieval only operation state data in the test points.
Therefore separating retrieval method model will not result in config data change.

-Qin
???: Lime [mailto:lime-bounces@ietf.org] ?? Carlos Pignataro (cpignata)
????: 2016?10?13? 12:39
???: huubatwork@gmail.com<mailto:huubatwork@gmail.com>
??: lime@ietf.org<mailto:lime@ietf.org>
??: Re: [Lime] split draft-kumar-lime-yang-connectionless-oam into two - one on data and one on methods/rpc?

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