Subject: Re: [Int-area] DCHP-based authentication for DSL?

From: "James Kempf" <[email-masked]>
Date: Sat, 13 Oct 2007 03:00:57 -0700

Economics (==business considerations) *never* come into consideration when IETF charters new work in contrast to other sdo's. That has avantages and disadvantages. One of the disadvantages is that people can spend years working on something only to see that, sadly, people would rather deploy a cheap hack. All the money and time invested in the technology development is then wasted. I've seen this story played out over and over in IETF, it is only a matter of time before companies start to question their investment in IETF.

          jak

--------------------------
Sent from my Nokia Handheld with BlackBerry Connect

-----Original Message-----
From: Mark Townsley <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: Internet Area <[email-masked]>
Sent: Fri Oct 12 06:13:32 2007
Subject: Re: [Int-area] DCHP-based authentication for DSL?

Iljitsch van Beijnum wrote:
> On 11-okt-2007, at 22:48, Richard Pruss wrote:
>
>> That would require PANA snooping on every switch that does Option 82 
>> insertion and DHCP snooping today.
>> It would also require a suite of new features on those switches to 
>> filter at the IP layer protocol. Current switches do MAC IP matching 
>> and security features around those two on a per port basis.
>> This is where the PANA proposal breaks down as it requires every 
>> element in the network to change.
>
> I don't think this can be a serious argument against other solutions 
> that DHCP, because EVERY solution requires numerous changes. The fact 
> that adding authentication to DHCP means a little less ISP 
> infrastructure needs to change can't be a reason to reject other 
> solutions out of hand. 
I can promise you that the economic realities of the solution will most 
certainly be part of what the ISP decides to deploy.
> I also don't remember seeing this as a requirement in the list that 
> Mark posted.
One of the requirements was: "IPAuth-6    Must fit into TR-101 
operational model" - while "fit into" is rather subjective, I think the 
spirit here was that the solution shouldn't require major rework to that 
design.
> Especially because a DHCP solution would impose considerable issues on 
> the end-user side. 
Now this is getting closer to what the DSL Forum is asking us. What kind 
of issues do you envision here?

- Mark
>
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area
>

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Mark Townsley <[email-masked]>
Date: Sat, 13 Oct 2007 15:45:50 +0200

James Kempf wrote:
>
> Economics (==business considerations) *never* come into consideration 
> when IETF charters new work in contrast to other sdo's.
>
This thread was largely within the context of understanding the basis 
behind the DSL Forum requirements and conclusion, which of course is one 
of those "other" SDOs.
>
> That has avantages and disadvantages. One of the disadvantages is that 
> people can spend years working on something only to see that, sadly, 
> people would rather deploy a cheap hack. All the money and time 
> invested in the technology development is then wasted. I've seen this 
> story played out over and over in IETF, it is only a matter of time 
> before companies start to question their investment in IETF.
>
I've seen the "role of business models" in the IETF debated a number of 
times, from a number of angles. Perhaps the most important thing to 
avoid is anything which could be construed as collusion, and many SDOs 
(ironically, not the IETF) have written statements on what is and is and 
is not appropriate conduct along these lines. In any case, when it comes 
to running code, the IETF very much cares, and that is often driven by 
some aspect of "business considerations". So, even if present in our 
discussion only via this indirection, it is still a part, ultimately, of 
what we do.

- Mark

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Oct 2007 14:40:53 -0500

James,

> when IETF charters new work in contrast to other sdo's.
This is incorrect. It is true that we are not discussing business
models, prices, etc. However, it is equally true that interest
from major users and vendors is an important input when
chartering new work. Not the only input or an overriding
concern, but an an important input nevertheless.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Oct 2007 14:40:53 -0500

James,

Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Oct 2007 10:37:20 -0700

Discussion, yes, as a critera for what new work gets chartered (and 
therefore whether it has a potential for actual deployment), no.

Typically the discussion goes something like this. At the BOF, Joe Advocate 
says that XYZ SDO/industry forum which controls deployment (substitute some 
SDO/industry forum like DSL Forum, 3GPP, 3GPP2, etc.) is interested in the 
new protocol. When you talk to people in XYZ, however, you find out that 
opinion is divided. Nevertheless, the Working Group is chartered anyway, 
since the only real criteria for chartering a working group in IETF is that 
a "community of interest" exist and that the IESG and IAB are happy with the 
technical soundness of the idea. 4 years later, after much good but 
essentially useless work, the protocol is complete but nobody wants to 
deploy it  because XYZ SDO has decided to do something different, usually 
modify an existing protocol, since they do not want to deploy a new protocol 
due to economic and business considerations.

I believe IETF should not charter work on new protocols until either a) 
there is a liason letter from an SDO that can control deployment asking 
specifically for the new protocol, or b) there is an industry forum with an 
implementation asking for standardization, indicating a committement of 
resources towards implementation and deployment.

In contrast maintenace work on old protocols, including cheap hacks such as 
the current topic of discussion, should not require any such strong proof of 
support, since the amount of work to do them is typically small and 
therefore if they fail to get deployed, the resources wasted are less.

It's time for the IETF to admit that the Internet protocol suite is done and 
to go into maintenance mode, leaving new developments to the research 
community where new and really innovative ideas are much more likely to get 
traction.

                   jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, October 13, 2007 12:40 PM
Subject: Business considerations (Was: Re: [Int-area] DCHP-based 
authentication for DSL?)

James,

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Oct 2007 17:30:25 -0600

James,

> the only real criteria for chartering a working group in IETF is that
> a "community of interest" exist and that the IESG and IAB are happy
> with the technical soundness of the idea. 4 years later, after much
> good but essentially useless work, the protocol is complete but nobody
> wants to deploy it ...

FWIW, the IESG and IAB are very interested in actual deployment and
implementation plans behind that community interest. And we use this
kind of information when approving BOFs, WGs, and rechartering efforts,
every time. Obviously not always with perfect results, but it is
incorrect to say that we do not care about this aspect.

> I believe IETF should not charter work on new protocols until either
> a) there is a liason letter from an SDO that can control deployment
> asking specifically for the new protocol, or b) there is an industry
> forum with an implementation asking for standardization, indicating a
> committement of resources towards implementation and deployment.
This is not the current procedure, nor do I think it would be a very
good one. I think we are moving fast off topic for this list so I won't
go into the details (but food for thought: do the plans from others
always succeed? Who cares about the Internet technology that is not tied
to a specific access?).

Jari