Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments)
Bert Greevenbosch <Bert.Greevenbosch@huawei.com> Mon, 07 January 2013 00:50 UTC
Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB2221F8A42 for <core@ietfa.amsl.com>; Sun, 6 Jan 2013 16:50:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHEG6oVCIAJd for <core@ietfa.amsl.com>; Sun, 6 Jan 2013 16:50:23 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B20321F8586 for <core@ietf.org>; Sun, 6 Jan 2013 16:50:21 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOM56997; Mon, 07 Jan 2013 00:50:19 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 Jan 2013 00:49:14 +0000
Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 Jan 2013 00:50:17 +0000
Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.003; Mon, 7 Jan 2013 08:50:12 +0800
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: Zach Shelby <zach@sensinode.com>, Andrew McGregor <andrewmcgr@gmail.com>
Thread-Topic: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments)
Thread-Index: AQHN6i4INd/yvaWIEUK38pCVjm1hP5g4WZ4AgASzTXA=
Date: Mon, 07 Jan 2013 00:50:11 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1FEED@szxeml509-mbx>
References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx> <1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> <95879247-97BE-454B-A325-A34FFAB36F68@sensinode.com>
In-Reply-To: <95879247-97BE-454B-A325-A34FFAB36F68@sensinode.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.110.143]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "core@ietf.org WG" <core@ietf.org>
Subject: Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2013 00:50:24 -0000
Hi Andrew, Zach, Indeed this solution is OK. Let's fix it this way. Best regards, Bert -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: 04 January 2013 17:01 To: Andrew McGregor Cc: Bert Greevenbosch; core@ietf.org WG Subject: Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments) Andrew, That would be a reasonable solution. I would suggest we create a ticket to solve Bert's comment in this way. Zach On Jan 4, 2013, at 5:45 AM, Andrew McGregor <andrewmcgr@gmail.com> wrote: > Simply deleting the "and MUST NOT be empty" from the first sentence you quote would make it unambiguous that an empty message is allowed, and must be rejected. > > Andrew > > On 4/01/2013, at 4:17 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote: > >> Hi Carsten, >> >> I agree that we should not define a separate NOOP method just for verification if the server is running. >> >> I guess the following text is what makes the suggested method work: >> >> A Confirmable message >> always carries either a request or response and MUST NOT be empty. A >> recipient MUST acknowledge such a message with an Acknowledgement >> message or, if it lacks context to process the message properly >> (including the case where the message is empty or has a message >> format error), MUST reject it; rejecting a Confirmable message is >> effected by sending a matching Reset message and otherwise ignoring >> it. >> >> I don't feel too strong about this. It is just that the spec seems to endorse violating its own MUST NOTs. But that discussion might be more philosophical than it is technical... >> >> Happy new year! >> Bert >> >> >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: 21 December 2012 15:36 >> To: Bert Greevenbosch >> Cc: core@ietf.org WG >> Subject: BG1 -- CoAP Ping (Re: [core] draft-ietf-core-coap-13 WGLC - my comments) >> >> Hi Bert, >> >> I'll pick some of your comments and reply with my personal view. >> I'll construct a separate subject for each so we have some threading if the discussion continues. >> >> On Dec 21, 2012, at 03:42, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote: >> >>> 1,E) p.9: "Provoking a Reset message (e.g., by sending an empty Confirmable message) is also useful as an inexpensive check of the liveness of an endpoint ("CoAP ping")." >>> I am not sure if we should endorse provoking RST messages by sending empty CON messages. >> >> We have found that it is very useful to have some lightweight "are you there" mechanism. >> This is both for diagnostics, and for address selection ahead of a heavy-weight non-idempotent operation. >> >> Now we could define a NOOP method that does nothing. In a Confirmable message, this would elicit an empty ACK. >> In total, this would look a lot like the mechanism described above, but with a "positive" ACK. >> 4-byte request, 4-byte ACK. >> >> However, the empty/RST exchange has essentially the same properties, with the simple advantage that you already (should) have implemented it. >> One method less, requires no additional code. >> Calling it out here was motivated by noticing that not every implementation before ETSI CoAP2 caught the MUSTs that make it work. >> >> One could argue that a ping that "works" should not end in an "error" message like RST. >> However, there are other cases where a RST is somewhat "normal", so seeing a RST should not be raising red alarms anyway. >> >> So I agree a bit with the sentiment you are expressing, but I think it is not sufficient reason to add a NOOP method. >> (I also briefly thought about instead adding an ECHO method (sends back the payload) so you can run diagnostics with different packet sizes. >> With a payload of 0 bytes, this becomes similar to NOOP, except that the ACK would carry a response code. >> Also sounds somewhat useful, but do we really need it? >> We most likely don't want an equivalent of CHARGEN, as this would be inviting amplification attacks.) >> >> Grüße, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net
- [core] draft-ietf-core-coap-13 WGLC - my comments Bert Greevenbosch
- Re: [core] draft-ietf-core-coap-13 WGLC - my comm… Barry Leiba
- Re: [core] draft-ietf-core-coap-13 WGLC - my comm… Bert Greevenbosch
- Re: [core] draft-ietf-core-coap-13 WGLC - my comm… Carsten Bormann
- [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap… Carsten Bormann
- [core] BG4 -- empty ACKs (Re: draft-ietf-core-coa… Carsten Bormann
- [core] BG8 -- NSTART=1 (Re: draft-ietf-core-coap-… Carsten Bormann
- [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-c… Carsten Bormann
- [core] BG39 -- Exotic URI (Re: draft-ietf-core-co… Carsten Bormann
- Re: [core] BG39 -- Exotic URI (Re: draft-ietf-cor… Klaus Hartke
- Re: [core] BG39 -- Exotic URI (Re: draft-ietf-cor… Carsten Bormann
- [core] BG24, BG35 -- reserved Location-* options … Carsten Bormann
- Re: [core] BG39 -- Exotic URI (Re: draft-ietf-cor… Bert Greevenbosch
- Re: [core] BG24, BG35 -- reserved Location-* opti… Bert Greevenbosch
- Re: [core] BG4 -- empty ACKs (Re: draft-ietf-core… Bert Greevenbosch
- Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-co… Bert Greevenbosch
- Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-… Bert Greevenbosch
- Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-… Andrew McGregor
- Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-… Zach Shelby
- Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-… Bert Greevenbosch
- Re: [core] BG8 -- NSTART=1 (Re: draft-ietf-core-c… Bert Greevenbosch
- Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-co… Bert Greevenbosch
- Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-co… Dijk, Esko
- Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-co… Dijk, Esko
- Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-co… Carsten Bormann
- Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-co… Carsten Bormann
- Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-co… Carsten Bormann
- Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-co… Dijk, Esko
- Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-… Carsten Bormann
- [core] Question on Appendix B (Re: draft-ietf-cor… Rahman, Akbar
- Re: [core] Question on Appendix B (Re: draft-ietf… Klaus Hartke
- Re: [core] Question on Appendix B (Re: draft-ietf… Rahman, Akbar
- Re: [core] Question on Appendix B (Re: draft-ietf… Klaus Hartke
- Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-… Bert Greevenbosch
- Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-co… Bert Greevenbosch
- Re: [core] BG4 -- empty ACKs (Re: draft-ietf-core… Maciej Wasilak