Re: [Gen-art] Genart last call review of draft-ietf-mpls-sfl-framework-08

Pete Resnick <resnick@episteme.net> Tue, 30 June 2020 16:55 UTC

Return-Path: <resnick@episteme.net>
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 577053A0C76; Tue, 30 Jun 2020 09:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 rs6n1qZEIBnN; Tue, 30 Jun 2020 09:55:19 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1A63A0C50; Tue, 30 Jun 2020 09:55:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 897FAB2B8455; Tue, 30 Jun 2020 11:55:03 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR979xsu12kQ; Tue, 30 Jun 2020 11:55:02 -0500 (CDT)
Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 3DD44B2B8445; Tue, 30 Jun 2020 11:55:02 -0500 (CDT)
From: Pete Resnick <resnick@episteme.net>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: Review Team <gen-art@ietf.org>, mpls <mpls@ietf.org>, draft-ietf-mpls-sfl-framework.all@ietf.org, Last Call <last-call@ietf.org>, rtg-ads@ietf.org
Date: Tue, 30 Jun 2020 11:55:01 -0500
X-Mailer: MailMate (1.13.1r5693)
Message-ID: <B6EA27BB-72F2-4E91-8B90-4D4DC2262E03@episteme.net>
In-Reply-To: <C575861D-0C01-4245-9B36-A3E5B17F6D4F@gmail.com>
References: <159345181106.6204.7060455676708406175@ietfa.amsl.com> <C575861D-0C01-4245-9B36-A3E5B17F6D4F@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/7sdAHw0oWPL8-0PCpAGp_iQZI3E>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-mpls-sfl-framework-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 30 Jun 2020 16:55:21 -0000

On 30 Jun 2020, at 7:24, Stewart Bryant wrote:

>> On 29 Jun 2020, at 18:30, Pete Resnick via Datatracker 
>> <noreply@ietf.org> wrote:
>>
>> Minor issues:
>>
>> It is not clear to me why this is being sent for Informational 
>> instead of
>> Proposed Standard. The shepherd's writeup does not justify it, and in 
>> fact the
>> writeup refers to the document as a "specification", which is exactly 
>> what it
>> appears to be. It defines the use of SFLs, describes how they are 
>> processed by
>> the endpoints, describes how they are aggregated, etc. While the 
>> document may
>> not be standalone, I don't see how it's really an Informational 
>> document. I
>> suggest restarting the Last Call for Proposed, and if for some reason 
>> it needs
>> to be Informational, it can always be downgraded after Last Call.
>
> Pete - the “tradition”...

I hear songs from "Fiddler on the Roof" in my head...

> ...in routing is that such documents are Informational and the 
> detailed protocol specifications are standards (there are a couple of 
> those in progress about to finish baking). I leave it up to our AD to 
> pass judgement on the matter as this is a simple fix, but I don’t 
> think the changed status is REQUIRED.

Absolutely agreed that it is not required, but given that this does 
contain specification, and how much less scrutiny is given to 
Informational document as against Standards Track (see, for example, the 
IESG balloting rules on each), Standards Track seems more sensible. But 
the world remains intact either way.

>> The Security Considerations section says, "The issue noted in Section 
>> 6 is a
>> security consideration." I'm not sure I understand why that is.
>
> Section 6 explains the privacy considerations, and privacy and 
> security are close friends so I cross referenced the section rather 
> than repeating it. I suggest that we wait to see what SECDIR wants to 
> do before changing any text.

Yes, glad to defer to SECDIR on this.

>> Nits/editorial comments:
>>
>> Section 1: "(see Section 3)" seems unnecessary.
>
> I can take that out on the next version, it was intended as a forward 
> reference to a completely new contract in MPLS.
>
>> Section 3: I thought the "Consider..." construction made those 
>> paragraphs
>> unnecessarily wordy and a bit harder to follow.
>>
> I will reword the first two sentences  para 2 of section 3 to simplify 
> the language.

Thanks. As I said, both very minor things.

> Thanks for the comments

My pleasure. Thanks for your quick followup.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best