pana@ietf.org
[Top] [All Lists]

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

Subject: RE: [Pana] Issue 207 AD-review, pana-fwk, section 7.2
From: James Carlson
Date: Tue, 27 Dec 2005 11:56:40 -0500
Alper Yegin writes:
> > 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?
> 
> I was just wondering why RFC3748, which has your name as one of the
> 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
> 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" :-)

OK.

> > 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?
> 
> No, there isn't. The only other document is the one that describes the SNMP
> 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.

> > Why is accomodating other solutions -- to
> > the point of not specifying one as required -- a concern?
> 
> So that people don't get the wrong impression that PANA works only with
> SNMP. 

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
> with you.

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.

-- 
James Carlson, KISS Network                    <james.d.carlson@xxxxxxx>
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

_______________________________________________
Pana mailing list
Pana@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pana

<Prev in Thread] Current Thread [Next in Thread>