Subject: rfc2553bis Update overview of assumptions, goals, etc.

From: Jim Bound <[email-masked]>
Date: Thu, 27 Jan 2000 13:04:28 -0500

Dear WG,

It is time to update because of the scope_id issues RFC 2553, the work will 
be rfc2553bis.  Before I start changing text, editing etc. I would like to 
be clear on the input and issues we need to resolve in the spec.  First I 
present some assumptions, then the changes in general that must be made per 
all the input.  Once we get that level of understanding I can then start
changing the spec.  All of this needs some discussion.  Lastly I present
the reviewers of this update that are needed to achieve consensus on
this spec.

IMPORTANT: The reason we are updating the spec is because of the
scope_id issue.  This is not a free-for-all to put everything people
want in the API, we have shipping products now, existing users, and
binary compatibility is imperative for this API and I would also add
source portability.  

Assumptions:

Not being done in rfc2553bis at this time I assume these will be info
rfcs?: 
A:  A paper will be written for scope_ids (carl williams)
B:  A paper on concatenating scope_ids and addresses (JINMEI Tatuya)
C:  A paper on literal IPv6 addresses with port numbers (TBD)         
D:  A paper on multihoming API issues (TBD)
E:  Others ?????????????????

XNS Work.

We will update text to be consistent with XNS version of the API you can
view this work at: 
http://www.opengroup.org/publications/catalog/c808.htm

Changes to rfc2553bis:

  1.  Edits to the Document we may have missed.
  2.  Update wording of rfc2553bis to be in synch with XNS version.
      For example section 3.10 will be updated to reflect what has been
      done XNS for struct sockaddr_storage and the additional error 
      vals will be added to getaddrinfo/getnameinfo.
  3.  getipnodebyname/getipnodebyaddr will be removed from the
      main document and moved to an appendix.  
  4.  getaddrinfo/getnameinfo need to be updated so all behavior
      supported by getipnodebyname/getipnodebyaddr is supported.
  5.  Header Files that should be added to the spec.

Some sin6_scope_id discussions:

1.  Need more text further describing its use or take the relevent
papers above and add as an appendix.

2.  The sections under section 4.0 Interface Identification should not
be altered to accept / send scope_id, these are useful functions and
this is not needed.

3.  Likewise for the Multicast functions in section 5.0 as stated in #2
above.

4.  inet_pton and inet_ntop should not be changed as they are useful
functions to work on addresses.  We need to add text to getaddrinfo
regarding implementation of strings containing address+scope_ids.

5.  Essentially the reason to moving to getaddrinfo/getnameinfo should
hide this API from dealing directly with scope_ids.

Reviewers for consensus of rfc2553bis update:

 - IPng WG
 - XNS WG
 - Internet Software Consortia and BIND Workers 

All discussion must take place on the IPng mailing list.

Comments and Input?

regards,
/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]
--------------------------------------------------------------------