|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
|The Call for Comments on the 802.16m SDD is available:|
The deadline is 5 January AOE.
Please number any associated contributions in the format "C802.16m-09/xxx", using the new year designation. Please use the "09" for all contributions to Session #59.
Note that Shkumbin has prepared an updated Comment Resolution Database
with Editor's Notes. In addition, he wanted to call your attention (see below) to a few problematic comment resolutions. If you are concerned with the way he resolved these issues, please submit an appropriate comment according to the Call for Comments mentioned above.
There were few comments that I had some issues with and they are listed below:
- Worth noting:
1. Technical Comment #510 is conflicting with #511. This is not straightforward as such since there was a significant vote on both comments. I decided to go with #510. I explored a possibility to merge both but it makes no sense.
2. Technical Comment #014 was very difficult to implement. There are few sections that will likely need a clean up in the future.
- Minor ones:
2. Technical Comment #173: I did not implement this one since it is not clear what part of SRD I need to include (and where). Section 5.6 of the SRD outlines requirements and I don't think they need to be repeated in the SDD.
3. Technical Comment #167: The resolution of that comment has been captured in a suboptimal way (to put it mildly). I chose to implement 1410r3 and this decision was taken based on the context. Otherwise I would need to implement C80216m-08/046r3 which is a commentary DB!
4. Technical Comment #070: I did not implement this since it appears to be superceded by #072, however the spirit of comment #070 needs to be somehow captured in future revisions.
2. Editorial Comment #505 is conflicting with #506 (and #503, #504). I think that #506 is the appropriate (although that sentence needs modification due to #510)
3. Editorial Comment #456: Lei is proposing changing AMC to AMCS. I disagree since AMC is well established acronym and I don't think it needs changing in our SDD.
4. Editorial Comment #336: Re-arrangin sections would make it impossible to see what has been changed in those sections hence editor would like to deferr rearranging sections to a later stage (bascially as on of the last things to do prioir to approval).
5. Editorial Comment #334: it is not an error, the commenter got it wrong.