Subject: Re: sockaddr_storage issue

From: Jim Bound <[email-masked]>
Date: Wed, 15 Dec 1999 15:21:22 -0500

Hi Carl,

>The XNET document has other changes that we should 
>also adopt with RFC2553bis (e.g., dealing with error codes 
>returned by getnameinfo()).  If the documents are not in sync,
>then we will have varying implementations (not good for IPv6
>adoption).  The KAME folks don't have access to the XNET documents 
>and have no idea what changes we made to getaddrinfo() a few months
>back.  Indeed, there were a number of substantial changes made to the 
>IPv6 socket API within the Open Group.

Yes we have to pick up the continued work from the xnet docs.  Also you
give the exact reason why we must have an RFC2553bis.  So I for one
agree with you.

>>> 1.  Deprecate getipnodebyname
>
>
>What about an applicability statement instead.  Unlike gethostbyname2()
>there is alot more code and porting documents making use of
>getipnodebyname().  I am not sure it is a good idea to banish it
>from the RFC as we did for gethostbyname2()?

Sure and I think we all agreed to do that.  I am using slang here by
saying its shot in the head.  Bottom line is I know of no ISV that will
use getipnodebyname if I also tell them that it won't work with
scope_ids.

>>> 2.  Make sure functionality and flags from getipnodebyname are supported
>>>     in getaddrinfo.
>
>I have given this thought (e.g., support of AI_ADDRCONFIG, AI_DEFAULT, AI_ALL
>and AI_V4MAPPED as new flag settings for getaddrinfo()). 
>We need to detail the behavior when any of these flags are specified
>with the various ai_family definitions (PF_UNSPEC, PF_INET, PF_INET6,...).  
>All the possible return error values need to be documented as well.  
>I can send out a proposed specification.

That would be great carl.  Do you wan to take a stab at the
applicability statement above too?

>Finally, it was noted that the sin6_scope_id is under specified (RFC2553).  
>For example, Erik raised the issue of what should the semantics be when 
>sin6_scope_id is set in a bind()? (and other issues).  Should these 
>clarifications be a separate I-D and then XNET could take the new RFC into 
>account when clarifying their specifications?

The reason we are in trouble now with getipnodebyname is because we left
it as an exercise for later to deal with scope_ids.  I don't think we
should do that again.  Yes we need to specify all cases we can think of
now.

I also believe XNET should be very much part of the update to this next
iteration.  So my plan is to include them in the review and input period
and they are part of consensus for this effort.

thanks
/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: Carl Williams <[email-masked]>
Date: Tue, 14 Dec 1999 23:28:17 -0800 (PST)

>    
>
>Do we have consensus on dropping the underscores i.e. make is ss_family?
>

As was pointed out the XNET document already has this change and
those vendors belonging to the Open Group already implement this
change.

Carl