Re: [Gen-art] Genart last call review of draft-ietf-spring-segment-routing-ldp-interop-11

[Joel Halpern Direct <[e-mail]>]

Thank you.  I apologize for missing the other normative items.  With 
those, plus the elaboration on the SRMS, the status as PS makes good sense.

Yours,
Joel

On 5/21/18 11:45 AM, Ahmed Bashandy wrote:
> Thanks a lot for the review
> 
> The document specifies externally visible behavior that must be 
> implemented by routers, otherwise SR and LDP routers cannot talk to each 
> other. For example, section 4.2.2  specifies preference rules. Another 
> example is the last two paragraphs in section 4.2.1. Hence I do not 
> think it can be informational. A third example is section 4.2 which 
> requires the existence of one SRMS in order for SR-only to speak to 
> LDP-only routers
> 
> But I agree that a more crisp description of SRMS is warranted. I will 
> add a section describing the SRMS functionality and specifying what to 
> do when receiving both prefix-SID sub-tlv and SRMS advertisements in the 
> next version, which I plan to send out in the next few days
> 
> 
> Ahmed
> 
> 
> 
> On 5/14/18 1:01 PM, Joel Halpern wrote:
>> Reviewer: Joel Halpern
>> 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-spring-segment-routing-ldp-interop-11
>> Reviewer: Joel Halpern
>> Review Date: 2018-05-14
>> IETF LC End Date: 2018-05-24
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary: This document appears to be ready for publication as an RFC.  
>> The
>> question of whether it is an Informational RFC or a Proposed Standards 
>> track
>> RFC is one that the ADs should examine.
>>
>> Major issues:
>>      This document is quite readable, and quite useful.  If my reading 
>> below
>>      (minor comment about section 4.2) is wrong, then everything is fine.
>>      However, reading the text, it does not appear to define SRMS.  
>> Rather, it
>>      describes a good way to use SRMS to achive smooth SR - LDP 
>> integration and
>>      migration.  As such, this seems to me to be a really good 
>> Informational
>>      Document.
>>
>> Minor issues:
>>      Section 4.2 states that it defines the SRMS (Segment Routing Mapping
>>      Server).  Looking at the relevant routing protocol document, they 
>> point to
>>      
>> https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 
>> as the
>>      defining source for the SRMS.  And that document does appear to 
>> define the
>>      SRMS.
>>
>> Nits/editorial comments:
>>
>>
>