Subject: RE: [Seamoby] Paging Protocol Decision Description

From: "Pat R. Calhoun" <[email-masked]>
Date: Thu, 17 Jan 2002 09:24:22 -0800

IMHO numbers are irrelevant. What counts here is whether the protocol
matches up against the requirements. We picked the one that was the
closest, based on the input from the assessment team.
 
PatC

- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]] 
Sent: Thursday, January 17, 2002 9:21 AM
To: Pat R. Calhoun; 'Cedric Westphal'
Cc: 'Behcet Sarikaya'; [email-masked]
Subject: RE: [Seamoby] Paging Protocol Decision Description

I don't want to take sides here since I'm not following 
the paging proposals and do not have an opinion on 
proposal X vs proposal Y, but really why are you having a numbering 
system if you're not going to follow it ???? 
What's the point of these numbers anyway if they are
(obviously) based on different criteria from those that 
the 'winning' protocol is assessed on ?
 
Seems very strange. 
 
Hesham

---

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

I hope I am not offending anyone, personally I don't care about paging, with
that
said:
I agree with Cedric here, In a true democracy, you count what inside the 
ballot box, and don't assume that the rest of the population that did not
vote (excuse the word) is in either side's favor. 
If a consensus is to take place, it should be announced and then the result
should be based on on whoever voices his opinion, not based on the silent 
audience.
 
I am just trying to learn something from of all this, for other work items 
 
Madjid

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:45 AM
To: Pat R. Calhoun
Cc: 'Behcet Sarikaya'; [email-masked]
Subject: Re: [Seamoby] Paging Protocol Decision Description

Pat,

Pat R. Calhoun wrote:

Behcet,

The process, to which I provided you a pointer a few days ago,
clearly states that folks express their opinion on the list. Jim and
I will not read other mailing list archives to determine roush
consensus. The seamoby list is the only one we can use to gauge
consensus.

Again, as Jim clearly stated, the only objection we are seeing right
now is yours (although you claim two other people did, and 3 is still
short of rough consensus for a list that has 499 members). If we
guaged there was rough consensus on this issue, then we would most
certainly act.

First, I have not followed the debate. However, I find unacceptable
that you would tell Behcet not to voice his opinion because he is the
only one doing so. How do you get
to the conclusion that the roughly 495 who are not participating in this
debate agree with you (and not Behcet) just because they shut up?
Can you point to one debate where the rough consensus was reached
by way of more than 250 favorable opinions? I have seen proposals on
this list (say car discovery reqs, for instance) decided by 2 people in
favor,
one against. For any outcome here to make sense, shouldn't the definition
of rough consensus be consistent?

Cedric.

Our primary concern at this time is to get the work completed and
achieve our milestones. So how about we get to work and put this
behind us.

PatC

- -----Original Message-----
From: Behcet Sarikaya [  <mailto:[email-masked]>
mailto:[email-masked] ] 
Sent: Wednesday, January 16, 2002 4:12 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Seamoby] Paging Protocol Decision Description

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.

James Kempf wrote:

>
>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
>

- -- 
Behcet 

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

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <  <http://www.pgp.com>
http://www.pgp.com >

iQA/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr
5WxMNRzg0Qv02oder+oZzLGR
=GIVv
-----END PGP SIGNATURE-----

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 17 Jan 2002 16:12:42 -0600

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:[email-masked]]
Sent: Thursday, January 17, 2002 3:21 PM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
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" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; <[email-masked]>
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
>
> 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.
>
>
>
>
>
>
>
> [email-masked]

[email-masked]

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Thu, 17 Jan 2002 14:16:52 -0800

>>>  by way of more than 250 favorable opinions?
>>Hmmm.. Perhaps you misread my statement. Read above.
>
>I did push your statement to the extreme. The point was consensus
>does not go by absolute numbers, but relative numbers of for and
>against, especially since on any topic, the very vast majority never
>says a thing. 

Correct - and I am still waiting for others to express their view

PatC

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 18 Jan 2002 10:36:05 +0100

> the requirement of not being dependent on a specific

=> 'considerations' should be part of the requirements. 
Not withstanding that, to go by your comments about the 
process (being murky), I think it seems reasonable 
to reconsider the outcome. Especially since (at least 
it seems to me) that the clarifications for the basis of 
selection have significantly 'expanded' since the meeting
in SLC. 

So maybe the decision needs some revisiting, at least
for reassurances, if nothing else. 
There seems to be some concern from several people.

Hesham

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 18 Jan 2002 09:56:25 -0600

I agree with Heshams, going forward with this and all
future "selections", it is better to have a clear selection 
process even before submissions. Rules should not be expanded
or contracted during the selection process.

Madjid

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Friday, January 18, 2002 3:36 AM
To: 'James Kempf'; Nakhjiri Madjid-MNAKHJI1; [email-masked]
Subject: RE: [Seamoby] Paging Protocol Decision Description

Hesham