RE: FW: [Entmib] Minutes from SF (fwd)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

So do we have a statement we can make as to what is the 
proper thing to do? My ENTMIB wg in fact had the specific
question.

Thanks,
Bert 

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: donderdag 24 april 2003 19:37
> To: Harald Tveit Alvestrand; iesg@ietf.org
> Subject: Re: FW: [Entmib] Minutes from SF (fwd)
> 
> 
> Harald:
> 
> >>>>>By the same logic, all the MAYs must be implemented or 
> removed too.
> >>>>
> >>>>I think this is raising the bar above current practice.
> >>>
> >>>You're probably right. But it still leaves the question of 
> whether these
> >>>features are specified enough for interoperable 
> implementations hanging.
> >>>Which is not a Good Thing.
> >>>
> >>>For one example of such features being tested:
> >>>
> >>>http://www.ietf.org/IESG/Implementations/http1.1-implementa
> tions.txt
> >>>
> >>>For instance, Accept-Ranges: is not a MUST or SHOULD feature.
> >>
> >>I think that both MUST and SHOULD requirements ought to be 
> included in
> >>interoperability testing.  However, I think that MAY is 
> going too far.
> >>Consider the following:
> >>
> >>          Implementations MUST support Triple-DES.
> >>          Implementations SHOULD support AES.
> >>          Implementations MAY support any other algorithms as well.
> >>
> >>I would like to see two implementations of Triple-DES and 
> AES.  The rest
> >>is too open ended.
> >
> >taking this a bit further...
> >
> >let's say that some standard has a MUST support triple-DES, 
> and has that 
> >properly specified.
> >
> >It also has a MAY support DES, and assigns codepoint 5 to that. But 
> >somehow the spec never got around to defining whether it was 
> DES in CBC 
> >mode or DES in ECB mode, and nobody has implemented it, so 
> there's no 
> >codebase to refer to.
> >
> >In that case, I'd claim that the specification of codepoint 
> 5 doesn't meet 
> >the criteria for Draft; reserving 5 for "DES - to be 
> specified" is OK, but 
> >keeping the ambiguous language in the document is not.
> >
> >(ok, this example looks contrived. But if it's not 
> implemented, we can't 
> >tell that it's properly specified.)
> 
> I understand your point.  If we notice them, then we should fix them.
> 
> I do not think we should raise the bar on the 
> interoperability testing.
> 
> Russ
>