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

Joel Halpern Direct <jmh.direct@joelhalpern.com> Mon, 14 May 2018 20:16 UTC

Return-Path: <jmh.direct@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996DF12D95B; Mon, 14 May 2018 13:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98YFZEJEJYlQ; Mon, 14 May 2018 13:16:10 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F7712D960; Mon, 14 May 2018 13:16:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 692F39C0710; Mon, 14 May 2018 13:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1526328967; bh=EM0dc8IXa6xZuKNQ6UpiGWFcBVnNaPcbOE1/+yYZbOU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JCCuZ35cCh/b59ONM9qUR9hWc3cF5hrmdor3Hq3Et7XDqIQiwY+3ZMOLLngCx5ufD wG/CYasrcf4AXBqW4RP7uNQ8i+HbawTNUYMMyo5cTWk7/DTYvwhw8DSM+UC5uzX1n3 7Fu4jgE+nzsiVWV9aQHcpoXSFKu9wXrvWq44hT/Y=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9E0B89C06E3; Mon, 14 May 2018 13:16:05 -0700 (PDT)
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Joel Halpern <jmh@joelhalpern.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "draft-ietf-spring-segment-routing-ldp-interop.all@ietf.org" <draft-ietf-spring-segment-routing-ldp-interop.all@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
References: <152632807068.10078.4478550408904407310@ietfa.amsl.com> <e53fa35538f042d98bde5e4e82f621d6@XCH-ALN-001.cisco.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <8050bc23-d648-4ac8-ff4c-1978d6ecc9d9@joelhalpern.com>
Date: Mon, 14 May 2018 16:16:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <e53fa35538f042d98bde5e4e82f621d6@XCH-ALN-001.cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/tjL5vVlm0-By9jMqEEnXf6pR2yw>
Subject: Re: [Gen-art] [spring] Genart last call review of draft-ietf-spring-segment-routing-ldp-interop-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 20:16:13 -0000

Thanks Les.  I wondered if that were the case.

Looking again at the draft, the problem then is that section 4.2 of the 
subject draft is not a normative definition of an SRMS.  It states the 
general functionality, and then provides an example of how it would work 
in the given scenario.

If the text were enhanced to be an effective normative definition of an 
SRMS, then that would also resolve the quesiton of the intended status 
of the draft.

Yours,
Joel

On 5/14/18 4:12 PM, Les Ginsberg (ginsberg) wrote:
> Joel -
> 
> I am not an author of this draft - but I am an author on the referenced IS-IS draft - which I assume is one of the drafts mentioned in  your comment:
> 
>>      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.
> 
> The IGP document references in the ldp-interop draft are stale. Newer versions of the IGP drafts have been published and they no longer reference draft-ietf-spring-conflict-resolution - a draft which is no longer active.
> 
> HTH
> 
>      Les
> 
> 
>> -----Original Message-----
>> From: spring <spring-bounces@ietf.org> On Behalf Of Joel Halpern
>> Sent: Monday, May 14, 2018 1:01 PM
>> To: gen-art@ietf.org
>> Cc: draft-ietf-spring-segment-routing-ldp-interop.all@ietf.org;
>> spring@ietf.org; ietf@ietf.org
>> Subject: [spring] Genart last call review of draft-ietf-spring-segment-routing-
>> ldp-interop-11
>>
>> 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:
>>
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring