minutes-2002-06-21

Tony Taylor (chair)

Greg Maston (scribe)

Dave Galagher

John Cosley

Docs:

http://grouper.ieee.org/groups/1450/private/1450.3-D14.pdf (july 11, 2006)

http://grouper.ieee.org/groups/1450/dot3/comments.xls (updated sep 27, 2006)

Agenda:

1. Added new page to xls with comments from N. Okumiya

2. Releases from Toshiba & Credence. And how to acknowledge in the standard?

3. Structural changes requested by IEEE

- Change clause 1 to "normative" - i.e., remove the word "informative"
- Move clause 5 to the annex

4. Key issues from the comment.xls -

* 48-GR - I think the syntax is fine. But ... we still need CSC release form. And ... should we move it to the annex?

* 49-GR, 77-JC, 137-GM, 138,GM - block merge rules

* 70-JC - I think these references are all defined in dot2. But ... we should add a reference to dot2 in clause 3.1 and 13

* 112-GM - concern about how to identify or classify Signals into SignalAttributes blocks

* 113-GM - "ESSM" : is this trade-marked?

* 118-GM - Is the PatternAttributes the only block that allows multiple references to named blocks and merges unnamed blocks?

Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.

To address the IEEE issue with "informative in the body of the spec", Tony proposed two changes:

- remove "informational" on clause 1.
- move clause 5 to an annex, possibly multiple annexes to allow separate referencing of external parties on respective issues.

Both changes unanimously approved.

Discussed item #48, which we hope is handled by moving the example to the annex (hopefully eliminating any issue with it being normative)

Discussed the block merge rules for some time. To address data assembly from separate blocks, Tony proposed eliminating all implicit data collection from unnamed groups, and support of an explicit statement such as InheritSignalAttributes. Tony took an AI to consider the effects to the language of adding these Inherit* statements.

In addition, there was discussion about the capability to reference multiple blocks to define parallel sets of constraints, currently defined in the standard as an implicit OR function between multiple reference statements within one block. Proposal is to make the ORing function explicit, allowing only 1 reference statement with all referenced blocks identified with a vertical bar between each name to explicitly identify the behavior. Greg is concerned about the derivation of the decision tree defined by this construct, necessary to establish whether the rules pass or not. Also there will always be questions from consumers of this data if both paths pass, and different tools report different paths as being successful - both are right, and neither agree with each other. Greg feels the standard needs to clarify sufficiently the semantics and interpretation of the constructs such that consistent conclusions can be made.

This discussion also raised the issue of how to handle fluid constructs, which are likewise difficult to establish a value for in order to run through the rules to see what passes. Tony indicated that this type of constraint check may be another type of operation not identified in the current chart, and that it may be necessary to limit the constructs defined in order to establish an evaluateable set of constraints that can be checked against a STIL test without going down the path of resource allocation in order to rules check. (Note after meeting by Tony - Upon closer review of Figure 1, I believe that the constraint application is part of flow (1) and that we should add the term "resource constraint" to the diagram. Also, we should identify that fluid constraints and ORing conditions should not be used in this application.)

Clarified several smaller concerns.

Meeting adjourned 11:20 Pacific time