eap Mailing List: RE: Issue on eap-keying: informational or standards track

[Joseph Salowey (jsalowey]

The EMSK material started out as a separate document.  There was a decision
to wrap it into the EAP-Key Framework document.  Given this it might make
sense to make the EAP-keying document standards track.  If this doesn't make
sense then I think we need to clearly define what goes into the standards
track and what doesn't.  I think there may be more required than what was in
the original EMSK document.  In any case the EAP-Keying document needs to be
consistent about EMSK usage.  

Joe  

eap-admin [at] frascone.com wrote:
>     Description of issue: should EAP-Keying be informational or    
> standards track 
> 
>     Submitter name: Florent Bersani
> 
>     Submitter email address: florent.bersani [at] francetelecom.com
> 
>     Date first submitted: 07/30/2004
> 
>     Document: Keying Framework
> 
>     Comment type: 'E'ditorial
> 
>     Priority: S' Must fix
> 
>     Section: various but 6.1.1 is a good example
> 
>     Rationale/Explanation of issue:
> 
>     It seems that the eap-keying document wishes to go "informational"
>     but it seems to me that it contains some normative text
> that impacts
>     EAP. I would consider logic that such text follow the
> same track as
>     the protocol it impacts, namely EAP and the standards track.
> 
>     For instance, RFC 3748 leaves the EMSK as unspecified and
>     reserved... but the EAP-Keying Framework specifies how to use the
>     EMSK (e.g. the AMSK scheme).
> 
>     Perhaps people more familiar with IETF procedures can provide
> some     input here? 
> 
>     Similarly, I am not sure that the key naming schemes
> should only be
>     informational, shouldn't they?
> 
>     Requested change:
> 
>     Specify the EMSK usage in a standards track document
> 
>     Add an explanatory note to the beginning of eap-keying telling
>     whether it places new requirements or it only gives some advice,
>     essentially explain to the reader the authoritative status of this
>     document (e.g., with respect to EAP). Text will be proposed as we
>     agree on this authoritative status... my feeling is that we should
>     really have two separate documents, one authoritative with key
>     naming and EMSK usage and one informational, with the useful
>     recommendations that are made throughout eap-keying (in
> which case,
>     the aforementioned note could look like "This document provides
>     insights and recommended practice for handling of EAP keying
>     material. Authoritative documents are RFC 3748 and [authoritative
>     keying document]. Should there be differences, RFC 3748 and
>     [authoritative keying document] prevail."
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap