Subject: RE: [ipv6mib] Re: Auth48 update to TCP-MIB(draft-ietf-ipv6-rfc2012-update-06.txt)

From: "Dave Thaler" <[email-masked]>
Date: Mon, 23 Aug 2004 12:36:43 -0700

I also prefer it the way it is now, and Rajiv's proposed mods
look fine to me.

-Dave

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]
> bs.de] On Behalf Of Juergen Schoenwaelder
> Sent: Monday, August 23, 2004 6:37 AM
> To: Kristine Adamson
> Cc: [email-masked]; [email-masked]
> Subject: Re: [ipv6mib] Re: Auth48 update to TCP-MIB(draft-ietf-ipv6-
> rfc2012-update-06.txt)
> 
> On Mon, Aug 23, 2004 at 04:04:57AM -0600, Kristine Adamson wrote:
> 
> > In this case, would it be better to update draft-3291bis to permit
> > zero-length octet-strings for InetAddress objects whose
InetAddressType
> is
> > IPv4 or IPv6?  We have already encountered problems with network
> > management applications not being able to get as much SNMP data back
in
> an
> > SNMP response as they would like to be able to.  With an IPv6
address in
> > an instance already taking up a lot of space in the SNMP response
> packet,
> > it doesn't seem like a good use of response packet space to return
16
> > bytes of zeros for the address.
> 
> While I do not really buy into the bandwidth argument, I am indeed
> wondering whether the current rule is perhaps overly restrictive. At
> the moment (and that is unchanged from RFC 3291 and even from RFC
2851),
> we have the following implication:
> 
> 	InetAddress zero-length  =>  InetAddressType == unknown
> 
> To change this (basically removing this rule), we would have to remove
> text from the 'unknown' definition and we would have to add text to
the
> InetAddress TC that zero-length values can be legal subject to the
> semantics spelled out in the definition where the TC is being used
> (with a statement that per default they are not legal if nothing is
> spelled out in the description clause (backwards compatibility)).
> 
> I am not sure which impact such a change will have. These TCs have
> seen quite some usage - not only in the IETF, but also in vendor
> specific MIB modules. And this is the first time I can remember
> (and that I could find in my mailing list archive) that a change
> to generally allow zero-length InetAddress values has been proposed.
> 
> Unless I hear a strong move to change the rule above, I actually
prefer
> to stay with what we have.
> 
> /js
> 
> --
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725
Bremen,
> Germany
> --
> !! This message is brought to you via the `ipv6mib' mailing list.
> !! Please do not reply to this message to unsubscribe. To unsubscribe
or
> adjust
> !! your settings, send a mail message to
<[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ipv6mib.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Tue, 24 Aug 2004 08:31:26 -0400

I have no problems with Rajiv's proposed changes.  I think that
is better than revving 3291bis and affecting other mibs.

Brian