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

From: Erik Nordmark <[email-masked]>
Date: Tue, 31 Aug 1999 17:46:16 -0700 (PDT)

[Resent with correct address]

>----------------Begin Forwarded Message----------------<

Date: Tue, 31 Aug 1999 10:18:58 -0700 (PDT)
From: "Erik Nordmark" <[email-masked]>
Subject: Re: Comments on 2292bis (Adv. API) (2)
To: "Vladislav Yasevich" <[email-masked]>
Cc: "IPNG Working Group" <[email-masked]>, [email-masked],
[email-masked], [email-masked]

> 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?)

> - 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?

> 
> Section 10 [page 37]
>   2040    All Hop-by-Hop options must be specified in a single ancillary data
>   2041    object.  Should multiple be specified the implementation might
> choose
>   2042    an arbitrary one or drop the packet.
> 
> - Does this refer to multiple options or multiple ancillary data objects?

The latter.

> 
> 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.

> 
> Section 13.
> - Why does this section exist in addition to section 18 (TODO and Open
> Issues)?  Should this be merged into one section?

Because it existed in 2292 :-)
Once we are done there will hopefully be no such section - just
a section with changes from rfc 2292.

> 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?

> 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.

> 
> Section 22.3.2 [page 51]
> - It might be good to qualify that cmsg is a pointer to the cmsghdr struct
> returned by a previous call to CMSG_NEXTHDR() or CMSG_FIRSTHDR().

Could do that - but I don't want to make this spec a tutorial 
on ancillary data since there are already books covering that subject.

> Section 22.3.4 [page 52]
> - This sentence is a little confusing, since the macro does not in
> fact allocate space:
>   2905     ....  This macro can be
>   2906     used, for example, to allocate space dynamically for the ancillary
>   2907     data.

I'll fix it.

> Section 23.1:  The example starts with:
> 
>        void  *extptr;
>        int   extlen;
>        struct msghdr  msg;
>        struct cmsghdr  *cmsgptr;
>        int   cmsglen;
>        struct sockaddr_in6  I1, I2, I3, D;
> 
>        extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3);
>        cmsglen = CMSG_LEN(extlen);
>        cmsgptr = malloc(cmsglen);
>        cmsgptr->cmsg_len = cmsglen;
> 
> Should the last three lines shown here be changed to:
> 
>        cmsglen = CMSG_SPACE(extlen);
>        cmsgptr = malloc(cmsglen);
>        cmsgptr->cmsg_len = CMSG_LEN(extlen);

I have a general TODO on this. The fact is that both CMSG_LEN and CMSG_SPACE
work when there is only one ancillary data item. But I think it makes sense
for constency to adopt your proposal.
(Turned out you found the one and only example - I thought there was more
brokenness.)

  Erik
>----------------End Forwarded Message----------------<

--------------------------------------------------------------------
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]
--------------------------------------------------------------------