[Lime] 答复: AD review: draft-ietf-lime-yang-connectionless-oam

[Qin Wu <[e-mail]>]

Good comments, will update based on your comments and suggestion.

Sent from HUAWEI AnyOffice
发件人： bclaise
收件人： Qin Wu;
抄送： [e-mail]; Carl Moberg (camoberg); akatlas; Jan Lindblad; Routing WG;
主题： Re: [Lime] AD review: draft-ietf-lime-yang-connectionless-oam
时间： 2017-09-01 19:18:09


Thanks Qin
See in-line.
Thanks for AD Review. We have addressed your comments in v-(09) together with other comments.

https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/
Just to clarify, ‘tp-tools’ grouping defined in  CL model support both proactive and on demand activation.
Grouping defined for common session  statistics on support proactive activation.
We have made this clear in the text.
Also it is intentional to separate retrieval- data from retrieval procedure, the rationale is clarified in the
introduction 1, last paragraph of draft-ietf-lime-yang-connectionless-oam-methods.

-Qin
发件人: Lime [mailto:[e-mail]] 代表 Benoit Claise
发送时间: 2017年8月11日 23:11
抄送: [e-mail]<mailto:[e-mail]>; Carl Moberg (camoberg); Alia Atlas
主题: [Lime] AD review: draft-ietf-lime-yang-connectionless-oam

Dear all,

Here is my AD review.



-

   To define a forwarding treatment of a test packet, the 'tp-address'

   needs to be associated with additional parameters, e.g.  DSCP for IP

   or TC for MPLS.
TC?
I'm still used to EXP, and had to look TC up.
Quoting the Internet (so it can't be wrong): Based on RFC5462, the EXP bit has been renamed to Traffic Class field. TC name is not uses widely.
The point was not to change TC to EXP, but to write:
DSCP for IP or EXP (renamed to Traffic Classic in RFC5462) for MPLS.
<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-types/>



- You included:

   The model is augmented to "/nd:networks/nd:network/nd:node" using
   'test-point-locations' defined below. 'tp-tools' grouping defined in
   this model supports both proactive and on-demand activation.

But unless you provide a draft reference, it doesn't make sense.
I had to check the YANG itself to discover the assigned prefix:

 import ietf-network {
      prefix nd;
    }

And then lookup ietf-network

- I see a "typedef route-distinguisher" in https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-types/
It's more complete that your leaf route-distinguisher, uint64.
At this point, I believe you should import it.
There are maybe other types you might want to import.


Some new editorial comments:
- indicatesindicate
- format.Each

Regards, Benoit