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

From: Mark Townsley <[email-masked]>
Date: Tue, 20 Dec 2005 11:29:49 +0100

Yoshihiro Ohba wrote:

>>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.
>  
>
If you are going to leave the door open to other options, the point is
not to mandate *use* of SNMP, but to at least mandate *implementation*
of SNMP (or some default, standard, version). The idea is to at least
have at least a baseline for all things that call themselves a PANA
functional entity. Perhaps this is what you are trying to say above, but
the term "used" implies how it is used in the network, not what the
implementor "uses" when writing the code.

So, instead of "SNMP is used for a compliant PANA implementation..." try
simply "SNMP MUST be implemented as well."

>  "
>
>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: Mark Townsley <[email-masked]>
Date: Tue, 20 Dec 2005 11:37:01 +0100

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 ...."
>  
>
Sorry guys, reading and replying in sequential order.

My point here is that at least ONE standard option needs to be mandated. 
I don't care which. Otherwise, the complexity of a standard solution 
that actually interoperates grows. I think you want to be able to say 
"my PAA, EP, Server, etc. does PANA" and that mean that at least *one* 
mode of operation is interoperable between all entities by virtue of the 
fact that they are PANA compliant alone. Otherwise, you end up with a 
matrix of PANA options, matching them up for each deployment, etc.

- Mark

>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)
>>
>>    
>>
>>>  has the responsibility to detect presence of a new PaC and
>>>      
>>>
>notifies
>  
>
>>>  the PAA(s) of the presence [RFC4058].  Such a presence
>>>      
>>>
>notification
>  
>
>>Is the issue that, since SNMP is rarely used for sets in routers
>>    
>>
>today,
>  
>
>send

---

From: Mark Townsley <[email-masked]>
Date: Tue, 20 Dec 2005 11:39:43 +0100

Yoshihiro Ohba wrote:

>On Tue, Nov 01, 2005 at 12:07:51AM +0200, Alper Yegin wrote:
>  
>
>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?
>  
>
Right, no one is forcing you to USE SNMP. Just make it available as an
*option* on *all* PANA compliant PAAs and EPs.

- Mark