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
