Ralph, This is quite confusing.
In their latest liaison letter, DSLF says they "are aware that discussion is still ongoing" based on their requirements. Last time they contacted us, they left us with the requirements. And that's where IETF has been. The latest liaison letter also says "seriously consider adopting". So, it is not like they decided to use that thing. Would they still want to pursue it even after so many people said it is a bad idea? I'm sure the DSLF would appreciate the feedback and would be willing to reconsider it. Besides, that's the spirit of the thread Jari started. This is not a 'how we merge the two documents and make an RFC out of it' discussion. Alper > -----Original Message----- > From: Ralph Droms [mailto:[EMAIL PROTECTED] > Sent: Friday, October 19, 2007 4:27 PM > To: Alper Yegin > Cc: Internet Area > Subject: Re: [Int-area] DCHP-based authentication for DSL? > > Alper - It looks like the DSLF requirements have evolved over time. > The initial DSLF liaison statements (May, 2007), sent to both the > IETF and the IEEE, request a solution to subscriber authentication > without specifying a particular solution technology. The > requirements in "Subscriber Authentication in DSL Networks" don't > mention the use of any specific IETF or IEEE protocols: > > Subscriber Authentication in DSL Networks > https://datatracker.ietf.org/documents/LIAISON/file457.doc > > DSL Forum Liaison to IETF Internet Area about WT146 > https://datatracker.ietf.org/documents/LIAISON/file458.doc > > The more recent DSLF liaison statement (August, 2007), sent to the > IETF, is more specific, asking the IETF to adopt a document merging > the mechanisms in draft-pruss-dhcp-auth-dsl-01.txt or draft-zhao-dhc- > user-authentication-02 as a work item; note the title explicitly > calls out DHCP: > > DSL Subscriber Authentication using DHCP > https://datatracker.ietf.org/documents/LIAISON/file490.doc > > Therefore, it seems that now the DSLF is looking for a DHCP-based > solution, based on the as yet unpublished document derived from the > two I-Ds cited above. > > - Ralph > > > On Oct 19, 2007, at Oct 19, 2007,4:31 AM, Alper Yegin wrote: > > > Ric, > > > > We are not saying DSLF MUST use PANA. But if DSLF is coming to IETF > > with the > > requirements it did and seeking a L3-based access authentication > > protocol, > > IETF has designed PANA exactly for that. > > > > If DSLF is satisfied with a 802.1X extension and IEEE is delivering > > that, so > > be it. There is nothing wrong with that. > > > > There does not appear to be a strong justification to hack DHCP the > > way you > > are proposing. Many people spoke against that already. > > > > Based on a cost/benefit analysis, doing that to DHCP may be > > justified for a > > DSL product line group, I'd understand. But not for the IETF, imo. > > > > > > Alper > > > >> -----Original Message----- > >> From: Richard Pruss [mailto:[EMAIL PROTECTED] > >> Sent: Friday, October 19, 2007 6:01 AM > >> To: Yoshihiro Ohba > >> Cc: Internet Area > >> Subject: Re: [Int-area] DCHP-based authentication for DSL? > >> > >> > >> > >> Yoshihiro Ohba wrote, around 19/10/07 11:39 AM: > >>> Option 82 makes no difference if option 82 is also > >>> inserted in PANA message. DHCP state transisions (excluding > >>> those for > >>> EAP state transitions) before completion of authentication makes no > >>> diffirence. The only difference would be DHCP state transitions > >>> after > >>> successful authentication in PANA, but I don't really think this > >>> is a > >>> big deal that can justify significant change to DHCP. > >>> > >>> > >> You still arguing PANA? The difference is that DHCP snooping and > >> Option > >> 82 insertion is implemented. > >> Running code, get it? DHCP snooping and Option 82 insertion is > >> implemented and deployed worldwide, working for millions of > >> subscribers... > >> > >> If the DSLForum is going to try recommend the huge cost to do > >> something > >> that changes every device in the Ethernet layer I suspect they > >> probably > >> will take something from IEEE, > >> that fixes MAC security and takes something like 802.1x but that > >> traverses client side and provider switches. Not PANA. > >> > >> DHCP Authentication is a small change to the existing deployment that > >> has Port as credentials for Option 82 and simply adds the ability to > >> have client supplied credentials but > >> otherwise uses the same architecture that is deployed today for > >> Option > >> 82 driven Ethernet DSLAMs and the upstream terminating BRASes. > >> > >> - Ric > >> > >>> Yoshihiro Ohba > >>> > >>> > >> > >> > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www1.ietf.org/mailman/listinfo/int-area > > > > > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
