[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Pls review documents on IESG Agenda October 27, 2005 Telechat
Bert,
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-ieprep-doma
in-req-05.txt includes in the Security Consideration section the
following:
- Most current deployments of SNMP are of versions prior to
SNMPv3, even though there are well-known security
vulnerabilities in those versions of SNMP.
- SNMP versions prior to SNMPv3 cannot support cryptographic
security mechanisms. Hence, any use of SNMP prior to
version 3 to write or modify MIB objects do so in a
non-secure manner. As a result, it may be best to constrain
the use of these objects to read-only by MIB managers.
- Finally, any MIB defining writable objects should carefully
consider the security implications of an SNMP compromise on
the mechanism(s) being controlled by those writable MIB
objects.
1. I believe that the first paragraph should also mention that SNMPv3 is
the current standard version, while previous versions are Historical.
2. I am not sure what this 'SNMP compromise' is supposed to mean. Can
you ask for a clarification?
Thanks and Regards,
Dan
> -----Original Message-----
> From: owner-mreview@ops.ietf.org
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> Sent: Friday, October 21, 2005 9:07 AM
> To: Mreview (E-mail)
> Subject: Pls review documents on IESG Agenda October 27, 2005 Telechat
>
> As always, your review and comments (if any), specifically
> from a SNMP/MIB/NM perspective will be appreciated.
>
> Bert
>
> -----Original Message-----
> 2.1 WG Submissions
> 2.1.1 New Item
> o draft-ietf-mpls-lsp-ping-10.txt
> Detecting MPLS Data Plane Failures (Proposed Standard) - 1 of 6
> Token: Alex Zinin
> o Two-document ballot: - 2 of 6
> - draft-ietf-pim-sm-v2-new-11.txt
> Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol
> Specification (Revised) (Proposed Standard)
> - draft-ietf-pim-proposed-req-01.txt
> PIM Sparse-Mode IETF Proposed Standard Requirements Analysis
> (Informational)
> Token: Alex Zinin
> o draft-ietf-nfsv4-rfc1832bis-06.txt
> XDR: External Data Representation Standard (Standard) - 3 of 6
> Token: Jon Peterson
> o draft-ietf-radext-chargeable-user-id-06.txt
> Chargeable User Identity (Proposed Standard) - 4 of 6
> Token: David Kessens
> o draft-ietf-sieve-variables-07.txt
> Sieve Extension: Variables (Proposed Standard) - 5 of 6
> Note: Document shepherd is Alexey Melnikov
> <alexey.melnikov@isode.com>
> Token: Scott Hollenbeck
> o draft-ietf-enum-iris-ereg-02.txt
> An ENUM Registry Type for the Internet Registry
> Information Service
> (Proposed Standard) - 6 of 6
> Note: Finishes Last Call on October 27. On IESG
> agenda, however LC
> comments urged and will be heeded.
> Token: Allison Mankin
>
> 2.1.2 Returning Item
> o Three-document ballot: - 1 of 1
> - draft-ietf-lemonade-urlauth-08.txt
> Internet Message Access Protocol (IMAP) - URLAUTH
> Extension (Proposed
> Standard)
> - draft-ietf-lemonade-burl-03.txt
> Message Submission BURL Extension (Proposed Standard)
> - draft-ietf-lemonade-catenate-05.txt
> Internet Message Access Protocol (IMAP) CATENATE
> Extension (Proposed
> Standard)
> Note: Checking for revised DISCUSSes based on updates
> Token: Ted Hardie
>
>
> 2.2 Individual Submissions
> 2.2.1 New Item
> o draft-hansen-2717bis-2718bis-uri-guidelines-06.txt
> Guidelines and Registration Procedures for new URI
> Schemes (BCP) - 1 of 2
> Token: Scott Hollenbeck
> o draft-legg-ldap-binary-03.txt
> Lightweight Directory Access Protocol (LDAP): The Binary
> Encoding Option
> (Proposed Standard) - 2 of 2
> Token: Ted Hardie
>
> 2.2.2 Returning Item
> NONE
>
> 3. Document Actions
>
> 3.1 WG Submissions
> Reviews should focus on these questions: "Is this
> document a reasonable
> contribution to the area of Internet engineering which
> it covers? If
> not, what changes would make it so?"
>
> 3.1.1 New Item
> o draft-ietf-ieprep-domain-req-05.txt
> Emergency Telecommunications Services (ETS) Requirements
> for a Single
> Administrative Domain (Informational) - 1 of 2
> Note: Note the RFC-Editor note that removes the reference
> in the Abstract.
> Token: Jon Peterson
> o draft-ietf-xcon-floor-control-req-03.txt
> Requirements for Floor Control Protocol (Informational) - 2 of 2
> Note: This was meant to go on the agenda when we considered
> draft-ietf-xcon-bfcp, but. the AD mislaid the request and
> thought wrongly
> this wasn't intended for ultimate publication.
> Token: Allison Mankin
>
> 3.1.2 Returning Item
> NONE
>
> 3.2 Individual Submissions Via AD
> Reviews should focus on these questions: "Is this
> document a reasonable
> contribution to the area of Internet engineering which
> it covers? If
> not, what changes would make it so?"
>
> 3.2.1 New Item
> o draft-mccobb-xv-media-type-00.txt
> XHTML+Voice - application/xv+xml (Informational) - 1 of 1
> Token: Scott Hollenbeck
>
> 3.2.2 Returning Item
> o draft-rharrison-lburp-05.txt
> LDAP Bulk Update/Replication Protocol (Informational) - 1 of 2
> Token: Ted Hardie
> o draft-vandesompel-info-uri-04.txt
> The "info" URI Scheme for Information Assets with
> Identifiers in Public
> Namespaces (Informational) - 2 of 2
> Note: Handling may depend on the results of review of APP
> draft-hansen-2717bis-2718bis-uri-guidelines-06.txt [Open
> Web Ballot]
> Token: Ted Hardie
>
> 3.3 Individual Submissions Via RFC Editor
> The IESG will use RFC 3932 responses: 1) The IESG has not
> found any conflict between this document and IETF work; 2) The
> IESG thinks that this work is related to IETF work done in WG
> <X>, but this does not prevent publishing; 3) The IESG thinks
> that publication is harmful to work in WG <X> and recommends
> not publishing at this time; 4) The IESG thinks that this
> document violates the IETF procedures for <X> and should
> therefore not be published without IETF review and IESG
> approval; 5) The IESG thinks that this document extends an
> IETF protocol in a way that requires IETF review and should
> therefore not be published without IETF review and IESG
> approval.
>
>
> Other matters may be recorded in comments to be passed on
> to the RFC Editor as community review of the document.
>
>
> 3.3.1 New Item
> NONE
> 3.3.2 Returning Item
> NONE
>
>
>