Subject: more 2292-bis comments

From: [email-masked] (Sam Manthorpe)
Date: Wed, 11 Aug 1999 12:23:57 -0700 (PDT)

Prompted by Vladislav's mail, I'm sending some comments
that I have also been accumulating regarding 2292-bis as I
implement it.  Erik, are you still taking care of this document?
You seem very involved and busy with other IPv6 hot-topics and my last 
private email regarding 2292bis remains unanswered.  The comments
are below... there could well be more as I haven't finished implementing
everything yet :-)

Cheers,
Sam.

    1.	I assume that the intention is to insert the extension
	headers created with the inet6_opt_* functions into the
	cmsg_data part of a control message to be passed as
	ancillary data.  This relationship between the CMSG_*
	macros and the inet6_opt_* functions wasn't stated
	explicitly in the document, although it does become
	apparent after reading the examples in the appendix.
	Why was the cmsg stuff moved to the appendix?

    2.	inet6_opt_append().  I think if the extbuf parameter
	is non-NULL then you would also like the function to
	update the extension header length field, right?  This
	isn't currently required by the document and I suggest
	that it should be.

    3.	I don't see any reason to not allow inet6_opt_append()
	to add Pad1 and PadN options (section 9.2).

    4.	I would suggest that padding options _not_ be returned
	by inet6_opt_next() and that this be stated in section 9.5.

    5.	Section 9.5 should desecribe how the function behaves
	once all the options have been read from the buffer; I would
	suggest that it return a value of zero and that the three
	call-by-reference return parameters remain undefined.

    6.	Is there really such an installed base to warrant the
	rfc-2292 compatability goal?  2292bis states it contains
	several modifications to simplify the implementation
	of the API but then suggests that implementation
	compatibility with 2292 would be a good thing, defeating
	the goal of these simplifications.  I really would prefer
	a `one or the other' approach, because there is no important
	functionality in one that isn't in the other regarding
	the ancillary data/sockopts functionality, it's just
	two different ways of doing things.

    7.	There seems to be some confusion as to whether the cmsg_len
	field of struct cmsghdr includes the header length or
	not.  The definition says it does, as does the ascii
	diagram, but some of the macro examples, CMSG_NXTHDR for
	example, imply that it does not.  I assume it is the
	macro examples that are wrong.

    8.	As Vladislav, I also question the value of section 12 in the API.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]
--------------------------------------------------------------------
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: Tue, 31 Aug 1999 13:45:03 -0700 (PDT)

> 	ancillary data.

Yes, cmsg_data *or* in a setsockopt for sticky options.

>	  This relationship between the CMSG_*

I'll try to make this more explicit.

> 	isn't currently required by the document and I suggest

The intent is that inet6_opt_init set the length (so that the other
functions can check for overrunning the the buffer).
I could embelish the example with pictures, or I could toss an
example implementation of inet6_opt_*() in an appendix.

> 	to add Pad1 and PadN options (section 9.2).

Agreed.

> 	by inet6_opt_next() and that this be stated in section 9.5.

I think that would make sense.

> 	call-by-reference return parameters remain undefined.

Yes, we need to specify something.

> 	two different ways of doing things.

I'm open to input. Does anybody want 2292 compatibility?

  Erik