> On 29 Jun 2020, at 18:30, Pete Resnick via Datatracker <noreply@xxxxxxxx> wrote: > > 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. 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. > > 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. > > 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 for the comments Stewart > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
