Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14464; 1 Nov 94 19:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14460; 1 Nov 94 19:12 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19815; 1 Nov 94 19:12 EST Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id SAA20539 for ; Tue, 1 Nov 1994 18:36:26 -0500 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA12000; Tue, 1 Nov 1994 18:28:58 -0500 Received: from by eve (4.1/4.7) id AB03129; Tue, 1 Nov 94 18:40:01 EST Date: Tue, 1 Nov 94 18:40:01 EST X-Station-Sent-From: eve.bellcore.com Message-Id: <9411012340.AB03129@eve> X-Sender: kaj@eve.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: TEST -- IGNORE _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15495; 1 Nov 94 20:38 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15491; 1 Nov 94 20:38 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa25521; 1 Nov 94 20:38 EST Received: from rome (rome.raynet.com [153.88.1.17]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id UAA26084 for ; Tue, 1 Nov 1994 20:04:09 -0500 Received: from by rome (8.6.9/SMI-4.1) id RAA25434; Tue, 1 Nov 1994 17:07:37 -0800 Received: from rook.raynet.com by (4.1/SMI-4.1) id AA18099; Tue, 1 Nov 94 17:03:10 PST Date: Tue, 1 Nov 94 17:03:10 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ed Barrett Message-Id: <9411020103.AA18099@> To: kaj@eve.bellcore.com Subject: Re: Returned mail: unknown mailer error 12 Cc: atommib@thumper.bellcore.com Hi, Greg Bernstein no longer works here. I do not have any forwarding address available. If this is a mailing list please remove gbernste@lima.raynet.com. Thanks, Ed > From Mailer-Daemon@lima Tue Nov 1 16:56:44 1994 > Return-Path: > Received: from lima.raynet.com by (4.1/SMI-4.1) > id AA18073; Tue, 1 Nov 94 16:56:44 PST > Received: by lima.raynet.com (5.0/SMI-SVR4) > id AA02353; Tue, 1 Nov 1994 16:56:12 +0800 > Date: Tue, 1 Nov 1994 16:56:12 +0800 > From: Mailer-Daemon@lima (Mail Delivery Subsystem) > Subject: Returned mail: unknown mailer error 12 > Message-Id: <9411020056.AA02353@lima.raynet.com> > To: Postmaster@lima > Content-Length: 1225 > X-Lines: 28 > Status: RO > > ----- Transcript of session follows ----- > mail: /var/mail/gbernste > mail: Can't open '/tmp/mailAAAa000_m' type: r+ > mail: Cannot create dead.letter > 554 ... unknown mailer error 12 > > ----- Message header follows ----- > Return-Path: > Received: from rome (rome0) by lima.raynet.com (5.0/SMI-SVR4) > id AA02351; Tue, 1 Nov 1994 16:56:12 +0800 > Errors-To: > Received: from thumper.bellcore.com by rome (8.6.9/SMI-4.1) > id RAA25402; Tue, 1 Nov 1994 17:00:37 -0800 > Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id SAA20539 for ; Tue, 1 Nov 1994 18:36:26 -0500 > Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) > id AA12000; Tue, 1 Nov 1994 18:28:58 -0500 > Received: from by eve (4.1/4.7) > id AB03129; Tue, 1 Nov 94 18:40:01 EST > Date: Tue, 1 Nov 94 18:40:01 EST > X-Station-Sent-From: eve.bellcore.com > Message-Id: <9411012340.AB03129@eve> > X-Sender: kaj@eve.bellcore.com > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > To: atommib@thumper.bellcore.com > From: kaj@cc.bellcore.com (Kaj Tesink) > Subject: TEST -- IGNORE > content-length: 680 >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08078; 8 Nov 94 15:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08074; 8 Nov 94 15:50 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa17997; 8 Nov 94 15:50 EST Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id PAA27646 for ; Tue, 8 Nov 1994 15:02:10 -0500 Received: from nacto1.nacto.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA10006; Tue, 8 Nov 94 11:56:23 -0800 Received: from alex.nacto.lkg.dec.com by nacto1.nacto.lkg.dec.com with SMTP id AA25639; Tue, 8 Nov 1994 14:56:20 -0500 Received: by alex.nacto.lkg.dec.com (5.65/4.7) id AA11161; Tue, 8 Nov 1994 14:56:19 -0500 Message-Id: <9411081956.AA11161@alex.nacto.lkg.dec.com> To: atommib@thumper.bellcore.com Subject: atmInterfaceMyNeighborIpAddress Date: Tue, 08 Nov 94 14:56:18 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Aleksey Y. Romanov" Hi, atmInterfaceMyNeighborIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP address of the neighbor system connected to the far end of this interface, to which a Network Management Station can send SNMP messages, as IP datagrams sent to UDP port 161, in order to access network management information concerning the operation of that system. Note that the value of this object may be obtained in different ways, e.g., by manual configuration, or through ILMI interaction with the neighbor system." ::= { atmInterfaceConfEntry 11 } What shoube a value for this object if neighbor does not support IP, does not support SNMP or this value is not detected yet (e.g. because link is down) ? My idea is 0.0.0.0. Opinions ? Aleksey   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08814; 8 Nov 94 16:39 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08809; 8 Nov 94 16:39 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19195; 8 Nov 94 16:39 EST Received: from fore.com (relay.fore.com [192.88.243.14]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id PAA04382 for ; Tue, 8 Nov 1994 15:58:30 -0500 Received: from dolphin.fore.com (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id PAA10316; Tue, 8 Nov 1994 15:40:41 -0500 Received: from loach.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA25312; Tue, 8 Nov 94 15:41:13 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Received: by loach.fore.com (4.1/SMI-4.1) id AA11525; Tue, 8 Nov 94 15:40:28 EST Date: Tue, 8 Nov 94 15:40:28 EST Message-Id: <9411082040.AA11525@loach.fore.com> To: atommib@thumper.bellcore.com, romanov@nacto.lkg.dec.com Subject: Re: atmInterfaceMyNeighborIpAddress I would say noSuchName. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com > atmInterfaceMyNeighborIpAddress OBJECT-TYPE > SYNTAX IpAddress > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The IP address of the neighbor system connected to > the far end of this interface, to which a Network > Management Station can send SNMP messages, as IP > datagrams sent to UDP port 161, in order to access > network management information concerning the > operation of that system. Note that the value > of this object may be obtained in different ways, > e.g., by manual configuration, or through ILMI > interaction with the neighbor system." > ::= { atmInterfaceConfEntry 11 } > > What shoube a value for this object if neighbor does not support > IP, does not support SNMP or this value is not detected yet (e.g. > because link is down) ? > > My idea is 0.0.0.0. > > Opinions ? > > Aleksey > > > > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05365; 13 Nov 94 22:02 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05361; 13 Nov 94 22:02 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14366; 13 Nov 94 22:02 EST Received: from jack.cisco.com (jack.cisco.com [171.69.1.139]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id VAA26483 for ; Sun, 13 Nov 1994 21:24:41 -0500 Received: (kzm@localhost) by jack.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA03743; Sun, 13 Nov 1994 18:23:59 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <199411140223.SAA03743@jack.cisco.com> Subject: Re: atmInterfaceMyNeighborIpAddress To: Drew Perkins Date: Sun, 13 Nov 94 18:23:59 PST Cc: atommib@thumper.bellcore.com, romanov@nacto.lkg.dec.com In-Reply-To: <9411082040.AA11525@loach.fore.com>; from "Drew Perkins" at Nov 8, 94 3:40 pm X-Mailer: ELM [version 2.3 PL11] I think Aleksey's suggestion of 0.0.0.0 is better than noSuchName since it allows the NMS to distinguish between the situations where the agent doesn't support this object, and the value is not obtainable via the ILMI. Keith. > I would say noSuchName. > > Drew > > > atmInterfaceMyNeighborIpAddress OBJECT-TYPE > > SYNTAX IpAddress > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The IP address of the neighbor system connected to > > the far end of this interface, to which a Network > > Management Station can send SNMP messages, as IP > > datagrams sent to UDP port 161, in order to access > > network management information concerning the > > operation of that system. Note that the value > > of this object may be obtained in different ways, > > e.g., by manual configuration, or through ILMI > > interaction with the neighbor system." > > ::= { atmInterfaceConfEntry 11 } > > > > What shoube a value for this object if neighbor does not support > > IP, does not support SNMP or this value is not detected yet (e.g. > > because link is down) ? > > > > My idea is 0.0.0.0. > > > > Opinions ? > > > > Aleksey >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06110; 14 Nov 94 12:42 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06106; 14 Nov 94 12:42 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10709; 14 Nov 94 12:42 EST Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id LAA15795 for ; Mon, 14 Nov 1994 11:56:35 -0500 Received: from nacto1.nacto.lkg.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA13368; Mon, 14 Nov 94 08:37:14 -0800 Received: from alex.nacto.lkg.dec.com by nacto1.nacto.lkg.dec.com with SMTP id AA14466; Mon, 14 Nov 1994 11:37:01 -0500 Received: by alex.nacto.lkg.dec.com (5.65/4.7) id AA17145; Mon, 14 Nov 1994 11:36:58 -0500 Message-Id: <9411141636.AA17145@alex.nacto.lkg.dec.com> To: Keith McCloghrie Subject: Re: atmInterfaceMyNeighborIpAddress Cc: atommib@thumper.bellcore.com, ddp@fore.com Date: Mon, 14 Nov 94 11:36:56 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Aleksey Y. Romanov" > I think Aleksey's suggestion of 0.0.0.0 is better than noSuchName > since it allows the NMS to distinguish between the situations > where the agent doesn't support this object, and the value is not > obtainable via the ILMI. > > Keith. > > > I would say noSuchName. It could not be noSuchName because atmInterfaceMyNeighborIpAddress is mandatory part of atmInterfaceConfGroup. > > Drew Aleksey   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10435; 16 Nov 94 16:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10431; 16 Nov 94 16:50 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18244; 16 Nov 94 16:50 EST Received: from fore.com (relay.fore.com [192.88.243.14]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id QAA04329 for ; Wed, 16 Nov 1994 16:05:12 -0500 Received: from dolphin.fore.com (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id QAA04675 for ; Wed, 16 Nov 1994 16:05:08 -0500 Received: by dolphin.fore.com (4.1/SMI-4.1) id AA01939; Wed, 16 Nov 94 16:05:09 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Atommib Newsgroup Message-Id: <9411162105.AA01939@dolphin.fore.com> Subject: subscribe atommib@fore.com To: atommib@thumper.bellcore.com Date: Wed, 16 Nov 1994 16:05:08 -0500 (EST) Cc: "Steve M. Kilby" Content-Type: text Content-Length: 27 subscribe atommib@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23026; 17 Nov 94 1:28 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23022; 17 Nov 94 1:28 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa28449; 17 Nov 94 1:28 EST Received: from theseus.fibronics.co.il (theseus.fibronics.co.il [192.114.69.30]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id AAA11238 for ; Thu, 17 Nov 1994 00:54:28 -0500 Received: by theseus.fibronics.co.il id AA02772 (5.65c/IDA-1.4.4 for atommib@thumper.bellcore.com); Thu, 17 Nov 1994 07:48:58 +0200 Date: Thu, 17 Nov 1994 07:48:58 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ester Solel Message-Id: <199411170548.AA02772@theseus.fibronics.co.il> To: atommib@thumper.bellcore.com Subject: subscribe atommib@fore.com subscribe atommib@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06302; 22 Nov 94 11:51 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06295; 22 Nov 94 11:51 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09570; 22 Nov 94 11:51 EST Received: from gw1.att.com (gw1.att.com [192.20.239.133]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id LAA29248 for ; Tue, 22 Nov 1994 11:03:10 -0500 Received: from mare.UUCP by ig1.att.att.com id AA19678; Tue, 22 Nov 94 10:42:36 EST Message-Id: <9411221542.AA19678@ig1.att.att.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "g.sundararaman" Date: 22 Nov 94 15:29:00 GMT Original-From: mare!guru (g.sundararaman) To: atommib-request@fore.com, atommib@thumper.bellcore.com Subject: Please unsubscribe Please unsubscribe guru@mare.att.com guru@garage.att.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01013; 24 Nov 94 7:36 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01009; 24 Nov 94 7:36 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03549; 24 Nov 94 7:36 EST Received: from ks3.haninge.trab.se (ks3.haninge.trab.se [131.115.49.96]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id GAA25348 for ; Thu, 24 Nov 1994 06:44:50 -0500 Received: from yankees.haninge.trab.se by ks3.haninge.trab.se with SMTP id AA25188 (5.65c8+/IDA-1.4.4 for ); Thu, 24 Nov 1994 12:53:13 +0100 Received: from redsox.haninge.trab.se by yankees.haninge.trab.se (4.1/SMI-4.1) id AA05999; Thu, 24 Nov 94 12:44:38 +0100 Date: Thu, 24 Nov 94 12:44:38 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Kim.Laraqui" Message-Id: <9411241144.AA05999@yankees.haninge.trab.se> To: atommib@thumper.bellcore.com Subject: Three questions on RFC1695 is the ifPhysAddress (in the ifTable for ifType=37,ATM) always equivalent to an E164 address? Has anyone thought of using RFC1695/M3 for network management (after additional definitions to accomodate for this in the MIB, e.g. to allow the use of shadow ifEntry in one M3-agent which would actually be managed by another M3 agent)? Is there a NM-strategy from the part of IETF for ATM networks? It seems to me that by starting to standardize network management from the ATM UNI, which gave SNMP advantages since customers expect SNMP, SNMP has slowly started to penetrate into management systems well beyond the UNI (e.g. through ILMI, which I quess will be used also for BICI and BISSI. Some public network operators in Europe will be very surprised). If we assume that ATM becomes a key data/telecom network for the next decades, and that the ATM Forum IS the marketplace, then we may end up having SNMP for Telecom as well as datacom network management all over the place. We're not talking about management of the odd IP-router in a public network but of the basic elements of you ATM backbone! The SNMP UNI offensive does not seem to be balanced by a CMIP BICI one. Is this something the IETF would encourage? I'm not so sure about that... Cheers /kim ----------------------- (Mr.) KIM LARAQUI TELIA RESEARCH S-13680 HANINGE SWEDEN PHONE: +46.8.7075568 FAX: +46.8.7075480 -----------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10212; 28 Nov 94 15:28 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10207; 28 Nov 94 15:28 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14001; 28 Nov 94 15:28 EST Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id OAA05447 for ; Mon, 28 Nov 1994 14:39:25 -0500 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA18987; Mon, 28 Nov 1994 14:31:42 -0500 Received: from [128.96.82.154] (nv-ktesink.cc.bellcore.com) by eve (4.1/4.7) id AA13194; Mon, 28 Nov 94 14:43:04 EST Date: Mon, 28 Nov 94 14:43:02 EST X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Kim.Laraqui" , atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: Three questions on RFC1695 At 11:44 AM 11/24/94, Kim.Laraqui wrote: >is the ifPhysAddress (in the ifTable for ifType=37,ATM) always >equivalent to an E164 address? no, not always; see p.9, sec.6.2.1 of 1695 > >Has anyone thought of using RFC1695/M3 for network management (after >additional definitions to accomodate for this in the MIB, e.g. to allow >the use of shadow ifEntry in one M3-agent which would actually be >managed by another M3 agent)? not sure what you mean here; is this a proxy scenario? note also that 1695 has been written as a general purpose mib for atm interfaces, not specifically for M3. however, as the ATMForum has demonstrated, it can successfully be used for the purpose of M3. > >Is there a NM-strategy from the part of IETF for ATM networks? It seems >to me that by starting to standardize network management from the ATM >UNI, which gave SNMP advantages since customers expect SNMP, SNMP has >slowly started to penetrate into management systems well beyond the UNI >(e.g. through ILMI, which I quess will be used also for BICI and >BISSI. Some public network operators in Europe will be very >surprised). > >If we assume that ATM becomes a key data/telecom network for the next >decades, and that the ATM Forum IS the marketplace, then we may end up >having SNMP for Telecom as well as datacom network management all over >the place. We're not talking about management of the odd IP-router in a >public network but of the basic elements of you ATM backbone! The SNMP UNI >offensive does not seem to be balanced by a CMIP BICI one. Is this >something the IETF would encourage? I'm not so sure about that... so what's the question or proposal? note that the IETF is and should not be interested in offensives and protocol wars. in the case of the ATM MIB the IETF has simply published an SNMP based MIB to be used by those folks who elect to use it. a good number of people seem to be implementing it. this doesnt preclude folks to use other protocols. kaj _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00605; 29 Nov 94 5:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00601; 29 Nov 94 5:14 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01842; 29 Nov 94 5:14 EST Received: from mucc.mahidol.ac.th (mucc.mahidol.ac.th [202.14.162.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id EAA28257 for ; Tue, 29 Nov 1994 04:36:34 -0500 Received: by mucc.mahidol.ac.th (5.4R3.10/200.1.1.4) id AA20320; Tue, 29 Nov 1994 16:31:32 +0700 Date: Tue, 29 Nov 1994 16:31:32 +0700 (GMT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Prachya Yodprasit - SCCS - 3737107 To: atommib@thumper.bellcore.com Subject: subscribe AToM MIB Working Group Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe ATM g3737107@mucc.mahidol.ac.th   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02199; 29 Nov 94 9:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02194; 29 Nov 94 9:11 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05427; 29 Nov 94 9:11 EST Received: from zeus.fibronics.co.il (zeus.fibronics.co.il [192.114.69.2]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id IAA09501 for ; Tue, 29 Nov 1994 08:18:07 -0500 Received: by zeus.fibronics.co.il id AA10755 (5.65c/IDA-1.4.4 for atommib@thumper.bellcore.com); Tue, 29 Nov 1994 15:11:24 +0200 Date: Tue, 29 Nov 1994 15:11:24 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ester Solel Message-Id: <199411291311.AA10755@zeus.fibronics.co.il> To: atommib@thumper.bellcore.com Subject: subscribe subscribe ATM ester@fibronics.co.il   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02416; 29 Nov 94 9:34 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02410; 29 Nov 94 9:34 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05879; 29 Nov 94 9:34 EST Received: from fore.com (relay.fore.com [192.88.243.14]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id IAA11892 for ; Tue, 29 Nov 1994 08:57:24 -0500 Received: from dolphin.fore.com (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id SAA04856 for ; Mon, 28 Nov 1994 18:46:28 -0500 Received: from loach.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA12662; Mon, 28 Nov 94 18:41:22 EST Received: from localhost by loach.fore.com (4.1/SMI-4.1) id AA19659; Mon, 28 Nov 94 18:34:42 EST Message-Id: <9411282334.AA19659@loach.fore.com> To: atommib@thumper.bellcore.com Cc: rns@fore.com Subject: Some questions Date: Mon, 28 Nov 1994 18:34:42 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Sidebotham Hi. I'm new to this group, and I have a couple of questions with regard to terminating VPL's and VCL's as represented in the ATM MIB: 1. In the discussion of the VPL Table, RFC 1695 states that "if the VPL terminates a VPC in the ATM host or switch, the manager turns on the atmVplAdminStatus to up(1) to turn the VPL traffic flow on." As I interpret this, no traffic should flow on related VCLs (i.e. with the same value of vpi as the VPL entry) if atmVplAdminStatus is set to "down", because a VPC being terminated in switch simply means that, although the path is ended, individual channels may still be routed by the switch. But what if there is no VPL entry at all, or the atmVplAdminStatus is not instantiated? Can a VCL entry be created without a corresponding VPL entry? Other than the snippet, above, I can't find anything that might require this. 2. In the discussion of the VCL Table, the RFC states that "if the VCL terminates a VCC in the ATM host or switch, the manager turns on the atmVclAdminStatus to up(1) to turn the VCL traffic flow on." One way to terminate a VCC in a switch would be to instantiate two VCL's, one representing a channel on an external port, one a channel on the "other side" of the internal "Proprietary Virtual Interface" (as discussed in section 8.4). These are then cross-connected and the appropriate VCL is created for the "Proprietary Virtual Interface" and turned "on". Cells are then routed via the cross-connect to the switch control port and read via the virtual interface. Unfortunately, there is no explicit information available to the manager relating the control port and its alter ego, the "Proprietary Virtual Interface". Do I have the right model here? I have some more questions, but I think I'll reserve them until I've seen the responses to these! Thanks, Bob Sidebotham FORE Systems rns@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02474; 29 Nov 94 9:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02470; 29 Nov 94 9:37 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05947; 29 Nov 94 9:37 EST Received: from fore.com (relay.fore.com [192.88.243.14]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id IAA11897 for ; Tue, 29 Nov 1994 08:57:27 -0500 Received: from dolphin.fore.com (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id SAA04863 for ; Mon, 28 Nov 1994 18:48:06 -0500 Received: from loach.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA12797; Mon, 28 Nov 94 18:44:30 EST Received: from localhost by loach.fore.com (4.1/SMI-4.1) id AA20367; Mon, 28 Nov 94 18:42:21 EST Message-Id: <9411282342.AA20367@loach.fore.com> To: atommib@thumper.bellcore.com Cc: rns@fore.com Subject: Some questions Date: Mon, 28 Nov 1994 18:42:21 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Sidebotham Hi. I'm new to this group, and I have a couple of questions with regard to terminating VPL's and VCL's as represented in the ATM MIB: 1. In the discussion of the VPL Table, RFC 1695 states that "if the VPL terminates a VPC in the ATM host or switch, the manager turns on the atmVplAdminStatus to up(1) to turn the VPL traffic flow on." As I interpret this, no traffic should flow on related VCLs (i.e. with the same value of vpi as the VPL entry) if atmVplAdminStatus is set to "down", because a VPC being terminated in switch simply means that, although the path is ended, individual channels may still be routed by the switch. But what if there is no VPL entry at all, or the atmVplAdminStatus is not instantiated? Can a VCL entry be created without a corresponding VPL entry? Other than the snippet, above, I can't find anything that might require this. 2. In the discussion of the VCL Table, the RFC states that "if the VCL terminates a VCC in the ATM host or switch, the manager turns on the atmVclAdminStatus to up(1) to turn the VCL traffic flow on." One way to terminate a VCC in a switch would be to instantiate two VCL's, one representing a channel on an external port, one a channel on the "other side" of the internal "Proprietary Virtual Interface" (as discussed in section 8.4). These are then cross-connected and the appropriate VCL is created for the "Proprietary Virtual Interface" and turned "on". Cells are then routed via the cross-connect to the switch control port and read via the virtual interface. Unfortunately, there is no explicit information available to the manager relating the control port and its alter ego, the "Proprietary Virtual Interface". Do I have the right model here? I have some more questions, but I think I'll reserve them until I've seen the responses to these! Thanks, Bob Sidebotham FORE Systems rns@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07842; 29 Nov 94 14:16 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07838; 29 Nov 94 14:16 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12408; 29 Nov 94 14:16 EST Received: from ctron.com (ctron.com [134.141.197.25]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id NAA10333 for ; Tue, 29 Nov 1994 13:25:07 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: clark@ccmailpc.ctron.com Received: from stealth.ctron.com by ctron.com (4.1/SMI-4.1) id AA08600; Tue, 29 Nov 94 13:25:05 EST Received: from ccmailpc.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA19256; Tue, 29 Nov 94 13:24:46 EST Received: from ccMail by ccmailpc.ctron.com id AA786144171 Tue, 29 Nov 94 13:22:51 EST Date: Tue, 29 Nov 94 13:22:51 EST Encoding: 29 Text Message-Id: <9410297861.AA786144171@ccmailpc.ctron.com> To: atommib@thumper.bellcore.com Subject: unsubscribe unsubscribe clark@ctron.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09726; 29 Nov 94 15:23 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09722; 29 Nov 94 15:22 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14206; 29 Nov 94 15:22 EST Received: from fore.com (relay.fore.com [192.88.243.14]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id OAA16443 for ; Tue, 29 Nov 1994 14:33:20 -0500 Received: from dolphin.fore.com (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id OAA03426 for ; Tue, 29 Nov 1994 14:33:05 -0500 Received: from loach.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA24930; Tue, 29 Nov 94 14:33:11 EST Received: from loach by loach.fore.com (4.1/SMI-4.1) id AA08256; Tue, 29 Nov 94 14:31:01 EST Message-Id: <9411291931.AA08256@loach.fore.com> To: atommib@thumper.bellcore.com Cc: rns@fore.com Subject: createAndGo Date: Tue, 29 Nov 1994 14:31:00 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Sidebotham Another puzzle: The ATM MIB specification goes to some pains to describe row creation for several of the tables, and includes references in these cases to the "createAndGo" operation specified in RFC 1443 (Textual Conventions for SNMPV2). For other tables, however, no mention is made of "createAndGo", and it's left to the reader to lookup the definition of "RowStatus" in RFC 1443. The reason I ask is because, in the interests of simplicity and correctness of operation, I would prefer to leave out the createAndGo semantics altogether. My reading of RFC1443 indicates that I have the right to do this, while still being compliant with that RFC. Unfortunately, for all the detail of the specification, this RFC is not very helpful. It says (RFC 1443, p15): "The management station issues a management protocol set operation which sets the desired instance of the status column to 'createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of 'wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.)" This seems, indirectly, to give license to *not* implement the "createAndGo" operation. Further evidence is supplied by Stalling's SNMP* book, p289: "Both options are available and an agent implementor may decide which option to support for each table." (This actually seems a broader conclusion than I would make--it puts the onus on the management station to support *both* styles of row creation). My conclusion is that for the tables in ATM MIB for which the creation method is not specified, that it's OK to implement just the "createAndWait" method. For the tables where both methods are specified, I'm puzzled, since RFC 1443 basically makes this an *agent* responsibility, but RFC 1695 specifies it. Any insights on this? If "createAndGo" is not implemented for any tables in ATM MIB, is the implementation in conformance with RFC 1695? An alternative question is: is RFC1695 in conformance with RFC1443 by specifying both types of row creation? Sorry for the nit-picking, but these details do make the difference! Thanks, Bob Sidebotham rns@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12951; 29 Nov 94 17:03 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12947; 29 Nov 94 17:03 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16999; 29 Nov 94 17:03 EST Received: from faline.bellcore.com (faline.bellcore.com [128.96.39.9]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id QAA26339 for ; Tue, 29 Nov 1994 16:15:33 -0500 Received: from fore.com (relay.fore.com [192.88.243.14]) by faline.bellcore.com (8.6.9/8.6.9) with ESMTP id QAA01297 for ; Tue, 29 Nov 1994 16:15:29 -0500 Received: from dolphin.fore.com (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id QAA04037 for ; Tue, 29 Nov 1994 16:10:19 -0500 Received: from loach.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA29782; Tue, 29 Nov 94 16:10:25 EST Received: from loach by loach.fore.com (4.1/SMI-4.1) id AA14044; Tue, 29 Nov 94 16:08:15 EST Message-Id: <9411292108.AA14044@loach.fore.com> To: atommib@thumper.bellcore.com Cc: rns@fore.com Subject: Modifying a row Date: Tue, 29 Nov 1994 16:08:14 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Sidebotham This is another nit, perhaps. The intent of ATM MIB with respect to modification of rows is unclear. Let's take, for example, the ATM Traffic Descriptor Parameter Table. In the introductory comments for this table, it is stated that: -- A row in the atmTrafficDescrParamable is deleted -- by setting the atmTrafficDescrRowStatus to destroy(6). -- The agent will check whether this row is still in use -- by any entry of the atmVplTable or atmVclTable. -- The agent denies the request if the row is still in -- use. Under the DESCRIPTION of atmTrafficDescrRowStatus, it is stated that: "This object is used to create a new row or modify or delete an existing row in this table." Note that the DESCRIPTION provides for both modification *and* deletion, but the introductory comments only talk about deletion. Now in RFC 1443, it is stated under a "NOTE WELL", that: "This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must be 'notInService' in order for the value of some other column of the same conceptual row to be modified." Clearly, the DESCRIPTION clause, above, does not comply with this requirement. Anyway, apart from the legalistic interpretation of the MIB, can anyone tell me whether the intention is that the QOS parameters associated with VPL's or VCL's could really be modified en masse, just by changing a single row of this table? And if they are, can this table be modified (1) by just modifying an entry, or (2) by setting the status value to 'notInService' and then modifying the entry? If the latter, under what circumstances can the status be changed to 'notInService'? That is, are there similar constraints to the constraints mentioned in the comment section for deleting a row? I suspect there are similar questions that can be asked about other tables in the MIB. Comments? Bob Sidebotham FORE Systems rns@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13903; 29 Nov 94 17:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13899; 29 Nov 94 17:54 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18074; 29 Nov 94 17:54 EST Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id RAA01575 for ; Tue, 29 Nov 1994 17:08:32 -0500 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA23544; Tue, 29 Nov 1994 17:00:51 -0500 Received: from by eve (4.1/4.7) id AB21431; Tue, 29 Nov 94 17:12:12 EST Date: Tue, 29 Nov 94 17:12:12 EST X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bob Sidebotham , atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: createAndGo Cc: rns@fore.com At 7:30 PM 11/29/94, Bob Sidebotham wrote: >Another puzzle: > >The ATM MIB specification goes to some pains to describe row creation >for several of the tables, and includes references in these cases to >the "createAndGo" operation specified in RFC 1443 (Textual Conventions >for SNMPV2). For other tables, however, no mention is made of >"createAndGo", and it's left to the reader to lookup the definition of >"RowStatus" in RFC 1443. > >The reason I ask is because, in the interests of simplicity and >correctness of operation, I would prefer to leave out the createAndGo >semantics altogether. My reading of RFC1443 indicates that I have the >right to do this, while still being compliant with that >RFC. Unfortunately, for all the detail of the specification, this RFC >is not very helpful. It says (RFC 1443, p15): > > "The management station issues a management protocol set operation > which sets the desired instance of the status column to > 'createAndWait'. If the agent is unwilling to process a request of > this sort, the set operation fails with an error of 'wrongValue'. (As > a consequence, such an agent must be prepared to accept a single > management protocol set operation, i.e., interaction 2a above, > containing all of the columns indicated by its column requirements.)" > >This seems, indirectly, to give license to *not* implement the >"createAndGo" operation. Further evidence is supplied by Stalling's >SNMP* book, p289: > > "Both options are available and an agent implementor may decide which > option to support for each table." my observation would be that the conformance statement is the ultimate judge on what should be supported. that answer may not be very satisfactory though. so there is also an issue of "what makes sense". the "either", "or" scenario that you paint above may in practice not really apply since if an agent can handle the complexity of the negotiated approach, it can likely also handle the one-shot approach. > >(This actually seems a broader conclusion than I would make--it puts >the onus on the management station to support *both* styles of row >creation). > >My conclusion is that for the tables in ATM MIB for which the creation >method is not specified, that it's OK to implement just the "createAndWait" >method. For the tables where both methods are specified, I'm puzzled, since >RFC 1443 basically makes this an *agent* responsibility, but RFC 1695 >specifies it. my reading is that by specifying both methods 1695 allows agent implementors to choose whether to support just the one-shot or also the negotiated approach. you may also notice that 1695 points out a preference for the negotiated approach (e.g., top of p.35). > >Any insights on this? If "createAndGo" is not implemented for any >tables in ATM MIB, is the implementation in conformance with RFC 1695? >An alternative question is: is RFC1695 in conformance with RFC1443 by >specifying both types of row creation? > >Sorry for the nit-picking, but these details do make the difference! yes. as has been described in the latest issue of The Simple Times the negotiated approach does have real advantages. so i would recommend to go with that. > >Thanks, >Bob Sidebotham > >rns@fore.com _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13924; 29 Nov 94 17:55 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13920; 29 Nov 94 17:55 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18084; 29 Nov 94 17:55 EST Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id RAA01564 for ; Tue, 29 Nov 1994 17:08:25 -0500 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA23536; Tue, 29 Nov 1994 17:00:44 -0500 Received: from [128.96.82.154] (nv-ktesink.cc.bellcore.com) by eve (4.1/4.7) id AA21431; Tue, 29 Nov 94 17:12:06 EST Date: Tue, 29 Nov 94 17:12:05 EST X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bob Sidebotham , atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: Some questions Cc: rns@fore.com At 11:42 PM 11/28/94, Bob Sidebotham wrote: >Hi. I'm new to this group, and I have a couple of questions with >regard to terminating VPL's and VCL's as represented in the ATM MIB: > >1. In the discussion of the VPL Table, RFC 1695 states that "if the >VPL terminates a VPC in the ATM host or switch, the manager turns on >the atmVplAdminStatus to up(1) to turn the VPL traffic flow on." > >As I interpret this, no traffic should flow on related VCLs (i.e. with >the same value of vpi as the VPL entry) if atmVplAdminStatus is set to >"down", because a VPC being terminated in switch simply means that, >although the path is ended, individual channels may still be routed by >the switch. But what if there is no VPL entry at all, or the >atmVplAdminStatus is not instantiated? Can a VCL entry be created >without a corresponding VPL entry? Other than the snippet, above, I >can't find anything that might require this. it strikes me that an agent should refuse this request since a critical resource (the underlying VPL) is not in place. this is indeed not explicitly spelled out, but consider what alternative there is ... btw you may want to check out the latest issue of the Simple Times which has some more info on the whole procedure. > >2. In the discussion of the VCL Table, the RFC states that "if the VCL >terminates a VCC in the ATM host or switch, the manager turns on the >atmVclAdminStatus to up(1) to turn the VCL traffic flow on." > >One way to terminate a VCC in a switch would be to instantiate two >VCL's, one representing a channel on an external port, one a channel >on the "other side" of the internal "Proprietary Virtual Interface" >(as discussed in section 8.4). These are then cross-connected and the >appropriate VCL is created for the "Proprietary Virtual Interface" and >turned "on". Cells are then routed via the cross-connect to the switch >control port and read via the virtual interface. Unfortunately, there >is no explicit information available to the manager relating the >control port and its alter ego, the "Proprietary Virtual >Interface". Do I have the right model here? i think so. you may also want to read section 8.1 on this. > >I have some more questions, but I think I'll reserve them until I've seen >the responses to these! > >Thanks, >Bob Sidebotham > >FORE Systems >rns@fore.com _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14359; 29 Nov 94 18:19 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14355; 29 Nov 94 18:19 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18822; 29 Nov 94 18:19 EST Received: from fore.com (relay.fore.com [192.88.243.14]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id RAA04476 for ; Tue, 29 Nov 1994 17:45:59 -0500 Received: from dolphin.fore.com (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id RAA04555; Tue, 29 Nov 1994 17:45:43 -0500 Received: from loach.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA05033; Tue, 29 Nov 94 17:45:49 EST Received: from loach by loach.fore.com (4.1/SMI-4.1) id AA25675; Tue, 29 Nov 94 17:43:39 EST Message-Id: <9411292243.AA25675@loach.fore.com> To: Kaj Tesink Cc: atommib@thumper.bellcore.com Subject: Re: createAndGo In-Reply-To: Your message of "Tue, 29 Nov 1994 17:12:12 EST." Date: Tue, 29 Nov 1994 17:43:38 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Sidebotham Kaj Tesink said: >the "either", "or" scenario that you paint above may in practice >not really apply since if an agent can handle the complexity of >the negotiated approach, it can likely also handle the one-shot approach. But there's a difference between "can handle" and "does handle correctly". By my reading, for instance, there's no ordering constraint on the appearance of the row status variable for a "createAndGo" scenario. This means that the agent is required to handle this case correctly whether the "createAndGo" is the first item in the PDU or the last item, or somewhere in the middle. This can obviously be handled using only moderately tricky multi-pass code, but verifying that all cases are handled correctly is another matter, and in my opinion, simply adds more layers of confusion to already confusing SNMP semantics. The equivalent of "createAndGo" could have been provided simply by creating a PDU which sets the row status to "createAndWait" at the beginning and "active" at the end (and specifying that the variables appearing in the PDU are ordered). If the SNMPv2 folks had specified it this way, then agents that supported both methods would have seen no difference between the two methods, whereas an agent that required the row setup to be in one PDU could have been allowed to require that all variables were provided. It comes down to whether the SNMPv2 designers were trying to make it easier for the agent or the manager. If the latter, they haven't succeeded, since they seem to require the manager to know how to do it both ways. I can't tell from any of the documents that I've looked at what the intention was. >my reading is that by specifying both methods 1695 allows agent implementors >to choose whether to support just the one-shot or also the negotiated >approach. you may also notice that 1695 points out a preference for >the negotiated approach (e.g., top of p.35). It does, indeed. What isn't clear from the specification is whether the agent has the option of doing either. In fact, I think there's a strong suggestion that, for certain tables, both methods are supposed to be supported by the agent. I think RFC 1695 should state that this is not required, if that's the intent. Thanks for your comments. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00951; 30 Nov 94 6:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00947; 30 Nov 94 6:11 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02584; 30 Nov 94 6:11 EST Received: from europe.cisco.com (europe.cisco.com [192.135.241.98]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id FAA12087 for ; Wed, 30 Nov 1994 05:35:51 -0500 Received: from [192.190.221.69] ([192.190.221.69]) by europe.cisco.com (8.6.8+c/EURO.FR.1.1) with SMTP id LAA29178 for ; Wed, 30 Nov 1994 11:34:05 +0100 Date: Wed, 30 Nov 1994 11:34:05 +0100 X-Sender: adehmel@munich.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alfred Dehmel Subject: unsubscribe unsubscribe adehmel@cisco.com