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

[Qin Wu <[e-mail]>]

发件人: Benoit Claise [mailto:[e-mail]]
发送时间: 2017年9月1日 19:18
收件人: Qin Wu
抄送: [e-mail]; Carl Moberg (camoberg); Alia Atlas; Jan Lindblad; Routing WG
主题: Re: [Lime] AD review: draft-ietf-lime-yang-connectionless-oam

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.


[Qin]: Fixed.


- 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.

[Qin]: I have add draft reference. I think CL method model provide both on-demand model and proactive model.
On-demand model is defined in the normative part while proactive model is defined in the appendix. Other authors,
Please correct me if I am wrong.

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.

[Qin]: Yes, we import draft-ietf-rtgwg-routing-types for both router-distinguisher and router-id. I hope I am not missing anything.


Some new editorial comments:
- indicatesindicate
- format.Each

[Qin]: Fixed.

Regards, Benoit