Hi,
I may still object to it being a standards document. I read roughly the
04 draft. My main issue is that I do not believe one should EVER use a
site-local address when sending to a GLOBAL address unless one has a
global address available. This does not appear to be a requirement of the
algorithm, but I will check again on my plane ride to Seattle. If it is I
can't see any argument changing my mind for the default behavior.
As far as it being standards tracked I will forgo that issue and the
reason is that precedence has been changed via ngtrans with some of the
specs being standards tracked for transition and rich's work is better
than a few of those in some instances and if they are standards track then
so should this be. I do believe though we in the IETF are on a slippery
slope here and need to be careful for any pandora's box we have opened for
lets say 2006 when we are working on technology we may not for see now as
standard vs informational. I should probably write a position paper on
this for the IESG and IAB as an objective treatise of IETF epistemology.
As far as policy I hav changed my mind on this a bit because I think we
could cause a mamor problem with IPv6 if we don't at least give some
default guidance to the vendors and market regarding use of our multi
scoped addressing architecture. My normal laizze-faire view of our work
here and my support or not support needs to be tempered in this case.
But then we get down to what is right and wrong.
Using same scope should be done as DEFAULT. Anything else is very very
bad. My belief is that what Rich did. But want to check one more time on
the plane.
My other concerns are how the wording is in the selection process and if
the spec tells me how I must implement this in libc, APIs, and most
importantly how I would do the conditionals and data structures to support
the draft. If it is left open and not forced by any IETF SHOULD or MUST I
am fine with it for my reasons above. I will check this on the plane
too.
As far as the issues not being resolved and the chairs sending a last
call. Well I will assume they belived the last call will flush the final
discussions out on the list. But I do think all the attached issues
should be resolved.
thanks
/jim
On Fri, 25 May 2001 [EMAIL PROTECTED] wrote:
>
> >This is a IPng working group last call for comments on advancing the
> >following document as a Proposed Standard:
> > Title : Default Address Selection for IPv6
> > Author(s) : R. Draves
> > Filename : draft-ietf-ipngwg-default-addr-select-04.txt
> > Pages : 20
> > Date : 14-May-01
> >Please send substantive comments to the ipng mailing list, and minor
> >editorial comments to the author. This last call period will end two
> >week from today on June 7, 2001.
>
> were there concrete agreement made about standard-track/informational?
> i find the following on IETF50 minutes, nothing else (correct me
> if i'm wrong). were there any poll on mailing list made?
> http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001.txt
>
> itojun
>
>
> ---
> Jim Bound thinks this shouldn't be a standard, should be informational.
> Thinks is policy. This should be suggested recommendation, not default.
> Draves: Thinks this document does have implementation requirements.
> "Must" requirement have implementation consequences. Bound: Doesn't
> agree with some of the choices (e.g., selection of site scope as source
> to send to global destination).
> (snip)
> Nordmark: Thinks this should be standards track. Splitting between must
> and should.
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
