Alper, I am sorry that you are not getting this but I believe that
adding software to PC's are specifically out of scope. Any SP who has
deployed something like PPPoE clients onto an end-users PC have an
allergic reaction to adding things to customer PC's. From that point on
the customer counts you as responsible for every thing that happens to
that PC.
I see this attitude in the requirement:
IPAuth-1 Authentication must not depend on the use of any given
application, eg web browser.
These requirements will not stand up to a bunch of lawyering, they were
a living list copied down during the course of debates in the DSLForum.
You need to read them with some common sense and understanding of DSL
networks and deployments.
The draft caters for devices on the home network like a set-top box or
other service device to participate in authentication.
- Ric
Alper Yegin wrote, around 2/12/07 8:15 AM:
Your latest I-D says:
Further, **different devices in the home** may have different policies
and require different credentials.
and
The DHCP Client resides either on a **home network device** or the
HGW, and the DHCP Server protocol state machine may reside fully on
the NAS.
Obviously neither the DSLF requirements nor your I-D mean to leave PCs at
home out of scope.
Alper
-----Original Message-----
From: Richard Pruss [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 22, 2007 10:41 PM
To: Alper Yegin
Cc: 'Yoshihiro Ohba'; [EMAIL PROTECTED]
Subject: Re: [Int-area] Combined draft on DHCP authentication
Alper possibly this has been the problem with this thread. You simply
do not understand that half the complexity in the DSL deployment is the
Layer 2 parts of TR-101.
- Ric
Alper Yegin wrote, around 22/11/07 7:16 PM:
There is no point in getting lost in the TR-101 text.
You said to look at the requirements, so we did it.
It reads in plain English:
Should be simple to implement on client (PC or CPE)
Unless PC is not "PC", there is no point in arguing....
-----Original Message-----
From: Richard Pruss [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 22, 2007 10:53 AM
To: Yoshihiro Ohba
Cc: Alper Yegin; [EMAIL PROTECTED]
Subject: Re: [Int-area] Combined draft on DHCP authentication
Yoshihiro Ohba wrote, around 22/11/07 2:59 PM:
Section 2 of TR-101 says:
"The principle guiding this specification work is that the resulting
functions should enable an as smooth as possible migration process
from an ATM based aggregation network to an Ethernet based aggregation
network."
Terminal originated PPPoE is mentioned also in TR-101 (e.g., Figure
15).
>From customer's point of view, it would be natural to think that a
*smooth* migration path includes support for existing PPPoE terminals
to be able to migrate to Ethernet based aggregation network without
necessarily upgrading their legacy CPEs to RGs.
In this thread, when the discussion comes to end-host support, I
always see inconsistency between what is stated in the DSLF
requirements (and TR-101) and what is stated by proponents of DHCP
authentication. If IPAuth-8 and IPAuth-9 are not really requirements,
why not re-send revised requirements officially from DSLF to IETF?
Unless requirements are revised, I don't think we can make a progress.
I am sorry I do not see the inconstancy, the requirements make perfect
sense if you understand that the TR's have multiple deployment models
in
them.
TR-101 is about moving from an ATM uplink for DSLAMs (access nodes) and
TR-101 mandated no changes to the CPE or RG's. WT-148 which we are
working on now is not TR-101 and while all involved want the minimum
changes it is well understood that we cannot remove PPPoA and PPPoE
from
the system without changing the CPE.
The system must provide a model for supporting PC's with no change to
the software of the PC is provided in TR-101 and it does not involve a
credential exchange. This system must continue to work in the new
proposal and the DHCP Authentication draft has a section on handling
clients that do not support the authentication mechanism.
Regards,
Ric
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
