sorry. Do not use site-local when sending to global if one has a global
source address should be the default.
/jim
On Fri, 25 May 2001, Jim Bound wrote:
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
