Subject: [radext] #28: Section 1.2

From: "radext issue tracker" <[email-masked]>
Date: Sun, 20 Jun 2010 23:38:47 -0000

#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:            
---------------------------------------+------------------------------------
 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.

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Sun, 20 Jun 2010 23:39:52 -0000

#28: Section 1.2
Description changed by bernard_aboba@…:

>    behavior within implementations.

New description:

     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/>

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 21 Jun 2010 15:00:27 -0000

#28: Section 1.2
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  critical                   |    Milestone:  milestone1
Component:  design                     |      Version:  1.0       
 Severity:  Submitted WG Document      |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

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