Date:Wed, 02 Oct 2002 13:17:53 -0400
From:Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| If you believe there is some sort of process problem here,
I didn't say that. I didn't ever say there was consensus to change
things, just as no-one (othe
> From: Robert Elz [mailto:[EMAIL PROTECTED]]
>
> I also assume that the necessary two implementations of all
> of this, that will allow a doc containing it to advance to DS
> have been documented in the implementation report?
This draft is up for PS, not DS.
--Brian
---
Date:Thu, 3 Oct 2002 03:14:50 -0700
From:"Brian Zill" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| This draft is up for PS, not DS.
It is entirely possible I've gotten myself confused here, but Rob Austein's
message that started this thread said ...
> | >Every router (whether IPv4 or IPv6) knows what subnets its own interfaces
> | >belong to (or, more accurately, what subnet numbers are assigned to
> | >the links to which it has interfaces). That is the most basic
> | >configuration info provided to a router -- it is provided with t
Hi Brian,
Just to clarify...
The subnet-local multicast scope is defined in the Addressing
Architecture document, which been sent to the IESG for
consideration as a draft standard.
Perhaps the mention of scoping has you thinking of the scoped
addressing architecture? That hasn't been sent to
Ah yes, sorry, I mistakeningly thought that we were discussing the
scoped addressing architecture draft in the second thread. I probably
shouldn't post at 3 AM.
--Brian
> -Original Message-
> From: Margaret Wasserman [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 03, 2002 04:58
>
> - CMSG_SPACE
>- return type could be socklen_t to match msg_controllen
>- argument type could also be socklen_t
>
> - CMSG_LEN
>- return type could be socklen_t to match cmsg_len type
>- argument type could also be socklen_t
>
>Short of a changing all of these to socklen_t, we
> On Wed, 2 Oct 2002 14:10:35 -0700,
> Michael Hunter <[EMAIL PROTECTED]> said:
>> Additionally, I suspect the removal actually breaks user code so much.
>> As I said before, user applications are usually expected to use
>> library functions for source routing and to not use the ip6r0_ad
>>> recent source code of FreeBSD and NetBSD (which have not supported
>>> 2292bis yet). The only occurrence of ip6r0_addr other than in user
>>> applications is in tcpdump, where no compatibility issue exists since
>>> tcpdump uses its own header definitions.
>
>> Which is telling about the stab
