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

[ncamwing <[e-mail]>]

Hi Stephen,

Thank you for the review and feedback (and apologies for the delayed
response!). Since we'll be at the IETF next week, perhaps we can meet
 live so that we can clarify how to clarify NAK vs. Error TLVs for
 the next version of the draft?

Please see inline for answers/comments:


On 1/25/10 2:42 AM, "Stephen McCann" <[e-mail]> wrote:

> 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?)
[NCW] Yes, that is the intent and we can clarify that in the IANA section
 if it not so....


> 
> 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.
[NCW] That is fine, I think we meant to leave it out as we do
not explicitly define one in the draft, though text does suggest the
 use of one.  I think one of the issues to consider is the state machine
 of the tunnel method and whether the state machine needs to know when
 to "conclude" (as well as allowing for a "protected" EAP success) which
 is why there is the suggestion for the need of some such explicit
 TLV....but we can consider alternate ways in which to proceed other
 that a result TLV.
> 
> 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.
[NCW] I think the subtle difference is NAK is more of negotiation(?) status
 to signal which TLVs were not supported vs Error is used for interpretation
 of the TLVs themselves that could affect the overall EAP state machine.
 So, in your example above, NAK would be used
 to specify which TLV was not supported but not affect the flow or EAP
 state machine, whereas the Error TLV may.
>From the current draft, the Error TLV only provides an Error code whereas
NAK includes a list of TLVs....but I am open to suggestions in how to merge
 these.  Would be happy to meet face to face next week so we can resolve
 this one.
> 
> 4) Do the TLV frames have a maximum length?
[NCW] They are inherently limited based on the TLV length field (2bytes)
 so the TLV can only be a max of 2^16
> 
> 5) What are Result TLVs? Is this a typo?
[NCW] Yes, that is a typo and will fix in the next revision.

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

--