RE: [Seamoby] Paging Protocol Decision Description

[Nakhjiri Madjid-MNAKHJI1 <[e-mail]>]

James,

As I said, I don't have any interest in paging right now.
obviously there has been a lot of obsanity flying around on the
list regarding paging proposals.
I just want to get the selection process straight for future
such as when we are to "select" CT or CAR proposals in the future, 
and  you still haven't answered my question (see my earlier email). 
How much interdependency can we have with work in Mobile IP
or other group?

Madjid

-----Original Message-----
From: James Kempf [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 3:21 PM
To: Nakhjiri Madjid-MNAKHJI1; [e-mail]
Subject: Re: [Seamoby] Paging Protocol Decision Description


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