Re: [Isms] wg last call followup - sshtm

["tom.petch" <cfinss at dial.pipex.com>]

---- Original Message -----
From: "David Harrington" <ietfdbh at comcast.net>
To: "'tom.petch'" <cfinss at dial.pipex.com>;
<j.schoenwaelder at jacobs-university.de>
Cc: <isms at ietf.org>
Sent: Wednesday, March 04, 2009 4:54 PM
Subject: RE: [Isms] wg last call followup - sshtm

> Hi Tom,
>
> > > I was totally confused by this whole thing myself. Then, to answer
> a
> > > question from Joe, I researched it fairly thorughly through the
> > > RFC341x series and realized my whole understanding was
> > wrong, and then
> > > explained it to Joe, who finally understood it. Now Tom has
> > a problem.
> > > (And I still slip into my old understanding and have to
> > remember this
> > > new approach). I expect that most operators will have an
> > understanding
> > > similar to my original understanding, which I think was the
> original
> > > intention of the SNMPv3 WG. I think we are turning things on their
> > > head here, and we better be sure operators understand.
> > >
> [...]
> > > alice is actually the sender, not the recipient. That one
> obviously
> > > slipped by.
> >
> > David,
> >
> > Actually, I see this one as ok:-)  It tells me that there is
> > a recipient and
> > that the identifier for that recipient has two values, one,
> > alice is used in the
> > NO, the other, rtr-nyc4, is used in the NR.
>
> And that is the confusion I had (or have) as well. I think saying that
> alice is the recipient is wrong, if the bob@ format is used.
>
> In USM, the sender and recipient are the same.
> In SSHTM, the sender and recipient are the same, **if** a user@
> address is not used.
> In SSHTM, if a bob at examp;e.com:PPP address is used, then alice is the
> sender and "bob" is the recipient.
>
Right, but as I said in the bit you elided, I am comfortable turning  the roles
round in my head and use sender instead of recipient in the paragraph from the
tsm appendix can understand it whether alice is referred to as sender or
recipient.

To me, it's a philsophical tangle.  I understand the mechanics and agree they
work but also see that what wording makes sense may depend on somewhat abstract
views of identity and identifier.

So I am happy to see the wording in tsm changed as long as we spell out the
mechanics so that they are clear, which I think the appendix does already.

But I also want to see free standing text about this, in the main body of the
I-Ds, no later than sshtm section 3, and again I think that the example of
access control and Notifications needs including so that regardless of the words
used, the steps an implementation must follow are unambiguous.

Tom Petch
>
> > Well, ok as in
> > correct, less ok as
> > in is it easy to read and understand.  I mentally duplicate
> > that text replacing
> > recipient with originator and that is also ok ie I import the
> > Architecture/USM
> > thinking that a transaction has one principal only now we use
> > two different
> > identifiers for that principal, one in NO, the other in NR.
> >
> > Whereas, as I say in my e-mail to Juergen, I cannot get the
> > right meaning out of
> > the e-mail he posted yesterday.
> >
> > "The point is that for notifications, access control
> > uses securityName to identify the notification receiver while SSH
> uses
> > the SSH user name to identify the notification sender. In many
> cases,
> > these will not be the same. So the user at host format allows to make
> > this important distinction. Is this understandable?"
> >
> > That does seem back to front to me but perhaps there is a
> > reading of that that I
> > am missing.
>
> I believe that for notifications, SNMP uses securityname for access
> control for the message **sender** not the notification receiver.
>
> Because in USM the sender and receiver securityName/principal is the
> same, this concept of access control for the sender, not the
> recipient, did not come easy. And if Juergen said "access control uses
> securityName to identify the notification receiver", then he is also
> working under the same bad assumptions I was working under before I
> grok'd the new reality.
>
> >
> > Tom Petch
> >
> > > I think it is unrealistic to expect that we will have this
> > all sorted
> > > out, and find all the incorrect usages, by the end of this
> > week. I do
> > > not expect to have another revision by deadline. If Wes or Joe are
> > > available and in a masochistic mood, maybe they'll get another
> > > revision done.
> > >
> > > The next revision we publish will have to explain this whole thing
> > > better so we are all on the same page (see there is a
> > benefit to only
> > > having 6 people in the WG; imagine the difficulty if more
> > had to be on
> > > the same page). Text welcome. Then we can really start to
> > > fine-tooth-comb these documents for inconsistencies.
> > >
> > > dbh
> > >
> > <snip>
> >
> >
>