At 9:31 PM -0400 6/26/00, Jim Bound wrote:
> > - identifying only the outgoing zone (for non-global destinations),
> > and leaving it to the IP layer to choose an outgoing interface
> > within that zone, or
>
>There is not a concept of zone other than in drafts in mail discussions
>and some prototype implementations. This is premature for a real world
>API.
Fair enough. But I believe the API can be written today in a way that
would allow later implementation of zones as proposed, without any change
to that API.
On the other hand, maybe the WG can come to agreement quickly on the
scope/zone architecture, and we can make that explicit in the basic API
spec. (Hope springs eternal.)
> > All this could be done with the single sin6_scope_id field in the sending
> > API, if the local indexes for the interfaces plus all zones (i.e., links,
> > sites, and any additional multicast zones configured on the node) are
> > given distinct values out of the same scope_id space, and if one index
> > value (say, 0) is reserved to mean "unspecified". Then, I think we could
> > probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it).
>
>I would claim all this sounds good but not real. In fact I think things
>will change again if we adopt global unique identifiers for site-local
>addresses which will be presented at some point in time to the WG.
If you are going to propose a different scoping model, I strongly suggest
that you document it in an ID before Pittsburgh. From what I hear,
implementors would like this settled soon (actually, a long time ago).
In any case, I *think* the existing sin6_scope_id field in the API makes
IPv6_MULTICAST_IF redundant, so the latter could be deprecated now,
even if sin6_scope_id is only ever used to identify interfaces, rather
than interfaces plus zones.
> >The scope/zone spec is not "still missing", though it certainly still needs
> >work. draft-ietf-ipngwg-scoping-arch-00.txt was published before Adelaide,
> >and an -01 revision was posted to the ipng mailing list by Brian Haberman
> >on March 22. That -01 version never made it into the Internet Drafts
> >directories (it was posted during the time just before Adelaide while
> >ID submissions were being refused), but we will rectify that ASAP.
>
>Still needs work is an under statement.
I don't recall receiving any comments on the draft, so apart from the work
the authors' know is still needed (mostly discussion of scoping in the
context of mobility), we haven't got any feedback to tell us about other
perceived inadequacies of the current document. I encourage everyone to
look it over (the -01 version, please) and let us know.
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------