Received: from cnri by ietf.org id aa09724; 1 Aug 97 19:06 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA05104 for ; Fri, 1 Aug 1997 19:05:28 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id TAA13326; Fri, 1 Aug 1997 19:00:41 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2926779 for TN3270E@LIST.NIH.GOV; Fri, 1 Aug 1997 19:00:37 -0400 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by list.nih.gov (8.8.5/8.8.5) with SMTP id SAA12558 for ; Fri, 1 Aug 1997 18:50:24 -0400 (EDT) Received: from d04lms02.raleigh.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA68688; Fri, 1 Aug 1997 22:54:34 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU008 id 5040200003814347; Fri, 1 Aug 1997 18:57:17 -0400 From: Kenneth White To: tn3270e@list.nih.gov MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: scoya@ietf.org, swallow@cisco.com, malis@alpo.casc.com, narten@raleigh.ibm.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Message-Id: <5040200003814347000002L072*@MHS> Date: Fri, 1 Aug 1997 18:57:17 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tn3270e@list.nih.gov I'm sorry if you already received the attached note but I decided to resend it a different way when my mail server informed me that it couldn't deliver it. Ken ----------------------- Date: The, 31 Jul 97 15:59:58 EDT From: KWHITE@RALVM12.RALEIGH.IBM.COM To: burgan@home.net cc: narten@raleigh.ibm.com, malis@alpo.casc.com, swallow@cisco.com, scoya@ietf.org Subject: Jeff, I was just asked by an implementer of the IPOA-MIB when they can expect the internet-draft to complete the review process. They are getting ready to ship and would prefer that a mib-2 based OID be used by the MIB as oppose to one under the experimental OID subtree. Can you let me know where the MIB stands in the review cycle and give a rough guess as to when it will be reviewed? Thanks, Ken   Received: from cnri by ietf.org id aa05490; 2 Aug 97 9:49 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA05894 for ; Sat, 2 Aug 1997 09:48:11 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id JAA04880; Sat, 2 Aug 1997 09:43:24 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2919141 for TN3270E@LIST.NIH.GOV; Sat, 2 Aug 1997 09:43:21 -0400 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by list.nih.gov (8.8.5/8.8.5) with SMTP id JAA04673 for ; Sat, 2 Aug 1997 09:33:19 -0400 (EDT) Received: from d04lms02.raleigh.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA42994; Sat, 2 Aug 1997 13:37:30 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU008 id 5040200003824519; Sat, 2 Aug 1997 09:40:10 -0400 From: Kenneth White To: tn3270e@list.nih.gov MMDF-Warning: Parse error in original version of preceding line at ietf.org Message-Id: <5040200003824519000002L092*@MHS> Date: Sat, 2 Aug 1997 09:40:10 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tn3270e@list.nih.gov Please ignore the last note I sent to this list. I messed up the destination address. Ken   Received: from cnri by ietf.org id aa07494; 3 Aug 97 11:56 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA07314 for ; Sun, 3 Aug 1997 11:55:18 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id LAA08983; Sun, 3 Aug 1997 11:49:13 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2919723 for TN3270E@LIST.NIH.GOV; Sun, 3 Aug 1997 11:49:10 -0400 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by list.nih.gov (8.8.5/8.8.5) with SMTP id LAA08881 for ; Sun, 3 Aug 1997 11:39:09 -0400 (EDT) Received: from d04lms02.raleigh.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AB19852; Sun, 3 Aug 1997 15:43:23 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU008 id 5040200003836155; Sun, 3 Aug 1997 11:46:54 -0400 From: Kenneth White To: tn3270e@list.nih.gov MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: dbolton@cisco.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: Message-Id: <5040200003836155000002L052*@MHS> Date: Sun, 3 Aug 1997 11:46:54 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tn3270e@list.nih.gov Derek, >This is a good start. Some high-level questions: >1. Is this only for LUT2? If it's for printers as well there's >a snag. Instead of the presumed sequence: > client Host > data ------------> > <----------- data > response -----------> > (longish delay) >printers can go > client Host > <----------- data > response -----------> > (longish delay) >or even > <----------- data > response -----------> > data ------------> > (longish delay) >which will lead to arbitrary "response times". Printer sessions were not considered. How about doing the following: client TN3270E Host Server D <------------------- data E turn DR on response ------------------> F DR +/- <--------- F - D would still be an approximation for total response time. F - E would then be SNA network time plus host time. I would have to update the text for the IP Network times in the tn3270eRtDataTable to indicate that an ElementType object in either the tn3270eResMapTable or the tn3270eTcpConnTable for a particular session would need to be examined to determine what the IP counter objects really represented. When a collection was for an aggregate then the IP Client could be a mix of LU and printer sessions. To solve this it might be better to create the following objects: tn3270eRtDataAverageSnaRt tn3270eRtDataCurrTotalIpRt tn3270eRtDataCurrElapsIpRtSq andkeep the counts seperate. Opinions? >2. Precision and wrap of totals > >You have the durations measured in milliseconds and allow 32 bits for >all totals. I don't see any provision for resetting the totals, so I >guess they're allowed to wrap. That imposes a minimum collection >rate. Right. In a tn3270eRtDataEntry: tn3270eRtDataCurrTotalRt tn3270eRtDataCurrTotalIpRt tn3270eRtDataCurrTransCount tn3270eRtDataCurrDrCount tn3270eRtDataCurrElapsRnTrpSq tn3270eRtDataCurrElapsIpRtSq tn3270eRtDataBucket1 tn3270eRtDataBucket2 tn3270eRtDataBucket3 tn3270eRtDataBucket4 tn3270eRtDataBucket5 can wrap. > >Suppose the round trip time is about 2000 msecs, which it could well >be in an overloaded network (precisely the time when you need this >RTM logic to give the right answers). That's 2**11. > >At 1000 tps, the total time will overflow after (2**21)/1000 seconds, >or about half an hour. To be on the safe side, the data would need to >be collected every 15 minutes. That might just about be acceptable, >but now look at the sum of squares. Each squared time is about 2**22, >so the total will overflow in 1 second! > >(It might seem unlikely that you could be processing 1000 tps yet have >a turn round of 2 seconds. That says that at any moment there are >2000 transactions in progress. Where are they all? If the server's >TCP is highly scalable and has plenty of buffering, there could be one >transaction pending for each of 2000 clients.) > >A possible solution is to use a different unit for the some of >squares, like 0.01 square seconds (i.e. 10000 square msecs). >Internally, the server would keep the information in square >milliseconds (or even smaller) - otherwise the total might never go >nonzero - but present the totals in the larger unit. > >Even for the unsquared totals, milliseconds seems unnecessarily small >a unit. Is anyone going to care about totals finer than a tenth of >a second? Good point. How about for: tn3270eRtDataCurrTotalRt tn3270eRtDataCurrTotalIpRt tn3270eRtDataCurrElapsRnTrpSq tn3270eRtDataCurrElapsIpRtSq changing the unit of measure to seconds. >3. Averaging >My own preference is always for sliding averages. They are far easier >to collect and in many situations more meaningful. Also, since you >have alerts generated from thresholds, a sliding average would cause >less alert thrashing. For sliding averages I assume that you mean keeping a window of n averages calculated at each collection interval. The average reported would be the average of the n averages. Is this what you mean? I would prefer leaving the averages as they are since totals are kept that can be sampled to show overall rates. A low threshold was defined in order to address the trap generation problem. >There are two subtle traps. >- Programmers generally make the aging too slow. E.g. if you want a >"ten minute" sliding average, don't reduce by a tenth each minute, >reduce by a fifth each minute. (I can justify that mathemetically if >needs be.) >- You need to watch for rounding error. The slower the aging, the >more bits are needed in the variable maintained. >4. TranCount >If performance is very poor, you might not get enough transactions >through to satisfy TranCount, so you dismiss the event as >statistically insignificant! >The orthodoxy is that the significance level is >related to numTransactions * (average-threshold)**2. >So I propose that TranCount is redefined as follows: > if > numTransactions * (average/threshold - 1)**2 < TranCount > then no alert is generated. >E.g. if the threshold is 200 msecs per transaction, the average >observed is 300 and TranCount is set to 20 then an alert >will be generated if numTransactions >= 80. On the other hand, >if the observed is 500 then the alert is generated if >numTransactions >= 9. >If my push for sliding averages is accepted then there's another >issue with TranCount - it has to be replaced by a transaction >rate (which is also maintained as a sliding average with the same >aging). But the formula is the same: > slidingRate * (average/threshold - 1)**2 < TranRate >(I'd like to find a more descriptive name than TranRate. IdleRate? >DetectRate?) I like your approach to using an algorithm for TranRate and will adopt your proposal. I will change the name to IdleRate. >> SNA resources can be configured to automatically request definite >> response or a TN3270E Server can dynamically request it itself. >> The tn3270eRtCollCtlType object in a tn3270eRtCollCtlEntry has a >> BIT setting, ddr(1), defined to inform the TN3270E Server as to >> whether dynamic definite response is enabled (refer to section >> 4.1, tn3270eRtCollCtlTable) for a particular response time >> collection policy. Dynamically requesting definite response from >> a TN3270E Server does increase IP Network traffic which may not be >> desirable in certain customer environments. In addition, if a >> customer determines that their IP Network times are not >> significant then dynamic definite response (DDR) can be disabled. >Another consideration is a mismatch between DR requesting on the SNA >side and DR requesting on the TN3270E side. If the Host sends a >multiple PU chain, the server does not know until EC whether DR is >being requested. Meanwhile, the server may have forwarded the start >of the record to the client. In practice, therefore, some servers are >converting EXR flows to DR flows already. I will need to add some text to cover this. In calculation timestamps E and F I don't think it matters which DR flow is used. If the TN3270E Server is doing one any way then is should use that one as oppose to a new one. I will incorporate the rest of your comments in the next revision which is expected to occur after Munich. Thanks for your comments. Ken   Received: from cnri by ietf.org id aa15067; 3 Aug 97 21:02 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA07725 for ; Sun, 3 Aug 1997 21:00:56 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id UAA20101; Sun, 3 Aug 1997 20:56:21 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2922994 for TN3270E@LIST.NIH.GOV; Sun, 3 Aug 1997 20:56:18 -0400 Received: from ringer.cisco.com (ringer.cisco.com [171.69.176.7]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id UAA20088 for ; Sun, 3 Aug 1997 20:56:15 -0400 (EDT) Received: (dbolton@localhost) by ringer.cisco.com (8.8.4-Cisco.1/8.6.5) id KAA02395 for tn3270e@LIST.NIH.GOV; Mon, 4 Aug 1997 10:56:59 +1000 (EST) From: "Derek W. Bolton" Message-Id: <199708040056.KAA02395@ringer.cisco.com> Subject: Re: To: tn3270e@list.nih.gov Date: Mon, 4 Aug 1997 10:56:59 +1000 (EST) In-Reply-To: <5040200003836155000002L052*@MHS> from "Kenneth White" at Aug 3, 97 11:46:54 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tn3270e@list.nih.gov Kenneth, > >1. Is this only for LUT2? If it's for printers as well there's > >a snag. Instead of the presumed sequence: > > client Host > > data ------------> > > <----------- data > > response -----------> > > (longish delay) > >printers can go > > client Host > > <----------- data > > response -----------> > > (longish delay) > >or even > > <----------- data > > response -----------> > > data ------------> > > (longish delay) > >which will lead to arbitrary "response times". > Printer sessions were not considered. How about doing the > following: > client TN3270E Host > Server > D > <------------------- data > E turn DR on > response ------------------> > F DR +/- > <--------- > F - D would still be an approximation for total response time. > F - E would then be SNA network time plus host time. No, that doesn't work unless the "response" from the printer is actually a reply (i.e. an SNA request). Can't make the Host respond to a response. Besides, E-D is likely to include printing time, not just network time. We could simply exclude LUT1 and LUT3 sessions from the stats. (3274 doesn't do RTM for printers.) The only other suggestion I have is: - separate stats (as you also suggest) - just measure Host time up to EOJ: client TN3270E Host Server D <------------------- data, not EB E response ------------------> F <------------------- data (perhaps EB) The time F-E should represent Host response time. I.e. if the Host did not send EB last time then the next rsp sent in should provoke more data immediately. One thing to watch here is pacing. E represents the time at which we gave the Host the go-ahead, whether by +rsp, -rsp or IPR. (Does the same issue arise with screens? I think it might.) > I would have to update the text for the IP Network times in the > tn3270eRtDataTable to indicate that an ElementType object in > either the tn3270eResMapTable or the tn3270eTcpConnTable for > a particular session would need to be examined to determine > what the IP counter objects really represented. When a collection > was for an aggregate then the IP Client could be a mix of LU > and printer sessions. To solve this it might be better to create > the following objects: > tn3270eRtDataAverageSnaRt > tn3270eRtDataCurrTotalIpRt > tn3270eRtDataCurrElapsIpRtSq > and keep the counts separate. Opinions? > >2. Precision and wrap of totals > > > >You have the durations measured in milliseconds and allow 32 bits for > >all totals. I don't see any provision for resetting the totals, so I > >guess they're allowed to wrap. That imposes a minimum collection > >rate. > Right. In a tn3270eRtDataEntry: > tn3270eRtDataCurrTotalRt > tn3270eRtDataCurrTotalIpRt > tn3270eRtDataCurrTransCount > tn3270eRtDataCurrDrCount > tn3270eRtDataCurrElapsRnTrpSq > tn3270eRtDataCurrElapsIpRtSq > tn3270eRtDataBucket1 > tn3270eRtDataBucket2 > tn3270eRtDataBucket3 > tn3270eRtDataBucket4 > tn3270eRtDataBucket5 > can wrap. > > > >Suppose the round trip time is about 2000 msecs, which it could well > >be in an overloaded network (precisely the time when you need this > >RTM logic to give the right answers). That's 2**11. > > > >At 1000 tps, the total time will overflow after (2**21)/1000 seconds, > >or about half an hour. To be on the safe side, the data would need to > >be collected every 15 minutes. That might just about be acceptable, > >but now look at the sum of squares. Each squared time is about 2**22, > >so the total will overflow in 1 second! > > > >(It might seem unlikely that you could be processing 1000 tps yet have > >a turn round of 2 seconds. That says that at any moment there are > >2000 transactions in progress. Where are they all? If the server's > >TCP is highly scalable and has plenty of buffering, there could be one > >transaction pending for each of 2000 clients.) > > > >A possible solution is to use a different unit for the sum of > >squares, like 0.01 square seconds (i.e. 10000 square msecs). > >Internally, the server would keep the information in square > >milliseconds (or even smaller) - otherwise the total might never go > >nonzero - but present the totals in the larger unit. > > > >Even for the unsquared totals, milliseconds seems unnecessarily small > >a unit. Is anyone going to care about totals finer than a tenth of > >a second? > Good point. How about for: > tn3270eRtDataCurrTotalRt > tn3270eRtDataCurrTotalIpRt > tn3270eRtDataCurrElapsRnTrpSq > tn3270eRtDataCurrElapsIpRtSq > changing the unit of measure to seconds. That might be going too far. There's some merit in keeping a consistent set of units if that's feasible. I would think tenths of seconds are fine enough for individual client measurements, yet coarse enough that the totals would not wrap too often. If we go for different units for variables of different scope then the use of 'subnet' totals gets awkward. There's no way of predicting at MIB design time whether the fine or coarse units are appropriate. (I know I suggested different units for the sum of squares, but that seems more defensible as a general principle.) Using the same example as above, and with tenths of seconds as the standard, even the sum of squares would take 2 hours to wrap. > >3. Averaging > >My own preference is always for sliding averages. They are far easier > >to collect and in many situations more meaningful. Also, since you > >have alerts generated from thresholds, a sliding average would cause > >less alert thrashing. > For sliding averages I assume that you mean keeping a window of n > averages calculated at each collection interval. The average > reported would be the average of the n averages. Is this what you > mean? I would prefer leaving the averages as they are since totals > are kept that can be sampled to show overall rates. A low threshold > was defined in order to address the trap generation problem. Not quite. For one thing, one must avoid the old average-of-averages trap. For another, you want something that smoothes the data to make it more intelligible. I ought to explain the problem I'm trying to solve. On the one hand, you want the average taken over a reasonable period, maybe 30 minutes, so that the NM application doesn't have to issue Get too often in order to see all the data. Even then, if it issues the Get every 10 minutes then it will see the same data two three or four times. Does it know how often it saw the same data? Not if there's no timestamp on it. So there's a 2:1 variation in how it might assess the general state of affairs. Also, as the averaging period becomes longer, bursts that should have been sufficient for an alert are missed. These bursts could themselves be as long as the averaging period if they happen to straddle two periods. So the ideal is to have the data updated fairly often but to contain enough smoothing that the NM appl doesn't have to poll hard. Here's what I propose: - Pick a fixed shortish sample period, t (like 20) seconds. - Configured "averaging" period is some multiple of this, 2k minutes (see note) - Compute the ratio h = 2k * 60 / t - Keep four variables: countThisPeriod of transactions totalThisPeriod of elapsed times countSliding; this is the count for the previous period, plus a diminishing contribution from all preceding periods. totalSliding; likewise - During a sample period, the ThisPeriod variables are updated for events completing that period - At the end of each period, the sliding counts are updated thus: countSliding = countSliding + countThisPeriod - countSliding/h totalSliding = totalSliding + totalThisPeriod - totalSliding/h The ThisPeriod variables are then reset and totalSliding/countSliding is compared with the alert threshold. - When a Get is issued for the average time, it reports totalSliding/countSliding Note: The averaging period is quoted as 2k because this gives the right expectations. The average age of the data in the sliding variables is k minutes. > >4. TranCount > >If performance is very poor, you might not get enough transactions > >through to satisfy TranCount, so you dismiss the event as > >statistically insignificant! > >The orthodoxy is that the significance level is > >related to numTransactions * (average-threshold)**2. > >So I propose that TranCount is redefined as follows: > > if > > numTransactions * (average/threshold - 1)**2 < TranCount > > then no alert is generated. > >E.g. if the threshold is 200 msecs per transaction, the average > >observed is 300 and TranCount is set to 20 then an alert > >will be generated if numTransactions >= 80. On the other hand, > >if the observed is 500 then the alert is generated if > >numTransactions >= 9. > >If my push for sliding averages is accepted then there's another > >issue with TranCount - it has to be replaced by a transaction > >rate (which is also maintained as a sliding average with the same > >aging). But the formula is the same: > > slidingRate * (average/threshold - 1)**2 < TranRate > >(I'd like to find a more descriptive name than TranRate. IdleRate? > >DetectRate?) > I like your approach to using an algorithm for TranRate and will > adopt your proposal. I will change the name to IdleRate. > >> SNA resources can be configured to automatically request definite > >> response or a TN3270E Server can dynamically request it itself. > >> The tn3270eRtCollCtlType object in a tn3270eRtCollCtlEntry has a > >> BIT setting, ddr(1), defined to inform the TN3270E Server as to > >> whether dynamic definite response is enabled (refer to section > >> 4.1, tn3270eRtCollCtlTable) for a particular response time > >> collection policy. Dynamically requesting definite response from > >> a TN3270E Server does increase IP Network traffic which may not be > >> desirable in certain customer environments. In addition, if a > >> customer determines that their IP Network times are not > >> significant then dynamic definite response (DDR) can be disabled. > >Another consideration is a mismatch between DR requesting on the SNA > >side and DR requesting on the TN3270E side. If the Host sends a > >multiple PU chain, the server does not know until EC whether DR is > >being requested. Meanwhile, the server may have forwarded the start > >of the record to the client. In practice, therefore, some servers are > >converting EXR flows to DR flows already. > I will need to add some text to cover this. In calculation > timestamps E and F I don't think it matters which DR flow is > used. If the TN3270E Server is doing one any way then is should use > that one as oppose to a new one. > I will incorporate the rest of your comments in the next revision > which is expected to occur after Munich. Thanks for your comments. > Ken   Received: from cnri by ietf.org id aa24710; 4 Aug 97 1:23 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid BAA07982 for ; Mon, 4 Aug 1997 01:21:53 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id BAA27344; Mon, 4 Aug 1997 01:17:07 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2916883 for TN3270E@LIST.NIH.GOV; Mon, 4 Aug 1997 01:17:04 -0400 Received: from tai.cisco.com (tai.cisco.com [171.69.160.33]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id BAA27331 for ; Mon, 4 Aug 1997 01:17:02 -0400 (EDT) Received: from mboe-pc.cisco.com (sj-dial-2-4.cisco.com [171.68.179.133]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id BAA22288; Mon, 4 Aug 1997 01:16:25 -0400 (EDT) Message-ID: <33E57221.1B21FA3D@cisco.com> Date: Mon, 04 Aug 1997 01:09:37 -0500 From: Michael Boe Organization: cisco Systems X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: "Derek W. Bolton" CC: tn3270e@list.nih.gov Subject: Re: X-Priority: 3 (Normal) References: <199708040056.KAA02395@ringer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tn3270e@list.nih.gov Derek W. Bolton wrote: > > Kenneth, > > > >1. Is this only for LUT2? If it's for printers as well there's > > >a snag. Instead of the presumed sequence: > > > client Host > > > data ------------> > > > <----------- data > > > response -----------> > > > (longish delay) > > > >printers can go > > > client Host > > > <----------- data > > > response -----------> > > > (longish delay) > > > >or even > > > <----------- data > > > response -----------> > > > data ------------> > > > (longish delay) > > > >which will lead to arbitrary "response times". > > > Printer sessions were not considered. How about doing the > > following: > > > client TN3270E Host > > Server > > D > > <------------------- data > > E turn DR on > > response ------------------> > > F DR +/- > > <--------- > > > F - D would still be an approximation for total response time. > > F - E would then be SNA network time plus host time. > > No, that doesn't work unless the "response" from the printer > is actually a reply (i.e. an SNA request). Can't make the > Host respond to a response. > > Besides, E-D is likely to include printing time, not just network > time. > > We could simply exclude LUT1 and LUT3 sessions from the stats. (3274 > doesn't do RTM for printers.) The only other suggestion I have is: That's a good idea. AFAIK, nobody cares a whit about "response times" for printers. BPS rates, yes. Contrary opinions? /msb > > - separate stats (as you also suggest) > - just measure Host time up to EOJ: > > client TN3270E Host > Server > D > <------------------- data, not EB > E > response ------------------> > F > <------------------- data (perhaps EB) > > The time F-E should represent Host response time. I.e. if the > Host did not send EB last time then the next rsp sent in > should provoke more data immediately. > > One thing to watch here is pacing. E represents the time at > which we gave the Host the go-ahead, whether by +rsp, -rsp or > IPR. (Does the same issue arise with screens? I think it might.) > > > I would have to update the text for the IP Network times in the > > tn3270eRtDataTable to indicate that an ElementType object in > > either the tn3270eResMapTable or the tn3270eTcpConnTable for > > a particular session would need to be examined to determine > > what the IP counter objects really represented. When a collection > > was for an aggregate then the IP Client could be a mix of LU > > and printer sessions. To solve this it might be better to create > > the following objects: > > > tn3270eRtDataAverageSnaRt > > tn3270eRtDataCurrTotalIpRt > > tn3270eRtDataCurrElapsIpRtSq > > > and keep the counts separate. Opinions? > > > >2. Precision and wrap of totals > > > > > >You have the durations measured in milliseconds and allow 32 bits for > > >all totals. I don't see any provision for resetting the totals, so I > > >guess they're allowed to wrap. That imposes a minimum collection > > >rate. > > > Right. In a tn3270eRtDataEntry: > > > tn3270eRtDataCurrTotalRt > > tn3270eRtDataCurrTotalIpRt > > tn3270eRtDataCurrTransCount > > tn3270eRtDataCurrDrCount > > tn3270eRtDataCurrElapsRnTrpSq > > tn3270eRtDataCurrElapsIpRtSq > > tn3270eRtDataBucket1 > > tn3270eRtDataBucket2 > > tn3270eRtDataBucket3 > > tn3270eRtDataBucket4 > > tn3270eRtDataBucket5 > > > can wrap. > > > > > > >Suppose the round trip time is about 2000 msecs, which it could well > > >be in an overloaded network (precisely the time when you need this > > >RTM logic to give the right answers). That's 2**11. > > > > > >At 1000 tps, the total time will overflow after (2**21)/1000 seconds, > > >or about half an hour. To be on the safe side, the data would need to > > >be collected every 15 minutes. That might just about be acceptable, > > >but now look at the sum of squares. Each squared time is about 2**22, > > >so the total will overflow in 1 second! > > > > > >(It might seem unlikely that you could be processing 1000 tps yet have > > >a turn round of 2 seconds. That says that at any moment there are > > >2000 transactions in progress. Where are they all? If the server's > > >TCP is highly scalable and has plenty of buffering, there could be one > > >transaction pending for each of 2000 clients.) > > > > > >A possible solution is to use a different unit for the sum of > > >squares, like 0.01 square seconds (i.e. 10000 square msecs). > > >Internally, the server would keep the information in square > > >milliseconds (or even smaller) - otherwise the total might never go > > >nonzero - but present the totals in the larger unit. > > > > > >Even for the unsquared totals, milliseconds seems unnecessarily small > > >a unit. Is anyone going to care about totals finer than a tenth of > > >a second? > > > Good point. How about for: > > > tn3270eRtDataCurrTotalRt > > tn3270eRtDataCurrTotalIpRt > > tn3270eRtDataCurrElapsRnTrpSq > > tn3270eRtDataCurrElapsIpRtSq > > > changing the unit of measure to seconds. > > That might be going too far. There's some merit in keeping a > consistent set of units if that's feasible. I would think tenths of > seconds are fine enough for individual client measurements, yet coarse > enough that the totals would not wrap too often. > > If we go for different units for variables of different scope then the > use of 'subnet' totals gets awkward. There's no way of predicting at > MIB design time whether the fine or coarse units are appropriate. (I > know I suggested different units for the sum of squares, but that > seems more defensible as a general principle.) > > Using the same example as above, and with tenths of seconds as the > standard, even the sum of squares would take 2 hours to wrap. > > > >3. Averaging > > > >My own preference is always for sliding averages. They are far easier > > >to collect and in many situations more meaningful. Also, since you > > >have alerts generated from thresholds, a sliding average would cause > > >less alert thrashing. > > > For sliding averages I assume that you mean keeping a window of n > > averages calculated at each collection interval. The average > > reported would be the average of the n averages. Is this what you > > mean? I would prefer leaving the averages as they are since totals > > are kept that can be sampled to show overall rates. A low threshold > > was defined in order to address the trap generation problem. > > Not quite. For one thing, one must avoid the old average-of-averages > trap. For another, you want something that smoothes the data to > make it more intelligible. > > I ought to explain the problem I'm trying to solve. On the one > hand, you want the average taken over a reasonable period, maybe > 30 minutes, so that the NM application doesn't have to issue Get > too often in order to see all the data. Even then, if it issues > the Get every 10 minutes then it will see the same data two three > or four times. Does it know how often it saw the same data? Not if > there's no timestamp on it. So there's a 2:1 variation in how it > might assess the general state of affairs. > > Also, as the averaging period becomes longer, bursts that should > have been sufficient for an alert are missed. These bursts > could themselves be as long as the averaging period if they happen > to straddle two periods. > > So the ideal is to have the data updated fairly often but to contain > enough smoothing that the NM appl doesn't have to poll hard. > > Here's what I propose: > > - Pick a fixed shortish sample period, t (like 20) seconds. > - Configured "averaging" period is some multiple of this, 2k minutes > (see note) > - Compute the ratio h = 2k * 60 / t > - Keep four variables: > countThisPeriod of transactions > totalThisPeriod of elapsed times > countSliding; this is the count for the previous period, plus a > diminishing contribution from all preceding periods. > totalSliding; likewise > > - During a sample period, the ThisPeriod variables are updated > for events completing that period > - At the end of each period, the sliding counts are updated thus: > > countSliding = countSliding + countThisPeriod - countSliding/h > totalSliding = totalSliding + totalThisPeriod - totalSliding/h > > The ThisPeriod variables are then reset and > totalSliding/countSliding is compared with the alert threshold. > > - When a Get is issued for the average time, it reports > > totalSliding/countSliding > > Note: The averaging period is quoted as 2k because this gives the > right expectations. The average age of the data in the sliding > variables is k minutes. > > > >4. TranCount > > > >If performance is very poor, you might not get enough transactions > > >through to satisfy TranCount, so you dismiss the event as > > >statistically insignificant! > > > >The orthodoxy is that the significance level is > > >related to numTransactions * (average-threshold)**2. > > >So I propose that TranCount is redefined as follows: > > > > if > > > numTransactions * (average/threshold - 1)**2 < TranCount > > > > then no alert is generated. > > > >E.g. if the threshold is 200 msecs per transaction, the average > > >observed is 300 and TranCount is set to 20 then an alert > > >will be generated if numTransactions >= 80. On the other hand, > > >if the observed is 500 then the alert is generated if > > >numTransactions >= 9. > > > >If my push for sliding averages is accepted then there's another > > >issue with TranCount - it has to be replaced by a transaction > > >rate (which is also maintained as a sliding average with the same > > >aging). But the formula is the same: > > > > slidingRate * (average/threshold - 1)**2 < TranRate > > > >(I'd like to find a more descriptive name than TranRate. IdleRate? > > >DetectRate?) > > > I like your approach to using an algorithm for TranRate and will > > adopt your proposal. I will change the name to IdleRate. > > > >> SNA resources can be configured to automatically request definite > > >> response or a TN3270E Server can dynamically request it itself. > > >> The tn3270eRtCollCtlType object in a tn3270eRtCollCtlEntry has a > > >> BIT setting, ddr(1), defined to inform the TN3270E Server as to > > >> whether dynamic definite response is enabled (refer to section > > >> 4.1, tn3270eRtCollCtlTable) for a particular response time > > >> collection policy. Dynamically requesting definite response from > > >> a TN3270E Server does increase IP Network traffic which may not be > > >> desirable in certain customer environments. In addition, if a > > >> customer determines that their IP Network times are not > > >> significant then dynamic definite response (DDR) can be disabled. > > > >Another consideration is a mismatch between DR requesting on the SNA > > >side and DR requesting on the TN3270E side. If the Host sends a > > >multiple PU chain, the server does not know until EC whether DR is > > >being requested. Meanwhile, the server may have forwarded the start > > >of the record to the client. In practice, therefore, some servers are > > >converting EXR flows to DR flows already. > > > I will need to add some text to cover this. In calculation > > timestamps E and F I don't think it matters which DR flow is > > used. If the TN3270E Server is doing one any way then is should use > > that one as oppose to a new one. > > > I will incorporate the rest of your comments in the next revision > > which is expected to occur after Munich. Thanks for your comments. > > > Ken   Received: from cnri by ietf.org id aa02114; 4 Aug 97 20:18 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA11511 for ; Mon, 4 Aug 1997 20:16:40 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id UAA01117; Mon, 4 Aug 1997 20:11:34 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2926887 for TN3270E@LIST.NIH.GOV; Mon, 4 Aug 1997 20:11:31 -0400 Received: from tai.cisco.com (tai.cisco.com [171.69.160.33]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id UAA01101 for ; Mon, 4 Aug 1997 20:11:29 -0400 (EDT) Received: from mboe-pc.cisco.com (is-as5200-20.cisco.com [171.68.11.162]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id UAA09058 for ; Mon, 4 Aug 1997 20:10:56 -0400 (EDT) Date: Mon, 4 Aug 1997 20:04:03 -0500 (Central Daylight Time) From: Michael Boe Reply-To: Michael Boe Subject: TN3270E Security enhancements...a toe in the water To: tn3270e@list.nih.gov Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov It's been a busy couple of months, and things have finally gotten back to near normal. My current residential abode has changed from Houston TX to San Francisco CA, but I've finally gotten caught up on my work. So, it's time to start on a very belated portion of the new TN3270E work. At the informal meeting at Cisco in May, the attendees agreed that the way forward seemed to be SSL/TLS. As I recall, the agreement amongst the participants was based on the following purported facts: a) SSL is the most widely deployed on the client-side platforms (this implies certain assumptions about the operating-system and working-environment of the clients....but commercial vendors all seemed to like the assumptions, so there was not a lot of disagreement here). The modus operandi here seems to be to "pick a winner." Nobody wants to deploy a technology that is not widely accepted or understood. b) the client-side implementors want an API or some easy set of code-interfaces to write to; c) the client-side implementors do not want to have export-restricted code problems (winsock 3 will have SSL libraries shipped with the OS or TCPIP stack); d) SSL has "rough consensus" in the marketplace; it certainly has running code. So, a question for the group is: do we have consensus on the above points? In particular, can we reach rough consensus that the SSL/TLS technology is the right path to choose? Goals of the Security Enhancements to TN3270E: ---------------------------------------------- Working backwards from the discussion (and previous discussions with individuals) on whether SSL is the way forward, I've cobbled together some goals of what TN3270E security should accomplish: * permit the server to authenticate the identity of the client for purposes of authorization or accounting. * permit the client to authenticate the identity of the server for purposes of authorization or accounting. * permit the client and server to negotiate whether or not the TN3270E session should be encrypted; if the session is encrypted, the two parties should also be able to negotiate whether or not the session is to be compressed. [SSL doesn't do very well on the compression side right now...the RSA cipher suite has null-compression (ie no compression). And the RSA cipher suite is the one which is the most widely available to the clients. One question that came up was "well, how much does encrypted-data on the wire compare in size to encrypted-and-compressed-data?" I seem to recall there's a 15% increase in CPU in using a LZ or LZW-type compression technique before DES compression...but I'd like to have that confirmed or denied. I'd also like to hear from folks whether any reported bandwidth reduction is worth it. For instance, how much bandwidth is saved on TN3270E streams by doing compression? Do adaptive LZW techniques work acceptably with TN3270E streams?] * on server-side, allow authentication of client identity to drive authorization of what resources that TN3270E session can reach. This is not to define an authorization technique or algorithm; the purpose is to make sure that the timing of the authentication is consistent with the execution of server-side authorization policies. What have I left out? Have I listed something that really is not necessary or very desirable? Brief Description of current SSL-based Telnet solutions: -------------------------------------------------------- I've looked around the web for telnet implementations that use TLS or SSL. There appear to a group of them using the SSLeay implementation of SSL. Here are some notes on the SSLeay Telnet hacks: * Uses RFC1416 to negotiate whether SSL (or some other auth-mechanism) is used. It does this in a hokey way: the sequence goes like this: server: AUTH SEND client: AUTH IS = AUTH_SSL_START server: AUTH REPLY =AUTH_SSL_ACCEPT [SSL-transport-level negotiation proceeds] [SSL-transport-level negotiation proceeds] The authentication, at the Telnet level, as rubber-stamped as being good in the telnet code *before* the SSL-level negotiation completes; if it turns out otherwise, the connection is dropped (and the program or child program terminates). * Alternately, the negotiation could happen at connect-time. One supposes this behavior is ok if an alternate server TCP port is chosen. So, it appears that early telnet-over-SSL experience has been flexible. The point seems to be that: * if the client connects to port 23 (well-known port for Telnet), then the SSL gets negotiated via RFC1416 (with SSL negotiation happening "between the lines"). * if the client connects to a "special" port, then the SSL negotiation happens at connect time; in this case, no RFC1416 negotiation occurs. The special port has an registered IANA well-known value of 992 (decimal). Some problems have arisen. First is the issue of using RFC1416 to "authenticate." As noted above, the RFC1416 form of the negotiation is a complete ruse--the only thing negotiated at the Telnet level is agreeing (or not) to enter SSL negotiation at that point in time. I have not investigated how hard this will be for users of the Winsock 3.x API. Specifically, can the client flush network buffers and frame the exact time (in the stream of the client/server dialog) that the TLS/SSL negotiates gets started? Another problem appears to be the negotiation of encryption--or rather, the lack of it. The SSL encryption/decryption happens at a layer which transparent to the normal Telnet communications. Also, the negotiation of encryption happens at the same time as the authentication--therefore, the end-user gets no choice in the matter. Not that this is all that bad...just that it makes a mockery of the Telnet option support. So...question here is: IF SSL is deemed the way to go, then do we support both of these methods in the code? Or just the negotiate-SSL-upon-connect style? Comments which go out on a limb and discuss *why* things are good or bad will be applauded :-). /msb   Received: from cnri by ietf.org id aa13425; 5 Aug 97 12:52 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA13458 for ; Tue, 5 Aug 1997 12:50:33 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id MAA24771; Tue, 5 Aug 1997 12:45:45 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2921269 for TN3270E@LIST.NIH.GOV; Tue, 5 Aug 1997 12:45:43 -0400 Received: from zoom.eicon.com (zoom.eicon.com [192.219.20.250]) by list.nih.gov (8.8.5/8.8.5) with SMTP id MAA24602 for ; Tue, 5 Aug 1997 12:35:40 -0400 (EDT) Received: from admin.eicon.com by zoom.eicon.com with SMTP id AA00713 (5.67a/IDA-1.5 for ); Tue, 5 Aug 1997 12:41:55 -0400 Received: by admin.eicon.com with Microsoft Mail id <33E780E9@admin.eicon.com>; Tue, 05 Aug 97 12:37:13 PDT From: Eugene Aresteanu To: 'TN3270 list' Subject: Security enhancements Date: Tue, 05 Aug 97 12:36:00 PDT Message-Id: <33E780E9@admin.eicon.com> Encoding: 51 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-tn3270e@list.nih.gov Hi! I would really appreciate if anyone could shed some light on the following points, following the TN3270 security enhancements mail. SSL is the most widely deployed on the client-side platforms (this implies certain assumptions about the operating-system and working-environment of the clients....but commercial vendors all seemed to like the assumptions, so there was not a lot of disagreement here). Would it be possible to know what the assumptions are? Especially for a Windows(NT/95) client and for a Java client? The client-side implementors want an API or some easy set of code-interfaces to write to; Does anyone know of such an API? And especially one for Java? The client-side implementors do not want to have export-restricted code problems (winsock 3 will have SSL libraries shipped with the OS or TCPIP stack); Sorry for my ignorance of this matter, but having an API on top of Winsock 3 SSL and writing to this API does solve the whole problem of encryption/authentication? Or it does require separate purchase of cryptographic algorithm engines? And again, will this API somehow be exposed to Java (Sun's intentions, other class libraries...). Another problem appears to be the negotiation of encryption--or rather, the lack of it. The SSL encryption/decryption happens at a layer which transparent to the normal Telnet communications. Also, the negotiation of encryption happens at the same time as the authentication--therefore, the end-user gets no choice in the matter. Not that this is all that bad...just that it makes a mockery of the Telnet option support. If you look at http and https, which are sort of two different protocols on two different ports, shouldn't we perheaps have a similar distinction between Telnet and TelnetS? And this would sort of move the ball from the TN3270 court into the Telnet court? Thank you!   Received: from cnri by ietf.org id aa14093; 5 Aug 97 13:20 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA13553 for ; Tue, 5 Aug 1997 13:19:11 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id NAA25713; Tue, 5 Aug 1997 13:14:30 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2921542 for TN3270E@LIST.NIH.GOV; Tue, 5 Aug 1997 13:14:28 -0400 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by list.nih.gov (8.8.5/8.8.5) with SMTP id NAA25557 for ; Tue, 5 Aug 1997 13:04:27 -0400 (EDT) Received: from d04lms02.raleigh.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AB22472; Tue, 5 Aug 1997 17:08:28 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU008 id 5040200003900776; Tue, 5 Aug 1997 13:11:58 -0400 From: Kenneth White To: tn3270e@list.nih.gov MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: dericv@wrq.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: call for status??? Message-Id: <5040200003900776000002L062*@MHS> Date: Tue, 5 Aug 1997 13:11:58 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tn3270e@list.nih.gov Deric, >Hi Gang, that is all y'all who have taken responsibility for work >items related to the TN3270E working group. >First, Thank You Rodger Erickson for posting your proposal so >quickly, you get first prize! >As to the rest of you.... Can you update the rest of us on the >status of your work? I understand that everyone has a "real" job >and that often "volunteer" work gets second, third, or lower >priority. But it would be useful for everyone (especially the >working group chairs) to be current on the status of the work. >I realize that I probably should have asked this earlier but now >that the IETF Munich meeting is drawing nearer, it is important to >get a gauge of the amount of work completed and the amount of work >yet to be completed. >So if everyone could please post a brief note (before Munich) on >the list telling us where you are at on your projects we would >greatly appreciate it. Bob Moore and I are currently working on two internet-drafts: , TN3270E-MIB that provides for TN3270E Server Configuration and , TN3270E-RT-MIB that provides TN3270E Server Performance Management. Both of these have been submitted to the working group and currently are being discussed. We have received some good feedback and are in the process of making some revisions. These MIbs will continue to be discussed on the TN3270E list and will be reviewed during one of the TN3270E sessions at Munich. We will re-post the MIbs after Munich. Ken   Received: from cnri by ietf.org id aa16600; 5 Aug 97 14:36 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA13773 for ; Tue, 5 Aug 1997 14:35:13 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id OAA28484; Tue, 5 Aug 1997 14:30:25 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2922212 for TN3270E@LIST.NIH.GOV; Tue, 5 Aug 1997 14:30:23 -0400 Received: from tai.cisco.com (tai.cisco.com [171.69.160.33]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id OAA28006 for ; Tue, 5 Aug 1997 14:20:17 -0400 (EDT) Received: from grind (grind.cisco.com [172.22.36.136]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id OAA22914; Tue, 5 Aug 1997 14:19:42 -0400 (EDT) Date: Tue, 5 Aug 1997 11:29:18 -0700 (PDT) From: Michael Boe Reply-To: Michael Boe Subject: Re: Security enhancements To: Eugene Aresteanu cc: 'TN3270 list' In-Reply-To: <33E780E9@admin.eicon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov > Hi! I would really appreciate if anyone could shed some light on the > following points, following the > TN3270 security enhancements mail. > > SSL is the most widely deployed on the client-side platforms (this > implies certain assumptions about the operating-system and > working-environment > of the clients....but commercial vendors all seemed to like the > assumptions, > so there was not a lot of disagreement here). > Would it be possible to know what the assumptions are? > Especially for a Windows(NT/95) client and for a Java client? Sure....though as a server vendor, I'm sure I haven't got anywhere near a complete list: * win95/winNT 5.0 platform with winsock 3.0 as a platform moves the export-restricted code out from the applications and into the OS (or jvm-enabled browser, if you're running a Java app). In fact, the platform set is less restrictive for java1.1 than for OS-native apps because of the fact that the browser is the OS-environment, not the platform OS itself....and the set of platforms that Java-enabled browsers run on is larger than the number of platforms that Microsoft's Winsock "shim/library" is deployed on :-). [I've dodged some hard work explaining the versioning problems both on win95 and on java-enabled platforms. That's because I'm hoping somebody will come forward with a more complete story on what the exact landscape of client OS-provided SSL libraries really is.] * the RSA cipher-suite is sufficient for general TN3270E use. The RSA cipher-suite is the only one "ubiquitously" deployed, and no real talk of SSL being ubiquitous in the real-world can be had without implying the same about the RSA suite. See the original mail's comments about compression for one possible reason why this might not be a good idea. Also note that the RSA suite requires licensing from RSA and/or PKP(?) if you're going to be including the RSA cipher-suite within your application (for instance, your app needs to live in an OS/browser environment where no API access to the OS-provided RSA calls exist). * that the story of certificates (and how the client retrieves them to provide them to server at SSL authentication time) is being "sorted out" for the various platforms. At this time, only the win95/nt platforms is a clear story emerging on how this can be done (and no clear story over whether this will become the "standard" way of doing these things, other than Microsoft's track record of controlling desktop API standards). See the Wallet and Crypto APIs from Microsoft for more info on this. > > The client-side implementors want an API or some easy set of > code-interfaces to write to; > Does anyone know of such an API? And especially one for Java? > > The client-side implementors do not want to have export-restricted code > problems (winsock 3 will have SSL libraries shipped with the OS or TCPIP > stack); > Sorry for my ignorance of this matter, but having an API on top of > Winsock 3 SSL and writing > to this API does solve the whole problem of encryption/authentication? > Or it does require > separate purchase of cryptographic algorithm engines? And again, will > this API somehow be > exposed to Java (Sun's intentions, other class libraries...). Anyone? > > Another problem appears to be the negotiation of encryption--or rather, > the > lack of it. The SSL encryption/decryption happens at a layer which > transparent > to the normal Telnet communications. Also, the negotiation of encryption > happens at the same time as the authentication--therefore, the end-user > gets > no choice in the matter. Not that this is all that bad...just that it > makes a > mockery of the Telnet option support. > If you look at http and https, which are sort of two different protocols > on two different ports, > shouldn't we perheaps have a similar distinction between Telnet and > TelnetS? And this > would sort of move the ball from the TN3270 court into the Telnet court? Yes...but the telnet WG does not appear to be active at this point. So we'll have to tackle that one on our own. It would be very desirable that whatever we come up with be "in common" with regular Telnet. /msb   Received: from cnri by ietf.org id aa20757; 5 Aug 97 16:05 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA14127 for ; Tue, 5 Aug 1997 16:03:31 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id PAA01937; Tue, 5 Aug 1997 15:58:19 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2923276 for TN3270E@LIST.NIH.GOV; Tue, 5 Aug 1997 15:58:16 -0400 Received: from fs1.montreal.hcl.com (fs1.montreal.hcl.com [198.168.185.55]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id PAA01897 for ; Tue, 5 Aug 1997 15:58:06 -0400 (EDT) Received: from jon.montreal.hcl.com by fs1.montreal.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id QKPNNLWN; Tue, 5 Aug 1997 16:02:21 -0400 Message-Id: <199708051958.PAA01897@list.nih.gov> Date: Tue, 05 Aug 1997 15:57:57 -0400 From: "Derek W. Bolton" To: tn3270e@list.nih.gov Subject: Re: Reply-To: "Derek W. Bolton" X-Mailer: SoftDesign WorldDesk Build 317 Sender: owner-tn3270e@list.nih.gov From owner-tn3270e@list.nih.gov Mon Aug 04 01:01 GMT 1997 Received: from [132.216.30.26] by fs1.montreal.hcl.com(Warp-9/NT) id 37955273.0; Mon, 04 Aug 97 01:01:33 GMT Received: from sirocco.CC.McGill.CA (sirocco.CC.McGill.CA [132.206.27.12]) by java.cc.mcgill.ca (8.8.5/8.8.5) with SMTP id UAA12719; Sun, 3 Aug 1997 20:57:11 -0400 (EDT) Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by sirocco.CC.McGill.CA (8.6.12/8.6.6) with ESMTP id VAA09886; Sun, 3 Aug 1997 21:03:19 -0400 X-SMTP-Posting-Origin: list.nih.gov (list.nih.gov [165.112.130.6]) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id UAA20101; Sun, 3 Aug 1997 20:56:21 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2922994 for TN3270E@LIST.NIH.GOV; Sun, 3 Aug 1997 20:56:18 -0400 Received: from ringer.cisco.com (ringer.cisco.com [171.69.176.7]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id UAA20088 for ; Sun, 3 Aug 1997 20:56:15 -0400 (EDT) Received: (dbolton@localhost) by ringer.cisco.com (8.8.4-Cisco.1/8.6.5) id KAA02395 for tn3270e@LIST.NIH.GOV; Mon, 4 Aug 1997 10:56:59 +1000 (EST) From: "Derek W. Bolton" Message-Id: <199708040056.KAA02395@ringer.cisco.com> Subject: Re: To: tn3270e@LIST.NIH.GOV Date: Mon, 4 Aug 1997 10:56:59 +1000 (EST) In-Reply-To: <5040200003836155000002L052*@MHS> from "Kenneth White" at Aug 3, 97 11:46:54 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tn3270e@LIST.NIH.GOV Return-Path: Kenneth, > >1. Is this only for LUT2? If it's for printers as well there's > >a snag. Instead of the presumed sequence: > > client Host > > data ------------> > > <----------- data > > response -----------> > > (longish delay) > >printers can go > > client Host > > <----------- data > > response -----------> > > (longish delay) > >or even > > <----------- data > > response -----------> > > data ------------> > > (longish delay) > >which will lead to arbitrary "response times". > Printer sessions were not considered. How about doing the > following: > client TN3270E Host > Server > D > <------------------- data > E turn DR on > response ------------------> > F DR +/- > <--------- > F - D would still be an approximation for total response time. > F - E would then be SNA network time plus host time. No, that doesn't work unless the "response" from the printer is actually a reply (i.e. an SNA request). Can't make the Host respond to a response. Besides, E-D is likely to include printing time, not just network time. We could simply exclude LUT1 and LUT3 sessions from the stats. (3274 doesn't do RTM for printers.) The only other suggestion I have is: - separate stats (as you also suggest) - just measure Host time up to EOJ: client TN3270E Host Server D <------------------- data, not EB E response ------------------> F <------------------- data (perhaps EB) The time F-E should represent Host response time. I.e. if the Host did not send EB last time then the next rsp sent in should provoke more data immediately. One thing to watch here is pacing. E represents the time at which we gave the Host the go-ahead, whether by +rsp, -rsp or IPR. (Does the same issue arise with screens? I think it might.) > I would have to update the text for the IP Network times in the > tn3270eRtDataTable to indicate that an ElementType object in > either the tn3270eResMapTable or the tn3270eTcpConnTable for > a particular session would need to be examined to determine > what the IP counter objects really represented. When a collection > was for an aggregate then the IP Client could be a mix of LU > and printer sessions. To solve this it might be better to create > the following objects: > tn3270eRtDataAverageSnaRt > tn3270eRtDataCurrTotalIpRt > tn3270eRtDataCurrElapsIpRtSq > and keep the counts separate. Opinions? > >2. Precision and wrap of totals > > > >You have the durations measured in milliseconds and allow 32 bits for > >all totals. I don't see any provision for resetting the totals, so I > >guess they're allowed to wrap. That imposes a minimum collection > >rate. > Right. In a tn3270eRtDataEntry: > tn3270eRtDataCurrTotalRt > tn3270eRtDataCurrTotalIpRt > tn3270eRtDataCurrTransCount > tn3270eRtDataCurrDrCount > tn3270eRtDataCurrElapsRnTrpSq > tn3270eRtDataCurrElapsIpRtSq > tn3270eRtDataBucket1 > tn3270eRtDataBucket2 > tn3270eRtDataBucket3 > tn3270eRtDataBucket4 > tn3270eRtDataBucket5 > can wrap. > > > >Suppose the round trip time is about 2000 msecs, which it could well > >be in an overloaded network (precisely the time when you need this > >RTM logic to give the right answers). That's 2**11. > > > >At 1000 tps, the total time will overflow after (2**21)/1000 seconds, > >or about half an hour. To be on the safe side, the data would need to > >be collected every 15 minutes. That might just about be acceptable, > >but now look at the sum of squares. Each squared time is about 2**22, > >so the total will overflow in 1 second! > > > >(It might seem unlikely that you could be processing 1000 tps yet have > >a turn round of 2 seconds. That says that at any moment there are > >2000 transactions in progress. Where are they all? If the server's > >TCP is highly scalable and has plenty of buffering, there could be one > >transaction pending for each of 2000 clients.) > > > >A possible solution is to use a different unit for the sum of > >squares, like 0.01 square seconds (i.e. 10000 square msecs). > >Internally, the server would keep the information in square > >milliseconds (or even smaller) - otherwise the total might never go > >nonzero - but present the totals in the larger unit. > > > >Even for the unsquared totals, milliseconds seems unnecessarily small > >a unit. Is anyone going to care about totals finer than a tenth of > >a second? > Good point. How about for: > tn3270eRtDataCurrTotalRt > tn3270eRtDataCurrTotalIpRt > tn3270eRtDataCurrElapsRnTrpSq > tn3270eRtDataCurrElapsIpRtSq > changing the unit of measure to seconds. That might be going too far. There's some merit in keeping a consistent set of units if that's feasible. I would think tenths of seconds are fine enough for individual client measurements, yet coarse enough that the totals would not wrap too often. If we go for different units for variables of different scope then the use of 'subnet' totals gets awkward. There's no way of predicting at MIB design time whether the fine or coarse units are appropriate. (I know I suggested different units for the sum of squares, but that seems more defensible as a general principle.) Using the same example as above, and with tenths of seconds as the standard, even the sum of squares would take 2 hours to wrap. > >3. Averaging > >My own preference is always for sliding averages. They are far easier > >to collect and in many situations more meaningful. Also, since you > >have alerts generated from thresholds, a sliding average would cause > >less alert thrashing. > For sliding averages I assume that you mean keeping a window of n > averages calculated at each collection interval. The average > reported would be the average of the n averages. Is this what you > mean? I would prefer leaving the averages as they are since totals > are kept that can be sampled to show overall rates. A low threshold > was defined in order to address the trap generation problem. Not quite. For one thing, one must avoid the old average-of-averages trap. For another, you want something that smoothes the data to make it more intelligible. I ought to explain the problem I'm trying to solve. On the one hand, you want the average taken over a reasonable period, maybe 30 minutes, so that the NM application doesn't have to issue Get too often in order to see all the data. Even then, if it issues the Get every 10 minutes then it will see the same data two three or four times. Does it know how often it saw the same data? Not if there's no timestamp on it. So there's a 2:1 variation in how it might assess the general state of affairs. Also, as the averaging period becomes longer, bursts that should have been sufficient for an alert are missed. These bursts could themselves be as long as the averaging period if they happen to straddle two periods. So the ideal is to have the data updated fairly often but to contain enough smoothing that the NM appl doesn't have to poll hard. Here's what I propose: - Pick a fixed shortish sample period, t (like 20) seconds. - Configured "averaging" period is some multiple of this, 2k minutes (see note) - Compute the ratio h = 2k * 60 / t - Keep four variables: countThisPeriod of transactions totalThisPeriod of elapsed times countSliding; this is the count for the previous period, plus a diminishing contribution from all preceding periods. totalSliding; likewise - During a sample period, the ThisPeriod variables are updated for events completing that period - At the end of each period, the sliding counts are updated thus: countSliding = countSliding + countThisPeriod - countSliding/h totalSliding = totalSliding + totalThisPeriod - totalSliding/h The ThisPeriod variables are then reset and totalSliding/countSliding is compared with the alert threshold. - When a Get is issued for the average time, it reports totalSliding/countSliding Note: The averaging period is quoted as 2k because this gives the right expectations. The average age of the data in the sliding variables is k minutes. > >4. TranCount > >If performance is very poor, you might not get enough transactions > >through to satisfy TranCount, so you dismiss the event as > >statistically insignificant! > >The orthodoxy is that the significance level is > >related to numTransactions * (average-threshold)**2. > >So I propose that TranCount is redefined as follows: > > if > > numTransactions * (average/threshold - 1)**2 < TranCount > > then no alert is generated. > >E.g. if the threshold is 200 msecs per transaction, the average > >observed is 300 and TranCount is set to 20 then an alert > >will be generated if numTransactions >= 80. On the other hand, > >if the observed is 500 then the alert is generated if > >numTransactions >= 9. > >If my push for sliding averages is accepted then there's another > >issue with TranCount - it has to be replaced by a transaction > >rate (which is also maintained as a sliding average with the same > >aging). But the formula is the same: > > slidingRate * (average/threshold - 1)**2 < TranRate > >(I'd like to find a more descriptive name than TranRate. IdleRate? > >DetectRate?) > I like your approach to using an algorithm for TranRate and will > adopt your proposal. I will change the name to IdleRate. > >> SNA resources can be configured to automatically request definite > >> response or a TN3270E Server can dynamically request it itself. > >> The tn3270eRtCollCtlType object in a tn3270eRtCollCtlEntry has a > >> BIT setting, ddr(1), defined to inform the TN3270E Server as to > >> whether dynamic definite response is enabled (refer to section > >> 4.1, tn3270eRtCollCtlTable) for a particular response time > >> collection policy. Dynamically requesting definite response from > >> a TN3270E Server does increase IP Network traffic which may not be > >> desirable in certain customer environments. In addition, if a > >> customer determines that their IP Network times are not > >> significant then dynamic definite response (DDR) can be disabled. > >Another consideration is a mismatch between DR requesting on the SNA > >side and DR requesting on the TN3270E side. If the Host sends a > >multiple PU chain, the server does not know until EC whether DR is > >being requested. Meanwhile, the server may have forwarded the start > >of the record to the client. In practice, therefore, some servers are > >converting EXR flows to DR flows already. > I will need to add some text to cover this. In calculation > timestamps E and F I don't think it matters which DR flow is > used. If the TN3270E Server is doing one any way then is should use > that one as oppose to a new one. > I will incorporate the rest of your comments in the next revision > which is expected to occur after Munich. Thanks for your comments. > Ken   Received: from cnri by ietf.org id aa21251; 5 Aug 97 16:18 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA14152 for ; Tue, 5 Aug 1997 16:16:53 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id QAA02406; Tue, 5 Aug 1997 16:11:53 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2923322 for TN3270E@LIST.NIH.GOV; Tue, 5 Aug 1997 16:11:51 -0400 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by list.nih.gov (8.8.5/8.8.5) with SMTP id QAA02121 for ; Tue, 5 Aug 1997 16:01:48 -0400 (EDT) Received: from d04lms02.raleigh.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AB115324; Tue, 5 Aug 1997 20:04:29 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU008 id 5040200003910382; Tue, 5 Aug 1997 16:07:59 -0400 From: Kenneth White To: tn3270e@list.nih.gov MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: dbolton@cisco.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: Message-Id: <5040200003910382000002L022*@MHS> Date: Tue, 5 Aug 1997 16:07:59 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tn3270e@list.nih.gov Derek, >No, that doesn't work unless the "response" from the printer >is actually a reply (i.e. an SNA request). Can't make the >Host respond to a response. >Besides, E-D is likely to include printing time, not just network >time. >We could simply exclude LUT1 and LUT3 sessions from the stats. (3274 >doesn't do RTM for printers.) The only other suggestion I have is: >- separate stats (as you also suggest) >- just measure Host time up to EOJ: > client TN3270E Host > Server > D > <------------------- data, not EB > E > response ------------------> > F > <------------------- data (perhaps EB) > The time F-E should represent Host response time. I.e. if the > Host did not send EB last time then the next rsp sent in > should provoke more data immediately. > >One thing to watch here is pacing. E represents the time at >which we gave the Host the go-ahead, whether by +rsp, -rsp or >IPR. (Does the same issue arise with screens? I think it might.) Bob and I discussed this and plan to updated the TN3270E-RT-MIB to exclude printer sessions. If you disagree please let us know. >> Good point. How about for: >> tn3270eRtDataCurrTotalRt >> tn3270eRtDataCurrTotalIpRt >> tn3270eRtDataCurrElapsRnTrpSq >> tn3270eRtDataCurrElapsIpRtSq >> changing the unit of measure to seconds. >That might be going too far. There's some merit in keeping a >consistent set of units if that's feasible. I would think tenths of >seconds are fine enough for individual client measurements, yet coarse >enough that the totals would not wrap too often. >If we go for different units for variables of different scope then the >use of 'subnet' totals gets awkward. There's no way of predicting at >MIB design time whether the fine or coarse units are appropriate. (I >know I suggested different units for the sum of squares, but that >seems more defensible as a general principle.) >Using the same example as above, and with tenths of seconds as the >standard, even the sum of squares would take 2 hours to wrap. OKay. I will change the unit of measure to 10th of seconds for all of the objects we have been discussing. How about making them all 10th of seconds? For example, the 4 bucket boundaries in a tn3270eRtCollCtlEntry as well as tn3270eRtDataAverageRt and tn3270eRtDataAverageIpRt. I would prefer to have a uniform unit of measure across the MIB were possible. > >3. Averaging > >My own preference is always for sliding averages. They are far easier > >to collect and in many situations more meaningful. Also, since you > >have alerts generated from thresholds, a sliding average would cause > >less alert thrashing. >>For sliding averages I assume that you mean keeping a window of n >>averages calculated at each collection interval. The average >>reported would be the average of the n averages. Is this what you >>mean? I would prefer leaving the averages as they are since totals >>are kept that can be sampled to show overall rates. A low threshold >>was defined in order to address the trap generation problem. >Not quite. For one thing, one must avoid the old average-of-averages >trap. For another, you want something that smoothes the data to >make it more intelligible. >I ought to explain the problem I'm trying to solve. On the one >hand, you want the average taken over a reasonable period, maybe >30 minutes, so that the NM application doesn't have to issue Get >too often in order to see all the data. Even then, if it issues >the Get every 10 minutes then it will see the same data two three >or four times. Does it know how often it saw the same data? Not if >there's no timestamp on it. So there's a 2:1 variation in how it >might assess the general state of affairs. This is a timestamp in a tn3270eRtDataEntry, tn3270eRtDataTimeStamp, as to when tn3270eRtDataAverageRt, tn3270eRtDataAverageIpRt, tn3270eRtDataTransCount, and tn3270eRtDataDrCount were last updated based on tn3270eRtCollCtlInterval. >Also, as the averaging period becomes longer, bursts that should >have been sufficient for an alert are missed. These bursts >could themselves be as long as the averaging period if they happen >to straddle two periods. >So the ideal is to have the data updated fairly often but to contain >enough smoothing that the NM appl doesn't have to poll hard. >Here's what I propose: >- Pick a fixed shortish sample period, t (like 20) seconds. >- Configured "averaging" period is some multiple of this, 2k minutes > (see note) >- Compute the ratio h = 2k * 60 / t >- Keep four variables: > countThisPeriod of transactions > totalThisPeriod of elapsed times > countSliding; this is the count for the previous period, plus a > diminishing contribution from all preceding periods. > totalSliding; likewise >- During a sample period, the ThisPeriod variables are updated > for events completing that period >- At the end of each period, the sliding counts are updated thus: > countSliding = countSliding + countThisPeriod - countSliding/h > totalSliding = totalSliding + totalThisPeriod - totalSliding/h > The ThisPeriod variables are then reset and > totalSliding/countSliding is compared with the alert threshold. >- When a Get is issued for the average time, it reports > totalSliding/countSliding >Note: The averaging period is quoted as 2k because this gives the >right expectations. The average age of the data in the sliding >variables is k minutes. Bob and I are willing to adopt your proposal for caculating sliding averages. In the TN3270E-RT-MIB we could change tn3270eRtCollCtlInterval to be the sample period with a default of 20 seconds instead of letting it be fixed. We could then define a new object, tn3270eRtCollCtlAPMultiplier, as the averaging period multiplier. The actual averaging period would be Interval times the multiplier. tn3270eRtDataAverageRt and tn3270eRtDataIpAverageRt can be recalculated at the end of a sample period (tn3270eRtCollCtlInterval) and tn3270eRtDataAverageRt compared to the thresholds for trap generation. tn3270eRtDataTransCount and DrCount would have to be the values used in the average calculation. Internally: "countThisPeriod of transactions and totalThisPeriod of elapsed times" would have to be kept and not surfaced in the MIB. This is different from your proposal of calculating the averages on demand. The DR counts need to be kept separate so we would have to do for it what is done for the general transaction count. The DR count is useful for comparing to the transaction count for determining if DR was used in calculating the IP Network Time for all of the clients specified by a IP Group. Regards, Ken   Received: from cnri by ietf.org id aa04566; 5 Aug 97 19:18 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA14797 for ; Tue, 5 Aug 1997 19:16:52 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id TAA13449; Tue, 5 Aug 1997 19:12:26 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2926373 for TN3270E@LIST.NIH.GOV; Tue, 5 Aug 1997 19:12:22 -0400 Received: from ringer.cisco.com (ringer.cisco.com [171.69.176.7]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id TAA12679 for ; Tue, 5 Aug 1997 19:08:03 -0400 (EDT) Received: (dbolton@localhost) by ringer.cisco.com (8.8.4-Cisco.1/8.6.5) id JAA16945 for tn3270e@LIST.NIH.GOV; Wed, 6 Aug 1997 09:08:51 +1000 (EST) From: "Derek W. Bolton" Message-Id: <199708052308.JAA16945@ringer.cisco.com> Subject: Re: To: tn3270e@list.nih.gov Date: Wed, 6 Aug 1997 09:08:51 +1000 (EST) In-Reply-To: <5040200003910382000002L022*@MHS> from "Kenneth White" at Aug 5, 97 04:07:59 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tn3270e@list.nih.gov Ken, > Bob and I discussed this and plan to updated the TN3270E-RT-MIB > to exclude printer sessions. If you disagree please let us know. Fine by me. > >> Good point. How about for: > >> tn3270eRtDataCurrTotalRt > >> tn3270eRtDataCurrTotalIpRt > >> tn3270eRtDataCurrElapsRnTrpSq > >> tn3270eRtDataCurrElapsIpRtSq > >> changing the unit of measure to seconds. > >That might be going too far. There's some merit in keeping a > >consistent set of units if that's feasible. I would think tenths of > >seconds are fine enough for individual client measurements, yet coarse > >enough that the totals would not wrap too often. > >If we go for different units for variables of different scope then the > >use of 'subnet' totals gets awkward. There's no way of predicting at > >MIB design time whether the fine or coarse units are appropriate. (I > >know I suggested different units for the sum of squares, but that > >seems more defensible as a general principle.) > >Using the same example as above, and with tenths of seconds as the > >standard, even the sum of squares would take 2 hours to wrap. > OKay. I will change the unit of measure to 10th of seconds for all > of the objects we have been discussing. How about making them all > 10th of seconds? For example, the 4 bucket boundaries in a > tn3270eRtCollCtlEntry as well as tn3270eRtDataAverageRt and > tn3270eRtDataAverageIpRt. I would prefer to have a uniform unit > of measure across the MIB were possible. Agree. > > >3. Averaging > >>For sliding averages I assume that you mean keeping a window of n > >>averages calculated at each collection interval. The average > >>reported would be the average of the n averages. Is this what you > >>mean? I would prefer leaving the averages as they are since totals > >>are kept that can be sampled to show overall rates. A low threshold > >>was defined in order to address the trap generation problem. > >Not quite. For one thing, one must avoid the old average-of-averages > >trap. For another, you want something that smoothes the data to > >make it more intelligible. > >I ought to explain the problem I'm trying to solve. On the one > >hand, you want the average taken over a reasonable period, maybe > >30 minutes, so that the NM application doesn't have to issue Get > >too often in order to see all the data. Even then, if it issues > >the Get every 10 minutes then it will see the same data two three > >or four times. Does it know how often it saw the same data? Not if > >there's no timestamp on it. So there's a 2:1 variation in how it > >might assess the general state of affairs. > There is a timestamp in a tn3270eRtDataEntry, > tn3270eRtDataTimeStamp, as to when tn3270eRtDataAverageRt, > tn3270eRtDataAverageIpRt, tn3270eRtDataTransCount, and > tn3270eRtDataDrCount were last updated based on > tn3270eRtCollCtlInterval. Ah - I missed that. But is it really needed? What is the benefit compared with simply reporting up-to-the minute data? OK, there has to be a sampling period, so the data can be up to one sample period old. But surely the sample periods can be kept below a minute, which would be much less than the NM appl poll period. What I'm saying is that I think the use of sliding averages dispenses with the need for timestamps. Anyway, your proposal allows either implementation. If an implementation is in a position to report current values for everything then it can compute the averages on demand and report as timestamp the time of the Get. All that the MIB can require is that the data are consistent with the timestamp. > >Also, as the averaging period becomes longer, bursts that should > >have been sufficient for an alert are missed. These bursts > >could themselves be as long as the averaging period if they happen > >to straddle two periods. > >So the ideal is to have the data updated fairly often but to contain > >enough smoothing that the NM appl doesn't have to poll hard. > >Here's what I propose: > >- Pick a fixed shortish sample period, t (like 20) seconds. > >- Configured "averaging" period is some multiple of this, 2k minutes > > (see note) > >- Compute the ratio h = 2k * 60 / t > >- Keep four variables: > > countThisPeriod of transactions > > totalThisPeriod of elapsed times > > countSliding; this is the count for the previous period, plus a > > diminishing contribution from all preceding periods. > > totalSliding; likewise > >- During a sample period, the ThisPeriod variables are updated > > for events completing that period > >- At the end of each period, the sliding counts are updated thus: > > countSliding = countSliding + countThisPeriod - countSliding/h > > totalSliding = totalSliding + totalThisPeriod - totalSliding/h > > The ThisPeriod variables are then reset and > > totalSliding/countSliding is compared with the alert threshold. > >- When a Get is issued for the average time, it reports > > totalSliding/countSliding > >Note: The averaging period is quoted as 2k because this gives the > >right expectations. The average age of the data in the sliding > >variables is k minutes. > Bob and I are willing to adopt your proposal for caculating sliding > averages. In the TN3270E-RT-MIB we could change > tn3270eRtCollCtlInterval to be the sample period with a default of > 20 seconds instead of letting it be fixed. We could then define > a new object, tn3270eRtCollCtlAPMultiplier, as the averaging period > multiplier. The actual averaging period would be Interval times the > multiplier. Not sure about that. I didn't intend that the sampling period be fixed by the MIB. In my view, it can be fixed by the implementation. It does not need to appear in the MIB at all. All the MIB cares about is the averaging period. None of the MIB variables are seriously affected by the sampling period. (In practice, it affects the smoothness with which the variables change value.) What use do you think the NM appl can make of that info? Of course, if you made the averaging period settable through the MIB then you'd need to define the set of valid values so that an implementation could choose a sampling period that's a factor of all averaging periods. E.g. averaging periods are always whole minutes. Regards, Derek > tn3270eRtDataAverageRt and tn3270eRtDataIpAverageRt can be > recalculated at the end of a sample period > (tn3270eRtCollCtlInterval) and tn3270eRtDataAverageRt compared to > the thresholds for trap generation. tn3270eRtDataTransCount and > DrCount would have to be the values used in the average calculation. > Internally: > "countThisPeriod of transactions and > totalThisPeriod of elapsed times" > would have to be kept and not surfaced in the MIB. This is different > from your proposal of calculating the averages on demand. > The DR counts need to be kept separate so we would have to do for it > what is done for the general transaction count. The DR count is > useful for comparing to the transaction count for determining if DR > was used in calculating the IP Network Time for all of the clients > specified by a IP Group. > Regards, Ken   Received: from cnri by ietf.org id aa12691; 7 Aug 97 12:09 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA19425 for ; Thu, 7 Aug 1997 12:08:25 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id MAA16133; Thu, 7 Aug 1997 12:02:17 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2940991 for TN3270E@LIST.NIH.GOV; Thu, 7 Aug 1997 12:02:13 -0400 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by list.nih.gov (8.8.5/8.8.5) with SMTP id LAA15342 for ; Thu, 7 Aug 1997 11:52:09 -0400 (EDT) Received: from d04lms02.raleigh.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA135894; Thu, 7 Aug 1997 15:56:24 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU008 id 5040200003976836; Thu, 7 Aug 1997 11:59:38 -0400 From: Kenneth White To: tn3270e@list.nih.gov MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: Message-Id: <5040200003976836000002L062*@MHS> Date: Thu, 7 Aug 1997 11:59:38 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tn3270e@list.nih.gov Derek, >> There is a timestamp in a tn3270eRtDataEntry, >> tn3270eRtDataTimeStamp, as to when tn3270eRtDataAverageRt, >> tn3270eRtDataAverageIpRt, tn3270eRtDataTransCount, and >> tn3270eRtDataDrCount were last updated based on >> tn3270eRtCollCtlInterval. >Ah - I missed that. But is it really needed? What is the >benefit compared with simply reporting up-to-the minute data? >OK, there has to be a sampling period, so the data can be >up to one sample period old. But surely the sample periods can >be kept below a minute, which would be much less than the >NM appl poll period. What I'm saying is that I think the >use of sliding averages dispenses with the need for timestamps. It's good to have a timestamp generated when the averages are updated for threshold comparison in order to return in a NOTIFICATION. Having a current timestamp in a RtDataEntry as oppose to the one in a NOTIFICATION enables correlation between the problem or resolution NOTIFICATION to the current performance. >Anyway, your proposal allows either implementation. If an >implementation is in a position to report current values for >everything then it can compute the averages on demand and report as >timestamp the time of the Get. All that the MIB can require is that >the data are consistent with the timestamp. Both AverageRt, AverageIpRt, TranCount, and DrCount must be consistent. You would have to be careful in that a get to AverageRt for example caused the four objects to be updated and not update them on a get to the other objects. There is nothing in the MIB that would prevent this. I would like to expand on TransCount and DrCount usage. Ideally, they should be equal. In practice DrCount may be less than TransCount. If it is then AverageRt (Total response time) does not include all of the IP Network Time approximations. AverageIpRt would contain only those times calculated for the clients that both support DR and have returned the response when the averages are calculated. Perhaps TransCount and DrCount can be used to generate a reliability estimator, DrCount / TransCount for example. >> Bob and I are willing to adopt your proposal for caculating sliding >> averages. In the TN3270E-RT-MIB we could change >> tn3270eRtCollCtlInterval to be the sample period with a default of >> 20 seconds instead of letting it be fixed. We could then define >> a new object, tn3270eRtCollCtlAPMultiplier, as the averaging period >> multiplier. The actual averaging period would be Interval times the >> multiplier. >Not sure about that. I didn't intend that the sampling period be >fixed by the MIB. In my view, it can be fixed by the implementation. >It does not need to appear in the MIB at all. All the MIB cares about >is the averaging period. None of the MIB variables are seriously >affected by the sampling period. (In practice, it affects the >smoothness with which the variables change value.) What use do you >think the NM appl can make of that info? Exposing the sample period in the MIB doesn't force an implementation to actually support variable sample periods. An implementation could simply return their sample period and disallow a set to this object. I would be willing to add the appropriate statements to the MIB to not require a set to this object. >Of course, if you made the averaging period settable through >the MIB then you'd need to define the set of valid values so >that an implementation could choose a sampling period that's >a factor of all averaging periods. E.g. averaging periods are >always whole minutes. That's why I attempted to express the averaging period as a multiplier, not as an interval, in the MIB. A management application that was going to set a averaging period would need to know the sample period. It could externalize a user's selection as a interval, divide this by the sample period that is retrieves using a get, and then set the multiplier. The multiplier would equal the interval selected divided by the sample period. Of course rounding would have to be considered since the interval selected may not be equally divisible by the sample period. An implementation that did not want to support sliding averages would not support a set to the averaging period multiplier object and instead default it to 1. I would like to provide a MIB that allows an implementation the freedom to decide what to implement considering all of the trade-offs. Regards, Ken   Received: from cnri by ietf.org id aa00837; 14 Aug 97 3:08 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid DAA04656 for ; Thu, 14 Aug 1997 03:11:51 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id DAA02168; Thu, 14 Aug 1997 03:06:00 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2996639 for TN3270E@LIST.NIH.GOV; Thu, 14 Aug 1997 03:05:57 -0400 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by list.nih.gov (8.8.5/8.8.5) with SMTP id CAA01534 for ; Thu, 14 Aug 1997 02:55:54 -0400 (EDT) Received: from d04lms02.raleigh.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA212840; Wed, 6 Aug 1997 19:26:02 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU008 id 5040200003946801; Wed, 6 Aug 1997 15:29:34 -0400 From: Kenneth White To: tn3270e@list.nih.gov MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: Message-Id: <5040200003946801000002L012*@MHS> Date: Wed, 6 Aug 1997 15:29:34 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tn3270e@list.nih.gov Derek, >> There is a timestamp in a tn3270eRtDataEntry, >> tn3270eRtDataTimeStamp, as to when tn3270eRtDataAverageRt, >> tn3270eRtDataAverageIpRt, tn3270eRtDataTransCount, and >> tn3270eRtDataDrCount were last updated based on >> tn3270eRtCollCtlInterval. >Ah - I missed that. But is it really needed? What is the >benefit compared with simply reporting up-to-the minute data? >OK, there has to be a sampling period, so the data can be >up to one sample period old. But surely the sample periods can >be kept below a minute, which would be much less than the >NM appl poll period. What I'm saying is that I think the >use of sliding averages dispenses with the need for timestamps. It's good to have a timestamp generated when the averages are updated for threshold comparison in order to return in a NOTIFICATION. Having a current timestamp in a RtDataEntry as oppose to the one in a NOTIFICATION enables correlation between the problem or resolution NOTIFICATION to the current performance. >Anyway, your proposal allows either implementation. If an >implementation is in a position to report current values for >everything then it can compute the averages on demand and report as >timestamp the time of the Get. All that the MIB can require is that >the data are consistent with the timestamp. Both AverageRt, AverageIpRt, TranCount, and DrCount must be consistent. You would have to be careful in that a get to AverageRt for example caused the four objects to be updated and not update them on a get to the other objects. There is nothing in the MIB that would prevent this. I would like to expland on TransCount and DrCount usage. Ideally, they should be equal. In practice DrCount may be less than TransCount. If it is then AverageRt (Total response time) does not include all of the IP Network Time approximations. AverageIpRt would contain only those times calculated for the clients that both support DR and have returned the response when the averages are calculated. Perhaps TransCount and DrCount can be used to generate a reliability estimator, DrCount / TransCount for example. >> Bob and I are willing to adopt your proposal for caculating sliding >> averages. In the TN3270E-RT-MIB we could change >> tn3270eRtCollCtlInterval to be the sample period with a default of >> 20 seconds instead of letting it be fixed. We could then define >> a new object, tn3270eRtCollCtlAPMultiplier, as the averaging period >> multiplier. The actual averaging period would be Interval times the >> multiplier. >Not sure about that. I didn't intend that the sampling period be >fixed by the MIB. In my view, it can be fixed by the implementation. >It does not need to appear in the MIB at all. All the MIB cares about >is the averaging period. None of the MIB variables are seriously >affected by the sampling period. (In practice, it affects the >smoothness with which the variables change value.) What use do you >think the NM appl can make of that info? Exposing the sample period in the MIb doesn't force an implementation to actually support variable sample periods. An implementation could simply return their sample period and disallow a set to this object. I would be willing to add the appropriate statements to the MIB to not require a set to this object. >Of course, if you made the averaging period settable through >the MIB then you'd need to define the set of valid values so >that an implementation could choose a sampling period that's >a factor of all averaging periods. E.g. averaging periods are >always whole minutes. That's why I attempted to express the averaging period as a multiplier, not as an interval, in the MIB. A management application that was going to set a averaging period would need to know the sample period. It could externalize a user's selection as a interval, divide this by the sample period that is retrieves using a get, and then set the multiplier. The multiplier would equal the interval selected divided by the sample period. An implementation that did not want to support sliding averages would not support a set to the averaging period multiplier object and instead default it to 1. I would like to provide a MIB that allows an implementation the freedom to decide what to implement considering all of the tradeoffs. Regards, Ken   Received: from cnri by ietf.org id aa24316; 15 Aug 97 0:29 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid AAA07421 for ; Fri, 15 Aug 1997 00:33:07 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id AAA20947; Fri, 15 Aug 1997 00:15:32 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2971875 for TN3270E@LIST.NIH.GOV; Fri, 15 Aug 1997 00:15:29 -0400 Received: from ringer.cisco.com (ringer.cisco.com [171.69.176.7]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id AAA20934 for ; Fri, 15 Aug 1997 00:15:27 -0400 (EDT) Received: (dbolton@localhost) by ringer.cisco.com (8.8.4-Cisco.1/8.6.5) id OAA25532; Fri, 15 Aug 1997 14:16:29 +1000 (EST) From: "Derek W. Bolton" Message-Id: <199708150416.OAA25532@ringer.cisco.com> Subject: Re: UNBIND/SENSE DATA To: bart@vnet.ibm.com, tn3270e@list.nih.gov Date: Fri, 15 Aug 1997 14:16:29 +1000 (EST) In-Reply-To: <199707241919.PAA07775@list.nih.gov> from "bart@VNET.IBM.COM" at Jul 24, 97 03:02:07 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tn3270e@list.nih.gov > Depending upon the implementation of the SNA LU interface, the > UNBIND RU can be available to the tn3270e server for processsing. An > enahncement to the tn3270e protocol would be to have the server > forward the UNBIND image to the client. This would include the > sense data (length depends upon whether Extended BIND was negotiated > or not). Since UNBIND can be sent at anytime from either LU, the > additional information would allow the client to better participate > in recovery of a lost session and manage the Operator Interface Area > (OIA). Currently, only the 1 byte type (reason code) is utilized. > I would be interested in the comments of others on this suggested > enhancement. I am in favor of making much greater use of SNA sense codes. These can be used to good effect without actually implementing any SNA. I particularly don't want to see a parallel set of codes grow up for TN3270 (as has already happened to some extent for the printer support). If you read my FMH proposal you'll see that I need to use SNA sense codes too. The only drawback with SNA sense codes is that there has been some undisciplined usage in the past, leading to sense codes which are much too specific to a context, or to the invention of new codes where existing codes have the same meaning. We could provide added value here by publishing a preferred subset of the codes, but I'm not sure it's worth the effort. Regards, Derek   Received: from cnri by ietf.org id aa07141; 15 Aug 97 11:10 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA08404 for ; Fri, 15 Aug 1997 11:13:44 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id LAA04146; Fri, 15 Aug 1997 11:08:28 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 2975438 for TN3270E@LIST.NIH.GOV; Fri, 15 Aug 1997 11:08:24 -0400 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by list.nih.gov (8.8.5/8.8.5) with SMTP id KAA03746 for ; Fri, 15 Aug 1997 10:58:20 -0400 (EDT) Received: from d04lms01.raleigh.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA15458; Fri, 15 Aug 1997 15:02:38 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU013 id 5040100007922128; Fri, 15 Aug 1997 11:00:30 -0400 From: Marcia Peters To: tn3270e@list.nih.gov MMDF-Warning: Parse error in original version of preceding line at ietf.org Message-Id: <5040100007922128000002L082*@MHS> Date: Fri, 15 Aug 1997 11:00:30 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tn3270e@list.nih.gov Derek's suggestion to make better use of existing SNA sense codes is a good one. Certainly we should avoid inventing sense codes unless it's really necessary. However, be aware that even reusing existing sense data for a new purpose may impact documentation (such as the SNA Formats). It may also impact Alerts (published in the MS Formats), since the alert problem solving information has some very specific words about what to do to resolve the problem. Bob Moore is a far greater expert than me in this area and I'm sure he will chime in if necessary. Marcia Peters IBM eNetwork Software Strategy and Technology (919)-254-4380   Received: from cnri by ietf.org id aa21198; 17 Aug 97 23:48 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA12214 for ; Sun, 17 Aug 1997 23:51:38 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id XAA15667; Sun, 17 Aug 1997 23:42:46 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 3024101 for TN3270E@LIST.NIH.GOV; Sun, 17 Aug 1997 23:42:43 -0400 Received: from tai.cisco.com (tai.cisco.com [171.69.160.33]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id XAA15654 for ; Sun, 17 Aug 1997 23:42:41 -0400 (EDT) Received: from mboe-pc.cisco.com (is-as5200-14.cisco.com [171.68.11.156]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id XAA25281; Sun, 17 Aug 1997 23:42:05 -0400 (EDT) Date: Mon, 18 Aug 1997 20:34:07 -0500 (Central Daylight Time) From: Michael Boe Reply-To: Michael Boe Subject: Re: UNBIND/SENSE DATA To: "Derek W. Bolton" cc: bart@vnet.ibm.com, tn3270e@list.nih.gov Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov >> Depending upon the implementation of the SNA LU interface, the >> UNBIND RU can be available to the tn3270e server for processsing. An >> enahncement to the tn3270e protocol would be to have the server >> forward the UNBIND image to the client. This would include the >> sense data (length depends upon whether Extended BIND was negotiated >> or not). Since UNBIND can be sent at anytime from either LU, the >> additional information would allow the client to better participate >> in recovery of a lost session and manage the Operator Interface Area >> (OIA). Currently, only the 1 byte type (reason code) is utilized. > >> I would be interested in the comments of others on this suggested >> enhancement. > >I am in favor of making much greater use of SNA sense codes. >These can be used to good effect without actually implementing >any SNA. I particularly don't want to see a parallel set of >codes grow up for TN3270 (as has already happened to some >extent for the printer support). I've no problem with the issue of whether to use SNA sense codes or to invent new ones; it seems a waste of time to re-invent things. The question is whether such codes are needed at all (following the KISS principle). In particular, if the client vendors find them useful then we should provide. But unless the client vendors say "yea verily, SNA codes are what we want," I don't see much point in architecting this into the spec. Client vendors? /msb > >If you read my FMH proposal you'll see that I need to use SNA >sense codes too. > >The only drawback with SNA sense codes is that there has been some >undisciplined usage in the past, leading to sense codes which are >much too specific to a context, or to the invention of new codes >where existing codes have the same meaning. We could provide added >value here by publishing a preferred subset of the codes, but I'm >not sure it's worth the effort. > >Regards, > Derek   Received: from cnri by ietf.org id aa10786; 19 Aug 97 12:52 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA17283 for ; Tue, 19 Aug 1997 12:55:45 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id MAA24226; Tue, 19 Aug 1997 12:49:43 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 3015982 for TN3270E@LIST.NIH.GOV; Tue, 19 Aug 1997 12:49:40 -0400 Received: from tai.cisco.com (tai.cisco.com [171.69.160.33]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id MAA24213 for ; Tue, 19 Aug 1997 12:49:38 -0400 (EDT) Received: from mboe-pc.cisco.com (is-as5200-44.cisco.com [171.68.11.186]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id MAA27808 for ; Tue, 19 Aug 1997 12:49:03 -0400 (EDT) Date: Wed, 20 Aug 1997 09:41:02 -0500 (Central Daylight Time) From: Michael Boe Reply-To: Michael Boe Subject: Minutes from the Munich IETF meeting To: tn3270e@list.nih.gov Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by list.nih.gov id MAA24214 Sender: owner-tn3270e@list.nih.gov Minutes of the Telnet TN3270E Enhancements (tn3270e) Working Group Reported by: Ed Bailey I.Summary: The tn3270e Enhancements Working Group conducted two 1-hour sessions on Tuesday 8/12/97 at 3:45 p.m. and 5:00 p.m. with approximately 12 people in attendance. The 3:45pm session opened with a brief discussion of the charter, activity on the listsrv, and use of the IETF web pages. The results of the most recent interoperability testing held in May at Cisco Systems were reviewed along with WG plans for the next interoperability testing. The submission of the tn3270e Internet Draft to the IESG for Draft status was proposed with no objections. Then, discussion proceeded to the activities currently underway on the use of TLS and IPSEC for security for the remainder of the first session. The 5:00pm session was devoted to the review of the Internet drafts for tn3270e management and Response Time MIBs. A number of suggested changes were identified which will be added to the drafts and reposted as updates on the listsrv. II. Detail (first hour session): The charter will be updated to reflect the progress of the working group. In particular, the update will address the rewrite of rfc1647 into the tn3270e internet draft, its last call in the working group and submission to the IESG for draft status. Based upon the second inter-operability testing which included 11 organizations and representing an array of client and server implementations, the working group is confident that consistent interpretations are possible with the latest internet draft and is ready for draft status. The WG Chair will work with the Area Directors on the IESG submission. The next interoperability testing is planned for October, 1997. The exact date and location will be posted on the list in the following weeks after Munich. More emphasis on printing and tn5250 is anticipated. A number of enhancements are being discussed in the working group (see minutes of Memphis 97). In particular, security, and network management are at the forefront. Demand for tn3270 security is high. SSL3 has no reference spec yet TLS and IPSEC may not be ready soon enough for us. In light of current IETF activities on TLS and IPSEC, the working group will implement security negotiations based upon TLS with the ability to "fall back" to SSL3.0 which should suffice initially. Most new implementation will be on SSL3.1 (TLS). General deployment of SSL3.0 in corporate networks will pressure implementations to use it for tn3270 as well. The wg decided to separate the base telnet security need into a separate document. Michael Boe will be publishing this document. Some of the other comments and observations are as follows. There are existing challenge/response mechanisms in place for most of the tn3270/tn5250 applications. The use of encryption is used to protect passwords from flowing in the clear but is has too high overhead to encrypt all the traffic. More discussion on the list is needed to address the use of encryption and certificates. III. Detail (second hour session): Network management of tn3270 sessions requires certain instrumentation in the client and server to allow for seting and getting certain relevant performance and configuration information. The tn3270e base mib and the tn3270e rt mib are intended to specify the minimum instrumentation for managing tn3270e connections. Although fairly complete, review of these two draft documents led to a number of changes to enhance the implementation and understanding of the information. A revision will be made and posted on the list for review in the next 30 days following Munich. Most changes evolved the use of the ipaddr and port numbers for better granularity, additional information in base, and positioning with the application mib. The revised drafts will identify the individual changes. Some additional comments included ipv6 naming, use of timingmarks, and consistency with SNAMS response time management. An informational rfc will be produced to note the rationale for the mib variables and how they can be used.   Received: from ietf.org by ietf.org id aa07514; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06636; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: tn3270e@list.nih.gov Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-tn3270e-tn3270-mib-02.txt Date: Fri, 29 Aug 1997 09:56:08 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06636@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telnet TN3270 Enhancements Working Group of the IETF. Title : Base Definitions of Managed Objects for TN3270E Using SMIv2 Author(s) : K. White Filename : draft-ietf-tn3270e-tn3270-mib-02.txt Pages : 29 Date : 1997-08-28 The purpose of this memo is to define a Management Information Base (MIB) for configuring and managing TN3270E Servers. The MIB defined by this memo is intended to provide generic support for both Host and Gateway TN3270E Server implementations. It is the intent that the MIB defined herein be extended by subsequent memos to provide non-generic configuration support and to enable TN3270E Response Time Collection. It is the intent of this MIB to fully adhere to all prerequisite MIBs unless explicitly stated. Deviations will be documented in corresponding conformance statements. The specification of this MIB will utilize the Structure of Management Information (SMI) for Version 2 of the Simple Network Management Protocol Version (refer to RFC1902, reference [1]). Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tn3270e-tn3270-mib-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-tn3270e-tn3270-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-tn3270e-tn3270-mib-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828133553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tn3270e-tn3270-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tn3270e-tn3270-mib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828133553.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa12783; 29 Aug 97 14:26 EDT Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA17579 for ; Fri, 29 Aug 1997 14:29:39 -0400 (EDT) Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.8.5/8.8.5) with ESMTP id OAA11810; Fri, 29 Aug 1997 14:20:55 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8c) with spool id 3062748 for TN3270E@LIST.NIH.GOV; Fri, 29 Aug 1997 14:20:52 -0400 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by list.nih.gov (8.8.5/8.8.5) with SMTP id OAA11491 for ; Fri, 29 Aug 1997 14:10:51 -0400 (EDT) Received: from d04lms03.raleigh.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA26264; Fri, 29 Aug 1997 18:14:52 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU035 id 5040300004944768; Fri, 29 Aug 1997 14:10:57 -0400 From: Kenneth White To: tn3270e@list.nih.gov MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Message-Id: <5040300004944768000002L082*@MHS> Date: Fri, 29 Aug 1997 14:10:57 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tn3270e@list.nih.gov The recent reposting of this MIB was done to fix some pointer errors to the MIB from the IETF home pages and wasn't done to announce a new version of the MIB. I'm in the process of updating the TN3270E-MIB and the TN3270E-RT-MIB based on the comments that were made to the list as well as at the working group meeting in Munich. I plan to post the next version of the TN3270E-MIB in a few days and the TN3270E-RT-MIB next week, Ken