[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIB-DOCTORS] RFC 4001 question
- To: "Romascanu, Dan (Dan)" <dromasca at avaya.com>
- Subject: Re: [MIB-DOCTORS] RFC 4001 question
- From: Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>
- Date: Wed, 26 Aug 2009 10:00:02 +0200
- Cc: "mib-doctors at ietf.org" <mib-doctors at ietf.org>, "Biton, Shlomi \(Shlomi\)" <sbiton at avaya.com>
- Delivered-to: mib-doctors at core3.amsl.com
- In-reply-to: <EDC652A26FB23C4EB6384A4584434A040198476F at 307622ANEX5.global.avaya.com>
- List-archive: <http://www.ietf.org/mail-archive/web/mib-doctors>
- List-help: <mailto:mib-doctors-request@ietf.org?subject=help>
- List-id: MIB Doctors list <mib-doctors.ietf.org>
- List-post: <mailto:mib-doctors@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
- Mail-followup-to: "Romascanu, Dan (Dan)" <dromasca at avaya.com>, "mib-doctors at ietf.org" <mib-doctors at ietf.org>, "Biton, Shlomi (Shlomi)" <sbiton at avaya.com>
- References: <EDC652A26FB23C4EB6384A4584434A040198476F at 307622ANEX5.global.avaya.com>
- Reply-to: Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>
- User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Aug 26, 2009 at 09:48:50AM +0200, Romascanu, Dan (Dan) wrote:
> A question from a colleague of mine (copied) raised an issue I was not
> able to answer and I would appreciate some help.
>
> Implementations must ensure that InetAddressType objects
> and any dependent objects (e.g., InetAddress objects) are
> consistent. An inconsistentValue error must be generated
> if an attempt to change an InetAddressType object would,
> for example, lead to an undefined InetAddress value. In
> particular, InetAddressType/InetAddress pairs must be
> changed together if the address type changes (e.g., from
> ipv6(2) to ipv4(1))."
>
> The value of an InetAddress object must always be
> consistent with the value of the associated InetAddressType
> object. Attempts to set an InetAddress object to a value
> inconsistent with the associated InetAddressType
> must fail with an inconsistentValue error.
>
> 'InetAddressType/InetAddress pairs must be changed together if the
> address type changes' sounds to me like multiple SetRequest operations
> should be used with pairs of objects Type/Address part of the varbind.
> What happens if the only tool the operator has at hand is a MIB browser
> that does not support multiple set operations? Should we always assume
> that browsers MUST support multiple set? If they do the association
> between corresponding InetAddressType/InetAddress is still the
> responsibility of the operator?
With "multiple SetRequest" you probably mean a single SetRequest with
multiple varbinds. If that interpretation is correct, then yes a MIB
browser that can do only single varbind SetRequests might have a
problem with a compliant implementation.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>