>>>>> On Wed, 27 Jun 2001 22:37:05 +0700,
>>>>> Robert Elz <[EMAIL PROTECTED]> said:
> | >> - Fix Authors address wrt Rich.
> | I don't know a common sense in such a case, either. rfc2553bis has
> | the same issue, and the latest draft simply removed his address.
> I'd wait and see how much of the doc ends up changing. If it is
> comparatively little, leave him as an author for the next rfc version
> then move him to acks for the one after that (if there ever is another).
> If there are lots of changes, do it now. If he stays as an author, in
> the authors' address section, just list him as "W.Richard Stevens (deceased)"
I think it's a reasonable approach.
> | > 2.1.2. IPv6 Extension Headers
> | >
> | > I think it would be useful to define a generic structure to specify
> | > IPv6 extension headers, since we sometimes encounter a situation where
> | > we can't detect the type of an extension header but should deal with
> | > the header.
> Huh?
Please forget about this topic. It was once discussed, and the
discussion was over with the result that you just want (i.e. we do not
include this structure).
> | But I might hold off for a while on icmp name lookups and site prefixes
> | so we can see what will happen with those.
> | If somebody wants to convince me that the WG will approve of that work
> | I'm game to add it to the API spec.
> Add it to the drafts now, so the API can be considered, on the assumption
> that the specs will be accepted. It takes no time at all to yank that
> part if that turns out to be an unwarranted assumption, but quite a long
> time of review and updates to add it later if it turns out to be needed.
> The name lookups spec in particular needs attention, as it needs to be
> determined just how the name that is returned is obtained. Is it always
> to be the same value as hostname(2) or can a node set one name to be used
> as the result of hostname() (to be used in local log reports, prompts, ...)
> and another to be returned to other nodes? No opinion at the minute,
> just a question that needs an answer.
Hmm, as I wrote in a previous message, I myself we should fix the API
without these "ongoing" stuff. If we're taking this approach, we'd
have to include structures for
draft-ietf-ipngwg-router-selection-00.txt
or even
draft-vida-mld-v2-00.txt
(although the latter one is an individual draft at this moment),
and probably more.
> | > 4. Access to IPv6 and Extension Headers
> | What do others think?
> | Should we specify this amount of detail?
> Yes. That's one of the most important factors in an API spec - what
> state the world will be left in when things go wrong. Otherwise, on
> any error, the only option is to close everything down and start again.
> Often that's not practical.
> | > 6.3. Specifying/Receiving the Hop Limit
> | I'll add that.
> | Using a zero length option should also work.
> Pick one preferred way, and doc that one, not several variations that
> all should work.
The 02 draft has the following text.
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'm okay with this text, although this provides two different ways.
> | If you don't know the number of hops before starting to build the routing
> | header you don't know how much memory to allocate for the option/ancillary
> | data.
> What this leads to is the question of who is responsible for the accounting.
> That can be either way - it can be done inside the API, or by the application.
> A decision just needs to be made (doing it inside the API functions makes for
> a simpler interface, but generally one with greater overheads).
I agreed with the current spec in the past discussion, so let's keep
this point.
> | The API isn't really designed to deal with anything but the recommended
> | way of doing extension headers i.e. at most one hbh header,
> | at most one destination header before a routing header,
> Yes - the "get the header by name" type interface is fine for some
> applications, but not nearly powerful enough in general, what is most
> likely needed is a "get the next header" interface, which returns the
> header type, its length, and its data, as well as a cookie to hand to
> the API the next time it is called (0 for the first call) so the API
> knows where it was up to in the list. The caller should provide space
> for the data - with as much as fits being returned (the returned length
> will indicate whether all of the data was included or not - by passing
> a data buffer length of 0 the application just gets the header type/length
> info back, so it can see what headers exist, and how big they are).
> With that, the "get the routing header" can be implemented as library
> routines rather than via the interface to the stack if desired.
We actually have to reconsider the extension header issues, as I said
in the first message in this thread. Your idea above seems to be a
good candidate. We'll discuss the issue in a separate thread later.
(So I'll basically skip the discussions below related to this issue)
> | > 8.2. Sending Hop-by-Hop Options
> | > What should the kernel do if an ancillary data contains multiple
> | > IPV6_HOPOPTS objects?
> |
> | I don't really care and I don't see a good reason for nailing down
> | this behavior in the specification. "Implementation defined".
> That seems reasonable - it is an "only buggy apps do that" type thing.
> But the doc needs to actually say that, not just ignore it.
I don't think so. I believe the protocol stack (normally the kernel)
should prevent (at least) non-privileged users from sending invalid
packets according to the protocol specification.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
