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.

(Bert Wijnen; former steering group member) Yes

Yes (2003-10-16 for -** No value found for 'p.get_dochistory.rev' **)
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.

(Steven Bellovin; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Margaret Cullen; former steering group member) No Objection

No Objection (2003-10-15 for -** No value found for 'p.get_dochistory.rev' **)
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.

(Ned Freed; former steering group member) No Objection

No Objection (2003-09-12 for -** No value found for 'p.get_dochistory.rev' **)
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
general.

(Randy Bush; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) (was No Record, Discuss) No Objection

No Objection (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.

(Ted Hardie; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Thomas Narten; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info