[Gen-art] REVIEW: draft-ietf-radext-rfc2618bis-03.txt

Attached is my review of the specified document, submitted as part of
the Gen-ART process.  For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Document Tag: draft-ietf-radext-rfc2618bis-03.txt
Document Title: RADIUS Auth Client MIB (IPv6)
Intended Status:  Proposed Standard
Shepherding AD:  Dan Romascanu

To the Author/Editor: Please wait for direction from your document
shepherd or AD before posting a new version of the draft.

----------------  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".

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art