Re: [Lime] WGLC: draft-ietf-lime-yang-oam-model-08

["Adrian Farrel" <[e-mail]>]

Thanks Michael,

That all looks good.

Adrian

> -----Original Message-----
> From: wangzitao [mailto:[e-mail]]
> Sent: 25 January 2017 02:22
> To: [e-mail]; 'Ron Bonica'; [e-mail];
draft-ietf-lime-yang-oam-
> [e-mail]
> Subject: RE: [Lime] WGLC: draft-ietf-lime-yang-oam-model-08
> 
> Thank Adrian for these valuable comments, please find my reply inline.
> 
> Best Regards!
> -Michael
> 
> -----邮件原件-----
> 发件人: Adrian Farrel [mailto:[e-mail]]
> 发送时间: 2017年1月25日 7:38
> 收件人: 'Ron Bonica'; [e-mail]; draft-ietf-lime-yang-oam-
> [e-mail]
> 主题: RE: [Lime] WGLC: draft-ietf-lime-yang-oam-model-08
> 
> Hi,
> 
> I read through this document again and think it is ready for publication.
> 
> Here are some minor things to ix along the way.
> 
> Thanks,
> Adrian
> ===
> You might sort out the line lengths.
> [Michael]: Yes, I can fix it.
> 
> ---
> Abstract is missing a final period.
> [Michael]: Thanks, I will fix it in next version.
> ---
> Some of the references in sections 1 8 and 9 seem to be duplicated.
> [Michael]: Yes, I will fix it.
> ---
> The last sentence of section 2 presumably belongs with the first paragraph.
> [Michael]: Indeed, it need to be fixed.
> ---
> The text in section 2 that defines the notation used in the trees that are
found in
> this document is useful, but I suspect it of being generic.
> (It would be nice if this was in a separate document so that everyone can
> reference it, but that is not the job of these authors or this WG.)
> 
> I did find several parts of the text confusing and I wondered whether:
> - you can can drop the statuses that are not used in this document
>   (I think there are no deprecated or obsoleted objects)
> [Michael]: Yep, the deprecated/obsolete statement is not used. Moving this
flag
> from the section make sense for me.
> 
> - add the other flags that are used (I see, "w" although I am surprised
>   to find what is effective a write-only object so perhaps that is an
>   error?)
> [Michael]: Agree.
> - give simple examples (because "x" and "-x" may be hard to distinguish)
> [Michael]: Agree.
> ---
> In 4 you have
>    Under each MA, there can be two or more MEPs (Maintenance Association
>    End Points).
> But your primary expansion of MEP in section 2.1 is different.
> [Michael]: Yes, it need to be fixed.
> ---
> Sections 1 and 2.1 use "RPC" the rest of the document uses "rpc"
> [Michael]: Yes, it need to be synchronized. I'd like to fix it.
> ---
> Section 4.4 has
>    Please refer to Section 4 for the complete
>    data hierarchy
> which is a bit odd given that we are in the middle of section 4.
> [Michael]: Yes, it seems odd, I think it can be modified to "Please refer to
Section
> 4.5 for the complete
>    data hierarchy".
> ---
> Not asking you to do it, but why after the whole of section 4, why are there
no
> "fragments" in section 4.5?
> ---
> A number of description clauses need to begin with capital letters.
> [Michael]:You are right, I will fix it in next version.
> ---
> loss-of-continuity refers to the receiving MEP's configured CC-V reception
period.
> I cannot find where I can read the value of that.
> [Michael]: I'd like to discuss with my coauthor to decide whether we need this
> attributes
> ---
> Any reason why sometimes
> 
>       leaf cc-transmit-interval {
>         type Interval;
>         description
>           "Interval between echo requests";
>       }
> 
> and sometimes
> 
>       leaf interval {
>         type Interval;
>         description
>           "Interval between echo requests";
>       }
> [Michael]: according to previous discussion, for continuity check, there is a
little of
> difference on same terminology For example:
> for mpls-tp, there are transmit-interval and receive-interval, therefore, we
> defined this attribute as cc-transmit-interval.
> ---
> Why is there a minimum packet-size of 64 octets?
> Why can't I send smaller CC and CV packets?
> [Michael]: I agree with your concern, especially consider for future
technologies,
> restrict the minimum packet-size as 64 octets seems not good idea.
> I would like to discuss with coauthor and may be change it in next version.
> ---
> Stray text "YANG module of OAM" right at the end of the module?
> [Michael]: yes, it need to be fixed.
> ---
> 6.2 has MEPID and MEP-ID and MEP ID.
> [Michael]: Yes, it need to be synchronized.
> ---
> 6.2 has
>    In this document we propose to extend the range to 0 to
>    65535.
> s/propose to extend/extend/
> [Michael]: Agree.
> ---
> 6.3 has "MAID" unexpanded.  This is probably just the ID of the MA, but ...
> [Michael]: Yes, you are right, I would like to fix it.
> Section 7 has
>    This section demonstrates the usability of the connection-oriented
>    YANG OAM data model to various connection-oriented OAM technologies,
>    e.g., TRILL and MPLS-TP.
> This should probably be
>    This section demonstrates the applicability of the connection-oriented
>    YANG OAM data model to TRILL and MPLS-TP.
> [Michael]: This section demonstrates the CO model's applicability, it
introduce the
> method of augmenting the CO model to derived technology specific model.
> Trill and MPLS-TP are just some examples.
> ---
> I think the affiliations and emails of the Contributors and Authors need to be
> double-checked.
> [Michael]: Agree.