The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model
RFC 3826

Note: This ballot was opened for revision 08 and is now closed.

(Steven Bellovin) Yes

(Bert Wijnen) Yes

Comment (2003-10-16 for -)
No email
send info
In response the the comment by Ned:
- I think that RFC3414 sect 11.2 does discuss this topic somewhat, 
  but not as detailed as this new document. So elaborating on this
  with more detail in this document seems goodness to me.

From one of my MIB doctors:
- Section 1.1 - should say probably 'User-based Security Model (USM)'
  as opposed to just 'USM'

- Language in 1.3 and 4 seem to be inconsistent 'can be 
  suggested' and MUST do not play well for my English parser 
  (not the best in the world, of course)
  This one is in sync with the concern about conflicting SHOULD and MUST
  language in the two sections.

(Harald Alvestrand) No Objection

(Randy Bush) No Objection

(Margaret Cullen) No Objection

Comment (2003-10-15 for -)
No email
send info
A minor editorial comment that can be ignored unless a document
update is needed for other reasons:

This document uses an unusual method for defining acronyms --
just using the full name at the beginning and the acronym later,
without associating the two.  Here is one example:

"The main goal of this memo is to provide a new privacy protocol for the
USM based on the Advanced Encryption Standard.
For a given user, the AES-based privacy protocol..."

I would have preferred to see Advanced Encryption Standard (AES),
as this makes it easier to associate the acronym with the name
and is consistent with other RFCs.

(Bill Fenner) No Objection

(Ned Freed) No Objection

Comment (2003-09-12 for -)
No email
send info
It seems to me that the password entropy discussion in 1.3 applies regardless
of the symmetric cipher that's employed and really belonged in section 11.2
of RFC 3414 rather than in a document whose goal is only to define a new symmetric
cipher for SNMP. But the way this section is worded (e.g. "functions specified
in this document") makes it sound like the need for strong passwords is somehow
specific to AES. Perhaps this could be reworded to make it clear the need is more

(Ted Hardie) No Objection

(Russ Housley) (was No Record, Discuss) No Objection

Comment (2003-10-15)
No email
send info
In section 3.1, please remove the dash at the front of each paragraph.  Alternatively, treat it as a bulleted list by adding an introduction sentence.

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Alex Zinin) No Objection