Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

From: [email-masked]
Date: Tue, 11 Oct 2005 13:04:23 -0500

Alex,
as for the IS we already have approved work items in the charter, therefore I would not discuss anymore whether MIPSHOP will work on 802.21 IS or not. As for ES and CS, the discussion is definitely still open. Should the WG decide to tackle also ES and CS, I do not believe that the number of work item would be unrealistic. 

As for protocol selection, there are various solutions that can be used to solve a stall. E.g. CAPWAP had a very formal protocol selection procedure that could be adopted also in MIPSHOP if the WG decides that's the way to go.

Stefano

> -----Original Message-----
> From: ext Alexandru Petrescu [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2005 11:57
> To: NJEDJOU Eric RD-RESA-REN
> Cc: Faccin Stefano (Nokia-NRC/Dallas); [email-masked]
> Subject: Re: [Mipshop] ES and CS within the MIPSHOP charter
> 
> 
> NJEDJOU Eric RD-RESA-REN wrote:
> > Stephano, This is exact. Not only the charter should include that 
> > (looks like the overall Working Group objective does) but also the 
> > scope description. That description appears as considering MIES and 
> > MICS as "may be adressed items" only where those could 
> appear as "to 
> > be solved" items for some actors use.
> 
> The actors interested in 802.21 should probably re-BoF.
> 
> Doing CS and ES in addition to IS is additional work, not to mention
> CARD, NED, network-controlled handovers, and the security of them all.
> These are enough work for a full-size WG, not just partial work in the
> mipshop WG, provided that the BoF proponents could converge on
> least-common denominators, as individuals.
> 
> If 802.21 can't decide between CARD and NED then probably IETF *could*
> help figure out a common CARNED way.
> 
> There was a MIHEP BoF proposal prior to the Paris meeting.  
> According to
> a report, that didn't get approved because not enough discussion.  I
> think the situation has changed.  So BoF again would make sense.
> 
> Alex
> 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Oct 2005 22:51:09 +0200

[email-masked] wrote:
> Alex, as for the IS we already have approved work items in the 
> charter, therefore I would not discuss anymore whether MIPSHOP will 
> work on 802.21 IS or not.

Ok.

> As for ES and CS, the discussion is definitely still open. Should the
>  WG decide to tackle also ES and CS, I do not believe that the number
>  of work item would be unrealistic.

For each work item there is a number of authors, but there should also
be a number of reviewers ready to read deep through the document.
Additionally, knowing that IS is targetting PS (Proposed Standard) there
should exist some inter-operable implementation experience prior to
going to IESG.  That is two different implementations (even if only
prototypical), it's good to have.

Is the thinking that this could be achieved for IS, ES and CS prior
to IESG July 2006.

That's what I meant being maybe too much work.

> As for protocol selection, there are various solutions that can be 
> used to solve a stall. E.g. CAPWAP had a very formal protocol 
> selection procedure that could be adopted also in MIPSHOP if the WG 
> decides that's the way to go.

On this topic - yes I mainly agree with you, there exist ways to converge.

Usually the goal of doing protocol selection is to get people to talk to
each other, not necessarily to select a 'winner' solution.  Sometimes
these selection steps end up in a DT being formed with people from all
camps.  Sometimes these DTs are too big, sometimes just right.
Sometimes they deliver other times they don't.

Assuming that a certain protocol is best is a wrong approach at IETF, IMHO.

Fully exercising some power of responsibility one may have at IETF
('muscle flexing') indicates there's something urgent somewhere, and
probably something wrong too.

That said, may ask again - why not BoF?

The only reasons I could see are:

-802.21 is in deep need of something from IETF.  BoF may take too long
 for that something to be delivered.
-the answers for "why not BoF" already exist and I've missed some
 decisions prior to Paris.
-mipshop urgently needs 802.21 WG items.

Which of those reasons is truer?

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Oct 2005 14:39:56 -0700

Alex,

CAPWAP did, in fact, pick winners and losers. Sometimes, this is 
unavoidable, especially when the various proposals involve very different 
architectural approaches. This was partially the case in CAPWAP. In 
addition, there were competing commercial interests there, something which I 
don't think we really have in MIPSHOP (nobody's business plan depends on 
which protocol is selected for IS).

Personally, I am very much in favor of design teams and collaborative work 
when there are competing proposals, since this seems to me to be more in the 
spirit of IETF, and I've had most success with that in the past. But in the 
current case, the evidence from list traffic seems more to favor a protocol 
competition, in which one protocol is selected, perhaps with modifications 
(as was the case in CAPWAP). One reason is because the two currrently 
competing proposals have very different architectural approaches. The other 
is due to the tone of the interaction from the CARD side which, in my 
opinion, has been quite competitive and not particularly conducive to 
collaborative work. Of course, it is possible that once we see the actual 
802.21 requirements, we'll see some additional proposals, possibly with yet 
different architectural approaches.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Sent: Tuesday, October 11, 2005 1:51 PM
Subject: Re: [Mipshop] ES and CS within the MIPSHOP charter

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Oct 2005 00:53:13 +0200

James Kempf wrote:
> unavoidable, especially when the various proposals involve very 
> different architectural approaches. This was partially the case in 
> CAPWAP.

James, thanks for pointing to that, and for the description - good to
know.  So I went on and skimmed through draft-ietf-capwap-eval-00.txt.
It's interesting to see the four Member Statements in the Evaluation
Team similar declarations of intent of the IEEE/ACM Candidates I receive
for voting.  Where's 'rough consensus'?

Then I checked the IESG Queue for CAPWAP.  Only two INFORMATIONAL RFCs.
 And a set of personal I-Ds submitted with no intended status and not
assigned to any shepherding AD.  It's true that things may change in the
near future, since the 'winner/looser' decision is relatively recent.

But I am wondering whether 'Evaluation Team' seemingly used by CAPWAP is
a recommended practice.  RFC 2418 'IETF Working Group Guidelines and
Procedures' recommends 'Design Teams' not 'Evaluation Teams'.

Further browsing RFCs I found that 'Evaluation Teams' were used
for selecting other protocols too, e.g. RFC3127 on AAA and 3955 on
IPFIX.  RFC3127 recommended Diameter for AAA (against SNMP, Radius++ and
COPS).  Diameter is a PS RFC.  All three others are PS RFCs too, and
being updated for other than AAA purposes.

RFC3955 on IPFIX recommended NetFlow against Diameter (and others).
There's no IPFIX RFC PS yet.  The IESG Queue indicates two IPFIX
INFORMATIONAL RFCs and a protocol draft version 19, presumably based on
NetFlow, but not assigned yet.  There's however a Cisco INFORMATIONAL
RFC on NetFlow.

> Personally, I am very much in favor of design teams and collaborative
>  work when there are competing proposals, since this seems to me to
> be more in the spirit of IETF, and I've had most success with that in
> the past.

>From the standpoint of IETF I think DTs are probably more successful at
converging that ETs are.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Oct 2005 16:08:04 -0700

> From the standpoint of IETF I think DTs are probably more successful at

DTs are certainly more common. The problem is that when there is a 
fundamental architectural disagreement (as, in my opinion, this case) the DT 
can't make any more progress than the entire WG can. Either one or the other 
architecture must be chosen. Trying to split the difference results in a 
dissatisfying, "design by committee" result.

            jak

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 12 Oct 2005 00:26:47 -0700 (PDT)

It seems to me like in this particular case, and given the past history,
we'd be better off *not* trying to converge and just doing an evaluation,
declare one winner, and be done with it. I note that in addition to the
other examples, MIDCOM also did this. I've actually been thinking that
this is perhaps another item to add, but I'd rather do a quick recharter
just for the evaluation draft when (and if) it does appear to be 
necessary. 

Also, Alex you mention that having at least two interoperable implementations
is a pre-requisite before sending anything to the IESG. Someone on this list is
bound to have the facts at hand, but I was under the impression that whereas that's
true of the routing area, it is not necessarily true in the INT area. Of course,
it's good to have. Now, to progress to Draft standard, it is a requirement (rfc1264).

-gabriel

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Oct 2005 12:25:20 +0200

gabriel montenegro wrote:
> It seems to me like in this particular case, and given the past 
> history, we'd be better off *not* trying to converge and just doing 
> an evaluation, declare one winner, and be done with it. I note that 
> in addition to the other examples, MIDCOM also did this.

Right, I remember a MIDCOM meeting in Salt Lake City, heated discussion.

Browsing RFCs, the MIDCOM evaluation did not use an Evaluation
Team.  It pitted SNMP, RSIP, Megaco, Diameter and COPS.  I can't
say what was the winner exactly; but midcom WG issued STUN, a
single Standards Track RFC.

MIDCOM, IPFIX and AAA evaluations had a common candidate which is
Diameter.  Wondering whether Diameter is a candidate here.  Using
Diameter between STA and Server (MN and AR, Diameter Node and Diameter
Client) may make sense when thinking that 802.16e and 3GPP may do
something related to ppp.

> I've actually been thinking that this is perhaps another item to add,
>  but I'd rather do a quick recharter just for the evaluation draft 
> when (and if) it does appear to be necessary.

Ok.

> Also, Alex you mention that having at least two interoperable 
> implementations is a pre-requisite before sending anything to the 
> IESG. Someone on this list is bound to have the facts at hand, but I
>  was under the impression that whereas that's true of the routing 
> area, it is not necessarily true in the INT area. Of course, it's 
> good to have. Now, to progress to Draft standard, it is a requirement
>  (rfc1264).

Gabriel, I agree with that.  I was not sure how to formulate it.  I
think I wanted to say that before going to IESG it is good to have some
prototypical experiments, or some strong commitment to implement.
 Such that discussions about implementation can take place too.

Alex