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

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

Alper Yegin wrote:

>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.
>  
>
That particular deployment won't, but "PANA" as a standard will.

Note that none of this is a comment on whether SNMP is good or bad here 
as a protocol option, it is whether or not there is at least some MUST 
for all options that is implemented by each PANA entity so that there is 
some baseline of interoperability between all vendors that create a PAA, 
EP, Server, etc. without having to match up who implemented which option.

This is just good protocol design, in general. With all of these 
options, if you didn't discuss it earlier, perhaps you should have.

0.02 EUR,

- Mark

>Alper
>
>
>
>
>
>
>  
>
>>-----Original Message-----
>>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)
>>
>>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
>
>  
>

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