(r5) P1735WorkPlan < P1735

P1735 Web>P1735GroupPrivateWorkspace>P1735WorkPlan (revision 5) (raw view)~~EditAttach~~
---++!! Work Plan
%TOC%

---+++ Process Overview

   1 Common Vocabulary
      2 Use Cases
      2 Glossary
      2 Reference Flow(s)
   1 Liaison Activities
      2 P1800 SystemVerilog
      2 P1076 VHDL
      2 EDIF
   1 Technology Review
      2 Pragma markup structure
      2 Key Management
      2 License Management
      2 Identity and Trust models
      2 Rights Management
   1 Recommendations
      2 End-user recommendations
      2 Standards Coordination recommendations
   1 Inter-operability Issues
      2 Validation Suite development
   1 Draft Development
      2 Outline Structure
      2 Draft Writing
      2 Review
      2 Revise and recirculate as needed
      2 Approve ballot draft
   1 Balloting
      2 Form Ballot Group
      2 Submit ballot draft
      2 Review ballot comments
      2 Revise and recirculate as needed
      2 Approve RevCom submission

---+++ Work items
   1. A processing model for transformative tools.  How do we balance the functional expectations for synthesis and other transformative tools with the demand for iron-clad security for protected IP?%BLUE%
      a. Do SDF files need to be generaged in encrypted form for protected blocks?
      a. What is the implication of the implied supply network of a  UPF power region that contains protected IP%ENDCOLOR%
   1. A transitive protection model that flows from the tool key.  What kinds of data need to be unlocked from that key (rights_block, data_block, digest_block), and how do we handle block specific keys (data session, digest, rights, etc).
   1. Recovering the original Verilog key_block syntax to implement transitive protection. Can this be done without a more complicated key_block?
   1. Applying encryption methods/keys to external content.  A form of external reference in place of  a data_block could also cover the use cases where the target file content does not have a suitable standard for IP encryption and rights management.
   1. An extended description framework for IP. Without duplicating the work of other standards, what can be done to improve IP management by producers and consumers. Structured data support in place of IP-author defined string content for:
      a. Support for signing protected IP for authentication purposes, and addressing the risk of trojan substitutions.
      a. Support for versioning and expiration of the protected envelope.
   1. Finishing the Key Management support, and extending the markup syntax if needed.%BLUE%
   1. What information is deemed to be protected under encryption.
      a. Language-neutral guidelines.
      a. Language-specific recommendations to working groups.
      a. Recommendations for partially protected constructs.
      a. What binding rules should apply at the boundaries of protected IP
      a. What behavior should be expected from assertions that fire from protected IP
      a. Do tool outputs and error messages have any privileged status over user-written PLI

---+++ Tentative Schedule

| Topic | Work Item(s) | Timeline | 
| Publishing interim recommendations |   | 2Q10 |
| Completing Key Management | 6  | 1Q11 |
| Security model | 1,2,4,7  | 2Q10 |
| IP Flow model | 5,7  | 2Q10 |
| Licensing Updates |   | 3Q10 - 4Q10 |
| Close of Donations |   | Jan 31, 2011 |
| Rights Management |   | 3Q10 - 1Q11 |
| End-user recommendations |   | 1Q11 |
| LRM updates and liaison |   | 4Q10 - 2Q11 |
| Draft completion |   | 2Q11 |
| Form Ballot group |   | 2Q11 |
| Ballot and publish |   | 3Q11 |
%ENDCOLOR%

-- Main.StevenDovich - 23 Jul 2008
Topic revision: r1 - 2010-12-13 - 15:56:51 - TWikiGuest
P1735