Skip to main content

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

Yes

(Dan Romascanu)
(Ron Bonica)

No Objection

(Cullen Jennings)
(David Ward)
(Lisa Dusseault)
(Ross Callon)
(Russ Housley)

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

Dan Romascanu Former IESG member
Yes
Yes () Unknown

                            
Jari Arkko Former IESG member
Yes
Yes (2008-08-27) Unknown
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 Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection (2008-08-28) Unknown
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?
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection (2008-08-26) Unknown
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).
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection (2008-08-28) Unknown
(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).