Subject: (IPng 6647) Basic API Update Oct 18th and XNET INput may be coming!!!

From: [email-masked]
Date: Mon, 19 Oct 1998 00:14:37 -0400

Folks,

Thanks for the final edits.  It appears we have a solid spec and folks
have implementations underway.  I will sumbit final edit as draft-03.txt
Monday evening.  It is just edits nothing that affects implementation.

But I heard that the XNET group is not happy with our namespace for the
API, and will be submitting a set of changes for this name space.  I
have advised the Chairs this may be happening.

It is my feeling we should go forward with last call and if this very
untimely and very late input does come in from XNET we can review it as
a WG last call item.

I have not seen any document yet privately or otherwise but here is how
I feel about this right now as an "individual IETF member and Internet
Society member":

  1.  The input is just plain too late from this standards organization,
      (XNET) they have had more than enough time to respond to this
      specification.   This is also not the way to work with the
      IETF as a standards body.  RFC 2133 has been there for a long
      time, with any suggested name space problem.

  2.  XNET does not represent all members on this list but only the 
      UNIX vendors (e.g. not PCs, Routers, BSDxxxx, other OS's), as 
      far as participating interests in that standards body.

  3.  Any name space suggestions must be proven that they are truly needed
      for this API.  At this point in time it is not enough that XNET 
      feels this is a good idea but must prove it.

  4.  If they can prove that this is a good idea, it may be that XNET
      can produce a later draft in their respective technical bodies
      and set of UNIX YEAR/YEAR (e.g. 95, 98) standards.  Then it 
      can be adopted by those supporting those standards.  The Basic
      API Informational RFC can be used as a base for that work.  If
      vendors feel this is important they can implement the change
      at the time the XNET process produces such a standard update.
      Given that this will not break any binary portability of 
      IPv6 implementations.

But at the end of the day it is up to you the working group to decide
what is best.  But I will proceed with the Chairs to request a last
call on draft-03.txt of this very important API which is needed by the
market and IPv6 implementors to become stable now. As previously stated
I will sumbit draft-03.txt Monday evening.

Sincerely,
And a very tired editor and co-author,  
/jim

--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Mon, 19 Oct 1998 15:10:27 -0700 (PDT)

> have advised the Chairs this may be happening.

One potential name space issue that shows up in our implementation
is the use of IFNAMSIZ for the if_*() routines.
This name has traditionally only been used with the SIOC* ioctls
and "promoting" the name to the API might be a bad idea.

So a name like IF_NAMESIZE might be better - that would reserve the
if_* and IF_* name space.

(Our implementation preserves IFNAMSIZ for binary compatibility of the
"old" SIOC{S,G}IF ioctls while using a larger name size for the "large"
ioctls used to carry IPv6 addresses etc. The larger name size is needed
for composing network interface names like "le0.skip.ipqos".)

Thus decoupling the API IF_NAMESIZE constant from the ioctl definition
IFNAMSIZ would allow the implementations to evolve independently of
the API.

The change to the spec would be to replace 3 occurances of IFNAMSIZ.
The change to an implementation would be to add
	#define IF_NAMESIZE IFNAMSIZ

   Erik

---

From: [email-masked]
Date: Mon, 19 Oct 1998 20:23:04 -0400

Erik,

We can take this input as part of the last call that will happen.  I
just submitted draft-03.  We should make a last call on that draft.
What you just sent is a mere editorial fix.  This can be fixed in
draft-04 which will be the draft with edits from 03.  Plus you have an
implementation fix that is pretty good.

thanks
/jim