[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: R41 in draft-ietf-v6ops-cpe-simple-security-07
Thank you for the clarification, I now see the intent. Ok for that as is.
While speaking, in 3.4 I-D says:"It remains to be seen whether the Internet Gateway Device profile of the Universal Plug And Play protocol will be extended for IPv6.". For me that sounds like there would be possibility for UPnP not being extended to IPv6, which is definitely not the case as work is currently being done to extend UPnP with IPv6. As the work is in progress, at this point the document could say instead:"Internet Gateway Device profile of the Universal Plug And Play protocol is being extended for IPv6."
I agree with Barbara that second sentence of R41 is not appropriate. What would be the possible replacement for the MUST, if that is taken as compromise approach?
>[mailto:email@example.com] On Behalf Of ext james woodyatt
>Sent: 30 July, 2009 11:39
>To: IPv6 Operations
>Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07
>On Jul 30, 2009, at 11:12, firstname.lastname@example.org wrote:
>> How to actually read Recommended MUST? Essentially as SHOULD?
>> Recommended SHOULD then? As MAY?
>My thoughts on that have always been that this document
>provides recommendations, not requirements, as it was
>originally intended to be a Best Current Practices document
>(now Informational) and not a Standards Track document.
>Nevertheless, it's supposed to be a useful set of guidelines
>for vendors of residential IPv6 gateway equipment, at least
>one of which would like to cite the RFC number and claim
>conformance. The use of normative language in this document
>is employed therefore to make such claims testable.
>So. MUST means you gotta do this if you want to cite the RFC
>and claim you followed the guidelines. SHOULD means you gotta
>have a reasonable case for not following the guideline if you
>want to cite the RFC and claim you followed the guidelines.
>MAY means you're explicitly allowed the option and still you
>can cite the RFC and claim you followed the guidelines. If
>you cite the RFC and claim you followed the guidelines, when
>in fact you didn't, then we can all point our fingers and
>tattle to your mothers.
>It might also help the authors of documents for other
>organizations to have normative language in the RFC that they
>can reference externally as their own requirements in one
>lump, e.g. "the device shall implement all the recommendations
>described in RFC #### with the following amendments, blah blah blah".
>I hoped that a disquisition on that topic would not be
>necessary in the intro section. Is it?
>james woodyatt <email@example.com>
>member of technical staff, communications engineering