Subject: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Sep 2007 09:02:17 +0200

On Wed, Aug 08, 2007 at 12:17:56PM +0200, Wijnen, Bert (Bert) wrote:
  
> I am confused by the last 2 paragraphs in sect 6.2
> 
>    The prepareOutgoingMessage ASI passes tmStateReference from the
>    Message Processing Subsystem to the dispatcher.  How or if the
>    Message Processing Subsystem modifies or utilizes the contents of the
>    cache is message-processing-model-specific.
> 
>    This may sound underspecified, but keep in mind that a message
>    processing model might have access to all the information from the
>    cache and from the message, and have no need to call a Security Model
>    to do any processing; an application might choose a Security Model
>    such as USM to authenticate and secure the SNMP message, but also
>    utilize a secure transport such as that provided by the SSH Transport
>    Model to send the message to its destination.
> 
> specifically the wording "an application...".
> Applications in our RFC3411 context are CG or CR or NO or NR or such.
> I am sure that is not intended here. But then, what is an "application"
> in this sentence above?
> 
> I am also not sure we should speak about the MPM to "not call a
> security model". From our architectural point of view, the MPM
> will ALWAYS call a security model. If an implementation does a
> shortcut, that is up to them... but should we discuss that here?
> 
> I am similarly confused by the "an application..." in section 6.4
> last paragraph.

I am wondering whether this issue can be solved by simply deleting the
second quoted paragraph since I am not sure it adds value.

/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://www1.ietf.org/mailman/listinfo/isms

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 11 Sep 2007 10:34:52 +0200

Inline

Bert Wijnen  

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 9:02 AM
> To: Wijnen, Bert (Bert)
> Cc: David Harrington; [email-masked]
> Subject: Re: tmStateReference in draft-ietf-isms-tmsm-09.txt
> 
> > security model". From our architectural point of view, the MPM will 
> > ALWAYS call a security model. If an implementation does a shortcut, 
> > that is up to them... but should we discuss that here?
> > 
> > I am similarly confused by the "an application..." in 
> section 6.4 last 
> > paragraph.
> 
> I am wondering whether this issue can be solved by simply 
> deleting the second quoted paragraph since I am not sure it 
> adds value.
> 

That would do it for me.
But iirc, DBH thinks it is important.
I am not hung up on it. But I stay confused if it is kept.

Removing the 2nd para above, does still leave the
use of "an application.." in sect 6.4, right?

Bert

---

From: "tom.petch" <[email-masked]>
Date: Wed, 12 Sep 2007 15:10:57 +0200

<inline -  thrice>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 11, 2007 9:02 AM
Subject: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt

Bert

I am puzzled that you are confused:-)  I read "an application" in this cont was advanced to Full Standard.'

I find this hard to write, needing to be clear what is being alluded to without
setting a load of hares running in all directions; needs to be coy but not too
coy.

Tom Petch
<snip>

---

From: "tom.petch" <[email-masked]>
Date: Wed, 12 Sep 2007 15:10:57 +0200

<inline -  thrice>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 11, 2007 9:02 AM
Subject: [Isms] Re: tmStateReference in draft-ietf-isms-tmsm-09.txt

Bert

I am puzzled that you are confused:-)  I read "an application" in this context
as meaning eg a CG or NO.  RFC3411 4.1.1.
   'The PDU Dispatcher provides the following primitive for an
   application to send an SNMP Request or Notification to another SNMP entity:'
.......
'    IN   transportDomain           -- transport domain to be used
     IN   transportAddress          -- transport address to be used
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model to use'
so the application chooses the securityModel and secure transport; I see no
problem with the text.

Removing the paragraph removes the mention of USM over secure transport.  OK,
this combination is problematic, as has been pointed out already, but if the
conclusion is that it is impossible, then I would like that explicit, not
implicit in the removal of a paragraph.

> > shortcut, that is up to them... but should we discuss that here?

I agree, calling the SM should be mandatory even if it is  no-op.

> > I am similarly confused by the "an application..." in section 6.4

Again, I am puzzled that you are confused; this paragraph makes sense to me.

Tom Petch

ext
as meaning eg a CG or NO.  RFC3411 4.1.1.
   'The PDU Dispatcher provides the following primitive for an
   application to send an SNMP Request or Notification to another SNMP entity:'
.......
'    IN   transportDomain           -- transport domain to be used
     IN   transportAddress          -- transport address to be used
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model to use'
so the application chooses the securityModel and secure transport; I see no
problem with the text.

Removing the paragraph removes the mention of USM over secure transport.  OK,
this combination is problematic, as has been pointed out already, but if the
conclusion is that it is impossible, then I would like that explicit, not
implicit in the removal of a paragraph.

> > shortcut, that is up to them... but should we discuss that here?

I agree, calling the SM should be mandatory even if it is  no-op.

> > I am similarly confused by the "an application..." in section 6.4

Again, I am puzzled that you are confused; this paragraph makes sense to me.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Sep 2007 18:11:29 +0200

> use of "an application.." in sect 6.4, right?

Perhaps this paragraph can go as well.

There is a more general question concerning combinations such as USM
over SSH which I think comes up in another thread and perhaps we need
explicit text about this that will allow us to replace these two
paragraphs. But I have to re-read the other threads again first...

/js

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 13 Sep 2007 08:53:35 +0200

Maybe I read/interpreted "an application may use.." instead of "an
application may choose....".

Even so, if we DO mean NO or CG, then maybe we should say that,
that takes away at least some of the potential confusion in my
mind. But I have to go reread/study now that I see your comments.

Bert Wijnen  

> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, September 12, 2007 3:11 PM
> To: [email-masked]; Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: [Isms] Re: tmStateReference in 
> draft-ietf-isms-tmsm-09.txt
> 
> <inline -  thrice>
> Tom Petch
> 
> I am puzzled that you are confused:-)  I read "an 
> application" in this context as meaning eg a CG or NO.  RFC3411 4.1.1.
> so the application chooses the securityModel and secure 
> transport; I see no problem with the text.
> 
> Removing the paragraph removes the mention of USM over secure 
> transport.  OK, this combination is problematic, as has been 
> pointed out already, but if the conclusion is that it is 
> impossible, then I would like that explicit, not implicit in 
> the removal of a paragraph.
> 
> deleting the

---

From: "David Harrington" <[email-masked]>
Date: Thu, 13 Sep 2007 08:01:30 -0400

Hi,

I suspect your confusion is between a "software application" and an
"SNMP application".
A software application might be a commercial NMS product that utilizes
the services of an SNMP stack (or contains an SNMP stack), whereas an
SNMP application is within the SNMP stack.

In reality, it is very possible that neither chooses anything; it
might be an operator that makes the choice, and he tells the software
application what to use, and then the software application tells the
SNMP application what to use, and the SNMP application tells the SNMP
engine what to use.

Let's take choice out of the issue. 

I changed an "application chooses" to an "application specifies". Now
it really makes no difference whether that is the software application
specifying or the SNMP application specifying; they work togethet to
pass the choice into the system.

Overloading terms often leads to ambiguity. But the SNMPv3 WG chose
application over other non-overloaded terminology (such as orangelet).
Now we have to live with the decision.

I believe it would be inappropriate to change "application" to "NO or
CG" since there are other applications already defined (proxy) and the
framework permits additional applications to be added. We should not
inadvertently constrain the framework by saying that it must be an NO
or a CG specifying this information.

dbh

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Thursday, September 13, 2007 2:54 AM
> To: tom.petch; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Isms] Re: tmStateReference in 
> section 6.4

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 14 Sep 2007 10:25:38 +0200

OK. I can live with that

Bert Wijnen  

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, September 13, 2007 2:02 PM
> To: Wijnen, Bert (Bert); 'tom.petch'; 
> [email-masked]
> Cc: [email-masked]
> I suspect your confusion is between a "software application" 
> and an "SNMP application".
> A software application might be a commercial NMS product that 
> utilizes the services of an SNMP stack (or contains an SNMP 
> stack), whereas an SNMP application is within the SNMP stack.
> 
> In reality, it is very possible that neither chooses 
> anything; it might be an operator that makes the choice, and 
> he tells the software application what to use, and then the 
> software application tells the SNMP application what to use, 
> and the SNMP application tells the SNMP engine what to use.
> 
> I changed an "application chooses" to an "application 
> specifies". Now it really makes no difference whether that is 
> the software application specifying or the SNMP application 
> specifying; they work togethet to pass the choice into the system.
> 
> Overloading terms often leads to ambiguity. But the SNMPv3 WG 
> chose application over other non-overloaded terminology (such 
> as orangelet).
> I believe it would be inappropriate to change "application" 
> to "NO or CG" since there are other applications already 
> defined (proxy) and the framework permits additional 
> applications to be added. We should not inadvertently 
> constrain the framework by saying that it must be an NO or a 
> CG specifying this information.
> 
> dbh
> 
> > Even so, if we DO mean NO or CG, then maybe we should say 
> that, that 
> > takes away at least some of the potential confusion in my 
> mind. But I 
> > have to go reread/study now that I see your comments.
> > 
> > Bert Wijnen
> > 
> > > I am puzzled that you are confused:-)  I read "an application" in 
> > > this context as meaning eg a CG or NO.
> > RFC3411 4.1.1.
> > > transport.  OK, this combination is problematic, as has 
> been pointed 
> > > out already, but if the conclusion is that it is 
> impossible, then I 
> > > would like that explicit, not implicit in the removal of a 
> > > paragraph.
> > >