Subject: [Isms] final last call on isms-radius-vacm-07 (deadline 2010-07-13)

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jul 2010 13:22:28 +0200

Hi,

Randy posted http://tools.ietf.org/html/draft-ietf-isms-radius-vacm-07
and here is the final last call to verify that everybody is happy with
revision. As you might recall, the last rewrite resulted from comments
we received from David Harrington. This final last call ends in one
week on July 13th. This is going to be a strict deadline.

Small nits that are discovered during this review period can be
collected by the editor (Randy) and then we can decide whether we deal
with them as part of the IESG procedure or spin a new ID (the reason
is that we hit the cutoff period).

I am attaching my document writeup. I am also happy to receive
feedback on the document writeup, in particular information whether
anybody is implementing this specification or planning to implement
this specification.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 6 Jul 2010 13:22:37 -0400

Hi,

me again. really guys, I'm trying to reach a point of full support for
the doc, without raising any new issues. but I have a few concerns
about the new text that I think should be addressed before sending
this to IESG. and unfortunately, I'm not sure an RFC editor note will
suffice for some of it. I know I looked at the rewrite already, but
the same eyes on different days see different things. Sorry for the
verbosity, but I'm trying to explain the problem, not just propose
simple rewordings. Maybe I'm wrong and these things can be ignored,
but please at least look at these points.

1) in 5.2, there is a discussion of multiple concurrent security
models. Doesn't this also support multiple concurrent transport
models, now that we use the prefix to disambiguate the transport model
associated with the sessionID? I don't think that's clear in 5.2 (but
might be clear enough elsewhere)

2) I think the "unique identifier of a session" is really the unique
identifier of a transport model session, and tmsessionid depends on a
transport model to generate such an id. (Note that I am not saying the
unique identifier of a transport session, only the transport model
session.) 

(Hmmm, let's see, have I argued that transport sessino ID should not
be used because the VACM subsytem shouldn't have access to the
transport model info? Am I contradicting myself? I don't remember. boy
this architecture makes my head hurt ...)

While there is text that says other AAA or non-AAA mechanisms can be
used as well, you really need an identifier that
signifies/implies/provides the binding between a transport connection
(I think this might be the NAS session in AAA terms) and the
authenticated identity and the dynamically-provided
service-authorization (as is provided by SSHTM and TLSTM). This is the
purpose of a transport model session. Then this specification adds the
data-access-authorization to the existing transport/user/service
binding.

So, if, as an implementer, I am using my own home-grown authentication
and authorization mechanism, I will need to provide some type of
tmsessionID that implies a security binding between the connection,
the identity, and the service. i.e., I need to provide a tmsessionID.
and **tm**sessionID implies I really need to define (at least loosely)
a transport model. The tmsessionid is used as an example, but I am not
sure any other sessionid would work.

Guidelines for developing a transport model are provided in the 559x
series, but by having this spec not say that they really need to
develop a transport model, implementers might be more apt to not
follow the guidelines and to make mistakes.

So I think the text about other mechanisms should be tightened up to
being "other standard or proprietary transport models", possibly with
a pointer to the requirements specified in 5590.

3) in 7.2 we start dealing with the transport model prefix. I like
this choice because the prefix makes it pretty clear what's in use,
compared to an OID. This has a couple implications however.

   Registry Name: SNMP Transport Domains
   Reference: [RFC2578] [RFC3417] [RFC5590]
   Registration Procedures: Specification Required
   Each domain is assigned a MIB-defined OID under snmpDomains

3a) I think the text needs to identify the IANA registry more clearly.
Currently, the text just points to RFC5590; I think it should
reference the IANA registry directly, because other RFCs define
prefixes as well. Since we only point to 5590, it might not be clear
that 5592 also registers some prefixes. And TLSTM registers prefixes.
And other specfications used to register prefixes won't be obvious
from looking at 5590, but would be obvious looking at the registry.
(and someplace the rfc editor provided guidance about how to reference
IANA registries.)

3b) the text refers to the "registered prefix". This means any prefix
used for AAA-VACM must be registered. The registry requires a
specification, and requires transport domains that are registered
under snmpDomains. I don't think the current text that talks about
other mechanisms makes it clear that these specification and
registration requirements exist. 

4) If somebody makes up their own prefix without registering it, they
could create conflicts with existing standard prefixes (or two
proprietary implementations might choose the same prefix). The
registration mechanism basically asserts the need to develop a
***transport model*** specification to help ensure interoperability.
(supporting my point 2)

5) If an implementer mistakenly used "ssh" as the prefix for their own
SSH-based authentication mechanism without all the MUST NOTs found in
5592, this would assert to an operator-configured AAA-VACM that the
tmSessionID was generated by SSHTM, and this could create security
vulnerabiltiies as a result of using two concurrent transport models
that are not clearly dis-ambiguated. Since AAA-VACM doesn't check the
authentication assertion implicit in the "ssh" prefix, a hacker might
be able to compromise the system. 

The potential vulnerabilities of prefix usage is not discussed in
security considerations.

(Given thet we just added the transport model identifier, SecCons
doesn't talk about a false assertion of the transport model at all,
whether identified using a prefix or an OID. I'm not quite sure what
the vulnerability might be.)

6) in 7.1, early session termination MAY result in denial of access.
should this be a SHOULD? (with an example exception being that an
implementation can distinguish between requests received before
session termination but not yet processed, from those recieved after
session termination). In AAA standards, is there support for
deliberately interupting processing to revoke existing authorization
policy? If so, then maybe this should be a MUST. or maybe SHOULD is
appropriate because it depends on the specific authorization
mechanism, and might be MAY for some, SHOULD for others, and MUST for
some (and if this is the case, this should be discussed in SecCons).

7) I think the security considerations should include a pointer to
7.2.3. I am not sure if somehow this could be turned into an attack,
but a security admin looking at the security considerations should be
made aware that this groupname re-assignment is supported, because the
assumptions in this spec need to match the assumptions in the
AAA-style authorization mechanism. Just a SecCons note with a pointer
to 7.2.3 is all I suggest.

8) an operational consideration: tmsessionid is being used as an index
in the mib. is tmsessionid guaranteed to be sufficiently predictable,
including with proprietary transport models, to ensure that an
operator can do manual config of an entry when needed, suhc as for
debugging?

9) I am a bit concerned about the ambiguity in the name of
vacmAaaTransportSessionID, and the description in the table that talks
about a session, without clarifying it is a transport model session,
not necessarily a transport session.

Hope this helps.

Randy (and the rest of the WG), keep up the good work. I know this is
irritating to get these late comments.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, July 06, 2010 7:22 AM
> To: [email-masked]
> Subject: [Isms] final last call on isms-radius-vacm-07 
> (deadline 2010-07-13)
> 
> Hi,
> 
> Randy posted
http://tools.ietf.org/html/draft-ietf-isms-radius-vacm-07
> and here is the final last call to verify that everybody is 
> happy with revision. As you might recall, the last rewrite 
> resulted from comments we received from David Harrington. 
> This final last call ends in one week on July 13th. This is 
> going to be a strict deadline.
> 
> Small nits that are discovered during this review period can 
> be collected by the editor (Randy) and then we can decide 
> whether we deal with them as part of the IESG procedure or 
> spin a new ID (the reason is that we hit the cutoff period).
> 
> I am attaching my document writeup. I am also happy to 
> receive feedback on the document writeup, in particular 
> information whether anybody is implementing this 
> specification or planning to implement this specification.
> 
> /js
> 
> --

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Jul 2010 10:39:53 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 06, 2010 4:22 AM
> Subject: [Isms] final last call on isms-radius-vacm-07 (deadline 2010-07-13)
>
> Hi,
> 

Ooops.  I already posted -08 with the spelling change Juergen requested.
 
> anybody is implementing this specification or planning to implement

In the writeup, s/helped to with/helped with/

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jul 2010 20:59:08 +0200

On Tue, Jul 06, 2010 at 07:22:37PM +0200, David Harrington wrote:

> [...] Sorry for the verbosity, but I'm trying to explain the
> problem, not just propose simple rewordings. Maybe I'm wrong and
> these things can be ignored, but please at least look at these
> points.

As co-chair, I like to ask you to send us proposed rewordings so that
we can be sure we understand the changes you want to be carried out.

This is going to be the final WG last call - contributors who want
additional changes to the document are expected to help us by being
precise concerning the changes they want applied to the document.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Jul 2010 20:09:59 -0700

Hi -

(As a technical contributor)

> From: "David Harrington" <[email-masked]>
> To: "'Juergen Schoenwaelder'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 06, 2010 10:22 AM
> Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13)
....
> might be clear enough elsewhere)

Rather than adding more verbiage, I propose deleting
the following sentence from section 5.2 to address this comment:

   This index structure was chosen to support use cases
   in which a given user could potentially have multiple concurrent
   sessions, and to support environments in which multiple security
   models might find concurrent usage.

Since this is only explanatory text, deleting it will have no normative
impact.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Jul 2010 20:20:30 -0700

Hi -

As a technical contributor...

> Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13)
...
> (and someplace the rfc editor provided guidance about how to reference

Proposed change to section 4.1:
OLD:
   The tmSessionID (along with its transport model prefix) [RFC5590] is
   a suitable identifier for a AAA-authorized "session".  This is

NEW:
   The tmSessionID (along with its transport model prefix from the SNMP
    Transport Domains registry) [RFC5590] is a suitable identifier for a
   AAA-authorized "session".  This is

Proposed change to section 6.2:
OLD:
   [RFC3411].  The module also relies on the IANA registry defined in
   [RFC5590] for transport domain prefixes.

NEW:
   [RFC3411].  The module also relies on the IANA SNMP Transport
   Domains registry defined in [RFC5590] for transport domain prefixes.

Section 7.2:
OLD:
   o  a session identifier, such as tmSessionID [RFC5590] along with the
      prefix for its transport domain, as a definitive identifier of the
      transport session that the AAA authorization is tied to;

NEW:
   o  a session identifier, such as tmSessionID [RFC5590] along with the
      prefix for its transport domain from the SNMP Transport Domains
      registry, as a definitive identifier of the transport session that the
      AAA authorization is tied to;

> registration requirements exist. 

I see no need to replicate requirements from other RFCs - to do so
is simply to invite maintenance headaches.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Jul 2010 20:39:29 -0700

Hi -

...
> ***transport model*** specification to help ensure interoperability.

The prefix  only serves to make the ID unique.  (in any sane implementation
strategy, the ID would be unique anyway, IMO - the need for the prefix is
merely an artefact of the way the architecture is described, and makes
no sense in terms of what needs to happen inside a master agent)
It doesn't really matter what the value is, as long as there are no
clashes within a particular implementation.

> 5592, this would assert to an operator-configured AAA-VACM that the

What do you mean by "operator-configured"?  There are no configurable
objects in this MIB module.

> be able to compromise the system. 

An earlier version of the i-d specifically addressed the trust issues -
folks were quite adamant in wanting them removed.

> The potential vulnerabilities of prefix usage is not discussed in

Broken implementations are infinitely vulnerable.  I think trying to
identify all the possible bugs that might occur in implementations
would not be at all helpful.
 
> the vulnerability might be.)

Previous comments removed the language from the security
considerations section that would have pre-emptively
addressed this issue.

But the fact is that the transport model identifier is merely a
uniquifier.  NOTHING in this MIB module attributes any semantics
to the value.

If we do *anything* about this comment, my preference would be to
remove all reference to the transport model identifier, and instead
of providing any helpful references to tmSessionID, to simply replace
it with words about a "unique identifier for each session, derived in
an implementation-specific manner". 

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Jul 2010 20:47:41 -0700

Hi -

...
> should this be a SHOULD?

No.  I think you're over-analyzing.

Whether termination results in denial of access will depend on
how VACM was configured in the first place.  For example, if VACM
would have allowed access anyway, session termination won't
impact the operation, unless the implementation builds in special
hooks to terminate in-progress operations.  I think *requiring* implementations
to add such hooks would be a huge step in the wrong direction.

> (with an example exception being that an

Let's not go there.

This is very much bound up in how the master agent queus and dispatches,
and I think we should avoid over-prescribing this extreme corner case.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Jul 2010 20:55:50 -0700

Hi -

(as a technical contributor...)

...
> to 7.2.3 is all I suggest.

Uhhh...  What about the current first paragraph of the security considerations
section?  It spells out the issue in full detail.  I suggest no action is needed here.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Jul 2010 20:58:23 -0700

Hi -

...
> operator can do manual config of an entry when needed, suhc as for

Since there are no writeable objects in this MIB module, I think this issue
is out of scope, and no action is needed.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Jul 2010 21:08:48 -0700

Hi -

...
> not necessarily a transport session.

Thinking like an implementor, this seems to be a distinction without a difference.

The current I-D says:
      DESCRIPTION "A specific identifier of the session.
                   This value MUST be unique among all
                   currently open sessions within a transport model.
                   The value has no particular significance other
                   to distinguish sessions.  An example of a suitable
                   value would be tmSessionID."

If this terminology is readlly a problem, I think we should stop trying to
be helpful, remove the transport prefix, and just say that the
session id is unique within a master agent, derived by implementation-
specific means.  In sane implementations, it will end up having
exactly the same bit pattern as tmSessionID, but we won't mention that.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jul 2010 11:34:26 -0400

+1
dbh 

> Behalf Of Randy Presuhn
> Sent: Tuesday, July 06, 2010 11:10 PM
> To: [email-masked]
> Subject: [Isms] radius-vacm section 5.2 (was: final last call 
> onisms-radius-vacm-07 (deadline2010-07-13))
> 
> Hi -
> 
> > To: "'Juergen Schoenwaelder'" 
> <[email-masked]>; 
> > <[email-masked]>
> Rather than adding more verbiage, I propose deleting the 
> following sentence from section 5.2 to address this comment:
> 
> Since this is only explanatory text, deleting it will have no 
> normative impact.
> 
> Randy
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jul 2010 12:03:36 -0400

> From: [email-masked] [mailto:[email-masked]] On 
+1 on the changes proposed for 3) and 3a)

> I see no need to replicate requirements from other RFCs - to 
> do so is simply to invite maintenance headaches.

My point is that this spec really promotes the idea of "other
mechanisms" besides standard AAA and standard transort models. I
understand that you want to allow for non-standard AAA, such as
TACACS+, and proprietary authentication and authroization mechanisms
such as those that already exist internally for CLI transport,
authentication and authorization. 

However, because you are using the transport model prefix, you are
forcing it to be true, even for proprietary other mechanisms, that you
MUST specify a transport model and MUST register the domain and
prefix. It might not be obvious to somebody developing support for
other mechanisms (specifically other secure transport, such as a
non-5592 SSH-based secure transport) that they need to write a
specification, make it publicly available, and register the domain and
prefix or it can cause interoperability and security problems. I do
not think this spec has been clear on that point and would like to see
that stated much more clearly. 

dbh

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jul 2010 12:08:06 -0400

OK. I agree I might be over-analyzing on this point.

dbh 

> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Tuesday, July 06, 2010 11:48 PM
> To: David Harrington; 'Juergen Schoenwaelder'; [email-masked]
> Subject: radius/vacm section 7.1 (was Re: [Isms] final last 
> call on isms-radius-vacm-07 (deadline2010-07-13))
> 
> Hi -
> 
> Whether termination results in denial of access will depend 
> on how VACM was configured in the first place.  For example, 
> if VACM would have allowed access anyway, session termination 
> won't impact the operation, unless the implementation builds 
> in special hooks to terminate in-progress operations.  I 
> think *requiring* implementations to add such hooks would be 
> a huge step in the wrong direction.
> 
> > (with an example exception being that an implementation can 
> > distinguish between requests received before session 
> termination but 
> > not yet processed, from those recieved after session 
> termination). In 
> > AAA standards, is there support for deliberately interupting 
> > processing to revoke existing authorization policy? If so, 
> then maybe 
> > this should be a MUST. or maybe SHOULD is appropriate because it 
> > depends on the specific authorization mechanism, and might 
> be MAY for 
> > some, SHOULD for others, and MUST for some (and if this is 
> the case, 
> > this should be discussed in SecCons).
> 
> Let's not go there.
> 
> This is very much bound up in how the master agent queus and 
> dispatches, and I think we should avoid over-prescribing this 
> extreme corner case.
> 
> Randy
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jul 2010 12:15:43 -0400

Hi,

I disagree that the first paragraph spells out the issue of replacing
a groupname in an existing entry. But I'm will to let this slide for
the sake of getting the draft submitted.

dbh

> Sent: Tuesday, July 06, 2010 11:56 PM
> To: [email-masked]
> Subject: [Isms] pointer to 7.2.3 Re: final last call on 
> isms-radius-vacm-07(deadline2010-07-13)
> 
> Hi -
> 

> Uhhh...  What about the current first paragraph of the 
> security considerations section?  It spells out the issue in 
> full detail.  I suggest no action is needed here.
> 
> Randy
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jul 2010 13:05:17 -0400

Hi 

Let me recommend a slightly different approach.

You refer to sane implementations, when what you mean is
implementations that would make the same assumptions (presumably sane)
that you would make.
But some of the assumptions you make are not borne out by existing
standards.
For example, you assume that in a sane implemntation tmSessionID will
be unique across all transport models, so it doesn't really need the
prefix. However, the standards only require tmSessionID to be unique
within a single transport model, so not all implementers will
necessarily make the same assumption you make. Therefore, we require
something to disambiguate the transport model within which it is
unique.

The problem, in my eyes, is that we are overloading tmSessionID to
also serve as the AAA-VACM sessionID, but they might actually have
different requirements for different purposes. 

So how about a section of "implementer guidelines" that spell out a
few of these potential conflicts between implementer assumptions and
the standards? Let's provide guidleines:
1) the sessionID for AAA-VACM is really an identifier of a
AAA-authenticated session.
2) since tmSessionID may also represent a AAA-authenticated session,
this could make a reasonable sessionID, but these really are designed
for different purposes, so an implementer should make no assumptions
about the contents of the tmSessionID (which would include the
uniqueness across all transport models assumption).
3) (if we drop the usage of prefix, then) SessionID must be unique
across all transport models, not just within a single transport model.
tmSessionID is unique only within a transport model, but is
implementation-defined. An implementation MAY choose to make their
tmSessionIDs unique across all transport models, so they can be used
as AAA-VACM session IDs.

If we do that, we have provided the helpful advice you want, without
overloading tmSessionID.
we can eliminate the prefix usage, which eliminates the implications I
raised.
and I will be happy seeing the clear distinction between tmSessionID
and the AAA-VACM sessionID.

dbh

> Sent: Wednesday, July 07, 2010 12:09 AM
> To: [email-masked]
> Subject: [Isms] transport (model) session? (was: Re: final 
> last call onisms-radius-vacm-07 (deadline2010-07-13))
> 
> Hi -
> 
> If this terminology is readlly a problem, I think we should 
> stop trying to be helpful, remove the transport prefix, and 
> just say that the session id is unique within a master agent, 
> derived by implementation- specific means.  In sane 
> implementations, it will end up having exactly the same bit 
> pattern as tmSessionID, but we won't mention that.
> 
> Randy
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 7 Jul 2010 11:41:54 -0700

Hi -

> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, July 07, 2010 9:03 AM
> Subject: RE: [Isms] radius/vacm section 7.2 (was Re: final last call onisms-radius-vacm-07 (deadline2010-07-13))
...
> prefix.

Only because the architecture does not guarantee sessiod ID
uniqueness, even though as a practical matter the SNMP engine
must maintain some way of uniquely identifying sessions, because
command responders MUST have this information in order to
send responses to the right place.  IMO it's an imaginary tail
wagging this dog.

> It might not be obvious to somebody developing support for

I think requiring a specification for such cases is a very good thing.

However, I do not see how failure to do so can cause the interoperability or
security problems you fear.  As long as the prefixes used by the transport models
supported by an implementation do not collide, things will just work.
The *SOLE* function of the transport model prefix here is to make up
for the theoretical lack of uniqueness in implementations that choose
to use tmSessionID as the source of those 32 bits of identifier.  It
doesn't matter what the value of the prefix is, as long as it
makes the index unique among all currently open sessions.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jul 2010 18:19:15 -0400

Hi,

As I said, I wanted the WG to consider my points. You have.
Randy and Juergen, I trust your judgement. Do as you see fit.

dbh 

> Sent: Wednesday, July 07, 2010 2:42 PM
> To: [email-masked]
> Subject: Re: [Isms] radius/vacm section 7.2 (was Re: final 
> last callonisms-radius-vacm-07 (deadline2010-07-13))
> 
> Hi -
> 
> > Subject: RE: [Isms] radius/vacm section 7.2 (was Re: final 
> last call 

> must maintain some way of uniquely identifying sessions, 
> because command responders MUST have this information in 
> order to send responses to the right place.  IMO it's an 
> imaginary tail wagging this dog.
> 
> > It might not be obvious to somebody developing support for other 
> > mechanisms (specifically other secure transport, such as a
> However, I do not see how failure to do so can cause the 
> interoperability or security problems you fear.  As long as 
> the prefixes used by the transport models supported by an 
> implementation do not collide, things will just work.
> The *SOLE* function of the transport model prefix here is to 
> make up for the theoretical lack of uniqueness in 
> implementations that choose to use tmSessionID as the source 
> of those 32 bits of identifier.  It doesn't matter what the 
> value of the prefix is, as long as it makes the index unique 
> among all currently open sessions.
> 
> Randy
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Jul 2010 14:49:14 +0200

> exactly the same bit pattern as tmSessionID, but we won't mention that.

Speaking as technical contributor...

I suggest to remove vacmAaaTransportModel and to make
vacmAaaTransportSessionID a unique identifier.

      DESCRIPTION "A specific identifier of the session.  This value
                   MUST be unique among all currently open sessions of
                   all transport models.  The value has no particular
                   significance other to distinguish sessions.
                   Implementations in which tmSessionID happens to be
                   unique across all transport models may use the
                   tmSessionID value."

This makes the MIB module simpler (simpler table index), ensures the
uniqueness required and provides implementation hints covering the
most likely case that tmSessionID is actually globally unique.

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 8 Jul 2010 09:27:49 -0400

+1

---

From: "David Harrington" <[email-masked]>
Date: Thu, 8 Jul 2010 11:18:37 -0400

+1

dbh 

> Behalf Of David B. Nelson
> Sent: Thursday, July 08, 2010 9:28 AM
> To: [email-masked]
> Subject: Re: [Isms] transport (model) session? (was: Re: 
> final last call onisms-radius-vacm-07 (deadline2010-07-13))
>