On Wed, Sep 26, 2018 at 10:59:50PM +0000, Les Ginsberg (ginsberg) wrote: > Benjamin - > > Responses nline. > > > -----Original Message----- > > From: Benjamin Kaduk <kaduk@xxxxxxx> > > Sent: Wednesday, September 26, 2018 2:11 PM > > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx> > > Cc: David Waltermire <david.waltermire@xxxxxxxx>; secdir@xxxxxxxx; > > lsr@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-isis-segment-routing-msd.all@xxxxxxxx > > Subject: Re: Secdir last call review of draft-ietf-isis-segment-routing-msd-16 > > > > On Wed, Sep 26, 2018 at 08:45:03PM +0000, Les Ginsberg (ginsberg) wrote: > > > David - > > > > > > Thanx for the review. > > > A new version of the draft (17) has been published to address your > > comments - subject to my responses below. > > > > Just in time for me to see the updated version for my IESG review; thanks. > > > > > > -----Original Message----- > > > > From: David Waltermire <david.waltermire@xxxxxxxx> > > > > Sent: Tuesday, September 25, 2018 12:14 PM > > > > To: secdir@xxxxxxxx > > > > Cc: lsr@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-isis-segment-routing- > > > > msd.all@xxxxxxxx > > > > Subject: Secdir last call review of > > > > draft-ietf-isis-segment-routing-msd-16 > > > > > > > > Reviewer: David Waltermire > > > > Review result: Has Issues > > > > > > > > I have reviewed this document as part of the security directorate's > > > > ongoing effort to review all IETF documents being processed by the > > > > IESG. These comments were written primarily for the benefit of the > > > > security area directors. > > > > Document editors and WG chairs should treat these comments just > > > > like any other last call comments. > > > > > > > > The summary of the review is Ready with (minor) issues > > > > > > > > My apologies for the late review on this draft. Overall I found this > > > > document to be well-written, and concise. > > > > > > > > General Comments: > > > > > > > > This document uses a mix of case around RFC2119 language (e.g., MAY > > may). > > > > You should use text from RFC8174 to indicate that lowercase versions > > > > of the keywords are not normative, or adjust the case of the > > > > lowercase words to ensure there is no confusion. > > > > > > > [Les:] Section 1.2 does include the standard boilerplate for RFC > > 2119/RFC8174. > > > > > > I checked all the lower case uses of "may" and they are intentional. > > > There was one instance of "should" that I changed to uppercase. > > > > > > > Minor nit: There is some inconsistency in the use of "MSD-Type" (the > > > > value) and "MSD type" (the concept). Suggest cleaning this up. > > > > > > > [Les:] Done > > > > > > > Specific comments: > > > > > > > > Section 1: > > > > > > > > Para 1: s/to insure/to ensure/ > > > > > > [Les:] Done. > > > > > > > > > > > Section 4: > > > > > > > > The last paragraph establishes a requirement on the registration of > > > > an MSD Type to define what the absence of a given MSD Type means. > > > > This is an important requirement that must be addressed during > > > > registration of new MSD Types. IMHO, this requirement should be > > > > echoed in the registration information in section 6 to make sure it is not > > overlooked. > > > > > > > [Les:] I disagree. Section 6 is defining exactly what should go into the new > > IANA registry. > > > The definition of "absence" is something that will have to be provided in > > the documents which define new MSD-types, but that will NOT be captured > > in the registry so including this in Section 6 isn’t appropriate. > > > > I think a good way to think about this is as giving guidance to the Experts, that > > they should not approve registration requests that fail to provide this > > information along with the request. Guidance for the Experts is appropriate > > in the IANA Considerations section. > > (Also, my understanding is that IANA prefers to have a more explicit > > template for new registrations to follow, though I should not try to speak for > > them.) > > > > [Les:] The reason we use "experts" is because we know/expect them to be familiar with the documents which define the TLVs (unlike a "general IETF reader" whose familiarity with the subject matter may vary). > Repeating what is said in Section 4 in Section 6 only makes sense if you think the "expert" only reads IANA sections. Such a person would not be an expert IMO. :-) I suspect that the experts would prefer to receive a high proportion of requests that meet the criteria the experts are going to apply, rather than constantly telling people they need to go fix the same thing and come back. It's best practice to be clear about what is required for a successful registration. -Benjamin
