Minutes of May 2001 Meeting


Austin/90 (includes corrections 4th June 2001)
Minutes of the 7th Plenary Meeting of the Austin Group
29 May - 1 June, 2001
Reading, UK, Hosted by The Open Group.

Attendees
NameAffiliationRole
Andrew JoseyThe Open GroupChair
Nick StoughtonUsenixWG15, Secretary
Don CragunSun MicrosystemIEEE
Bouazza BaccharCompaqThe Open Group
Andrew GollanSun Microsystems
Joanna FarleySun Microsystems
Ulrich DrepperRed Hat
Jon HitchcockUniplex
Frank PrindleDoD - Teleconference, Tuesday, Wednesday, Thursday
Mark BrownIBM - Teleconference, Tuesday, Wednesday, Thursday
Joe GwinnRaytheon - Teleconference, Wednesday, Thursday
Cathy HughesThe Open GroupEditor

Andrew Josey called the seventh meeting (a.k.a. Austin/M8, since this counting includes a teleconference) of the Austin Group to order at 9:05 am Tuesday May 29th at The Open Group's office in Reading, Berkshire.

Meeting Goals

The goal of this meeting is to review the draft six Common Specifications. The bulk of the meeting will be spent doing issue resolution based on Aardvark comments submitted during the review period. Many of the comments have been predisposed by the editors. These will not be discussed unless there is some disagreement with the proposal.

  1. Administrivia
  2. Procedures Update

    No updates.

  3. Identification of Organizational Reps

    see attendance list above.

  4. Status Reports
  5. Old business
    None.
  6. New business
  7. Consent list
    No new consent items
  8. Issues list
    No new issues
  9. Action Item Review

    1. ACTION TOG IR to convey the decision for XCU ERN 062 to the Base WG for confirmation. CLOSED
    2. ACTION - Jon Hitchcock to submit revised words for XCU ERN 083. CLOSED.
    3. ACTION TOG IR to convey XCUN ERN 086 to the BWG for their consideration. CLOSED
    4. ACTION TOG IR to convey XCU ERN 113 to OgTgBase for their consideration. CLOSED
    5. ACTION TOG IR to refer XSH ERN 022 to BWG for their consideration
    6. ACTION TOG IR to request a resolution from the BWG to ensure that XSH ERN 026 is in scope, with the recommendation that this ERN is accepted.
    7. ACTION Frank Prindle to propose suitable words here CLOSED -- use posix_trace_event()
    8. ACTION Andrew Gollan to write rationale for 2.10.12 socket out of band data state, and the concerns around it.
    9. ACTION Andrew Josey to submit UK ISO ballot comment on sockatmark to cover ISO process if we decide to add it
    10. ACTION TOG IR to ask OGTGBASE: Should we make it mandatory to allow a node with an IPv4 address to communicate using that address via an AF_INET6 socket? I.e. should we change "may" to "shall" in the following (from 2.10.20.2) "If a node has an IPv4 address, then the implementation may allow applications to communicate using that address via an AF_INET6 socket."
    All actions must be closed by 2001-06-10 unless otherwise stated.
  10. Draft & Meeting Schedule

    Draft 7 should be issued June 15 Looking at a ten day recirculation and no new comments or objections. Submit to IEEE Standards Board July 29. We should not need another face-to-face meeting for another five years (well, maybe four years ...)

  11. AOB
    1. Awards

      The following Aardvark awards were presented by Andrew Josey:

      • Le Prix de Gross Aardvark

        awarded to Donn S. Terry for high quantity bug reporting

      • Le Prix de Grand Aardvark

        award to Don W. Cragun for high quality bug reporting

      Nominations are sought for

      • L'Aardvark Reprise - Most often seen aardvark request
      • L'Aardvark Cuille're en Bois - Most stupid aardvark request
      • L'Aardvark Flambe - Most inflammatory email message (the email message that generated the most followups)
    2. sockatmark() function

      The sockatmark function from 1003.1g is not included ... and is urgently needed. Does the scope allow us to include this or do we have to put it in a technical corrigendum? The scope does include a statement allowing changes to be made to make the document self-consistent, and there is currently a dangling normative reference to this function. We could get away with adding it using this as a change -- Andrew is mailing Roger Martin to see if he agrees. We have the text from 1003.1g, and it is ready to go in. We need to get as many people as possible looking at this.

      Looking at this function in the room: there are possible problems caused because the function does not specify whether it blocks or not. There are other methods for testing for a mark ... such as using a signal handler with SIGURG1, or via select. However, these only tell you that there is out of band data around, they do not indicate that you are actually at the mark. ACTION - Andrew Gollan to develop some Application Usage text and examples for sockatmark()
      Revisited, Friday. Andrew Gollan reports that he has checked and not implementations he is aware of will actually block in sockatmark(). Additionally, we can find no examples of code that actually use the underlying SOCKATMARK ioctl functionality. This function would complete the picture for the TCP/IP protocol stack, but is not widely used. ACTION Andrew Gollan to write rationale for 2.10.12 socket out of band data state, and the concerns around it. Andrew Josey has asked the entire ballot group for their opinion on adding this function. ACTION Andrew Josey to submit UK ISO ballot comment on sockatmark to cover ISO process if we decide to add it

    3. Removal of additional legacy items

      In the subprofiling considerations there are some references to legacy funcctions. Remove references to 

      ftime()		from XSI_SINGLE_PROCESS
getwd()		from XSI_FILE_SYSTEM
mktemp()	from XSI_FILE_SYSTEM
utimes()	from XSI_FILE_SYSTEM
wcswcs()	from XSI_WIDE_CHAR
    4. Response to reviewers note in XSH page 483, line 1324:

      The following functions are missing from the table in 2.4.3 (the set of functions that shall either be reentrant or non-interruptable by signals and shall be async-signal-safe)
      accept(), bind(), connect(), getpeername(), getsockname(), getsockopt(),
      listen(), recv(), recvfrom(), recvmsg(), send(), sendto(),
      setsockopt(), shutdown(), socket(), socketpair(), poll(), pselect(),
      select(),sendmsg().

    5. limits.h

      There are a few problems in limits.h arising from the 8-bit byte decision. In particular, CHAR_MIN is a value, not a min acceptable, and CHAR_MAX similarly.

    6. Sockets and IPv6

      Comments from Jack McCann received: 

      Andrew,

Here are the outstanding issues from apifolks/ipng.

Dave Thaler identified a number of issues with 2553bis, of which
the following items are applicable to austin:

>3) The description of IPV6_MULTICAST_IF should say (as is done for
>   IPV6_JOIN_GROUP) what happens if the app specifies 0.
>   (I believe this should tell the kernel to choose one.)

I think Dave is right, here is the draft 6 text in xsh section
2.10.20.4 lines 2822-2824:

   IPV6_MULTICAST_IF
   The index of the interface to be used for outgoing multicast packets.
   It can be set via setsockopt() and read via getsockopt().

We could add another sentence copied from IPV6_JOIN_GROUP:

   If the interface index is specified as zero, the system selects
   the interface.

>4) IPV6_LEAVE_GROUP is similarly terse.  If the app passes 0 as the
>   interface to IPV6_JOIN_GROUP, the current wording implies that
>   it has to magically figure out which interface the kernel chose
>   and specify that interface in the leave.  The wording should
>   be updated to say that the value of the interface field should match=20
>   whatever the app used in that field in its IPV6_JOIN_GROUP call.

Again, Dave makes a valid point, here is draft 6 text in xsh
section 2.10.20.4 lines 2812-2816:

   IPV6_LEAVE_GROUP
   When set via setsockopt(), it removes the application from the
   multicast group on an interface (identified by its index) and
   addressed by a given multicast address.  An attempt to read
   this option using getsockopt() shall result in an [EOPNOTSUPP]
   error.  The value of this option is an ipv6_mreq structure.

We could harmlessly (by saying "should") add another sentence as
Dave suggests:

   The application should specify the same interface as was
   used in IPV6_JOIN_GROUP.

As I glance through this section, I notice that the data types
and default values of the following options are unspecified in
austin (note section 2.10.16 defines arg type and default for
socket level options).  Here are the values from
draft-ietf-ipngwg-rfc2553bis-03.txt:

				arg type	boolean?	default

   IPV6_MULTICAST_HOPS		int		no		1
   IPV6_MULTICAST_IF		unsigned int	no		0
   IPV6_MULTICAST_LOOP		unsigned int	yes		1
   IPV6_UNICAST_HOPS		int		no		none

>8) In section 6.4:
>> [...]  Note that IN6_IS_ADDR_LINKLOCAL
>> and IN6_IS_ADDR_SITELOCAL return true only for the two local-use IPv6
>> unicast addresses. [...]
>
>I believe "types of" should be inserted after "two".=20
>There's certainly more than two local-use unicast addresses...
>Furthermore, it would help to illustrate the point by explicitly
>stating what the result of the test
>IN6_IS_ADDR_LINKLOCAL( ::1 )
>is, especially in light of the fact that the scoped-arch document
>says ::1 is link-scoped (i.e. it should return false, and it's
>worth noting this, similar to the current note about multicast
>addresses).

This applies to draft 6 xbd page 280 lines 10043-10045, which
could be replaced with something like:

   IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only
   for the two types of local-use (link-local and site-local, respectively)
   IPv6 unicast addresses.  They do not return true for multicast
   addresses of either link-local or site-local scope.  Note that
   IN6_IS_ADDR_LINKLOCAL does not return true for the IPv6 loopback
   address (::1).

In addition to Dave's comments, there was the topic of EAI_NODATA
brought up by jinmei@kame.net.  The [brief] history of EAI_NODATA
is it was in RFC2553, but removed by XNET in XNS 5.2 based on the
following change request by Craig Metz:

> Rationale: EAI_ADDRFAMILY, EAI_NODATA, and EAI_NONAME can't always be
> distinguished, and they mean basically the same thing. Parameters were passed
> in querying for something, and no result was found that matched against the
> query. Given that the query failed, I don't think that the further
> determination of how much or little was found is useful, and I don't think
> that you can necessarily make this distinction reliably. The information
> needed to make this distinction isn't available for all protocols one
> might use to actually perform a query.
>
> I believe that EAI_ADDRFAMILY and EAI_NODATA should be removed, and both
> failure cases be part of EAI_NONAME.

The counterargument, presented by Jinmei, is that for DNS lookups,
there are useful cases when we separate EAI_NODATA and EAI_NONAME.
If there was consensus on this, it was consensus by silence (I don't
think anyone else spoke up in support of this change), but neither
was there objection...  I'll note that we (Tru64 UNIX) no longer
use EAI_NODATA, but I find references to it in BIND9...

One last comment, my own, on 2.10.20.2 Compatibility with IPv4.
If you look at the usage of the term "may" in that section, and
then look at the strict definition of the term "may" on page 452
xsh lines 35-39, you realize that implementations are not required
to support use of AF_INET6 sockets over IPv4, and that applications
are discouraged from using AF_INET6 sockets over IPv4 because of
the portability concerns that raises.  I believe the definition
of the term "can" on page 451 xsh lines 18-21 is more appropriate,
i.e. "applications can" use AF_INET6 sockets over IPv4.  Of course,
that implies "implementations shall".  I believe that was the intent
of RFC2553, and that the consensus on the default value of the
IPV6_V6ONLY supports this.  However, this was not directly discussed
on the IPng or apifolks mailing lists, and it feels late to be
making this kind of change to austin, but I wanted to at least
identify the issue.  I wonder how many other folks thought that
when RFC2553 said "applications may", it meant "implementations
shall"...

- Jack

      We will Accept As Marked this -- at page 519 line 2824 Add: "If the interface index is specified as zero, the system selects the interface (for example, by looking up the address in a routing table and using the resulting interface)."
      We will not take the second action suggested (for IPV6_LEAVE_GROUP), since this is obvious and soes not need stating.
      At P519 L2821 add "The paramater type of this option is a pointer to int (default value 1)" At P519 L2824 add "The paramater type of this option is a pointer to unsigned int (default value 0)." ... etc (Cathy has full markup)
      On Page 280 delete lines 10043-10045.
      On Page 518, change "may" -> "can" at lines 2782 and 2794. Also there is a possible "may"->"shall" needed at line 2789, but this would need a base WG resolution. Probably not worth doing. ACTION TOG IR to ask OGTGBASE: Should we make it mandatory to allow a node with an IPv4 address to communicate using that address via an AF_INET6 socket? I.e. should we change "may" to "shall" in the following (from 2.10.20.2) "If a node has an IPv4 address, then the implementation may allow applications to communicate using that address via an AF_INET6 socket."

    All members of the Austin Group wish to thank The Open Group for hosting this meeting and taking care of our needs so dutifully.

    The meeting adjourned at 1.03pm friday.

    If you have comments or additions to the Minutes please send them to Andrew Josey (ajosey@opengroup.org).