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

From: [email-masked] (Tim Hartrick)
Date: Wed, 4 Nov 1998 20:20:33 -0800

Jim,

> 
> I do not believe these changes are warranted and our namespace has been
> tested in practice not theory.  I do not see the value of causing this
> extra work for implementors of IPv6 and reject 98% of Chris's input.
> The name space has already proved pollution does not exist on our
> platforms from this WG.
> 
> In addition I recommend if XNET in its standards arena wishes to produce
> an update to this work it may do so as part of its process.
> 
> But it is up to this working group to decide.  If you want these changes
> I will do the editing and it will take me probably sometime, but I will
> do it as expediently as possible if we have consensus.  And in this case
> a rough consensus is simply not enough as it is too much work, as any
> who implement this stuff will tell you, and I am one who implements it
> too.
>

I agree that most of these cosmetic name changes are unnecessary.  I am
personally pretty tired of changing the names of constants back and forth.

My only concern and it should be a concern to you as well is that XNET will
unilaterally make these changes to the XNET documents.  This would be real
bad for implementors that need X/Open branding.

If someone deploys using the current draft and then they need to get X/Open
branding in the future it will require a new second name for almost everything
related to IPv6.  That would be real bad.

What I would like to know from Chris is what are the consequences if this
group gives his requests the thumbs down.  Will X/Open then turn around and
make the changes unilaterally thus putting folks who need X/Open branding
squarely between a rock and a hard place in terms of the namespace problem.

No matter what X/Open does the problem is solvable via appropriate pre-
processor conditionals however it sure would be nice not to have two defines
for the same constant toggled based on whether the application is trying
to be X/Open or IETF "compliant".

So what is the word Chris?

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: Jim Bound <[email-masked]>
Date: Thu, 05 Nov 1998 09:55:42 -0500

Tim,

I agree with your concerns and the WG should consider it.  I agree also
what is Chris's intention, we need to here?

ALso there are other datapoints:

1.  Not all implementations are 1003.1 compliant so that wording in this
spec should never happen regardless of what XNET does.

2.  XNET is not what it was yesterday.  I am not sure anyone cares about
XNET or TOG in the market.  This should be verified though.

3.  Representatives for XNET is a closed body as far as meetings 
etc.  The members I am aware of now are (and Chris correct me if I miss
someone):  

       Compaq
       Sun
       HP
       IBM

    I for one from Compaq will put on my company hat if our spec
    is accepted as is to sugggest to other members of XNET we leave the
    IETF Base API spec in place, and not change it.  

    If Sun, HP, and IBM do the same Chris's proposal would not see the
    light of day in XNET.  

4.  Lastly it is not up to Chris and it is up to the XNET members and I
am on that mail list too.

So the question may be will Sun, IBM, HP, and Compaq vote for this not
being supported by XNET and leaving the spec as is.

On this mail list I am wearing my individual hat not my company hat as
best I can.  I for one don't like the idea the more I think about it 4
(or a few more) vendors controling what this API does or does not do.
I think that is bogus as a standards participant and if this WG does not
believe the changes are needed they should not be made.  

We should not change our spec because XNET changes it, the spec should
just pass thru XNET without this change are my thoughts now.

/jim