In your previous mail you wrote:
Good lord, if I had known what it was going to lead to I would never
have suggested adding a scope (zone) identifier to the sockaddr_in6.
=> the can of worms was opened when we added scopes to the address
architecture or if you prefer when we try to replace Fortran by Algol (:-).
Can anyone explain how being able to restrict the flow of globally
addressed datagrams to some set of interfaces is going to be useful to
Joe Average application writer?
=> Joe Average will use the zero sin6_scope_id which will give the default
and unique global zone. And if (s)he puts a random value (applying the
original meaning of "average" :-) then (s)he should get an error.
What is wrong with simply numbering an attached nodes interfaces starting
at one and numbering a nodes attached sites starting at one?
=> nothing, I'd just believe you don't like the new model (and the
last paragraph of section 7 of the scope arch I-D).
I am just not getting what we are gaining or likely to gain by attempting
to number these zones from the same identifier space and then allowing
all these degrees of freedom in how the sin6_scope_id is interpreted.
=> read the section 7.
I find it difficult to get most application writers to understand select().
=> I don't understand the link for the select() system call?
Do we really believe that this level of complexity is going to be understood
sufficiently by application writers to make use of it.
=> this can be a problem but application writers can just put zero in
sin6_scope_id... This will work without any trouble on a single interface
host (more than 90% of the cases?).
Regards
[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]
--------------------------------------------------------------------
