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

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

Yoshihiro Ohba wrote:

>On Thu, Nov 03, 2005 at 12:40:14AM +0200, 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.
>>    
>>
>>>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?
>>>      
>>>
>>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 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.
>
>  
>
>>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). 
>>    
>>
>
>I agree.
>  
>
I disagree. From an architectural vantage, PANA defines entities and
this WG defines how they speak to one another. At a minimum, I think
that PANA encompasses the Client, PAA and EP. The AAA server could be
argued as outside the "PANA" realm itself, and something that must be
interworked with a number of interfaces (though I still would support
chosing some MUST implement as a default).

Thus, at least within the PANA entities themselves, I would strongly
recommend one set of MUST implement options so that PANA at least works
"out of the box." If you want to fill cart with a ton of options and
differentiation all over the place, fine, but ONE default that works is
a Good Thing (and will help greatly getting these documents through the
IESG, I can say this from experience already).

- Mark

>Yoshihiro Ohba
>
>  
>
>>Alper
>>
>>    
>>
>>>Yoshihiro Ohba
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>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

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 20 Dec 2005 15:52:42 +0200

Hi Mark,

I understand that mandating at least one choice is a good thing for
interoperability. But I couldn't figure out the best way to capture that
in the IETF documents.

For example, even though we define a PAA-to-EP protocol based on SNMP,
architecture are still free to choose other protocols, especially their
existing/upcoming proprietary protocols. Examples: RP interface between
BS and PDSN in 3GPP2, and R6 interface between the BS and ASN-GW in
WiMAX. When SDOs make such decisions, it should not appear that they are
failing to comply with an IETF standard. The proposed "MUST" clause
yields such an undesired result. If a vendor of PDSN knows that the
product will be used with 3GPP2, and SNMP is not used, then the vendor
should not have to implement SNMP just for the sake of IETF compliance.

I know that for example in some SDOs, work includes defining "profiles"
for defining useful combinations when options are present. For example,
we could define an "IETF profile of PANA architecture" that includes
"PANA and SNMP". An SDO like the ones I mentioned above don't need to
comply with this profile, and they can have their own. [3GPP2 profile
could include PANA and RP]

Does this help?

Alper

> From: Mark Townsley [mailto:[email-masked]]
> Sent: Tuesday, December 20, 2005 12:53 PM
> To: Yoshihiro Ohba
> Cc: Alper Yegin; [email-masked]

---

From: James Carlson <[email-masked]>
Date: Tue, 20 Dec 2005 09:30:53 -0500

> should not have to implement SNMP just for the sake of IETF compliance.

This produces walled gardens for deployment, which is something that I
had thought IETF documents (and the IETF mission as a whole) were
supposed to avoid.

It means that users end up with no choice.  If they are implementing
3GPP2 and need PANA, they can't just choose any desired product
claiming to support PANA.  Instead, they must choose a product that
supports the special "flavor" used in 3GPP2.

How is that result considered "interoperability?"

Of course, both users and vendors are free to flout whatever
requirements they feel they need to (or can manage to get away with),
as the IETF doesn't yet have a police force, but I think it's hard to
see how explicitly non-interoperable solutions can be recommended by a
Standards Track IETF document.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 21 Dec 2005 08:05:27 +0200

James,

3GPP2, as an SDO defining an IP-based architecture, can take several
protocols from IETF and other SDOs, and define others on its own to
reach "3GPP2 interoperability." I didn't understand where the problem is
with this.

I also didn't understand what you were referring to as
"non-interoperable solutions recommended by a Standards Track IETF
document".

I'd appreciate if you can clarify.

Alper

> From: James Carlson [mailto:[email-masked]]
> Sent: Tuesday, December 20, 2005 4:31 PM
> To: Alper Yegin
> Cc: 'Mark Townsley'; 'Yoshihiro Ohba'; [email-masked]
> Subject: RE: [Pana] Issue 207 (AD-review, pana-fwk, section 7.2)
> 
> Alper Yegin writes:

---

From: James Carlson <[email-masked]>
Date: Wed, 21 Dec 2005 10:18:10 -0500

> reach "3GPP2 interoperability." I didn't understand where the problem is

There isn't one.  As I said, developers (including other standards
organizations) are free to do as they like.  The IETF has no
enforcement arm.  If it's necessary for them to ignore a "MUST" out of
some IETF RFC, or just discard an entire RFC completely, I see no
problem with that.  (There are clearly deployment and global problems
resulting from it, but those aren't the IETF's fault.)

> "non-interoperable solutions recommended by a Standards Track IETF

The goal of RFCs and the IETF as a whole, as I understand it, is to
foster interoperability.  One of the crucial elements of that is
establishing a common base: a common set of implementation options or
features on which users can always rely.  The current draft says this:

                                              If the PAA and EP are
      residing on the same node, an API is sufficient for this
      communication.  Otherwise, a protocol is required to carry the
      authorized client attributes from the PAA to the EP.  While not
      prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp]
      is suggested for this task.

That word -- "suggested" -- is in my opinion too weak for the task.
It permits (and perhaps encourages) implementors to choose whatever
protocol might be handy.  The result is a lack of interoperability:
those that speak SNMP won't be able to talk to those who do not.  Both
will claim to support the resulting RFC, and yet they do not work
together.  That's a failure of interoperability.

Reasonable ways out of the dilemma would, I think, include:

  - removing the PAA/EP separation concept entirely and requiring
    these two functions to be implemented on a single node.  This
    means that anyone who wants to separate them will essentially be
    on his own to do so.  Users must not assume that a PANA
    implementation includes PAA/EP separation as a feature.  (This is
    pretty close to what the current text actually does.)

  - mandating the use of some particular protocol to connect PAA and
    EP, while allowing the use of additional protocols if desired.
    This is what I think the AD is suggesting.

---

From: James Carlson <[email-masked]>
Date: Wed, 21 Dec 2005 10:35:35 -0500

> resulting from it, but those aren't the IETF's fault.)

Perhaps I ought to clarify that a bit more: I think that if some other
organization believes it can and should cherry-pick IETF documents and
tweak requirements to fit its purposes, then the responsibility for
that "tweaking," and the resulting effects, should rest entirely on
that other organization.  The IETF ought not be in the business of
paring away or watering down requirements that promote
interoperability merely to make some other group happier.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 22 Dec 2005 06:20:04 +0200

I think we may be getting into "system/architecture interoperability"
whereas in the IETF specifications we should stick to "protocol
interoperability."

PANA framework document has this figure:

                                              RADIUS/
                                              Diameter/
        +-----+       PANA        +-----+     LDAP/ API    +-----+
        | PaC |<----------------->| PAA |<---------------->| AS  |
        +-----+                   +-----+                  +-----+
           ^                         ^
           |                         |
           |         +-----+         |
      IKE/ +-------->| EP  |<--------+ SNMP/ API
   4-way handshake   +-----+

Without making any dent on the PaC-to-EP protocol interoperability, the
other interfaces (PaC-to-EP, EP-to-PAA, PAA-to-AS) can be anything. 

Should we mandate use of one set of protocols for the whole system? Like
MUST use PANA with RADIUS, SNMP, and IKE? This is just one of the
combinations which would not be used by most of the deployments (because
there are too many combinations). For that, a "MUST" that is going to be
typically violated is not really going to help interoperability.

Similarly we can talk about RFC 3748 (EAP) and the AAA protocol between
the EAP pass-through authenticator and the authentication server. The
spec just enumerates the possibilities: RADIUS and Diameter. It does not
even suggest one, and of course it does not mandate one. I think this
makes sense.

I understand the intent behind the suggestion, but I'm afraid we are
stepping outside the scope of IETF and we cannot really help there. This
is for another level of interoperability, and it needs to be handled by
our customers (systems builders, various SDOs), imo.

Alper

> Sent: Wednesday, December 21, 2005 5:18 PM
> To: Alper Yegin

---

From: James Carlson <[email-masked]>
Date: Wed, 21 Dec 2005 17:13:24 -0500

> whereas in the IETF specifications we should stick to "protocol

I disagree with the first part, but agree strongly with the latter.

Protocol interoperability _requires_ that minimum standards be set.

> other interfaces (PaC-to-EP, EP-to-PAA, PAA-to-AS) can be anything. 

That's the part I disagree with.

If PANA includes EP/PAA separation by way of a networking protocol as
an integral part of its definition, then it needs to describe that
protocol.  The protocol can be a variable -- but even if it is, there
needs to be one common value chosen as "must implement."  If not, then
the document doesn't describe an interoperable system.

> MUST use PANA with RADIUS, SNMP, and IKE? This is just one of the

Not "use."  "Implementation."

> typically violated is not really going to help interoperability.

In that case, I would suggest that the document has the wrong focus.
It shouldn't attempt to standardize the deployment components at all
and instead just talk about the one protocol (PaC to PAA) alone.

If it's going to bite off the bigger problem, then I think it has to
deal with the interoperability of the bigger problem.  Allowing
vendors to choose mutually incompatible protocols as part of that
solution does _not_ achieve interoperability.

> even suggest one, and of course it does not mandate one. I think this

I think that's a slightly different problem because the AAA connection
isn't _necessarily_ any part of the PANA implementation, while EP,
PaC, and PAA are.  The AAA part could just be system infrastructure.

But it does have similar problems if it's part of the solution
recommended by this document.

> our customers (systems builders, various SDOs), imo.

I don't think that's true.  I don't see "levels" of interoperability
here.  Either the document tells vendors what they need to do to
achieve interoperability, or it does not.  If it does not, then at
least that material doesn't sound like standards track material to me.

---

From: James Carlson <[email-masked]>
Date: Wed, 21 Dec 2005 17:21:53 -0500

> That's the part I disagree with.

To take it to an absurd conclusion: why not allow the vendor to
specify some protocol other than PANA for the PaC-to-PAA connection?
After all, as long as the EAP messages get through and the protocol is
"right" for some environment, that should be sufficient to get
interoperability.  Why tie this one part down?

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 22 Dec 2005 08:08:42 +0200

> the document doesn't describe an interoperable system.

With that token, RFC 3748 should have mandated either RADIUS or
Diameter, as the EAP pass through mode is an integral part of its
definition. But it didn't. And others like ISMS, IKEv2, MIP4, MIP6, etc.
should do the same. Does this make sense?

> and instead just talk about the one protocol (PaC to PAA) alone.

I don't see how identifying elements of a bigger picture and a list of
interfaces among them is a bad thing. Does it help interoperability
better if we didn't mention any one of these?

> recommended by this document.

I meant to give this as an example that RFC 3748 didn't follow what you
are suggesting. 

> least that material doesn't sound like standards track material to me.

Maybe this is one of the causes of the discussion: this document is for
an informational RFC, not standards track. Does this help?

Alper

---

From: James Carlson <[email-masked]>
Date: Thu, 22 Dec 2005 10:06:11 -0500

> should do the same. Does this make sense?

For what it's worth, and it might not be much, I was not at all in
favor of including the "pass-through behavior" feature as part of the
EAP RFC.  I viewed it as an unnecessary foray into implementation
territory, as an unbiased observer on either side of such a device
(lower-layer or AAA) cannot tell if such a thing is going on.  It's
design and implementation, not protocol.

But, yes, given that it does describe it, it should give a minimum
requirement to promote interoperability.  It seems to in a slightly
obtuse way in section 3.1 (specifying that RADIUS "satisfies [the]
ordering requirements"), but you're right that it should say more.

Is your argument that since the EAP RFC lacks detail required to
produce an interoperable "Pass-through Authenticator," then it's ok
for this PANA document to omit the details necessary to make an
interoperable EP?

> better if we didn't mention any one of these?

I don't think it's necessarily a bad thing.  I do think it's less
helpful, though, if it doesn't specify some minimum requirements.  The
point is to get interoperability.  You can't get there if the big
picture has boxes labeled "maybe."

Are you perhaps saying that this is an issue for some other document?
I.e., is there an "EP behavior" document that will mandate the use of
at least the SNMP-based protocol?

> an informational RFC, not standards track. Does this help?

You're right; that's part of it.  Based on the context, I didn't
realize that it was informational only.

That seems very strange to me.  Why would there be any reluctance at
all to specify a common solution for the good of all?  How could
anyone anywhere possibly be worried about being "out of compliance"
with an Informational RFC?  Why is accomodating other solutions -- to
the point of not specifying one as required -- a concern?

Having a document intended to foster interoperability that doesn't
actually do that seems somewhat less "informational" than would
otherwise be desired.

But I'd rather see the IESG bury the "Informational" process out back
rather than fight this fight.  If the document authors are not
concerned with a lack of interoperability between EP and PAA stemming
from independent vendor protocol choices, then I suppose there's not
much more to be said.

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 26 Dec 2005 22:52:01 +0200

> for this PANA document to omit the details necessary to make an

I was just wondering why RFC3748, which has your name as one of the
co-authors, didn't follow your suggestion. I also meant to point out
multiple other examples in the same boat; and how following your suggestion
means IETF, in its own terms, mandating one of the two AAA protocols. I
didn't mean to say "we have right to copy previous mistakes" :-)
 
> at least the SNMP-based protocol?

No, there isn't. The only other document is the one that describes the SNMP
extensions to realize PAA-to-EP protocol.

> with an Informational RFC?  

I'm aware that other SDOs do care about being in compliance with RFCs of any
type. I'm not saying they never violate RFCs, but they try not to. 

> Why is accomodating other solutions -- to

So that people don't get the wrong impression that PANA works only with
SNMP. 

> from independent vendor protocol choices, then I suppose there's not

Sorry that I, as just one of the authors of the document, couldn't agree
with you.

Alper

---

From: James Carlson <[email-masked]>
Date: Tue, 27 Dec 2005 11:56:40 -0500

Alper Yegin writes:
> co-authors, didn't follow your suggestion.

If you must know, I contributed some material early on, but wasn't
actively involved in the writing of that RFC.  Bernard Aboba felt that
I should have "author" status because of those contributions, not
because I validated or audited much (or indeed any) of the text.  I
didn't quite think that was the case, but I didn't argue the issue,
either.

If you're saying that I'm somehow responsible for (and get veto clout
over) the material that ends up there, I think you might be mistaken.
Even for active contributors to a document, the IETF works by rough
consensus, not by unanimous vote, and attributing positions taken by a
document with multiple authors to those of the authors individually
seems a bit rash to me.

I suspect that my argument here is faring about as well as the one for
EAP.

> I also meant to point out

OK.

> extensions to realize PAA-to-EP protocol.

But does that (or should that) document specify that when there's a
PAA/EP separation, then at least that protocol must be supported?

If it does not, then this is just one of a field of protocols the
vendor could select.  When multiple vendors make different choices,
the resulting implementations will not be able to talk to each other.

> So that people don't get the wrong impression that PANA works only with

I still don't get it.

Why is it impossible to specify a _minimum_ requirement?  If folks
want to embellish the heck out of their implementations and include 2,
10, or 50 possible protocols, that's just fine.  But why not require
that at least one particular one is present so that interoperability
using that protocol is always possible?

If SNMP is the problem, then specify some other protocol as the
minimum.  I don't think it matters which protocol is selected, as long
as it's at least one.

> Sorry that I, as just one of the authors of the document, couldn't agree

I'll give.

Mark: do what you see fit here.  It seems the document authors just
don't agree that omitting a minimum requirement leads to
interoperability problems, and I'm not sufficiently motivated to be
overly concerned whether PANA can be deployed successfully.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 27 Dec 2005 23:19:11 +0100

>overly concerned whether PANA can be deployed successfully.
One thing is sure, my job will be far more more difficult in getting 
this past the IESG if the WG refuses to at least identify one 
interoperable configuration as a default MUST implement. I would like 
the WG to make my job easier, not more difficult.

- Mark

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Dec 2005 15:04:15 +0200

This is an interesting thread...

FWIW, I'll say a few words first about the EAP example that
was brought up.  RFC 3748 was largely as it was given that
we were documenting EAP not redesigning EAP. If we look
back to the very early times when EAP was designed (pre-
EAP WG), I think we can first say that it would have been
better if passthrough was better officially recognized in
the architecture as opposed to treating it as something
that is not visible to the client. We could have provided
better security for it, for instance. Another issue is
sufficient detail to deal with the sometimes hairy
special cases -- current documents now provide this
detail, and this seems necessary. A third issue is
what protocol to use on the backend side -- in the
EAP case the details are largely elsewhere than
in selecting the specific AAA protocol. More generally,
the IETF normally does not mandate a specific AAA protocol
when defining an application or network access protocol.

And then back to PANA. I would not like to mandate
a specific backend AAA protocol, although we do need
some details for it. Ongoing work in the WG writes
those details down while still allowing either RADIUS
or Diameter to be used.

The case with SNMP to the EP is less clear. First, in
this case the client does see the difference between
a single box and a distributed (PAA-EP) implementation.
To me this says that the functionality must be an official,
explicit part of the PANA protocol and always present.
The question is whether the protocol inside the access
network (SNMP or other) is mandated in the specifications.
I do share Mark's and James' concern of providing interoperable
products. To me, part of the attraction in PANA is its ability
to run over IP and be put to "any" access network. And
what about running PANA over different types of
networks simultaneously?

Having said that, I'm not so crazy about SNMP either.
But I wonder if we could get past this specific issue
by saying "All PAA nodes SHOULD implement the
EP interface as specified in [ietf-pana-smp]"?

--Jari

---

From: James Carlson <[email-masked]>
Date: Wed, 28 Dec 2005 14:03:54 -0500

> EP interface as specified in [ietf-pana-smp]"?

I don't think the effect of the word "SHOULD" is substantially
different from the current "suggested."  Neither allows the user to
rely on the fact that one particular solution will always be
available.