RE: RADEXT Milestone revisions

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Nelson, David <mailto:dnelson@enterasys.com> supposedly scribbled:

> 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?  

Not really: the document is & has been publicly available for some time; if it's not self-explanatory there is a serious problem.

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

I see.  So all we really had to do was associate it with WLAN (kind of like wrapping up, say, oil drilling in a wildlife refuge with a military budget proposal) & everything would have been OK?  This technology is not specific to WLANs; the smallest possible enclosing scope might be EAP.  Limiting it to the delivery of EAP-related keying material is far too restrictive, IMHO, but that's neither here nor there.

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

See above.

> 
>> 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, 

What does that mean?  Can't change the header?  No new messages?  If that is the case, then why is draft-zorn-radius-encattr-02.txt out of 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.  

Just humor a moron a bit longer: how do you expect to "address modularity of cipher suites" in RADIUS w/o modifying (at the very least the processing of) the RADIUS headers?  Is that not "PDU-wide scope"?  Have the rules changed?  Would it be too much to ask that the rules be clearly stated?  (More stupidity: I thought that that was what the WG charter was for.)

> I believe that
> this was all explained in previous postings to the list.  

Instead of revising the interpretation of the charter, how about revising the charter, so that the WG may be spared the need to follow these theological discussions?
 
> 
>> 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? 

Since we're talking about roles, the conversation in question was not between a WG member & a WG chair, but between two individual contributors, just in case that wasn't clear.
   
> 
>> 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.  

Neither do I.  Are you saying now that key management _is_ in scope of the radext charter?
 
> 
> 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.  

Rather than, oh, say, discussing them on the list.  So much for the "heart of the IETF process", I guess.

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

I'm not assuming anything, merely observing your actions.
  
> 
> 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. :-)       

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
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/>