Re: [Gen-art] Post-telechat review of draft-ietf-lime-yang-connectionless-oam-16

[Qin Wu <[e-mail]>]

Thanks Elwyn, your addition comment and proposal for moving forward make a lot of sense. Thanks again for thoughtful review on this document.

-Qin
发件人: Elwyn Davies [mailto:[e-mail]]
发送时间: 2017年11月13日 8:52
收件人: Qin Wu <[e-mail]>
抄送: [e-mail]
主题: RE: Post-telechat review of draft-ietf-lime-yang-connectionless-oam-16

Hi, Qin.

A great improvement - thanks.

The only thing I would say (as I said in my last set of comments) is that I would add the identity of the document that defines the module that is imported i the actual code ofthe YANG module.  The reason for this is that  the YANG code will eventually be freestanding and so it is useful to be able to see where the import is coming from in the actual code rather than having to look back in the RFC.  Alsoat present the document does explicitly tie the YANG module names to the defining documents which means a reader has to look through all the documents tofind whic is which (or look in the YANG index).

This could be handled by a note to the RFC editor or in Auth48.

Cheers,
Elwyn


Sent from Samsung tablet.

-------- Original message --------
From: Qin Wu <[e-mail]<mailto:[e-mail]>>
Date: 12/11/2017 15:23 (GMT+00:00)
To: 'Elwyn Davies' <[e-mail]<mailto:[e-mail]>>
Subject: RE: Post-telechat review of   draft-ietf-lime-yang-connectionless-oam-16

Incorporated your comments in v-17,
https://tools.ietf.org/rfcdiff?url2=draft-ietf-lime-yang-connectionless-oam-17.txt

-Qin
-----邮件原件-----
发件人: Qin Wu
发送时间: 2017年11月10日 15:08
收件人: Elwyn Davies <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: RE: Post-telechat review of draft-ietf-lime-yang-connectionless-oam-16

Thanks Elwyn for taking last sanity check. We will wrap up your comments in v-(17)

-Qin
-----邮件原件-----
发件人: Elwyn Davies [mailto:[e-mail]]
发送时间: 2017年11月10日 3:28
收件人: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: Post-telechat review of draft-ietf-lime-yang-connectionless-oam-16

Hi.
Some remaining comments from the earlier gen-art reviews that perhaps ought to be addressed plus some additional introduced nits. Apologies for the long  delay - I failed to notice that -16 had been published and gen-art reviewers don't get new version notifications.

Minor Issues:

Sources of imported models:  It would be useful to list the RFCs/I-Ds that define the models that are imported as a new section before the YANG definitions.  Currently draft-ietf-netmod-schema-mount, draft-ietf-rtgwg-ni-model and draft-ietf-rtgwg-routing-types that are under development are not mentioned; the existing standards of RFC 6021 and RFC 7223 should also be referenced (7223 is).  They should all be normative.  [The references are present but they need to be linked to the module names and listed separately from the YANG specification.]

Nits:

s1, bullet 1: s/networks/network/

[Qin]: Fixed.

s1, end of para 7: s/OAM protcols/OAM protocols/

[Qin]: Fixed.

s1, last para: s/Connectionless Communicatioms/connectionless communications/

[Qin]: Fixed.

s2.2, TP definition: s/diagnostic test/diagnostic tests/

[Qin]: Fixed.

s3, para 10 (top of page 6): s/test- point/test-point/

[Qin]: Fixed.

s3, last para: The term 'proactive' has not yet been defined.  A forward reference to s3.2 is needed (e.g., "proactive (see Section 3.2)").

[Qin]: Fixed.

s3.2, last para: s/be extended to specific OAM technology/is extended to cover a specific OAM technology/

[Qin]: Fixed.

s3.3, para 2:
OLD:

    OAM neighboring test points are referred to a list of neighboring
    test points in adjacent layers up and down the stack for the same
    interface that are related to the current test point.

NEW:

    Each OAM test point may have an associated list of neighboring
    test points in other layers up and down the protocol stack for the same
    interface and are therefore related to the current test point.
ENDS

[Qin]: Accepted.

ss3.6 and 3.7:
The use of single quotes and associated spacing in these sections is not correct, and there are some other language corrections.
The corrected version is suggested here:
NEW:
3.6.  Path Discovery Data

    This is a generic grouping for the path discovery data model that can be
    retrieved by any data retrieval methods including RPC operations.
    Path discovery data output from methods, includes 'src-test-point'
    container, 'dst-test-point' container, 'sequence-number'leaf, 'hop-
    cnt'  leaf, session statistics of various kinds, path verification and
    path trace related information.  Path discovery includes data to be
    retrieved on a 'per-hop' basis via a list of 'path-trace-info-
    list' items which includes information such as 'timestamp' grouping,
    'ingress-intf-name', 'egress-intf-name' and 'app-meta-data'.  The
    path discovery data model is made generic enough to allow different
    methods of data retrieval.  None of the fields are made mandatory for
    that reason.  Note that a set of retrieval methods are defined in
    [I-D.ietf-lime-yang-connectionless-oam-methods].

3.7.  Continuity Check Data

    This is a generic grouping for the continuity check data model that can
    be retrieved by any data retrieval methods including RPC operations.
    Continuity check data output from methods, includes 'src-test-
    point' container, 'dst-test-point' container, 'sequence-number' leaf,
    'hop-cnt' leaf and session statistics of various kinds.  The
    continuity check data model is made generic enough to allow different
    methods of data retrieval.  None of the fields are made mandatory for
    that reason.  Noted that a set of retrieval methods are defined in
    [I-D.ietf-lime-yang-connectionless-oam-methods].

ENDS

[Qin]: Accepted.

s5: The import items should have a description indicating the modules from which they come including the relevant RFC numbers.  Note this is in addition to a section in the introductory text summarisng what modules are imported (as noted in minor issues).

[Qin]: Good suggestion and will fix this.

s5, "container path=trace-info" description: s/like/such as/

[Qin]: Fixed.

s5. "grouping timestamp":
It would be good to add references (including section numbers) to the description showing where the various timestamps are defined in the IEE PTP doc and the NTP RFC.

[Qin]: Fixed.

s5, "container timestamp-64bit": I believe there is a typo in the description:
OLD:
"Only applies when Truncated NTP or 64bit NTP Timestamp.";
NEW:
"Only applies when Truncated PTP or 64bit NTP Timestamp.";
[Qin]: Fixed.