Re: [Seamoby] Paging Protocol Decision Description

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

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

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <[e-mail]>
To: "'James Kempf'" <[e-mail]>; <[e-mail]>
Sent: Thursday, January 17, 2002 11:48 AM
Subject: RE: [Seamoby] Paging Protocol Decision Description


> 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:[e-mail]]
> Sent: Wednesday, January 16, 2002 1:53 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/seamoby
>


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