RE: RADEXT Milestone revisions

["Nelson, David" <dnelson@enterasys.com>]

Glen Zorn writes...
 
> For the record, I didn't say that "keywrap" is out of scope, I said
that
> our draft is out of scope.

I see that as a distinction without any difference.  Would you care to
elaborate?  Is your keywrap draft about more than just keywrap?

> Is that a WG document?

The WLAN Attributes ID is an individual submission in pre-WG review, as
a WLAN Attributes RFC is a WG milestone.

> Or are we to assume that anything one of the Chairs proposes is
> automatically in scope?

No, of course not.  The inference I had hoped to convey is that the
chairs would likely be particularly careful about limiting the scope of
their submissions to the scope of the WG charter.

> The interesting questions are how this scope change occurred w/o a 
> change in the charter...

The issue is a matter of interpretation, as to whether or not new keywap
mechanisms, specifically new cipher suites for keywrap, are a new
security mechanism for RADIUS.  The initial interpretation was that they
were.  After a fair amount of discussion of this issue on the list, and
a discussion with Russ Housley, I decided that they were not.  A new
security mechanism for RADIUS would have PDU-wide scope, while a new
cipher suite for keywrap affects only individual attributes.
Additionally, the discussion in SAAG of the need to address modularity
of cipher suites in IETF protocols, arising out of the hash attacks,
played into the revised interpretation.  I believe that this was all
explained in previous postings to the list.

> Perhaps it also captured the fact that the conversation was an offer
of
> cooperation by myself and his "take it to the list" response was in
the
> nature of a rather curt rebuff to that offer.

No.  That nuance did not come through.  Generally speaking, however, a
request to discuss technical issues, the relative merits of various
solution approaches and Internet Draft submissions on the WG mailing
list is not considered a "rebuff".  I believe it to be at the very heart
of the IETF process.  No?

> What issues would those be?  The only one I recall is the one raised
again
> by Hannes, which is patently out of scope.

I'll review the minutes, but I recall that other issues were raised.  I
raised one issue about how the KEK management would occur. Your response
was that was out of scope of the document.  I never found that a
satisfying answer.

Following up on issues, and pro-actively driving their discussion on the
list, is incumbent upon document authors, in seeking to advance their
drafts. 

> Every indication is that our draft_is considered to be unacceptable by
> the chairs.  Bernard undoubtedly had reasons to ignore work by WG
members
> that had been in progress for more than a year at the in favor of
> proposing a novel scheme but I, at least, am not privy to them.

I believe that Bernard has technical issues with your draft.  That fact
that he chose to propose an alternate solution underscores that
assumption.  However, it is not fair to assume that *both* co-chairs
share the same opinion in this matter.  We often agree, and typically
work out any disagreements off-list.

In the case where one co-chair is acting in the capacity of an
individual WG member, by submitting an Internet Draft for consideration
as a WG work item, that co-chair recuses himself from acting in the
capacity of chair in determining consensus on that submission.  Just as
I recused myself and asked Bernard to determine consensus on the revised
MIB IDs, I would expect Bernard to recuse himself and ask me to
determine consensus on the WLAN ID.  (As a process point, we're probably
in trouble on the Issues & Fixes ID, as both co-chairs are co-authors.
:-)


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>