Subject: RE: [Pana] IESG Review of protocol and framework documents

From: "Alper Yegin" <[email-masked]>
Date: Sun, 24 Jun 2007 10:26:08 +0300

Hi Dan,

                                                RADIUS,
                                                Diameter,
          +-----+       PANA        +-----+     LDAP, API, etc. +-----+
          | PaC |<----------------->| PAA |<------------------->| AS  |
          +-----+                   +-----+                     +-----+
             ^                         ^
             |                         |
             |         +-----+         |
     IKE,    +-------->| EP  |<--------+ SNMP, API, etc.
     4-way handshake,  +-----+
     etc.                 .
                          .
                          .
                          v
                     Data traffic

According to our framework, as illustrated above, PANA is part of a larger
picture that includes other protocols running between various entities.

While the core protocol work of PANA WG is running between PaC and PAA, we
are also showing protocols between PAA-to-AS, PAA-to-EP, and PaC-to-EP.

The PaC-to-EP protocol is very much access technology specific. E.g., PKMv2
in WiMAX, 802.1X 4-way handshake in WiFi, etc. We list them informatively.

The PAA-to-EP protocol is also architecture specific. WiMAX uses R6, some
WiFis uses CAPWAP, some ADSL would be using ANCP, etc.

I think what we can do is, like we did for the PaC-to-EP protocols, we can
informatively list the protocols (excluding SNMP) that are used for the
PAA-to-EP leg.

Alper

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Sunday, June 24, 2007 8:57 AM
> To: Alper Yegin; Mark Townsley
> Cc: Jari Arkko; [email-masked]
> Subject: RE: [Pana] IESG Review of protocol and framework documents
> 
> > And Dan, would that (removing pana-snmp references from our
> > documents) an acceptable resolution to your Discuss comment?
> >
> 
> Do you mean removing the references to draft-ietf-pana-snmp, or removing
> any reference to using SNMP as the protocol for an authenticator to
> enforcement point when the two are separated?
> 
> If you eliminate the reference but still mention SNMP as an optional
> solution for PAA-to-EP communication you would need to add some more
> information (even high level) about how this is supposed to work (I
> could not understand this in the absence of the now Dead draft). You
> must show in Section 2 of draft-ietf-pana-framework and in Section 11.6
> in draft-ietf-pana-pana what kind of SNMP entities (agents, managers)
> need to be implemented and how these are mapped in the PANA entities (in
> the server for PANA, in per-packet access control entities) when these
> are separated.
> 
> If you completely eliminate SNMP you are left with answering the
> question of what will be the PAA-to-EP communication protocol.
> 
> Dan
> 
> 
> 
> > -----Original Message-----
> > From: Alper Yegin [mailto:[email-masked]]
> > Sent: Sunday, June 24, 2007 1:32 AM
> > To: 'Mark Townsley'; Romascanu, Dan (Dan)
> > Cc: 'Jari Arkko'; [email-masked]
> > Subject: RE: [Pana] IESG Review of protocol and framework documents
> >
> > Hello Mark and Dan,
> >
> > > Dan is asking about SNMP. I understand that we have gone in circles
> > > with respect to whether SNMP is required to be implemented
> > or not, and
> > > it looks like the result was confusing to Dan. We either need to
> > > revive the SNMP document, or kill it off completely in the
> > WG and in these specs.
> >
> > The WG was originally scoped to work only on the PaC-to-PAA
> > protocol (PANA).
> > Later the WG was asked by our previous AD to also define at
> > least one protocol for the PAA-to-EP leg. We ended up
> > embarking on that work to define a complete picture.
> >
> > Irrespective of the EAP peer (e.g., PaC) to authenticator
> > (e.g., PAA) protocol (e.g., PANA, PKMv2, IEEE 802.1X, HRPD),
> > there is need for an authenticator to enforcement point
> > protocol when the two are separated.
> > Today there are numerous protocols used for that (e.g., R6 in
> > WiMAX, CAPWAP in WiFi, Rp in 3GPP2, and IETF's upcoming ANCP
> > in DSL). Defining an architecture-neutral protocol is a good
> > task, but I'd say it's better scoped as a work item for a separate WG.
> >
> > For that reason, I'm leaning towards putting that work aside
> > for PANA WG. If and when IETF decides to tackle generic
> > authenticator to enforcement point protocol,
> > draft-ietf-pana-snmp can be a useful starting point.
> >
> > Let's see if there is any objection from the WG.
> >
> > And Dan, would that (removing pana-snmp references from our
> > documents) an acceptable resolution to your Discuss comment?
> >
> > Regards,
> >
> > Alper
> >

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 24 Jun 2007 16:55:26 +0300

Thank you Dan.

Alper

> Sent: Sunday, June 24, 2007 11:46 AM
> Hi Alper,
> Thanks, this makes sense to me now.
> 
> If what is left in the two documents is either no mention of SNMP or
> mentioning something on the lines of 'SNMP was considered as a possible
> solution for PAA-to-EP communication which may be subject to future
> work' - this would allow me clear the DISCUSS.
> 
> Dan
> 
> 
> 
> 
> 
> > Sent: Sunday, June 24, 2007 10:26 AM
> > To: Romascanu, Dan (Dan); 'Mark Townsley'
> >           +-----+                   +-----+
> >   +-----+
> > According to our framework, as illustrated above, PANA is
> > part of a larger picture that includes other protocols
> > running between various entities.
> >
> > While the core protocol work of PANA WG is running between
> > PaC and PAA, we are also showing protocols between PAA-to-AS,
> > PAA-to-EP, and PaC-to-EP.
> >
> > The PaC-to-EP protocol is very much access technology
> > specific. E.g., PKMv2 in WiMAX, 802.1X 4-way handshake in
> > WiFi, etc. We list them informatively.
> >
> > The PAA-to-EP protocol is also architecture specific. WiMAX
> > uses R6, some WiFis uses CAPWAP, some ADSL would be using ANCP, etc.
> >
> > I think what we can do is, like we did for the PaC-to-EP
> > protocols, we can informatively list the protocols (excluding
> > SNMP) that are used for the PAA-to-EP leg.
> >
> >
> > Alper
> >
> > > Do you mean removing the references to draft-ietf-pana-snmp, or
> > > removing any reference to using SNMP as the protocol for an
> > > authenticator to enforcement point when the two are separated?
> > >
> > > must show in Section 2 of draft-ietf-pana-framework and in Section
> > > 11.6 in draft-ietf-pana-pana what kind of SNMP entities (agents,
> > > managers) need to be implemented and how these are mapped
> > in the PANA
> > > entities (in the server for PANA, in per-packet access control
> > > entities) when these are separated.
> > >
> > > > > Dan is asking about SNMP. I understand that we have gone in
> > > > > circles with respect to whether SNMP is required to be
> > implemented
> > > > or not, and
> > > > The WG was originally scoped to work only on the
> > PaC-to-PAA protocol
> > > > (PANA).
> > > > Later the WG was asked by our previous AD to also define at least
> > > > one protocol for the PAA-to-EP leg. We ended up embarking on that
> > > > work to define a complete picture.
> > > >
> > > > Irrespective of the EAP peer (e.g., PaC) to authenticator (e.g.,
> > > > PAA) protocol (e.g., PANA, PKMv2, IEEE 802.1X, HRPD),
> > there is need
> > > > for an authenticator to enforcement point protocol when
> > the two are
> > > > separated.
> > > > Today there are numerous protocols used for that (e.g.,
> > R6 in WiMAX,
> > > > CAPWAP in WiFi, Rp in 3GPP2, and IETF's upcoming ANCP in DSL).
> > > > Defining an architecture-neutral protocol is a good task, but I'd
> > > > say it's better scoped as a work item for a separate WG.
> > > >
> > > > For that reason, I'm leaning towards putting that work aside for
> > > > PANA WG. If and when IETF decides to tackle generic
> > authenticator to
> > > > enforcement point protocol, draft-ietf-pana-snmp can be a useful
> > > > starting point.
> > > >