AD review of draft-ietf-radext-status-server-06.txt

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

I have reviewed the I-D draft-ietf-radext-status-server-06.txt. The
document is in good shape and ready to be sent to IETF Last Call. The
comments below can be considered together with the other comments
received during the IETF Last Call. 

The comments are divided into Technical and Editorial. 

T1. The document is using the Status-Server Code (12) which is
experimental. Why is not the intended status of the document
experimental? 

T2. The following requirements seem to conflict: 

- section 4.1: 'The client MAY increment packet counters as a result of
sending a
   Status-Server request, or receiving a Response packet. '

- section 4.6.2: ' Clients implementing Status-Server MUST NOT increment
[RFC4668] or
   [RFC4670] counters upon reception of Response packets to Status-
   Server queries. '

I think that the later is better. 

T3. The following requirements seem to conflict: 

- section 4.2: 'The server MAY increment packet counters as a result of
receiving a
   Status-Server, or sending a Response packet. '

- section 4.6.1: '...when a server fully implements
   Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST
   be unaffected by the transmission or reception of packets relating to
   Status-Server.'

I think that the later is better. 


E1. I could not understand the logic of the different alignments of
paragraphs in Section 3. 

E2. In section 4.1 I do not like the word 'Robust' in ' Robust
implementations SHOULD accept any Response packet ...'

E3. In the same section I think that 'should' in the following phrase
needs to be capitalized: 

> That is, prior to accepting the response as valid, the client should
   check that the Response packet Code field is either Access-Accept (2)
   or Accounting-Response (5).  

E4. In the same section I think that the MUST in the following phrase
needs not be capitalized: 

> If the Response Authenticator is valid,
   then the packet MUST be deemed to be a valid response from the
   server.

E5. In Section 4.5 s/Each RADIUS Proxyhas/Each RADIUS Proxy has/


Thanks and Regards,

Dan


 

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