On Wed, 7 Sep 2005, The IESG wrote: > A modified charter has been submitted for the Integrated > Security Model for SNMP (isms) working group in the Security > Area of the IETF. ... > In order to leverage the authentication information already > accessible at managed devices, the new security model will > use the SSH protocol for message protection, and RADIUS for > AAA-provisioned user authentication and authorization. > However, the integration of a transport mapping security model > into the SNMPv3 architecture should be defined such that it is > open to support potential alternative transport mappings to > protocols such as BEEP and TLS. > > The new security model must not modify any other aspects of > SNMPv3 protocol as defined in STD 62 (e.g., it must not create > new PDU types). If (as I have gathered from the discussion over the past few days) the last sentence quoted above means that it is out of scope for the working group to even consider solutions that allow agents and managers to work on either side of firewalls or NATs, then I think that the charter is drawn too narrowly and should be revised. Indeed, I think that it should be an explicit goal (if not a requirement) for the solution to work even when one of the parties (agent or manager) is unable to accept incoming TCP connections. That issue will have to be addressed eventually, and it is better for implementors to go through the churn once rather than twice. Mike Heard P.S. Note that I am using the words "agent" and "manager" in the traditional sense, i.e., to mean "notification originator + command responder" and "notification receiver + command generator" respectively. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf