Hi Roman, Thank you for your comments.
> ** Section 2 > > The registration procedure for the "IS-IS Neighbor Link-Attribute Bit > Values" registry is changed to be "Expert Review". General guidance > for the designated experts is defined in [RFC7370] and more specific > guidance can be found in [RFC5029]. > > I read through RFC5029 and didn’t find any text scoped as guidance to the > designated expert. RFC 5029 created the registry that we are modifying. Thus, it behooves the designated expert to be familiar with RFC 5029. The more specific guidance is relative to the registry and functionality that is captured in the registrants. > I read through Section 4 of RFC7370 and had the following questions: > > -- Per “The Designated Experts SHOULD then review the assignment requests > > on their technical merit”, is there any further guidance? When would the DE > not evaluate the request on technical merits? If a Designated Expert was acting inappropriately, there is an unbounded number of factors that they could consider, including the phase on the moon, the affiliations of the authors, or whether last night’s dinner was satisfactory. > -- Is the WG confident that “expert review” is the correct registration > policy? > I ask because the text in this section seems to be preferring a reference of > some kind which hints that “specification required” (which also includes an > expert review and could be an I-D) might be more appropriate. Yes. All other IS-IS registries are already under “expert review”. This has functioned well to date, up until us trying to make an experimental entry in this registry. We choose “expert review” to “specification required” because we put more weight in the opinions of the experts than in the fact that someone has written a specification. Writing something down is a very low bar and it would be very easy for someone to write a bad specification. Thus, the primary criteria is to satisfy the oversight of the designated experts, who presumably will ensure that there is a good and sensible specification as well. > > ** Idnits reported: > > -- The draft header indicates that this document updates RFC5029, but the > abstract doesn't seem to directly say this. It does mention RFC5029 > though, so this could be OK. > > The abstract text explicitly needs text to the effect of “This document > updated > RFC5029 …” Sentence added in -03. T _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
