Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013

[Behcet Sarikaya <[e-mail]>]

Hi Sri,

I think that Client/Server behaviour (Section 7 & 9) in the draft needs
some clarification.

Please check Bernie's mail:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg11144.html
on draft-ietf-dhc-80211-option-01.txt.

Also please check the operation described in Li's draft:
http://tools.ietf.org/html/draft-xue-dhc-location-option-01

Regards,

Behcet
On Wed, Apr 17, 2013 at 10:47 AM, Sri Gundavelli (sgundave) <
[e-mail]> wrote:

> Hi Ted,
>
> Thanks for your comments.
>
> This requirement is not coming from any SDO. We believe this is a generic
> requirement for IETF based IP architectures.
>
> As you are aware, many operators are deploying large scale SP WiFI
> networks. These deployments are based on standard IETF protocols and
> architectures (tunneling, mobility, Routing, AAA protocols ...). In many
> of these deployments the subscriber services are tied to the access
> network, for example, the initial portal page may be different based on
> the user location (SSID, AP Mac address ..). These parameters are
> typically carried on DHCP option-82, and are coded in a vendor basis.
> There is no standard encoding that a backend system can reliably depend on
> for learning these parameters. In the past when WiFI was largely contained
> to enterprises, with single vendor solutions, this worked fine. But, now
> in many deployments there are multi-vendor systems and interop is
> required. The draft is trying to attempt to fix that gap. We want to drive
> this work in DHC, not using a liaison statement, but as a gap in IETF
> protocols, to solve a practical deployment issue and improve
> interoperability.
>
> I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI
> networks and he can comment on this.
>
>
>
>
> Regards
> Sri
>
>
>
>
>
>
>
>
>
>
>
> On 4/17/13 7:59 AM, "Ted Lemon" <[e-mail]> wrote:
>
> >When we talked about this earlier, I said that it might be better to have
> >this work done in DHC rather than forcing it to find a new working group
> >because it seemed to be something that was being asked for by other SDOs.
> >  However, the authors never said anything about that over and above what
> >they've already said in meetings, so I don't actually have a clear
> >picture of who is asking for this.   Looking in the data tracker, I don't
> >find any liaison statement requesting that this work be done.
> >
> >The authors have expressed a great deal of urgency about this work, and I
> >don't want to delay it any further, so I will state that as a
> >participant, I'm in favor of the working group taking on the work.
> >However, with my AD hat on, I would like to get some kind of actual
> >request for help from the SDOs who want this functionality before the end
> >of the call for adoption.   Otherwise I think Bernie's concern that the
> >DHC working group really isn't qualified to evaluate the validity of the
> >option contents will remain unaddressed, and I think it's a valid concern.
> >
> >The request from the SDOs should be of the form "we need DHCP options to
> >deliver the following bits of functionality," and should briefly describe
> >the functionality that's needed, and refer to the documents that the SDO
> >is working on that support this need.
> >
> >If this need is not really coming from these SDOs, but rather from some
> >IETF working group, then perhaps Bernie's original observation was
> >correct, and this work should be done in that working group instead.
> >
> >_______________________________________________
> >dhcwg mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>