| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Joey, It is the co-location aspect that I like, as I agree with
you, it should make it much easier to review and verify the code. I’m just not
confident that most people are ready to deal with both text and code revisions
simultaneously. Brian From: Chou, Joey
[mailto:joey.chou@intel.com] Dear Brian, Thanks for your comment and recommendation. As you may know, it is a huge effort to generate contributions to
move ASN.1 code to specific section in 16.2.3. That is why we send out these contributions
on the reflector to test the water. The main objective is to co-locate the
table and it’s associated ASN.1 code in the sam section to ease the
review and encourage people making changes on both places. My major concern
about the MAC control messages in general is that the tables won’t be stablized
until the last 16m meeting. It is fine, if the group is not ready for this
proposal. As to the ASN.1 group you initiated in another email thread, I can
volunteer to lead such group, since I already have the ASN.1 tool set in place
to do such task. Thanks, and best regards, Joey From: Kiernan, Brian G
[mailto:Brian.Kiernan@InterDigital.com] Joey, While I have no inherent objection to this approach and there
even are parts of it that I like, I do recommend that the associated ASN.1
sections after each message table remain informative until we are confident
that a given table is finalized. Also, unless a given table change text
contribution includes the necessary revisions to the ASN.1 code and we can
review and approve those revisions during a session, the code will still be one
revision behind. Brian From: Chou, Joey
[mailto:joey.chou@intel.com] 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 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 11:22 AM 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 |