Re: [radext] #28: Section 1.2

["radext issue tracker" <trac@tools.ietf.org>]

#28: Section 1.2
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  critical                   |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
Description changed by bernard_aboba@â:

Old description:

> We emphasize that the uses of "MUST" and "MUST NOT" in this document
>    are limited to requirements to follow the IETF process for IETF
>    standards, and quotes from other documents.  As a result, the uses of
>    "MUST" and "MUST NOT" in this document do not prescribe new mandatory
>    behavior within implementations.
>
> [BA] Since elements of this paragraph have been incorporated into the
> proposed text of Section 1.3, it can be deleted.  Note that RFC 2119
> Section 6 appears restricts usage of "MUST" and "MUST NOT":
>
>    We emphasize that the uses of "MUST" and "MUST NOT" in this document
>    are limited to requirements to follow the IETF process for IETF
>    standards, and quotes from other documents.  As a result, the uses of
>    "MUST" and "MUST NOT" in this document do not prescribe new mandatory
>    behavior within implementations.

New description:

 We emphasize that the uses of "MUST" and "MUST NOT" in this document
    are limited to requirements to follow the IETF process for IETF
    standards, and quotes from other documents.  As a result, the uses of
    "MUST" and "MUST NOT" in this document do not prescribe new mandatory
    behavior within implementations.

 [BA] Since elements of this paragraph have been incorporated into the
 proposed text of Section 1.3, it can be deleted.  Note that RFC 2119
 Section 6 appears restricts usage of "MUST" and "MUST NOT":

     Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

--

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/28#comment:1>
radext <http://tools.ietf.org/radext/>


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>