Hi Paul, Many thanks for your review! Please see inline
Cheers, Jeff On 8/27/18, 10:33, "Paul Kyzivat" <[email protected]> wrote: 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-ospf-segment-routing-msd-17 Reviewer: Paul Kyzivat Review Date: 2018-08-27 IETF LC End Date: 2018-08-29 IESG Telechat date: ? Summary: This draft is on the right track but has open issues, described in the review. Issues: Major: 0 Minor: 3 Nits: 1 1) MINOR: The abstract says: This document defines only one type of MSD, but defines an encoding that can support other MSD types. and later section 1 says: It also defines the Base MPLS Imposition MSD type. I can find nothing in the document that does this definition. It seems that this definition is actually done by draft-ietf-isis-segment-routing-msd, which is referenced. The text needs to agree with the structuring of the documents. [jeff] ack, in the previous version BMI was defined on both, ospf and isis, removed 2) MINOR: Section 1 also says: Although MSD advertisements are associated with Segment Routing, the advertisements MAY be present even if Segment Routing itself is not enabled. I found nothing else in the document that elaborated on this. Further explanation is needed, in a section other than the introduction. [jeff] the meaning of the statement is that MSD MAY be advertised even if Segment Routing is not enabled, ie MSD(s) advertisement could be used by any other application that would find the data provided of value. I would appreciate, if you could be more specific about what's missing. 3) MINOR: The first paragraph of section 4 says: When Link MSD is present for a given MSD type, the value of the Link MSD MUST take preference over the Node MSD. When a Link MSD type is not signalled but the Node MSD type is, then the value of that *Link* MSD type MUST be considered as the corresponding *Node* MSD type value. This appears to have scrambled the use of Link and Node a bit. I think it is intended to say: When Link MSD is present for a given MSD type, the value of the Link MSD MUST take preference over the Node MSD. When a Link MSD type is not signalled but the Node MSD type is, then the value of that Node MSD type MUST be considered as the corresponding Link MSD type value. [jeff]ack, changed 4) NIT: Section 2 uses: 'The Type:' when documenting the "Type" field of the TLV, while sections 3 uses: 'Type:'. These ought to be consistent. [jeff]ack, changed _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
