Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "David T. Perkins" <[email-masked]>
Date: Wed, 13 Apr 2005 13:37:40 -0700 (PDT)

HI,

I thought you were using the term "peer entity" to
mean an SNMP engine. I'm sorry that I misinterpreted
that if you meant something else. What do you mean
by "peer entity"? What identity is used for each peer?

Regards,
/david t. perkins
On Wed, 13 Apr 2005, David B Harrington wrote:

> Hi David,
> 
> When you decide to post your explanation, please indictae where in my
> message you think I characterized SNMPv3 as having engines with
> authenticated identities. I have read and reread what I said, and I
> don't see that I ever said that.
> 
> dbh
> 
> > -----Original Message-----
> > From: David T. Perkins [mailto:[email-masked]] 
> > Sent: Wednesday, April 13, 2005 3:09 PM
> > To: David B Harrington
> > Cc: 'Robert Story'; 'Sam Hartman'; [email-masked]
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> > 
> > HI,
> > 
> > I disagree with your characterization of SNMPv3. SNMP engines
> > do not have authenticated identifies. 
> > 
> > I'll explain further in another message.
> > 
> > /david t. perkins
> > 
> > On Wed, 13 Apr 2005, David B Harrington wrote:
> > 
> > > A GET-request is an unsolicited communication; only the response
> is
> > > solicited. 
> > > 
> > > Netconf chose a model akin to SNMPv1's architecure, where one
> entity
> > > is always the manager and the other is always the agent. The
> manager
> > > is always allowed to initiate unsolicited communications to 
> > the agent.
> > > It complicates the paradigm when it is necessary for the 
> > agent to send
> > > an unsolicited message to the manager. 
> > > 
> > > The SNMPv3 architecture has been designed as an environment of
> peer
> > > entities that happen to provide certain types of services. 
> > Both sides
> > > of a relationship should be able to send unsolicited messages,
> e.g.
> > > informs, if the two sides support the corresponding services.
> SNMPv3
> > > allows a single entity to support  services to a)generate and
> > > b)receive and c)respond to unsolicited communications. 
> > > 
> > > I think TLS fits the peer-to-peer approach. I agree that the SSH
> > > architecture might be slightly more problematic 
> > establishing a two-way
> > > relationship between peers.
> > > 
> > > David Harrington
> > > [email-masked]
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] 
> > > > [mailto:[email-masked]] On Behalf Of Robert Story
> > > > Sent: Wednesday, April 13, 2005 8:14 AM
> > > > To: Sam Hartman
> > > > Cc: [email-masked]
> > > > Subject: Re: [Isms] Discussion: Architecture direction for ISMS
> > > > 
> > > > On Tue, 12 Apr 2005 16:22:24 -0400 Sam wrote:
> > > > SH> Why is this true?  If all engines have credentials they 
> > > > can use, why can't
> > > > SH> you open a session if you need one?
> > > > 
> > > > My concern was was with regards to fitting into an existing 
> > > > infrastructure
> > > > where unsolicited communication was not the norm. I use ssh 
> > > > as an example,
> > > > because I am not familiar with TLS. While a ssh session does 
> > > > establish a key
> > > > for the peer host, additional configuration would be needed 
> > > > to allow that peer
> > > > to autonomously establish connections back to the 
> > originator's host.
> > > > 
> > > > With one of the goals of ISMS being re-use of existing 
> > > > infrastructure, I was
> > > > just thinking that for some infrastructures (eg ssh), get and 
> > > > set would easily
> > > > fit, but notifications would require more thinking.
> > > > 
> > > > _______________________________________________
> > > > Isms mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/isms
> > > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Isms mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/isms
> > > 
> > 
> > 
> 
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 13 Apr 2005 22:09:03 -0400

Hi David,

You are correct; I am using "peer entity" to refer to SNMP engines.
Dictionary.com defines "peer" as "A person who has equal standing with
another or others." I think that is a reasonable characterization of
the relationship between SNMPv3 engines, especially when compared to
the relationships of SNMPv1/v2 engines as manager/agent. 

I didn't say that SNMP engines have authenticated identities.

David Harrington
[email-masked]

> Sent: Wednesday, April 13, 2005 4:38 PM
> To: David B Harrington