stds-80220-requirements: Requirements Document rev 6: some comments on items for closure
Dave et al
I have some comments on items for closure. Hopefully we can discuss
these briefly on the call tomorrow.
Section 4.5.1.1-4 Various types of handoff (Closure Proposed)
These sections are empty of text. Does this mean they will be removed
once "closure: is reached? If so, I agree that they should be removed.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Section 4.1.16.1 Access Control (Closure Proposed)
I agree with Alan Chickinsky's comment/question on this section.
Action: Change the whole paragraph to "A cryptographic method shall be
used."
Reason: A secured connection is what we care about whether or not it is
challenge response or certificate based. Also a challange-response is
at layer 7, not layer 2.
Here is Alan's original comment:
5- In 4.1.15.2 "Access Control" We should change the the whole
paragraph to
be "A cryptographic method shall be used." For example a secured
connection
using a certificate is not considered "challange-response". Also a
challange-response is at layer 7, not layer 2.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
4.5.3 CPE software upgrade .push. (Closure Proposed)
Please note I had the following response dated Aug 1 not shown
in Rev6 to Neka's comments:
"Regarding code push to the UT, this is a management function
independent of the air interface, and dependent on the
on the operations processes of the ISP or network operator.
AlOan Chickinsky made an excellent proposal at the meeting last week.
He said that, for those requirements that are not at the PHY/MAC level,
we need to understand what features the PHY/MAC
must support. It would be helpful if you would recast
your requirement in those terms. In this context, I believe it is
safe to say that the PHY/MAC could accomplish what you suggest through an
appropriate QOS service level for the code data itself.
Finally requirements on the number of code images a UT should support
and how it switches between the two are clearly out of the scope
of the PHY/MAC and should not appear in the requirements document."
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Section 4.5.4 OA&M Support
I have looked through the emails on the reflector and see that there has
not been discussion regarding the text in this section. While these items
are clearly valuable tools for monitoring the 802.20 air interface
by a network operator, the list is certainly not complete, and the level
of detail is inconsistent with where the rest of the document
and is inconsistent with the general consensus to stick to simple
requirements.
I therefore propose that we eliminate the exhaustive list of different
variables and replace it with general text eventhough the "5 day consensus
period" has passed
Action: Remove exhaustive list of items in section 4.5.4
Replace with: The air interface will provide necessary infrastructure
in order for a network operator to monitor the performance of the
802.20 air interface.
Rationale: The section is currently too detailed given the consensus
around simple requirements. Also, the "sideways management" piece of the
protocol reference model implicitly mandates this functionality.
Regards
Mike
Michael Youssefmir
ArrayComm, Inc.
On Wed, Aug 06, 2003 at 06:00:33PM -0500, Mcginniss, Dave S [GMG] wrote:
> Agenda for the Requirements group call scheduled for Thursday August
> 14th at 1:00pm CDT. The current version for this call and ongoing
> discussion on the exploder will be Revision 6.
>
>
>
> The call-in number will be 888-517-2888 Pin 34557.
>
>
>
>
>
> 1 Closure of all items having no comments since the
> plenary meeting that have content not in contention. The revision 6
> version has these sections marked (Closure Proposed).
>
> 2 System Reference Model Discussion.
>
> 3 Packet/Frame error rate
>
> 4 Antenna Diversity
>
> 5 Update on RF (Link Parameter issues) discussed on
> Wednesday the 13th.
>
> 6 Duplexing.
>
> 7 802.1q tagging.
>
> 8 Call Blocking moved to Layer 3 + Support.
>
>
>
> David S. McGinniss
>
> Sprint Broadband Wireless Group
>
> Principal Engineer II
>
> (630) 926-3184
> david.s.mcginniss@mail.sprint.com
>
>
>
>
>
>
>