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

[Elwyn Davies <[e-mail]>]

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/

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

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

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

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

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

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

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

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

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

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

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.

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