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

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

----- Original Message -----
From: "Jeffrey Hutzelman" <jhutz at cmu.edu>
To: "David Harrington" <ietfdbh at comcast.net>; <isms at ietf.org>
Cc: <jhutz at cmu.edu>
Sent: Sunday, March 01, 2009 3:48 PM
Subject: Re: [Isms] wg last call followup - e-mail address


> --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

I am sorry if you found my facetiousness offensive.  It has been over three
years for me, trying to make sense of the mappings, and being convinced with
each successive I-D that either it will not work or I cannot understand it or
...

My point was not that there is not some more information about e-mail format
addresses, but that the text I quote is the first anyone will ever hear about it
if they read the SNMPv3 documents in a sensible order.  And as an introduction,
that sentence is dire (IMO).  The later sentences flesh out the format, the
implementation detail if you like, but there is no statement anywhere of why
this complication is introduced especially as this feature brings fresh
problems, as all the mappings we have had have done.  In particular, it creates
the 'Pasi problem', Command Generator sends a Request with securityName of
Alice, gets a Reponse with securityName of Bob.  Pasi described it as
surprising.  I say unacceptable.  And that is why I specified this scenario in
my other post.  By all means explain that it solves an NO problem - well I think
that that is essential - but if the solution leads to unacceptable results with
CR/CG, then our job is not done.

I say that a paragraph is needed saying what the problem is with NO and how this
solves it ie requirements and design, to me the foundation of my practice as an
engineer.


Tom Petch
> -- Jeff
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms