Subject: [Isms] transport subsystem and new terminology

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Jul 2006 15:01:20 +0200

Dave,

if I recall your proposal correctly, you wand to introduce a transport
subsystem with proper ASIs and then we would define an SSH transport
model which can be used with a session-based security model. I wonder
whether this change will also affect the titles of our documents:

- Will the document "Transport Mapping Security Model (TMSM)
  Architectural Extension for the Simple Network Management Protocol
  (SNMP)" become "Session-based Security Model (SSM) Architectural
  Extension for the Simple Network Management Protocol (SNMP)" or
  something close to that? (Perhaps even just "Session-based Security
  Model for the Simple Network Management Protocol (SNMP)" would do
  it?)

- Will the "Secure Shell Security Model for SNMP" become something
  like "Secure Shell Transport Model for the Simple Network Management
  Protocol (SNMP)"? Or more precise perhaps "Secure Shell Transport
  Model for the Session-based Security Model of the Simple Network
  Management Protocol (SNMP)"?

What do you intend to do? And can you post the draft ASIs for the
transport subsystem as you see them so we do not have to wait until
all the edits have been done?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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

---

From: "David Harrington" <[email-masked]>
Date: Mon, 24 Jul 2006 17:07:23 -0400

Hi,

I think the resulting documents would be "SSH Transport Mapping" and
"Session-based Security Model".
I will over the next few weeks break down what needs to be changed to
effect the split.

My planned split was based on assumptions that we were accepting that
there no special procedures were rqeuired to support notifications. If
we are changing that assumption, based on Wes's email and based on the
issues you raised at IEFF66, my planned split may not be possible.

I have committed my time for this coming week to work on company
projects, so I will probably not have a lot of time to analyze the
impact on TMSM and SSHSM of Wes's three approaches. His approaches are
not described in terms of RFC3411 architectural modularity, and I
would like to better understand how his stuff fits into the RFC3411
architecture, and the EOP I have in the current documents.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 9:01 AM
> To: Dave Harrington
> Cc: [email-masked]
> Subject: [Isms] transport subsystem and new terminology
> 
> Dave,
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 26 Jul 2006 15:44:31 -0700

>>>>> On Mon, 24 Jul 2006 17:07:23 -0400, "David Harrington" <[email-masked]> said:

David> I have committed my time for this coming week to work on company
David> projects, so I will probably not have a lot of time to analyze the
David> impact on TMSM and SSHSM of Wes's three approaches. His approaches are
David> not described in terms of RFC3411 architectural modularity, and I
David> would like to better understand how his stuff fits into the RFC3411
David> architecture, and the EOP I have in the current documents.

David, since you don't have time to do an analysis (and I just got
back into town from vacation and don't have time to write much up
quickly), I'll answer your questions:

1) the architecture described in my message does fit into 3411
   models.  I need more details about which of the 341x architectures
   you think don't fit.

2) based on another message, there may be a typo or two in the message
   (it was mostly un-proof-read) at least in the usage of the terms NG
   and NR.  I need to review it along side your comments on the
   subject.

I don't believe I proposed anything that violates 3411 architectural
concepts.  The only potential break is who opens the transport through
which SNMPv3 messages get sent (EG, either the NG or the NR could).
-- 
Wes Hardaker
Sparta, Inc.