Re: [Seamoby] comments on the paging protocol assessment draft

["James Kempf" <[e-mail]>]

Yoshi,

> But it is still not clear why draft-renker is selected even based on
> the focused requirements, since the rating for draft-renker on each of
> those requirements are not the highest (see below).
>
>
>
|------------|------------|-------------|-------------|------------|
>    |            | Ref. [3]   | Ref. [4]    |    Refs.    | Ref. [5]
|
>    |            |            |             |-------------|
|
>    |            |            |             | [6]     [7] |
|
>
|------------|------------|-------------|-------------|------------|
>
>
>    (snip)
>
>    |    4.6     |            |             |             |
|
>    | Multiple   |            |             |  4/2     1  |
|
>    | Dormant    |    2       |     1       |             |     2
|
>    |  Modes     |            |             |             |
|
>
|------------|------------|-------------|-------------|------------|
>
>    (snip)
>

As I mentioned, this was not a top priorty requirement and was
not discussed during the decision phase. However, if you
want an opinion, as the assessment draft stated, draft-ohba
tied support for multiple dormant modes to 802.11 power
management, a specific link layer type, in Appendix A.
Draft-renker had nothing on this requirement, as the assessment
indicated.
What the requirement was really getting at was support for
time-slotted paging, and perhaps the requirement wording should have
been
more clear in this respect. Draft-sarikaya did an excellent job of
discussing time-slotted paging, but, unfortunately, as I discussed in
my response to Behcet, the entire design was predicated
on a protocol that was not yet through reqirements phase in
another working group. Something like the time-slotted
paging support in draft-sarikaya is what is needed in
the final protocol.

As a metacomment, this requirement represents exactly the
difficulty that the assesement team and the decision
team had with regard to selecting one of these drafts
as the basis for further work. Each draft had particular
aspects of it that were well thought out and recommended
themselves for inclusion in the final result, but none of
the drafts exhibited the maturity of implementation
and design that immediately suggested it as
the only possible candidate for selection, and some drafts had
particular aspects that mitigated strongly against
selection.

>    |    4.7     |            |             |             |
|
>    |Independence|            |             |  1       4  |
|
>    | of Mobility|    4       |     3       |             |     4
|
>    | Protocols  |            |             |             |
|
>
|------------|------------|-------------|-------------|------------|
>
>    (snip)

In this case, draft-renker was viewed as having overspecified the
requirement.
Overspecification is not necessarily negative, since getting it to
match the requirements means that things only need to be taken out, and
that may often simplify doing a final design, because the choices and
their consequences are clear, whereas, if a single choice is presented,
the consequences of the rejected choices may not be so clear. Of course,
other things being equal, a design that exactly meets the requirements
and exhibits the kind of maturity of design and implementation
mentioned above is preferable.

>
>    |    4.12    |            |             |             |
|
>    | Orthogonal-|            |             |  4       4  |
|
>    | ity of PA  |     4      |     1       |             |     2
|
>    | and subnets|            |             |             |
|
>
|------------|------------|-------------|-------------|------------|
>
>    (snip)
>

The justification for the classification given to draft-renker
on Requirement 4.12, the orthogonality of PA subnets (pg. 8 of the
assessment draft)
indicated to me that the rating of 1 was unfair. The justification has
to
do with an obscure use of the TMSI for paging. Perhaps this was a typo
or
something the assessment team overlooked in the process
of performing the normalization. As the diagram on pg. 13 of
draft-renker
clearly shows, the protocol is designed to support mapping of
multiple subnets to a paging area, which is controlled by the paging
agent.
This is in contrast to draft-ohba, where support for multiple
subnets was only briefly mentioned, almost as an afterthought.
At worst, draft-renker rates a very strong 2 on this requirement.

>
> > Would you find it satisfactory if, as Jari suggested, some text
> > is inserted into the assessment draft explaining how the final
> > decision was made?
> >
> >             jak
>
> Yes.
>

I will attempt to come up with some text that describes
the decision phase.

            jak



_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby