Subject: RE: [Seamoby] Paging Protocol Decision Description

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 17 Jan 2002 13:48:43 -0600

James,

I have an issue with this process. 
You said that one of the drafts was rejected because it had
a dependency on a document that is under assessment in Mobile IP.

I guess this is new, on one hand we are saying that are
protocols needs to be interoperable, on the other hand we are
dismissing solutions that have interdependency:
This means that we need to wait for the solutions in other groups to 
become RFCs and then try to work them into our proposals? Aren't we
introducing a significant dead time here?

Can we set up or debate what the rules are here?

Thanks,

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 1:53 PM
To: [email-masked]
Subject: [Seamoby] Paging Protocol Decision Description

As promised, here is a description of the decision process used to
select the Seamoby paging protocol. After discussion and
editing based on WG feedback, this will be incorporated into
draft-ietf-seamoby-paging-protocol-assessment-00.txt.

Comments please.

            jak

------------------------------------------------------------------------
------------------------------------------
Assessment and Decision Process

The assessment team spent three weeks reading through the protocol
proposals.
Each team member was assigned a proposal for assessment, with the
exception
of draft-sarikaya and draft-guri, which were both assigned to
one team member because not enough people volunteered. Each team member
wrote up the results of their assessment, and submitted it to
the assessment draft editor for assembly into this draft. A
teleconference
was held to discuss the assessments and normalize assessments between
different team members. The assessment team did not make a
recommendation
about which draft to pick; however, the team did recommend that the next
step should be to either go through another round of design in which the
authors would attempt to refine their proposals, or to immediately begin
the
process of harmonizing the protocols to come up with a working group
draft.

Given that the assessment team's recommendation about which draft to
accept
was indeterminate, a decision team was formed by the two Working Group
co-chairs, with the Area Director providing advice. The decision team
decided
to proceed toward selecting a draft as the basis of a harmonized
protocol, in
order to avoid further delay in starting on the process of desiging the
Seamoby paging protocol.

The decision about which draft to select was difficult, because each
draft
had particular aspects 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. Some drafts had particular
aspects
that mitigated strongly against selection. A good example of this
difficulty
is Requirement 4.6, Multiple Dormant Modes. This requirement was
intended to
foster support for hosts that have no explicit L2 paging support,
basically
time-slotted paging. Draft-sarikaya has an excellent discussion of
time-slotted paging mode, but the basis of that draft is a protocol
(HMIPv6)
that has been proposed in another working group for a problem that is
still
in the requirements phase. The other proposals had varying degrees
of support for time-slotted paging, but none was sufficient to recommend
itself on this particular requirement.

The assessment team's work allowed the decision team to reduce the
number of drafts under consideration from five to two. The decision team
quickly decided to rule out draft-koodli because the draft is lacking in
specifics and is vague on many requirements, as mentioned in the
assessment
team's report. Draft-sarikaya was ruled out because it is based on a
protocol
that is currently under evaluation in another working group, setting up
an
unacceptable dependency between the Seamoby paging protocol design and
the
other working group's process. Also, draft-sarikaya exclusively supports
Mobile IPv6, and a primary requirement of all Seamoby work is that the
protocols be independent of mobility protocol. While the assessment of
draft-guri was positive, draft-guri is explicitly concerned with
utilizing
Layer 2 support for paging, and was therefore not sufficiently broad
enough
as a base for IP paging. However, the ideas expressed in draft-guri were
felt
to be valuable and necessary for including in the final Seamoby paging
protocol for those cases where Layer 2 paging support is available.

The decision between the remaining two drafts, draft-renker and
draft-ohba,
was especially difficult because they were judged to be about of equal
quality. The decision team decided to focus on three primary
requirements
that were thought to be crucial to the successful acceptance of IP
paging:
independence of mobility protocol, support for existing mobility
protocols,
and independence of paging area from subnet topology.

Of these, both draft-renker and draft-ohba provided adequate support for
the first two, independence of mobility protocol and support for
existing
mobility protocols. Draft-renker was judged by the assessment team to
be overspecific in these areas, in the sense that it contained two
modes,
explicit mode and implicit mode, depending on whether Mobile IP was
supported
or not. However, considering the relatively immature state of the paging
protocol design, the decision team felt that providing the working group
with choices, where the benefits and drawbacks of each choice could be
clearly weighed, was preferable to providing a fixed decision, so
draft-renker was judged to be better in this regard.

On the requirement for independence of paging area from subnet topology,
the
support described in draft-ohba was very sketchy and did not provide
the decision team with a clear idea about how this could be achieved,
particularly with regard to the movement of a mobile host while the host
is
in dormant mode. Draft-renker has a much clearer description of how this
could
be achieved, and was judged to be better in this regard.

Additional aspects of draft-renker that recommended it as the selection
were attention to details of interaction with existing IP
routing, and a survey of paging strategies. While probably not essential
to
the final protocol design, the material on paging strategies showed
that the authors had given some thought to separating policy from
mechanism,
and were familiar with the somewhat extensive academic
literature on paging, and IP paging in particular.

While draft-renker was selected by the decision team as the basis for
continued Seamoby paging protocol work, the decision team feels that it
is
important to incorporate the outstanding contributions of the other
authors
into the final protocol design, in particular, the time-slotted paging
discussion in draft-sarikaya, the Layer 2 interface work in draft-guri,
the
paging state machine discussion in draft-koodli, and the security
protocol
work in draft-ohba. Additional aspects of the other drafts that address
issues which were weakly addressed or not addressed at all in
draft-renker
should also be incorporated, as well as ideas from other working group
members that address requirement which none of the draft addressed
particularly
well.

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

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Jan 2002 13:21:29 -0800

Majhid,

That was only one consideration. Another was that it did not meet
the requirement of not being dependent on a specific
mobility protocol.

If you have an opinion on about whether we should re-open
the selection phase, please post it under the thread I
opened this morning.

Thanx.

            jak