Subject: Re: Comments on 2292bis (Adv. API) (2)

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 01 Sep 1999 10:24:03 -0400

Erik Nordmark wrote:
> 
> > Section 9.5 [page 36]
> > - How is the "previous" length updated in this sentence?
> >   1977     ....  This
> >   1978     function returns the updated "previous" length taking into account
> >   1979     the option that was returned.
> 
> It updates it so that it can be passed to the next call to inet6_opt_next.
> I'll add some text to that effect.
> (Or were you asking how to implement this?)

I was asking, what "update 'previous' length" means in this case.  Do we simply
account for the new option by increment (or decrement for other functions) the
length accordingly, or is there some other processing need?  The reason I asked
this is that the sentence seemed a little vague to me.

> 
> > - Also, the main body of the spec does not indicate if inet6_opt_next returns
> > pad options or just skips over them. The example code in the appendix shows
> > the application code does recognize and ignore pad options. Suggest a note
> > be added to this section indicating inet6_opt_next does return pad options.
> 
> I agree we should clarify this. But do we want  it to return them or skip them?
> 

I do not see a reason for returning Pad1 and PadN options.  The reason I asked
is then the example in the Appendix had Pad1 and PadN in the 'switch' clause and
it was not stated anywhere in the document whether inet6_opt_next returned these
options.

> 
> >
> > Sections 12.2 and 12.3
> > - What was the reason to put rcmd_af() and rexec_af() in this spec?
> > It was the concensus of the reviewers that these functions are not really
> > needed since they both used to call rresvport() and can be made to call
> > rresvport_af().  As it is currently, rcmd() and rexec() do the hostname
> > lookups.  At this point these functions can make the decision  to use V6 or
> > V4 based on the addresses returned.  We do not really see the need for
> > rcmd_af() and rexec_af().
> 
> I tried finding the old discussion but failed to do so.
> 
> The issue is that transparently changing rcmd and rresvport to
> open AF_INET6 sockets (based on what getipnodebyname returns)
> might break some existing applications.
> For example, an application which calls rcmd and then calls
> getpeername.
> 
> Thus I think we need APIs so that only applications which state that
> they can handle sockaddr_in6 addresses will get an AF_INET6 socket
> returned by rcmd/rexec/rresvport.
> 

OK, I see your point.  I guess we can leave it in this document for lack of
a better place.

> > Section 22 [page 47]
> > - This section and it's subsections add a lot of new requirements to
> > an implementation's handling of the msghdr and cmsghdr structures.
> 
> What aspects of msghdr and cmsghdr are new? 99% of it is in
> posix/xnet already.
> 
> The only new things are CMSG_SPACE and CMSG_LEN. Anything else?
>

Yes.  
	- Last paragraph of section 22.3.1 (CMSG_FIRSTHDR). I checked the xnet
	doc and it does not require this check.  I agree that this is a good thing
	to do and we should put this into the main body of the document to avoid
	porting problems.
	- Second paragraph of section 22.3.2.  This is new to the API and is not
	specified in Posix or xnet.

> > We don't think this should be treated as "informational" given that
> > many of these requirements are necessary to support the main body of
> > the spec.  Also, the new requirements are being made to posix standard
> > structures and macros.  Something needs to be done to make this section
> > less "informational."
> 
> We could lift out the new stuff and leave the repetitive information
> in the appendix.

That would be great.

>   Erik

Thanks
-vlad

+++++++++++++++++++++++++++++++
Vladislav Yasevich
Compaq Computer Corp.
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
(603) 884-1079
--------------------------------------------------------------------
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]
--------------------------------------------------------------------