Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] [STDS-802-16m] IEEE 802.16m ASN.1 review activity

Dear Joey,

I'm confused.

I do not have the meeting minutes from Session 68.5 yet, but if I recall correctly, the TG agreed during the closing plenary that the draft would include ASN.1 code as an informative annex until the draft is sufficiently stable, at which time the ASN.1 code in the annex would be made normative.  This plan also follows the decision the group made earlier this year.

We accepted an update to the informative annex containing ASN.1 code, and we agreed, as a group, that instead of relying on a small group of individuals, a larger group would be formed to contribute and/or check the ASN.1 code going into the annex.  The Chair started a list of people who volunteered to participate, and just today the Chair initiated an open invitation to others on the reflector.

But looking at these contributions, these in no way reflect the decisions the group made during Session 68.5.  These contributions propose moving ASN.1 code directly into the normative body of the Draft, making that ASN.1 code normative, and they propose to eliminate the existing message tables in the draft.

Is this somehow supposed to be related to the group sanctioned ASN.1 review activity?  Joey, are you aware that you're on the email list for the group of ASN.1 contributors who have agreed to do something completely different than you're proposing here in these contributions?

Regards,
Ron Murias

On 2010-09-01, at 7:03 PM, Chou, Joey wrote:

At the Calgary meeting, TGm accepted a contribution 967r2 by a group of people to align ASN.1 code in Annex R.2 with message tables in D7 draft. I believe it was an important step, as it was the 1st attempt to align both message tables and ASN.1 code. However, there were still many isssues that generated heated discussions both offline and in the closing plenary of the Clagary meeting. These issues are sumarized below:
 
·        The ASN.1 code is one draft behind the message tables.
·        How can the ASN.1 code become normative, if the message tables are undergoing many technical changes in every meeting.  
 
After the Calgary meeting, Scott, Bancroft, Alessandro, and I had offline discussions on how to resolve the above issues. Here is our proposal:
 
·        Attached are two contributions http://dot16.org/ul//upload/TGm_db/C80216m-10_1090.doc  and http://dot16.org/ul//upload/TGm_db/C80216m-10_1091.doc  that move ASN.1 code from Annex R.2 to the corresponding sections in 16.2.3.
·        #1091 moves MAC-Control-Message structure and common type definitions to section 16.2.3,
·        #1090 proposes creating a subsection 16.2.3.1 .. n for each functional area listed in Table 678 (e.g. 16.2.3.1 Network Entry / Re-entry Messages). It moves all message beloning to such functional area to such subsections (e.g. 16.2.3.1.1 AAI-RNG-REQ). It then moves type definitions common to messages in a functional area to subsection 16.2.3.1, and moves ASN.1 code of network entry / re-entry messages after the message table in the corresponding subsection. The reason to co-locate table and ASN.1 code in a section is to align both table and its ASN.1 code, and promote changes to both table and ASN.1 code together in future sessions.  
·        If there are technical changes to the tables of Network Entry / Re-entry Messages, they can be harmonized with #1090  to generate one contribution to change both tables and ASN.1 code after the St Petersburg meeting. We intend to include a few messages in a contribution in order to simplify table and ASN.1 harmonization.     
·        After all ASN.1 code in Annex R.2 are migrated to specific sections in 16.2.3.x, then Annex R.2 can be removed. But, TGm can release separate ASN.1 ASCII file that can be used for ASN.1 code compilation and MAC message implementation. This is similar to the release of a separate MIB data file in 802.16-2009.
 
#1090 only covers Network Entry / Re-entry Messages. Additional contributions are needed to move other messages. The intent of this proposal is to align both tables and ASN.1 code in each new draft. We understand this is not an easy task. But, we have only have a few meetings left before closing 16m. We believe it is worth a try to resove this tough issue. Any comments are welcome.
 
Thanks,
 
Joey
 
 
From: Kiernan, Brian G [mailto:Brian.Kiernan@INTERDIGITAL.COM] 
Sent: Wednesday, September 01, 2010 8:24 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: [STDS-802-16] FW: [STDS-802-16m] IEEE 802.16m ASN.1 review activity
 
Sent: Wednesday, September 01, 2010 11:22 AM
To: Roger B. Marks; STDS-802-16@LISTSERV.IEEE.ORG
 
Subject: RE: [STDS-802-16m] IEEE 802.16m ASN.1 review activity
 
As was agreed during the 802.16m session #68.5 in Calgary, the Draft going forward will include the ASN.1 code as an informative annex, with the intent to update that code as the document evolves, ultimately making the code normative when the draft is sufficiently stable.  Up until now, this code (C-802.16m-10/967r2) http://www.ieee802.org/16/tgm/contrib/C80216m-10_0967r2.doc  has been developed by a fairly small group of dedicated individuals consisting of: Alessandro Triglia and Bancroft Scott (OSS Nokalva); Scott Probasco (Nokia); Wookbong Lee (LGE); Kelvin Chou (MediaTek); Taeyoung Kim, Youngbin Chang, Hyunjeong Kang and Youngkyo Baek (all from Samsung); and Joey Chou (Intel)
 
This message is an invitation for other 802.16 members with an interest and expertise in ASN.1 to join this group to help insure that the code accurately reflects the draft standard text as the document evolves.
 
If you are interested in participating in this activity, please e-mail me.
 
Brian