Standards track is clearly right for this doc. It isn't just
policy - in fact, it isn't really policy at all. It expressly
says that local policy can override the rules, but otherwise
specifies how nodes should behave, and I think specifies stuff
that is needed for correct interoperbility.
I would delete the (I think just one, but I might have missed something)
reference to getaddrinfo() though - what is done in that func, and
what is done elsewhere, really is a local implementation issue, and
shouldn't be in this doc. Don't specify (to a large degree, don't
even hint at) how or where it should be done, just that it should be.
For Jim ... I think you'll find if you read the doc, that it meets your
requirements on site-local and global addresses - it will pick addresses
of the same scope if such addresses exist. That is, unless that has
been overridden by the application (or something) of course - that is,
the draft doesn't prohibit using a site local address when sending to
a global, it just won't generate that by itself unless no global is
available. That's how it should be I think.
I happen to believe there are good reasons for sending to a global
address from a site local - but when that's do be done it ought be
done by the application/library/whatever deliberately, the way the
draft has it is fine - absent other info, send to a global from a global.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
