Subject: Re: [Pana] Issue 207 (AD-review, pana-fwk, section 7.2)

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 01 Nov 2005 08:21:44 -0500

On Tue, Nov 01, 2005 at 12:07:51AM +0200, Alper Yegin wrote:
> I don't think we can mandate SNMP on any PANA implementation. A system
> that solely relies on its proprietary PAA2EP protocol cannot be forced
> to implement SNMP. I think all we can say is "SNMP [I-D.ietf-pana-snmp]
> or a proprietary protocol MAY be used ...."

I don't think the proposed text is forcing the use of SNMP.  I think
the issue is whether we call an implementation that uses a proprietary
PAA2EP protocol a complient PANA implmentation or not.  In other
words, what is needed for a PAA2EP protocol to be PANA complient?

Yoshihiro Ohba

> 
> Alper
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Yoshihiro Ohba
> > Sent: Monday, October 31, 2005 11:27 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [Pana] Issue 207 (AD-review, pana-fwk, section 7.2)
> > 
> > >7.2  Notification of PaC Presence
> > >
> > >   When PAA and EP are separated and PAA is configured to be the
> > >   initiator of the discovery and initial handshake phase of PANA, EP
> > >   has the responsibility to detect presence of a new PaC and
> notifies
> > >   the PAA(s) of the presence [RFC4058].  Such a presence
> notification
> > >   is carried in a PAA-EP protocol message [I-D.ietf-pana-snmp].
> > >
> > >
> > Again, is this always snmp? If so, why not just say that? Opening the
> > door to too many options here just complicates deployment options,
> > interoperability, etc.
> > 
> > Is the issue that, since SNMP is rarely used for sets in routers
> today,
> > that you want to leave the door open to xml or cli filter config? If
> > that is the case, please state it (or if I'm completely out of line,
> > state that as well). You can even give the background here, that
> > vendor-specific filter installation may be used as it is more commonly
> > known, though a standard method such as SNMP MUST be implemented by a
> > compliant PANA implementation.
> > 
> > 
> >   Ohba: Sure.  We can revise Section 7.2 to explain background as
> >   follows:
> > 
> >   "
> >    7.2  Notification of PaC Presence
> > 
> >       When PAA and EP are separated and PAA is configured to be the
> >       initiator of the discovery and initial handshake phase of PANA,
> >       EP has the responsibility to detect presence of a new PaC and
> >       notifies the PAA(s) of the presence [RFC4058].  Such a presence
> >       notification is carried in a PAA-EP protocol message.  A
> >       vendor-specific protocol may be used for carrying the presence
> >       notification, though a standard method such as SNMP
> >       [I-D.ietf-pana-snmp] MUST be implemented by a compliant PANA
> >       implementation.
> >   "
> > 
> >   Also to be consistent, change the following paragraph in Section 7:
> > 
> > 
> >   "
> >    When a PaC is authenticated and authorized, the PAA should notify
> >    EP(s) and ask for installing filtering rules to allow the PaC to
> send
> >    and receive data traffic.  SNMP is used between PAA and EP(s) for
> >    this purpose when these entities are not co-located [I-D.ietf-pana-
> >    snmp].
> >   "
> > 
> >   to:
> > 
> >   "
> >    When a PaC is authenticated and authorized, the PAA should notify
> >    EP(s) and ask for installing filtering rules to allow the PaC to
> >    send and receive data traffic.  A PAA-EP protocol between PAA and
> >    EP(s) is used for this purpose.  A vendor-specific protocol may be
> >    used as a PAA-EP protocol, though SNMP is used for a complient PANA
> >    implementation.
> >   "
> > 
> > Regards,
> > 
> > Yoshihiro Ohba
> > 
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> 
> 

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

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Nov 2005 17:17:13 +0200

I don't think we ever discussed what "PANA compliant" means. Rather than
making an attempt in defining this term, I'd say "any protocol that
satisfies the requirements of PAA to EP signaling can be used for that
purpose." These requirements are described in RFC4058. I don't think if
a deployment uses something other than SNMP it'd be missing anything.

Alper

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Tuesday, November 01, 2005 3:22 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: Re: [Pana] Issue 207 (AD-review, pana-fwk, section 7.2)
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 01 Nov 2005 10:51:54 -0500

> a deployment uses something other than SNMP it'd be missing anything.

If a deployment is based on using PAA and EP implemented by the same
vendor, there is no problem.  But if PAA and EP are implemented by
different vendors, then is the above statement sufficient for
interoperability?

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 3 Nov 2005 00:40:14 +0200

> different vendors, then is the above statement sufficient for

I see your point. But this is not really about "PANA 'protocol'
interoperability". Because that does not depend on the PAA2EP protocol.
I think it is about architectural interoperability. In an architecture
where we have multiple network elements (PAA, EP, PAC, AAA server) and
multiple protocols (PANA, EAP, PAA2EP, RADIUS/Diameter, etc.) ensuring
one network element from one vendor can interoperate with another
element from another vendor is the issue... 

I don't know if we really want to capture something about this in the
documents, but " a standard method such as SNMP [I-D.ietf-pana-snmp]
MUST be implemented by a compliant PANA implementation." seemed too
strong (at least in the absence of a common understanding of what 'PANA
compliant implementation' means). 

Alper

> > > > > Again, is this always snmp? If so, why not just say that?
Opening
> > the
> > > > > that you want to leave the door open to xml or cli filter
config?
> > If
> > > > > known, though a standard method such as SNMP MUST be
implemented
> > by a
> > > > >       When PAA and EP are separated and PAA is configured to
be
> > the
> > > > >       initiator of the discovery and initial handshake phase
of
> > PANA,
> > > > >       EP has the responsibility to detect presence of a new
PaC
> > and
> > > > >   Also to be consistent, change the following paragraph in
Section
> > 7:
> > > > >    EP(s) and ask for installing filtering rules to allow the
PaC
> > to
> > > > send
> > > > >    and receive data traffic.  SNMP is used between PAA and
EP(s)
> > for
> > > > >    EP(s) and ask for installing filtering rules to allow the
PaC
> > to
> > > > >    send and receive data traffic.  A PAA-EP protocol between
PAA
> > and
> > > > >    EP(s) is used for this purpose.  A vendor-specific protocol
may
> > be
> > > > >    used as a PAA-EP protocol, though SNMP is used for a
complient
> > PANA

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 02 Nov 2005 18:28:17 -0500

> element from another vendor is the issue... 

I think you are right.  Taking a look at PAA-AS protocol, RADIUS,
Diameter or any other protocol can be used for it, and the PANA
framework does not specify a default PAA-AS protocol.  I think the
same logic can apply to PAA-EP protocol.

> compliant implementation' means). 

I agree.

Yoshihiro Ohba