Subject: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 8 Aug 2015 20:11:35 +0000

LIME,

This email starts a two-week poll on adopting draft-tissa-lime-yang-oam-model-06 [1] as a LIME working group item.

Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons).

This poll runs until ** August 24th, 2015 **.

We are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

*If you are listed as a document author or contributor*, please respond to this email and indicate whether or not you are aware of any relevant IPR.

The draft will not be adopted until a response has been received from each author and contributor.

If you are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Thank you,

Ron Bonica / Carlos Pignataro
LIME co-chairs

[1] http://datatracker.ietf.org/doc/draft-tissa-lime-yang-oam-model/ <http://datatracker.ietf.org/doc/draft-tissa-lime-yang-oam-model/>

---

From: Qin Wu <[email-masked]>
Date: Mon, 10 Aug 2015 09:47:52 +0000

Support as a coauthor, I am not aware of any relevant IPR.

-Qin
发件人: Lime [mailto:[email-masked]] 代表 Carlos Pignataro (cpignata)
发送时间: 2015年8月9日 4:12
收件人: [email-masked]
抄送: [email-masked]
主题: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

LIME,

Thank you,

[1] http://datatracker.ietf.org/doc/draft-tissa-lime-yang-oam-model/

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 12 Aug 2015 00:27:17 +0200

All,

I support adopting this draft as WG item.

I am not aware of any relevant IPR.

Best regards, Huub.

-----------------------

LIME,

This email starts a two-week poll on
adopting draft-tissa-lime-yang-oam-model-06 [1] as a LIME
working group item.

Please send comments to the list and state if you support
adoption or not (in the later case, please also state the
reasons).

We are also polling for knowledge of any IPR that applies to
this draft, to ensure that IPR has been disclosed in compliance
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
details).

*If you are listed as a document author or contributor*,
please respond to this email and indicate whether or not you are
aware of any relevant IPR.

The draft will not be adopted until a response has been
received from each author and contributor.

If you are not listed as an author or contributor, then
please explicitly respond only if you are aware of any IPR that
has not yet been disclosed in conformance with IETF rules.

Thank you,

LIME co-chairs

_______________________________________________
Lime mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lime

--
*****************************************************************
请记住，你是独一无二的，就像其他每一个人一样

---

From: wangzitao <[email-masked]>
Date: Fri, 21 Aug 2015 07:36:56 +0000

Support. And I am not aware any relevant IPR.

-Best Regards!
Michael

LIME,

Thank you,

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 21 Aug 2015 16:32:54 +0000

I do not support adoption of this document as WG item.

I believe that until Applicability of Generic YANG Data Model for layer Independent OAM Management demonstrates that the proposed model indeed is common among OAM technologies developed at IETF, e.g. IP, IP/MPLS, MPLS-TP, and TRILL, beyond just YANG customization mechanisms adopting this draft as WG item is premature. And the applicability document has not demonstrated that yet as you can see from the attached comments to the  Applicability of the draft-tissa-lime-yang-oam-model and couple more generic notes:

  *   Operations, Administration and Maintenance address Fault Management and Performance Monitoring of the FCAPS. If the scope of the document does not include both then I suggest not to refer to is as OAM but perhaps On-demand Continuity Check and Connectivity Verification, i.e. ping and traceroute, Common YANG model;
  *   section 4 is more about general YANG extensibility than of the proposed OAM YANG data model;
  *   IP/MPLS OAM not being separated from MPLS-TP OAM;
  *   Performance Monitoring arbitrary being left outside the scope for some technologies, e.g. Ethernet;
  *   often Service OAM being presented as Transport OAM, e.g. VPLS, NVO3.

Regards,
        Greg

From: Lime [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Saturday, August 08, 2015 1:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

LIME,

Thank you,

---

From: Tom Taylor <[email-masked]>
Date: Sat, 22 Aug 2015 22:43:19 -0400

For the record, I support adoption of this document as a WG draft. There 
are changes I want to see in it, but these can come about through 
ordinary WG process. This is a first call, not a last call. As to the 
points Greg puts forward below, I think his subtext is that if there is 
inconsistency between the LIME model and the work done in the MPLS WG, 
it is the LIME model that has to change. Obviously there is room for 
negotiation, but I believe the LIME charter gives LIME the priority here.

Tom Taylor

On 21/08/2015 12:32 PM, Gregory Mirsky wrote:
> I believe that until Applicability of Generic YANG Data Model for layer
> Independent OAM Management demonstrates that the proposed model indeed
> is common among OAM technologies developed at IETF, e.g. IP, IP/MPLS,
> MPLS-TP, and TRILL, beyond just YANG customization mechanisms adopting
> this draft as WG item is premature. And the applicability document has
> not demonstrated that yet as you can see from the attached comments to
> the  Applicability of the draft-tissa-lime-yang-oam-model and couple
> more generic notes:
>
>   * Operations, Administration and Maintenance address Fault Management
>     and Performance Monitoring of the FCAPS. If the scope of the
>     document does not include both then I suggest not to refer to is as
>     OAM but perhaps On-demand Continuity Check and Connectivity
>     Verification, i.e. ping and traceroute, Common YANG model;
> *From:*Lime [mailto:[email-masked]] *On Behalf Of *Carlos
> Pignataro (cpignata)
> *Sent:* Saturday, August 08, 2015 1:12 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06
>
> LIME,
>
>
> adopting draft-tissa-lime-yang-oam-model-06 [1] as a LIME working group
> item.
>
> Please send comments to the list and state if you support adoption
> or not (in the later case, please also state the reasons).
>
> We are also polling for knowledge of any IPR that applies to this draft,
> to ensure that IPR has been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> *If you are listed as a document author or contributor*, please respond
> to this email and indicate whether or not you are aware of any relevant IPR.
>
> please explicitly respond only if you are aware of any IPR that has
> not yet been disclosed in conformance with IETF rules.
>
> Thank you,
>

---

From: Dapeng Liu <[email-masked]>
Date: Mon, 24 Aug 2015 16:40:42 +0800

+1 support

Dapeng Liu

2015-08-09 4:11 GMT+08:00 Carlos Pignataro (cpignata) <[email-masked]>:

> Please send comments to the list and state if you support adoption or not
> (in the later case, please also state the reasons).
>
> *If you are listed as a document author or contributor*, please respond to
> this email and indicate whether or not you are aware of any relevant IPR.
>
> If you are not listed as an author or contributor, then please explicitly
> respond only if you are aware of any IPR that has not yet been disclosed in
> conformance with IETF rules.
>
> Thank you,
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Yuji Tochio <[email-masked]>
Date: Tue, 25 Aug 2015 08:00:12 +0900

Hi all,

Support.
But I also concur with Greg's concern and I would like to ask WG to solve the concern as well as the comment I sent to this list.

Thanks, Yuji

On 2015/08/09 5:11, Carlos Pignataro (cpignata) wrote:
> We are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 
> 3979, 4879, 3669 and 5378 for more details).
>

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Mon, 24 Aug 2015 23:19:28 +0000

I concur with Greg's concerns.

Best regards,
Eve

From: Lime [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Friday, August 21, 2015 12:33 PM
To: Carlos Pignataro (cpignata); [email-masked]
Cc: [email-masked]
Subject: Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

Regards,
        Greg

From: Lime [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Saturday, August 08, 2015 1:12 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

LIME,

Thank you,

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 24 Aug 2015 17:41:50 -0700

Agree with Greg.

I have particular concern about this statement in the draft:

All implementations that follow the YANG framework presented in this
   document MUST implement the generic YANG model presented here.

This seems to stipulate a requirement that neither YANG as a language nor any existing technology requires, except maybe CFM itself. Where is this stipulation coming from and why is it a MUST?

> On Aug 24, 2015, at 4:19 PM, Varma, Eve L (Eve) <[email-masked]> wrote:
> 
> I concur with Greg’s concerns.
>  
> Best regards,
> Eve
>  
> From: Lime [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gregory Mirsky
> To: Carlos Pignataro (cpignata); [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> Operations, Administration and Maintenance address Fault Management and Performance Monitoring of the FCAPS. If the scope of the document does not include both then I suggest not to refer to is as OAM but perhaps On-demand Continuity Check and Connectivity Verification, i.e. ping and traceroute, Common YANG model;
> section 4 is more about general YANG extensibility than of the proposed OAM YANG data model;
> IP/MPLS OAM not being separated from MPLS-TP OAM;
> Performance Monitoring arbitrary being left outside the scope for some technologies, e.g. Ethernet;
> often Service OAM being presented as Transport OAM, e.g. VPLS, NVO3.
>  
>  
> Regards,
>         Greg
>  
> From: Lime [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Carlos Pignataro (cpignata)
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lime <https://www.ietf.org/mailman/listinfo/lime>
Mahesh Jethanandani
[email-masked]

---

From: Tom Taylor <[email-masked]>
Date: Mon, 24 Aug 2015 21:10:14 -0400

It comes from making the making the draft Standards Track. If you claim 
to implement the ultimate RFC, this is a logical consequence, just as 
for any other Standards Track RFC.

Tom Taylor

On 24/08/2015 8:41 PM, Mahesh Jethanandani wrote:
> This seems to stipulate a requirement that neither YANG as a language
> nor any existing technology requires, except maybe CFM itself. Where is
> this stipulation coming from and why is it a MUST?
>

---

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Tue, 25 Aug 2015 02:18:16 +0000

Hi Greg and all,

"And the applicability document has not demonstrated that yet as you can see from the attached comments and couple more generic notes:

  *   often Service OAM being presented as Transport OAM, e.g. VPLS, NVO3."

[Yan] Thanks for your general comments and input on Applicability document (the relevant draft is draft-zhuang-lime-yang-oam-model-applicability), we are happy to address these in the update of applicability document.
Other's contribution to applicability document are also welcome.

Regards,
        Greg

LIME,

Thank you,

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 25 Aug 2015 22:42:49 +0200

All,

After reading other comments, I thoroughly re-read the draft and

now I agree with Greg about the status of the draft.

Best regards, Huub.

============

Greg wrote:

I
do not support adoption of this document as WG item.

I
believe that until Applicability of Generic YANG Data Model
for layer Independent OAM Management demonstrates that the
proposed model indeed is common among OAM technologies
developed at IETF, e.g. IP, IP/MPLS, MPLS-TP, and TRILL,
beyond just YANG customization mechanisms adopting this
draft as WG item is premature. And the applicability
document has not demonstrated that yet as you can see from
the attached comments to the  Applicability of the
draft-tissa-lime-yang-oam-model and couple more generic
notes:

Operations,
Administration and Maintenance address Fault Management
and Performance Monitoring of the FCAPS. If the scope of
the document does not include both then I suggest not to
refer to is as OAM but perhaps On-demand Continuity Check
and Connectivity Verification, i.e. ping and traceroute,
Common YANG model;

section
4 is more about general YANG extensibility than of the
proposed OAM YANG data model;

IP/MPLS
OAM not being separated from MPLS-TP OAM;

Performance
Monitoring arbitrary being left outside the scope for some
technologies, e.g. Ethernet;

often
Service OAM being presented as Transport OAM, e.g. VPLS,
NVO3.

Regards,

Greg

From:
Lime [mailto:[email-masked]]
On Behalf Of Carlos Pignataro (cpignata)

To: [email-masked]

Cc:
[email-masked]

Subject: [Lime] Call for Adoption:
draft-tissa-lime-yang-oam-model-06

LIME,

We are also polling for knowledge of any IPR that applies to
this draft, to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
and 5378 for more details).

*If you are listed as a document author or contributor*,
please respond to this email and indicate whether or not you
are aware of any relevant IPR.

If you are not listed as an author or contributor, then
please explicitly respond only if you are aware of any IPR
that has not yet been disclosed in conformance with IETF
rules.

Thank you,

LIME co-chairs

---

From: Qin Wu <[email-masked]>
Date: Wed, 26 Aug 2015 02:38:04 +0000

Hi, All:
Do we poll for adoption on draft-tissa-lime-yang-oam-model-06? Do we poll for adoption on draft-zhuang-lime-yang-oam-model-applicability?
I became a little confused by  this call now.
As LIME charter said:
“
Goals and Milestones:
  Feb 2015 - Adopt the WG draft on YANG data model(s)
  Aug 2015 - Adopt the WG draft for Applicability of the generic model
”
LIME YANG model should be developed before Applicability document work item based on Charter said. The key reason for this order is without knowing what LIME base model look like, how do we know how to apply LIME YANG model to various technologies.

LIME YANG model and Applicability document are completely two separated two work items.
draft-zhuang-lime-yang-oam-model-applicability was just called out just before Prague meeting to show an example on what Applicability document looks like when Chairs called for progress on Applicability document before IETF93. In Prague, draft-zhuang-lime-yang-oam-model-applicability was presented and got a lot of discussion, the most of important goal of discussing draft-zhuang-lime-yang-oam-model-applicability is to seek the opinion on the scope of LIME applicability rather than contents of LIME Applicability document.

Yes, LIME Applicability document is not perfect since it is just a infant and hasn’t grown up, please be patient and give it some time,e.g., section 4 needs to be rewritten to focus on how to extend base model to support different OAM technologies, we can discuss this,
Yes, IP/MPLS OAM needs to be separated from MPLS-TP OAM in the Applicability draft.
Yes, Fault Management and Performance monitoring are two important aspects,  Ethernet section need to cover performance measurement based on Y.1731 in the Applicability draft. in Prague meeting, we discussed both  Fault management and performance monitoring separately in one joint session, but our proposal is not to separate performance monitoring from LIME base model, we just leave it in the separate draft for now and we can put it back if the WG has consensus. So all of these are something we can be fixed in the applicability document. It is useful input to shape the scope of Applicability document not LIME base model.

-Qin
发件人: Lime [mailto:[email-masked]] 代表 Zhuangyan (Yan)
发送时间: 2015年8月25日 10:18
收件人: Gregory Mirsky; [email-masked]
抄送: Carlos Pignataro (cpignata)
主题: Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

Hi Greg and all,

“And the applicability document has not demonstrated that yet as you can see from the attached comments and couple more generic notes:

  *   often Service OAM being presented as Transport OAM, e.g. VPLS, NVO3.”

Regards,
        Greg

LIME,

Thank you,

---

From: Qin Wu <[email-masked]>
Date: Wed, 26 Aug 2015 03:25:56 +0000

BTW: Forget to mention, just a little background, draft-tissa-lime-yang-oam-model is the replacement of draft-tissa-netmod-oam-00, which was created earlier before LIME WG was formed.
draft-tissa-lime-yang-oam-model has been around more than 4 or 5 IETF meetings and got a lot of discussions on the lists regarding open issues and received sufficient reviews from WG chairs, YANG doctors, IETF participants. In the recent IETF Prague meeting, we made a good progress and discussed and resolved most of main open issues, So that’ why we are ready to go. We are not saying we are perfect now, but we need to follow WG process.

-Qin
发件人: Lime [mailto:[email-masked]] 代表 Qin Wu
发送时间: 2015年8月26日 10:38
收件人: Zhuangyan (Yan); Gregory Mirsky; [email-masked]
抄送: Carlos Pignataro (cpignata)
主题: Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

Hi, All:

Yes, LIME Applicability document is not perfect since it is just a infant and hasn’t grown up, please be patient and give it some time,e.g., section 4 needs to be rewritten to focus on how to extend base model to support different OAM technologies, we can discuss this,
Yes, IP/MPLS OAM needs to be separated from MPLS-TP OAM in the Applicability draft.
Yes, Fault Management and Performance monitoring are two important aspects,  Ethernet section need to cover performance measurement based on Y.1731 in the Applicability draft. in Prague meeting, we discussed both  Fault management and performance monitoring separately in one joint session, but our proposal is not to separate performance monitoring from LIME base model, we just leave it in the separate draft for now and we can put it back if the WG has consensus. So all of these are something we can be fixed in the applicability document. They are useful input to shape the scope of Applicability document not LIME base model.

-Qin
发件人: Lime [mailto:[email-masked]] 代表 Zhuangyan (Yan)
发送时间: 2015年8月25日 10:18
收件人: Gregory Mirsky; [email-masked]<mailto:[email-masked]>
抄送: Carlos Pignataro (cpignata)
主题: Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

Hi Greg and all,

Regards,
        Greg

LIME,

Thank you,

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 26 Aug 2015 14:10:54 -0700

[Adding BFD mailing list back because this decision affects them]

Tom,

I was hoping for a rational that went beyond  “and you shall …”

Something along the lines of why /lime/bfd is better than /lime -> /bfd. Or why almost all configuration models for BFD that currently work just fine, now have to start supporting CFM like semantics in Maintenance Domain (MD), Maintenance Association (MA) or Maintenance Endpoint (MEP) configuration to realize a BFD session.

You might find a similar discussion around the devices YANG model germane to this thought process. In particular, the thread titled "issue Y34 - root node" on the netmod mailing list.

Cheers.

> On Aug 24, 2015, at 6:10 PM, Tom Taylor <[email-masked]> wrote:
> 
> It comes from making the making the draft Standards Track. If you claim to implement the ultimate RFC, this is a logical consequence, just as for any other Standards Track RFC.
> 
> Tom Taylor
> 

Mahesh Jethanandani
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Thu, 27 Aug 2015 01:56:21 +0000

Hi, Mahesh:
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Mahesh Jethanandani
发送时间: 2015年8月27日 5:11
收件人: Tom Taylor
抄送: [email-masked]; [email-masked]
主题: Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

Tom,

[Qin]: See 
http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html
http://www.ietf.org/mail-archive/web/netmod/current/msg13113.html

What device YANG model is applied to this WG is about the following substructure:
     +--rw device
          +--rw logical-network-elements
                +--rw networking-instances
                   +--rw networking-instance* [networking-instance-name]
                      +--rw oam-protocols
                      |  +--rw bfd
                      |  +--rw cfm
                      |  +--rw twamp
Rather than the example quoted in Y-34 (http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html)
   +--rw device
          +--rw info
          |  +--rw device-type?   enumeration
          +--rw hardware
          +--rw interfaces
          |  +--rw interface* [name]
          |     ...
          +--rw qos

So In my understanding, device model is more focusing on discussing organizing different type of models in a
  comprehensive structure. For the same type of models(e.g., OAM type), we can find common structure to make different technology specific OAM models with same type (i.e.,OAM type)work together. The relationship between these models are described as several models are extension to one base model.

The debate on Y-34 is about whether we should add new top level node (device) on top of another existing top level node(e.g., interface). Device and interface are of two different types, 

One interesting proposal raised by Lada in http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html is:
"Extend YANG so that a *specific* schema tree can be grafted at a given data node."
One example given by Lada in the discussion is:
"
I believe there are other use cases in the existing modules. For
example, the ietf-routing module could simply define the data model for
a single routing instance (i.e. without "routing-instance" list at the
top), and it can be then used without changes on simple devices, and
more complex router implementations can graft it as a subtree under
"routing-instance", "networking-instance" or whatever.

"
I think this is something more relevant to what we are doing. I think we should consider to take this approach.

Cheers.

>> nor any existing technology requires, except maybe CFM itself. Where 
>> is this stipulation coming from and why is it a MUST?
>> 
> 

Mahesh Jethanandani
[email-masked]