Subject: Re: [Lime] Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

From: Greg Mirsky <[email-masked]>
Date: Wed, 7 Feb 2018 23:05:30 +0800

Dear Authors, et. al,
thank you for your dedication to this work. Please kindly consider my
comments, as I've shared them January 31st, for the IETF LC :
- this document introduces YANG data model of connection-oriented OAM
protocols. I couldn't find the definition or reference to normative
definition of the connection-oriented OAM. As we've discussed, I
believe that the definition of the channel forwarding in G.800 in
section 6.3.1, specifically for connection-oriented packet switching,
is the one we can use similarly to the definition of connectionless
OAM in draft-ietf-lime-yang-connectionless-oam. And the fact that both
documents share one source of definitions, in my view, is advantage of
consistent dictionary.
- "This is the base identy of technology types which are
TRILL,MPLS-TP,vpls etc" Had VPLS been characterized as CO-PS? Not to
get into the discussion, perhaps stop after MPLS-TP be acceptable. And
I encourage to omit other references to VPLS in the document:
            - "... or for VPLS this can be per VPLS instance [RFC6136]."
            - " a VRF for VPLS,"
- what is the benefit to have specific ipv4-address and ipv6-address
in 'choice mep-address' rather than ip-address imported from
inet:ip-address?
- I think that 'leaf packet-size' is related to packet padding, not
the actual size of the test packet as there's always minimum size
determined by the corresponding technology and thus the packet size
cannot be smaller than the minimum size of, for example, LBM. Current
range for the leaf packet-size in rpc continuity-check is 0...10000
and in rpc continuity-verification the range is 64 ... 10000 (why such
inconsistency?). Test packet of 0 bytes doesn't seem practical while
test packet with 0 bytes of padding/payload does. And though we'd like
to use default for zero-touch (almost zero-touch), this is very
technology-specific parameter (compare Ethernet LBM and MPLS LSP
Ping).

Nits:
- s/interface)/interface)./
- consistency in using YANG vs. Yang throughout the document should be
achieved.
- s/../maintenance-domain]/co-oam:mas/co-oam:ma[/../maintenanc
e-domain]/co-oam:mas/co-oam:ma/
- s/CoS field in MPLS-TP/TC field in MPLS-TP/

On Mon, Feb 5, 2018 at 11:07 PM, The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the Layer Independent OAM Management
> in
> the Multi-Layer Environment WG (lime) to consider the following document: -
> 'Generic YANG Data Model for Connection Oriented Operations,
>    Administration, and Maintenance(OAM) protocols'
>   <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> as Proposed
>   Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2018-02-19. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document presents a base YANG Data model for connection oriented
>    OAM protocols.  It provides a technology-independent abstraction of
>    key OAM constructs for such protocols.  The model presented here can
>    be extended to include technology specific details.  This guarantees
>    uniformity in the management of OAM protocols and provides support
>    for nested OAM workflows (i.e., performing OAM functions at different
>    levels through a unified interface)
>
>    The YANG model in this document conforms to the Network Management
>    Datastore Architecture defined in
>    [I-D.ietf-netmod-revised-datastores].
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connec
> tion-oriented-oam-model/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connec
> tion-oriented-oam-model/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     rfc6905: Requirements for Operations, Administration, and Maintenance
> (OAM) in Transparent Interconnection of Lots of Links (TRILL)
> (Informational - IETF stream)
>
>
>
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime
>

---

From: "tom p." <[email-masked]>
Date: Wed, 14 Feb 2018 15:45:06 -0000

There seems to be a number of defects, mostly in the YANG module

- Abstract  appears to contain a reference to
   [I-D.ietf-netmod-revised-datastores].

-ITU-T [G.8013], MEF Service OAM, MPLS-TP [RFC6371], ...
MEF Service OAM wants a reference

- There is no note to RFC Editor asking that the date of the file name
and the Revision clause in the YANG module to be updated

- The YANG Module imports from
ietf-yang-types
ietf-inet-types
ietf-interfaces
but there is no mention of where these can be found and the relevant
RFC, perhaps 6991 for ietf-yang-types, seem not to appear in the I-D
References.  (See draft-ietf-netmod-rfc7277bis or
draft-ietf-netmod-rfc8022bis for examples of how this might be handled)

"Initial revision. - 12 version";
    reference "draft-ietf-lime-yang-oam-model";
I would expect this to refer to the subsequent RFC in which case it
needs a note to the RFC Editor asking them to insert the allocated
number

/This is the base identy of//This is the base identity of

'rfc6905 trill OAM '
this looks like a reference to an RFC but I see no sign of 6905 in the
References for the I-D

 identity cv-defect
...........
[RFC6371] highlights, when performing ...

This looks like a reference, using XML, in the YANG module which does
not work since the YANG module will be in plain text only (but 6371 does
appear in the References of the I-D:-)

- s6.3 In the Based Mode of operation
Is this the same as the Base mode of operation

IETF XML registry [RFC3688] [RFC3688].
A duplicate reference, or a missing reference, perhaps

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>;
<[email-masked]>
Sent: Monday, February 05, 2018 3:07 PM

> The IESG has received a request from the Layer Independent OAM
Management in
beginning of
> The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriente
d-oam-model/
> IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriente
d-oam-model/ballot/
>     rfc6905: Requirements for Operations, Administration, and
Maintenance (OAM) in Transparent Interconnection of Lots of Links
(TRILL) (Informational - IETF stream)

---

From: Benoit Claise <[email-masked]>
Date: Mon, 19 Feb 2018 15:20:46 -0500

Thanks Tom,

Authors, please address those comments and post a new draft version.

Regards, Benoit
> 'rfc6905 trill OAM'
> .

---

From: Qin Wu <[email-masked]>
Date: Thu, 22 Feb 2018 03:00:37 +0000

Thanks Tom, please see my reply inline below.
-----邮件原件-----
发件人: tom p. [mailto:[email-masked]] 
发送时间: 2018年2月14日 23:45
收件人: ietf
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

[Qin]: Fixed.

[Qin]:Fixed.

- There is no note to RFC Editor asking that the date of the file name and the Revision clause in the YANG module to be updated

- The YANG Module imports from
ietf-yang-types
ietf-inet-types
ietf-interfaces
but there is no mention of where these can be found and the relevant RFC, perhaps 6991 for ietf-yang-types, seem not to appear in the I-D References.  (See draft-ietf-netmod-rfc7277bis or draft-ietf-netmod-rfc8022bis for examples of how this might be handled)

[Qin]: Thanks, fixed.

"Initial revision. - 12 version";
    reference "draft-ietf-lime-yang-oam-model"; I would expect this to refer to the subsequent RFC in which case it needs a note to the RFC Editor asking them to insert the allocated number

[Qin]: Good catch, fixed.

[Qin]:Fixed.
'rfc6905 trill OAM '
this looks like a reference to an RFC but I see no sign of 6905 in the References for the I-D

[Qin]: Will add reference to RFC6905.
 identity cv-defect
...........
[RFC6371] highlights, when performing ...

This looks like a reference, using XML, in the YANG module which does not work since the YANG module will be in plain text only (but 6371 does appear in the References of the I-D:-)

[Qin]: Will add reference to RFC6371.

[Qin]: It is typo, thanks, fixed.
IETF XML registry [RFC3688] [RFC3688].
A duplicate reference, or a missing reference, perhaps

[Qin]:Fixed.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, February 05, 2018 3:07 PM

Management in
beginning of

---

From: "tom p." <[email-masked]>
Date: Fri, 23 Feb 2018 11:42:24 -0000

----- Original Message -----
From: "Qin Wu" <[email-masked]>
Sent: Thursday, February 22, 2018 3:00 AM

> Thanks Tom, please see my reply inline below.

Looks good.

I still see
 ...  [RFC6371] highlights   ...
which looks to me like an XML/HTML style of reference from within the
YANG module which does not work since the YANG module has to work as
plain text.  Yes, the reference clause is now there, which is good, but
I think that the
[RFC6371]
needs removing if it is what I suspect that it is.

And I always like the RFC Editor to have an easy time and so include a
note asking them to replace the xxxx.  I like the way that
draft-ietf-softwire-dslite-yang
does this.

Tom Petch

> 抄送: [email-masked]; [email-masked]; [email-masked];
[email-masked]
> 主题: Re: Last Call:
<draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic
YANG Data Model for Connection Oriented Operations, Administration, and
Maintenance(OAM) protocols) to Proposed Standard
>     reference "draft-ietf-lime-yang-oam-model"; I would expect this to
refer to the subsequent RFC in which case it needs a note to the RFC
Editor asking them to insert the allocated number
References for the I-D
> Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
> > The IESG plans to make a decision in the next few weeks, and
solicits
> final
> > [email-masked] mailing lists by 2018-02-19. Exceptionally, comments
may
> be

---

From: Qin Wu <[email-masked]>
Date: Fri, 23 Feb 2018 12:00:36 +0000

-----邮件原件-----
发件人: tom p. [mailto:[email-masked]] 
发送时间: 2018年2月23日 19:42
收件人: Qin Wu; ietf
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

----- Original Message -----
From: "Qin Wu" <[email-masked]>
Sent: Thursday, February 22, 2018 3:00 AM

Looks good.

I still see
 ...  [RFC6371] highlights   ...
which looks to me like an XML/HTML style of reference from within the YANG module which does not work since the YANG module has to work as plain text.  Yes, the reference clause is now there, which is good, but I think that the [RFC6371] needs removing if it is what I suspect that it is.

And I always like the RFC Editor to have an easy time and so include a note asking them to replace the xxxx.  I like the way that draft-ietf-softwire-dslite-yang does this.

[Qin]: Note that I had added a explicit reference under that description within the YANG module in v-06 as follows:
"
    reference
      "RFC 6371: Operations, Administration, and Maintenance
       Framework for MPLS-Based Transport Networks";
"
So it is not XML/HTML style any more. :-)

Tom Petch

> 主题: Re: Last Call:
<draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and
Maintenance(OAM) protocols) to Proposed Standard
> but there is no mention of where these can be found and the relevant
RFC, perhaps 6991 for ietf-yang-types, seem not to appear in the I-D References.  (See draft-ietf-netmod-rfc7277bis or draft-ietf-netmod-rfc8022bis for examples of how this might be handled)
>     reference "draft-ietf-lime-yang-oam-model"; I would expect this to
refer to the subsequent RFC in which case it needs a note to the RFC Editor asking them to insert the allocated number
References for the I-D
> [Qin]: Will add reference to RFC6905.
not work since the YANG module will be in plain text only (but 6371 does appear in the References of the I-D:-)
> Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
solicits
may

---

From: "tom p." <[email-masked]>
Date: Fri, 23 Feb 2018 12:14:33 -0000

----- Original Message -----
From: "Qin Wu" <[email-masked]>
Sent: Friday, February 23, 2018 12:00 PM

YANG module which does not work since the YANG module has to work as
plain text.  Yes, the reference clause is now there, which is good, but
I think that the [RFC6371] needs removing if it is what I suspect that
it is.
note asking them to replace the xxxx.  I like the way that
draft-ietf-softwire-dslite-yang does this.
>
> [Qin]: Note that I had added a explicit reference under that
> So it is not XML/HTML style any more. :-)

But look just above that, as in the extract below,  and  I see [RFC6371]
which still looks like an XML/HTML style reference from within the YANG
module.

identity cv-defect {
    base defect-types;
    description
      "This function should support monitoring between
       the Maintenance End Points (MEPs) and,
       in addition, between a MEP and Maintenance Intermediate
       Point (MIP). [RFC6371] highlights ....

Tom Petch

> not work since the YANG module will be in plain text only (but 6371
does appear in the References of the I-D:-)
> > >    OAM protocols.  It provides a technology-independent
abstraction
> of
> > >    key OAM constructs for such protocols.  The model presented
here
> > can

---

From: Qin Wu <[email-masked]>
Date: Mon, 26 Feb 2018 01:25:18 +0000

Fixed, thanks Tom.

-Qin
-----邮件原件-----
发件人: tom p. [mailto:[email-masked]] 
发送时间: 2018年2月23日 20:15
收件人: Qin Wu; ietf
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

----- Original Message -----
From: "Qin Wu" <[email-masked]>
Sent: Friday, February 23, 2018 12:00 PM

> which looks to me like an XML/HTML style of reference from within the
YANG module which does not work since the YANG module has to work as plain text.  Yes, the reference clause is now there, which is good, but I think that the [RFC6371] needs removing if it is what I suspect that it is.
> And I always like the RFC Editor to have an easy time and so include a
note asking them to replace the xxxx.  I like the way that draft-ietf-softwire-dslite-yang does this.
description within the YANG module in v-06 as follows:
>        Framework for MPLS-Based Transport Networks"; "

But look just above that, as in the extract below,  and  I see [RFC6371] which still looks like an XML/HTML style reference from within the YANG module.

identity cv-defect {
    base defect-types;
    description

Tom Petch

> RFC, perhaps 6991 for ietf-yang-types, seem not to appear in the I-D
References.  (See draft-ietf-netmod-rfc7277bis or draft-ietf-netmod-rfc8022bis for examples of how this might be handled)
> > - s6.3 In the Based Mode of operation Is this the same as the Base 
> > mode of operation
> >
abstraction
here