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

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

This is probably not editorial but I cannot tell.

I commented during the last round time how hard I find it to understand parts of
these I-Ds and a concrete example of this is the e-mail address format we now
have for transportAddress.

Assume I read all of RFC341x, then tmsm, tsm and sshtm and am almost at the end
of my journey of discovery and then I encounter
"      (If the session was not opened locally with a user at example.com
      formatted tmTransportAddress, ..."

Hang on, what have I missed?  Re-read all the foregoing and I am none the wiser;
this is indeed the first reference.  Why have e-mail format addresses? What
function do they serve?  Reverse engineer the ASI and EOP and I am fairly sure
that they do not work, or more likely I cannot understand the relevant text.  I
thought this when Wes proposed wording for it last month; I waited for the
complete I-Ds before I tried again but am still none the wiser.

I have read every post on this list for years ... but that helps me none.  The
nearest is Jeff saying that this overcomes an asymmetry in SSH.  Well, yes, I
track SSH and understand its asymmetry; and am none the wiser:-(

What I think essential is an expanatory paragraph, much earlier, in tmsm even
(thinking that another transport model might find a use for this) saying eg

"The transportAddress, as passed by the application may take the form
user at example.com:port
The 'user' part may be used to establish a transport and then be used by the
remote engine as securityName.  The local engine still uses securityName as well
and so has two names, one of which is used somewhere and the other elsewhere
making this specification hard to understand, dysfunctional even.  This
capability meets no known requirement but there is a good reason for it being
present".

Well, you might find a better pair of the last two sentences but after expending
so much effort, I am a tad frustrated at my lack of understanding:-).  I really
would like to understand why we introduced this and how it works.  My current
focus is on a Command Generator as ssh client and the processing of outbound
Request and inbound Response; forget about Command Responders and Notification
engines for the moment.

Wes?
Jeff?
Dave?
Dave?

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
To: <isms at ietf.org>
Sent: Thursday, February 26, 2009 8:53 AM
Subject: [Isms] wg last call followup


> On November 4th 2008, I started WG last call on the ISMS document set:
>
> [1] Transport Subsystem for the Simple Network Management Protocol (SNMP)
>     <draft-ietf-isms-tmsm-15.txt>
> [2] Transport Security Model for SNMP
>     <draft-ietf-isms-transport-security-model-10.txt>
> [3] Secure Shell Transport Model for SNMP
>     <draft-ietf-isms-secshell-13.txt>
> [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple
>     Network Management Protocol (SNMP) Transport Models
>     <draft-ietf-isms-radius-usage-04.txt>
>
> We received some comments and the subsequent mailing list discussions
> have led to some changes to the ISMS core documents. David just posted
> revised IDs of the core documents:
>
> [1] Transport Subsystem for the Simple Network Management Protocol (SNMP)
>     <draft-ietf-isms-tmsm-16.txt>
> [2] Transport Security Model for SNMP
>     <draft-ietf-isms-transport-security-model-11.txt>
> [3] Secure Shell Transport Model for SNMP
>     <draft-ietf-isms-secshell-14.txt>
>
> Please take a look at the changes. Let us know by March 6th if there
> are any major technical problems with the changes that must be fixed
> before submitting the documents to the AD for publication.  Please
> keep in mind that we are going for Proposed Standard, the entry-level
> maturity level for the standards track.
>
> If you find editorial issues, please report them clearly marked as
> editorial issues.
>
> /js