Ben - The points you make below make sense to me - but I am not sure how we get the stronger review process associated w "Expert Review" and at the same time require that some public document exist for each application. Are you saying that we can require both? I actually thought that was the intent of "Specification Required" - but your comments suggest otherwise. I really wish RFC 5226 addressed this more robustly... Les > -----Original Message----- > From: Ben Campbell [mailto:ben@xxxxxxxxxxx] > Sent: Wednesday, October 06, 2010 8:55 AM > To: Les Ginsberg (ginsberg) > Cc: draft-ietf-isis-genapp.all@xxxxxxxxxxxxxx; General Area Review > Team; The IETF > Subject: Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp- > 03.txt > > > On Oct 6, 2010, at 10:14 AM, Les Ginsberg (ginsberg) wrote: > > > [...] > > >>> > >>> From RFC 5226: > >>> > >>> "Specification Required - Values and their meanings must be > >>> documented in a permanent and readily available public > >>> specification, in sufficient detail so that > >> interoperability > >>> between independent implementations is possible. When > >> used, > >>> Specification Required also implies use of a Designated > >>> Expert, who will review the public specification..." > >>> > >>> We deliberately chose "Specification Required" because: > >>> > >>> a)It requires a public specification > >>> b)It allows the public specification to be other than an RFC > >>> c)It requires expert review > >> > >> Completing the sentence in your quote: "who will review the public > >> specification and evaluate whether it is sufficiently clear to allow > >> interoperable implementations." > >> > >> My understanding of "Specification Required" is that the expert > review > >> is merely to ensure that the documentation is sufficiently complete > > and > >> readable to implement in an interoperable way. That review is not > >> intended to ensure compliance to other criteria specified in the > > draft. > >> > >> However, the draft includes some specific criteria for GENINFO > >> applications. If you want the reviewer to enforce those criteria, > then > >> I think you need at least "Expert Review". OTOH, in RFC5226, the > >> "expert review" policy has less to say about the required level of > >> documentation, so the draft might require some more meat in that > area. > >> > > > > This is a bit distressing - because you are suggesting that RFC 5226 > > doesn't define a category which is appropriate for our usage - which > > means we have to try to define a unique policy. I am not quite sure > how > > to do that with sufficient authority and minimal controversy. > > > > My understanding is that RFC 5226 is specific to IANA considerations > - > > so we have attempted to define a clear policy as to how the review of > > code point assignments is done. > > > > Beyond that, it seems clear that a given Application specification > could > > specify behavior that might be seen as undesirable e.g. it could > specify > > some extremely high rate of updates. Given that we allow application > > specification to be defined in public documents from a variety of > > sources, I don't see how we could define an enforceable review policy > > for the application specifications. It is at the IANA codepoint > > allocation that we have control - and certainly it seems within the > > purview of an expert to say "I think your specification is flawed and > I > > won't approve the allocation of codepoints until the issues of > concern > > are addressed". > > > > > Yes, both "specification required" and "expert review" involve expert > review. But they have significant differences in the scope of the > review. "Specification required" means that the expert should review to > make sure the specification is clear enough to be implemented in an > interoperable fashion. It doesn't in any way indicate that the expert > thinks the code point is "good", or that it conforms to the purpose of > the registry. Certainly, the expert could offer advise on issues, but > the registrant would not be under any obligation to follow the advise. > > "Expert Review" means that the expert should review a registration to > make sure that it conforms to the criteria set forth in the document > that defined the registry. I really think that is what you are looking > for, particularly from your last sentence above about the expert being > able to block allocation of a flawed code point. > > For example, RFC 3563 calls out "Expert Review", and sets a number of > criteria, one of which is the assertion that registrations require > standards actions, or that they require publications from ISO/IEC > JTC1/SC6 that meant the normal requirements for an RFC. > > In your case, I think you need Expert Review, with criteria along the > lines that registrants must meet the requirements of "specification > required", that it must describe its expected rate of updates (and that > this not be excessive), that it must address any security > considerations, etc. > > > > >> I note that while RFC3563, which established the IS-IS TLV Codepoint > >> registry, says "Expert Review", the review criteria is pretty much > >> equivalent to "standards action". I'm guessing the only reason it > was > >> not "standards action" was to allow ISO/IEC JTC1/SC6 to submit > >> specifications, which are to be held to the same standard as a > >> standards-track RFC, but do not actually get published as such. So > for > >> practical purposes, the proposed policy for GENINFO is significantly > >> weaker than for the parent registry--more so than one might think > from > >> just looking at the registry itself. > > > > I am not clear on why "Expert Review" is seen as a stronger review > > criteria than "Specification Required" - which includes expert review > as > > well as a requirement for a public specification. > > Actually, "expert review" doesn't have to be stronger than > specification required. But it can be. It's all a matter of how you > define the review criteria. The difference is, in "expert review" you > get to define the criteria. In "specification required", the criteria > is already defined, and fairly limited. > > RFC3563 has has quite strict criteria, thus my comment about it being > "stronger". For all practical purposes, the policy for RFC 3563 is > "standards action" with some very specific exceptions. > > [...] > > >>> > >>> If the revised version of a GENINFO TLV is sent in an LSP with a > >>> different number from the previous version there can be transient > >>> windows where other systems have two copies of information > regarding > >> the > >>> same application. This may be unavoidable. For completeness we > >> specify > >>> that the choice of what to do in such transient situations is > >>> implementation specific (undefined). This section does specify ways > >> to > >>> minimize the occurrence/duration of such transient periods. > >> > >> Does leaving this undefined cause interop issues? If not, then no > >> problem. > > > > There is no alternative. It is not possible to determine in a > reliable > > way which copy is "newer". > > Okay > > [...] > > > >> > >> Since the registration policy is not at least "RFC Required", > there's > >> no explicit requirement that the public document actually do this. > If > >> you wish to require them to do it, you will need to state something > to > >> that effect. (See previous comment about whether the registration > >> policy actually enforces that sort of criteria.) > > > > I appreciate your point - but I don't see how we have the authority > to > > place a requirement on a document developed in another standards > body. > > > > You can set criteria for the codepoint allocation, though. Requiring > the specification of a code point to address security seems to be a > reasonable criteria. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf