|
Benjamin - Please review
https://tools.ietf.org/html/rfc8126#section-1.1 In particular (emphasis added): " The purpose of having a dedicated IANA Considerations section is to provide a single place to collect clear and concise information and instructions for IANA. Technical documentation should reside in other parts of the document…” I think what you propose is not consistent with the intent of the IANA section. Thanx. Les > -----Original Message----- > From: Benjamin Kaduk <kaduk@xxxxxxx> > Sent: Wednesday, September 26, 2018 4:06 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 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 |
