RE: Last Call: Stream Control Transmission Protocol Management Information Base to Proposed Standard

["C. M. Heard" <heard@pobox.com>]

>>>>> On Fri, 9 May 2003, Wijnen, Bert (Bert) wrote:
Bert> We came to consensus (or so I thought) that people MUST do one
Bert> of two things (as per above new text for InetAddress):
Bert>   - Add a SIZE retriction, OR
Bert>   - DESCRIBE the applicable constraints in an appropriate place.

I agree with this.

Bert> What I see is:
Bert> 
Bert>   - Page 8 talks about only IPv4/IPv6 and unknown addresses to be
Bert>     valid for the current MIB module. Maybe it needs to add some
Bert>     text for explaining SIZE constraints as well?

That would satisfy the requirement.  However, if these are indeed
hard-and-fast requirements, I think that they should be written
into the object definitions explicitly.  More on this below.

Bert>   - DESCRIPTION clauses of sctpAssocLocalAddr and sctpAssocRemAddr,
Bert>     and sctpLookupRemPrimIPAddrEntry contain a discussion on the
Bert>     SIZE constraints. We have clearly allowed for that in the
Bert>     proposed new text for InetAddress above and so I do not see
Bert>     why we need to force them to remove the text and use a SIZE
Bert>     clause instead (as Mike suggested).
Bert>     Is it that we feel the text is not clear enuf?

It's not just unclear, it's downright inaccurate.  The stuff on page 8
says this:

   Both sctpAssocLocalAddrTable and sctpAssocRemAddrTable are indexed by
   addresses. 'Addr' and 'AddrType' use the syntax InetAddress and
   InetAddressType defined in the Textual Conventions for Internet
   Network Address (RFC3291). In the general case this syntax is valid
   for Unknown IP addresses, IPv4, IPv6, non-global IPv4, non-global
   IPv6 address and DNS, but only the IPv4 and IPv6 address options are
   allowed in this MIB.

The last sentence says that the only InetAddressType values allowed are
ipv4(1) and ipv6(2), which implies that the only possible sizes are
4 or 16 octets.  The compliance statement's DESCRIPTION clause, on the
other hand, says this:

   -- OBJECT        sctpAssocLocalAddrType
   -- SYNTAX        InetAddressType {ipv4(1), ipv6(2)}
   -- DESCRIPTION
   --       It is only required to have IPv4 and IPv6 addresses without
   --       zone indices.
   --       The address with zone indices is required if an
   --       implementation can connect multiple zones.
   --
   -- OBJECT        sctpAssocLocalAddr
   -- SYNTAX        InetAddress (SIZE(4|16))

which suggests that in fact IPv4, IPv6, non-global IPv4, non-global
IPv6 addresses are allowed, but only the global ones are required.
In other words, the allowed InetAddressType values allowed are
ipv4(1), ipv6(2), ipv4z(3), and ipv6z(4), and the sized allowed are
4, 8, 16, or 20 octets.  So, the text on page 8 needs to be improved
on this point.

There is, however, another issue with the text on page 8, and that
is that it rules out using the MIB module with new address types,
which is something that RFC 3291 discourages.  If that's really
what the MIB module designers mean to do, then it should be factored
explicitly into the object definitions.  If that's not what they
intended, then some additional adjustments to the text on page 8
will be required.

The DESCRIPTION clauses of sctpAssocLocalAddr and sctpAssocRemAddr,
and sctpLookupRemPrimIPAddrEntry, on the other hand, say this:

          Theoretically this could result in a more than 128 subid
          index, but that in practice it is only required to support
          IPv4 and IPv6 addresses, so it would never be more than 20
          octets.

If IPv4/IPv6 and zoned counterparts are the only possible address types,
then it is not even theoretically possible to overflow then length.  If
one kept the spirit of this definition but removed the inaccurate text,
it would say something like this:

          Since only IPv4 and IPv6 addresses are allowed, the size
          of this object cannot exceed 20 octets.

However, that would be just as restrictive as making the SYNTAX
InetAddress (SIZE(0..20)).  Changing a DESCRIPTION like this to
allow larger sizes would be an illegal semantic change, and would
be forbidden for the same reasons that changing a SIZE constraint
is generally not allowed.

Now, when I made my original comments, I was operating on the
assumption that the proper course for this MIB document was to
make it adaptable to new address types, and so the proper size
restriction is the cap imposed by the 128 sub-id limit (this is
required to work with the present and only forseeable versions
of the SNMP).  That's why I suggested a cap of 114 octets rather
than 20.  In principle, that could be done either by having a
SYNTAX value of InetAddress (SIZE(0..114)) or by words like this
in the DESCRIPTION clause:

          In order to avoid exceeding the limit of 128 sub-identifiers
          for object names, it is required that the size of this
          object not exceed 114 octets.

Bert> In other words, if we give people a choice of two options, why
Bert> would we enforce one of them?

For me, it's not a question of forcing people to do certain things
but rather a question of recommending to them to use the best tool
for the job.  In my opinion, if I can say the exact same thing in
a SIZE constraint or in a DESCRIPTION clause, then the better option
is the SIZE constraint because it's more explicit.  I would resort to
a textual description in a DESCRIPTION clause or elsewhere only when
the more formal mechanisms can't do the job, which is indeed sometimes
the case but apparently not here.

>>>>> On Fri, 9 May 2003, Harrie Hazewinkel wrote:
Harrie> Even though the text part of the draft speaks about "only the
Harrie> IPv4 and IPv6 address options are allowed in this MIB", the
Harrie> description part of 'sctpAssocRemPrimAddrType ' does not say
Harrie> that.

Agreed.

Harrie> The description uses the word 'expected' that is (IMO) the word
Harrie> which needs fixing.
Harrie> 
Harrie>    sctpAssocRemPrimAddrType OBJECT-TYPE
Harrie>       SYNTAX         InetAddressType
Harrie>       MAX-ACCESS     read-only
Harrie>       STATUS         current
Harrie>       DESCRIPTION
Harrie>            "The internet type of primary remote IP address.
Harrie> 
Harrie>            Only IPv4 and IPv6 addresses are expected."
Harrie> 
Harrie> In my opinion an expectation is different from what is valid.
Harrie> The expectation allows a possible DNS type. The description
Harrie> should make it clear that only IPv4 and IPv6 are allowed
Harrie> or all kinds of address types that resolv in an InetAddress
Harrie> length that adheres to the OID size limitation.

Exactly.  If the DESCRIPTION clause says that only IPv4 and IPv6 are
allowed, however, that's equivalent to having a SYNTAX value of
InetAddressType {ipv4(1), ipv6(2), ipv4z(3), ipv6z(4)}, and I would
argue that explicit subtyping is a better tool for the job than
text in a DESCRIPTION clause.

Harrie> Although, a subtype could have been nice for the 'InetAddressType'
Harrie> RFC 3291 says it is better not to do that, but it MAY be in a
Harrie> compliance statement.  From description of 'InetAddressType'
Harrie> [in] rfc 3291:
Harrie>     To support future extensions, the InetAddressType textual
Harrie>     convention SHOULD NOT be sub-typed in object type definitions.
Harrie>     It MAY be sub-typed in compliance statements in order to
Harrie>     require only a subset of these address types for a compliant
Harrie>     implementation.
Harrie> 
Harrie> This is indeed what they have done.

Yes, but let me remind you what SHOULD NOT means (per RFC 2119):

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

If the MIB module authors indeed think that the proper design is to
restrict the module to supporting only the InetAddressType values
ipv4(1), ipv6(2), ipv4z(3), and ipv6z(4) and no other types that
might be defined in the future, then that would qualify as a one of
those particular circumstances when subtyping in an object
definition is both acceptable and even useful, I think.  On the
other hand, if it's possible that the MIB module can be used with
other yet-to-be defined address types, then avoiding the subtyping
(and putting in the most liberal possible SIZE constraints or
equivalent text) is the right thing to do.  My previous comments
assumed the latter, but that could be wrong.  The existing
compliance statement that sets the minimum implementation
requirements to ipv4(1) and ipv6(2) would of course be appropriate
with either alternative.

Mike