IETF Logo Mail Archive

Re: [Anima-bootstrap] bootstrap over CoAP

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 18 July 2016 08:53 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B026312D14D for <anima-bootstrap@ietfa.amsl.com>; Mon, 18 Jul 2016 01:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 JgtXqxSqEFsQ for <anima-bootstrap@ietfa.amsl.com>; Mon, 18 Jul 2016 01:53:15 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EA912D09F for <anima-bootstrap@ietf.org>; Mon, 18 Jul 2016 01:53:15 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id 52so88364212qtq.3 for <anima-bootstrap@ietf.org>; Mon, 18 Jul 2016 01:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BNAHJV4DBwkBBt7uadE4HvirajCvmWFOaM5zRfCUMf0=; b=sbR95udgJJuLHYrjlWENf0xSx1sSCQWlosmrytmcGMGpFIaIwpXpcob/hybdk2t3aN hIZhJcAx0Hvm4cOBxCwQtfFJQSEcZqz8urJy8uPlFeDR11MevH72uFx0UrQ/hG11q/ss KYZ1bDcr8YgGXpkqEk6zXrrDO6I5h0nPMEQ4S5fDeWc2lPQFQ64BByw+/VRJRvPNWrPe Odg5e1c/lU5j8XrPZ5wjIvpFXhuVz+nfI+XvqP8oj6lVtVUP09clkC2TQCYpG2sgpAsZ KYE9JU7Rypd8wwYeAVXqu0VwaAiOrA4ZPqMBhWWsR3W8JTibWhatGJ+mTT0Iv5DTjEy+ zjSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BNAHJV4DBwkBBt7uadE4HvirajCvmWFOaM5zRfCUMf0=; b=EsZOA5J7Rb59BPjxU9AU54KT5Mg6n5crf4yIeGuXWIh2pPeHkrX2VQsmlnBWPVkmMM x2MtlyQfRsAgHBBL9f1nkPYjgQ3qZM6cT5mcmm/okWIfPpy6jvJ9E9aBsOuhXKqDI1VO EaUJbywJBWe6ibwDVpxqFfUsA5tNBeCkp/+4k1OCilu4U1DTH+ls6Q9Pc/6f6HtnlkRL rQU0tZiqTPEeWDegMwP88WOvijAPuUMzJxDLUNKJDr9nDqRV2YDsjAE1mFpbRDzgP88k smSkg4uAtUJcNnWXmo/vsYVpSaqIy3TFU1cBt2J/ga7wjL+9h5urrbYQgBXWxivJhPSU RcxA==
X-Gm-Message-State: ALyK8tLA9XGv+rvrA4rjCPoF/Fj/ZjSFUEjlo06ooLokPtML7Xsdf5hPLQtr3F/K5ucv+g==
X-Received: by 10.237.50.35 with SMTP id y32mr11947325qtd.98.1468831994225; Mon, 18 Jul 2016 01:53:14 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m11sm974649qke.36.2016.07.18.01.53.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 01:53:13 -0700 (PDT)
To: "Max Pritikin (pritikin)" <pritikin@cisco.com>
References: <3A2F4C70-4960-4592-9314-6EC53B53CC94@cisco.com> <5d5623cd-fe4b-e443-da5d-6a43ffb9b5c6@gmail.com> <57810029.2070408@tzi.org> <17d1c08e-e9c6-d017-58ba-85989d56273d@gmail.com> <5781531A.1080702@tzi.org> <729980b6-767a-b675-1874-5c8e1fefd025@gmail.com> <8D35379D-678D-4293-93E4-150253AE46CE@cisco.com> <930872E1-2025-4EA5-B394-1991754216EE@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <a52cd114-fa8f-decb-dd3d-81fa182c88d6@gmail.com>
Date: Mon, 18 Jul 2016 20:53:09 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <930872E1-2025-4EA5-B394-1991754216EE@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/gjd5cR9CflMZgkZeKpGHUmV8Euc>
Cc: Carsten Bormann <cabo@tzi.org>, "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
Subject: Re: [Anima-bootstrap] bootstrap over CoAP
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2016 08:53:17 -0000


Regards
   Brian Carpenter
   (Don't blame me, I voted Remain.)



On 17/07/2016 22:19, Max Pritikin (pritikin) wrote:
> 
>> On Jul 10, 2016, at 7:14 PM, Max Pritikin (pritikin) <pritikin@cisco.com> wrote:
>>
>>>
>>> On Jul 9, 2016, at 11:33 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>
>>> On 10/07/2016 07:40, Carsten Bormann wrote:
>>>>>> I'm not sure I understood that part of the draft*), but generally CoAP
>>>>>> is designed so you can avoid fragmentation 
>>>>>
>>>>> That isn't what the draft seems to say, though. However, it's clearly talking
>>>>> about application-layer fragmentation to avoid IP fragmentation.
>>>>
>>>> (that's segmentation...  I know.)
>>>>
>>>>>> (and use the segmentation
>>>>>> provided by draft-ietf-core-block instead); the latter has per-segment
>>>>>> reliability (acknowledgements and retransmits).   DTLS may require
>>>>>> fragmentation during its handshake; this is mitigated if you can use a
>>>>>> PSK (symmetric) or, if you need asymmetric, ECC-based ciphersuite, which
>>>>>> allows the packets to stay well below 1280 bytes.
>>>>>
>>>>> Right. So the app layer chops the message into <1280 byte pieces, and one
>>>>> of them is lost...?
>>>>
>>>> Each of those segments ("blocks") is (actually, can be, but you do want
>>>> to do this with the block-wise protocol) transmitted reliably, so it
>>>> doesn't get lost.
>>>
>>> OK, so I think that a couple of sentences in draft-pritikin-coap-bootstrap
>>> could clarify all that.
>>
>> Thank you. We can make that happen,
> 
> The relevant text appears to be that CoAP [RFC7252] s4.2 Confirmable and non-Confirmable messages. Draft-ietf-core-block references this in s1 "using Non-confirmable requests within block-wise transfers outside the use case of 
> Section 2.8 would escalate the overall non-delivery probability”. Effectively CoAP, and then core-block, address this issue so we don’t need to say anything additional. We could mandate ‘Confirmable’ more so than is indicated in core-block. 

I agree that you don't need to add anything normative. I still think it would
help the reader to point out that integrity and loss recovery are provided
by this mechanism, because most people think of UDP as not providing those
properties.

   Brian

> 
> - max
> 
>>
>> - max
>>
>>
>>>
>>> Thanks
>>>   Brian
>>>
>>>> Grüße, Carsten
>>
>> _______________________________________________
>> Anima-bootstrap mailing list
>> Anima-bootstrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>

v2.23.0 | Report a Bug | By Email