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.

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.

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.

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.