Issue on eap-keying: informational or standards track
From: Florent Bersani (florent.bersanird.francetelecom.fr)
Date: Fri, 1 Oct 2004 13:42:54 -0400 (EDT)
   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."


Results generated by Tiger Technologies using MHonArc.