[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [KEYPROV] Phone Conference Call about KEYPROV Documents: Bridge

Here is meeting minutes that I noted from our conference call today.

--------------------

PSKC conference call meeting minutes

Participants: Hannes, Phillip, Sean, Ming
Time: 11:00am PDT 08/08/2008

Suggested changes:

a) Some cosmetics work to make document better

b) More importantly, some enhancements on semantics consistency

* key usage element

- Not all elements are applicable to all algorithms
- For some algorithms, some elements make sense. It makes the use of theFrom keyprov-bounces at ietf.org  Fri Aug  8 17:06:29 2008
Return-Path: <keyprov-bounces at ietf.org>
X-Original-To: keyprov-archive at optimus.ietf.org
Delivered-To: ietfarch-keyprov-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6BFBB3A6CDE;
	Fri,  8 Aug 2008 17:06:29 -0700 (PDT)
X-Original-To: keyprov at core3.amsl.com
Delivered-To: keyprov at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2E2853A6CDE
	for <keyprov at core3.amsl.com>; Fri,  8 Aug 2008 17:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5
	tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id zEpZCdDEDJby for <keyprov at core3.amsl.com>;
	Fri,  8 Aug 2008 17:06:27 -0700 (PDT)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	by core3.amsl.com (Postfix) with ESMTP id 449B43A69FE
	for <keyprov at ietf.org>; Fri,  8 Aug 2008 17:06:27 -0700 (PDT)
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com
	[65.205.251.35])
	by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id m78NoI8O013378;
	Fri, 8 Aug 2008 16:50:18 -0700
Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by
	MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 17:06:18 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8F9B3.BEA73772"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 8 Aug 2008 17:06:17 -0700
Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9FDA803 at mou1wnexmb10.vcorp.ad.vrsn.com>
In-Reply-To: <489C8AD8.8040006 at gmx.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Phone Conference Call about KEYPROV Documents: Bridge
Thread-Index: Acj5gVJ/45gfuDefQPmW3Deq9gDL/QAMNmDg
References: <4898964A.8020707 at gmx.net>
	<5BFE9E473DBFC24CA87F18F29B3F0AC40203F23F at sur-corp-ex-02.corp.ad.activcard.com>
	<9ED76AB595E4944BB33D8998DE448D110160CB8D at CORPUSMX10B.corp.emc.com>
	<2788466ED3E31C418E9ACC5C316615572FF9D0 at mou1wnexmb09.vcorp.ad.vrsn.com>
	<9ED76AB595E4944BB33D8998DE448D110160CB99 at CORPUSMX10B.corp.emc.com>
	<3E5A2F1AD44F5E49A74F79AB47C0C0C9FDA74F at mou1wnexmb10.vcorp.ad.vrsn.com>
	<489AF906.5040804 at gmx.net> <489C8AD8.8040006 at gmx.net>
From: "Pei, Mingliang" <mpei at verisign.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig at gmx.net>
X-OriginalArrivalTime: 09 Aug 2008 00:06:18.0156 (UTC)
	FILETIME=[BF2786C0:01C8F9B3]
Cc: SMachani at DIVERSINET.COM, keyprov at ietf.org
Subject: Re: [KEYPROV] Phone Conference Call about KEYPROV Documents: Bridge
X-BeenThere: keyprov at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Provisioning of Symmetric Keys \(keyprov\)" <keyprov.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyprov>,
	<mailto:keyprov-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/keyprov>
List-Post: <mailto:keyprov at ietf.org>
List-Help: <mailto:keyprov-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyprov>,
	<mailto:keyprov-request at ietf.org?subject=subscribe>
Sender: keyprov-bounces at ietf.org
Errors-To: keyprov-bounces at ietf.org

This is a multi-part message in MIME format.

Here is meeting minutes that I noted from our conference call today.

--------------------

PSKC conference call meeting minutes

Participants: Hannes, Phillip, Sean, Ming
Time: 11:00am PDT 08/08/2008

Suggested changes:

a) Some cosmetics work to make document better

b) More importantly, some enhancements on semantics consistency

* key usage element

- Not all elements are applicable to all algorithms
- For some algorithms, some elements make sense. It makes the use of the
xml har
xml hard.
- For example, section 8.4.4.2 OCRA algorithm. We need to add

* what are possible attributes and values that can be used
* add these specification for each algorithm registered in section 8.4.4

c) Check consistency about the content order 

e.g. SSL is mentioned at the end of the document. It should be mentioned
in the beginning of requirement section as well. It is 

d) Informational data was discused in IETF meeting.

DeviceInfo is informational to server. The purpose wasn't clear in the
document. Why is it needed. What consisted ID and so on.

* Assessment: there are questions from the meeting but it doesn't look
that they ask for changes other than clarification. Maybe we can add
some context how it can be used, for bulk key transfer.

e) Enhancements in Section 5

diagram:

* the diagram doesn't look relational, differing from DSKPP
* keyproperties doesn't appear to be optional from the diagram, and it
becomes clear later. It is better to present the most clearest /
simplest instance first. It doesn't need to present according to XML
order.

e.g. move keyproperties to the later section, for bulk case. Introduce
simple case first.

f) Appendix A

* Provide some description for each example
* Use some more concrete values, e.g. Manufacturer value

g) Priority

* section 8.4.4. Work on one to identify what should be added. Then
others can share the work
* section 11

h) Action items:

- Post these comments and work in progress in the mailing list
- Ming to send out an example case for the section 8.4.4 enhancement

-----------------

- Ming 

PSKC conference call meeting minutes

Participants: Hannes, Phillip, Sean, Ming
Time: 11:00am PDT 08/08/2008

---------

Suggested changes:

a) Some cosmetics work to make document better

b) More importantly, some enhancements on semantics consistency

* key usage element

- Not all elements are applicable to all algorithms
- For some algorithms, some elements make sense. It makes the use of the xml hard.
- For example, section 8.4.4.2 OCRA algorithm. We need to add

* what are possible attributes and values that can be used
* add these specification for each algorithm registered in section 8.4.4

c) Check consistency about the content order 

e.g. SSL is mentioned at the end of the document. It should be mentioned in the beginning of requirement section as well. It is 

d) Informational data was discused in IETF meeting.

DeviceInfo is informational to server. The purpose wasn't clear in the document. Why is it needed. What consisted ID and so on.

* Assessment: there are questions from the meeting but it doesn't look that they ask for changes other than clarification. Maybe we can add some context how it can be used, for bulk key transfer.

e) Enhancements in Section 5

diagram:

* the diagram doesn't look relational, differing from DSKPP
* keyproperties doesn't appear to be optional from the diagram, and it becomes clear later. It is better to present the most clearest / simplest instance first. It doesn't need to present according to XML order.

e.g. move keyproperties to the later section, for bulk case. Introduce simple case first.

f) Appendix A

* Provide some description for each ewE¢·±jjezÇ?¶*'ó?68$ at jX(®+a?g§yçm¡§]­j·©¢Ë"nW?¶Úânë^±©Ý½©nzËaj×?·®±çZuÛazǬ¥ç"~'¶*'~?ÞiÈZ?
+?Øf­è"²×«yا±ç-??üã??ç$r?ì?Ë^?Ì?n?­¶?¢{^?Ú+uê
PSKC conference call meeting minutes

Participants: Hannes, Phillip, Sean, Ming
Time: 11:00am PDT 08/08/2008

---------

Suggested changes:

a) Some cosmetics work to make document better

b) More importantly, some enhancements on semantics consistency

* key usage element

- Not all elements are applicable to all algorithms
- For some algorithms, some elements make sense. It makes the use of the xml hard.
- For example, section 8.4.4.2 OCRA algorithm. We need to add

* what are possible attributes and values that can be used
* add these specification for each algorithm registered in section 8.4.4

c) Check consistency about the content order 

e.g. SSL is mentioned at the end of the document. It should be mentioned in the beginning of requirement section as well. It is 

d) Informational data was discused in IETF meeting.

DeviceInfo is informational to server. The purpose wasn't clear in the document. Why is it needed. What consisted ID and so on.

* Assessment: there are questions from the meeting but it doesn't look that they ask for changes other than clarification. Maybe we can add some context how it can be used, for bulk key transfer.

e) Enhancements in Section 5

diagram:

* the diagram doesn't look relational, differing from DSKPP
* keyproperties doesn't appear to be optional from the diagram, and it becomes clear later. It is better to present the most clearest / simplest instance first. It doesn't need to present according to XML order.

e.g. move keyproperties to the later section, for bulk case. Introduce simple case first.

f) Appendix A

* Provide some description for each exampleample
* Use some more concrete values, e.g. Manufacturer value

g) Priority

* section 8.4.4. Work on one to identify what should be added. Then others can share the work
* section 11

h) Action items:

- Post these comments and work in progress in the mailing list
- Ming to send out an example case for the section 8.4.4 enhancement


_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov