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

["Andrew G. Malis" <[e-mail]>]

Stewart,

Glad to be of assistance.

Cheers,
Andy


On Thu, Jan 2, 2020 at 9:09 AM Stewart Bryant <[e-mail]>
wrote:

>
> Hi Andy
>
> Thank you for the review.
>
> > On 30 Dec 2019, at 19:31, Andrew G. Malis <[e-mail]> 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
> >
>
>