Re: [Emu] FW: New Version Notification for draft-cam-winget-eap-tlv-00

[Stephen McCann <[e-mail]>]

Nancy,
           I've reviewed
http://www.ietf.org/id/draft-cam-winget-eap-tlv-00.txt and have the
following comments:

1) Is the intention to make the TLV types administered by IANA?
Doesn’t there have to be a request in this draft? (I’m not sure, but I
just wanted to know?)

2) I don’t think you really need a result TLV. In my opinion, it would
be better to minimize the TLV’s defined in this draft and leave
“result” or other functionality to the RFC that defines the additional
TLV types. That way this simply focuses on using EAP to transport
these TLV’s.

3) Do you really need Error TLV? Or could you combine NAK and Error
TLV? Take the example of an EAP-Request containing 2 vendor-specific
TLV’s. Let’s say one can be processed and the other cannot. How do I
use the “error TLV”? It might be better to define error fields within
the TLV and use NAK as an error type.

4) Do the TLV frames have a maximum length?

5) What are Result TLVs? Is this a typo?

Kind regards

Stephen


2010/1/20 ncamwing <[e-mail]>:
> Dear Colleagues,
>
> As there have been discussions on how to carry data (such as crypto-binding,
> channel data, result indication and posture assessment
> as defined by the NEA group) beyond authentication methods inside an EAP
> tunnel,  we have submitted a proposal for using a TLV container to type and
> transport such data; the draft is referenced below.
>
> We would appreciate all comments.
>
> Thanks,
>    Nancy.
>
>
>
>
>
> ------ Forwarded Message
> From: IETF I-D Submission Tool <[e-mail]>
> Date: Mon,  4 Jan 2010 15:04:12 -0800 (PST)
> To: Hao Zhou <[e-mail]>
> Cc: Nancy Cam-Winget <[e-mail]>
> Subject: New Version Notification for draft-cam-winget-eap-tlv-00
>
>
> A new version of I-D, draft-cam-winget-eap-tlv-00.txt has been successfuly
> submitted by Hao Zhou and posted to the IETF repository.
>
> Filename:  draft-cam-winget-eap-tlv
> Revision:  00
> Title:   EAP Type-Length-Value Container
> Creation_date:  2010-01-05
> WG ID:   Independent Submission
> Number_of_pages: 11
>
> Abstract:
> The Extensible Authentication Protocol (EAP), defined in RFC 3748,
> facilitates multiple authentication methods that are widely deployed
> today.  As tunnel mechanisms become more prevalent, there has been
> interest in carrying other types of data between the EAP Peer and the
> EAP server.  Existing tunnel EAP methods have already defined generic
> data structures to carry such information.
>
> This document defines a generic TLV "container" that can be used
> within an EAP method.
>
> Status of this Memo
>
> This Internet-Draft is submitted to IETF in full conformance with the
> provisions of BCP 78 and BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups.  Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time.  It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on July 9, 2010.
>
> Copyright Notice
>
> Copyright (c) 2010 IETF Trust and the persons identified as the
> document authors.  All rights reserved.
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of
> publication of this document.  Please review these documents
> carefully, as they describe your rights and restrictions with respect
> to this document.  Code Components extracted from this document must
> include Simplified BSD License text as described in Section 4.e of
> the Trust Legal Provisions and are provided without warranty as
> described in the BSD License.
>
>
>
> The IETF Secretariat.
>
>
>
> ------ End of Forwarded Message
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>