Subject: RE: Last Call: draft-ietf-pana-framework-06

From: "Nelson, David" <[email-masked]>
Date: Thu, 6 Apr 2006 11:15:15 -0400

Bob O'Hara writes...

> I can't forecast what an official interpretation
> response might say, but the text in clause 5 is taken from the
overview
> section of the standard.  The text prohibiting non-802.1X frames from
> passing on the uncontrolled port is taken from clause 6, the
description
> of the Data SAP.  My opinion would be that the text in clause 6 would
be
> given precedence, both because of its placement and because of its
> specificity.

I offer a little historical perspective on the text under debate in this
thread.  I am responsible for the text in Clause 5 that appears to allow
other protocols besides 802.1X/EAPOL, which terminate in the AP, i.e. do
not allow forwarding to the DS, to run over the 802.1X uncontrolled port
in the AP.  I added this text to one of the 802.11i drafts specifically
to address a letter ballot comment on the previous draft.  I was quite
active in TGi at the time, including the comment resolution work.  TGi
voted to accept this comment resolution.  It was arguably my mistake to
leave the apparent conflict with the text of Clause 6, but the comment
was probably only against Clause 5.  Whether this comment resolution was
a good idea, in the long run, is of course open to debate.  The intent
at the time was to allow operations such as those proposed in PANA, at
least to the extent that I understand them based on this thread.  I'm
not sure this will help in resolving the issue, but at least it explains
the apparent conflict.

Regards,

Dave Nelson

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

---

From: "Bob O'Hara \(boohara\)" <[email-masked]>
Date: Thu, 6 Apr 2006 16:55:38 -0700

Yoshihiro,

You say that the "intent of the standard has been already clarified by
David Nelson".  This is incorrect.  David has offered his opinion as an
individual as to what he believes took place.  He has no authority to
interpret the "intent" of the standard.

Only the working group can interpret the standard when there is an
apparent ambiguity, as this situation appears.  Basing the work of PANA
on anything less would be very precarious, indeed.

 -Bob
 
-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 4:46 PM
To: Bob O'Hara (boohara)
Cc: Alper Yegin; Yoshihiro Ohba; Sam Hartman; [email-masked]
Subject: Re: Last Call: draft-ietf-pana-framework-06

Thanks for the URL to the "interpretation request".

The text in the URL says:

"
Interpretations are issued to explain and clarify the intent of the
standard and are not intended to constitute an alteration to the
original standard or to supply consulting information. The
interpretations subgroup cannot make new rules to fit situations not
yet covered in the standard, even if the investigations of the
subgroup lead it to conclude that the requirement is incomplete or in
error. Changes to the standard are made only through revisions or
supplements to the standard.
"

The intent of the standard has been already clarified by David Nelson.
TGi voted to accept the text proposed for the intent.  So I don't
expect the intent to be changed through the "interpretation request"
procedure, while I expect the intent to be more clarified in the
procedure.

Best regards,
Yoshihiro Ohba

On Thu, Apr 06, 2006 at 04:28:07PM -0700, Bob O'Hara (boohara) wrote:
> The official way to do this is to submit an "interpretation request"
to
> the IEEE.  The instructions can be found here:
> http://standards.ieee.org/reading/ieee/interp/.  The request will then
> be referred to the appropriate working group for response and
approval.
> The earliest that this could be completed by 802.11 is during their
> meeting during the week of May 14-18.
> 
> This would result in an official response from the 802.11 working
group
> and the IEEE.  Generally, the response will include referral to the
next
> maintenance task group for inclusion in a corrigendum or the next
> revision of the standard.
> 
>  -Bob
>  
> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Thursday, April 06, 2006 4:22 PM
> To: Bob O'Hara (boohara); 'Yoshihiro Ohba'; 'Sam Hartman'
> Cc: [email-masked]
> Subject: RE: Last Call: draft-ietf-pana-framework-06
> 
> 
> Hi Bob,
> 
> I think the issue at hand is not the interpretation of text, but the
> conflicting text in the 802.11i standard. David Nelson has already
shed
> some
> light to this.
> 
> Text in Clause 5 opens the door for non-802.1X protocols to utilize
the
> uncontrolled port, and we didn't find any limitations on what those
> protocols may be -- hence concluded that PANA could be one of those.
> This is
> where PANA WG came from. I'd not say this is an "interpretation", but
> rather
> spec-reading.
> 
> How are we (in fact, IEEE) going to resolve this?
> 
> Alper
> 
> 
> 
> 
> > -----Original Message-----
> > From: Bob O'Hara (boohara) [mailto:[email-masked]]
> > Sent: Thursday, April 06, 2006 4:49 PM
> > To: Alper Yegin; Yoshihiro Ohba; Sam Hartman
> > Cc: [email-masked]
> > Subject: RE: Last Call: draft-ietf-pana-framework-06
> > 
> > Alper,
> > 
> > In my reading of 802.11i, such an AP will not be compliant.  In
> > addition, PANA needs to have the 802.11 mobile client also support
> PANA.
> > Currently, PANA packets would also be dropped at the sending client,
> > prior to opening the 802.1X controlled port.
> > 
> > In Yoshi's email, referenced at the URL below, he says that it is
> > possible to interpret the text in the current 802.11ma revision
draft
> to
> > allow the PANA operations described for bootstrapping an 802.11i AP.
> > The IEEE is the only body that has the authority to interpret their
> > standards.  For 802.11, IEEE delegates that authority to the working
> > group that I chair.  I can't forecast what an official
interpretation
> >  -Bob O'Hara, Chair, 802.11 Task Group m
> > 
> > -----Original Message-----
> > From: Alper Yegin [mailto:[email-masked]]
> > Sent: Wednesday, March 22, 2006 11:55 AM
> > To: Bob O'Hara (boohara); 'Yoshihiro Ohba'; 'Sam Hartman'
> > Cc: [email-masked]
> > Subject: RE: Last Call: draft-ietf-pana-framework-06
> > 
> > 
> > Hi Bob,
> > 
> > Last two e-mails were in response to Sam's "implementability"
concern.
> > 
> > Note that, when an IEEE 802.11 AP is used as a PANA EP and
> bootstrapped
> > for
> > IEEE 802.11i security, it is not an "off-the-shelf" AP. Some amount
of
> > coding needs to be done on the AP.  The question is, would this
> modified
> > AP
> > still be compliant with IEEE 802.11i or not (no, PANA WG does not
mean
> > to
> > propose a change to IEEE standards.)
> > 
> > Please see Yoshi's e-mail and let us know what you think.
> > http://www1.ietf.org/mail-archive/web/ietf/current/msg41011.html
> > 
> > Thanks.
> > 
> > Alper
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Bob O'Hara (boohara) [mailto:[email-masked]]
> > > Sent: Wednesday, March 22, 2006 8:34 PM
> > > To: Alper Yegin; Yoshihiro Ohba; Sam Hartman
> > > Cc: [email-masked]
> > > Subject: RE: Last Call: draft-ietf-pana-framework-06
> > >
> > > I have no doubt that an implementation can be made to work, when
one
> > has
> > > control of all the layers.  The question is whether PANA bootstrap
> > will
> > > work when all that is supplied is a PANA layer that must operate
> above
> > > an existing, presumably standards compliant, 802.1X/802.11i
> > > implementation.  When one can bypass a restriction of 802.11i
(which
> > > says to drop non-802.1X frames on the uncontrolled port), then
PANA
> > > bootstrap is possible.
> > >
> > > However, what authority has PANA to change a standard developed in
> an
> > > entirely different standards organization?
> > >
> > >
> > >  -Bob
> > >
> > > -----Original Message-----
> > > From: Alper Yegin [mailto:[email-masked]]
> > > Sent: Wednesday, March 22, 2006 7:19 AM
> > > To: 'Yoshihiro Ohba'; 'Sam Hartman'
> > > Cc: [email-masked]
> > > Subject: RE: Last Call: draft-ietf-pana-framework-06
> > >
> > > We (Samsung) have an implementation as well.
> > >
> > > Alper
> > >
> > > > -----Original Message-----
> > > > From: Yoshihiro Ohba [mailto:[email-masked]]
> > > > Sent: Wednesday, March 22, 2006 12:02 AM
> > > > To: Sam Hartman
> > > > Cc: [email-masked]
> > > > Subject: Re: Last Call: draft-ietf-pana-framework-06
> > > >
> > > > If implementability of the specification is an issue, my company
> has
> > > > an implementation of bootstrapping 802.11i PSK mode based on
> running
> > > > PANA over Uncontrolled Port.  The implementation works without
> > > > modifying a WiFi hardware or its firmware.  We have a plan to
> > publish
> > > > the source code of the implementation in Open Diameter project.
> > > >
> > > > Regards,
> > > > Yoshihiro Ohba
> > > >
> > > > On Tue, Mar 21, 2006 at 11:45:25AM -0500, Sam Hartman wrote:
> > > > > >>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]>
> > writes:
> > > > >
> > > > > e email discussion over
> > > > >     Yoshihiro> the EAP mailing list quoted below, I had a
short
> > > > >     Yoshihiro> conversation on this issue with Jesse Walker
> during
> > > > >     Yoshihiro> IEEE 802 interim meeting in January in order to
> > > > >     Yoshihiro> follow-up the email discussion and understand
the
> > > input
> > > > >     Yoshihiro> from Jesse more.  As far as I understand, he
> seemed
> > > to
> > > > >     Yoshihiro> agree on this possible interpretation while he
> > > > >     Yoshihiro> mentioned that there is no existing 802.11i
> > > > >     Yoshihiro> implementation that uses 802.1X Uncontrolled
Port
> > for
> > > > >     Yoshihiro> non-802.1X frame exchange, but I may be still
> > > > >     Yoshihiro> misunderstanding something.  Also, for the sake
> of
> > > > >     Yoshihiro> completeness of the email discussion over the
EAP
> > > > >     Yoshihiro> mailing list, the following email that I sent
in
> > > > >     Yoshihiro> response to msg03872 should be quoted as well:
> > > > >     Yoshihiro>
> > > http://lists.frascone.com/pipermail/eap/msg03879.html.]
> > > > >
> > > > >
> > > > > So, the implementability of our specifications is a
significant
> > > > > concern.  If we do not expect there to be environments in
which
> a
> > > > > feature of our spec will be implementable, then we should
remove
> > > that
> > > > > feature.
> > > > >
> > > > > Implementability is sufficiently important that RFC 2026
> > explicitly
> > > > > gives the IESG the ability to request an implementation report
> > even
> > > > > for publication at proposed standard when it has questions
about
> > > > > whether a particular feature can be implemented interoperably.
> > > > >
> > > > > --Sam
> > > > >
> > > > >
> > > >