Re: [Isms] wg last call followup - e-mail address

[Jeffrey Hutzelman <jhutz at cmu.edu>]

--On Sunday, March 01, 2009 09:30:06 AM -0500 David Harrington 
<ietfdbh at comcast.net> wrote:

> > Well, we're not going to have a paragraph like that, because it
> takes
> > totally the wrong tone.  The feature is present because it
> > _does_ need a
> > requirement and is needed.  But yes, there should be a
> > paragraph describing
> > the transport address format; I'm surprised if that's not in there.
>
> If you had looked, you would have found it in the MIB.

Hrm.  I didn't look, only because I figured Tom had, and if he couldn't 
find it, then perhaps we haven't said it prominently enough.


> > Then you're not going to understand, because it's not
> > intended for that use
> > case.  It's specfically for the case of a Notification
> > Originator as an SSH
> > client, where the SNMP securityName names the recipient of the
> > notification, not the originator.
>
> I think that is a misstatement. Per RFC3411 modularity, any
> application should be able to use that format of domain/address. A CG
> could use this format just as well as a NO can. The proxy application
> defined in RFC3413 should be able to use this format just as well as a
> NO.

It's _intended_ for the case I described, where deriving the SSH username 
from the SNMP securityName is likely to produce the wrong answer.  In the 
case of a CG, deriving the SSH username from the SNMP securityName probably 
will produce the correct answer, so the user at host address format is much 
less likely to be used by a CG.  But you're right; that doesn't mean it 
_can't_ be used by a CG.

Nonetheless, I think my previous statement is true -- an NO is the use case 
for the user at host address format, so it's difficult to understand why it is 
useful without considering that case.

-- Jeff