[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
inet address update diff
Below is a diff of my XML sources of the updated document relative to
the last ID. I will be offline for two weeks now so please understand
if responses to questions/concerns will take some time.
/js
Index: inetaddress.xml
===================================================================
RCS file: /usr/home/schoenw/CVS/ietf/inet-address-mib/inetaddress.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -U10 -r1.7 -r1.8
--- inetaddress.xml 2001/02/22 16:13:09 1.7
+++ inetaddress.xml 2001/07/13 20:52:14 1.8
@@ -1,38 +1,38 @@
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<rfc ipr="full2026"
- docName="draft-ops-rfc2851-update-00.txt"
+ docName="draft-ietf-ops-rfc2851-update-01.txt"
category="std">
-<!-- $Id: inetaddress.xml,v 1.7 2001/02/22 16:13:09 schoenw Exp $ -->
+<!-- $Id: inetaddress.xml,v 1.8 2001/07/13 20:52:14 schoenw Exp $ -->
<front>
<title abbrev="TCs for Internet Network Addresses">
Textual Conventions for Internet Network Addresses
</title>
<author initials="M." surname="Daniele" fullname="Mike Daniele">
- <organization>Compaq Computer Corporation</organization>
+ <organization>Consultant</organization>
<address>
<postal>
- <street>110 Spit Brook Rd</street>
- <city>Nashua</city>
+ <street>19 Pinewood Rd</street>
+ <city>Hudson</city>
<region>NH</region>
- <code>03062</code>
+ <code>03051</code>
<country>USA</country>
</postal>
- <phone>+1 603 884-1423</phone>
- <email>daniele@zk3.dec.com</email>
+ <phone>+1 603 883-6365</phone>
+ <email>mwdaniele@adelphia.net</email>
</address>
</author>
<author initials="B." surname="Haberman" fullname="Brian Haberman">
<organization>Nortel Networks</organization>
<address>
<postal>
<street>4039 Emperor Blvd., Suite 200</street>
<city>Durham</city>
<region>NC</region>
@@ -65,38 +65,41 @@
<postal>
<street>Bueltenweg 74/75</street>
<city>38106 Braunschweig</city>
<country>Germany</country>
</postal>
<phone>+49 531 391-3289</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>
-<date month="February" year="2001"/>
+<date month="July " year="2001"/>
<area>Operations and Management</area>
<workgroup>IPv6 MIB Design Team</workgroup>
<keyword>Network Management</keyword>
<keyword>Simple Network Management Protocol</keyword>
<keyword>SNMP</keyword>
<keyword>Management Information Base</keyword>
<keyword>MIB</keyword>
<abstract>
<t>
This MIB module defines textual conventions to represent commonly
used Internet network layer addressing information. The intent is
- that these definitions will be imported and used in MIBs that
- would otherwise define their own representations.
+ that these textual conventions will be imported and used in MIB
+ modules that would otherwise define their own representations.
+ </t>
+ <t>
+ This document obsoletes RFC 2851.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Several standard-track MIB modules use the IpAddress SMIv2 base
@@ -105,22 +108,22 @@
contain 4 byte IPv4 addresses. The IpAddress SMIv2 base type has
become problematic with the introduction of IP Version 6 (IPv6)
addresses <xref target="refs.RFC2373"/>.
</t>
<t>
This document defines multiple textual conventions as a mechanism
to express generic Internet network layer addresses within MIB
module specifications. The solution is compatible with SMIv2 (STD
58) and SMIv1 (STD 16). New MIB definitions which need to express
network layer Internet addresses SHOULD use the textual
- conventions defined in this memo. New MIBs SHOULD NOT use the SMIv2
- IpAddress base type anymore.
+ conventions defined in this memo. New MIB modules SHOULD NOT use
+ the SMIv2 IpAddress base type anymore.
</t>
<t>
A generic Internet address consists of two objects, one whose
syntax is InetAddressType, and another whose syntax is
InetAddress. The value of the first object determines how the
value of the second object is encoded. The InetAddress textual
convention represents an opaque Internet address value. The
InetAddressType enumeration is used to "cast" the InetAddress
value into a concrete textual convention for the address type.
This usage of multiple textual conventions allows expression of
@@ -130,27 +133,27 @@
<t>
The textual conventions defined in this document can be used to
define Internet addresses by using DNS domain names in addition to
IPv4 and IPv6 addresses. A MIB designer can write compliance
statements to express that only a subset of the possible address
types must be supported by a compliant implementation.
</t>
<t>
MIB developers who need to represent Internet addresses SHOULD use
these definitions whenever applicable, as opposed to defining
- their own constructs. Even MIBs that only need to represent IPv4
- or IPv6 addresses SHOULD use the textual conventions defined in
- this memo.
+ their own constructs. Even MIB modules that only need to represent
+ IPv4 or IPv6 addresses SHOULD use the textual conventions defined
+ in this memo.
</t>
<t>
- There are many widely deployed MIBs that use IPv4 addresses and
- which need to be revised to support IPv6. These MIBs can be
+ There are many widely deployed MIB modules that use IPv4 addresses
+ and which need to be revised to support IPv6. These MIBs can be
categorized as follows:
</t>
<t>
<list style="numbers">
<t>
MIB modules which define management information that is in
principle IP version neutral, but the MIB currently uses
addressing constructs specific to a certain IP version.
</t>
<t>
@@ -162,37 +165,54 @@
</list>
</t>
<t>
MIB modules of the first type SHOULD provide object definitions
(e.g. tables) that work with all versions of IP. In particular,
when revising a MIB module which contains IPv4 specific tables, it
is suggested to define new tables using the textual conventions
defined in this memo which support all versions of IP. The status
of the new tables SHOULD be "current" while the status of the old
IP version specific tables SHOULD be changed to "deprecated". The
- other approach of multiple tables for different IP versions is
- strongly discouraged.
+ other approach of having multiple similar tables for different IP
+ versions is strongly discouraged.
</t>
<t>
MIB modules of the second type, which are inherently IP version
specific, do not need to be redefined. Note that even in this
case, any additions to these MIB modules or new IP version
specific MIB modules SHOULD use the textual conventions defined in
this memo.
</t>
<t>
MIB developers SHOULD NOT use the textual conventions defined in
this document to represent generic transport layer addresses.
Instead the SMIv2 TAddress textual convention and associated
definitions should be used for transport layer addresses.
</t>
<t>
+ This memo introduces some ordering constraints in order to achieve
+ the following two goals:
+ <list style="numbers">
+ <t>
+ 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 e.g. handle some error conditions.
+ </t>
+ <t>
+ Provide some rules that prevent MIB module authors from doing
+ certain mistakes which can make future extensions of tables
+ with new objects impossible.
+ </t>
+ </list>
+ </t>
+ <t>
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
in this document are to be interpreted as described in RFC 2119
<xref target="refs.RFC2119"/>.
</t>
</section>
<section title="The SNMP Management Framework">
<t>
The SNMP Management Framework presently consists of five major
components:
@@ -258,60 +278,58 @@
MIB.
</t>
</section>
<section title="Definitions">
<figure>
<artwork>
INET-ADDRESS-MIB DEFINITIONS ::= BEGIN
-
IMPORTS
MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
-
inetAddressMIB MODULE-IDENTITY
- LAST-UPDATED "200102220000Z"
+ LAST-UPDATED "200107130000Z"
ORGANIZATION
"IETF Operations and Management Area"
CONTACT-INFO
"Juergen Schoenwaelder (Editor)
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig, Germany
Phone: +49 531 391-3289
EMail: schoenw@ibr.cs.tu-bs.de
- Send comments to mibs@ops.ietf.org."
+ Send comments to <mibs@ops.ietf.org>."
DESCRIPTION
"This MIB module defines textual conventions for
representing Internet addresses. An Internet
address can be an IPv4 address, an IPv6 address
or a DNS domain name."
- REVISION "200102220000Z"
+ REVISION "200107130000Z"
DESCRIPTION
- "First revision, published as RFC XXXX. This revisions
- contains several clarifications and it introduces some
- new textual conventions: InetAddressPrefixLength,
- InetPortNumber, and InetAutonomousSystemNumber."
+ "Second version, published as RFC &rfc.number;. This
+ revisions contains several clarifications and it
+ introduces some new textual conventions:
+ InetAddressPrefixLength, InetPortNumber, and
+ InetAutonomousSystemNumber."
REVISION "200006080000Z"
DESCRIPTION
"Initial version, published as RFC 2851."
::= { mib-2 76 }
-
InetAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding
InetAddress object is a zero-length string.
It may also be used to indicate an IP address
which is not in one of the formats defined
@@ -323,69 +341,82 @@
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be
accompanied by a definition of a textual convention for use
with that InetAddressType.
- The InetAddressType textual convention SHOULD NOT be subtyped
+ The InetAddressType textual convention SHOULD NOT be sub-typed
in object type definitions to support future extensions. It
- MAY be subtyped in compliance statements in order to require
+ MAY be sub-typed in compliance statements in order to require
only a subset of these address types for a compliant
- implementation."
+ implementation.
+
+ 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))."
SYNTAX INTEGER {
unknown(0),
ipv4(1), -- these named numbers are aligned
ipv6(2), -- with AddressFamilyNumbers from
dns(16) -- IANA-ADDRESS-FAMILY-NUMBERS-MIB
}
-
InetAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic Internet address.
An InetAddress value is always interpreted within the
- context of an InetAddressType value. The InetAddressType
- object which defines the context must be registered
- immediately before the object which uses the InetAddress
- textual convention. In other words, the object identifiers
- for the InetAddressType object and the InetAddress object
- MUST have the same length and the last sub-identifier of
- the InetAddressType object MUST be 1 less than the last
- sub-identifier of the InetAddress object.
+ context of an InetAddressType value. The InetAddressType
+ object which defines the the format of the InetAddress
+ value MUST be registered immediately before the object(s)
+ which use the InetAddress textual convention.
+
+ In other words, an (InetAddressType, InetAddress) tuple
+ must be registered in exactly this order while and
+ (InetAddressType, InetAddress, InetAddress) triple
+ must be registered in exactly this order.
+
+ 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
+ which is inconsistent with the associated InetAddressType
+ must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers."
SYNTAX OCTET STRING (SIZE (0..255))
-
InetAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents an IPv4 network address:
octets contents encoding
1-4 IP address network-byte order
The corresponding InetAddressType value is ipv4(1)."
SYNTAX OCTET STRING (SIZE (4))
-
InetAddressIPv6 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
STATUS current
DESCRIPTION
"Represents an IPv6 network address:
octets contents encoding
1-16 IPv6 address network-byte order
17-20 scope identifier network-byte order
@@ -393,173 +424,156 @@
The scope identifier (bytes 17-20) MUST NOT be present
for global IPv6 addresses. For non-global IPv6 addresses
(e.g. link-local or site-local addresses), the scope
identifier MUST be present if there is no other way to
disambiguate non-global IPv6 addresses. The scope
identifier contains a link identifier for link-local
and a site identifier for site-local IPv6 addresses.
The scope identifier MUST disambiguate identical address
- values. For link-local addresses, the scope identifier will
- typically be the interface index (ifIndex as defined in the
- IF-MIB, RFC 2863) of the interface on which the address is
- configured.
+ values. For link-local addresses, the scope identifier
+ will typically be the interface index (ifIndex as defined
+ in the IF-MIB, RFC 2863) of the interface on which the
+ address is configured.
The scope identifier may contain the special value 0
which refers to the default scope. The default scope
may be used in cases where the valid scope identifier
is not known (e.g., a management application needs to
write a site-local InetAddressIPv6 address without
knowing the site identifier value). The default scope
SHOULD NOT be used as an easy way out in cases where
the scope identifier for a non-global IPv6 address
is known."
SYNTAX OCTET STRING (SIZE (16|20))
-
InetAddressDNS ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Represents a DNS domain name. The name SHOULD be
fully qualified whenever possible.
The corresponding InetAddressType is dns(16).
The DESCRIPTION clause of InetAddress objects that
may have InetAddressDNS values must fully describe
how (and when) such names are to be resolved to IP
addresses."
SYNTAX OCTET STRING (SIZE (1..255))
-
InetAddressPrefixLength ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes the length of a generic Internet network address
prefix. A value of n corresponds to an IP address mask
which has n contiguous 1-bits from the most significant
bit (MSB) and all other bits set to 0.
- An InetAddressPrefixLength value is always interpreted
+ An InetAddressPrefixLength value is always interpreted
within the context of an InetAddressType value. The
- InetAddressType only object or InetAddressType with
- InetAddress objects which define the context must be
- registered immediately before the object which uses the
- InetAddressPrefixLength textual convention. In other
- words, the object identifiers for the InetAddressType
- object and the InetAddressPrefixLength object MUST
- have the same length and the last sub-identifier of
- the InetAddressType object MUST be 1 less than the
- last sub-identifier of the InetAddressPrefixLength
- object and MUST be 2 less than the last sub-identifier
- of the InetAddressPrefixLength object if an InetAddress
- object is defined between InetAddressType and
- InetAddressPrefixLength objects.
+ InetAddressType object must be registered before the
+ object which uses the InetAddressPrefixLength textual
+ convention.
InetAddressPrefixLength values that are larger than
the maximum length of an IP address for a specific
InetAddressType are treated as the maximum significant
value applicable for the InetAddressType. The maximum
significant value is 32 for the InetAddressType
'ipv4(1)' and 128 for the InetAddressType 'ipv6(2)'.
The maximum significant value for the InetAddressType
'dns(16)' is 0.
The value zero is object-specific and must be defined as
part of the description of any object which uses this
syntax. Examples of the usage of zero might include
situations where the Internet network address prefix
is unknown or does not apply."
SYNTAX Unsigned32
-
InetPortNumber ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a 16 bit port number of an Internet transport
layer protocol. Port numbers are assigned by IANA. A
current list of all assignments is available from
<http://www.iana.org/>.
The value zero is object-specific and must be defined as
part of the description of any object which uses this
syntax. Examples of the usage of zero might include
situations where a port number is unknown, or when the
value zero is used as a wildcard in a filter."
REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"
SYNTAX Unsigned32 (0..65535)
-
InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an autonomous system number which identifies an
Autonomous System (AS). An AS is a set of routers under a
single technical administration, using an interior gateway
protocol and common metrics to route packets within the AS,
and using an exterior gateway protocol to route packets to
other ASs'. IANA maintains the AS number space and has
delegated large parts to the regional registries.
Autonomous system numbers are currently limited to 16 bits
(0..65535). There is however work in progress to enlarge the
autonomous system number space to 32 bits. This textual
convention therefore uses an Unsigned32 value without a
range restriction in order to support a larger autonomous
system number space."
REFERENCE "RFC 1771, RFC 1930"
SYNTAX Unsigned32
-
END
</artwork>
</figure>
</section>
<section title="Usage Hints">
<t>
One particular usage of InetAddressType/InetAddress pairs is to
avoid over-constraining an object definition by the use of the
IpAddress SMI base type. An InetAddressType/InetAddress pair
allows to represent IP addresses in various formats.
</t>
<t>
The InetAddressType and InetAddress objects SHOULD NOT be
- subtyped. Subtyping binds the MIB module to specific address
+ sub-typed. Sub-typing binds the MIB module to specific address
formats, which may cause serious problems if new address formats
need to be introduced. Note that it is possible to write
compliance statements in order to express that only a subset of
the defined address types must be implemented to be compliant.
</t>
<t>
- Internet addresses MUST always be represented by a pair of
- InetAddressType/InetAddress objects. It is not allowed to "share"
- an InetAddressType between multiple InetAddress objects.
- Furthermore, the InetAddressType object must be registered
- immediately before the InetAddress object. In other words, the
- object identifiers for the InetAddressType object and the
- InetAddress object MUST have the same length and the last
- sub-identifier of the InetAddressType object MUST be 1 less than
- the last sub-identifier of the InetAddress object.
+ The InetAddressType object must be registered immediately before
+ the InetAddress object(s) or InetAddressPrefixLength object(s). In
+ other words, the object identifiers for the InetAddressType object
+ and the InetAddress object MUST have the same length and the last
+ sub-identifier of the InetAddressType object MUST be less than the
+ last sub-identifier of the InetAddress object. This rule allows
+ programs such as MIB compilers to identify the InetAddressType of
+ a given InetAddress or InetAddressPrefixLength object by searching
+ for the InetAddressType object which precedes InetAddress or
+ InetAddressPrefixLength registration.
</t>
<section title="Table Indexing">
<t>
When a generic Internet address is used as an index, both the
InetAddressType and InetAddress objects MUST be used. The
- InetAddressType object MUST come immediately before the
- InetAddress object in the INDEX clause. If multiple Internet
- addresses are used in the INDEX clause, then every Internet
- address must be represented by a pair of InetAddressType and
- InetAddress objects.
+ InetAddressType object MUST be listed immediately before the
+ InetAddress object in the INDEX clause.
</t>
<t>
The IMPLIED keyword MUST NOT be used for an object of type
InetAddress in an INDEX clause. Instance sub-identifiers are
then of the form T.N.O1.O2...On, where T is the value of the
InetAddressType object, O1...On are the octets in the
InetAddress object, and N is the number of those octets.
</t>
<t>
There is a meaningful lexicographical ordering to tables indexed
@@ -592,54 +606,54 @@
<t>
The size of the scope identifier has been chosen so that it
matches the sin6_scope_id field of the sockaddr_in6 structure
defined in RFC 2553 <xref target="refs.RFC2553"/>.
</t>
</section>
<section title="Multiple InetAddresses per Host">
<t>
A single host system may be configured with multiple addresses
- (IPv4 or IPv6), and possibly with multiple DNS names. Thus it
- is possible for a single host system to be represented by
- multiple InetAddressType/InetAddress pairs.
+ (IPv4 or IPv6), and possibly with multiple DNS names. Thus it is
+ possible for a single host system to be accessible by multiple
+ InetAddressType/InetAddress pairs.
</t>
<t>
If this could be an implementation or usage issue, then the
DESCRIPTION clause of the relevant objects MUST fully describe
required behavior.
</t>
</section>
<section title="Resolving DNS Names">
<t>
DNS names must be resolved to IP addresses when communication
with the named host is required. This raises a temporal aspect
to defining MIB objects whose value is a DNS name: When is the
name translated to an address?
</t>
<t>
For example, consider an object defined to indicate a forwarding
destination, and whose value is a DNS name. When does the
forwarding entity resolve the DNS name? Each time forwarding
- occurs? Once, when the object was instantiated?
+ occurs or just once when the object was instantiated?
</t>
<t>
The DESCRIPTION clause of such objects SHOULD precisely define
how and when any required name to address resolution is done.
</t>
<t>
Similarly, the DESCRIPTION clause of such objects SHOULD
precisely define how and when a reverse lookup is being done if
an agent has accessed instrumentation that knows about an IP
- address and the MIB or implementation requires to map the
- address to a name.
+ address and the MIB module or implementation requires to map
+ the IP address to a DNS name.
</t>
</section>
</section>
<section title="Table Indexing Example">
<t>
This example shows a table listing communication peers that are
identified by either an IPv4 address, an IPv6 address or a DNS
name. The table definition also prohibits entries with an empty
address (whose type would be "unknown"). The size of a DNS name
@@ -750,50 +764,51 @@
</section>
<section title="Security Considerations">
<t>
This module does not define any management objects. Instead, it
defines a set of textual conventions which may be used by other
MIB modules to define management objects.
</t>
<t>
Meaningful security considerations can only be written in the
- modules that define management objects.
+ MIB modules that define management objects. This document has
+ therefore no impact on the security of the Internet.
</t>
</section>
<section title="Acknowledgments">
<t>
This document was produced by the Operations and Management Area
- "IPv6MIB" design team. The authors would like to thank Randy Bush,
- Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro Hagino, Tim
- Jenkins, Glenn Mansfield, Keith McCloghrie, Thomas Narten, Erik
- Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew Smith, Dave
- Thaler, Kenneth White, Bert Wijnen, and Brian Zill for their
- comments and suggestions.
+ "IPv6MIB" design team. The authors would like to thank Fred Baker,
+ Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro
+ Hagino, Tim Jenkins, Glenn Mansfield, Keith McCloghrie, Thomas
+ Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew
+ Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill for
+ their comments and suggestions.
</t>
</section>
<section title="Intellectual Property Notice">
<t>
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found
in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
- permission for the use of such propritary rights by implementors
+ permission for the use of such proprietary rights by implementors
or users of this specification can be obtained from the IETF
Secretariat.
</t>
<t>
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be required
to practice this standard. Please address the information to the
IETF Executive Director.
</t>
@@ -806,30 +821,49 @@
<t>
Added new TCs: InetAddressPrefixLength, InetPortNumber,
InetAutonomousSystemNumber
</t>
<t>
Rewrote the introduction to say clearly that in general, one
should define MIB tables that work with all versions of
IP. The other approach of multiple tables for different IP
versions is strongly discouraged. (kzm)
</t>
+ <t>
+ Added text to the InetAddressType and InetAddress descriptions
+ which requires that implementations must reject set operations
+ with an inconsistentValue error if they lead to inconsistencies.
+ </t>
+ <t>
+ Relaxed the rules to make it possible to register tuples where
+ multiple objects share an InetAddressType value, which is
+ needed for filters of the form (InetAddressType, InetAddress,
+ InetPortNumber, InetAddress InetPortNumber).
+ </t>
+ <t>
+ Added a paragraph in the Introduction which explains the
+ motivation for the ordering constraints.
+ </t>
</list>
</t>
</section>
<section title="Open Issues">
<t>
<list style="symbols">
+ <t>
+ Check that the document is consistent with
+ draft-ietf-ipngwg-scoping-arch-02.txt and add a reference to
+ it.
+ </t>
<t>
- Shall we define an InetProtocolNumber TC, similar to the
- InetPortNumber TC?
+ Addition of an InetScopeIdentifier TC? (Bill Fenner)
</t>
</list>
</t>
</section>
</middle>
<back>
<references>