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

From: Mukesh Kacker <[email-masked]>
Date: Thu, 12 Nov 1998 07:20:25 -0800 (PST)

I would just like to add some personal comments/perspective on this issue
since some of the discussions went more towards adding heat than light.
(Just comments, no changes here so it is not important this didn't go out
 before yesterdays deadline :-))

What Jim has just submitted represents a good compromise/middle-ground of
what was achievable in the namespace area without causing too much pain.

In my view, the only significant thing not adopted is what Chris explained
as a design principle in formal standards that standards should use
a "minimalist" design principle and keep their list of reserved prefixes
as brief as possible. In itself, that is a good goal for APIs that are
developed from scratch.

However that was in conflict in this case with another requirement of
"Ease of portability of IPv4 applications". The IPv6 Socket API prefixes
are a "logical extension" of the IPv4 Socket API prefixes which makes
porting/extending applications easier. That design goal has represents more
value BOTH to system vendors and application writers that whatever is achieved
with a "minimal" prefix list.

Having said that, I would like to thank Chris Harding for his proposal and
Jim for adopting what was possible from that which would keep changes if/when
these interfaces are added as formal standards to a minimum.

Since a lot of "heat" was also part of the discussions, probably because a lot
of us feel that formal standards have caused unnecessary pain in the past by
adopting some gratuitous changes where the gains did not justify the pains
or even made things worse towards usability of the interfaces. The best way
to avoid that is to work towards a process more like how IETF protocol
standards process works where implementations and field experience is required
before full standardization and reviews are more open. And for developers
to actively participate in reviews when they happen.

However, formal standards do sometimes represent a forum where one can document
these interfaces better, add language that reduces ambiguity, refine error
codes and take into account any system specific differences which adds good
value. In general, they make possible code that is not a pile of
#ifdef (PRODUCT_NAME) which is hard to maintain in a portable manner and
ideally take implementation experiences into account.
If changes happen during formal standardization, I hope the developer community
here will review the standards and give feedback and I hope the standards
process will be open enough to make the widest possible review possible and
balance the "gain" vs "pain" issue for any changes.

--------------------------

-Mukesh Kacker
 Internet Engineering
 Sun Microsystems Inc.
 [email-masked]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------