1. ScanStructures - A very simple solution was arrived at to solve this quite contentious issue. You can see the details in the document.
Basically, a null ScanCellType block is defined to not consume any shift data - hence supporting the lockup latch definition.

2. NameMaps - This is a new issue, that hopefully you can take a look at prior to the meeting on Thursday. The issue is that the cell names in
the ScanStructures block constitute an extremely large part of the pattern file. The NameMaps allow this to be moved into an IfNeed file,
but the volume is pretty much the same as in ScanStructures. The solution is included in clause 17 of the new document and uses the
InheritNameMap to solve the problem.

3. Draft D18 ready for ballot - We need to decide whether the document, as it stands, is ready for submittal to ballot. You will note that there
are two links above. The two files, at this time, are identical with the exceptions - Draft 18 has the new D18 banner on every page, and D18 has
change bars cleared. You can view D17 to see all the lastest changes (i.e., the change bars), or you can view D18 is it will be submitted.

Balloting initiation
Tony identified that the ballot formation is now closing on Dec 1, so get yourself identified to the IEEE soon. ** BE AWARE THIS IS EARLIER
THAN THE DATE SPECIFIED IN THE IEEE MAILING **

ScanStructures
There was an issue raised about modeling or containing lockup latches as part of the scancell information. To address this, empty
scancelltypes are explicitly defined to support lockup-latches.
Accepted by the WG.

NameMaps
Reviewed the additional syntax constructs in the namemaps, designed to better support hierarchical naming descriptions. Conditionally
accepted (no issues raised) but under continuing review by WG.

[AI1] to Tony to add a comment before the second environment block in 17.4 to identify that the names defined in this block are the same
names defined in the hierarchical description format and refer this block back to the other block.

bracketed busses
Reviewed the additional rules defined to support creation of default bracketed groups in signals, and bracketed groups in signalgroups.

Motion by John Cosley to change the default for undeclared-bracketed names from [0..n] to [n..0]. 4 in favor with no objections; change to
be made by Tony [AI2].

John raised the question that a basename declared with brackets can still be accessed without explicit brackets. The intention is that
this is true: you can access an unbracketed base name which is the same thing as accessing the bracketed form with all defined indices.

boolean expressions, compare expressions
Issue with interpreting '=='; John identified that it would be desirable if this operator was symmetric on both sides of the '==', which makes the interpretation of the data to be uniform. The ambiguity problems here are notably with WFC_lists and signal/var names, and integer values with WFC_lists.

Discussion about making the interpretation of the expressions uniform, in particular, interpreting an expression not otherwise differentiated
as a WFC_list by default, whether it is on the LHS or RHS of the '=='. This would be a default expression interpretation rule for all
contexts where expressions are present; expressions are WFC_lists unless otherwise delineated. There are several mechanisms of
delineation: single-quotes for signals/groups/variables, \w, \d, etc.

Greg strongly recommends that these clarifications make it into the document for review as there have been several earlier reviewers
pinging on these same issues. Care must be exercised in the description here, as currently in dot-zero expressions on the RHS of
the '=' are interpreted as based WFC_lists depending on the Base declaration of the group being used to reference that
assignment... this overrides somewhat the basic assumption that all expressions are interpreted as WFC_lists at least in the '='
operation.

logic expressions
Some discussion continued on a similar vein to the issues with boolean expressions. Concern was raised about ambiguity of the logic
expressions, and requests were made to elaborate a bit on these expressions to eliminate mis-interpretation of the construct from
overly complex perception of the intent.

Next Actions
Tony will send draft 18 to the IEEE for review. We will continue to monitor additional technical issues. Next meeting in two weeks - Dec
4, 10:00 PST with likely final acceptance of this document for balloting.

Meeting adjourned at 10:52 pm PST.