Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-control

"Andrew G. Malis" <agmalis@gmail.com> Thu, 02 January 2020 14:47 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7875D12004F; Thu, 2 Jan 2020 06:47:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 igZUsokIDFyo; Thu, 2 Jan 2020 06:47:33 -0800 (PST)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB72120018; Thu, 2 Jan 2020 06:47:33 -0800 (PST)
Received: by mail-qk1-x736.google.com with SMTP id t129so31477330qke.10; Thu, 02 Jan 2020 06:47:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GgV3gW6R5ZZ5Mviio5X1vJoHj0DxRslVBE89O9pT4Wk=; b=pkC4Li/ZZwI4yAgFNu45ysFvTRqnE56lO1Ybp7tE1dlST+CTIyU5pJO67IFW2VtamV E9xVQNbJfc/FKfkmlnSN+m/xmZRMDQms/4Qen386PnEKE8ab3hMEz9BzQfCmM8CU69bS n8C41ye2Xs+BaCiK7ZUzcdT+wr1pCGzIyKqy89zNtODN5Vbjm3C6Na5FiKBzfRh6Dzvl FdydulhANx0CIT9RYdjzY8VB7zIrKDWWs3nvLEoagZpNaJBiUNKdRYq1b6ZDeQpMFGCn SPvL//ZhxENFQMhsFmU/q5RycxLhN4CaNoE7xxrpSn8TnsguOXRQgar++N/KvKSbldnG wbAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GgV3gW6R5ZZ5Mviio5X1vJoHj0DxRslVBE89O9pT4Wk=; b=VKHeCTLGzo6gK9TyvLNLdDT+++Yq2wV6bXEJrDBLXD6dNZDiWw61NqeRDBICZXJScx ynudfT8+g5Mvt94wZkLACFGzYtptYPJohs7u2DAK3MBgjze6QAsjDM6m+EZFHXYOtGqO XrjsjGYHTYqD6NIRF+eA5LV7rtHfCGm54TFiW9eVAPAqPsJxa6SKkm+n1uv4sxusOzl7 4rEQfte4iiCXChKjPzpQxsBxaltMX2dTyE7TqF4XZrvkkzzkMzdjukBW+Nrqoog8dNI+ kCLOuC88WYcfH6+ubVJdkUw9Tu01srRyHupIogQGKQt5KZVyPNRv8ZPBSZp9ut9IkfuB LhrQ==
X-Gm-Message-State: APjAAAWM8Ogg/ooxOUrMLtjRJdetdM3yUQSqlwX0vG15HTtjiaKxhM2y hkHTyw+eQ8wo28NhzUBVQgTnixwJTtZ0o3ahi5A=
X-Google-Smtp-Source: APXvYqyFT1eL2SSzJJgF9JuDEqQ+YsmJabxfYCb/8VNgcHX8SFShwDIwbHuHYMU3AH3RaEVreVfGPv3ksgoGEsYFK3s=
X-Received: by 2002:a37:c24b:: with SMTP id j11mr64415268qkm.57.1577976452600; Thu, 02 Jan 2020 06:47:32 -0800 (PST)
MIME-Version: 1.0
References: <CAA=duU3_AaiH4J7o0vai=KCL_LY93e2xc0JQO3t6WsUSWM3dJg@mail.gmail.com> <F395ECEC-E39D-4AE1-8277-11A73DC3EF71@gmail.com> <CAA=duU18ZJoamK_tZcUP=3pJTmA7OYP+Pa8bu9-wtcPu-6DzLg@mail.gmail.com>
In-Reply-To: <CAA=duU18ZJoamK_tZcUP=3pJTmA7OYP+Pa8bu9-wtcPu-6DzLg@mail.gmail.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Thu, 2 Jan 2020 09:47:21 -0500
Message-ID: <CAA=duU1yW+rpn2PXkUg7Kd23HiUpDb7CMnke9M62usHQG8_rkg@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: draft-bryant-mpls-sfl-control@ietf.org, mpls <mpls@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ebd5e9059b2945e3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/iU0BAoneGMBEXocJqrZAGGMP8GE>
Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-control
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2020 14:47:37 -0000

Stewart,

Looking at the diff from the previous version, I just noticed a typo that I
missed earlier. In the first paragraph of the introduction, "withdrawn"
should be "withdraw". I also see that you added an Oxford comma, which is
fine by me! :-)

Cheers,
Andy


On Thu, Jan 2, 2020 at 9:40 AM Andrew G. Malis <agmalis@gmail.com> wrote:

> Stewart,
>
> Glad to be of assistance.
>
> Cheers,
> Andy
>
>
> On Thu, Jan 2, 2020 at 9:09 AM Stewart Bryant <stewart.bryant@gmail.com>
> wrote:
>
>>
>> Hi Andy
>>
>> Thank you for the review.
>>
>> > On 30 Dec 2019, at 19:31, Andrew G. Malis <agmalis@gmail.com> wrote:
>> >
>> > All,
>> >
>> > I’ve been selected as an MPLS-RT reviewer for
>> draft-bryant-mpls-sfl-control,
>> > which is currently a candidate for MPLS WG adoption.
>> >
>> > In general I believe that the draft is ready for WG adoption. However,
>> I have a few minor comments which may be addressed either before or after
>> WG adoption.
>> >
>> > 1. The Security Considerations section says "It is assumed that this
>> protocol is run in a well managed MPLS network with strict access controls
>> preventing unwanted parties from generating MPLS OAM packets." While this
>> is true of most (all?) MPLS networks, this assumption should also be stated
>> in the abstract or Introduction as well.
>>
>> I have added a line to the Introduction.
>>
>> I generally work on the assumption that the purpose of the Abstract is to
>> help the potential reader decide if they want to read the document (or more
>> likely to help a search engine match the document against a query) and I am
>> unconvinced as to value of the qualification text in deciding whether to
>> read the rest of the document.
>>
>>
>> >
>> > 2. Section 8 contains the line "Force references to appear with mkd
>> [RFC3032] [RFC5036]". However, both references appear elsewhere as well, so
>> this line can be removed.
>>
>> The earlier references are in text that I included as a figure to force
>> the layout style I wanted, and the markdown compiler ignores references in
>> figures. The compiling process excluded unused references so they have to
>> be forced. I have changed the text to
>>
>> RFC Editor please remove this note which is used to force the following
>> references to appear {{RFC3032}} {{RFC5036}}
>>
>> >
>> > 3. I would move "I-D.ietf-mpls-sfl-framework" to the Normative
>> References, as understanding it is necessary to understand this draft.
>> >
>>
>> The framework is informational and so the reference would become a
>> down-ref. I will leave it to the chairs and ADs on how they want to proceed
>> with this. It is not unusual for a framework to be required reading and yet
>> informational.
>>
>>
>> > 4. The text in Section 2 is out of date. The current wording is:
>> >
>> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>> "OPTIONAL" in this document are to be interpreted as described in BCP 14
>> [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as
>> shown here.
>> >
>> > RFC 8174 should also be added as a normative reference.
>>
>> Done
>>
>> >
>> > 5. When this draft was last updated, Stewart included the following in
>> an email message to the MPLS WG:
>> >
>> > "Next to do is authors of draft-bryant-mpls-sfl-control to check that
>> > this is suitable to be called by another protocol to act on its behalf.
>> > When we are satisfied that that is that case and any consequentially
>> > necessary amendments have been make to the other drafts we will
>> > request adoption of draft-bryant-mpls-sfl-control and then WGLC on all
>> > three."
>> >
>> > There's been no follow-up indication that this analysis has occurred,
>> or further revision to the draft. If it has, the authors should indicate as
>> such on the list. If it hasn't, then this will serve as a reminder to the
>> authors.
>>
>>
>> George and I discussed this and concluded that the design was
>> satisfactory.
>>
>> I certainly indicated this to the chairs but I cannot remember if I
>> posted that to the list. If any reader of this note (which will go to the
>> MPLS list) has any technical concerns WRT this point, please raise them and
>> we will work with you to address the issue.
>>
>> New version (05) has been uploaded.
>>
>> Best regards
>>
>> Stewart
>>
>>
>>
>> >
>> > Thanks,
>> > Andy
>> >
>>
>>