On Oct 6, 2010, at 11:08 AM, Les Ginsberg (ginsberg) wrote: > 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... Don't take the choices in RFC 5226 as the only thing you can do--there's room for "tweaking" them to your needs. It seems like you are really looking for the union of "Expert Review" and "Specification Required". It's easier to start from "Expert Review" since it is the more flexible of the two policies ( in that it explicitly states that the document that establishes the registry will contain the criteria for the review.) It's perfectly okay to have that criteria include something to the effect of "The code point must be defined in a publicly available document that substantially meets the requirements of the 'Specification Required' policy in RFC 5226." > > 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