RE: Bugs in UDP-MIB and TCP-MIB (was: RE: MIB DOctor review of: d raft-ietf-ipv6-inet-tunnel-mib-01.txt)

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

It would be good to prepare the fix to UDP and TCP MIB documents in the form
of RFC-Editor instructions aka

- on page x pls change
  OLD:
    ....
  NEW:
    ...

So that we can make the change when we see the AUTH48.
I need to check the impact a bit though... (I am in the process of 
recovering from a broken laptop... so I do not have verything handy at the
moment).

Thanks, Bert


> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Friday, August 13, 2004 05:34
> To: Mreview (E-mail)
> Cc: Wijnen, Bert (Bert); Margaret Wasserman (E-mail)
> Subject: Bugs in UDP-MIB and TCP-MIB (was: RE: MIB DOctor review of:
> draft-ietf-ipv6-inet-tunnel-mib-01.txt)
> 
> 
> On Thu, 12 Aug 2004, Dave Thaler wrote:
> > >   3. According to RFC3291, if the address is unknown, then the
> > >      value should be the zero-length octet string
> > 
> > My reading of 3291 is that the zero-length octet string is 
> only used if 
> > the InetAddressType is unknown.
> 
> http://www1.ietf.org/internet-drafts/draft-ietf-ops-rfc3291bis-05.txt
> says something a little bit different -- an InetAddressType object
> must assume the value unknown(0) if the corresponding InetAddress
> object has zero length, but the reverse is not necessarily true,
> per the following excerpt from the InetAddressType DESCRIPTION clause:
> 
>    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
>                below.
> 
> > If the type is known to be IPv4 or IPv6, then the zero-length
> > octet string is not used.
> 
> That, however, is certainly true.
> 
> 
> > [... ] The new UDP MIB says [ ... ] (and the TCP MIB has
> > similar text):
> >       an application which is willing to accept only IPv4
> >       or only IPv6 datagrams is represented by a
> >       udpEndpointLocalAddressType of the appropriate
> >       address type, and udpEndpointLocalAddress of ''h (a
> >       zero-length octet-string).
> > 
> > However, from RFC 3291 (unchanged in 
> draft-ietf-ops-rfc3291bis-05.txt), 
> > the definition of the InetAddressType says
> >          ipv4(1)     An IPv4 address as defined by the
> >                      InetAddressIPv4 textual convention.
> > 
> >          ipv6(2)     A global IPv6 address as defined by the
> >                      InetAddressIPv6 textual convention.
> > 
> > And the SYNTAX clauses of those are:
> > InetAddressIPv4 ::= TEXTUAL-CONVENTION
> >     SYNTAX       OCTET STRING (SIZE (4))
> > 
> > InetAddressIPv6 ::= TEXTUAL-CONVENTION
> >     SYNTAX       OCTET STRING (SIZE (16))
> > 
> > Since the 0-length string is not legal in those SYNTAX clauses,
> > my reading is that the UDP-MIB (which is in IETF last call) 
> > and TCP-MIB (which is in the RFC editors queue)
> > interpretation is not legal, and the existing TUNNEL-MIB 
> > interpretation is correct.
> > 
> > Or am I missing something?
> 
> IMHO, you are not.  I think that both of those documents need to be
> corrected.  Fortunately, they are both blocked waiting for 3291bis,
> since it is a normative reference in both.
> 
> I guess we would be covered by a Last Call comment on the UDP-MIB,
> but we will have to ask for help from Bert and Margaret for the
> TCP-MIB.
> 
> Mike
> 
> 
>