Subject: [Isms] TLSTM counters issue

From: Wes Hardaker <[email-masked]>
Date: Mon, 25 Jan 2010 10:28:42 -0800

Robert Story sent me comments on the draft as well (in between the first
last call and Juergen's request for final comments by the 19th) and I
was looking into his comments.  One issue that he brought up is that
with the current MIB we have the following two counters:

  snmpSshtmSessionOpens
  snmpSshtmSessionCloses

These both describe "client" side connection open and closes.  This
exactly mirrors the SSHTM MIB.  But he brings up a good point that it
would be useful to have similar counters on the server side.

So, the choices are:

1) Don't add them (SSH doesn't have server side counters)
2) Add them and change the name of the originals so we have:
  snmpSshtmSessionClientOpens
  snmpSshtmSessionClientCloses
  snmpSshtmSessionServerOpens
  snmpSshtmSessionServerCloses
3) Change the current counters so they summarize both client and server
   side connections.  Note that I don't think this is a valid option
   since if I recall the original counter text actually was counting
   both sides and the WG wanted the counters to mirror the client-side
   behavior of the SSH document.  So I think the only valid choices,
   based on the past history, are #1 and #2 above.

Thoughts?

The new counters, if desired, would be:

snmpTlstmSessionServerOpens  OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times a (D)TLS session has been
                 successfully established on a (D)TLS server.
                "
    ::= { snmpTlstmSession N }

snmpTlstmSessionServerCloses  OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times a (D)TLS session has been
                 closed on a (D)TLS server.
                "
    ::= { snmpTlstmSession N }

Note that the client side text is a bit different since we're really
counting ASI invocations regardless of whether they succeed or fail:

       "The number of times an openSession() request has been
       executed as an (D)TLS client, whether it succeeded or failed."

On the server, you can't necessarily count failed session invocations to
you.  And I'm not sure how you'd a failed closed session, since you'd
always delete it from your session list which is functionally always
closed on the server side.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Robert Story <[email-masked]>
Date: Mon, 25 Jan 2010 14:04:53 -0500

On Mon, 25 Jan 2010 10:28:42 -0800 Wes wrote:
WH> 
WH> Robert Story sent me comments on the draft as well (in between the first
WH> last call and Juergen's request for final comments by the 19th) and I
WH> was looking into his comments.  One issue that he brought up is that
WH> with the current MIB we have the following two counters:
WH> 
WH>   snmpSshtmSessionOpens
WH>   snmpSshtmSessionCloses

I assume you mean snmpTlstmSession*, here and below.

WH> 2) Add them and change the name of the originals so we have:
WH>   snmpSshtmSessionClientOpens
WH>   snmpSshtmSessionClientCloses
WH>   snmpSshtmSessionServerOpens
WH>   snmpSshtmSessionServerCloses

I vote for this option. I'd like to be able to know how much use (D)TLS
is getting on the server side...

WH> On the server, you can't necessarily count failed session invocations to
WH> you.

But you could count the number of times that the certificate presented
by the client wasn't accepted, right? So I'd think there should be a
snmpTlstmSessionServerOpenErrors as well. Which raises the question of
why there aren't tlstmClient(CertificateUnknown|InvalidCertificate)
notifications as well.  [Did I ask before why it's not
UnknownCertificate instead of CertificateUnknown? Everythwere else in
the mib is XxxCertificate.]

WH> And I'm not sure how you'd a failed closed session, since you'd
WH> always delete it from your session list which is functionally always
WH> closed on the server side.

You could get an error from the TLS close_notify... Though I'm not even
sure why the server would ever initiate closing a session.

-- 
Robert Story
Senior Software Engineer
SPARTA (dba Cobham Analytic Soloutions)

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 25 Jan 2010 11:42:51 -0800

>>>>> On Mon, 25 Jan 2010 14:04:53 -0500, Robert Story <[email-masked]> said:

RS> I assume you mean snmpTlstmSession*, here and below.

Yep.  My bad; I copied from the other document since I was comparing
them and forgot which I was staring it.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Jan 2010 22:37:40 +0100

>    based on the past history, are #1 and #2 above.

It is not clear to me what "D(TLS) session successfully established"
means - how deep I have to peek into D(TLS) to implement these
counters. The EoP do not describe when snmpTlstmSessionOpens is
incremented (perhaps an omission, there is text for
snmpTlstmSessionCloses).
 
>     ::= { snmpTlstmSession N }

It is not clear to me whether this includes successful (D)TLS
exchanges and if so which ones. How deep do I have to peek into (D)TLS
to implement this counter?

/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: Mon, 25 Jan 2010 16:48:28 -0500

in SSHTM, the open sessions counter is incremented before any open
processing actually occurs; it counts the number of times the
openSession ASI is called. 

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Monday, January 25, 2010 4:38 PM
> To: Wes Hardaker
> Cc: [email-masked]
> Subject: Re: [Isms] TLSTM counters issue
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 25 Jan 2010 13:53:00 -0800

>>>>> On Mon, 25 Jan 2010 16:48:28 -0500, "David Harrington" <[email-masked]> said:

DH> in SSHTM, the open sessions counter is incremented before any open
DH> processing actually occurs; it counts the number of times the
DH> openSession ASI is called. 

Thanks; that makes sense.

And in light of that and in Juergen's analysis I have to agree with the
way it was done in SSHTM.  I'm not sure how possible it is (in all
implementations) to determine when a successful (D)TLS negotiation has
succeeded and thus the server side counters may be impossible to detect
without specific state tracking looking for the first SNMP packet to
traverse a connection and counting the "firsts".  And I don't think
that's worth it.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 25 Jan 2010 17:38:25 -0500

> traverse a connection and counting the "firsts".  And I don't think

Thinking about this a bit, I agree.  The counters we have in the transport 
mapping are about the ASI's in the transport mapping.  Defining MIB's for 
SSH and for (D)TLS, whereever they are used, is a separate project.

-- Jeff

---

From: Robert Story <[email-masked]>
Date: Tue, 26 Jan 2010 08:23:10 -0500

On Mon, 25 Jan 2010 22:37:40 +0100 Juergen wrote:
JS> > The new counters, if desired, would be:
JS> > 
JS> > snmpTlstmSessionServerOpens  OBJECT-TYPE
JS> >     SYNTAX       Counter32
JS> >     MAX-ACCESS   read-only
JS> >     STATUS       current
JS> >     DESCRIPTION "The number of times a (D)TLS session has been
JS> >                  successfully established on a (D)TLS server.
JS> >                 "
JS> >     ::= { snmpTlstmSession N }
JS> 
JS> It is not clear to me whether this includes successful (D)TLS
JS> exchanges and if so which ones. How deep do I have to peek into (D)TLS
JS> to implement this counter?

I don't think we need to peek very far at all. We already have a
requirement (in section 5.1.2) for a tmSessionID  "which MUST be a
unique session identifier for this (D)TLS connection." Seems like
whenever we create this new session identifier would be a good time to
increment the counter.

---

From: Robert Story <[email-masked]>
Date: Tue, 26 Jan 2010 08:37:35 -0500

On Mon, 25 Jan 2010 13:53:00 -0800 Wes wrote:
WH>                            I'm not sure how possible it is (in all
WH> implementations) to determine when a successful (D)TLS negotiation has
WH> succeeded

But it isn't a (D)TLS negotiation counter, it's a snmpTlstmSession
counter, A unique tmSessionID must be created for each session, so I
think that's a nice clean place to increment the counter.

If we want to complain about having to peek inside (D)TLS processing,
I'd be more worried about tlstmTLSProtectionErrors, which is
_explicitly_ defined as counting (D)TLS processing errors. All the
other counters are about tlstmSessions.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2010 14:43:24 +0100

> whenever we create this new session identifier would be a good time to

The description is at least ambiguous. So when do you think this
counter is incremented? Straight after the TCP layer accept()?
At least then the name would be confusing...

/js

---

From: Robert Story <[email-masked]>
Date: Tue, 26 Jan 2010 09:45:44 -0500

On Tue, 26 Jan 2010 14:43:24 +0100 Juergen wrote:
JS> > I don't think we need to peek very far at all. We already have a
JS> > requirement (in section 5.1.2) for a tmSessionID  "which MUST be a
JS> > unique session identifier for this (D)TLS connection." Seems like
JS> > whenever we create this new session identifier would be a good time to
JS> > increment the counter.
JS> 
JS> The description is at least ambiguous. So when do you think this
JS> counter is incremented? Straight after the TCP layer accept()?

I don't think so. This is a TlstmSession counter, not a TLS counter. 

We don't have an implementation for TLS yet, but looking at Wes' "proof
of concept" code for UDP, I find a comment:

            /* if we don't have a cachep for this connection then
               we're receiving something new and are the server
               side */

which looks like a good place to set a flags (say, newConnection). A
little further down in the code, after the SSL read is ok (which I
think means the certificate was validated), the counter could be
incremented if newConnection was set. And if the SSL read failed, I'd
increment the (non-existent-but-I-think-we-should-add)
snmpTlstmSessionServerOpenErrors counter.

As I said in my earlier messages, section 5.1.2 says we have to create a
tmStateReference and have a unique session id. Wherever that code is
would be a logical place to increment a session open counter.

I seem to be fighting a losing battle, though, so unless someone else
sees the light and speaks up, I'll defer to the group wisdom.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2010 16:01:51 +0100

> sees the light and speaks up, I'll defer to the group wisdom.

Robert,

the counter needs to have clear semantics spelled out in the
DESCRIPTION clause and without references to source code of one
particular implementation. This means we need to agree at which stage
of the processing this counter is incremented - otherwise
implementations will end up counting different things. It will matter
to people if some implementations simply count TCP accepts while
others count successful TLS certificate exchanges and validations
while others count something in between.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 26 Jan 2010 07:10:03 -0800

>>>>> On Tue, 26 Jan 2010 08:37:35 -0500, Robert Story <[email-masked]> said:

RS> If we want to complain about having to peek inside (D)TLS processing,
RS> I'd be more worried about tlstmTLSProtectionErrors, which is
RS> _explicitly_ defined as counting (D)TLS processing errors. All the
RS> other counters are about tlstmSessions.

That's a good point.  Maybe we should remove that one since I agree it's
somewhat over the line of where we should be looking.

In the end, I think these sorts of counters are very useful.  But they
probably belong in a separate MIB devoted exclusively to TLS and
would contain many more counters for tracking individual issues.
(e.g. "number of configured CA certificates" and "unable to successfully
negotiate algorithms" and ...)
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Robert Story <[email-masked]>
Date: Tue, 26 Jan 2010 11:11:48 -0500

On Tue, 26 Jan 2010 16:01:51 +0100 Juergen wrote:
JS> the counter needs to have clear semantics spelled out in the
JS> DESCRIPTION clause and without references to source code of one
JS> particular implementation. This means we need to agree at which stage
JS> of the processing this counter is incremented [...]

Section 5.1.2 says

   [...] These steps describe the processing of a
   singular SNMP message after it has been delivered from the (D)TLS
   stream.

   Create a tmStateReference cache for the subsequent reference and
   assign the following values within it:

That seems like a nice clear place. When you create the tmStateReference
cache for the first SNMP message received over a new session, increment
the counter.

Alternatively, Section 5.3 would also work, by appending "Increment the
snmpTlstmSessionServerOpens counter" to step 3.a, or "Increment the
appropriate counter (snmpTlstmSessionClientOpens or
snmpTlstmSessionServerOpens)" to step 4.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jan 2010 12:50:31 +0100

> snmpTlstmSessionServerOpens)" to step 4.

OK. Adding explicit text to the EoP would make it clear what is being
counted.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 27 Jan 2010 07:22:53 -0800

>>>>> On Wed, 27 Jan 2010 12:50:31 +0100, Juergen Schoenwaelder <[email-masked]> said:

>> snmpTlstmSessionServerOpens)" to step 4.

JS> OK. Adding explicit text to the EoP would make it clear what is being
JS> counted.

The opinions still seem to be split on this issue.  Other opinions or
confirmations that this shouldn't be done would be good to help me
determine on which side of the issue the WG currently relies.  It
appears at this time:

For adding server counters:
   Robert S
   Juergen S?

Against:
   David H
   Jeffrey H

Ambivalent:
   Me.  Sort of.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 27 Jan 2010 11:22:08 -0500

Hi,

The only comment I have made on this issue is to point out where in
the EOP the counter gets incremented in SSTM. It does this before
actually entering the SSH open session processing. It just counts the
number of times the OpenSession ASI is called.

I have no issue with having server open/close counters as long as the
counters are tracking ASI usage, and have no specific knowledge of the
(D)TLS internal processing. I can see that it could be useful
information.

What I heard Jeff saying is that he agrees with that position - count
the ASI calls, but not the (D)TLS internal processing.

So you can put me in the For group - if we can increment it based on
TLSTM EOP location and not tls implementation details.
Then we can talk about the specifics of where to increment the
counters.

I would prefer that the SSHTM counters and TLSTM counters be parallel
in meaning, so operators don't need to interpret sshtm opensession
counters differently than they interpret tlstm opensession counters.
So incrementing the client open counter should be the first thing done
in the (client) opensession EOP. it is important to make sure the
counters count the same things, so the counter in DTLSTM should be
placed to count the same things - making sure any "abort" situations
for sshtm that are handled after incrementing the counter happen in
the same relative sequence in tlstm, as much as makes protocol sense.

If I were doing this in sshtm, I think I would have tried to place
this at the point where a new server-side sessionID was assigned (5.1
4), or at a new 5.1 5 - at the point where the receiveMessage ASI is
being called, and the message is passing from the TM to the
dispatcher.

dbh

> Behalf Of Wes Hardaker
> Sent: Wednesday, January 27, 2010 10:23 AM
> To: Robert Story
> Cc: [email-masked]
> >>>>> On Wed, 27 Jan 2010 12:50:31 +0100, Juergen 
> Schoenwaelder <[email-masked]> said:
>

---

From: "tom.petch" <[email-masked]>
Date: Wed, 27 Jan 2010 17:07:49 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
Sent: Wednesday, January 27, 2010 4:22 PM

> >>>>> On Wed, 27 Jan 2010 12:50:31 +0100, Juergen Schoenwaelder
> For adding server counters:

Against
Tom Petch
(I agree with Jeff's summary)

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 27 Jan 2010 13:44:32 -0500

> the ASI calls, but not the (D)TLS internal processing.

Yes, pretty much,  But see below.

> counters differently than they interpret tlstm opensession counters.

Me too.  That means one thing we should _not_ have is a single counter that 
includes both incoming and outgoing connections, because SSHTM doesn't do 
that.  However, I'm not opposed to counting them both, separately, subject 
to the same concerns David discusses.

-- Jeff

---

From: Ira McDonald <[email-masked]>
Date: Wed, 27 Jan 2010 17:14:54 -0500

Hi,

I agree that having separate client and server
session counters is desirable and that they
should be based on ASI invocations and NOT
on peeking at the internals of TLS or SSH.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
email: [email-masked]
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 27 Jan 2010 14:51:26 -0800

>>>>> On Wed, 27 Jan 2010 17:14:54 -0500, Ira McDonald <[email-masked]> said:

IM> I agree that having separate client and server
IM> session counters is desirable and that they
IM> should be based on ASI invocations and NOT
IM> on peeking at the internals of TLS or SSH.

Ok, I think there is now plenty of consensus to add them.  So here's
what I'm gonna do:

1) publish -06 without them.
2) publish -07 with them to clearly show what was done via diffs

I think there may be a problem deciding when the closed ASI is called as
a server or a client, but I need to go dive in to the text to see if
there is a good place to delineate that.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jan 2010 00:28:39 +0100

> there is a good place to delineate that.

I do not think a separate ID is needed for every change. It should
also be easy to identify the section where changes for the counter(s)
were made in an email message.

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 29 Jan 2010 08:50:17 +0100

Juergen

I agree that there is rough consensus to add counters for servers but that does
not make it a good idea.  As 3.3 says
"(D)TLS sessions may be initiated by (D)TLS clients on behalf of SNMP
   appplications that initiate communications"
no mention of servers because servers do not initiate sessions.  I cannot see a
server issuing an openSession so if snmpTlstmSessionServerOpens
"The number of times an openSession request has been
       executed as an (D)TLS server, ..."
ever changes, I would think that that is an engine on the way to
self-destruction.

Nor can an SNMP engine reliably tell if its stack is the recipient of an open.
If a client opens a session in anticipation of sending Notifications but, it is
a fair day and none are ever sent, then all the server may see is a request to
validate a certificate and may not see that if the certificate has already been
validated.

If data does arrive, then a server can compare the tlstm session id and treat a
new one, or one it has not seen for a while, as a session open, but who knows
what that represents under the abstraction layer in terms of ClientHello,
rehandshake, renegotiation, session resumption and all the other murky waters of
TLS? As has already been said, this work belongs in the TLS MIB module.

Tom Petch

----- Original Message -----
From: "Ira McDonald" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>; "Ira McDonald"
<[email-masked]>
Cc: "Robert Story" <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 27, 2010 11:14 PM
Subject: Re: [Isms] TLSTM counters issue

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jan 2010 12:07:17 +0100

On Fri, Jan 29, 2010 at 08:50:17AM +0100, tom.petch wrote:
 
> I agree that there is rough consensus to add counters for servers
> but that does not make it a good idea.  As 3.3 says
> no mention of servers because servers do not initiate sessions.  I
> cannot see a server issuing an openSession so if
> snmpTlstmSessionServerOpens

But this sounds like a wording issue. I personally agree that
snmpTlstmSessionServerOpens is a somewhat unfortunate choice. A 
server accepts sessions, it does not open them.

snmpTlstmSessionOpens
snmpTlstmSessionClientCloses
snmpTlstmSessionOpenErrors
snmpTlstmSessionAccepts
snmpTlstmSessionServerCloses
snmpTlstmSessionAcceptErrors

It appears to me that the server is also not really executing the
openSession() ASI - if so, the desription text needs to reflect that.

NIT: Step 4) in section 5.2 refers to a step 4b) which I think should
     be 5b).

NIT: There are references to snmpTlstmSessionOpenErrors which has been
     renamed; we need to make sure that renamings are applied
     everywhere.

> Nor can an SNMP engine reliably tell if its stack is the recipient
> of an open.  If a client opens a session in anticipation of sending
> Notifications but, it is a fair day and none are ever sent, then all
> the server may see is a request to validate a certificate and may
> not see that if the certificate has already been validated.

Well, the current text in 3a) in section 5.3 leaves it implementation
specific how the counter is incremented, that is whether this is
delayed until the first payload arrives or not. At least that is my
reading. You have a problem with that?
 
> If data does arrive, then a server can compare the tlstm session id
> and treat a new one, or one it has not seen for a while, as a
> session open, but who knows what that represents under the
> abstraction layer in terms of ClientHello, rehandshake,
> renegotiation, session resumption and all the other murky waters of

The counters by design does not tell anything inside of (D)TLS. If you
want counters giving you more insight, then yes someone needs to write
a (D)TLS MIB module.

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 29 Jan 2010 08:40:53 -0500

> openSession() ASI - if so, the desription text needs to reflect
that.

+1

> reading. You have a problem with that?

I think the serveropens should be tied to the first message received;
I don't think we assign a sessionID until there is an incoming
message.

> want counters giving you more insight, then yes someone needs to
write

+1

dbh

---

From: "tom.petch" <[email-masked]>
Date: Fri, 29 Jan 2010 14:07:14 +0100

----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Friday, January 29, 2010 12:07 PM

> reading. You have a problem with that?

Yes!

The server can count the number of times it is asked to validate a certificate,
it can count the number of seemingly new session IDs there are, but both
are only a loose approximation to the openSessions that the client issues.

By all means count certificate validations and new session IDs, just don't
pretend that they are 'openSessions', just something from which the number
of session accepts can be guesstimated with some degree of error.  This
is more than wording, it is a question of what we are counting and who 
should draw what inferences from them; the MIB module should not be
drawing the inferences.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Jan 2010 11:28:44 -0800

>>>>> On Fri, 29 Jan 2010 12:07:17 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> NIT: Step 4) in section 5.2 refers to a step 4b) which I think should
JS> be 5b).

JS> NIT: There are references to snmpTlstmSessionOpenErrors which has been
JS> renamed; we need to make sure that renamings are applied
JS> everywhere.

FYI, I just fixed those; thanks for catching them.  I've also verified
that any reference to any of the older names don't exist besides the two
references to snmpTlstmSessionOpenErrors, both of which were changed to
snmpTlstmSessionClientOpenErrors.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Jan 2010 11:31:32 -0800

>>>>> On Fri, 29 Jan 2010 08:40:53 -0500, "David Harrington" <[email-masked]> said:

>> reading. You have a problem with that?

DH> I think the serveropens should be tied to the first message received;
DH> I don't think we assign a sessionID until there is an incoming
DH> message.

I think you need to be careful there in the wording, because the
different sides treat things differently:

1) client: openSession() is used and the sessionID is established there
   (step 4).

2) server: currently implementation dependent as to when the sessionID
   is established.  I think the consensus is currently leaning toward
   fixing this so that in the "processing incoming" section we detect a
   missing sessionID and discuss assigning it *then* and incrementing
   the counter *then*.

   I'll work on text for that, but I suspect that this is what everyone
   would prefer?

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Jan 2010 11:33:18 -0800

>>>>> On Thu, 28 Jan 2010 00:28:39 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> I do not think a separate ID is needed for every change.

Needed, no.  But it's certainly helpful to read the specific changes
associated with that delta since it was so recently discussed and
everyone was concerned about it.

The whole purpose of the "rapid update" and "diff viewer" of the tools
page is specifically for helping discussions like this one where when
we're at the wire we need to be very accurate in what we're talking
about.

There is no negative that I know of, on the other hand.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Jan 2010 11:35:55 -0800

>>>>> On Fri, 29 Jan 2010 12:07:17 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> But this sounds like a wording issue. I personally agree that
JS> snmpTlstmSessionServerOpens is a somewhat unfortunate choice.

I actually don't like it either, and I'd be happy to change it.  The
name was chosen because it was suggested as a name to use.

JS> A server accepts sessions, it does not open them.

Well, I'd actually disagree with the wording semantics.  Both sides
actually need to "open" the connection to some extent and neither side
can fulfill the "opening" of the session entirely by themselves.

snmpTlstmSessionServerAccepts doesn't seem right either.
snmpTlstmSessionServerEstablishments is probably closer, though over 32
characters.

Opinions welcome :-)