Subject: [mpls] Genart last call review of draft-ietf-mpls-sfl-framework-08

From: Pete Resnick via Datatracker <[email-masked]>
Date: Mon, 29 Jun 2020 10:30:11 -0700

Reviewer: Pete Resnick
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-mpls-sfl-framework-08
Reviewer: Pete Resnick
Review Date: 2020-06-29
IETF LC End Date: 2020-07-06
IESG Telechat date: Not scheduled for a telechat

Summary:

A couple of minor issues and a couple of *extremely* nitty nits, but overall
looks ready to go.

Major issues:

None.

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.

The Security Considerations section says, "The issue noted in Section 6 is a
security consideration." I'm not sure I understand why that is.

Nits/editorial comments:

Section 1: "(see Section 3)" seems unnecessary.

Section 3: I thought the "Consider..." construction made those paragraphs
unnecessarily wordy and a bit harder to follow.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 Jun 2020 13:24:34 +0100

> On 29 Jun 2020, at 18:30, Pete Resnick via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Pete Resnick

Pete - the “tradition” 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.

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

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

> 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 for the comments

Stewart

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 30 Jun 2020 11:55:01 -0500

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

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

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

> I can take that out on the next version, it was intended as a forward 
> reference to a completely new contract in MPLS.
>

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