Proposed comment resolution for 2618bis-2621bis drafts

["Nelson, David" <dnelson@enterasys.com>]

The following Gen-ART review was received on the subject I-D, which as
completed IETF Last Call.

I propose to accept the comments from this review and apply them to all
four documents (2618bis-2621bis) as applicable, as well as the IETF LC
comment on the typos in 2620bis and 2621bis (see
https://ops.ietf.org/lists/radiusext/2006/msg00510.html).  I will
prepare revised I-Ds on all four RADIUS IPv6 MIBs, and submit them prior
to the deadline on Monday, June 26 (probably by this afternoon, in
fact).

If anyone in WG objects to resolving the IETF LC and Gen-ART review
comments as proposed, please reply to this message.


----------------  Begin review  ----------------

Summary: This draft is on the right track but has an open issue,
	described in the review.

I really only have one major concern that I think NEEDS to be
addressed and that is that the security concerns are not complete.
The two minor comments are to improve the clarity and need not delay
things, but since an update may well be needed they may as well be
addressed at the same time.  The typo, of course, can be fixed any
time up to and including AUTH48 with the RFC editor.

I'll also note that except for the Security Considerations comment
these also apply to the rfc2619bis draft as well, however I didn't
review it, just looked at these points (but I did notice a typo ["cab"
instead of "can" in paragraph 2 of Security Considerations in
rfc2619bis] that you could fix).  I figured I'd just mention that
since the two drafts have the same author

Major concerns
--------------

In the list of sensitive objects in the security section, you list
both the address and the port objects in the new table, but only the
address and not the port in the deprecated table.  I'd expect the port
number there to be as sensitive.  Also, while nowhere near as
sensitive as the address and port, the address type also potentially
leaks useful info.

Minor comments
--------------

Is RFC4001 Normative?  The Textual conventions defined there are used
here.  I would think that would make it normative to the definitions
in this document.  This MIB imports from INET-ADDRESS-MIB which is
defined in RFC4001, so I think it must be normative.  But, I am not a
MIB expert, so I could be mistaken, of course.

Is the server MIB also being updated?  I see there's a draft for
that.  I suggest that it should be referenced at least in Section 5
second paragraph.  Perhaps more than just citing it include a sentence
about "client in this doc and server in [RFCtbd]".  Of course, this
should be symmetrical, that doc should ref this one.

----------------------------------------------------------------
   The following typo is noted for the convenience of possible copy
   editors but is not part of the technical review.

Typos
-----

In the abstract, the third sentence needs a comma after "extensions".

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