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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

OK... what we need to do is this.

- Verify what they mean. I think they mean to say that for now
  only IPv4 and IPv6 need to be supported (maybe also IPv4z
  and IPv6z, we should check that).
- If that is the case, then I would strongly suggest to NOT use
  the SIZE (0..114) bur rather use some text in DESCRIPTION to
  warn that current SNMP version do not support OIDs longer 
  than 128 subIDs, so one must take that into account.
- The DESCRIPTION clauses also only say that currently only
  IPv4/6 need to be supported.
- The COMPLIANCE specifies exactly the types to be supported and
  the proper SIZEs that go with that.

It is too bad, but it may very well be fastest if we check/verify
the first sentence first, and then do exact proposals for text
changes, aka

OLD 
  ....
NEW
  ....

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: maandag 12 mei 2003 23:40
> To: Mreview (E-mail)
> Subject: RE: Last Call: Stream Control Transmission Protocol 
> Management
> In formation Base to Proposed Standard
> 
> 
> >>>>> 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
> 
>