Subject: [Seamoby] Paging Protocol Decision Description

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Jan 2002 11:53:11 -0800

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 16 Jan 2002 14:37:25 -0600

James,
 Following comments:
1. This text is not consistent with the minutes and the slides on which 
your presentation was based at WG meeting in IETF 52.
2. Regarding newly introduced comments on draft-guri, how come an aspect 
that is good to have in the final draft becomes the reason for rejection 
to select it?
  Since you made no comments on draft-guri at SLC I could not raise this 
question there, sorry about that :)
3. The comments on hmipv6 belong to you personally, please check the 
slides on WG document status of MIP WG, you should be able to see the 
official opinion of WG chairs of MIP WG. I think that it is a serious 
problem to state strong opinions on the business of other WGs especially 
if they are flawed.
 
4. The text does not mention the simple sum of the marks given to each 
draft?

  In short this text adds to the controversy failing to resolve 
anything.Regardless of what people say the conclusion is not going to 
change, right? Then why ask opinion of WG members? Is this normal? I do 
not think such a system can be maintained.

Regards,

--behcet

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Jan 2002 13:40:21 -0800

Behcet,

> your presentation was based at WG meeting in IETF 52.

The text I posted was my recollection, confirmed by Pat and
Allison, about the process we went through to make the decision.
There was a lot more detail than in my slides, because I wanted
to make sure that the authors of the proposals that were not
selected understood the decision process thoroughly. To the extent
that material from the slides was covered, I believe it is consistent.
For
example, the last paragraph cites a few examples of good
features in the various drafts that we would like to see in
the final result.Of those, only the security features from
draft-ohba were not on the slides, and that was an oversight
on my part, for which I apologize.

> question there, sorry about that :)

As I have told you before on this list, and as was stated in the
text I posted, draft-guri deals only with supporting L2 paging.
This is too limited to be the basis for the Seamoby IP paging protocol.
The text states that we want to see the ideas in draft-guri incorporated
into the final Seamoby protocol, and, as I have also told you before
on this list, we are working on
trying to organize a L2 Triggers BOF in Minneapolis so we can
discuss the kind of L2 triggers that are discussed on page 6 of
draft-guri. Seamoby is not the right place for this kind of work,
but we are trying to get one set up, and the L2 triggers work
for paging in draft-guri could be an important contribution. If, of
course,
you decide to participate.

> problem to state strong opinions on the business of other WGs
especially

I don't understand this comment. There is currently a draft,
draft-ietf-mobileip-lmm-requirements-00.txt, in the MIP
WG that outline requirements for an LMM solution. This
draft has not yet gone through WG Last Call, nor through
IETF Last Call, and so it does not yet have an RFC number.
That means that LMM is not yet out of the requirements phase.
This is what I said. We can't base the Seamoby paging
protocol on a protocol in another WG that isn't yet out
of requirements phase. The other WG might go through
the same kind of requirements assessment process for
competing protocols we've gone through
and come up with another protocol instead of HMIPv6
as the selected LMM protocol. Where would that leave
us?

> 4. The text does not mention the simple sum of the marks given to each

A simple sum shows nothing. How should one rate under- versus
over-specification? In some cases, underspecification can be
a good thing, in other cases not. Same with overspecification.

In retrospect, I see now that putting numbers on these was a mistake.
It led people to believe that one could simply sum the numbers
and come up with a decision. Unfortunately, it was not so easy.
You can be assured that I will never use that technique again.

> not think such a system can be maintained.

Any such decision is always subject to WG concensus.
Unfortunately, the only voice we are hearing on the mailing list
right now is yours. One voice isn't enough for concensus, nor
is text from a private email forwarded and posted apparently without the
author's permission. Goodness knows, we have enough vocal
people on this list. It took us a year to get CT requirements
done (and we still don't have them in IESG Last Call!) because
everybody had an opinion. If I were seeing some of these people, who
were not authors of competing proposals coming forward and
saying that we should change the decison, it would be another
matter.

                    jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 16 Jan 2002 18:12:19 -0600

Several people not authors of proposals (Vijay, Rene) voiced their 
concern on the murky assessment, or am I wrong, or are you waiting for  
the sky to fall down?

To be on the positive side, we can offer Majordomo based mailing list 
support for the design team, if only with no WG draft.

Take it or leave it.

-- 
Behcet

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Jan 2002 16:45:48 -0800

Behcet,

> concern on the murky assessment, or am I wrong, or are you waiting for

The text I've posted was intended to clarify how the decision
was made. If there are any further concerns expressed, then
we can discuss them.

> support for the design team, if only with no WG draft.

Thanx for the offer, but I believe we will stick with current WG
draft.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Jan 2002 11:08:15 -0800

Behcet,

You are quoting me out of context.... my comment was not about
the protocol assessment.

Vijay

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 17 Jan 2002 14:26:38 -0600

Vijay,
  Really? Let me copy your email you sent on Jan. 14 :

>Hi Jim,
>
>just one comment.
>
>James Kempf wrote:
>
>>> 
>>>  Behcet,
>>> 
>>> Up until now, the only people who have expressed
>>> an opinion about the paging protocol decision were authors of protocols
>>> that
>>> were not selected. One could, quite frankly, view this as "sour grapes"
>>> on their part for not having been selected. However,
>>
>
>People spend a lot of their time to come up with proposals.
>and they also hope that their proposal goes somewhere in the
>WG. and when the protocol assessment turns out to be murky
>and they complain, I dont think it is right to call them 
>"sour grapes".
>
>Vijay
>
Was this not Vijay Devarapalli? If  not then my apologies.

-- 
Behcet

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Jan 2002 13:50:21 -0800

it doesnt matter now. James Kempf has started a separate thread.
I guess opinions sent on that thread alone will count.

Vijay