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

"Andrew G. Malis" <agmalis@gmail.com> Thu, 02 January 2020 14:40 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 2310312004F; Thu, 2 Jan 2020 06:40:44 -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, 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 rys4hwqsC6iW; Thu, 2 Jan 2020 06:40:41 -0800 (PST)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 487DB120018; Thu, 2 Jan 2020 06:40:41 -0800 (PST)
Received: by mail-qv1-xf2a.google.com with SMTP id dc14so15052860qvb.9; Thu, 02 Jan 2020 06:40:41 -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=3HzZx+g2O5OXVnMgzRvsQDjTwp+bFsMiKfTuvxIG5i8=; b=bELXP7stjDivCtwSN+nkRjJcCIzJZ6W8Djon7++bQjTWbqZVdzhndJncky8FLlqtut V7K0COm59gxWHR++dbaCBvcDDeLT85l3prAR/B9KpY7t95YkR5VaDlx5R1r4fHpzjfaT Ez8Tozd8Lrb91D6pVqiveq+ftF8vTAVcyxGrwCUyc1Y4cN+0d4iW4et1qzD4XEzTNIiV SbZxdCZA2c0BcbIALllAV0aTjzfkTSmjckP8BWRxbw3TQhflWoNAy4x9R6CAubSgkEYc fA56uBYvPr2Ai0p0Jj79pl/BJu8XXZzPQNfXNrHs5g51LVi9OK/BRLMvhSpS/js2Dj1Y 78Xg==
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=3HzZx+g2O5OXVnMgzRvsQDjTwp+bFsMiKfTuvxIG5i8=; b=Xgxua+JjZ6WxvIAhIcD9SLtcXtQJr5+EPW/jX25WRmIIx55apekK90K7PD/VTX3sje 7zXffc0bMciTYfH9CMbWwejRhrZBeSbaipgn37y0IxKx5uKMpMQB1VwYowpmU6cM4+1c rXNCa1NqwJnDADj1Hu5tfm+E3jDBEe0Uvs1zxiJrZKIGHLiUijug3p/rBQhPmgqAayIr qD4GFGjw+Cb+fZCeunrWWVBWWYlrptdVFs/GSq/3bCIZGcGy6QWBVZfmr2SxVMkoAC/H j/ag5LMC9v5fAG5yScop9x9bTptIPZkmwcp4Pyvf517uV5fKRWVL1Ey/sOujwcrmzUll WLKQ==
X-Gm-Message-State: APjAAAVr1xST6fJFDBDOMb9kZ8T48SPZJ9GL5XeEBQjGWLxTIfgW/VU8 xQ5SQZ8gWg5AxRvSAPfX9/niUCjrLc/d0orWPqE=
X-Google-Smtp-Source: APXvYqwD6sxjiHbO9DcZuBEhseZ3jsg2BDa4EEs5cPthSeKang1DuAPNlnqq+Js97o2Ruthb7Jm4brR5ginkDSIALwU=
X-Received: by 2002:a0c:ada3:: with SMTP id w32mr61225755qvc.99.1577976040336; Thu, 02 Jan 2020 06:40:40 -0800 (PST)
MIME-Version: 1.0
References: <CAA=duU3_AaiH4J7o0vai=KCL_LY93e2xc0JQO3t6WsUSWM3dJg@mail.gmail.com> <F395ECEC-E39D-4AE1-8277-11A73DC3EF71@gmail.com>
In-Reply-To: <F395ECEC-E39D-4AE1-8277-11A73DC3EF71@gmail.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Thu, 2 Jan 2020 09:40:29 -0500
Message-ID: <CAA=duU18ZJoamK_tZcUP=3pJTmA7OYP+Pa8bu9-wtcPu-6DzLg@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="000000000000593196059b292da6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/qD8si5A0DNjlEv4TjtqdeRsmjTk>
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:40:44 -0000

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
> >
>
>