[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ops-rfc2851-update-05.txt last call summary
>>>>> Wijnen, Bert (Bert) writes:
Bert> Anyway... I need a summary of the issues/concerns raised with an
Bert> answer and potential text to be updated. I need this by Wed
Bert> noon (european time (i.e. 6am ET)), that is if I want to keep
Bert> the document on the IESG agenda for Thursday.
I will try to summarize the issues as I understand them below. I am
not sure I know the answer. I will describe the issues by way of
examples.
(1) Dave Thaler <dthaler@windows.microsoft.com> raised the following
issue:
You have a table indexed by an (InetAddressType, InetAddress)
pair, lets call them baseAddressType and baseAddress. Suppose you
have another table extension which is indexed by (baseAddressType,
baseAddress, extsnIndex) and which has a column extsnAddress of
type InetAddress. One would expect that the baseAddressType object
in this case also defines the InetAddressType of the extsnAddress
object. The text in the current ID does not really handle this
case.
Dave Thaler suggested some text which tries to extend the rules so
that index objects are considered to be "in front" of any other
objects in a table entry.
(2) Mike Heard <heard@pobox.com> raised the following issues:
Mike carefully read the text on the ordering constraints for
InetAddressType and InetAddress/InetAddressPrefixLength objects
and he found several cases where the text was not precise enough.
He proposed concrete changes/additions to make the text more
precise.
He also suggested text which covers cases where people might break
things if there are gaps in the column registrations and so
subsequent MIB module revisions can introduce new InetAddressType
objects and thus change semantics of existing objects as a side
effect.
Mike also found the problem Dave Thaler has already reported.
However, Mike suggests to actually remove the ordering constraints
rather than making them even complicated as suggested by Dave
Thaler.
(3) Keith McCloghrie raised the question whether the concrete
InetAddress TCs (InetAddressIPv4, InetAddressIPv6, ...) can be
alone in MIBs that are clearly IP version specific. Although the
document started with rigid rules that required MIB authors to
always use (InetAddressType, InetAddress) pairs, it has evolved
into a state where this is a SHOULD rather than a MUST.
Keith further asks: If it is legal to use concrete InetAddress TCs
such as InetAddressIPv6 alone, is it still required to have an
InetAddressType object?
(4) The RFC Editor raised the question whether reference [21] is
normative or not.
Discussion:
Issues (1) and (2) are closely related. The motivations for the
ordering constraints are given on page 4:
1. Enable programs to identify the InetAddressType object which
discriminates a certain InetAddress object. This allows tools
such as MIB compilers to understand the dependencies and to
generate code to handle some error conditions.
2. Provide some rules that prevent MIB module authors from doing
certain mistakes which can make future extensions of tables with
new objects impossible.
It turns out that fomulating the ordering constraints in a precise way
is not trivial and that the rules become relative complex in order to
handle tables where the InetAddressType is an index object "borrowed"
from other tables. There are also cases with table augmentations that
need to considered. In the lifetime of this document, the ordering
constraints have generated the most heat. On the other hand, dropping
them altogether (or turning them into strong suggestions described in
the "usage hints" section) and requiring DESCRIPTIONS to identify the
InetAddressType for each InetAddress/InetAddressPrefixLength objects
has the effect that it is impossible for generic tools (such as
manager/agent code generators or generic MIB browsers) to do the right
thing. This is a tradeoff decision where it would be nice to have a WG
chair who determines consensus to either drop the ordering constraints
or trying to get the right and flexible enough the actually handle all
foreseeable cases. My personal observation from following the
discussions is that people who spoke up seem to prefer to drop the
ordering requirements.
On issue (3), there has been private communication between me and
Keith. One resolution would be to allow the usage of concrete TCs
with a clear warning. The proposed warning which should be added to
each concrete address TC might look like this:
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType as a pair, i.e., in place of
just InetAddress, or in place of both InetAddressType and
InetAddress.
Also, in the beginning of the document, the following paragraph
MIB developers who need to represent Internet addresses SHOULD use
these definitions whenever applicable, as opposed to defining their
own constructs. Even MIB modules that only need to represent IPv4 or
IPv6 addresses SHOULD use the textual conventions defined in this
memo.
should be replaced with:
MIB developers who need to represent Internet addresses SHOULD use
these definitions whenever applicable, as opposed to defining their
own constructs. Even MIB modules that only need to represent IPv4 or
IPv6 addresses SHOULD use the InetAddressType/InetAddress textual
conventions defined in this memo.
On issue (4), one can argue that the RFC 2851 update does not anything
new which has not been in some form in RFC 2851 and which depends on
[21]. On the other hand, [21] is really helpful to understand the
concept of address scopes and zones.
/js
--
Juergen Schoenwaelder Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Muehlenpfordtstr. 23, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <http://www.ibr.cs.tu-bs.de/~schoenw/>
/js
--
Juergen Schoenwaelder Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Muehlenpfordtstr. 23, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <http://www.ibr.cs.tu-bs.de/~schoenw/>