Subject: (IPng 6701) Re: Namespace Pollution and the IPv6 Basic API

From: Chris Harding <[email-masked]>
Date: Thu, 05 Nov 1998 17:16:13 +0000

Hi -

Let me try to reply to Jim's and Tim's comments in one message.

First, regarding the Feature Test Macros. These comments are largely a
matter of preciseness of language. The Basic API as per the draft is
unlikely to break existing applications. But you can't _guarantee_ this
without Feature Test Macros, or some equivalent mechanism. So I suggested
that they be mentioned - but not specified - in the basic API. It won't
necessarily hurt if they are not mentioned because this is the sort of
thing that can be added in a formal standard without overly disturbing
implementations or applications, and perhaps a formal standard is the
appropriate place to do this.

For clarification, the specific reference I was suggesting be included in
the Basic API is to IEEE Standard 1003.1 - the main POSIX Standard that
covers fork(), exec(), open(), close(), wait(), and about a thousand  other
well-known operating system primitives - rather than to P1003.1g which is
the draft extension to it for networking services. I also listed the
namespace reservations made by P1003.1g, but purely as background to the
proposed name changes.

Actually, I care a lot more about the proposed name changes than about the
Feature Test Macros, because they will make the API easier to use. If IPv6
and the Basic API to it are successful, there will be many more programmers
using the API than implementing it. And while an implementor may spend
several working years on what goes behind the API, and know every wrinkle,
the main concerns of the user are typically elsewhere. A user will want to
spend as little time as possible understanding a service API, and API
designers will do well to make things easy for users. There are cases where
the complexity of protocol APIs have inhibited their take-up and have
inhibited use of the protocols.

But I would not advocate, and I don't think that any of the present members
of XNET would advocate, changing the names after they have been agreed in
the IETF. I (and I think they) fully agree with Jim and Tim that this would
not be the right road to go down. It would confuse matters at what will be
a crucial time for deployment of IPv6. That is why I make the proposal, in
the IETF forum, at this time. I do so in the belief that the ipng is the
body responsible for the design of the Basic API, and will accept the
implications of that responsibility. These include giving thought to
usability of the API, and to compatibility with related standards produced
by the wider API community.

Finally, in view of Jim's most recent mail, I have a question for the IETF.
I have been to several IETF meetings now, and attended working group
meetings that filled their rooms and overflowed into the corridors, but at
which fewer people spoke than normally do at meetings of XNET, which as Jim
points out are much more sparsely attended. I have then been to Plenary
sessions at which someone complains about this situation and stresses the
need for wider input. So I have to ask, is the IETF an open forum in which
comments made by anyone will be given due consideration, provided they are
made in due form, or is there a closed circle of the "chosen few" who
welcome outside participation only when it gives them rubber stamp approval?

Regards,

Chris
+++++

-------------------------------------------------------------------------
           Chris Harding
  T H E    Development Manager
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:[email-masked]   Ph: +44 118 950 8311 x2262
           WWW: http://www.opengroup.org    Fx: +44 118 950 0110  

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.
-------------------------------------------------------------------------
--------------------------------------------------------------------
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: Thu, 05 Nov 1998 16:28:48 -0500

Chris,

>appropriate place to do this.

We believe we will not break existing apps.  Mentioning 1003.1 is OK.
But that is not what was proposed.  Let me suggest to you some alternate
wording in another thread later.

>namespace reservations made by P1003.1g, but purely as background to the

As one whose name is on 1003.1 from many years ago I understand fully
the jist of 1003.1.  My issue is that a non-Host normal stack may be used
for IP, and even the most basic 1003.1 forms may not exist
like exec/fork paradigm.

>inhibited use of the protocols.

I for one understand that and your intentions.

>by the wider API community.

I agree with that too and I would claim we did give thought to that too.
But I will respond more after your last paragraph.

>welcome outside participation only when it gives them rubber stamp approval?

Of course the IETF welcomes all participation of a technical nature
which the proposed name space clearly is for this discussion.  But we
also face that this API has been in process for a long time so any
changes have to be deemed as pretty important to be done and accepted at
this point in time.  I think the changes you propose are essentially
cosmetic and don't add any new value to warrant all the implementors
changing their implementations.  That was my individual input.  Now we
need to hear from others so give it a chance.  We have until next
Wednesday to decide (11/11).  I clearly stated that if the WG wants this
proposed change I will start editing the document.  So the process is
working for you.  Yes I am a formiddable person who does not support
your view and I have that right and am voicing it.  But I always go with
WG consensus and have many times, when I disagreed with it.

What you have to accept is your proposal may be rejected not just by me
but by this process.  If that happens it does not mean we did not listen
or even we think it is a bad idea.

Had you provided your excellent proposal awhile ago long before running
code existed I think it would have been accepted.  Now your proposal is
up against a lot of running code and most likely being integrated into
product level base line releases.  The question now is adding your
suggested change important enough to take a hit in time to make the
change.  I think it is not.  But the forum is open to tell me I am
wrong, or your idea is very important to incorporate.

I have had one very strong implementor and proponent of IPv6 send me
private mail that this change is unacceptable fyi.

There is no closed chosen few for this particular event.  I will not
speak or answer for all the IETF as I can't.  But this API has
been completely open.  But, running code has a place in this standards
body that it really doesn't quite have in other standards body.  Running
code has a status almost like its own veto power in some cases.  To
avoid that veto power ideas have to pretty good and needed.  Running
code means we need to listen to the implementors as a group of people.
So they are a faction for the lack of better words right now.  Yes that
faction has some weight for any of us in the IETF.  In this case I sit
in that faction.  In other cases in the IETF I am not in that faction
but am very glad they are there across the board usually in this
community.  So yes your input is up against that faction and the fact
that IPv6 deployment is in process and your change will affect time to
market and costs of IPv6 development for the API.

At the plenary this next IETF 43 I have a new issue and it is happening
here and elsewhere in the IETF.  That is input that is too late and then
holds up the processes.  We have to have a penalty or somethign for
input that is too late.  There is absolutely no reason why your input
could not have come right after 2133 started to be rechecked earlier
this year in the spring of 1998 at the L.A. meeting.  All the way back
at draft-01-new version.  ipv6mr, sin6, etc have been around long before
RFC 2133 let alone the 3 drafts prior to the present 03 draft.  That is
the problem you face now, not that the IETF is not fair or operates in a
closed system, but that your very very late with this input for this
API.

thanks
/jim

---

From: Chris Harding <[email-masked]>
Date: Fri, 06 Nov 1998 16:05:19 +0000

Dear Jim,

Thanks for your reply. All that I am asking is that my comment be
considered on its merits. Of course I don't expect it to be accepted just
because XNET asked me to make it. I hope it will be accepted because it
makes good sense. That's how it looks to me, but if the consensus is
otherwise, so be it.

As to the timing, I do take your point that it would have been better to
make this comment earlier (I did in fact make a similar one some time ago
on the draft Advanced API). But - perhaps I am misunderstanding the process
- I thought that "last call" defined the point after  which a comment would
be too late. Perhaps this is something that rightly should be raised in
plenary, so that a proper understanding can be established if there is in
fact an earlier cut-off point.

I hope that we now understand each other. For my part, I will now leave the
discussion up to other members of the group (unless someone raises a
technical point on the comment that I need to elucidate).

Regards,

Chris
+++++

---

From: Jim Bound <[email-masked]>
Date: Fri, 06 Nov 1998 11:53:32 -0500

Chris,

Thanks for the mail.  I am out of it too.  

For what it is worth the proprosal is sound and a good piece of work. I
can't get past the shipping of the IPv6 API though.  I feel bad about it
but I have to do this often in my job too.  Not fun for sure.

thanks again for your hard work on this effort, lets see what folks say.
/jim