AD review of draft-ietf-radext-management-authorization-05.txt

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

Please my below my AD comments for
draft-ietf-radext-management-authorization-05.txt. In general this is a
well-written and rather straight forward document, in good shape for
IETF Last Call. I suggest that the editors discuss my comments before
suggesting a resolution about whether a Revised ID is needed before the
IETF last Call or not. 

1. section 2, page 4: replace 'NETCONF(XML over/SSH/BEEP/SOAP)' by
'NETCONF(XML over SSH or BEEP or SOAP)'

2. section 5.2 and the following refer to 'a transport with equal or
better protection'. I am wondering whether such a hierarchy of the
Management-Transport-Protection is or will be always possible. Actually
we may have a problem already, as SNMP allows any combination of
authentication and privacy modes, and it is not clear which is the
'better' between (auth, noPriv) and (noAuth, priv). 

3. Related to the previous comment and in the same section - the
Confidentiality-Protection value is missing from the enumeration of
Value in the definition of the Management-Transport-Protection attribute

4. Section 5.3 

   No precedence relationship is defined for multiple occurrences of the
   Management-Policy-Id (TBA-4) Attribute.  NAS behavior in such cases
   is undefined.  Therefore, two or more occurrences of this attribute
   SHOULD NOT be included in an Access-Accept or CoA-Request.

I am wondering if a MUST NOT would not be in place here. How can
interoperability of different vendors solutions be ensured if two or
more occurrences of the attribute are included in an Access-Accept or
CoA-Request and no standard precedence algorithm is in place? Any reason
to allow this at all ever? 

5. Last paragraph in Section 5.3, page 11 

.  It is recommended that
   the message contain UTF-8 encoded 10646 [RFC3629] characters.

It looks to me that RECOMMENDED needs to be capitalized here. 

6. Section 9 - page 17 - I do not see 0+ being used in Table 9, so it
can be dropped by now from the table clarification list

7. Section 10 - I suspect the first Note ends after '... As an RFC'. 

8. Section 10, same comment as in Section 3 related to the values of the
Management-Transport-Protection attribute

9. I am wondering if Section 11 should not say something about the
option No-Protection of the Management-Transport-Protection attribute
being NOT RECOMMEDED in any critical configuration, or secure sensible
environment

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