Subject: 2292bis-02: zero-length setsockopt

From: [email-masked]
Date: Mon, 29 Oct 2001 19:43:50 +0900

during RFC2292 to 2292bis transition, it seems that the following text
	has been added to multiple places:

(how to reset values set by IPV6_HOPLIMIT setsockopt)
>   In order to clear a sticky IPV6_HOPLIMIT option the application can
>   specify -1 as the value.  Alternatively, the application can specify  <--
>   an IPV6_HOPLIMIT socket option with a zero length.			  <--

	i don't think it is a usual practice for setsockopt.  they normally
	take a parameter with fixed length.
	i'm wondering where did this behavior come from, and how popular is it
	for UNIX setsockopt to behave like this.  any hints?

itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 29 Oct 2001 14:42:48 +0100 (CET)

> 	for UNIX setsockopt to behave like this.  any hints?

I guess I stuck that text in there based on some goal of consistency with
the other IPV6_ options in the spec.

Clearly(?) for IPv6_DSTOPTHDR it makes sense to be able to
clear the sticky option by setting it to zero length.
(I think this is consistent with setting IP_OPTIONS to zero length.)

So what about IPV6_HOPLIMIT that is a fixed length quantity?
Is it more important to be consistent with the other IPv6 options
(and allow zero length as a way to clear it) or is it more
important to make the option value always have a fixed length (meaning
that -1 is the only way to set if to "default").

I don't have a strong opinion either way.

  Erik