Re: [Gen-art] Genart last call review of draft-ietf-mpls-ldp-yang-06

[Alissa Cooper <[e-mail]>]

Theresa, thanks for your review. I entered a No Objection ballot supporting Roman’s and Benjamin’s DISCUSS ballots, which note the items you mention below about the security considerations and IPv6, respectively.

Alissa


> On Sep 25, 2019, at 3:50 AM, Theresa Enghardt via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Theresa Enghardt
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-mpls-ldp-yang-06
> Reviewer: Theresa Enghardt
> Review Date: 2019-09-25
> IETF LC End Date: 2019-10-04
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> This draft is basically ready for publication, but has some minor issues that
> should be fixed before publication.
> 
> Major issues: None.
> 
> Minor issues:
> 
> Section 1.1:
> 
> Why is LDP IPv6 grouped in the "extended" category and not in the "base"
> category, which the draft states to be the "minumum requirements for a typical
> base LDP deployment" and "suffice for small deployments"? Are typical, small
> deployments usually IPv4-only, and is this expected to remain true? Please
> consider briefly explaining this design decision.
> 
> What does "igp sync" refer to? Is this the same as "igp-synchronization-delay"
> in the extended model? Please consider expanding this abbreviation and/or
> providing a reference.
> 
> Section 3:
> 
> Could you provide references for the "widely deployed non-RFC features", which
> are part of the extended model, please?
> 
> "GR session is in recovery state" - What does "GR" refer to?
> 
> Section 10:
> 
> In the Security Considerations, it would be great if you could provide some
> examples of writable/creatable/deletable data nodes which may be considered
> sensitive or vulnerable, and what negative effects on network operations one
> could expect if an attacker wrote to them.
> 
> Nits/editorial comments:
> 
> The document doesn't use any RFC 2119 keywords, yet has text resembling RFC
> 2119 boilerplate text. Please consider removing the RFC 2119 boilerplate text.
> 
> The document contains a few typos and grammar issues.
> To improve readability, please check for consistency of upper/lower case terms,
> for the use of definite and indefinite articles, and consider running a
> spellchecker.
> 
> Some examples:
> 
> Section 1.1:
> 
> "The configuration and state items are divided into following two broad
> categories" --> "The configuration and state items are divided into the
> following two broad categories"
> 
> "This is worth higlighting " --> "It is worth highlighting"
> 
> Section 3:
> 
> "yang" - should this be all caps?
> 
> "rpc" - should this be all caps?
> 
> "grapically" --> "graphically"
> 
> Section 5.2.1:
> 
> "This container falls under global tree" --> "This container falls under the
> global tree"
> 
> "The example of former is interface hello timers, and example of latter is
> enabling hellos for a given AF under an interface." --> "The example of the
> former is interface hello timers, and an example of the latter is enabling
> hellos for a given AF under an interface."
> 
> "A peer is uniquely identified using its LSR Id and hence LSR Id is the key for
> peer list" [missing punctuation]
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art