Steve,
>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).
I know exactly what each "PRODUCT IMPLEMENTATION" offers and the
idea of scoping is not even on the table for deployment. No one is even
suggesting who ships real products breaking the server apps I spoke of
they would be out of business right now for IPv6. Hello, Mr. Customer I
am vendor X and here is my new IPv6 product, but beware it will break
your network server apps but go ahead implement sitelocal addresses with
overlapping servers. I am speaking of an Open Systems enviornment where
all IETF standards are adhered too and proprietary extensions are
frowned upon by the customer, that would break multi-vendor total
interoperability.
But we need to work on it quickly I agree. This API is for now not
tomorrow. It could be we need adjuncts to the API, and new specs like
we may have new Addressing specs.
As far as my idea. No way will I have a draft before Pittsburgh. That
ain't happening. I am willing to present the idea on the agenda
depending on what times/days IPng is happening at Pittsburgh.
Thats ujp to you and Bob. I did not suggest it as I could not get a
full draft written up by the deadline or the IETF meeting.
But I also have one hell of an argument prepared for the IESG if we
don't fix the overlapping app problem in our deliberations for scoping.
I think I will at least raise some questions.
>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.
This is possible if we qualify for now that it is just an interface.
This is the first time it came up really we have been living with do
what IPv4 did. We can do different but I don't want to open up a six
month debate on the API update and we are now faced with backwards
compatibility so we will need to support both. We can't break ISV apps
each time we update this API spec and after this update we move to API
part II or put it in the Advanced API. So we will need both if we go
this route. Again folks have already ported applications we cannot
break those apps. So for this spec deprecation is not a good idea.
>> >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.
Hmmm for some reason I can't find the -01 version. I will check that.
But I thought the draft was fine except I want another draft that makes
all addresses except link-local unique within a site. This prevents
breaking Internet Server Apps that cross site boundaries. I sent input
to that affect. I do need now to check you did nothing to prohibit what
I want to suggest but I don't think you did?
regards,
/jim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
