InterfaceTable question

2003-10-01 Thread Brookes, Stuart P
Title: Message All, I am new to SNMP and its workings, thus this may seem a very simple question with an obvious answer to the majority of you. But, how often, if ever, should the counters in the InterfaceTable be reset? Are they counters that should never be re-set or should they be

InterfaceTable question

2003-10-01 Thread Brookes, Stuart P
Title: Message All, I am new to SNMP and its workings, thus this may seem a very simple question with an obvious answer to the majority of you. But, how often, if ever, should the counters in the InterfaceTable be reset? Are they counters that should never be re-set or should they be

RE: InterfaceTable question

2003-10-01 Thread Romascanu, Dan (Dan)
Title: Message Stuart, First, this question is more suitable to the MIBs list in the OPS area. Avoid copying all the IETF list for such issues in the future. Specifically, I suggest that you look at section 4.6.1.2 for recommendations on counters reset. Regards, Dan -Original

RE: InterfaceTable question

2003-10-01 Thread Romascanu, Dan (Dan)
Title: Message I forgot to mention the document - http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.txt. -Original Message-From: Romascanu, Dan (Dan) Sent: 01 October, 2003 12:00 PMTo: Brookes, Stuart P; [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject:

cross-pollination (was Re: InterfaceTable question)

2003-10-01 Thread Valdis . Kletnieks
On Wed, 01 Oct 2003 12:04:51 +0300, Romascanu, Dan (Dan) said: http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.txt Specifically, I suggest that you look at section 4.6.1.2 for recommendations on counters reset. Hopefully, that document isn't in violent

Persistent applications-level identifiers, the DNS, and RFC 2428

2003-10-01 Thread John C Klensin
Hi. I just had occasion to look again at RFC 2428, FTP Extensions for IPv6 and NATs, M. Allman, S. Ostermann, C. Metz. September 1998, and to think about in the context of the recent flame-war^H^H^H^H^H^H^H^H^H discussions about use of IP addresses in applications. 2428 provides additional

Re: Persistent applications-level identifiers, the DNS, and RFC 2428

2003-10-01 Thread Keith Moore
John, The extensions in 2428 are in wide use, and they work just fine. I don't see any reason to change them. Nor do I believe there is consensus that applications should always be passing names in preference to IP addresses. And until there is a system for assigning stable names to hosts

Re: Persistent applications-level identifiers, the DNS, and RFC 2428

2003-10-01 Thread John C Klensin
--On Wednesday, 01 October, 2003 14:35 -0400 Keith Moore [EMAIL PROTECTED] wrote: John, The extensions in 2428 are in wide use, and they work just fine. I don't see any reason to change them. Nor do I believe there is consensus that applications should always be passing names in preference to

Re: Persistent applications-level identifiers, the DNS, and RFC 2428

2003-10-01 Thread Keith Moore
Keith, you are starting down the path I was hoping to avoid, so maybe my specific concern and suggestion wasn't clear. If is is working well as is, then I withdraw even the hint of deprecating the thing.My main objection to 2428 is not that it _permits_ addresses, but that it

RE: Persistent applications-level identifiers, the DNS, and RFC 2428

2003-10-01 Thread Michel Py
John, John C Klensin wrote: It seems appropriate to ask whether 2428 should be opened and given at least the capability of passing DNS names and maybe some syntax that would permit clean extension to future identifiers. It seems to me that this does not buy us much if it is limited to FTP.

RE: Persistent applications-level identifiers, the DNS, and RFC 2428

2003-10-01 Thread John C Klensin
--On Wednesday, 01 October, 2003 14:48 -0700 Michel Py [EMAIL PROTECTED] wrote: John, John C Klensin wrote: It seems appropriate to ask whether 2428 should be opened and given at least the capability of passing DNS names and maybe some syntax that would permit clean extension to future

Re: Persistent applications-level identifiers, the DNS, and RFC 2428

2003-10-01 Thread Masataka Ohta
John; I just had occasion to look again at RFC 2428, FTP Extensions for IPv6 and NATs, Please consider this a fairly narrow question. I'm afraid that your question is still too broad. Are you asking the question for IPv6 or for NATs?

Trouble Interpreting RFC 2142

2003-10-01 Thread Sabahattin Gucukoglu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm sure this has been raised before, and have done my fair share of searching - I think - on the matter. Trouble is, I can't seem to interpret RFC 2142 properly and reach a firm conclusion. I've seen variations on the interpretation of

Re: Persistent applications-level identifiers, the DNS, and RFC 2428

2003-10-01 Thread John C Klensin
--On Thursday, 02 October, 2003 09:55 +0859 Masataka Ohta [EMAIL PROTECTED] wrote: John; I just had occasion to look again at RFC 2428, FTP Extensions for IPv6 and NATs, Please consider this a fairly narrow question. I'm afraid that your question is still too broad. Are you asking the

Re: Trouble Interpreting RFC 2142

2003-10-01 Thread Valdis . Kletnieks
On Thu, 02 Oct 2003 02:08:22 BST, Sabahattin Gucukoglu [EMAIL PROTECTED] said: Great. So, while I'm not prevented from inventing fab new mailboxes for the same or even more services, business roles, etc., I'm at least tentatively asked to support the listed mailboxes for services I run,

Re: Trouble Interpreting RFC 2142

2003-10-01 Thread Vernon Schryver
From: [EMAIL PROTECTED] ... I read it as saying We suggest you have aliases from section 3 for appropriate business units, and the service-oriented ones from section 5 are mandatory if you run that service. So if you have a sales division, a mailbox called 'sales' is suggested, but if you

Re: Trouble Interpreting RFC 2142

2003-10-01 Thread Dave Crocker
Sabahattin, SG Part of the abstract runs thus: ... SG encouraged to support AT LEAST each mailbox name for ... SG Then, part of the Rationale says: SG However, if a given service is offerred, then the associated mailbox SG name(es) must be supported, resulting in delivery to a recipient SG