IETF Logo Mail Archive

Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload

Alexander Pelov <a@ackl.io> Wed, 14 October 2015 09:24 UTC

Return-Path: <a@ackl.io>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEEF1B2CC3; Wed, 14 Oct 2015 02:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn3Dw4elUdRz; Wed, 14 Oct 2015 02:24:21 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057F31B2CD0; Wed, 14 Oct 2015 02:24:21 -0700 (PDT)
Received: from dhcp-salsa-i-130-75.rennes.enst-bretagne.fr (unknown [IPv6:2001:660:7301:3728:c46c:5963:1cca:3408]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 318D0A80F2; Wed, 14 Oct 2015 11:24:19 +0200 (CEST)
To: Carsten Bormann <cabo@tzi.org>, Rafa Marin Lopez <rafa@um.es>
References: <56162F1A.5020503@ackl.io> <DEC84E1F-F40D-48C2-8CBD-8262FADD45B2@um.es> <561C038C.7090305@tzi.org>
From: Alexander Pelov <a@ackl.io>
Message-ID: <561E1F58.4030501@ackl.io>
Date: Wed, 14 Oct 2015 11:24:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <561C038C.7090305@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/aQ2BHHh59P-5JGTbzy9nctkRkxE>
Cc: 6tisch@ietf.org, Dan Garcia <dan.garcia@um.es>, ace@ietf.org
Subject: Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2015 09:24:22 -0000

Hi Carsten,

yes, you are right about this! Thanks for pointing it out.

Indeed, the wording should be carefully selected, and I think in some 
(most?) cases the token can be zero-length. However, as you correctly 
state, this should not be a MUST. If the requester includes a token, 
then the responder must conform to the CoAP specification.

Best,
Alexander


Le 12/10/2015 21:01, Carsten Bormann a écrit :
> Rafa Marin Lopez wrote:
>> I would say that using zero-length token is possible. What I am not sure is whether make it mandatory or not. I mean we could say that if the client sends a zero-length token the server can consider it OK as per the text above. If there is a non-zero length token value should be also fine.
> There is never a reason to discuss token values -- these are chosen by
> the requester based on its needs, and there is never a reason for a
> responder to question that choice.
>
> Grüße, Carsten
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

v2.23.0 | Report a Bug | By Email