Meeting Minutes October

Report as inappropriate Your report has been received

Shared by: liaoqinmei

Tags

Stats

views:: 6
posted:: 10/20/2011
language:: English
pages:: 21

Public Domain

Document Sample

Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

IEEE P1609 Working Group Meeting
NY Thruway and Toll Authority, Albany, NY

Minutes, Tuesday, October 3, 2006
Agenda & Action Item Reviews and Standard Notifications
Tom Kurihara called the meeting to order. He reviewed the IEEE policies and
procedures,and pointed out the existence of the policy statement and received
acknowledgement that everyone present was familiar with its content..
Tom asked for a volunteer to take notes for these meetings. Rick Noens volunteered to
take notes for the Tuesday and Wednesday meetings. Jules Madey volunteered to take
the notes for the Thursday meeting.
Tom reviewed the proposed agenda which was accepted.
Tom reviewed the action item status.
It was noted that 1609.3 was running late. The forecast was to have it ready for
recirculation on 9/25/06 but it will take a few more days before the final edits are
complete.
1609.4 edits are in process.
1609.1 is getting ready for publication. It is currently in the pre-publication edit audit
stage.
It has been suggested that the 1609.0 Architecture draft that was circulated for comment
by Wayne Fisher be put aside and instead an outline for this document be constructed.
There was no objection to this approach. A target date of the end of 2006 was set to have
this outline complete.
There was a discussion about the need for a formal agreement between 1609 and SAE.
There was a concern about the Message Framework activity in SAE and the linkage to
1609. It was decided that this could be accomplished with the linkage being between the
1609.0 work and SAE.
During a discussion of the status of 1609.3, Lee Armstrong stated that work still needed
to be done to insure that all the comments from the Sponsor Ballot had been addressed. It
was believed that comments concerning the PICS were completed.

ACID/ACM Discussions
Lee brought up the issue of ACID/ACM. He reported that the white paper he had sent to
the reflector had had very few comments. He also commented that the tutorial sent to the
RAC was slightly different than the one sent to the reflector. He had subsequently sent
the tutorial sent to the RAC to the reflector on September 13 and this document was dated
September 1, 2006.
Lee reviewed the document during the meeting highlighting the main points. Alastair
comment on his email input concerning this tutorial with specific reference to the fact

1
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

that he thinks the document should be taken to a higher level discussion. The objective is
to find a way to identify the application. Also discussed was the need for a hierarchical
approach rather than a flat space approach. If we have a hierarchical approach we can
support classes of applications which allows for other organization to control.
Specifically the RAC would control the ACID and other groups could control the ACM.
The issue of the RAC’s concern was discussed. They do not want to be the deciding
authority on who gets ACIDs. They only want to validate if the forms have been filled
our correctly. Their concern is that they will be making decisions on who gets ACIDs
based on criteria that they don’t want to manage. This is a motivation for their
recommendation of a 4 byte field thus creating enough capacity to avoid future
contention.
Alastair suggested that ACID defines application capability. This lead to a discussion of
what ACID defines. Is messaging structure defined by ACID? Doug suggested that we
focus on understanding and/or defining ACM before we address ACID. The comment
was made that the definition of ACM has been growing because we defined ACID as a 1
byte field. The question was raised if ACID alone is sufficient? Comment was made that
we need to agree on the function of ACID/ACM before we can go into more detail. It
was agreed that an ACM is unique to an ACID. ACID is not required to have an ACM.
Follow this, a discussion of the meaning of a context mark ensued. Can a message set
vary by context mark? At his point Doug focused the discussion using flip charts which
were filled in as follows:
Discussion start
1 Context mark in PST only
No context mark in WSMP header
No context mark for WSM in CCH
ACM still variable length
1a Does stack or application match context mark?
2 multiple ACID registration at provider
if multiple, ACMs per ACID PST
UDP only
*single ACID including all hierarchy registration
3 multiple ACID registration at users
Single user registration per ACID
4 ACID hierarchy
Currently class.subclass
Management issue only
Issues: manage available space
5 Response to RAC
6 Name the fields
Revise processing

ACID Hierarchy
1 Manage available ACI space
2 Subclass could be variable length
3 length of class/subclass fields

2
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

4 control of message sets
5 issue certs by class and covers entire subclass
6 hierarchy may simplify registration
7 ACID version in subclass
- minor convenience issue
- can support backwards compatibility

ACID = class.subclass

Proposal:
1 No ACID extension (future expansion)
2 Reserve 10M values for 1609 WG future use

Lunch Break

SAE Update
Following the lunch break Frank Perry presented on the SAE work. The following are
the highlights:
 Subcommittees are organized around ACIDs
 Expect J2735 to be approved this week and then published
o There are 58 data elements
o 29 data elements referenced in 2735
o 13 Data Concepts
 The current draft has 5 messages defined and they are:
Basic Safety Message
Common Safety Request
Emergency Alert/Vehicle Alert
Generic Transfer
Probe Data
 The subcommittees working within the DSRC Technical Committee are:
Vehicle Safety
Public Safety
Message Framework
Traffic Info
Fee & Fleet – Currently inactive
Digital Maps – Currently inactive
 The Work Plan for the Technical Committee for 2007 is:

3
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

Revisions and amendments to Version 1 from VII POC, CAMP, IEEE, etc.
Develop a “Users Guide” to assist in using J2735
Further define the Message Dispatcher concept
Integrate/Coordinate the IT IS and ATIS Standards with J2735
 During a discussion after the presentation, Frank said the SAE currently expects
to define when to use WSMP and IPV6.

World Congress 2008 IMS Update
Jules gave an update on plans for the IMS in NYC in 2008. He said that this IMS would
be different in that some or all of the systems would remain in place after the World
Congress and continue to be utilized. He said that in addition to previous demonstrations
there would be Toll Bridge, Height Warning, and Intersection Collision Warning
applications. Jules is the contact person with respect to this IMS activity.

Resumption of ACID/ACM Discussion
Doug drew the following on flip charts to illustrate User and Provider relationships with
respect to messages and multiple applications.

Decide on ACID or ACM
User needs knowledge of switch
App 1
User
App 2

User
App 1
Provider
App 2

OR
User
App 1
Provider App 3
App 2

4
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

Doug’s proposal is to have a single ACID / Port. This would move routing up a layer.
At this point the group held a discussion on the need for hierarchy in the ACID/AMC
scheme. The real question is what does a hierarchy approach add over a flat ACID
scheme?
Once again going to flip charts Doug led the group discussion on framing the issues
which he listed as:
ISSUES
1. Manage available ACID space
2. Subclass could be variable length
3. Length of class / subclass fields
4. Control of message sets
5. Issue Certs by class (cover entire subclass)
6. Hierarchy may simplify registrations
7. ACID version in subclass
Doug also suggested that we tell the RAC that we want to reserve X ACIDs for the future
use of the 1609 WG no matter what solution we decide on. The group agreed with this
suggestion.
Since in was late in the day Doug suggested that we take a straw poll before recessing the
meeting. The results were:
Flat 6
Hierarchy 2
Abstain 8

Minutes, Wednesday, October 4, 2006
OmniAir Presentations
The first item of the day was an OmniAir BoD Presentation. This presentation was sent
to the 1609 reflector on 10/4/06.
The second presentation was given by SwRI on Test Method Development. It was also
sent to the 1609 reflector on 10/4/06.
Following these presentations a brief discussion was held in which topics like the
possibility for self certification were discussed. Also it was mentioned that Bluetooth®
has an evolved certification process and that OmniAir might benefit from lessons learned
in the Bluetooth SIG. John Moring volunteered to help with this effort. Also, during
discussions it was mentioned that OmniAir and SwRI will need to get the IEEE OK to
create derivative work when developing testing plans. They will also need to decide on
which versions of the 1609 documents to use when developing test methods.

5
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

Update on FP6 & FP7
Dick Roy gave a verbal update on activities with in the 6th Framework Project and plans
for the 7th Framework Project in Europe. It was noted that there will be an open
workshop to be held in Brussels on October 18th and 19th by the 6FP CVIS project. The
purpose of the workshop is to review the use cases and requirements collected thus far
and seek additional ones.

VIIC Update
Doug gave a VIIC presentation which was sent to the 1609 reflector on 10/4/06. Scott
Andrews joined in via the phone during the presentation to assist Doug. Discussions that
occurred during the presentation and after it included:
 Commercial vehicles and not being addressed at this time. They will be
addressed in the future.
 It is not yet agreed upon as to how the random MAC address scheme will be
accomplished.
 The feeling is that the number of bytes required for security is too large.
 It was stated that VIIC will want 1609 to make changes, to reflect what they are
doing so that they can be compliant. This is to be expected as early
adopters/implementers are encouraged to give feedback relating to improvements
needed in the standard.
 A denial of service attack has been identified. In the presentation it says it is a
1609.2 problem but after discussions it was agreed it was really a 1609.3 problem.
John Moring agreed that he could fix the problem by not terminating a service if
an invalid cert comes in but leave what action to take to the application.
 The auto OEMs do not see any need to have applications standards since they
won’t allow open platforms. Any application going on their platforms will need
to be qualified by them.

Security Update
William Whyte gave a verbal update. He said that the next version of the Security
Guidelines will be available within a few days. Also, he said that the outcome of the
ACID/ACM discussion would likely have an impact on both the Security Guidelines and
V2 of 1609.2

Resumption of the ACID/ACM Discussion
Doug presented a proposal in PowerPoint form. After extensive discussion what follows
is the amended proposal. The discussion points are noted after the presentation material
within these notes.

ACID Proposal for the RAC
 Flat ACID of 32 bits

6
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

 ACIDs 0x0 and 0xFFFFFFFF are not assignable
 ACIDs 0x1 to 0x20 are pre-assigned
• RAC needs to record current Point of Contact for each
 ACIDs 0x21 to 0x7FFFFFFF are currently available for RAC assignment
 ACIDs 0x80000000 to 0xFFFFFFFE are reserved for future 1609 use
• Could be used to create a future hierarchical space
 An applicant submitting multiple ACID requests at the same time may request
that the ACID numeric values be assigned sequentially
 Each ACID request must be individually justified and paid for in the same
manner as would be otherwise required for an individual ACID request

Doug Kavner provided the following proposal:

Proposal for ACID/ACM/ACF Usage in
1609.3
 ACM (variable length) appears in PST only
 ACM removed from WSMP header
 WSA Certificate contains ACIDs but not ACMs
 A PST shall not contain duplicate ACIDs
 A UST shall not contain duplicate ACIDs
 Remove ACF from the PST

Proposal to Rename Fields
(during the following discussion on renaming fields, Lee gave a presentation
entitled ACID naming.ppt, that explained why the term “service” was
inappropriate for naming this field and “application” was the technically correct
terminology when considering the protocol stack of 1609.) What follows is a
summary of the multiple rounds of voting on the candidate names.
 ACID  (Round 1)
 SID (Service Identifier) 2
 AID (Application Identifier) 2

7
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

 ASID (Application Service Identifier) 6
 WPID (WAVE Port Identifier) 3
 WIP (WAVE Interface Point) 4
 Other 4
 ACID  (Round 2)
 ASID (Application Service Identifier) 4
• Identifies a service provided by an application on the
provider side that is offered to a user application
 PSID (Provider Service Identifier) 4
• Identifies a service provided by an application to another
WAVE device
 ASID (Application Set Identifier) 1
• A number that identifies the set of applications that are
associated with that number
 WPID (WAVE Port Identifier) 2
 WIP (WAVE Interface Point) 5
 Other 6
 ACID  (Round 3)
 ASID (Application Service Identifier)
• Identifies a service provided by an application on the
provider side that is offered to a user application
 PSID (Provider Service Identifier) ****
• A number that identifies a service provided by an
application to applications on other WAVE devices
• Moved by D. Kavner, seconded by J. Madey
• Approved by unanimous consent
 WIP (WAVE Interface Point)
 CID (Component ID)
• Generic term without baggage
 EID (Element ID)
• Generic term without baggage
 WID (WAVE Identifier)
 WCID (WAVE Component Identier)
 Other

8
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

ACM 
 SCM (Service Context Mark)
 SSA (Service Selection Attribute)
 CDF (Context Data Field)
 PSCF (Provider Service Context Field)
 PSC (Provider Service Context) ***
• A field associated with a PSID containing supplementary
information related to the service. The format of the PSC
is PSID dependent.
• Moved by D. Kavner, seconded by R. Noens
• Approved by unanimous consent
(As part of the discussion on this motion, Lee pointed out that this is not just a name
change from ACM to PSC, but a change in the function performed by this field. It is no
longer a part of the application/service identification, but is now a data field to be passed
to the application. It has nothing to do with application/service identification any more.
What used to be an identifier made up of two parts (ACID and ACM) is being merged
into just one single item, the PSID. What was the ACM is no longer used. A new field is
being created, the PSC, that serves to use the announcement to pass data to an
application. The PSC replaces the ACM within the message constructs (uses the same
field placement), but is not used for the same purpose at all, it is something totally new.
Lee pointed out that this a significant change and people need to be aware of it, but no
further discussion occurred.).
 PSCI (Provider Service Context Information)
 PSCI (Provider Service Context Identifier)
 PSCC (Provider Service Context Code)

Updates to 1609.3 V1
 Incorporate all above proposals
 Application matching based on PSID only
 Keep both automatic WBSS join and confirm before join models
 PSC is removed from the UST

9
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

• If a PSC is present in a PST for a PSID registered in the
UST for automatic join, the WBSS is joined unconditionally
• The PSC is still included in the application activation
notification sent to the user executable that registered the
PSID in the UST
 Change from normative to informative the requirements on HOW a PST is
processed – Defer to V2
 No change to current functionality
 Retain need normative requirements for WHAT is done
 Correct Denial of Service vulnerability if a WSA update is received with
incorrect credentials while a WBSS is active
 Ignore WSAs with invalid credentials (logging is OK)
 Processing of WSAs with valid credentials is unchanged
 PSC Maximum Size
 Discussion
• Sponsor ballot version has 255 bytes, WG poll in ~May 2006
to change to 32 bytes in response to comments
• OEMs have objected to 32 bytes, however that was when
the PSC was in the header of all WSMs
• Having a max of 32 bytes allows flexibility and potentially
saves WSA space if the longer PSC can be used to
eliminate extra PSIDs in the PST at a minimum cost of 32
bytes each
• Systems using WAVE are always free to set requirements
on which PSIDs are supported by the System. Maximum
PSC size may be a criterion for deciding which PSIDs to
support.
• Allowing the PSC to be too large enables it to be abused to
exchange data
 Proposal 1: Retain maximum of 32 bytes, add informative
statement that services should be designed to use the smallest
PSC possible and is not to be used to exchange application data
• Moved by D. Kavner, seconded by J. Madey
• Approved by unanimous consent of the diehards still in the
room
 Proposal 2: Add maximum PSC length for each PSID to WSA
certificate

10
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

• Rejected as being a form of application certification, which is
outside the scope of 1609.3

The following discussion notes are to capture topics, no decisions were made:
 Key elements are Flat with ½ reserved for 1609 WG use
 We are really talking about a service of an application which creates some
confusion
 Want to have confirm before join to dictate this behavior
 Added multiple requests with sequential assignments as a compromise. This
would enable the use of hierarchy implementations while keeping it outside the
scope of this standard.
 Dick was concerned that unauthorized applications would be allowed to work.
The comment was made that we are not certifying the applications. That is done
outside the scope of 1609.
 We will not allow multiple applications to use the same ID
 When looking at names it was felt that Application and Service had a lot baggage
which creates problems for both terms.
 We are not going to support ID # recovery. Once assigned it can never be reused.
 The straw poll on whether the ID should be 3 or 4 bytes was a 7 to 7 tie. It was
decided to go with the 4 bytes (32 bits)
Doug used the flip chart to present the following examples when discussing the
relationship between ACID and ACM:
Examples
ACID ACM
47 = Gas (Texaco)
48 = Parking (Central Parking)

ACID ACM
47 = ePayment 0001 Gas
47 = ePayment 0010 Parking
47 = ePayment 0011 both

ACID

11
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

47 = ePayment Provider information is in the 1st message

NOTE: The motions and results relating to the ACID/ACM discussions and the RAC
response are noted above in the presentation material.

Notes Taken by Tom Kurihara after R. Noens Departure
Affirm that we have reached consensus on the use of the ACID (now PSID) and the
elimination of the ACM. We also added an new term, PSC. Note that the purpose and
functionality of ACM and PSC are not the same as noted earlier in these meeting
notes. The PSID would be a flat four-byte space, as suggested by the RAC, with a large
block of addresses reserved for future use.
Time line.
October 5 Complete discussion in P1609 working group
October 13 Author complete changes to P1609.3D20 and send to project editor
October 19 Project Editor complete formating and cross reference check and noting
additional changes made to the draft that were not covered by the comments
October 20 Project Editor to .csv file and draft to WG Chair to initiate a 15-day
WG review of a sizable document with changes
November 3 WG review period closes
November 10 Author and Project Editor address WG comments, completes entries in
.csv file and completes draft to WG Chair for first recirculation November 11 WG chair
submits request for first 10-day recirculation ballot November 12 Start first recirculation
ballot November 22 First recirculation closes November 30 Author and Project Editor
completes review of comments and changes in
voter positions and prepare responses December 6 Start second recirculation ballot if
needed, other wise prepare .csv
file and draft for REVCOM submission (anticipate submission closing date as January
23, 2007)
The above, give or take a day or two was agreed to shortly before the close of the
meeting on Wednesday and after the secretary had departed. The above is also subject to
change, the objective being to complete all of the milestones before the next REVCOM
submission closing date.
Remaining to be done on Thursday this week is to discuss additional technical issues
(comments) to Dot3 that were discovered after the close of the initial sponsor ballot and
requires WG discussion and decision and confirm the next meeting dates
A request was made to IEEE to ask A. Weaver, RAC Administrator, to call the
teleconference number 1-888-346-3659, participant code 51006# at or after 0930, to
discuss RAC requirements, answer any questions that the WG has regarding the RAC

12
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

procedures, and timing of submission in view of the changes in the completion and
REVCOM submission schedule for P1609.3. The WG did not discuss nor determine the
time line for preparing the material for RAC and the WG review period to gain
agreement that it is consistent with the changes made to P1609.3, knowing that the draft
will not be submitted to REVCOM until January 2007.

Minutes, Thursday, October 5, 2006
Rick Noens not present.
Draft minutes taken by J. Madey.

Thursday
October 5, 2006
Minutes

Begin 0855
F. Weytjens up first with comments to 1609.3
-----------------------------------------------------------------------------------------------------
See attached Excel File
Comments_P1609_3D18Edited..xls
-----------------------------------------------------------------------------------------------------
J. Moring will respond to written comments from F. Weytjens

Next up 10:00
Telcon with Angela Weaver, IEEE Registration Authority Committee Administrator.
Angela stated that since the schedule for the approval of Dot 3 has been rescheduled for
March 2007, there is less urgency in getting the tutorial, application form, and other
supporting documentation prepared and ready for RAC review and approval.

Follow on discussion to the RAC discussion yesterday

L. Armstrong
Questions re managing number (PSID) set to be assigned
Armstrong: If there are existing numbers that can be used, don’t ask for another?
Weaver: Similar situation in the ether type field but there are potentially millions of
numbers involved and a simple keyword search may not suffice
Armstrong: What is the control mechanism you use for ether type?
Weaver: A consultant reviews the intended use statement and suggests whether a
new ether type is needed.
Armstrong: Consultant review is new info
Weaver: Paid consultant gets emails when application made and has 90 days to
return a decision
Armstrong: Assumption we made is that RAC gets a request and the application is
granted without a formal review process
Weaver: Saw info from WG that did need review but heard later that we may have
opted out of the formal review

13
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

Armstrong: Mutual misunderstanding regarding the review process
Tom: part of the confusion might be due to the WG eventually going out of business
Weaver: So RAC needs recommendation of someone who could perform the
consultant review function
Armstrong: Our real concern is managing the number set
Kurihara: We now need to consider what happens when the present WG dissolves
Armstorng: Other questions regarding the scale of the application process. Can info
be in a data base rather than a flat file?
Weaver: Typical starting operations are flat file until or unless indication of scope
requiring a data base structure is given
Armstrong: We can provide the information required for creation of a database
Weaver: Format for the ethertype process was sent to Tom. Specific dates can be
changed as needed.
Weytjens : Fees … concern about customers blocking
Weaver: We can make a recommendation which RAC and business manager will
review. Depends upon amount of staff time needed for creation and maintenance of
the registry. Previous instances have resulted in either acceptance, reduction or
increase of the originating group’s suggestions.
Weaver; We can forward our comments and suggestions to the RAC for their
considerations
Kurihara: any further questions?
No
Weaver: Anything else that comes up can be forwarded to her by email
Kurihara: Once we have firmed up our input to the RAC on the registry, we probably
need to have another teleconference.

End of call at 10:15

(T. Kurihara: tentative schedule for next steps … to be inserted in minutes at this
point)

L. Armstrong: suggested application form for RAC PSID assignment
(insert in minutes at this point)

-------------------------------------------------------------------------------------------------------
-
See attachment to this word document: “Registration form.pdf”

-------------------------------------------------------------------------------------------------------
-ACTION ITEMS (this meeting only with numbered action items and TMK
suggestions added before circulating the draft minutes to the WG for consideration
before the meeting.)

200610 01. Form provides for information relative to management of the PSID
assigned values

14
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

T. Kurihara, L. Armstrong
200610-02. Discussion on the naming of L. Armstrong’s suggested fields … finish
this later, not important for the context of the applications format Lee has suggested
(F. Weytjens … web access for application form??)
The pdf file Lee created has XML data embedded … can fill out off line and, when
on line, can submit by email (Action pending includes the creation of a form and
format for posting to the IEEE RA web site to apply for a PSID. TMK)

200610-03.. D. Roy, T. Kurihara, L. Armstrong, F. Weytjens discussion on
identifying responsible organizations for a category relative to requesting a new
category (Suggest F. Weytjens lead this task, for completion before January 12,
2007, date for completing the IEEE RAC Tutorial. TMK)

200610-04.General discussion on two points: How does a potential user learn enough
about the process to determine what he needs and once the need is established, and
how does he apply and obtain an appropriate PSID? (Suggest L. Armstroing include
this informative information in the Informative annex to the IEEE RAC Tutorial.
TMK)

200610-05. L. Armstrong .. if a different message set than that used by existing
applications under an issued PSID, then an assignment of another PSID is probably in
order. (Need discussion electronically before January 12 before the tutorial is
circulated for review; may include different alternative views and ways of handling
based on service or message. TMK)

200610-06. C. Kain .. perhaps an industry consortium in the appropriate context for
the reviewing consultant. (Action item for C. Kain to research Uniform Code Council
or equivalent. Provide results at next meeting. TMK)

200610-07. What are IP issues, if any? Can an application be denied? (T. Kurihara
… denial is off the table) Is this discussion outside of our scope? (The comment was
made based on a completed request for registration, if complete, then processed for
approval,; if incomplete returned to sender for resubmission, not denial of application.
Should be addressed in the informative annex to the tutorial. Intent is to minimized
decision time for the IEEE RA. TMK)

T. Kurihara we are trying to establish a suggested process for the RAC to issue PSIDs

L. Armstrong .. we are required to provide information on where to go to get the
necessary information to resolve an assignment request. (Suggest that the process be
simple and based on the information submitted on the form and to avoid resolving
assignment request. The revised stand-alone PSID protocol differs from that of the
ACID/ACM to be assigned in a limited address space. Reservation of address space
for future allocation with rationale for that allocation is additional informative
information for the IEEE RA and for the applicants. TMK)

15
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

200610-08. L. Armstrong to include a view point in the tutorial. Many comments in the
current discussion relate to an applicant learning about the process before even touching
an application form … how is that need to be satisfied? F.Weytans .. when do we need
this procedure for the RAC Tom it needs to be in RAC hands when the standard hits the
street. (more detail, that is, the draft of the tutorial must be in the hands of the IEEE RA
at the same time that the Dot3 draft is submitted to REVCOM, February 9, 2007, to
obtain IEEE SASB approval of Dot3. TMK)

200610-09. Discussion on private vs public PSID; what’s the difference? Does private
imply IP rights? L. Armstrong. (Suggest that the previous assumption about the
ACID/ACM combination needs to be reviewed and adjusted accordingly given the flat
space for the PSID and the change in relationship between the use of the PSC from the
PSID. A note regarding the legacy assignments of the ACID (now PSID) needs to be
added to Dot3, if not already done. TMK)

200610-10. L. Armstrong. Discussion on control; who controls? What happens after
this group dissolves? Is control out of our scope; will it eventually be self regulating. D.
Roy … what is to prevent any PSID from being issued?? (Suggest that informative
material be included in the informative part of the annex accompanying the IEEE RAC
tutorial. TMK) Re K. Kain’s comments, the PSID applicant should be working through
or with industry consortia or representative user groups to insure enough knowledge /
resources on the part of the applicant (the ideal). The application for the PSID is the final
step.
But the form itself probably needs a tutorial. L. Armstrong reviewed the inputs from the
1609 WG requested by the RAC (inserted list from Lee here)
------------------------------------------------------------------------------------------------------------
-
• Questions to be answered:
– Address allocation amount (256 numbers is not enough)
– field size and flat number space
– How would one go about structuring an allocation
– procedure with the expansion numbers
– Are there any restrictions on obtaining assignments
(http://standards.ieee.org/faqs/OUI.html#q11 for example
– Explain issue of fair and equitable distribution of values
• Tutorial (similar to those located at
http://standards.ieee.org/regauth/oui/tutorials/) Oct. 2
• Provide procedures for grandfathering process for assignments that have been
issued Oct. 9
• Define public and private assignments and include instructions for customers in
either the standard or on the web pages
Oct. 23
• Provide text for web pages in Microsoft Word (Main page (similar to
http://standards.ieee.org/regauth/oui/forms) Oct. 30

16
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

• Application (similar to
|http://standards.ieee.org/regauth/1451/manufacturerID/Form1.html) or
https://standards.ieee.org/regauth/ethertype/ETH-form.shtml)
• FAQs (similar to http://standards.ieee.org/faqs/OUI.html)
• Public listing (similar to|http:// standards.ieee.org/regauth/oui/index.shtml
• Download the public listing to define what information will be distributed to the
public
• Revised web pages if changes made Nov. 16
------------------------------------------------------------------------------------------------------------
-

200610-11. Dates in the insert were based on a December publication and now need to be
changed re our telecon with Angela today. (Suggested dates for the March 2007
REVC6OM meeting, is the tutorial and all supporting information available for WG
review and comment before January 12, circulated on January 13, and review
completed before January 25 and comments and revised draft circulated to the WG
February 2 for discussion and approval at the WG meeting.

K. Kain: take a look at the EPC issuing process .. a very large flat space but internal
organization is hierarchical…
General agreement that it might be good to look at the UCC’s International Code Council
(ICC) handling of the those assignments …(Suggest considering sources for background
information and assignment procedures. TMK)

D. Roy strongly suggests that the PSC is no longer needed and is an opportunity for
abuse. L. Armstrong: not part of this discussion.

200610-12. Do we review the EPC issuing process for consideration of that model? C..
Kain will discuss with T. Kurihara and L. Armstrong before Janaury 11.

Discussion on price… one determining element is cost of processing by the RAC. We
(the working group) will not set price but will describe the process we recommend so that
RAC can establish the price. We don’t need the actual number at this point.

200610-13 D. Roy … straw poll … how many people believe that the RAC should
simply rubber stamp the application … form: “I want a number, please send number to
this address” Or at least a very simple form….Discussion (no poll taken) (See form
developed to support the registration and assignment process. The goal is a simple
assignment conforming to the already assigned IEEE RA and RAC tutorials posted to the
IEEE RA Web site; not a “rubber stamp,” but based on the information submitted by the
applicant, thus the form should include the concerns that was the basis of the R. Roy’s
words. TMK)

17
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

200610-14. L. Armstrong include in informational material supporting the tutorial.
TMK) J.Moring what happens when the applicant for the PSID dies or otherwise no
longer exists as a point of contact? T. Kurihara, assumption is that applicant is
responsible for updating that point of contact and it is somewhat of a black hole.
If two people think they own this number, how is it resolved. D. Roy, but the number
wouldn’t be reissued … John, but if I buy one with some friends and they go their
separate ways and we both claim we the PSID, what happens .. D.Roy …PSID not
effective unless the app is certificated (Suggested procedural and informational material
for the annex supporting the tutorial and form. TMK)

General discussion on “ownership” of the PSID

T. Kurihara .. is the “ethertype” assignment process similar to our needs

L. Armstrong … hasn’t heard anything in opposition to Dick’s specific proposal for the
form (still no poll taken).

200610-15. L. Armstrong. (Already covered in suggestions and other action items for
inclusion in the tutorial and supporting information thereto, but needs to be addressed
explicitly and for agreement by the commentors. TMK) So how do you know whether
you need to apply? Provide web accessible information to make that decision.

L. Armstrong .. suggests going to the IEEE website on ethertype application to see how
it is done.
F. Weytans .. interested in learning what criteria that process has for denial. (Insturction
supporting the form must be explicit on information required, otherwise the form is
returned for further elaboration, not denied.

200610-16. T.Kurihara … time line for input for RAC (T. Kurihara to submit to RAC
Adminsitrator, not later than February 9, 2007, however, advisable that RAC have time to
review, discuss, and comment before REVCOM meeting in March 2007; otherwise we
may have REVCOM provisional approval or rejection of Dot3. TMK)
L. Armstrong .. by Thanksgiving, will have a set of inputs to the RAC questions ready for
stoning by the WG members (NOT Met. Revised date is February 9, 2007. TMK)

200610-17. SwRI to confirm venue and dates. Possible move next meeting to 2/6-2/8,
still at SwRI … D. Kavner had a conflict with the earlier date. (SwRI action completed,
see meeting and lodging information. TMK)

T. Kurihara … any further business? No additions

Meeting adjourned at 11:52

Attendees
IEEE SCC32 DSRC WORKING GROUP P1609 Sign-up list
Revised: October 5, 2006

18
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

IEEE Int NAME E-MAIL ADDRESS 10/19 11/01 03/01 05/10 07/12 10/03-
Mbr or Cat & 11/03 03/03 05/12 07/14 10/05
Inv Exp P,U 10/21 2005 2006
A,GI TC
IEEE SA P Andrews, Scott scott@cogenia.com xTxT xxx xx- xTxT- -xT-
IEEE GI Armstrong, Lee lra@tiac.net xxx xxx xxx XXX xxx
SA
G Arnold, James James.a.Arnold@fhwa.dot.gov xxx
P Bai, Fan Fan.bai@gm.com - x xxx -xx
P Bathrick, Ward Ward.bathrick@ratheon.com ---
AASHT GI Brownlow, William WBrownlow@aashto.org - - - - XXX
O
GI Brummond, Jeff jab@iters.com xxx
GI Cash, Broady BCASH@arinc.com xxx xxx xx- XXX
IEEE Staff Ceglia, Matthew m.j.ceglia@ieee.org xxx
SA
GI Char, Ronald K. Ronald.Char@jhuapl.edu ---
P Chen, Chi chen@rtna.daimlerchrysler.com ---
IEEE SA P Cook, Ken kcook@ivhs.com xTxT xTxTxT xT-xT xTxT-
P Delpose, Luca luca.delpose@dex.com - - xxx
IEEE SA P Dessouky, Khaled kdessouky@technocom-
wireless.com
U Dickey, Susan dickey@path.berkeley.edu xTxT xxx xxx XXX
U Dulmage, Jared jaredd@ee.ucla.edu ---
IEEE SA P Ely, Joe ely@trmi.com xTxT ---
IEEE SA Fisher, Wayne wfisher@arinc.com xxx xT-- xx- XXX xTxTxT
IEEE SA U Fitz, Michael fitz@ee.ucla.edu ---
P Gaeta, Mike gaeta@intrass.com ---
IEEE Staff Gerdon, Patricia p.gerdon@ieee.org
IEEE SA U Gerges, Ramez ramez-its1@ieee.org
P Graham, Susan sue_graham@denso-diam.com ---
U Gwynne, Gloria ggwynne@dot.ca.gov xTxT xxx - xT-
P Hedges, Chris chris.a.hedges@delphi.com xTxTxT xTxTxT
IEEE SA P Hochnadel, Ron ronh@intrass.com xTxT xTxTxT xTxTxT xTxTxT xTxTxT xTxTxT
P Honma, Miyoko miyoko_honma@denso- ---
diam.com
P Hunzinger, Jason jason_hunzinger@denso- ---
diam.com
U Ingram, Mary Ann mai@ece.gatech.edu - - - ---
P Jiang, Daniel daniel.jiang@daimlerchrysler.co xTxT xx-
m
IEEE GI Kain, Carl ckain@mitretek.org xTxT xxx xTxTxT xxx
U Karnik, Pankaj pankaj.karnik@jhuapl.edu -xx
IEEE SA P Kavner, Doug dkavner@raytheon.com xTxT xxx xxx xxx xx-
IEEE SA GI Kelley, David davidkelley@ITSware.Net
P Khijniak, Dmitri dkhijniak@technocom- - - - - XXX
wireless.com
P Kircher, Max max.kircher@bmw.de - - xxx
GI Kind, Brian brian.kind@jhuapl.edu ---
IEEE SA P Kohli, Japjeev jkohli@ivhs.com xTxT
U Koga, Keiichiro k-koga@da.jp.nec.com
P Korowajczuk, leonhard@celplan.com xT--
Leonhard
GI Kreeb, Bob kreeb_bob@bah.com ---
P Krishnan, Hariharan.Krishnan@gm.com ---
Hariharan
P Kukshya, Vikas vkukshya@hrl.com ---
IEEE SA GI Kurihara, Thomas tkstds@mindspring.com xTxT xxx xxx xxx XXX xxx
M.
P Laberteaux, Ken klaberteaux@ttc-usa.com ---
IEEE SA GI Lamm, Ryan rlamm@swri.org xxx

19
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

IEEE Int NAME E-MAIL ADDRESS 10/19 11/01 03/01 05/10 07/12 10/03-
Mbr or Cat & 11/03 03/03 05/12 07/14 10/05
Inv Exp P,U 10/21 2005 2006
A,GI TC
IEEE SA P Landt, Jerry jerry.landt@transcore.com xTxT xTxTxT xxx xxx xxx
IEEE P Lee, Chu Hee Chuhee.Lee@vw.com ---
P Liu, Jason jliu@technocom-wireless.com xTxT xT-- xx-
IEEE SA U Madey, Jules jules.madey@thruway.state.ny xTxT xTxT- xTxTxT xTxTxT XXX xxx
GI Mak, Tony tonykm@path.berkeley.edu ---
P Malarky, Alastair amalarky@ivhs.com - - - Xxx XXX xxx
P Mangold, Heiko mangold@rtna.daimlerchrysler.c ---
om
GI Marshall, Mira marshall_mina@bah.com ---
U McGuickin, Tim mcguickin@omniair.org x--
IEEE SA P McNew, Justin jmcnew@technocom- xTxT xxx xx- xxx XXX
wireless.com
IEEE SA GI Morgan, Yasser yasser.morgan@transcore.com xTxT -xx xxx xx-
IEEE SA GI Moring, John jmoring@technocom- xTxT xxx xx xT xxx
wireless.com
IEEE SA ITE Morris, Ross morrisR@wsdot.wa.gov xTxT xxx
Rep U
IEEE P Mostafa, Kassem mostafa.kassem@transcore,com
IEEE SA P Noens, Richard rick.noens@motorola.com xxx xxx XXX xxx
DIC O’Connor, Roger rjoconnor@highway- -- xT
electronics.com
NPST O’Hara, Sean ohara@syrres.com
C
IEEE P Oomen, Peter poomen@ivhs.com ---
IEEE SA U Oyama, Sam Oyama@siji.hitachi.co.jp xxx
U Park, Joon Gou tgpark@samsung.com ---
P Patno, Brian bpatno@raytheon.com ---
P Peredo, Gordon peredo@rtna.daimlerchrylser.co ---
m
P Perry, Frank fperry6@ford.com xxx xxx x--
GI Pickering, Craig pickering_craig@bah.com ---
GI Proper, Susan sproper@mitretek.org xxx
P Puwala, Ravi ravi@zazunetworks.com - - - - XX xxx
GI Pundari, Mohan mohanp@mohan.com
GI Rai, Vinuth vinuth@us.toyota-itc.com xxx
GI Rescora, Eric ekr@itfm.com xxx
P Rinchiuso, Joe j.rinchiuso@motorola.com - - xxx XXX
P Ring, Ed erjring@mmm.com ---
A Robinson, Craig crobinson@ttc-usa.com ---
IEEE SA P Roebuck, Randy rdroebuck@sirit.com xx- xx- xxxT XXxT xTxTxT
IEEE SA GI Roy, Richard dickroy@alum.mit.edu xTxT xxx xxx xTxx XXX xxx
P Ryan, Dave djryan@raytheon.com ---
IEEE SA GI Sabounghi, Lewis Lewis@Sabounghi.com ---
IEEE GI Schaffnit, Tom tom@schaffnit.com ---
IEEE SA P Schnacke, Dick dick.schnacke@transcore.com ---
IEEE P Serviss, Jerry jerry.serviss@motorola.com xTxT xTxTxT
GI Siesel, Douglas des@iteris.com ---
U Schumitz, John schumitz@pbworld.com xxx
IEEE SA U Sheppard, John jsheppar@arinc.com - xxx ---
IEEE SA P Soor, Hardev hsoor@technocom-wireless.com
IEEE GI Soranno, Robert Robert.Soranno@jhuapl.edu xxx xxx xxx xTxT-
IEEE SA P Spenler, Stephen spenler@ivhs.com xTxT
P Spurgeon, Bill bspurgeon@siritcorp.com ---
U Sung, S.K. s.sung@samsung.com ---
P Tang, Wai-cheung wctang@ivhs.com
P Tengler, Steve tengles@ntcna.nissan-usa.com
P Terrier, Dan dterrier@ivhs.com xTxT

20
Preliminary draft: Minutes IEEE P1609 WG meeting, October 3-5, 2006

IEEE Int NAME E-MAIL ADDRESS 10/19 11/01 03/01 05/10 07/12 10/03-
Mbr or Cat & 11/03 03/03 05/12 07/14 10/05
Inv Exp P,U 10/21 2005 2006
A,GI TC
P Tong, Roger rtong@ivhs.com ---
P Trerotola, Ron rtrerotola@technocom- ---
wireless.com
P Turnock, Glenn gturnock@ivhs.com xTxT xTxTxT -xTxT
P Wells, Bryan Bryan_Wells@denso-diam.com x- xx- xT- XX- xTxT-
IEEE P Weytjens, Filip fillip.weytjens@transcore.com xx- xxx XXX xxx
IEEE SA P Whyte, William wwhyte@ntru.com x-- x-- xx- X-- -x-
P Williamson, Bill bwilliamson@eviewsinc.com xxx
P Wilson, Chris christopher.wilson@diamlerchrys ---
ler.com
P Xing, Daniel dxing@us.toyota-itc.com - - - - XXX xxx
P Yamamoto, t-yamamoto@bu.jp.nec.com
Takeshi
P Yin, Jijun jijun@hrl.com
P Zhu, Jeffery jzhu@ivhs.com ---
GI Wolff, William bwolff@swri.org - - - - - xxx