Subject: Re: rfc2553bis comments

From: Tim Hartrick <[email-masked]>
Date: Thu, 29 Jun 2000 19:02:42 -0700 (PDT)

> 
> > - should we extend this model to the reception side, ie. one matches
> >   only when the incoming interface belongs to the right zone?
> 
> Are you talking about using bind() to limit the zone of acceptance?
> 

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.

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?

What is wrong with simply numbering an attached nodes interfaces starting
at one and numbering a nodes attached sites starting at one?

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.

I find it difficult to get most application writers to understand select().
Do we really believe that this level of complexity is going to be understood
sufficiently by application writers to make use of it.

I am dubious that it will.  I will shut-up now and keep reading.

Tim Hartrick
Mentat Inc.

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Thu, 29 Jun 2000 19:17:19 -0700

>have suggested adding a scope (zone) identifier to the sockaddr_in6.

I was afraid I was going to trigger that reaction.  :-)

>Joe Average application writer?

I doubt that it will.  And if you can ignore all my words of justification
and just notice that I was proposing keeping all of that cruft in the
"Advanced API", you'll see that Joe Average application writer shouldn't
be exposed to it.

Steve

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Jun 2000 11:43:34 +0200

In your previous mail you wrote:

=> 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 (:-).

=> 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.

=> 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).

=> read the section 7.

=> I don't understand the link for the select() system call?

=> 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-masked]

---

From: Jim Bound <[email-masked]>
Date: Fri, 30 Jun 2000 06:46:47 -0400

hi francis,

let me try a non-technical response to define the complexity.

in this community folks like you, tim, carl, erik, jack, itojun,
etc.  are like the gods of network programming and even muck around in OS
internals with network subsytems and some even change paradigms that
have worked for 15 years on the internet in our code bases.  these folks
also understand the work of Dr. Richard Stevens and Turing machines,
etc....

but there is a whole class of "programmer" that builds applications
which the end user really sees and the real reason people buy computers
that do networking.  there job is to ship user space code that people
will pay for to do a business function.  They are usually called
"application" programmers and we are the "systems programmers".

the basic API was written for the "applications programmers".  tim's
comment on select() I agree with.  the select() or poll() sys call is
not intuitive to an application programmer that now has to re-write
their application server for 10,000+ connections because of the Internet
explosion when they wrote it for about 100 connections and might have
not even used select or poll.

part of our job here is to keep the "BASIC" API as simple as possible
and now BACKWARDS compatible for the application programmer who will
port their apps to IPv6.  Its a human thing not just a technical thing.
I am not saying not fix parts that need to be addressed like the issue
of multicast IF.

I will say that after this next release of the Basic API we are done.
It will got to XNET/POSIX and then either some of the stuff I am hearing
in here goes to the Advanced API or to another API we may need for QOS,
IPSEC, whatever...But we must live with the next update for good.
The basic API cannot be a moving target for developers porting to IPv6.

regards,
/jim

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Jun 2000 13:56:36 +0200

=> I agree and if you have seen by last mail you can find in it
two ideas which address this concern.

=> unfortunately you can't give the programming of an application
which have to support 10,000+ connections to Joe Average, and
I am afraid that this applies to multicast applications too.

Regards

PS: a part of my concern about the routing table is this cannot easily
hiden to the administrator and unfortunately Joe Average as an administrator
has a very low skill.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Fri, 30 Jun 2000 09:49:44 -0400

this is where the difference happens between product engineer and other
engineers.  I have no choice but to make joe or mary average work.
and it has everything to do with my view of the basic api.

take care,
/jim