> I've incorporated trivial editorial nits to my local copy of the
> draft, and I've not mentioned them in this response.
Sounds good.
> I agree. How about this (which is a total rewrite of abstract):
> This document provides sockets APIs to support "advanced" IPv6
> applications, as a supplement to a separate specification, RFC 2553.
> The expected applications include Ping, Traceroute, routing daemons
> and the like, which typically use raw sockets to access IPv6 or ICMPv6
> header fields. This document proposes some portable interfaces for
> applications that use raw sockets under IPv6. There are other
> features of IPv6 that some applications will need to access: interface
> identification (specifying the outgoing interface and determining the
> incoming interface), IPv6 extension headers, and path MTU information.
> This document provides API access to these features too. Additionally,
> some extended interfaces to libraries for the "r" commands are
> defined. The extension will provide better backward compatibility to
> existing implementations that are not IPv6-capable.
Works for me!
> > General: it would be good to have a proper reference to the posix
> > standards in the references section. I.e.:
> >> 4.3BSD Reno sockets API in 1990. The reason is that these ancillary
> >> data fields are part of the Posix.1g standard and should therefore be
> >> adopted by most vendors.
> Are you suggesting to add the POSIX standard in References explicitly?
> Or are you suggesting to check the latest version of the standard and
> to rewrite the text accordingly (if necessary)?
Definitely suggesting the first.
I'm asking about the second. I wonder, for example, whether someone
familiar with the POSIX/Austin Group work has reviewed the document.
My concern is that there may be some fairly trivial inconsistencies
with this document and the basic API. It would be nice to try and fix
those (if they exist). Can anyone speak to this point?
> > Also, how does this align with the Austin group work and the revised
> > basic API? Are the documents in sync with each other? I say this
> > because the Basic API is apparently in alignment with the Austin Group
> > work. It would probably be useful to have some text saying how this
> > document relates to that standard.
> Hmm, good point. As far as I know, there has been no effort to synch
> the advanced API to other "official" standards. Also, rfc2292bis is
> not as mature as rfc2553bis; 2292bis is a total revise of RFC 2292,
> and backward compatibility is not provided. So, with the following
> point:
> > Early in the introduction, the document should say it is
> > updating/replacing the RFC 2292.
> I'd propose to add the following paragraph to Introduction:
> This document is intended to replace RFC 2292 "Advanced Sockets API
> for IPv6", February 1998. The revise is based on implementation
> experiences of the previous RFC, as well as some additional
> extensions that has been found as important throughout the IPv6
> deployment. Note, however, that this document is still
> informational. Once the API specification becomes mature and is
> deployed among implementations, it should be incorporated to official
> standards, such as POSIX (refer to the document explicitly -if
> necessary-).
Generally looks good, but I might reword it a bit as:
This document updates and replaces RFC 2292. This revision is
based on implementation experience of the RFC 2292, as well as
some additional extensions that have been found to be useful
through the IPv6 deployment. Note, however, that further work on
this document may still be needed. Once the API specification
becomes mature and is deployed among implementations, it may be
formally standardized by a more appropriate body, such as has been
done with the Basic API [RFC XXX]
> > Also, take a look at the most recent changes to the basic API. Do any
> > spill over into this document? One change to the basic API that seems
> > relevant to this one:
> >> . More alignments with [3]:
> >> - [3] does not contain protocol family definitions (PF_xxx).
> >> Replaced PF_INET6 with AF_INET6, or removed as appropriate.
> > This document still refernces PF_INET, etc.
> Okay, I've changed PF_xxx to AF_xxx at least. I'm not sure if we need
> more.
Nor do I. That's why I'm thinking it would be good if someone familiar
with the Austin work/basic API could review the document from this
perspective (if this hasn't been done yet).
> > I note that there are some new ICMP types that have been assigned that
> > this document doesn't seem to reference (e.g., those greater than
> > 138). Should they be added?
> I don't think so. Since more and more new types will come, we need to
> make a fixed point of "feature freeze". And, at least to me, the
> newer types are either immature or less interesting to applications.
OK.
> >> We note that many of the functions and socket options defined in this
> >> document may have error returns that are not defined in this
> >> document. Many of these possible error returns will be recognized
> >> only as implementations proceed.
> > This might have been true the first time this document was
> > produced. Is it still true today?
> As I said above, rfc2292bis is not very mature yet. So, I think this
> paragraph is still true, at least to some extent. How about
> s/many/some/ here?
OK
> >> 5. Extensions to Socket Ancillary Data
> >>
> >> This specification uses ancillary data as defined in Posix.1g with
> >> the following compatible extensions:
> > should this ID also include text relative to the austin group work?
> I'm not sure what this comment exactly means...does the proposed
> change in Introduction answer to this comment?
I'm asking whether at this point in time we should be referencing the
posix.1g work as what we want to align with, or whether its the newer
revision that has been formally adopted by the Austin
Group. Presumably, they are not the same.
> >> operation. Returning the received hop limit is useful for programs
> >> such as Traceroute and for IPv6 applications that need to verify that
> >> the received hop limit is 255 (e.g., that the packet has not been
> >> forwarded).
> > how does this help traceroute? Traceroute needs to set, not receive
> > the ttl.
> Actually, I had the same question before, and I slightly recall
> someone explained the intention at that time. However, I don't have a
> clear memory about it. I admit the description still seems odd.
> So, I don't mind to remove traceroute as an example, though. This
> feature is still useful for other purposed (as described just after
> this part). Unless anyone else clarifies this, I'll remove the
> traceroute usage.
works for me.
> >> To specify the outgoing traffic class value, just specify the control
> >> information as ancillary data for sendmsg() or using setsockopt().
> >> Just like the hop limit value, the interpretation of the integer
> >> traffic class value is
> >>
> >> x < -1: return an error of EINVAL
> >> x == -1: use kernel default
> >> 0 <= x <= 255: use x
> >> x >= 256: return an error of EINVAL
> > note that the terminology surrounding diffserv/traffic class has
> > changed (see RFC 3260). Is the current API still OK? there are only 64
> > diffserv values now. (I think this is OK, but the authors should recheck).
> I've asked this to itojun, who originally proposed this socket
> option. Our decision is we should just go with RFC 2460 definitions
> (not 3260). So, the current text will not need to be revised.
OK.
> >> ENXIO The interface specified by ipi6_ifindex does not exist
> >>
> >> ENETDOWN The interface specified by ipi6_ifindex is not enabled for
> >> IPv6 use.
> >>
> > Indention not right. (too far to left)
> Are you talking about the space between the keyrword "EXNIO" and its
> description, etc? If so, I first must point out that this part is
> aligned with the longest keyword (EADDRNOTAVAIL). I don't mind to
> change the indentation policy, but is it really necessary?
This is minor formatting issue. In the ID, the terms "ENXIO" and
"ENETDOWN" are all the way at the left margin. But all the other
text in the document is indented 3 spaces. This seems to be an
exception here.
> >> int inet6_opt_init(void *extbuf, size_t extlen);
> >>
> >> This function returns the number of bytes needed for the empty
> >> extension header i.e. without any options.
> > I don't understand this sentence. Does this then always return the
> > same value? And doesn't an "empty" header require 0 bytes? Or is this
> > actually "length remaining"?
> > Actully, the "length" field is weird in subsequent usages to. Is it
> > really a length, or an offset into the options? Calling it length is
> > confusing. Is it too late to change this?
> Yes, it always returns the same value (except -1 for errors). In our
> implementation, the value is 2 (the length of the "next header" and
> the "length" fields of an IPv6 option header), but I think the actual
> value can be hidden from the caller.
Right. If the function always returns the same value by definition,
why return a value at all?
> As shown in the usage examples in Section 23, the "length" value is
> actually used as a kind of "offset." I don't think the current text
> is confusing, but we can rewrite the description using the term
> "offset". (It would not be too late, because the change will not
> break compatibility to existing implementations). Do you think we
> need the change?
Personally, I think the term "offset" would be clearer since that is
indeed what the variable seems to be holding..
Thomas
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
