Re: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]>

> Sent: Wednesday, September 26, 2018 4:06 PM

> To: Les Ginsberg (ginsberg) <[e-mail]>

> Cc: David Waltermire <[e-mail]>; [e-mail];

> [e-mail]; [e-mail]; [e-mail]

> 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 <[e-mail]<mailto:[e-mail]>>

> > > Sent: Wednesday, September 26, 2018 2:11 PM

> > > To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>

> > > Cc: David Waltermire <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;

> > > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> > > [e-mail]<mailto:[e-mail]>

> > > 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 <[e-mail]<mailto:[e-mail]>>

> > > > > Sent: Tuesday, September 25, 2018 12:14 PM

> > > > > To: [e-mail]<mailto:[e-mail]>

> > > > > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> > > > > draft-ietf-isis-segment-routing- [e-mail]<mailto:[e-mail]>

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