> > > Some of the key issues to keep in mind here are: > > > > > > 1) Is the logical link point-to-point, or is it shared among > multiple > > > devices of the same subscriber, or is it shared among multiple > > > subscribers? > > > Requirement IPAuth-18 and WT-146 implies that all three are legal > > > models. > > > > According to my understanding, the architecture is intended to be > capable > > of > > identifying the data traffic of an authenticated client, and enforcing > a > > policy on it. This relies on network element placement, of course. > > I don't see how your response above is relevant to issue #1, which is > the link model.
I think there are a number of different models supported by the architecture. I was trying to answer your question based on how it may relate to access authentication. I'll let a more DSL-clueful person explain us the link model(s). > > > 2) Is the problem about authenticating access to the local link, or > > > about authenticating access to the network behind the L3 edge > device? > > > > I think it is both. > > If it is both, and the link is capable of carrying non-IP traffic (like > Ethernet is), then a L3 solution would be particularly inappropriate. WT-146 provided by DSLF is all about "IP sessions." So, I presume non-IP traffic is out of scope. Alper > > -Dave > > > I'm not aware of a case where clients are authorized > > to > > send/receive IP traffic with the others connected to the same > DSLAM/BRAS, > > but not with the ones on the Internet. > > > > Alper > > > > > > > > > There's no significant difference in the point-to-point link case, > but > > > in the other two models, the difference becomes very significant. > So > > > for example, for subscriber-to-subscriber communication where > > > subscribers are on the same shared media, do you care about > restricting > > > access between them? If so, then L3 is the wrong place to solve the > > > problem, and the whole notion of IP Sessions is suspect for this > > > particular problem. Indeed, the requirement would be for a > > > network-layer-protocol-independent solution. Basically you would > want a > > > mechanism which is L2-independent as well as L3-independent. > > > > > > 3) Since power management is an important issue for many hosts, and > > > there can be (per WT-146) hosts on the link, it is important to not > > > constantly ping hosts with packets that can result in the host > coming > > > out of a low power state, as this can drastically increase the power > > > costs (either in electric bill, or battery life) to consumers. > Hence > > > page 17 of WT-146 can be scary to many people. > > > > > > -Dave > > > > > > > -----Original Message----- > > > > From: Jari Arkko [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, July 24, 2007 2:35 PM > > > > To: Internet Area > > > > Cc: Dhc Chairs > > > > Subject: [Int-area] DSL forum liaison statement on subscriber > > > > authentication > > > > > > > > This relates to the earlier discussion on using DHCP or something > > > > else for subscriber authentication and/or network access control. > > > > > > > > We have received a liaison statement from the DSL forum. > > > > Please see > > > > > > > > https://datatracker.ietf.org/documents/LIAISON/file457.doc > > > > https://datatracker.ietf.org/documents/LIAISON/file458.doc > > > > http://www.dslforum.org/techwork/tr/TR-101.pdf > > > > http://www.arkko.com/ietf/intarea/dsl2006.887.03.doc > > > > > > > > Comments on these requirements and potential approaches > > > > to satisfying them would be appreciated. > > > > > > > > Jari > > > > > > > > P.S. The last two items have been missed in the IETF liaison > > > > site; I'm working to get them up there. > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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
