Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats
RFC 5345

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

(Jari Arkko) Yes

Comment (2008-08-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Nice document and interesting reading!

It would be great if the authors would be able to fix the scheme
errors noted in Pasi's review.

The document mentions that the use of authentication and encryption
mechanisms is something that could be measured from the traces.
Not being an SNMP expert I have to wonder whether the use of
encryption would be compatible with being able to use the packet
traces. Do SNMP security mechanisms encrypt entire packets, hiding
OIDs and operations, or just the actual object values?

(Ron Bonica) Yes

(Dan Romascanu) Yes

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Pasi Eronen) No Objection

Comment (2008-08-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The example XML document doesn't actually validate with the schema
(the "snmptrace" element is missing the namespace declaration, and the
schema's oid.type regexp seems to need parenthesis around the first
line to properly match).

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

Comment (2008-08-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Were this an IETF document I would want to discuss how it addresses
BCP 70 section 4.7.  Specifically:

   o  Protocols may or may not insist that all corresponding protocol
      elements be valid, according to the validity mechanism chosen; in
      either case, the extensibility design should be clear.  What
      happens if the data is not valid?

(Tim Polk) No Objection

Comment (2008-08-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
(A)

 References in sections 2, 2.1, 2.2, and the first paragraph of 2.3 appear in the text as
[1], [2], etc. but appear in the references section appear as [RFC2578], etc.

(B)

I thought the document's guidance on storing raw traces a bit confusing.  Filtering and
anonymizing are recommended in 2.3 and the security considerations, but storing
raw traces is recommended in section 2.4.

I assume that "raw" traces are complete and unfiltered/not anonymized.  Perhaps that
isn't true?  I couldn't check, since I can't track reference [1] (see above).

(David Ward) No Objection