Austin/106
Minutes of the 8th Plenary Meeting of the Austin Group
8-9 May, 2002
Reading, UK, Hosted by The Open Group.
Austin/106
Minutes of the 8th Plenary Meeting of the Austin Group
8-9 May, 2002
Reading, UK, Hosted by The Open Group.
Attendees
| Name | Affiliation | Role |
| Andrew Josey | The Open Group | Chair |
| Nick Stoughton | Usenix | WG15, Secretary |
| Don Cragun | Sun Microsystem | IEEE |
| Ulrich Drepper | Red Hat | |
| Raja Srinivasan | Oracle | |
| Ben Harris | University of Cambridge | |
| Keld Simonsen | DKUUG (teleconference, part) | |
| Finbarr Murphy | HP Compaq (teleconference, full) | TOG |
| Matts Wichman | Intel (teleconference, part) | |
| Cathy Hughes | TOG (teleconference, part) | |
| Jon Hitchcock | ||
| Joanna Farley | Sun Microsystems | |
| Joerg Schilling | GMD (teleconference, part) | |
| Glen Fowler | AT&T Labs Research (teleconference, part) | |
| Dave Butenhof | HP/Compaq (teleconference, part) | |
| David Korn | AT&T Labs Research (teleconference, part) | |
| Andrew Gollan | Sun Microsystems | |
| Lois Goldthwaite | IST/5/-/15 | |
| David Edmondson | Sun Microsystems | |
| Yvette Ho Sang | IEEE Standards (teleconference, part) |
Andrew Josey called the eigth meeting (a.k.a. Austin/M9, since this counting includes a teleconference) of the Austin Group to order at 9:05 am Wednesday May 8th at The Open Group's office in Reading, Berkshire.
Meeting Goals
The goal of this meeting is to put together the scope for Technical Corrigendum Number 1 (TC1), and the associated project paperwork for the participating sponsoring organizations, and resolution of the aardvark input to date for production of TC1.
A large part of the meeting will be spent doing issue resolution based on Aardvark comments submitted during the period since the final draft was completed. Attendees are assumed to be familiar with the proposed dispositions for the aardvark prior to the attendance of the meeting - these will not be discussed unless there is some disagreement with the proposal.
Ben Harris (University of Cambridge and the NetBSD project) was welcomed.
Added new Business Item to discuss and further document the ongoing role of the Austin Group.
ICSC liaison will be here Thursday afternoon to discuss sockets extensions.
Minutes were published as Austin/90. No comments received. Minutes approved.
All action items from the previous meeting have been closed.
SD1 updated
SD2 updated
No updates.
see attendance list above.
The Open Group approved the standard on September 12 2001. The IEEE ballot succesfully concluded, and the standards board approved the standard on December 6th 2001. The document has been published as IEEE Standard 1003.1:2001/The Open Group Base Specifications Issue 6, with both designations on the covers.
Two print runs so far ... 75 + 12. Document on-line in HTML, and Guide Book with PDF on CD-ROM. You can buy the official CD-ROM for a lot more if you really want! Thanks to the IEEE should be noted for giving permission for the HTML version. 2484 people have registered to read the on-line version.
In ISO ballot, document held up administratively; FDIS ballot will start any day now for 2 months. Thanks to Keld Simonsen for assisting in going round the roadblocks here. ISO have requested the document be published in four parts. It is important to note that in spite of this, the standard is the whole document, and no quarter stands alone in any respect.
ISSUE: It is extremely unfortunate that ISO cannot manage to publish this standard as a single part without editorial change. Resolved we will accept their proposal to publish as four parts, with the proviso that it should be distributed on a single CD and sold as a single standard.
A Technical Corrigenda is a lighter weight process than an IS, and will not require full ISO balloting (though it will need IEEE ballot).
The Austin Group was established to be the joint development body and maintenance organization for the revised 1003.1-2001 specification. Now that the standard has been approved it is important to establish a period of stability, with active maintenance of the document as issues are discovered. Maintenance would be through handling interpretation requests (entered via the aardvark defect reporting system) and publishing Technical Corrigenda or Interpretations when appropriate. What about new work? Can TCs contain new interfaces? No. A TC is a small editorial change that adds no new APIs (may add symbols, reserve namespace, etc) and an interpretation can suggest future directions (non-normative) while widening conformance.
New work has to happen in another forum (PASC, OGTGBASE, WG15, somewhere else etc) and have reached mature consensus before coming to the AG to be rolled into a future revision.
Based on past performance we should expect the next revision to commence in about 2005 with output expected in 2007.
Interpretations should be in line with established procedures for interpretations handling, such as the PASC Interpretations Guidelines, and would require 30 day review by the expert group (the Austin Group reflector). Interpretations cannot change the standard. A Technical Corrigendum does change the standard (and often substantively), and must therefore be balloted in IEEE, subject to a company review in The Open Group, and approved by the ISO document Editor.
Suggested that the Technical corrigenda take the form of a set of editing instructions to the approved standard, for examples look at the http://www.opengroup.org/corrigenda/ web area and look at XSH5 Corrigenda.
What is a TC? (what is the anatomy of a TC item, how do we recognize one when we see it)
Interpretations
Interpretations will happen concurrently; everything starts out as an aardvark defect report, unless raised during a plenary session when all the ORs are present. Interps may be controversial, but will not change the meaning of the current approved standard document. If the fix for an interpretation is non-controversial, small, in scope, etc, then it may be fixed in a TC. We need to ensure that the IEEE ballot group is engaged in the discussion to ensure quick balloting.
New Interfaces for consideration in a future revision
The AG has not been established as the development body for new material. The stance for the original revision was to take established approved standards and integrate them when appropriate. This is the approach that will again be taken for a future revison. Thus if a defect report raises the possibility of new interfaces for inclusion, the standard response will be that it is out of scope for either a TC or Interpretation, and that if the new material were to meet the following criteria it may be considered for inclusion in a future revision subject to the agreed scope determined at that time:
A submission of New Interfaces for consideration for inclusion in a future revision must meet the following criteria:
Profiling
What about profiles? Does the AG have any role in defining or accepting profiles? This group does not develop profiles. The document contains profiling rules (including subprofiles).
In the aardvark review below, items that are clearly candidates for TC1 or identified. Others may well also be candidates if they meet the criteria (The chair will be initial judge). Level of controversy is probably biggest gate, size of change second.
Note for the avoidance of doubt, the aardvark reports are the master dispositions and override the minutes. Please consult the aardvark reports.
Remove from pre-disposed list: 2
This list shows only the ERNs discussed at the meeting. Others were pre-disposed.
XBD ERN 2: (Removed from pre-disposed by Jon Hitchcock) There are no macros associated with these functions. The rdvrk is against the option codes, which are used on the sys/mman.h page, so reject. If there is another problem, it should be submitted separately. ADV+MF=MC1, so we could have coded the page differently, but as it is it is not wrong. Editor will markup for future revision.
XBD ERN 3: If this is accepted we would also need to change XBD unistd.h line 14133 (p 401) to match. Accept As Marked.
XBD ERN 9: Accept as marked (no action required). Dave Butenhof comments (in rdvrk) provide rationale. In fact, there can be no POSIX implementation on a system that does not provide atomic syncronized access to a memory location (byte or otherwise). Advice given.
XBD ERN 10: This has been in since 1003.1c (1996). Ulrich asserts that the statement that these cannot have useful dependencies is wrong. Dave Butenhof has been asked for input... Dave now attending (Wednesday 1.00pm). Dave agrees that these functions should remain in the list. Leaving these functions on the list makes the requirements explicit. Reject.
XBD ERN 11: (Ulrich) Adding this requirement would make the function more costly for no actually gain. (Dave B) It should be on the list w.r.t. itself. Otherwise you must rely on the application to provide the necessary sync. for the inititialization. This only needs to happen for the first call in any thread on any given pthread_once_t. Do we have to do anything? Probably not; there is an inadequacy in the standard. AAM only needs to be for the first call in each thread on a given pthread_once_t. TC1 candidate.
XBD ERN 13: AAM, take changes given, and also define the table contents on p143.
XBD ERN 14: Accept
XBD ERN 15: AAM; if TZ is changed while any threads are using the time functions, the behavior is undefined. Too much existing practice to allow a change. We need some words stating this for TC1. Something like: "If an environment variable used by the implementation is modified by one thread while another is using it, the effects are undefined." at p159 after lines 5569-5572, shaded THR. (See rdvrk for final wording). Candidate for TC1.
XBD ERN 16: Accept
XBD ERN 17: It is clear that the debate on REs is still ongoing (see email archive), and concensus is far from complete. We should probably spawn a specialist subgroup to go away and consider this problem and come back with words for future TC or revision. ACTION 2002-05-01: Form a subgroup to consider XBD ERNs 17, 18 & 19 (with a broad enough scope to deal with any other issues that arise in the discusssion). AGREED: David Korn to act as chair of this subgroup.
XBD ERN 18: See 17
XBD ERN 19: See 17
XBD ERN 21: Two current implementations ... one returns empty string if no currency symbol, one returns a single character (+, -, or .). Considerable argument: Ulrich argues that implementations must return at least one byte, plus a nul byte, and applications can rely on accessing the second byte of the string (which might be the nul byte). Nick (and Don) argue that the null string should be permitted here. Ben also agrees that we should follow existing practice. AAM "If the currency symbol is the empty string, implementations may return the empty string." This is a candidate for TC1, but it is a user visible change (applications can no longer rely on the second byte of the string being valid). This change is being made to reflect common practice.
XBD ERN 23: OPEN (leave for Andrew Gollan). Andrew is now here (Thursday). Accept. TC1 Candidate.
XBD ERN 24: Hold for Andrew G. Reject (see XSH corresponding aardvark)
XBD ERN 25: Hold for Andrew G. Accept - TC1 candidate. ACTION 2002-05-02: XBD ERN 25 Andrew Gollan to ensure that all special IPv6 address objects are declared const correctly.
XBD ERN 26: Hold for Andrew G. Accept - TC1 candidate.
XBD ERN 27: Accept
XBD ERN 28: Accept
XBD ERN 31: Accept
XBD ERN 34: Options are: Make it an implementation defined number,
Add rationale stating that the units are undefined, but frequently 512.
Or simply to remove the element from the structure. There should be rationale
explicitly stating that there is no relationship between st_blocks, st_blocksize
and f_bsize (from XBD ERN 35: No action required ... even though this is XSI shaded, and this
header need not be present. However, if it is not, then the definitions in it will
need to appear elsewhere. Defect withdrawn by submitter.
XBD ERN 36: Accept
XBD ERN 38: While this might be useful commentary, it is substantial work and therefore
out of scope for TC1. There are also concerns about the maintainabilty of lists
like these, and they should really go into the guide book.
There is no actual problem with the standard. This is simply a readability issue.
XBD ERN 40: No change required ... withdrawn.
XBD ERN 42: Accept
XBD ERN 43: (Actually, this is XCU, page 716, lines 27689-27693). This is new work,
and should be submitted to one of the sponsoring groups first. Joerg will submit
this to OGTGBASE.
XCU ERN 1: Change "None" to "Not used" where appropriate, fix operands and options
throughout Special Builtins. Refer to description if not "None".
ACTION 2002-05-04: Ben Harris to provide complete list of changes for XCU ERN 1.
XCU ERN 2: Accept
XCU ERN 3: Accept
XCU ERN 4: AAM - System Interfaces
XCU ERN 5: AAM - see rdvrk for new text.
XCU ERN 6: Withdrawn
XCU ERN 7: Both the range and error conditions are defined already (1.7.2.1, page 7),
except for where ISO C requires SIGFPE. Results of dividing by zero
are explicitly undefined (in ISO C). Reject.
XCU ERN 8: Withdrawn
XCU ERN 9: OPEN - candidate for TC1 (DWC to check this overnight). Revisited, Thursday.
First part is OK (path_var). Changes to second part (system_var). Comments
in rdvrk. AAM. On XCU P 17, delete 693-696 (POSIX2_VERSION). On P 18, change
XCU ERN 10: Accept
XCU ERN 11: OPEN - want Keld input. Keld attending Thursday afternoon.
The problem is that invalid characters are weakly defined here.
If invalid characters means "either those that are not valid
members of the fromcode or those that have no corresponding value in tocode"
there is a problem, since this is inconsistent with the way that the iconv()
library function works. If this definition (of invalid chars) is changed
to "those that are not valid members of the fromcode", the problem goes away.
Ulrich's position is that the iconv() function is broken and glibc will not implement
it. This change is acceptable to him. AAM - change 1st sentence to "Omit any characters
that are invalid in fromcode from the output".
ACTION 2002-5-05: XCU ERN 11 Joanna Farley to propose final text for first inconsistency.
XCU ERN 12: Accept
XCU ERN 13: Accept
XCU ERN 14: AAM - replace "the application ... is empty or" with
"the output file shall be empty or"
XCU ERN 15: Accept
XRAT ERN 1: AAM, page 11, change "Groupsc" to "Groups", page 13 l 440
change prefixed to suffixed. P23, remove "and {cooperating implementation}".
XRAT ERN 2: AAM, replace with SIGEV_THREAD an ensure that it is correctly indexed.
XRAT ERN 3: AAM - rdrvk has words.
XRAT ERN 4: Accept
XSH ERN 4: This is a difficult area. We appear to tell applications to do
something that is unspecified (or implementation defined). Best route to solve this
(potentially controversial) issue is to come up with an interpretation including
future directions. We should check the wording in the 1988 standard.
Line 1474 directs apps to perform an unspecified action.
XSH ERN 5: Accept
XSH ERN 6: Reject - Out of Scope - new work, please submit an approved standard.
XSH ERN 7: AAM - no question asked, unclear aardvark. We agree with Dave Butenhof!
XSH ERN 8: Accept
XSH ERN 9: AAM - TC1 candidate, further align with ISO C. Use Clive Feather's
email suggested actions (austin-review-l 1093). See rdvrk for full resolution. Drop sequence
point stuff.
XSH ERN 10: Accept
XSH ERN 11: Accept
XSH ERN 12: All the SC values in unistd.h should always be present.
Using string args instead of int args for the *conf functions is a change
to the standard that is out of scope; this is an API, not an ABI, and binary
values are not required. A group writing an ABI could (should) provide values for these
symbols, this is not a goal of this standard. The SC values are strings, for the
compiler to translate as it sees fit.
AAM - _SC values must always be provided, and should be unshaded. TC1 candidate.
XSH ERN 13: Many emails on this subject (dlsym! 109 messages in austin-group-l).
ACTION 2002-05-06: DWC to propose response for XSH ERN 13 as an interpretation.
XSH ERN 14: It is necessary to permit implementations to re-open stdin,out and err
to prevent security problems in some circumstances (setuid/setgid).
"If fd 0,1, or 2 would otherwise be closed after a succesful call to one
of the exec family, and the execed file has either the set-user-ID or
set-groupID mode bit set (XSI - and the ST_NOSUID bit is not set on the
file system containing the new image) implementations may open an
unspecified file for each of these file descriptors in the new process
image."
Add to App Usage statement strongly discouraging applications from depending
on closing 0, 1, or 2 before an exec even if the setuid or setgid bits are not set.
XSH ERN 15: This is a global edit, which are almost always dangerous and lead to
errors. While the submitter has identified the places where "process signal mask" is used
there are no detailed editing instructions. The committee does not wish to
proceed without detailed editing instructions.
A global change of s/process signal mask/thread signal mask/g" is not appropriate.
While the committee agrees that there is a problem, we cannot proceed. Reject,
please resubmit with more detail.
XSH ERN 16: There is no good definition if canonical name, and DNS is not the
only implementation.
ACTION 2002-05-07: XSH ERN 16 Andrew Gollan to provide definitions for Canonical Name and Alias (in the context of network naming).
Probably TC1 candidate.
XSH ERN 17: Accept. TC1
XSH ERN 18: AAM - shade IP6 appropriately - TC1 candidate
XSH ERN 19: AAM - use "shall be" instead of "is" in proposed text. TC1 candidate.
XSH ERN 20: Accept - TC1 candidate
XSH ERN 21: Accept - TC1 candidate
XSH ERN 22: Considerable discussion. Leaving it as unsigned is better engineering.
Either way, apps do not care about it. Consitency was an argument for making it unsigned,
but Finnbarr points out that other (old) interfaces have signed ints. Forcing
implementations to change from int to usigned is actually not a big deal (Andrew G).
General consensus is reject on the grounds that it makes no difference to apps, only
to implementations (half of which are right already). REJECT.
XSH ERN 23: Accept - ACTION Andrew Gollan to define numeric form of network addresses.
ACTION 2002-05-08: XSH ERN 23 Andrew Gollan to define numeric form of network addresses.
XSH ERN 24: AAM - shallify - TC1 candidate
XSH ERN 25: Accept - TC1 candidate
XSH ERN 26: OPEN - needs research. ACTION TOG OR to investigate.
ACTION 2002-05-09: TOG OR to investigate XSH ERN 26
XSH ERN 27: AAM - option 2 seems best. There are applications that do not test for
null, and right now they don't have to. Following the C standard seems the most sane
answer. If we want to go for option 1 or 3, we need to define what is
in the structure. AAM - option 2,
add EOVERFLOW to shall fail, CX shaded. TC1 Candidate.
XSH ERN 28: Accept. TC1 Candidate.
XSH ERN 29: Both IFNAMSIZ and IF_NAMESIZE are used extensively. We believe that the
correct one is IF_NAMESIZE. Accept. TC1 candidate.
XSH ERN 30: Accept - TC1 Candidate.
XSH ERN 31: Accept - TC1 Candidate.
XSH ERN 32: Reject - this was introduced following our normal rules for adding "restrict".
(See Austin/45 for these rules).
XSH ERN 33: Accept - TC1 Candidate
XSH ERN 34: Accept - TC1 Candidate
XSH ERN 35: AAM, use option 2 - mirror gmtime() change (see XSH ERN 27).
Update the examples to check for NULL pointer or note that no error checking is done.
Also fix localtime_r to allow for null pointer on error.
XSH ERN 36: Accept - Candidate for TC1
XSH ERN 37: Accept - Candidate for TC1
XSH ERN 38: Accept - Candidate for TC1
XSH ERN 39: Accept - Candidate for TC1
XSH ERN 40: Accept - Candidate for TC1
XSH ERN 41: Accept - Candidate for TC1
XSH ERN 42: Accept - Candidate for TC1
XSH ERN 43: AAM (predisposed) XSH ERN 44: Badly formed aardvark ... please resubmit with a statement of what the
problem is, and a proposed solution. Reject.
XSH ERN 45: This is new work. Please feel free to develop this under another standards body
(e.g. PASC) and bring us an approved standard with reference implementation.
For TC1 we should add App Usage about priority inversion. AAM.
XSH ERN 46: Accept - Candidate for TC1
XSH ERN 47: Accept - Candidate for TC1
XSH ERN 48: AAM - for TC1 make it unspecified, but also add rationale stating that
future versions will malloc for a null pointer. Lois strongly encourages use of implementation
defined now. Nick and Ulrich agree. Rationale needs more words (in rdvrk). We will use imp def.
XSH ERN 49: See the bsearch ERN. AAM, TC1
XSH ERN 50: Accept - Candidate for TC1
XSH ERN 51: Accept - Candidate for TC1
XSH ERN 52: AAM, use digit 0.
XSH ERN 53: Question assumed is "On systems that do support rt signals but do not
support SA_SIGNFO on non rt signals, is ENOTSUP a valid error condition when
SA_SIGINFO is requested on a signal not between SIGRTMIN and SIGRTMAX".
We believe the answer is YES.
This is an interp.
May need a "may fail" error for ENOTSUP for TC1. Words in rdvrk.
XSH ERN 54: OPEN defer to OGTGBASE
ACTION 2002-05-10: TOG OR to convey XSH ERN 54 to OGTGBASE for theior consideration.
XSH ERN 55: Accept - TC1
XSH ERN 56: AAM - TC1, rdvrk has words.
XSH ERN 57: AAM - TC1, first sentence is OK. Second sentence is not (might open
a file, then set rlimit, then call sysconf. The highest open fd may then be greater than
the number returned). Need additional note in getrlimit() App Usage stating
"If a process attempts to set the hard or soft limit for RLIMIT_NOFILE
to a value less than the highest currently open fd + 1, unexpected behavior may occur."
XSH ERN 58: Interp. The standard is clear, EPERM is the only permitted value.
No change required.
XSH ERN 59: (rdvrk lost this, but it was submitted on time)
AAM (tokens, not token, first option). TC1.
XCU Echo.
Ben Harris believes that the use of System V escapes and the removal of
the BSD options was an accident. Don stated that no, this was deliberate
and it was pointed out that the specification had gone thru the balloting
process. We thought the issues had gone away. However, this breaks
many scripts. Most *BSD systems will not be able to conform here. Ben
has prepared a new echo page for discussion (Austin/104). Everyone is
agreement that this is a candidate for TC1. Editor will prepare final
text and circulate to this group.
Support for the Euro
During the aardvark review the issue of the version of ISO 4217
and the Euro support was raised and discussed as follows. One approach
would be just to update the reference to ISO 4217
to allow for the Euro, however this seems to be
be setting up problems for later when the next currency comes along.
A better approach is to look at the requirement within XBD
and consider an extensible approach.
Problem: We do not allow the Euro or any new currencies
and do not permit extensibility.
Proposed solution:
change xbd p 140 l4787-4792 from
The international currency symbol. The operand shall be a four-character
string, with the first three characters containing the alphabetic
international currency symbol in accordance with those specified in the
ISO 4217: 1995 standard. The fourth character shall be the character used
to separate the international currency symbol from the monetary quantity.
to
The international currency symbol. The operand shall be a four-character
string, with the first three characters containing the alphabetic
international currency symbol. The international currency symbol should
be chosen in accordance with those specified in the ISO 4217 standard.
The fourth character shall be the character used to separate the
international currency symbol from the monetary quantity.
The Interconnect Software
Consortium. Dave Edmondson, co-chair of the ICSC Sockets Working
group gave a presentation on the work that this group is doing to extend
the sockets API. The slides will be available as Austin/105. Arose from
"Infiniband" work (v high speed interconnect solution for SAN, NAS and
other very high performance network).
The Infiniband association does not have it in its charter to specify
APIs. Mostly UNIX vendors plus others formed ICSC, 3 groups: Interconnect
Transport API, Fabric management API, and sockets extensions. This
presentation only about sockets. The DAT collaboration is also working
in similar space.
The sockets API has changed little over the last 15+ years. The scale
of connections (10s to 100s of millions of simultaneous connections),
and bandwidth (many gigabit) has dramatically increased, and so some
limitations in sockets have been uncovered. A desire to offload more
to hardware, RDMA, copy avoidance, async ops etc.
Winsock API seen by some as better than UNIX sockets ... UNIX sockets
seen as old and crusty.
Sockets extension group has aim to keep separate from Infiniband
space. Charter looking to extend standard UNIX sockets. Currently at
requirements specification phase. Draft 1 is current level, with about
150 requirements. Scope setting.
Membership is company based, one company, one vote.
Current areas of discussion include async I/O (including async connect
and accept). Writing white paper on limitations of current approachs
here, and how event management and completion notification fits into
UNIX style AIO. Also buffer management (buffer pinning), OS bypass
(implement everything in user space). Support for new protocols STCP,
DCP, etc. STCP for example allows multiple addresses bound to one socket.
Also codify common existing API extensions (e.g. sendfile).
Of course, you have to get ISVs to use the API ... majority of group is
OS vendors. Currently engaging iPlanet, Java, Oracle, DB2 and Notes folk,
more needed.
Participation is strongly encouraged - 2 weekly teleconference (at
9.00pm BST). If you are not a member, either join (will need to sign
45 page agreement), or badger chairs (or other members) to get your
views represented.
Timescales aggressive ... Phase 1 complete by august 2002, phase 2
(the contentious stuff) by November 2002. Current funding does not
include a reference implementation. IBM and HP have expressed interest
in implementing on Linux, but no commitment.
We do not believe we need a formal liaison to this group at this point,
but Joanna Farley shares an office with Dave Edmondson, and will keep
an eye on him!
utility (see getconf (on page 481)) and through the sysconf( ) function defined in the System
Interfaces volume of IEEE Std 1003.1-2001. The literal names shown in Table 1-3 (on page 17)
apply only to the getconf utility; the high-level language binding describes the exact form of each
name to be used by the interfaces in that binding.
to
utility (see getconf (on page 481)).
This is covered by text elsewhere (the system_var operand), and is wrong in this table.
Add this at p296 before line 9599. TC1 Candidate (security critical, even
if possibly controversial).
extra commentJoanna pointed out error on page ??? Line ??? should be "TSA TSS"
Marked up aardvark to be recirculated by Monday May 13. Actions from this meeting close May 28. Final aardvark issued by June 24. TC1 draft 0 should be issued by May 28 (not including items still open). Interpretations should start 30 day clock by May 28 wherever possible. Teleconference meeting probable mid-June to close out open items. We need to form raise a PAR (and PMC eval criteria), get this through the SEC and NesCOM, and form a ballot group. Deadline August 2 for PAR submission. We also need to fully understand the ISO process.
We probably need a face-to-face annually, but as aardvark demands.
The following awards were presented by Andrew Josey:
The meeting adjourned at 4.57pm Thursday.