Subject: Re: [Isms] Comments on tmsm-14

From: "tom.petch" <[email-masked]>
Date: Fri, 14 Nov 2008 18:06:26 +0100

<inline>

Tom Petch

----- Original Message -----
From: "Dave Shield" <[email-masked]>
To: "ISMS WG" <[email-masked]>
Sent: Friday, October 24, 2008 11:45 AM
Subject: [Isms] Comments on tmsm-14

>
> filename=ISMS-tmsm-14-comments.txt Transport Subsystem
> -------------------
>
> Section 2
>   The second paragraph ends "with no significant effort..."
> This comes from the text of my previous comments, where the elision was
> intended to indicate that the remainder of the text from draft-12
> should be retained.
>   This paragraph should finish:
>
> "... with no significant effort on his part other than identifying
> requirements and verifying the quality of service being provided."
>

yes but in -15 we now have
'with no significant effort with no  significant effort on his part'

>
> Section 3.2.2.1
>   The final paragraph refers to "tmSecurityLevel".  However no such
> field is defined in this set of documents - the tmStateReference cache
> distinguishes between tmRequestedSecurityLevel and tmTransportSecurityLevel.
> This section should probably refer to 'tmTransportSecurityLevel' (since
> it's talking about incoming messages).
>
fixed in -15
>
> Section 3.2.3
>   The first paragraph talks about extracting security parameters "from
> the transport layer by the Security Model".  Isn't it the secure Transport
Model that extracts these parameters?

Changed in -15  but I think that this change is a mistake.  The Secure Transport
Model may extract them but only to put them in the cache, not to hand them over
to the Message Processing Model; it is the Transport Security Model that passes
them on.

>
> Section 3.3.1
>   Paragraphs three and four talk about "securityName" and "securityLevel".
> Should these be "tmSecurityName" and "tmRequestedSecurityLevel" respectively?

No!!  securityName and securityLevel are different concepts and are the right
ones here.

>
> Section 3.3.2
>   Paragraph one talks about "securityName" and "securityLevel".  Should
> these be "tmSecurityName" and "tmRequestedSecurityLevel" respectively?
>
No!!  securityName and securityLevel are different concepts and are the right
ones here.

>
>   Paragraph two ends with "... the message should be discarded ..."
> Should this be a SHOULD?
>

That would be a material change to the specification and not one I would agree
with.

>
> Section 5.2.2
>   The last two bulletted items do not describe fields within the
> tmStateReference, and should be normal paragraphs.
>
fixed in -15
>
> Section 6.4.1
>   Is the Message Processing Subsystem allowed to modify/utilise the contents
> of the tmStateReference cache?   Surely it just passes this between the
> Transport Model and Security Model?
>

That is what the specification says!  I would call it keeping our options open,
probably wise considering the pain and grief that it has taken to add transport
security to RFC3411.

>
>   Should the set of SNMP Transport Domains be rooted under 'snmpDomains'
> (following RFC 3417) or under 'transportDomains' (following RFC 3419)?
>   Is it worth registering prefixes for some of the commonly-used additional
> transport domains listed in RFC 3419 - e.g.  SNMP-over-UDP/IPv6, or
> SNMP-over-TCP (both v4 & v6)?
>
 I think that snmpDomains is right but note that tmsm-15 s.8 erroneously refers
to snmpDomain

In passing, why is proxy prxy and not proxy?  Is there a length limit of four
characters?

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

---

From: "David Harrington" <[email-masked]>
Date: Sun, 16 Nov 2008 16:26:41 -0600

Hi, 

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
[..]
 
> 'with no significant effort with no  significant effort on his part'

whoops. 

> to the Message Processing Model; it is the Transport Security 

-15- says "before the message is passed to the Message
   Processing Subsystem." It doesn't say it passes the parameters to
the MPM. I believe this is correct.

> No!!  securityName and securityLevel are different concepts 

section 3.3.2 talks about what applications provide; they never
provide tmSecurityName or tmRequestedSecurityLevel.

In section 3.3.1, we use both variable names. Unfortunately, it is not
clear at which point in the process this is done, so it is unclear
which is the right set of variables.

My personal feeling is that applications SHOULD NOT be trying to
select transport sessions. That creates a binding between applications
and transport models that violates RFC3411 modularity. Earlier
revisions said that SNMP recognized no sessions, though the transport
might.

I am not sure how to fix this, and await instructuons from the chair.

> That would be a material change to the specification and not 

Hmmm. I cannot find the paragraph in -15- where this is not already
expressed as SHOULD. I do not understand how this would be a material
change to the specification; a session-based transport model has
always discarded the message if we could not establish a session.

> probably wise considering the pain and grief that it has 

It deliberately does not constrain an MPM.
>  I think that snmpDomains is right but note that tmsm-15 s.8 

which usage do you consider incorrect? I looked at this and do not
think any usage is incorrect. The table heading is just a table
heading, not an OID.

> In passing, why is proxy prxy and not proxy?  Is there a 

yes.
"This registry will contain ASCII
   strings of one to four characters ..."

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Nov 2008 08:09:15 +0100

> I am not sure how to fix this, and await instructuons from the chair.

I suggest to discuss this in the ISMS session later today and then I
might help with reading consensus.

/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/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms