From Bert.Greevenbosch@huawei.com Thu Jan 3 19:37:55 2013 Return-Path: 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 0F4DB21F8EA5 for ; Thu, 3 Jan 2013 19:37:55 -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 xHzJxwGdyJeF for ; Thu, 3 Jan 2013 19:37:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 909C221F8DF0 for ; Thu, 3 Jan 2013 19:37:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANE49510; Fri, 04 Jan 2013 03:37:52 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 03:37:04 +0000 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 03:17:46 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.01.0323.003; Fri, 4 Jan 2013 11:17:39 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: BG1 -- CoAP Ping (Re: [core] draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN303s7EWIo3+TIEmZTHPst/2V9Jg4kA1A Date: Fri, 4 Jan 2013 03:17:39 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> In-Reply-To: <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> 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" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 03:37:55 -0000 Hi Carsten, I agree that we should not define a separate NOOP method just for verificat= ion 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 endor= se violating its own MUST NOTs. But that discussion might be more philosoph= ical than it is technical... Happy new year! Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 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 com= ments) 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 = wrote: > 1,E) p.9: "Provoking a Reset message (e.g., by sending an empty Confirmab= le message) is also useful as an inexpensive check of the liveness of an en= dpoint ("CoAP ping")." > I am not sure if we should endorse provoking RST messages by sending empt= y CON messages. We have found that it is very useful to have some lightweight "are you ther= e" mechanism. This is both for diagnostics, and for address selection ahead of a heavy-we= ight non-idempotent operation. Now we could define a NOOP method that does nothing. In a Confirmable mess= age, this would elicit an empty ACK. In total, this would look a lot like the mechanism described above, but wit= h a "positive" ACK. 4-byte request, 4-byte ACK. However, the empty/RST exchange has essentially the same properties, with t= he 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" messa= ge 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 n= ot 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 AC= K would carry a response code. Also sounds somewhat useful, but do we really need it? =20 We most likely don't want an equivalent of CHARGEN, as this would be inviti= ng amplification attacks.) Gr=FC=DFe, Carsten From andrewmcgr@gmail.com Thu Jan 3 19:45:56 2013 Return-Path: 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 4EFE921F8EB8 for ; Thu, 3 Jan 2013 19:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Eh+0FvmpQbEZ for ; Thu, 3 Jan 2013 19:45:55 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 84B2021F8AF8 for ; Thu, 3 Jan 2013 19:45:55 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id rl6so9073851pac.1 for ; Thu, 03 Jan 2013 19:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=v0dzkcRWZTHE8nG6WDfTzBgx+tSUvCF/L+jlTcfLXOw=; b=UMHrT3cdah9bSGlisQPHyLP2vpjeAUoMeC2cN2hyQqERuQKIQ4PVkKFX90bfaffnpu 4lAlLyHoc3kVnuFtaaoecfTsYBRtbJgm++11cddQkY4meAfMa0CxLrH4NRxySnuv1rbL NZcWTmRmJXkmt//eVp0p2OdBoC2n0rzGCvFbW6u21147up043tXeNlwsxaVPhgHvTd+7 +SoF0SxGjCSXxWa95G6T2ph/aFb7Gij6m0Slv1A5yte7Nlnda+4GvDJ/KIFOq+rpbXrs ywmBnOxo2UbO1i76Y0b70D4WqeuOJ37j/5XGLpZam59VH6xp0VoADo6fs4dHYb5QUkTd aBzg== X-Received: by 10.68.241.232 with SMTP id wl8mr158048412pbc.144.1357271155272; Thu, 03 Jan 2013 19:45:55 -0800 (PST) Received: from ?IPv6:2406:e000:63ad:1:7405:e356:77b7:e0bd? ([2406:e000:63ad:1:7405:e356:77b7:e0bd]) by mx.google.com with ESMTPS id jv1sm26133699pbc.36.2013.01.03.19.45.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Jan 2013 19:45:54 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_2ECA80C9-D049-41A9-89F9-E719C684B36B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx> Date: Fri, 4 Jan 2013 16:45:45 +1300 Message-Id: <1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 03:45:56 -0000 --Apple-Mail=_2ECA80C9-D049-41A9-89F9-E719C684B36B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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 = wrote: > Hi Carsten, >=20 > I agree that we should not define a separate NOOP method just for = verification if the server is running. >=20 > I guess the following text is what makes the suggested method work: >=20 > 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. >=20 > 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... >=20 > Happy new year! > Bert >=20 >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > 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) >=20 > Hi Bert, >=20 > 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. >=20 > On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: >=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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? =20 > We most likely don't want an equivalent of CHARGEN, as this would be = inviting amplification attacks.) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_2ECA80C9-D049-41A9-89F9-E719C684B36B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLTCCBSkw ggQRoAMCAQICECmH/UgVhRC4KdUoO6m7mZYwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTIxMjE4MDAwMDAwWhcNMTMxMjE4MjM1OTU5WjAlMSMw IQYJKoZIhvcNAQkBFhRhbmRyZXdtY2dyQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMGLMaQLqrr4Po89Mh1wt0m0pBHonRc2JzB/FEppdssTQVlt12w/t4+2iKMA8met QZrFdNLqZ0N68gaVhD9qRcBT4cnW0FGVxTi1DQCeKrSQHQROKrAzTyw8OX62JL7a6sfTHwgz3F0/ lsGsyu+Dh9EZ27piLGqBVZ8ufEs2idE4kLF3lZvS484Xg7EdRrcnfKr08aW97UyO3l3N/60h+zcz ALCSByi3g8KVX9Op3YG1qqNdaCSIelZA/iW5hiH/0m+tyXkR/r7M+EnGgRHpY1w8mES4D91hy7Wg ORElyBlMJEMTsm3RH96lD9F5l5kt16t8ERCwiZEUUb5scha0K78CAwEAAaOCAeQwggHgMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQtolMDOCi9twAjlNp3fgY8034r vDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGFu ZHJld21jZ3JAZ21haWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCPgrUc/mtH5DglerEV71ytIHuX 8V+elGfHhDls0xEpR3OkL8F/OEWHyHEfYF5ebJZU5P2dpbJDIFB6Mw4VbX1T+Y6NQ4V3EcIQG2ZZ JH5lgazHWaaZm6CFVrPMICx5IU79S2OH0dnhuNG+Cru3hhyY9h4C4oiFAR2ws7ks+rSX5frzpeUy u8FHc2Bvw+kC2Mhj91WFcAqQ+JEI6tZ0Fm9ilK9eNwfFKAm9RwuscsXqzswILlFpIfqIXWouZEpU SxNweg0f2YlsrpYkBd5cK2JodudlAToZfeow5H5/TDd88Xv3zhTU/0gSO7/bK0OsI6ibNGo5nfpM ZrZKjkIeRBsJMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECECmH/UgVhRC4KdUoO6m7mZYwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMTA0MDM0NTQ2WjAjBgkqhkiG9w0BCQQxFgQU/+dzEiud n8zF7/JHFX9fGYsiiTIwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQQIQKYf9SBWFELgp1Sg7qbuZljCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECECmH/UgVhRC4KdUoO6m7mZYwDQYJKoZI hvcNAQEBBQAEggEAbwnUGluLYcsS2w+bwynGAb+5qJlV/RfXu8J3dVRGKckB7dC3AAb9cxtSif+R i6aEfczhU1KWKJ71gws3gVZx7YrbVxNAwFWgQIgpnep91Nu4iDCKb+d7Ozqe/ndTRyFQTliBurX2 e/f+AQj1Y3qRwmnYlUHULmhQ7kNlpSa9KLxyY7OvZCHVM5dMenjM9RZj5nOHTxzsAIFf8+dHX8vB oABQtdUvql4Bbaoy9WJNB1nfFjAkQpb70TXzhDSndqYEl2gpnvxtcPY1gMJWg4Q0k047Tby273Ms woTUO4MJtvAmQNxLHxsfSXpLedVbHJkJ2sTEx7tz0TGG52J3YBWyFwAAAAAAAA== --Apple-Mail=_2ECA80C9-D049-41A9-89F9-E719C684B36B-- From zach@sensinode.com Fri Jan 4 01:00:45 2013 Return-Path: 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 155DA21F8ECB for ; Fri, 4 Jan 2013 01:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 R0+tm0GBJ9Kf for ; Fri, 4 Jan 2013 01:00:44 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 027F521F8EBA for ; Fri, 4 Jan 2013 01:00:43 -0800 (PST) Received: from [10.128.8.206] (line-21396.dyn.kponet.fi [213.145.192.6]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r0490YMq022948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Jan 2013 11:00:35 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Zach Shelby In-Reply-To: <1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> Date: Fri, 4 Jan 2013 11:01:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <95879247-97BE-454B-A325-A34FFAB36F68@sensinode.com> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx> <1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> To: Andrew McGregor X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 09:00:45 -0000 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 = 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. >=20 > Andrew >=20 > On 4/01/2013, at 4:17 PM, Bert Greevenbosch = wrote: >=20 >> Hi Carsten, >>=20 >> I agree that we should not define a separate NOOP method just for = verification if the server is running. >>=20 >> I guess the following text is what makes the suggested method work: >>=20 >> 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. >>=20 >> 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... >>=20 >> Happy new year! >> Bert >>=20 >>=20 >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org]=20 >> 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) >>=20 >> Hi Bert, >>=20 >> 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. >>=20 >> On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: >>=20 >>> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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? =20 >> We most likely don't want an equivalent of CHARGEN, as this would be = inviting amplification attacks.) >>=20 >> Gr=FC=DFe, Carsten >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 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 From Bert.Greevenbosch@huawei.com Sun Jan 6 16:50:24 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: Zach Shelby , Andrew McGregor Thread-Topic: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN6i4INd/yvaWIEUK38pCVjm1hP5g4WZ4AgASzTXA= Date: Mon, 7 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" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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]=20 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 wrote: > Simply deleting the "and MUST NOT be empty" from the first sentence you q= uote would make it unambiguous that an empty message is allowed, and must b= e rejected. >=20 > Andrew >=20 > On 4/01/2013, at 4:17 PM, Bert Greevenbosch wrote: >=20 >> Hi Carsten, >>=20 >> I agree that we should not define a separate NOOP method just for verifi= cation if the server is running. >>=20 >> I guess the following text is what makes the suggested method work: >>=20 >> 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. >>=20 >> I don't feel too strong about this. It is just that the spec seems to en= dorse violating its own MUST NOTs. But that discussion might be more philos= ophical than it is technical... >>=20 >> Happy new year! >> Bert >>=20 >>=20 >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org]=20 >> 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) >>=20 >> Hi Bert, >>=20 >> 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. >>=20 >> On Dec 21, 2012, at 03:42, Bert Greevenbosch wrote: >>=20 >>> 1,E) p.9: "Provoking a Reset message (e.g., by sending an empty Confirm= able 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 em= pty CON messages. >>=20 >> We have found that it is very useful to have some lightweight "are you t= here" mechanism. >> This is both for diagnostics, and for address selection ahead of a heavy= -weight non-idempotent operation. >>=20 >> Now we could define a NOOP method that does nothing. In a Confirmable m= essage, 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. >>=20 >> However, the empty/RST exchange has essentially the same properties, wit= h 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 implementat= ion before ETSI CoAP2 caught the MUSTs that make it work. >>=20 >> One could argue that a ping that "works" should not end in an "error" me= ssage like RST. >> However, there are other cases where a RST is somewhat "normal", so seei= ng a RST should not be raising red alarms anyway. >>=20 >> So I agree a bit with the sentiment you are expressing, but I think it i= s 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? =20 >> We most likely don't want an equivalent of CHARGEN, as this would be inv= iting amplification attacks.) >>=20 >> Gr=FC=DFe, Carsten >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 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 From Bert.Greevenbosch@huawei.com Mon Jan 7 16:38:03 2013 Return-Path: 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 8CEA81F0CE4 for ; Mon, 7 Jan 2013 16:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 Cgidc5-6P41V for ; Mon, 7 Jan 2013 16:38:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 66C381F0C5F for ; Mon, 7 Jan 2013 16:38:02 -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 AON42542; Tue, 08 Jan 2013 00:38:01 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 Jan 2013 00:36:54 +0000 Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 Jan 2013 00:37:59 +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; Tue, 8 Jan 2013 08:37:56 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: BG8 -- NSTART=1 (Re: [core] draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN310BoGxoO+xYmkmhavkhVj4yrJg9p2PQ Date: Tue, 8 Jan 2013 00:37:52 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB2041B@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <980474C2-9E1D-4ADF-8BCF-A9D47F1A7D9A@tzi.org> In-Reply-To: <980474C2-9E1D-4ADF-8BCF-A9D47F1A7D9A@tzi.org> 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" Subject: Re: [core] BG8 -- NSTART=1 (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:38:03 -0000 Hi Carsten, Thank you for your explanation about NSTART. I see the requirement of limiting the amount of outstanding interactions as= a means for congestion control. I have also reviewed the history of NSTART and PROBING_RATE. Both were adde= d in coap-12 as a resolution to ticket #215. According to the Vancouver min= utes, the value NSTART=3D1 was proposed for devices that cannot estimate th= e RTT. It was also proposed to consider a higher value for devices that can= estimate the RTT. A problem with NSTART=3D1 may be a server that returns piggybacked response= s that need some processing time. For example, a server (or reverse proxy) = may provide two different resources, both of which are independent but requ= ire one second to collect their information. With NSTART=3D1, this would me= an that the client can only request the second resource after at least one = second, even when there is no congestion. I guess this issue also hangs together with the time threshold above which = the server should refrain from piggybacking. That, however, is explicitly l= eft out of scope of scope of the spec, see section 5.2.1. Fortunately the draft only defines a default values for NSTART and PROBING_= RATE, which can be overridden upon more extensive knowledge/experience of C= oAP congestion control. But, although the default values can be overridden,= the text about NSTART uses MUSTs and SHALLs, implying that each implementa= tion has to support them, requiring code for the book keeping. Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 21 December 2012 17:24 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: BG8 -- NSTART=3D1 (Re: [core] draft-ietf-core-coap-13 WGLC - my co= mments) On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 8,T) NSTART=3D1 implies that you cannot send a bulk of requests at once. = Is this the intention, Yes. > or would a small but higher value of NSTART still be acceptable? According to RFC 5405, no. However, this is qualified for a 3-second interval, so there may be some le= eway here. What happens is this: The first request goes out. If it is acknowledged, the counter limited by = NSTART (we need a name for that) goes back to 0 and we can send the second = request. If it isn't, we retransmit the first request after 2-3 seconds, so we conti= nue to use up the RFC 5405 limit. If the first retransmission of the first request is acknowledged, we can se= nd the second request. If not, we might be able to squeeze in a second request if we only want to = stick to the letter of RFC 5405. However, the point of BEBO is to actually slow down in the face of losses, = so this shouldn't be overdone. If we have to do this, it may be a good idea to operate the second request = on the BEBO schedule of the first request (i.e., stick to the maximum of th= e BEBO variables per peer). Of course, the 3 seconds of RFC 5405 were picked out of thin air at a time = when people weren't thinking that much about constrained networks. Maybe it actually is too low (i.e., too high a rate) for us! But, actually, clamping down NSTART to 1 if you know nothing about path or = peer is a *feature*. =20 The poor server receiving those requests has to process them. It may only = have one buffer. If a new request comes in before it had a chance to respond to the first on= e, it will essentially have to drop the packet (or trash the old request). (And similar considerations may apply to constrained routers on the way.) Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Mon Jan 7 17:11:52 2013 Return-Path: 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 DBE8E21F8506 for ; Mon, 7 Jan 2013 17:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 J8JTXFEkBZ9R for ; Mon, 7 Jan 2013 17:11:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98121F84FB for ; Mon, 7 Jan 2013 17:11:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANH12526; Tue, 08 Jan 2013 01:11:50 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 Jan 2013 01:10:03 +0000 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 Jan 2013 01:10:57 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.003; Tue, 8 Jan 2013 09:10:52 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN315iJ1Q/0+sXYEmo5E7r/F2NcJg9qGLQ Date: Tue, 8 Jan 2013 01:10:51 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB20446@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> In-Reply-To: <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> 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" Subject: Re: [core] BG7 -- PROBING_RATE (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 01:11:53 -0000 Hi Carsten, I have reviewed the NSTART and PROBING_RATE backgrounds together, but I tho= ught it's will be best to keep the threads separated. As mentioned in my other e-mail, I have reviewed the history of NSTART and = PROBING_RATE. Both entities were added in coap-12 as a resolution to ticket= #215. The ticket history indeed mentions NSTART, but I couldn't find anyth= ing about PROBING_RATE. The same holds for the minutes from the Vancouver m= eeting. How did PROBING_RATE come into being? I am still not convinced about PROBING_RATE, especially its dependence on t= he message size. Restricting (re)transmissions based on data size makes sen= se for applications such as streaming, where a lot of data is transmitted i= n subsequent RTP packets. In that case, the amount of data per time unit (t= hereby the amount of packets) could be restricted in order to reduce conges= tion. However, for CoAP, where we normally talk about a few messages (per c= lient/server pair) of limited size, I think it is more appropriate to put a= limit on the number of messages per time unit, than making it dependent on= the message size. How about setting a RECOMMENDED minimum time between subsequent outstanding= interactions, for example the 3s mentioned in RFC 5405? Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 21 December 2012 17:34 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my = comments) This may actually mainly be an editorial problem. On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 7,T) p.25: "Unless this is modified by additional congestion control opti= mizations, it MUST be chosen in such a way that an endpoint does not exceed= an average data rate of PROBING_RATE in sending to another endpoint that d= oes not respond." You are quoting this out of context. The context is: In order not to cause congestion, Clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). The default value of NSTART for this specification is 1. Now this is the text that explains how to handle non-responding peers: A client stops expecting a response to a Confirmable request for which no acknowledgment message was received, after EXCHANGE_LIFETIME. The specific algorithm by which a client stops to "expect" a response to a Confirmable request that was acknowledged, or to a Non-confirmable request, is not defined. Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending to another endpoint that does not respond. So: 1) If a Confirmable request times out, you reset the NSTART counter (for wh= ich we still need a name) to 0 after EXCHANGE_LIFETIME. 2) For Non-confirmables, we don't have a timeout. So we use PROBING_RATE t= o decay the NSTART counter. > p.26, in the table: "PROBING_RATE =3D 1 Byte/second". Yes, that is quite conservative. I had 7 bytes/second, but there was some = transport input that this might be too much. > p.21: "Retransmission is controlled by two things that a CoAP endpoint MU= ST keep track of for each Confirmable message it sends while waiting for an= acknowledgement (or reset): a timeout and a retransmission counter. For a = new Confirmable message, the initial timeout is set to a random counter bet= ween ACK_TIMEOUT and (ACK_TIMEOUT*ACK_RANDOM_FACTOR) (see Section 4.8), and= the retransmission counter is set to 0. When the timeout is triggered and = the retransmission counter is less than MAX_RETRANSMIT, the message is retr= ansmitted, the retransmission counter is incremented, and the timeout is do= ubled. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, o= r if the endpoint receives a Reset message, then the attempt to transmit th= e message is canceled and the application process informed of failure." Well, this is unrelated; none of this is controlled by PROBING_RATE. > It seems that PROBING_RATE is another constraint on top of what is define= d on p.21, since the algorithm of p.21 alone would already violate the prob= ing rate, especially at the beginning of the retransmissions. This is the editorial issue: We need to make clear that these two don't int= eract. > Is 1 Byte/second reasonable? Does it mean that a 16 byte CoAP message nee= ds at least 16 seconds between two subsequent retransmissions? Over which t= ime frame is the PROBING_RATE calculated? Actually, there is a need for another clarification: The usage of PROBING_R= ATE needs to account for overhead. So, for a 16 byte CoAP message, you wou= ld account 16+8+40 =3D 64 bytes (IPv6), so, the next one goes out only afte= r 64 seconds or when the response is received, whatever comes earlier. > Suggestion: remove PROBING_RATE. PROBING_RATE is needed to keep some control over Non-confirmables. I don't= think we can take that away. If you never send a Non-confirmable, you can ignore PROBING_RATE. Gr=FC=DFe, Carsten From esko.dijk@philips.com Tue Jan 8 00:18:15 2013 Return-Path: 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 B160721F8517 for ; Tue, 8 Jan 2013 00:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 GIq-G9use6UD for ; Tue, 8 Jan 2013 00:18:14 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 70D3421F8514 for ; Tue, 8 Jan 2013 00:18:12 -0800 (PST) Received: from mail30-co1-R.bigfish.com (10.243.78.219) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Tue, 8 Jan 2013 08:18:12 +0000 Received: from mail30-co1 (localhost [127.0.0.1]) by mail30-co1-R.bigfish.com (Postfix) with ESMTP id 68D58740108; Tue, 8 Jan 2013 08:18:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zz217bI98dI15d6O9251Jc89bhd6eah542Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail30-co1 (localhost.localdomain [127.0.0.1]) by mail30-co1 (MessageSwitch) id 1357633089993176_30863; Tue, 8 Jan 2013 08:18:09 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.215]) by mail30-co1.bigfish.com (Postfix) with ESMTP id F020E900152; Tue, 8 Jan 2013 08:18:09 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 8 Jan 2013 08:18:09 +0000 Received: from 011-DB3MMR1-015.MGDPHG.emi.philips.com (10.128.28.99) by 011-DB3MMR1-002.MGDPHG.emi.philips.com (10.128.28.52) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 8 Jan 2013 08:18:07 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.34]) by 011-DB3MMR1-015.MGDPHG.emi.philips.com ([10.128.28.99]) with mapi id 14.02.0318.003; Tue, 8 Jan 2013 08:18:07 +0000 From: "Dijk, Esko" To: Bert Greevenbosch , Carsten Bormann Thread-Topic: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN7T0soRixYQAWQkaCYvN2QryWEZg/EYpw Date: Tue, 8 Jan 2013 08:18:06 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B4D7FA@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB20446@szxeml509-mbx> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB20446@szxeml509-mbx> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.140.132.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org WG" Subject: Re: [core] BG7 -- PROBING_RATE (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 08:18:15 -0000 Hi Bert, Carsten, > I have reviewed the history of NSTART and PROBING_RATE. Both entities wer= e added in coap-12 as a resolution to ticket #215. > The ticket history indeed mentions NSTART, but I couldn't find anything a= bout PROBING_RATE. The same holds for the minutes > from the Vancouver meeting. How did PROBING_RATE come into being? same question from me. I did not see PROBING_RATE mentioned in the ticket c= omments or elsewhere. Based on Ticket #215 alone it would not be needed, or= do I miss something...? Three more comments on PROBING_RATE: 1. the PROBING_RATE mechanism text is currently written with unicast in min= d. We should perhaps also indicate how CoAP multicast should handle it, e.g. c= larify that a client can resend a multicast NON request (resending meaning = the same Message ID) after receiving the first response from any server. 2. agree with Bert that the dependency on IPv6/6LoWPAN packet size seems un= fortunate, because the CoAP stack typically wouldn't be able to compute tha= t size. How would that work? I can imagine that doing this computation base= d on expected average or 'worst case' IPv6 header sizes for the given syste= m configuration is more feasible then. 3. the 1Byte/second default limit seems on the low side? (suitable for 20th= century technology ;) ) some discussion or clarification/justification for this value would help. E= .g. why is CON allowed to send much more bytes per second than NON. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ber= t Greevenbosch Sent: Tuesday 8 January 2013 2:11 To: Carsten Bormann Cc: core@ietf.org WG Subject: Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC -= my comments) Hi Carsten, I have reviewed the NSTART and PROBING_RATE backgrounds together, but I tho= ught it's will be best to keep the threads separated. As mentioned in my other e-mail, I have reviewed the history of NSTART and = PROBING_RATE. Both entities were added in coap-12 as a resolution to ticket= #215. The ticket history indeed mentions NSTART, but I couldn't find anyth= ing about PROBING_RATE. The same holds for the minutes from the Vancouver m= eeting. How did PROBING_RATE come into being? I am still not convinced about PROBING_RATE, especially its dependence on t= he message size. Restricting (re)transmissions based on data size makes sen= se for applications such as streaming, where a lot of data is transmitted i= n subsequent RTP packets. In that case, the amount of data per time unit (t= hereby the amount of packets) could be restricted in order to reduce conges= tion. However, for CoAP, where we normally talk about a few messages (per c= lient/server pair) of limited size, I think it is more appropriate to put a= limit on the number of messages per time unit, than making it dependent on= the message size. How about setting a RECOMMENDED minimum time between subsequent outstanding= interactions, for example the 3s mentioned in RFC 5405? Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: 21 December 2012 17:34 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my = comments) This may actually mainly be an editorial problem. On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 7,T) p.25: "Unless this is modified by additional congestion control opti= mizations, it MUST be chosen in such a way that an endpoint does not exceed= an average data rate of PROBING_RATE in sending to another endpoint that d= oes not respond." You are quoting this out of context. The context is: In order not to cause congestion, Clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). The default value of NSTART for this specification is 1. Now this is the text that explains how to handle non-responding peers: A client stops expecting a response to a Confirmable request for which no acknowledgment message was received, after EXCHANGE_LIFETIME. The specific algorithm by which a client stops to "expect" a response to a Confirmable request that was acknowledged, or to a Non-confirmable request, is not defined. Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending to another endpoint that does not respond. So: 1) If a Confirmable request times out, you reset the NSTART counter (for wh= ich we still need a name) to 0 after EXCHANGE_LIFETIME. 2) For Non-confirmables, we don't have a timeout. So we use PROBING_RATE t= o decay the NSTART counter. > p.26, in the table: "PROBING_RATE =3D 1 Byte/second". Yes, that is quite conservative. I had 7 bytes/second, but there was some = transport input that this might be too much. > p.21: "Retransmission is controlled by two things that a CoAP endpoint MU= ST keep track of for each Confirmable message it sends while waiting for an= acknowledgement (or reset): a timeout and a retransmission counter. For a = new Confirmable message, the initial timeout is set to a random counter bet= ween ACK_TIMEOUT and (ACK_TIMEOUT*ACK_RANDOM_FACTOR) (see Section 4.8), and= the retransmission counter is set to 0. When the timeout is triggered and = the retransmission counter is less than MAX_RETRANSMIT, the message is retr= ansmitted, the retransmission counter is incremented, and the timeout is do= ubled. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, o= r if the endpoint receives a Reset message, then the attempt to transmit th= e message is canceled and the application process informed of failure." Well, this is unrelated; none of this is controlled by PROBING_RATE. > It seems that PROBING_RATE is another constraint on top of what is define= d on p.21, since the algorithm of p.21 alone would already violate the prob= ing rate, especially at the beginning of the retransmissions. This is the editorial issue: We need to make clear that these two don't int= eract. > Is 1 Byte/second reasonable? Does it mean that a 16 byte CoAP message nee= ds at least 16 seconds between two subsequent retransmissions? Over which t= ime frame is the PROBING_RATE calculated? Actually, there is a need for another clarification: The usage of PROBING_R= ATE needs to account for overhead. So, for a 16 byte CoAP message, you wou= ld account 16+8+40 =3D 64 bytes (IPv6), so, the next one goes out only afte= r 64 seconds or when the response is received, whatever comes earlier. > Suggestion: remove PROBING_RATE. PROBING_RATE is needed to keep some control over Non-confirmables. I don't= think we can take that away. If you never send a Non-confirmable, you can ignore PROBING_RATE. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Tue Jan 8 00:24:17 2013 Return-Path: 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 1BE2E21F8833 for ; Tue, 8 Jan 2013 00:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jll-nmKfni34 for ; Tue, 8 Jan 2013 00:24:15 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8B44A21F8838 for ; Tue, 8 Jan 2013 00:24:09 -0800 (PST) Received: from mail180-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Tue, 8 Jan 2013 08:23:52 +0000 Received: from mail180-ch1 (localhost [127.0.0.1]) by mail180-ch1-R.bigfish.com (Postfix) with ESMTP id 8CD0E4002AC; Tue, 8 Jan 2013 08:23:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zz217bI98dI15d6O9251Jc89bhd6eah542Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail180-ch1 (localhost.localdomain [127.0.0.1]) by mail180-ch1 (MessageSwitch) id 1357633430812628_29858; Tue, 8 Jan 2013 08:23:50 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail180-ch1.bigfish.com (Postfix) with ESMTP id C34DF2C0064; Tue, 8 Jan 2013 08:23:50 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 8 Jan 2013 08:23:50 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.34]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.02.0318.003; Tue, 8 Jan 2013 08:23:32 +0000 From: "Dijk, Esko" To: Bert Greevenbosch , Carsten Bormann Thread-Topic: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN5BSm6L5ZR+tmwUWK7GuQ1NWbFpg+LuVA Date: Tue, 8 Jan 2013 08:23:32 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B4D812@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1D925@szxeml509-mbx> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D925@szxeml509-mbx> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.140.132.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org WG" Subject: Re: [core] BG7 -- PROBING_RATE (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 08:24:17 -0000 Hi Bert, > So only a new message (with a new message ID) needs to observe the probin= g rate? I would say no, particularly a resent NON message needs to heed the probing= rate. > ...for which no ACK or response is received... You probably mean 'response' here, as ACKs are only used with CON? > ... However, resending *the same* message (as part of the CON resend mech= anism)... Also with NON, messages can be resent. E.g. useful for multicast requests f= or additional reliability. The CON resend mechanism is probably not relevan= t for this discussion based on Carsten's last remark ("... you can ignore P= ROBING_RATE."). Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ber= t Greevenbosch Sent: Thursday 27 December 2012 10:28 To: Carsten Bormann Cc: core@ietf.org WG Subject: Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC -= my comments) Hi Carsten, Thank you for your many answers to my comments. I believe to understand that you mean, that the probing rate does not apply= to messages that are resent as part as the CON resend mechanism. So only a= new message (with a new message ID) needs to observe the probing rate? What I mean is, when we send a 64 byte message, we need at least 64*PROBING= _RATE =3D 64 seconds between sending two messages *with different message i= ds*, for which no ACK or response is received? However, resending *the same= * message (as part of the CON resend mechanism) within this time is OK? Why is the probing rate dependent on the message size? Can't we just set a = fixed value for all messages? Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: 21 December 2012 17:34 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my = comments) This may actually mainly be an editorial problem. On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 7,T) p.25: "Unless this is modified by additional congestion control opti= mizations, it MUST be chosen in such a way that an endpoint does not exceed= an average data rate of PROBING_RATE in sending to another endpoint that d= oes not respond." You are quoting this out of context. The context is: In order not to cause congestion, Clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). The default value of NSTART for this specification is 1. Now this is the text that explains how to handle non-responding peers: A client stops expecting a response to a Confirmable request for which no acknowledgment message was received, after EXCHANGE_LIFETIME. The specific algorithm by which a client stops to "expect" a response to a Confirmable request that was acknowledged, or to a Non-confirmable request, is not defined. Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending to another endpoint that does not respond. So: 1) If a Confirmable request times out, you reset the NSTART counter (for wh= ich we still need a name) to 0 after EXCHANGE_LIFETIME. 2) For Non-confirmables, we don't have a timeout. So we use PROBING_RATE t= o decay the NSTART counter. > p.26, in the table: "PROBING_RATE =3D 1 Byte/second". Yes, that is quite conservative. I had 7 bytes/second, but there was some = transport input that this might be too much. > p.21: "Retransmission is controlled by two things that a CoAP endpoint MU= ST keep track of for each Confirmable message it sends while waiting for an= acknowledgement (or reset): a timeout and a retransmission counter. For a = new Confirmable message, the initial timeout is set to a random counter bet= ween ACK_TIMEOUT and (ACK_TIMEOUT*ACK_RANDOM_FACTOR) (see Section 4.8), and= the retransmission counter is set to 0. When the timeout is triggered and = the retransmission counter is less than MAX_RETRANSMIT, the message is retr= ansmitted, the retransmission counter is incremented, and the timeout is do= ubled. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, o= r if the endpoint receives a Reset message, then the attempt to transmit th= e message is canceled and the application process informed of failure." Well, this is unrelated; none of this is controlled by PROBING_RATE. > It seems that PROBING_RATE is another constraint on top of what is define= d on p.21, since the algorithm of p.21 alone would already violate the prob= ing rate, especially at the beginning of the retransmissions. This is the editorial issue: We need to make clear that these two don't int= eract. > Is 1 Byte/second reasonable? Does it mean that a 16 byte CoAP message nee= ds at least 16 seconds between two subsequent retransmissions? Over which t= ime frame is the PROBING_RATE calculated? Actually, there is a need for another clarification: The usage of PROBING_R= ATE needs to account for overhead. So, for a 16 byte CoAP message, you wou= ld account 16+8+40 =3D 64 bytes (IPv6), so, the next one goes out only afte= r 64 seconds or when the response is received, whatever comes earlier. > Suggestion: remove PROBING_RATE. PROBING_RATE is needed to keep some control over Non-confirmables. I don't= think we can take that away. If you never send a Non-confirmable, you can ignore PROBING_RATE. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Tue Jan 8 14:01:38 2013 Return-Path: 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 9138411E80AE for ; Tue, 8 Jan 2013 14:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 moeACqfWB4oG for ; Tue, 8 Jan 2013 14:01:37 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 57F8521F84F3 for ; Tue, 8 Jan 2013 14:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r08M1NLm023271; Tue, 8 Jan 2013 23:01:23 +0100 (CET) Received: from [192.168.217.105] (p54892470.dip.t-dialin.net [84.137.36.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C47D6131; Tue, 8 Jan 2013 23:01:22 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D925@szxeml509-mbx> Date: Tue, 8 Jan 2013 23:01:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1D925@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] BG7 -- PROBING_RATE (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 22:01:38 -0000 Hi Bert, I'm sorry for being so behind in my E-Mail. Let me try to respond to the messages in this thread separately. On Dec 27, 2012, at 10:28, Bert Greevenbosch = wrote: > I believe to understand that you mean, that the probing rate does not = apply to messages that are resent as part as the CON resend mechanism. = So only a new message (with a new message ID) needs to observe the = probing rate? Actually, PROBING_RATE was intended entirely about striking from the = books those messages that are not benefitting from any ACK or response. Without PROBING_RATE, you would never be able to send, e.g., another NON = request if the first one gets lost. It seems that the current text is not expressing this area of = application very well. It says "The specific algorithm by which a client stops to "expect" a response to a Confirmable request that was acknowledged, or to a Non-confirmable request, is not defined." PROBING_RATE doesn't govern anything else, including Confirmable = requests that weren't acknowledged at all! > What I mean is, when we send a 64 byte message, we need at least = 64*PROBING_RATE =3D 64 seconds between sending two messages *with = different message ids*, for which no ACK or response is received? = However, resending *the same* message (as part of the CON resend = mechanism) within this time is OK? Yes to the latter. No to the former if this is about CON -- the waiting = for ACKs is supposed to take care of the rate-limiting. (It still doesn't hurt to slow down probing if nothing is coming back at = all. But the intention was not to govern that case by PROBING_RATE.) > Why is the probing rate dependent on the message size? Can't we just = set a fixed value for all messages? We could, but then we'd have to assume large messages and would have a = very low message rate. Since messages in CoAP are more likely to be small, that would limit us = more than necessary. (An implementation might still want to choose that behavior, if that is = convenient.) Gr=FC=DFe, Carsten From cabo@tzi.org Tue Jan 8 14:08:56 2013 Return-Path: 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 9407F1F0CFB for ; Tue, 8 Jan 2013 14:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KSu4B5-hvMwy for ; Tue, 8 Jan 2013 14:08:56 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AC6E41F0CFA for ; Tue, 8 Jan 2013 14:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r08M8j0i025937; Tue, 8 Jan 2013 23:08:45 +0100 (CET) Received: from [192.168.217.105] (p54892470.dip.t-dialin.net [84.137.36.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 459C3134; Tue, 8 Jan 2013 23:08:45 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB20446@szxeml509-mbx> Date: Tue, 8 Jan 2013 23:08:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB20446@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] BG7 -- PROBING_RATE (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 22:08:56 -0000 On Jan 8, 2013, at 02:10, Bert Greevenbosch = wrote: > Hi Carsten, >=20 > I have reviewed the NSTART and PROBING_RATE backgrounds together, but = I thought it's will be best to keep the threads separated. >=20 > As mentioned in my other e-mail, I have reviewed the history of NSTART = and PROBING_RATE. Both entities were added in coap-12 as a resolution to = ticket #215. The ticket history indeed mentions NSTART, but I couldn't = find anything about PROBING_RATE. The same holds for the minutes from = the Vancouver meeting. How did PROBING_RATE come into being? There must be something slowing down unresponded NONs. PROBING_RATE was = meant for this. I seem to remember proposing a PROBING_RATE of 7 B/s in Vancouver, only = to be bid down to 1 B/s by people in the room. > I am still not convinced about PROBING_RATE, especially its dependence = on the message size. Restricting (re)transmissions based on data size = makes sense for applications such as streaming, where a lot of data is = transmitted in subsequent RTP packets. In that case, the amount of data = per time unit (thereby the amount of packets) could be restricted in = order to reduce congestion. However, for CoAP, where we normally talk = about a few messages (per client/server pair) of limited size, I think = it is more appropriate to put a limit on the number of messages per time = unit, than making it dependent on the message size. If you know your maximum message size, you can easily implement it this = way by translating 1 B/s to, say, 0.01 message/s for 100-byte-max = messages. > How about setting a RECOMMENDED minimum time between subsequent = outstanding interactions, for example the 3s mentioned in RFC 5405? Well, RFC 5405 mentions | SHOULD measure RTT and transmit max. 1 datagram/RTT | | | else, SHOULD send at most 1 datagram every 3 seconds | | | SHOULD back-off retransmission timers following loss | | which I take to mean stubbornly sending a packet every 3 s is not within = the spirit of RFC 5405. More importantly, a room full of sensors that all stubbornly send a = packet every 3 s is a recipe for congestion collapse, independent of = what RFC 5405 suggests or not (this brings up Lars' scenario of having = to chisel the sensors out of the wall to end the congestion collapse). = So we need to find a way to slow down in case of no response, much = beyond the 3 s default. The current text tries to keep a lot of leeway = for how to implement this. 1 B/s is a reasonably conservative way to = approach this Gr=FC=DFe, Carsten From cabo@tzi.org Tue Jan 8 14:22:20 2013 Return-Path: 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 B64D121F84E2 for ; Tue, 8 Jan 2013 14:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 e45MOjrJOhAU for ; Tue, 8 Jan 2013 14:22:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E096F21F84E0 for ; Tue, 8 Jan 2013 14:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r08MM8kv002986; Tue, 8 Jan 2013 23:22:08 +0100 (CET) Received: from [192.168.217.105] (p54892470.dip.t-dialin.net [84.137.36.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6EAEE13C; Tue, 8 Jan 2013 23:22:08 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B4D7FA@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Tue, 8 Jan 2013 23:22:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <642D3858-4AF5-49EA-A9AF-3C4FDA1E05F1@tzi.org> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB20446@szxeml509-mbx> <031DD135F9160444ABBE3B0C36CED618B4D7FA@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] BG7 -- PROBING_RATE (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 22:22:20 -0000 On Jan 8, 2013, at 09:18, "Dijk, Esko" wrote: > Hi Bert, Carsten, >=20 >> I have reviewed the history of NSTART and PROBING_RATE. Both entities = were added in coap-12 as a resolution to ticket #215. >> The ticket history indeed mentions NSTART, but I couldn't find = anything about PROBING_RATE. The same holds for the minutes >> from the Vancouver meeting. How did PROBING_RATE come into being? > same question from me. I did not see PROBING_RATE mentioned in the = ticket comments or elsewhere. Based on Ticket #215 alone it would not be = needed, or do I miss something...? I hope I motivated this in the previous message. > Three more comments on PROBING_RATE: > 1. the PROBING_RATE mechanism text is currently written with unicast = in mind. > We should perhaps also indicate how CoAP multicast should handle it, = e.g. clarify that a client can resend a multicast NON request (resending = meaning the same Message ID) after receiving the first response from any = server. Those messages don't fall under the case of PROBING_RATE, right? > 2. agree with Bert that the dependency on IPv6/6LoWPAN packet size = seems unfortunate, because the CoAP stack typically wouldn't be able to = compute that size. How would that work? I can imagine that doing this = computation based on expected average or 'worst case' IPv6 header sizes = for the given system configuration is more feasible then. If you can't compute (or guesstimate) it, use an overhead of 64 B. This = is going to be close enough. If you know better, you can send faster. Should we add this approach to the text? I think we are moving into = implementation approaches here... > 3. the 1Byte/second default limit seems on the low side? (suitable for = 20th century technology ;) ) > some discussion or clarification/justification for this value would = help. E.g. why is CON allowed to send much more bytes per second than = NON. Good question. I came into this with a proposal for 7 B/s... CON can send 5 messages in TRANSMIT_WAIT, i.e. 62 to 93 s -- let's = assume the randomness mostly works here. Yes, these could be ~ 1280 bytes (for PUT, POST, or on the way back for = a large GET response that consistently gets lost), so if you = persistently retry right after the final timeout, the max average rate = is about 1280*5/77.5 ~ 80 B/s. Don't do that! (We could extend PROBING_RATE to cover this case, but this would go into = the wrong direction complexity-wise.) But the complexity of PROBING_RATE doesn't change by giving it a = different value. Gr=FC=DFe, Carsten From esko.dijk@philips.com Wed Jan 9 00:54:12 2013 Return-Path: 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 D08C021F874C for ; Wed, 9 Jan 2013 00:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rHT6hzy2Hj2z for ; Wed, 9 Jan 2013 00:54:11 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 55AD521F8653 for ; Wed, 9 Jan 2013 00:54:09 -0800 (PST) Received: from mail68-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Wed, 9 Jan 2013 08:54:08 +0000 Received: from mail68-ch1 (localhost [127.0.0.1]) by mail68-ch1-R.bigfish.com (Postfix) with ESMTP id E9C2E3E0231; Wed, 9 Jan 2013 08:54:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(zzbb2dI217bI98dI15d6O9251Jc89bhd6eah542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail68-ch1 (localhost.localdomain [127.0.0.1]) by mail68-ch1 (MessageSwitch) id 1357721645733271_21466; Wed, 9 Jan 2013 08:54:05 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail68-ch1.bigfish.com (Postfix) with ESMTP id A6316C00D3; Wed, 9 Jan 2013 08:54:05 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 9 Jan 2013 08:54:05 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.34]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.02.0318.003; Wed, 9 Jan 2013 08:53:58 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN7T0soRixYQAWQkaCYvN2QryWEZg/EYpwgADxK4CAAKrpYA== Date: Wed, 9 Jan 2013 08:53:57 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B4E45A@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB20446@szxeml509-mbx> <031DD135F9160444ABBE3B0C36CED618B4D7FA@011-DB3MPN2-083.MGDPHG.emi.philips.com> <642D3858-4AF5-49EA-A9AF-3C4FDA1E05F1@tzi.org> In-Reply-To: <642D3858-4AF5-49EA-A9AF-3C4FDA1E05F1@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org WG" Subject: Re: [core] BG7 -- PROBING_RATE (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 08:54:13 -0000 > I hope I motivated this in the previous message. Yes, thanks. > Those messages don't fall under the case of PROBING_RATE, right? Do you mean multicast in general, or resent multicast requests (i.e. with t= he same Message ID) ? The motivation "There must be something slowing down unresponded NONs" can = be made a bit more precise then: e.g. it applies only to unicast NONs for w= hich response is always expected to come. (Assuming multicast is excluded) > If you can't compute (or guesstimate) it, use an overhead of 64 B. This = is going to be close enough. Ok, the MUST requirement can be met by using an upper bound for the header = overhead. If guesstimates (of expected avg header overhead) can also be use= d, perhaps the text should indicate this. > CON can send 5 messages in TRANSMIT_WAIT, ... > ... these could be ~ 1280 bytes So an upper bound for PROBING_RATE would be 80 B/s to be equal to the CON c= ase on 'unconstrained' networks. Then for 6LoWPAN 802.15.4 networks, assuming an IPv6 packet size of about 8= 0-120B, PROBING_RATE would be 5-8 B/s. So the value 8 would seem more logic= al to me; but I missed the discussion details from the meeting. Agree that adjusting PROBING_RATE is the least complex solution to improve/= optimize throughput. Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday 8 January 2013 23:22 To: Dijk, Esko Cc: Bert Greevenbosch; core@ietf.org WG Subject: Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC -= my comments) On Jan 8, 2013, at 09:18, "Dijk, Esko" wrote: > Hi Bert, Carsten, > >> I have reviewed the history of NSTART and PROBING_RATE. Both entities we= re added in coap-12 as a resolution to ticket #215. >> The ticket history indeed mentions NSTART, but I couldn't find >> anything about PROBING_RATE. The same holds for the minutes from the Van= couver meeting. How did PROBING_RATE come into being? > same question from me. I did not see PROBING_RATE mentioned in the ticket= comments or elsewhere. Based on Ticket #215 alone it would not be needed, = or do I miss something...? I hope I motivated this in the previous message. > Three more comments on PROBING_RATE: > 1. the PROBING_RATE mechanism text is currently written with unicast in m= ind. > We should perhaps also indicate how CoAP multicast should handle it, e.g.= clarify that a client can resend a multicast NON request (resending meanin= g the same Message ID) after receiving the first response from any server. Those messages don't fall under the case of PROBING_RATE, right? > 2. agree with Bert that the dependency on IPv6/6LoWPAN packet size seems = unfortunate, because the CoAP stack typically wouldn't be able to compute t= hat size. How would that work? I can imagine that doing this computation ba= sed on expected average or 'worst case' IPv6 header sizes for the given sys= tem configuration is more feasible then. If you can't compute (or guesstimate) it, use an overhead of 64 B. This is= going to be close enough. If you know better, you can send faster. Should we add this approach to the text? I think we are moving into implem= entation approaches here... > 3. the 1Byte/second default limit seems on the low side? (suitable for > 20th century technology ;) ) some discussion or clarification/justificati= on for this value would help. E.g. why is CON allowed to send much more byt= es per second than NON. Good question. I came into this with a proposal for 7 B/s... CON can send 5 messages in TRANSMIT_WAIT, i.e. 62 to 93 s -- let's assume t= he randomness mostly works here. Yes, these could be ~ 1280 bytes (for PUT, POST, or on the way back for a l= arge GET response that consistently gets lost), so if you persistently retr= y right after the final timeout, the max average rate is about 1280*5/77.5 = ~ 80 B/s. Don't do that! (We could extend PROBING_RATE to cover this case, but this would go into th= e wrong direction complexity-wise.) But the complexity of PROBING_RATE doesn't change by giving it a different = value. Gr=FC=DFe, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Wed Jan 9 12:43:36 2013 Return-Path: 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 BDEC411E80B8 for ; Wed, 9 Jan 2013 12:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 AJJXolF2gCGb for ; Wed, 9 Jan 2013 12:43:36 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AE9EA11E80AD for ; Wed, 9 Jan 2013 12:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r09KhN4n008124; Wed, 9 Jan 2013 21:43:23 +0100 (CET) Received: from [192.168.217.108] (p5489266F.dip.t-dialin.net [84.137.38.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4F79C775; Wed, 9 Jan 2013 21:43:23 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> Date: Wed, 9 Jan 2013 21:43:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx> <1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> To: Andrew McGregor X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:43:37 -0000 On Jan 4, 2013, at 04:45, Andrew McGregor 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. In [1152], I'm proposing a slightly different approach: Since the "always carries either a request or response" also is not true = in the CoAP ping case, it is probably better to qualify the whole = sentence: message as Confirmable in the CoAP header. A Confirmable = message - always carries either a request or response and MUST NOT be = empty. A + always carries either a request or response and MUST NOT be + empty, unless it is used only to elicit a Reset message. 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 I hope this completely resolves this. Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Wed Jan 9 13:44:52 2013 Return-Path: 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 79FC421F884A for ; Wed, 9 Jan 2013 13:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 QBuscoXiHEi5 for ; Wed, 9 Jan 2013 13:44:52 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id C08F421F8849 for ; Wed, 9 Jan 2013 13:44:51 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jan 2013 16:44:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jan 2013 16:44:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) Thread-Index: Ac3uqgRgIR4qbLAmQMOKJGlQneE+qwABuvgQ References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx><42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org><46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx><1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> From: "Rahman, Akbar" To: "Carsten Bormann" , "Zach Shelby" X-OriginalArrivalTime: 09 Jan 2013 21:44:50.0506 (UTC) FILETIME=[8D412AA0:01CDEEB2] Cc: core@ietf.org Subject: [core] Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 21:44:52 -0000 Hi Carsten/Zach, I have a clarification question on Appendix B (URI Examples) of coap-13: - For examples 2-4, what is the purpose of listing the "Destination IP Address" and "Destination UDP Port"? - That is, for these examples, the URI is constructed without any reference to the IP Address and UDP Port. So it is confusing. =20 - Of course, for the 1st and 5th examples having the IP Address and UDP Port makes perfect sense as they are used in the example URI construction. Or did I somehow misunderstand the examples? Akbar From hartke@tzi.org Wed Jan 9 14:06:42 2013 Return-Path: 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 1291E21F85CB for ; Wed, 9 Jan 2013 14:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.027 X-Spam-Level: X-Spam-Status: No, score=-5.027 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, 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 QTlF3YRmWhdg for ; Wed, 9 Jan 2013 14:06:41 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 14A2B21F85BC for ; Wed, 9 Jan 2013 14:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r09M6XMH013929 for ; Wed, 9 Jan 2013 23:06:33 +0100 (CET) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 245047A1 for ; Wed, 9 Jan 2013 23:06:33 +0100 (CET) Received: by mail-la0-f54.google.com with SMTP id fp12so2441499lab.13 for ; Wed, 09 Jan 2013 14:06:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.108.172 with SMTP id hl12mr66336765lab.32.1357769192663; Wed, 09 Jan 2013 14:06:32 -0800 (PST) Received: by 10.112.95.166 with HTTP; Wed, 9 Jan 2013 14:06:32 -0800 (PST) In-Reply-To: References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx> <1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> Date: Thu, 10 Jan 2013 00:06:32 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 22:06:42 -0000 Hi Akbar, Akbar Rahman wrote: > I have a clarification question on Appendix B (URI Examples) of coap-13: > > - For examples 2-4, what is the purpose of listing the "Destination IP > Address" and "Destination UDP Port"? > > - That is, for these examples, the URI is constructed without any > reference to the IP Address and UDP Port. So it is confusing. > > - Of course, for the 1st and 5th examples having the IP Address and UDP > Port makes perfect sense as they are used in the example URI > construction. Appendix B shows examples for the algorithm specified in Section 6.5. Section 6.5 refers to the destination IP address and port in step 2 and 4 respectively. But not all paths of the algorithm cause the destination IP address and port to be included in the URI result. 2. ... If the request does not include a Uri-Host Option, let /host/ be the IP-literal (making use of the conventions of [RFC5952]) or IPv4address representing the request's destination IP address. 4. If the request includes a Uri-Port Option, let /port/ be that option's value. Otherwise, let /port/ be the request's destination UDP port. Although the intro of Appendix B says that the examples are for constructing an URI from options, the examples also work for Section 6.4 + DNS resolution. Then the input is the URI and the outputs are the options and the destination IP address and port for the request. Best regards, Klaus From Akbar.Rahman@InterDigital.com Wed Jan 9 14:12:51 2013 Return-Path: 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 305C621F872E for ; Wed, 9 Jan 2013 14:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] 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 JNS4SkFaT-Zn for ; Wed, 9 Jan 2013 14:12:50 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4159021F871E for ; Wed, 9 Jan 2013 14:12:43 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jan 2013 17:12:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jan 2013 17:12:41 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) Thread-Index: Ac3utaR9VOECaZZ6SXSFOJ75LCn5EwAAEaLQ References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx><42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org><46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx><1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> From: "Rahman, Akbar" To: "Klaus Hartke" X-OriginalArrivalTime: 09 Jan 2013 22:12:42.0186 (UTC) FILETIME=[71A74AA0:01CDEEB6] Cc: core@ietf.org Subject: Re: [core] Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 22:12:51 -0000 Hi Klaus, Thanks for the explanation, and it makes sense now. But also I think you have to add a better intro for Appendix B or the next reader (not subscribed to this list) will have the same issue as I did. Do you agree? /Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Klaus Hartke Sent: Wednesday, January 09, 2013 5:07 PM To: core@ietf.org Subject: Re: [core] Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) Hi Akbar, Akbar Rahman wrote: > I have a clarification question on Appendix B (URI Examples) of coap-13: > > - For examples 2-4, what is the purpose of listing the "Destination IP > Address" and "Destination UDP Port"? > > - That is, for these examples, the URI is constructed without any > reference to the IP Address and UDP Port. So it is confusing. > > - Of course, for the 1st and 5th examples having the IP Address and UDP > Port makes perfect sense as they are used in the example URI > construction. Appendix B shows examples for the algorithm specified in Section 6.5. Section 6.5 refers to the destination IP address and port in step 2 and 4 respectively. But not all paths of the algorithm cause the destination IP address and port to be included in the URI result. 2. ... If the request does not include a Uri-Host Option, let /host/ be the IP-literal (making use of the conventions of [RFC5952]) or IPv4address representing the request's destination IP address. 4. If the request includes a Uri-Port Option, let /port/ be that option's value. Otherwise, let /port/ be the request's destination UDP port. Although the intro of Appendix B says that the examples are for constructing an URI from options, the examples also work for Section 6.4 + DNS resolution. Then the input is the URI and the outputs are the options and the destination IP address and port for the request. Best regards, Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Wed Jan 9 14:19:49 2013 Return-Path: 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 902F721F870A for ; Wed, 9 Jan 2013 14:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.327 X-Spam-Level: X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 j7dIOfuOCaj0 for ; Wed, 9 Jan 2013 14:19:49 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A741F21F86AE for ; Wed, 9 Jan 2013 14:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r09MJfS2019451 for ; Wed, 9 Jan 2013 23:19:41 +0100 (CET) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 447397A9 for ; Wed, 9 Jan 2013 23:19:41 +0100 (CET) Received: by mail-la0-f54.google.com with SMTP id fp12so2452503lab.13 for ; Wed, 09 Jan 2013 14:19:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.144.103 with SMTP id sl7mr17683099lab.23.1357769980818; Wed, 09 Jan 2013 14:19:40 -0800 (PST) Received: by 10.112.95.166 with HTTP; Wed, 9 Jan 2013 14:19:40 -0800 (PST) In-Reply-To: References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx> <1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> Date: Thu, 10 Jan 2013 00:19:40 +0200 Message-ID: From: Klaus Hartke To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 22:19:49 -0000 Akbar Rahman wrote: > Thanks for the explanation, and it makes sense now. But also I think > you have to add a better intro for Appendix B or the next reader (not > subscribed to this list) will have the same issue as I did. Do you > agree? Yes, the current text (or lack thereof) has already confused a few people. Text suggestions to improve the appendix are highly welcome. Best regards, Klaus From Akbar.Rahman@InterDigital.com Wed Jan 9 14:41:17 2013 Return-Path: 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 F40D321F84F3 for ; Wed, 9 Jan 2013 14:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 AEhkgA2vDlZU for ; Wed, 9 Jan 2013 14:41:16 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id F13CA21F84B6 for ; Wed, 9 Jan 2013 14:41:13 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jan 2013 17:41:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDEEBA.6D134A92" Date: Wed, 9 Jan 2013 17:41:12 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) Thread-Index: Ac3ut3CGD/i5s6V5R0Gz+ByLogGdXwAAvx52 From: "Rahman, Akbar" To: "Klaus Hartke" X-OriginalArrivalTime: 09 Jan 2013 22:41:12.0522 (UTC) FILETIME=[6D17DAA0:01CDEEBA] Cc: core@ietf.org Subject: Re: [core] Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 22:41:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDEEBA.6D134A92 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2xhdXMsDQoNCllvdXIgZXhwbGFuYXRpb24gdGV4dCBiZWxvdyAobWludXMgdGhlIGFsZ29y aXRobSBleHRyYWN0cykgd291bGQgbWFrZSBhbiBleGNlbGxlbnQgaW50cm9kdWN0aW9uLiBJIHdv dWxkIHZvdGUgZm9yIHRoYXQuDQoNCg0KL0FrYmFyDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogS2xhdXMgSGFydGtlIFtoYXJ0a2VAdHppLm9yZ10NClNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAwOSwgMjAxMyAwNToxOSBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRv OiBSYWhtYW4sIEFrYmFyDQpDYzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBR dWVzdGlvbiBvbiBBcHBlbmRpeCBCIChSZTogZHJhZnQtaWV0Zi1jb3JlLWNvYXAtMTMgV0dMQykN Cg0KDQoNCkFrYmFyIFJhaG1hbiB3cm90ZToNCj4gVGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24s IGFuZCBpdCBtYWtlcyBzZW5zZSBub3cuICBCdXQgYWxzbyBJIHRoaW5rDQo+IHlvdSBoYXZlIHRv IGFkZCBhIGJldHRlciBpbnRybyBmb3IgQXBwZW5kaXggQiBvciB0aGUgbmV4dCByZWFkZXIgKG5v dA0KPiBzdWJzY3JpYmVkIHRvIHRoaXMgbGlzdCkgd2lsbCBoYXZlIHRoZSBzYW1lIGlzc3VlIGFz IEkgZGlkLiAgRG8geW91DQo+IGFncmVlPw0KDQpZZXMsIHRoZSBjdXJyZW50IHRleHQgKG9yIGxh Y2sgdGhlcmVvZikgaGFzIGFscmVhZHkgY29uZnVzZWQgYSBmZXcNCnBlb3BsZS4gVGV4dCBzdWdn ZXN0aW9ucyB0byBpbXByb3ZlIHRoZSBhcHBlbmRpeCBhcmUgaGlnaGx5IHdlbGNvbWUuDQoNCkJl c3QgcmVnYXJkcywNCktsYXVzDQoNCg0K ------_=_NextPart_001_01CDEEBA.6D134A92 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0NCiJIVE1MIFRpZHkgZm9y IFdpbmRvd3MgKHZlcnMgMjUgTWFyY2ggMjAwOSksIHNlZSB3d3cudzMub3JnIj4NCjxtZXRhIGh0 dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04 Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0NCiJNUyBFeGNoYW5nZSBTZXJ2ZXIg dmVyc2lvbiA2LjUuNzY1NC4xMiI+DQo8dGl0bGU+UmU6IFtjb3JlXSBRdWVzdGlvbiBvbiBBcHBl bmRpeCBCIChSZToNCmRyYWZ0LWlldGYtY29yZS1jb2FwLTEzIFdHTEMpPC90aXRsZT4NCjwvaGVh ZD4NCjxib2R5Pg0KSGkgS2xhdXMsPGJyPg0KPGJyPg0KWW91ciBleHBsYW5hdGlvbiB0ZXh0IGJl bG93IChtaW51cyB0aGUgYWxnb3JpdGhtIGV4dHJhY3RzKSB3b3VsZA0KbWFrZSBhbiBleGNlbGxl bnQgaW50cm9kdWN0aW9uLiBJIHdvdWxkIHZvdGUgZm9yIHRoYXQuPGJyPg0KPGJyPg0KPGJyPg0K L0FrYmFyPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQo8Yj5Gcm9tOiZuYnNwOzwvYj5LbGF1cyBIYXJ0a2UgWzxhIGhyZWY9DQoibWFpbHRvOmhh cnRrZUB0emkub3JnIj5oYXJ0a2VAdHppLm9yZzwvYT5dPGJyPg0KPGI+U2VudDombmJzcDs8L2I+ V2VkbmVzZGF5LCBKYW51YXJ5IDA5LCAyMDEzIDA1OjE5IFBNIEVhc3Rlcm4NClN0YW5kYXJkIFRp bWU8YnI+DQo8Yj5UbzombmJzcDs8L2I+UmFobWFuLCBBa2Jhcjxicj4NCjxiPkNjOiZuYnNwOzwv Yj5jb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDombmJzcDs8L2I+UmU6IFtjb3JlXSBRdWVz dGlvbiBvbiBBcHBlbmRpeCBCIChSZToNCmRyYWZ0LWlldGYtY29yZS1jb2FwLTEzIFdHTEMpPGJy Pg0KPGJyPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCjxwPjxm b250IHNpemU9IjIiPkFrYmFyIFJhaG1hbiB3cm90ZTo8YnI+DQomZ3Q7IFRoYW5rcyBmb3IgdGhl IGV4cGxhbmF0aW9uLCBhbmQgaXQgbWFrZXMgc2Vuc2Ugbm93LiZuYnNwOyBCdXQNCmFsc28gSSB0 aGluazxicj4NCiZndDsgeW91IGhhdmUgdG8gYWRkIGEgYmV0dGVyIGludHJvIGZvciBBcHBlbmRp eCBCIG9yIHRoZSBuZXh0DQpyZWFkZXIgKG5vdDxicj4NCiZndDsgc3Vic2NyaWJlZCB0byB0aGlz IGxpc3QpIHdpbGwgaGF2ZSB0aGUgc2FtZSBpc3N1ZSBhcyBJDQpkaWQuJm5ic3A7IERvIHlvdTxi cj4NCiZndDsgYWdyZWU/PGJyPg0KPGJyPg0KWWVzLCB0aGUgY3VycmVudCB0ZXh0IChvciBsYWNr IHRoZXJlb2YpIGhhcyBhbHJlYWR5IGNvbmZ1c2VkIGENCmZldzxicj4NCnBlb3BsZS4gVGV4dCBz dWdnZXN0aW9ucyB0byBpbXByb3ZlIHRoZSBhcHBlbmRpeCBhcmUgaGlnaGx5DQp3ZWxjb21lLjxi cj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpLbGF1czxicj48L2ZvbnQ+PC9wPg0KPC9ib2R5 Pg0KPC9odG1sPg0K ------_=_NextPart_001_01CDEEBA.6D134A92-- From hartke@tzi.org Wed Jan 9 15:32:49 2013 Return-Path: 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 18B8F21F8476 for ; Wed, 9 Jan 2013 15:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.477 X-Spam-Level: X-Spam-Status: No, score=-5.477 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 0rgjozBwlLI3 for ; Wed, 9 Jan 2013 15:32:48 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 06B3221F845A for ; Wed, 9 Jan 2013 15:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r09NWeJ1018544 for ; Thu, 10 Jan 2013 00:32:40 +0100 (CET) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5798F7C9 for ; Thu, 10 Jan 2013 00:32:40 +0100 (CET) Received: by mail-lb0-f178.google.com with SMTP id l5so31724lbo.9 for ; Wed, 09 Jan 2013 15:32:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.125.240 with SMTP id mt16mr66822924lab.17.1357774359890; Wed, 09 Jan 2013 15:32:39 -0800 (PST) Received: by 10.112.95.166 with HTTP; Wed, 9 Jan 2013 15:32:39 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Jan 2013 01:32:39 +0200 Message-ID: From: Klaus Hartke To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] Question on Appendix B (Re: draft-ietf-core-coap-13 WGLC) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 23:32:49 -0000 Akbar Rahman wrote: > Your explanation text below (minus the algorithm extracts) would make an > excellent introduction. I would vote for that. Done in [1154]. I've also changed the examples such that the URI (output) appears below the options (inputs). Klaus From Bert.Greevenbosch@huawei.com Wed Jan 9 16:14:34 2013 Return-Path: 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 B837D1F0CFF for ; Wed, 9 Jan 2013 16:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 AYpJTd2ourS7 for ; Wed, 9 Jan 2013 16:14:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CE8A11F0CFC for ; Wed, 9 Jan 2013 16:14:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANI67068; Thu, 10 Jan 2013 00:14:31 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 00:13:18 +0000 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 08:14:30 +0800 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Thu, 10 Jan 2013 08:14:27 +0800 From: Bert Greevenbosch To: Carsten Bormann , Andrew McGregor Thread-Topic: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN6i4INd/yvaWIEUK38pCVjm1hP5hA+XUAgADAolA= Date: Thu, 10 Jan 2013 00:14:25 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB20B88@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1EADB@szxeml509-mbx> <1F479A1A-4671-4883-9022-9DA647ED73DE@gmail.com> In-Reply-To: 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" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 00:14:34 -0000 Hi Carsten, Yes, indeed the empty message does not qualify as a request or response. Th= e new text is better. Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 10 January 2013 04:43 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) On Jan 4, 2013, at 04:45, Andrew McGregor wrote: > Simply deleting the "and MUST NOT be empty" from the first sentence you q= uote would make it unambiguous that an empty message is allowed, and must b= e rejected. In [1152], I'm proposing a slightly different approach: Since the "always carries either a request or response" also is not true in= the CoAP ping case, it is probably better to qualify the whole sentence: message as Confirmable in the CoAP header. A Confirmable message - always carries either a request or response and MUST NOT be empty.= A + always carries either a request or response and MUST NOT be + empty, unless it is used only to elicit a Reset message. 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 I hope this completely resolves this. Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Wed Jan 9 21:50:09 2013 Return-Path: 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 CB52B21F85A4 for ; Wed, 9 Jan 2013 21:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 o4WOYD8+3VTk for ; Wed, 9 Jan 2013 21:50:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5A62821F8596 for ; Wed, 9 Jan 2013 21:49:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANI81692; Thu, 10 Jan 2013 05:49:58 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 05:48:44 +0000 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 05:49:56 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.003; Thu, 10 Jan 2013 13:49:54 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN315iJ1Q/0+sXYEmo5E7r/F2NcJg9qGLQgAHsNwCAAS8dIA== Date: Thu, 10 Jan 2013 05:49:53 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB20BEB@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB20446@szxeml509-mbx> In-Reply-To: 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" Subject: Re: [core] BG7 -- PROBING_RATE (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 05:50:09 -0000 Hi Carsten, Thank you for your feedback. I have listened to the recordings of the Friday meeting in Vancouver. Indee= d there has been an extensive discussion on congestion control; however the= re was not much decided. The main thread in the discussion was, that you ne= ed at least an RTT estimator to do something clever. People were suggesting= various ways, including mixing CONs and NONs and using the RTT of CONs to = evaluate the network condition. The outcome of the discussion was, that we need more knowledge/work to crea= te suitable congestion control guidelines. A task force was setup, which wa= s to provide a separate document with guidelines for congestion control. A 7 B/s limit was briefly mentioned as "NSTART decay" (slide 98) and as a c= onservative limit for unidirectional (slide 100). The former was briefly di= scussed, whereas the latter only mentioned. From the recordings, I cannot c= onclude there was group consensus on PROBING_RATE. The dependence on size of the PROBING_RATE leads to different time-outs for= different messages, unless messages have a fixed size. This implies that t= he client needs to maintain separate timing information for each request. O= ne can indeed use a fixed estimate for the maximum message size, and in thi= s way convert PROBING_RATE from B/s to messages/s. It will lead to an even = lower rate than would have been possible without the conversion. After conversion, the PROBING_RATE mechanism is essentially a linear scheme= . It is similar to the 3s resend mechanism mentioned below, though with a m= uch lower (yet arbitrary!) default value. Unlike with the exponential back-= off scheme, if the connection is congested while all clients are sending at= PROBING_RATE, there is nothing the clients will do to reduce the congestio= n. I truly think that defining the PROBING_RATE mechanism in the base CoAP spe= c is premature. Neither the default value nor de unit "B/s" has a solid qua= ntitative background. In fact, during the Vancouver discussion most people = talked naturally about messages/second. I think it is better to do somethin= g more clever in the separate document mentioned above. Best regards, Bert Slides: http://www.ietf.org/proceedings/84/slides/slides-84-core-0.pdf Recordings: http://www.ietf.org/audio/ietf84/ietf84-regencyf-20120803-0900-= am1.mp3 -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 09 January 2013 06:09 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: Re: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC -= my comments) On Jan 8, 2013, at 02:10, Bert Greevenbosch = wrote: > Hi Carsten, >=20 > I have reviewed the NSTART and PROBING_RATE backgrounds together, but I t= hought it's will be best to keep the threads separated. >=20 > As mentioned in my other e-mail, I have reviewed the history of NSTART an= d PROBING_RATE. Both entities were added in coap-12 as a resolution to tick= et #215. The ticket history indeed mentions NSTART, but I couldn't find any= thing about PROBING_RATE. The same holds for the minutes from the Vancouver= meeting. How did PROBING_RATE come into being? There must be something slowing down unresponded NONs. PROBING_RATE was me= ant for this. I seem to remember proposing a PROBING_RATE of 7 B/s in Vancouver, only to = be bid down to 1 B/s by people in the room. > I am still not convinced about PROBING_RATE, especially its dependence on= the message size. Restricting (re)transmissions based on data size makes s= ense for applications such as streaming, where a lot of data is transmitted= in subsequent RTP packets. In that case, the amount of data per time unit = (thereby the amount of packets) could be restricted in order to reduce cong= estion. However, for CoAP, where we normally talk about a few messages (per= client/server pair) of limited size, I think it is more appropriate to put= a limit on the number of messages per time unit, than making it dependent = on the message size. If you know your maximum message size, you can easily implement it this way= by translating 1 B/s to, say, 0.01 message/s for 100-byte-max messages. > How about setting a RECOMMENDED minimum time between subsequent outstandi= ng interactions, for example the 3s mentioned in RFC 5405? Well, RFC 5405 mentions | SHOULD measure RTT and transmit max. 1 datagram/RTT | | | else, SHOULD send at most 1 datagram every 3 seconds | | | SHOULD back-off retransmission timers following loss | | which I take to mean stubbornly sending a packet every 3 s is not within th= e spirit of RFC 5405. More importantly, a room full of sensors that all stubbornly send a packet = every 3 s is a recipe for congestion collapse, independent of what RFC 5405= suggests or not (this brings up Lars' scenario of having to chisel the sen= sors out of the wall to end the congestion collapse). So we need to find a= way to slow down in case of no response, much beyond the 3 s default. The= current text tries to keep a lot of leeway for how to implement this. 1 B= /s is a reasonably conservative way to approach this Gr=FC=DFe, Carsten From angelo.castellani@gmail.com Thu Jan 10 07:29:10 2013 Return-Path: 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 9723721F8583 for ; Thu, 10 Jan 2013 07:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 NouB6eEdXPFn for ; Thu, 10 Jan 2013 07:29:10 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 899CE21F8506 for ; Thu, 10 Jan 2013 07:29:09 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id n10so566425lbo.8 for ; Thu, 10 Jan 2013 07:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=p4NiZoEWs4A14WX3f7AT+54/Zn88AxC0zcVEELWZ0rQ=; b=aUD1DagNPrUwx4ORP+pStquDY1aWGhk3E9KxFZIamISwC9QtzzPks/OIXwg7EQ3HTA ff6KLcwyQ+kzbLlPTdT5gEDUG1yBXXj4QpIIbIEdQFzPHP9lCSNzr5u1KfogIMxiSOuu qhtoWI5eK2dXn0TRcKyTPV2I4ZiafbejpZ8izuIwR+kKFtIgug+cdGqbvRBnTvx/L4az eKBptiq0rvqUT3vvbqOqZ1hiU1IgL4MFPfIg3L1wszdvqUcQoC2QWJ1Z0JL/f6HybrAn CACUntCeesdtlD7bBrZRW6TKYSl5PuuC9Rcwq1jzcfqfohL550JtwOvxTLxI9xtB836h d05Q== Received: by 10.152.114.66 with SMTP id je2mr68282501lab.40.1357831748223; Thu, 10 Jan 2013 07:29:08 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.112.163.234 with HTTP; Thu, 10 Jan 2013 07:28:52 -0800 (PST) From: "Angelo P. Castellani" Date: Thu, 10 Jan 2013 16:28:52 +0100 X-Google-Sender-Auth: AQ5Nl_MoKaCg5Gx3lHQRumIFfHQ Message-ID: To: core Content-Type: text/plain; charset=UTF-8 Subject: [core] WGLC draft-ietf-core-coap-13 Critical Options and 4.02 Bad Option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 15:29:10 -0000 Dear WG, in the current CoAP specification a server MUST issue a "4.02 Bad Option" response either if: A. an option is malformed B. an option is unrecognized The case B seems inconsistent with the current definition of the 4.xx class of response codes (Client Error). If a client sends a valid and well-formed critical option to a server that does not implements it, the server tells the client that the error is from its side. I believe that a better response code for this scenario is either: 1. The existing response code "5.01 Not Implemented" 2. A new response code "5.06 Option Not Supported" Best, Angelo ===== Referenced text: 5.4.1. Critical/Elective Options fall into one of two classes: "critical" or "elective". [...] o Unrecognized options of class "critical" that occur in a confirmable request MUST cause the return of a 4.02 (Bad Option) response. This response SHOULD include a diagnostic payload describing the unrecognized option(s) (see Section 5.5.2). [...] 5.9.2. Client Error 4.xx This class of response code is intended for cases in which the client seems to have erred. These response codes are applicable to any request method. [...] 5.9.2.3. 4.02 Bad Option The request could not be understood by the server due to one or more unrecognized or malformed options. The client SHOULD NOT repeat the request without modification. From sye.loong.keoh@philips.com Fri Jan 11 00:23:19 2013 Return-Path: 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 37CFA21F89C0 for ; Fri, 11 Jan 2013 00:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wkSrLdTB-XYe for ; Fri, 11 Jan 2013 00:23:18 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id D7C8221F88D6 for ; Fri, 11 Jan 2013 00:23:17 -0800 (PST) Received: from mail27-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 11 Jan 2013 08:23:16 +0000 Received: from mail27-va3 (localhost [127.0.0.1]) by mail27-va3-R.bigfish.com (Postfix) with ESMTP id 7118D12018C for ; Fri, 11 Jan 2013 08:23:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz217bI15d6O9251J2174Mc85ehzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275dh1033IL18c673h17326ahz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail27-va3 (localhost.localdomain [127.0.0.1]) by mail27-va3 (MessageSwitch) id 1357892593584314_28036; Fri, 11 Jan 2013 08:23:13 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.248]) by mail27-va3.bigfish.com (Postfix) with ESMTP id 8931E440074 for ; Fri, 11 Jan 2013 08:23:13 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 11 Jan 2013 08:23:10 +0000 Received: from 011-DB3MMR1-023.MGDPHG.emi.philips.com (10.128.28.107) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 11 Jan 2013 08:22:58 +0000 Received: from 011-DB3MPN1-031.MGDPHG.emi.philips.com ([169.254.1.185]) by 011-DB3MMR1-023.MGDPHG.emi.philips.com ([fe80::e485:97aa:9b41:86e3%11]) with mapi id 14.02.0318.003; Fri, 11 Jan 2013 08:22:58 +0000 From: "Keoh, Sye Loong" To: "core@ietf.org" Thread-Topic: WGLC draft-ietf-core-coap-13 Certificate Authority Name Thread-Index: Ac3v1NzAYb5ECOpFRk2QsWFHKkWWYw== Date: Fri, 11 Jan 2013 08:22:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.92.83.29] Content-Type: multipart/alternative; boundary="_000_EAE29B174013F643B5245BA11953A1BE2234F03A011DB3MPN1031MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] WGLC draft-ietf-core-coap-13 Certificate Authority Name X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:23:19 -0000 --_000_EAE29B174013F643B5245BA11953A1BE2234F03A011DB3MPN1031MG_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Carsten, Klaus, Zach and all, We would like to confirm our understanding with regards to the use of Certi= ficates in DTLS in core-coap. In Section 9.1.3.3. (http://tools.ietf.org/html/draft-ietf-core-coap-13#sec= tion-9.1.3), it defines the following: The Authority Name in the certificate is the name that would be used in the= Host part of a CoAP URI. It is worth noting that this would typically not= be either an IP address or DNS name built in the usual way but would inste= ad be built out of a long term unique identifier for the device such as the= EUI-64 [EUI64]. The discovery process used in the system would build up the mapping be= tween IP addresses of the given devices and the Authority Name for each dev= ice. Some devices could have more than one Authority and would need more= than a single certificate. Our understanding is that : 1. The Authority Name in the Certificate is preferably not an IP addr= ess, nor a DNS name. 2. The Authority Name should preferably be the device=92s EUI-64. (or= another such identifier if available) 3. There is a known mapping between IP addresses of a given device an= d its EUI (i.e. the Authority Name in the certificate). 4. A (discovery) process is used such that a CoAP endpoint can learn = about, and internally store, relevant mapping entries. (Prior to the step b= elow) 5. When exchanging certificates during the DTLS handshake, the Author= ity Name (EUI-64) in the certificate is mapped to the device=92s IP address= based on the mapping. Then this IP address is checked against the IP addre= ss of the communication partner. Thus, ensuring that the handshake request = originates from the correct CoAP device. 6. The mapping between IP addresses and EUI is not defined in CoAP an= d it is left to implementers. Is our understanding above conforming to the intent of the draft? best regards, Sye Loong Keoh Esko Dijk ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_EAE29B174013F643B5245BA11953A1BE2234F03A011DB3MPN1031MG_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear Carsten, Klaus, Zach = and all,
 
We would like to confirm o= ur understanding with regards to the use of Certificates in DTLS in core-co= ap.
In Section 9.1.3.3. (http://tools.ietf.org/html/draft-ietf-core-coap-13#se= ction-9.1.3), it defines the following:
 
The Authority Name in the certificate is the name that =
would be used in the Host part of a CoAP URI.  It is worth noting that=
 this would typically not be either an IP address or DNS name built in the =
usual way but would instead be built out of a long term unique identifier f=
or the device such as the EUI-64 [EUI64].  The dis=
covery process used in the system would build up the mapping between IP add=
resses of the given devices and the Authority Name for each device. Some &n=
bsp;  devices could have more than one Authority and would need m=
ore than a single certificate.
 
Our understanding is that = :
1.       The Authority Name in the Certificate= is preferably not an IP address, nor a DNS name.
2.       The Authority Name should preferably = be the device=92s EUI-64. (or another such identifier if available)<= /span>
3.       There is a known mapping between IP a= ddresses of a given device and its EUI (i.e. the Authority Name in the cert= ificate).
4.       A (discovery) process is used such th= at a CoAP endpoint can learn about, and internally store, relevant mapping = entries. (Prior to the step below)
5.       When exchanging certificates during t= he DTLS handshake, the Authority Name (EUI-64) in the certificate is mapped= to the device=92s IP address based on the mapping. Then this IP address is= checked against the IP address of the communication partner. Thus, ensuring that the handshake request originate= s from the correct CoAP device.
6.       The mapping between IP addresses and = EUI is not defined in CoAP and it is left to implementers.
 
Is our understanding above= conforming to the intent of the draft?
 
best regards,
Sye Loong Keoh
Esko Dijk

The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_EAE29B174013F643B5245BA11953A1BE2234F03A011DB3MPN1031MG_-- From hallam@gmail.com Fri Jan 11 13:12:24 2013 Return-Path: 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 28B8E21F8AF8 for ; Fri, 11 Jan 2013 13:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.131 X-Spam-Level: X-Spam-Status: No, score=-4.131 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 rRsGFysL6dcj for ; Fri, 11 Jan 2013 13:12:23 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by ietfa.amsl.com (Postfix) with ESMTP id 87E4521F8AF4 for ; Fri, 11 Jan 2013 13:12:22 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq13so2214186lab.33 for ; Fri, 11 Jan 2013 13:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wfwEwIvFe/qGiTree4/woq703r9Biyr7I76sx9Ft/Xg=; b=vHjZkuFab45y4G//ImB5Qe8h0qAIiTfMddqdPQ5zayvQP1wSp+7CfbhpnM53KRfjWa MJcS3qD7Fuj3lycVu4Ha+0O+3YloblBROb6w/gk/QrRk9ls+fdXdPg5ln1X5OqG5ZvcO oR3cTZ6rMbW6UXFq/205yJFNhlP7iIgbMv1VMxTAgq0C6EPxbluxa1TTK6oktXWG1ZmE +zBaiSaXeF67JGbIPhpDG96OFPjmxBJIwz0b5dK5CycXTpMKdzJg2cIstAlzZXB6ZCWM 9wfbBnH2zn5cVLgYiKKmnebbVdp87YLX+n3JJdpXS3fFamQkBRVxgmwgDOS4MyGPDgzh m+UA== MIME-Version: 1.0 Received: by 10.152.144.164 with SMTP id sn4mr73948030lab.57.1357938741368; Fri, 11 Jan 2013 13:12:21 -0800 (PST) Received: by 10.112.60.166 with HTTP; Fri, 11 Jan 2013 13:12:20 -0800 (PST) Date: Fri, 11 Jan 2013 16:12:20 -0500 Message-ID: From: Phillip Hallam-Baker To: core@ietf.org Content-Type: multipart/alternative; boundary=e89a8f22c4af4e55f304d309c062 Subject: [core] One UDP request, many replies X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:12:24 -0000 --e89a8f22c4af4e55f304d309c062 Content-Type: text/plain; charset=ISO-8859-1 I have a protocol that I am working on called Omnibroker that is intended to provide a one-stop-shopping type approach to all the third party trust data that a client might need. This includes DNS, NTP, OCSP and reputation services. The protocol has two parts, the first manages establishing a connection to the service provider, exchanging cryptographic session keys, authanticating, yadda yadda. One comment made on the protocol is that the connection part is completely general. It could be applied to virtually any request/response type Web Service as security at the transaction layer is always going to come down to some sort of shared session key for integrity and confidentiality and the option of digital signatures (plus a means of archiving them) in the rare case we want non-repudiation. 90% of the Omnibroker protocol is packaging to establish the connection and then apply it to a query/response protocol. So pretty much most of the protocol is reusable. Since these are TRUST services it is vital that every message be authenticated independently of any transport security. Due to deployment constraints there are three planned transport protocols: DNS (tunneling over TXT), Web Service and UDP. Looking at the CoApp pec it looks like a pretty good basis for the UDP version of the protocol. So if I layer Omnibroker on CoApp, the same set of options could be used to support other protocols that needed application layer authentication. There is one area where CoApp does not meet my needs and that is the limit to one UDP request/response packet. I think that is a little more restrictive than necessary. I get that people want to use multicast and requests need to be limited to a single packet. That is fine. The requests are almost always small. Fitting the response into 1280 bytes is much more limiting. I know that there needs to be a limit but I think we could make it more than just one packet. Most of my transactions would fit into one UDP request plus up to eight response packets. If the response is any longer than eight packets then it isn't going to be one of the latency sensistive use cases. So I could hack the CoApp protocol up on a one off basis so that I sent one response that had a flag saying 'more responses to come' and then send those as unsolicited messages. But this might be something that would be better done as a general CoApp capability. -- Website: http://hallambaker.com/ --e89a8f22c4af4e55f304d309c062 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a protocol that I am working on called Omnibroker that is intended t= o provide a one-stop-shopping type approach to all the third party trust da= ta that a client might need. This includes DNS, NTP, OCSP and reputation se= rvices.

The protocol has two parts, the first manages establish= ing a connection to the service provider, exchanging cryptographic session = keys, authanticating, yadda yadda.

One comment mad= e on the protocol is that the connection part is completely general. It cou= ld be applied to virtually any request/response type Web Service as securit= y at the transaction layer is always going to come down to some sort of sha= red session key for integrity and confidentiality and the option of digital= signatures (plus a means of archiving them) in the rare case we want non-r= epudiation.

90% of the Omnibroker protocol is packaging to establis= h the connection and then apply it to a query/response protocol. So pretty = much most of the protocol is reusable. Since these are TRUST services it is= vital that every message be authenticated independently of any transport s= ecurity.=A0


Due to deployment constraints there are = three planned transport protocols: DNS (tunneling over TXT), Web Service an= d UDP.

Looking at the=A0CoApp=A0pec it looks like = a pretty good basis for the UDP version of the protocol. So if I layer Omni= broker on CoApp, the same set of options could be used to support other pro= tocols that needed application layer authentication.


There is one area where=A0CoApp does not= meet my needs and that is the limit to one UDP request/response packet. I = think that is a little more restrictive than necessary. I get that people w= ant to use multicast and requests need to be limited to a single packet. Th= at is fine. The requests are almost always small. Fitting the response into= 1280 bytes is much more limiting. I know that there needs to be a limit bu= t I think we could make it more than just one packet.

Most of my transactions would fit into one UDP request = plus up to eight response packets. If the response is any longer than eight= packets then it isn't going to be one of the latency sensistive use ca= ses.

So I could hack the CoApp protocol up on a one off basi= s so that I sent one response that had a flag saying 'more responses to= come' and then send those as unsolicited messages. But this might be s= omething that would be better done as a general CoApp capability.



--
Website: http://hallambaker.com/
--e89a8f22c4af4e55f304d309c062-- From darconeous@gmail.com Sat Jan 12 10:26:31 2013 Return-Path: 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 4218521F878F for ; Sat, 12 Jan 2013 10:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 yolAo+S-Szv2 for ; Sat, 12 Jan 2013 10:26:29 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 19E3921F8713 for ; Sat, 12 Jan 2013 10:26:29 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id rl6so1564428pac.15 for ; Sat, 12 Jan 2013 10:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=inMU+Bvh+PK36G773HENjyA/CJxRT2u0lIzI/Cxt+rg=; b=B4b8uhvIJFtK+KstCwRo76crb5q3dXaWx+BV/ZtVpEibYPyG8VNsbDAmXG1JgwIoO4 9iITKiomgzbCixNzpIWt5f0Q4Fod0GOB1ISlXwiZxee97kjGhwcnmdRkfm7FBAHkK+2o rSBJQlPrwGAG4hmvONoRU2Q9ElfnEdb5ft3GtgttvenhnuksERJyMiKLMlsP1/vctQHC 6H4A+6v4xQNz7lNnfPXGOObSsTMVPqSIdUCWCbeVDwztRueRDmd1bmu5gVZ6EQ1jhDHV F78RSYwhA6Z0DRV2amviAnPU7gY8ARICpyXcKG65l7nnu5qZ7a++5yFedamAklSbR4Xi S++w== X-Received: by 10.68.211.42 with SMTP id mz10mr241491567pbc.100.1358015188710; Sat, 12 Jan 2013 10:26:28 -0800 (PST) Received: from [172.30.96.30] (c-67-174-221-32.hsd1.ca.comcast.net. [67.174.221.32]) by mx.google.com with ESMTPS id nf9sm4972832pbc.17.2013.01.12.10.26.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jan 2013 10:26:28 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_0B7B6788-8132-4612-83FC-A7DA879CEF55" From: Robert Quattlebaum In-Reply-To: Date: Sat, 12 Jan 2013 10:26:25 -0800 Message-Id: <02EAF087-5709-4CFD-A4FC-F8A6E5A56CAE@gmail.com> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1499) Cc: IETF CoRE Working Group Subject: Re: [core] One UDP request, many replies X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 18:26:31 -0000 --Apple-Mail=_0B7B6788-8132-4612-83FC-A7DA879CEF55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 While it is true that a single CoAP confirmable message should elicit = only one direct ACK, there is no reason that you couldn't have more than = one non-ACK response. Indeed, this is how draft-ietf-core-observe works. = CoAP can also be used to transfer more than 1280 bytes by using = draft-ietf-core-block. On Jan 11, 2013, at 1:12 PM, Phillip Hallam-Baker = wrote: > I have a protocol that I am working on called Omnibroker that is = intended to provide a one-stop-shopping type approach to all the third = party trust data that a client might need. This includes DNS, NTP, OCSP = and reputation services. >=20 > The protocol has two parts, the first manages establishing a = connection to the service provider, exchanging cryptographic session = keys, authanticating, yadda yadda. >=20 > One comment made on the protocol is that the connection part is = completely general. It could be applied to virtually any = request/response type Web Service as security at the transaction layer = is always going to come down to some sort of shared session key for = integrity and confidentiality and the option of digital signatures (plus = a means of archiving them) in the rare case we want non-repudiation. >=20 > 90% of the Omnibroker protocol is packaging to establish the = connection and then apply it to a query/response protocol. So pretty = much most of the protocol is reusable. Since these are TRUST services it = is vital that every message be authenticated independently of any = transport security.=20 >=20 >=20 > Due to deployment constraints there are three planned transport = protocols: DNS (tunneling over TXT), Web Service and UDP. >=20 > Looking at the CoApp pec it looks like a pretty good basis for the UDP = version of the protocol. So if I layer Omnibroker on CoApp, the same set = of options could be used to support other protocols that needed = application layer authentication. >=20 >=20 > There is one area where CoApp does not meet my needs and that is the = limit to one UDP request/response packet. I think that is a little more = restrictive than necessary. I get that people want to use multicast and = requests need to be limited to a single packet. That is fine. The = requests are almost always small. Fitting the response into 1280 bytes = is much more limiting. I know that there needs to be a limit but I think = we could make it more than just one packet. >=20 > Most of my transactions would fit into one UDP request plus up to = eight response packets. If the response is any longer than eight packets = then it isn't going to be one of the latency sensistive use cases. >=20 > So I could hack the CoApp protocol up on a one off basis so that I = sent one response that had a flag saying 'more responses to come' and = then send those as unsolicited messages. But this might be something = that would be better done as a general CoApp capability. >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_0B7B6788-8132-4612-83FC-A7DA879CEF55 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 While it is true that a single CoAP confirmable message should elicit only one direct ACK, there is no reason that you couldn't have more than one non-ACK response. Indeed, this is how draft-ietf-core-observe works. CoAP can also be used to transfer more than 1280 bytes by using draft-ietf-core-block.

On Jan 11, 2013, at 1:12 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

I have a protocol that I am working on called Omnibroker that is intended to provide a one-stop-shopping type approach to all the third party trust data that a client might need. This includes DNS, NTP, OCSP and reputation services.

The protocol has two parts, the first manages establishing a connection to the service provider, exchanging cryptographic session keys, authanticating, yadda yadda.

One comment made on the protocol is that the connection part is completely general. It could be applied to virtually any request/response type Web Service as security at the transaction layer is always going to come down to some sort of shared session key for integrity and confidentiality and the option of digital signatures (plus a means of archiving them) in the rare case we want non-repudiation.

90% of the Omnibroker protocol is packaging to establish the connection and then apply it to a query/response protocol. So pretty much most of the protocol is reusable. Since these are TRUST services it is vital that every message be authenticated independently of any transport security. 


Due to deployment constraints there are three planned transport protocols: DNS (tunneling over TXT), Web Service and UDP.

Looking at the CoApp pec it looks like a pretty good basis for the UDP version of the protocol. So if I layer Omnibroker on CoApp, the same set of options could be used to support other protocols that needed application layer authentication.


There is one area where CoApp does not meet my needs and that is the limit to one UDP request/response packet. I think that is a little more restrictive than necessary. I get that people want to use multicast and requests need to be limited to a single packet. That is fine. The requests are almost always small. Fitting the response into 1280 bytes is much more limiting. I know that there needs to be a limit but I think we could make it more than just one packet.

Most of my transactions would fit into one UDP request plus up to eight response packets. If the response is any longer than eight packets then it isn't going to be one of the latency sensistive use cases.

So I could hack the CoApp protocol up on a one off basis so that I sent one response that had a flag saying 'more responses to come' and then send those as unsolicited messages. But this might be something that would be better done as a general CoApp capability.



--
Website: http://hallambaker.com/
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--Apple-Mail=_0B7B6788-8132-4612-83FC-A7DA879CEF55-- From wasilak@gmail.com Wed Jan 23 12:30:03 2013 Return-Path: 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 BE6D421F8738 for ; Wed, 23 Jan 2013 12:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 phZcUpyxC4jL for ; Wed, 23 Jan 2013 12:30:03 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6F221F872E for ; Wed, 23 Jan 2013 12:30:02 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id fn15so1754362wgb.20 for ; Wed, 23 Jan 2013 12:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mSV3iBDogBPM8CZtbKoYzrLlwFtngF2IEYyp+SqeshI=; b=FZPiGt7+z4f/Mu09HaX/C9iNkezI0WaThAD3U7cxh1Ek0FNtytPDTBISuXxO5t/RxI geYpmE+isp+g6zfh3T2QPeO8DgyzRAhLsHzVmBXgmqRhULWaKrfHJn5XEIdkCQS3N78X tzrozUjsDWCPNwbqRd8D7b2vkukKq9tdLn2ziLEMxjSIJsij+FWD4BEvaXn5MK5ujC+5 qBvX3rjJsvR8ify8iwRYZ9vsncxc64xeAZKhveASXa2I4CUpIZAHS0z4sESBQLu2RHTO v2epUrAWoqZGx3hoNV4kwDMoPqDggbvvZ/rAmNNBf/NRuXwGH7SxDkrWLByxRiBIEsHd BkOQ== MIME-Version: 1.0 X-Received: by 10.194.90.238 with SMTP id bz14mr5015377wjb.9.1358973001689; Wed, 23 Jan 2013 12:30:01 -0800 (PST) Received: by 10.216.255.140 with HTTP; Wed, 23 Jan 2013 12:30:01 -0800 (PST) In-Reply-To: <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> Date: Wed, 23 Jan 2013 21:30:01 +0100 Message-ID: From: Maciej Wasilak To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7bfcf524066acb04d3fa8f7a Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 20:30:03 -0000 --047d7bfcf524066acb04d3fa8f7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, some time ago there was a discussion whether blocks in blockwise transfer should be sent in sequential fashion. The suggested approach was: 1) the protocol does not fundamentally disallow out-of-order access (and, many servers will be able to provide out-of-order access (e.g., because they are stateless)) 2) still, there is an expectation that more servers will be able to cope with sequential access than with out-of-order access. Servers that implement one of the Block options SHOULD enable sequential access, and MAY enable out-of-order access. Question: In what way server which accepts only sequential access should reject out-of-order messages? Is it okay to send 4.08 Request Entity Incomplete er= ror message? (or is it reserved only for cases when M byte is not set). Best Regards Maciej Wasilak 2012/4/12 Carsten Bormann > On Apr 12, 2012, at 11:36, Dijk, Esko wrote: > > > Carsten, > > > >> So a client that wants to maximize interoperability will probably > operate in sequential fashion. > > Ok. If this constitutes the minimum level of interoperability for > core-block, should we mandate it as such? > > > > Option 1) e.g. specify a CoAP end-point MUST be prepared to receive > block numbers in sequential fashion. > > Well, it is hard to say what such a MUST ("be prepared to receive...") > really constrains. > A server can still always go belly-up, stop serving a resource, ... > > I think the point is indeed that there is a larger expectation of > successful completion when a client steps sequentially through the blocks > of a resource. > > > Option 2) e.g. specify a CoAP end-point MAY use block numbers in > sequential fashion. > > [this automatically implies an end-point MUST be prepared > to receive sequential block numbers. At least an implementer MUST > > consider this possibility.] > > But it also MAY use out-of order accesses... just with a slightly lower > level of expectation that the server will be able to successfully respond= . > > > Though, the sequential case is so obvious from the I-D that it is > already a de-facto minimum interoperability (though not formally stated). > > That was indeed my reasoning so far. > > To me it seems we could make all this more apparent by stating two things= : > > 1) the protocol does not fundamentally disallow out-of-order access (and, > many servers will be able to provide out-of-order access (e.g., because > they are stateless)) > 2) still, there is an expectation that more servers will be able to cope > with sequential access than with out-of-order access. Servers that > implement one of the Block options SHOULD enable sequential access, and M= AY > enable out-of-order access. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --047d7bfcf524066acb04d3fa8f7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello,

some time ago there was a discussion whether bloc= ks in blockwise transfer should be sent in sequential fashion. The suggeste= d approach was:

1) the protocol does not fundament= ally disallow out-of-order access (and, many servers will be able to provid= e out-of-order access (e.g., because they are stateless))
2) still, there is an expectation that more servers will be able to cope wi= th sequential access than with out-of-order access. =C2=A0Servers that impl= ement one of the Block options SHOULD enable sequential access, and MAY ena= ble out-of-order access.

Question:
In what way server which accepts on= ly sequential access should reject out-of-order messages?=C2=A0Is it okay to send=C2=A04.08=C2=A0Request Entity Incomplete=C2=A0error message? (or is it reserved only for cases when=C2=A0M byte is not set).
Best Regards
Maciej Wasilak

2012/4/12 Carsten Bormann <cabo@tzi.org>
On Apr 12, 2012, at 11:36,= Dijk, Esko wrote:

> Carsten,
>
>> So a client that wants to maximize interoperability will probably = operate in sequential fashion.
> Ok. If this constitutes the minimum level of interoperability for core= -block, should we mandate it as such?
>
> Option 1) e.g. specify a CoAP end-point MUST be prepared to receive bl= ock numbers in sequential fashion.

Well, it is hard to say what such a MUST ("be prepared to receiv= e...") really constrains.
A server can still always go belly-up, stop serving a resource, ...

I think the point is indeed that there is a larger expectation of successfu= l completion when a client steps sequentially through the blocks of a resou= rce.

> Option 2) e.g. specify a CoAP end-point MAY use block numbers in seque= ntial fashion.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[this automatically im= plies an end-point MUST be prepared to receive sequential block numbers. At= least an implementer MUST
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consider this possibi= lity.]

But it also MAY use out-of order accesses... just with a slightly low= er level of expectation that the server will be able to successfully respon= d.

> Though, the sequential case is so obvious from the I-D that it is alre= ady a de-facto minimum interoperability (though not formally stated).

That was indeed my reasoning so far.

To me it seems we could make all this more apparent by stating two things:<= br>
1) the protocol does not fundamentally disallow out-of-order access (and, m= any servers will be able to provide out-of-order access (e.g., because they= are stateless))
2) still, there is an expectation that more servers will be able to cope wi= th sequential access than with out-of-order access. =C2=A0Servers that impl= ement one of the Block options SHOULD enable sequential access, and MAY ena= ble out-of-order access.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--047d7bfcf524066acb04d3fa8f7a-- From wasilak@gmail.com Wed Jan 23 12:31:28 2013 Return-Path: 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 993E221F8749 for ; Wed, 23 Jan 2013 12:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 nLWLPSEIh2xi for ; Wed, 23 Jan 2013 12:31:27 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12F5921F8740 for ; Wed, 23 Jan 2013 12:31:26 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id o1so1094679wic.11 for ; Wed, 23 Jan 2013 12:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=6vqFwEe+EzYsDrHfNoQZxXnmC8jG8p+giuOXQ/s5z30=; b=pE+q08v6S84dPtDcHZoAXKLCoVXnSTZBnAyP6TiNDrCYtbIZ6mwSvDxtuRa9V3XJq5 JyZC7dv+0upr1Fw9WV5SglQEEDmDfwvd9WQAQLN2I3c+VSyboy/5qCBTUn27z34+NKGO eZOSk7/8yVm0yf8EmUT97xHt4YwaM+uZlYV7l8q6ebNxRI+g2wqVuWrifJlbWBJNEe9C WylF4axLQMJeZgp2l4OaudTQe79Ee4oQxMS5FBL5PFmuXU4802Mi0d9BF79gcDIEfO7j BYlbVSPwyNcPIVOFCui5dni7QPwI6v4Ua3a30wYFB3jWV6UmOlR6K/tZqNQT5KsMf0OP tLdQ== MIME-Version: 1.0 X-Received: by 10.180.103.136 with SMTP id fw8mr4771740wib.27.1358973086173; Wed, 23 Jan 2013 12:31:26 -0800 (PST) Received: by 10.216.255.140 with HTTP; Wed, 23 Jan 2013 12:31:26 -0800 (PST) In-Reply-To: <76B4185D-C1CF-4DF8-89C2-8C610D7A3669@gmail.com> References: <76B4185D-C1CF-4DF8-89C2-8C610D7A3669@gmail.com> Date: Wed, 23 Jan 2013 21:31:26 +0100 Message-ID: From: Maciej Wasilak To: IETF CoRE Working Group Content-Type: multipart/alternative; boundary=f46d044304460f898704d3fa940d Subject: Re: [core] Apparent race condition in blockwise transfer draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 20:31:28 -0000 --f46d044304460f898704d3fa940d Content-Type: text/plain; charset=UTF-8 Hey Robert, As far as I understand all stateful blockwise transfers should be identified now by a tuple (client, uri_path), where client is another tuple (address, port). I agree that introducing proxies might lead to race conditions. It is true for PUT/POST transfers, but also for stateful GET transfers (as in draft-ietf-core-block-10: "The server may identify the sequence by the combination of the requesting end-point and the URI being the same in each block-wise request."). So if two GET requests (for example with different uri-query) are sent through a proxy, server also won't be able to tell them apart. Some practical workaround might be sending POST/PUT requests to subresources instead of a base resource: POST /data-sink/sensor1 POST /data-sink/sensor2 where sensor1 and sensor2 are temporary labels, instead of: POST /data-sink However both proxy and server need to understand these labels, which might be complicated. Best Regards Maciej Wasilak 2012/12/24 Robert Quattlebaum > Hello everyone, > > I just wanted to bring up a race condition apparently present in > the current blockwise transfer draft. However, even if you are not > interested in draft-ietf-core-block, you may want to read over this > email anyway: Similar problems may be present in protocols which > need the server to associate multiple messages as being a part of > the same logical request. For now I'll limit the discussion to > draft-ietf-core-block-10. > > Previously, the token field (as well as the source IP address and > port) could be used by the server to correlate multiple messages > that were a part of the same logical request ("token-affinity"). > In this sense the token field was not really opaque because the > server was relying on the value of the token to not change between > subsequent messages in the same logical request. However, this > semantic-entanglement had the benefit of ensuring truly atomic > behavior of requests which consist of multiple messages, without > depending on artificial limitations on how the protocol should be > used or the behavior of a specific transport layer. > > At some point over the past year (Forgive me, I haven't been paying > attention), the semantics of the token parameter was clarified to > be entirely opaque (meaning that only the client's address/port > could be used for determining which messages are a part of the same > blocked request). This was a reasonable change because it allows > client implementations to be more flexible. However, without further > clarification or additional mechanisms, this change leads to > undefined/unreliable behavior in certain cases. > > Consider the case where you have a LoWPAN where nodes regularly > dump gathered information to a CoAP server in "the cloud" via a > CoAP-CoAP proxy. If two (or more) nodes try to perform a large POST > (using Block1) to the same CoAP URL thru the proxy at the same time, > the destination machine in the cloud has no way to differentiate > the messages as being two independent atomic requests. > > In a previous discussion off-list, Carsten suggested that the proxy > could identify the start of subsequent requests as potentially > conflicting and use a different source port for each conflicting > request sent from the proxy, but this technique only works if the > cloud-side transport layer uses the UDP/IP transport---this technique > would not work if the proxy was sending requests to the cloud via > CoAP-over-SMS, as described in section 14 of > draft-becker-core-coap-sms-gprs-02. > > I think the root of this problem is the reliance on information > from the transport layer in determining which individual messages > belong to the same logical request. Doing this just happens to work > out in most cases. However, because these edge cases are transient > in nature, diagnosing such problems in the field may be very difficult > and frustrating. Sure, there are work-arounds, but they have specific > disadvantages which may not be obvious. > > The bottom line is that by refining the semantics of the token field > to no longer allow the server to use token-affinity to associate > multiple messages to logical requests, a race condition has been > introduced into the protocol. This race condition was hidden by the > fact that, by using the address/port information from the transport > layer, things *usually* work just fine. Usually, but not always. > > All that being said, I don't necessarily believe that reverting the > token behavior is necessarily the right solution to this problem: > Allowing the client to use the token to keep track of state on a > message-per-message basis is useful. The trick is giving the same > flexibility to the server: If we can't rely entirely on the transport > layer information to associate logically-related messages (and we > can't use the token) then what should be used? > > We could always simply document this class of problems in the draft > so that implementors are aware that they may need to work around > it, but I worry that this may be the first of a class of similar > race conditions if this issue is not addressed directly. > > Thoughts? > > __________________ > Robert Quattlebaum > eMail: darco@deepdarc.com > www: http://www.deepdarc.com/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --f46d044304460f898704d3fa940d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Robert,

As far as I understand all = stateful blockwise transfers should be identified now by a tuple (client, u= ri_path), where client is another tuple (address, port). I agree that intro= ducing proxies might lead to race conditions. It is true for PUT/POST trans= fers, but also for stateful GET transfers (as in draft-ietf-core-block-10: = "The server may=C2=A0identify the sequence by the combination of the requesti= ng end-point=C2=A0and the URI being th= e same in each block-wise request."). So if two GET requests (f= or example with different uri-query) are sent through a proxy, server also = won't be able to tell them apart.=C2=A0

Some practical workaround might be sending POST/PUT requests to subresource= s instead of a base resource:=C2=A0
POST /data-sink/sensor1=C2=A0
PO= ST /data-sink/sensor2
where sensor1 and sensor2 are temporary labels, instead of:
POST /data-sink
However both proxy and server need to understand these labels, which might = be complicated.

Best Regards
Maciej Wasilak
2= 012/12/24 Robert Quattlebaum <darconeous@gmail.com>
Hello everyone,

I just wanted to bring up a race condition apparently present in
the current blockwise transfer draft. However, even if you are not
interested in draft-ietf-core-block, you may want to read over this
email anyway: Similar problems may be present in protocols which
need the server to associate multiple messages as being a part of
the same logical request. For now I'll limit the discussion to
draft-ietf-core-block-10.

Previously, the token field (as well as the source IP address and
port) could be used by the server to correlate multiple messages
that were a part of the same logical request ("token-affinity").<= br> In this sense the token field was not really opaque because the
server was relying on the value of the token to not change between
subsequent messages in the same logical request. However, this
semantic-entanglement had the benefit of ensuring truly atomic
behavior of requests which consist of multiple messages, without
depending on artificial limitations on how the protocol should be
used or the behavior of a specific transport layer.

At some point over the past year (Forgive me, I haven't been paying
attention), the semantics of the token parameter was clarified to
be entirely opaque (meaning that only the client's address/port
could be used for determining which messages are a part of the same
blocked request). This was a reasonable change because it allows
client implementations to be more flexible. However, without further
clarification or additional mechanisms, this change leads to
undefined/unreliable behavior in certain cases.

Consider the case where you have a LoWPAN where nodes regularly
dump gathered information to a CoAP server in "the cloud" via a CoAP-CoAP proxy. If two (or more) nodes try to perform a large POST
(using Block1) to the same CoAP URL thru the proxy at the same time,
the destination machine in the cloud has no way to differentiate
the messages as being two independent atomic requests.

In a previous discussion off-list, Carsten suggested that the proxy
could identify the start of subsequent requests as potentially
conflicting and use a different source port for each conflicting
request sent from the proxy, but this technique only works if the
cloud-side transport layer uses the UDP/IP transport---this technique
would not work if the proxy was sending requests to the cloud via
CoAP-over-SMS, as described in section 14 of
draft-becker-core-coap-sms-gprs-02.

I think the root of this problem is the reliance on information
from the transport layer in determining which individual messages
belong to the same logical request. Doing this just happens to work
out in most cases. However, because these edge cases are transient
in nature, diagnosing such problems in the field may be very difficult
and frustrating. Sure, there are work-arounds, but they have specific
disadvantages which may not be obvious.

The bottom line is that by refining the semantics of the token field
to no longer allow the server to use token-affinity to associate
multiple messages to logical requests, a race condition has been
introduced into the protocol. This race condition was hidden by the
fact that, by using the address/port information from the transport
layer, things *usually* work just fine. Usually, but not always.

All that being said, I don't necessarily believe that reverting the
token behavior is necessarily the right solution to this problem:
Allowing the client to use the token to keep track of state on a
message-per-message basis is useful. The trick is giving the same
flexibility to the server: If we can't rely entirely on the transport layer information to associate logically-related messages (and we
can't use the token) then what should be used?

We could always simply document this class of problems in the draft
so that implementors are aware that they may need to work around
it, but I worry that this may be the first of a class of similar
race conditions if this issue is not addressed directly.

Thoughts?

__________________
Robert Quattlebaum
eMail: =C2=A0darco@deepdarc.com www: =C2=A0 =C2=A0ht= tp://www.deepdarc.com/

_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--f46d044304460f898704d3fa940d-- From trac+core@trac.tools.ietf.org Thu Jan 24 01:29:41 2013 Return-Path: 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 92A3821F8716 for ; Thu, 24 Jan 2013 01:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Tesba2AcQU+d for ; Thu, 24 Jan 2013 01:29:41 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CC23521F84A1 for ; Thu, 24 Jan 2013 01:29:40 -0800 (PST) Received: from localhost ([127.0.0.1]:39638 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TyJ7q-0004oc-0Q; Thu, 24 Jan 2013 10:29:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Thu, 24 Jan 2013 09:29:37 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/273#comment:1 Message-ID: <075.8dc4f8b132fe247fe918ea91f49c8fbb@trac.tools.ietf.org> References: <060.a27f62e00f2d05b781ab5068c8e0d20e@trac.tools.ietf.org> X-Trac-Ticket-ID: 273 In-Reply-To: <060.a27f62e00f2d05b781ab5068c8e0d20e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #273: Include guidelines on when (not) to use CoAP response to multicast request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:29:41 -0000 #273: Include guidelines on when (not) to use CoAP response to multicast request Changes (by esko.dijk@philips.com): * owner: draft-ietf-core-groupcomm@tools.ietf.org => esko.dijk@philips.com * status: new => assigned Comment: Proposed resolution is to add a section on Multicast Request and Response Suppression. First, this section briefly lists all normative requirements on accepting requests (or not) and sending responses (or not). Second, this new section will list most common multicast usages briefly and for each usage, provide a guideline for the various types of responses (2.xx, 4.xx, 5.xx, empty-payload, ...)when responses should be suppressed and when not. -- -----------------------------------+------------------------------------ Reporter: esko.dijk@philips.com | Owner: esko.dijk@philips.com Type: task | Status: assigned Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Thu Jan 24 03:54:24 2013 Return-Path: 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 1F52D21F899F for ; Thu, 24 Jan 2013 03:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 canDB2sY5X5h for ; Thu, 24 Jan 2013 03:54:23 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1A021F89A4 for ; Thu, 24 Jan 2013 03:54:22 -0800 (PST) Received: from localhost ([127.0.0.1]:49574 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TyLNr-0006RT-BN; Thu, 24 Jan 2013 12:54:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 24 Jan 2013 11:54:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/274 Message-ID: <060.7eda5107ad7608dc2f4f1046db908829@trac.tools.ietf.org> X-Trac-Ticket-ID: 274 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130124115423.6B1A021F89A4@ietfa.amsl.com> Resent-Date: Thu, 24 Jan 2013 03:54:22 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #274: Add section on multicast via Proxy and its limitations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:54:24 -0000 #274: Add section on multicast via Proxy and its limitations Add a section to explain the issues & limitations of doing CoAP multicast requests via a CoAP Proxy. Goal is to warn and guide implementers in this subject. Also such a section would provide a placeholder/reminder of the problems that might be addressed further in the future. (Based on IETF 85 CoRE WG meeting discussion on Multicast CoAP requests via a Proxy.) Discussion summary, for reference - aggregation of responses in a proxy is difficult, since it doesn't know when to stop aggregating responses. - SIP tried to deal with this problem but didn't solve it. - There may be an expectancy of CoAP client to get single response back from proxy, not multiple. The client in this case may not even know what it could expect. It may not even know the Proxy-URI contains a multicast target. - presented via-proxy use case exposes gap in the core-coap specification regarding multicast via proxy. (Note: Expectation is that core-coap won’t address it in the first planned RFC release.) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From floris.vandenabeele@intec.ugent.be Mon Jan 28 02:33:16 2013 Return-Path: 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 2E1A321F8549 for ; Mon, 28 Jan 2013 02:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, 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 uPOsE6y-AgCA for ; Mon, 28 Jan 2013 02:33:15 -0800 (PST) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 0688C21F842F for ; Mon, 28 Jan 2013 02:33:14 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id 00CD012C36F; Mon, 28 Jan 2013 11:33:13 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id nSQNPE-3TdLv; Mon, 28 Jan 2013 11:33:13 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp2.ugent.be (Postfix) with ESMTP id 3F7F312C357; Mon, 28 Jan 2013 11:33:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 1C5681F; Mon, 28 Jan 2013 11:33:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reTSGAGVltC5; Mon, 28 Jan 2013 11:33:13 +0100 (CET) Received: from [157.193.135.223] (dhcp-zdpt-223.intec.ugent.be [157.193.135.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id CEA0A1E; Mon, 28 Jan 2013 11:33:12 +0100 (CET) Message-ID: <510653E8.4060109@intec.ugent.be> Date: Mon, 28 Jan 2013 11:33:12 +0100 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Zach Shelby References: <30a64b4fc85a612b82a5ed4fe685476e@xs4all.nl> <5F948749-91FB-4687-B0F6-CD0B713E3931@sensinode.com> <7e66b0ef133d031d61a4cd103108bb0f@xs4all.nl> <14303B24-14FE-4026-BA9F-CA4444E2492D@sensinode.com> In-Reply-To: <14303B24-14FE-4026-BA9F-CA4444E2492D@sensinode.com> Content-Type: multipart/alternative; boundary="------------000903010604030007070107" X-Miltered: at jchkm3 with ID 510653E9.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 510653E9.000 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 510653E9.000 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: Core Subject: Re: [core] resource-directory-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 10:33:16 -0000 This is a multi-part message in MIME format. --------------000903010604030007070107 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Zach&all, I read and implemented the draft and interpreted the usage of the con parameter the same way as Zach did, i.e. to be used to update volatile IP addresses thus ensuring the reachability of the registered endpoint. I also have a couple of comments/questions about draft-shelby-core-resource-directory-04: * Shouldn't the default value for the con parameter in section 5.2 also be the 'default discovery URI' as in section 4? The draft states to use the source port as the context port, however this port will usually be a client port and will differ from the port the endpoint is listening on (e.g. port 60000 vs 5683). * In draft-bormann-core-simple-server-discovery-00 a definition is given for the 'default discovery URI', I would suggest referencing it or adding it to the document in section 4. This definition does include the listening port instead of the source port. * Peter wrote: In the example of sec 5.3, the last line, ;ct=41;rt=”lightLux;if=”sensor” is identical to the 2nd line in the payload of the Registration example. This contradicts the last line of the intro of sec 5.32 Parameters (not Paremeters) that have not changed SHOULD NOT be included in an update. Better remove or change the last line in the Update example. Good eye. Will change that. I don't agree that this a contradiction, the last line of 5.32 refers to the URI query parameters that are passed on (e.g. con, rt and lt) and not the CoAP Payload. So in my view this shouldn't be altered. Enforcing this on the payload as well, would seem to imply that the payload would be a patch of some sort (which seems to be out of the scope of the document). * Why reuse the rt accronym for end point type? This is confusing with the resource type that is defined in RFC 6690. * There is small mistake in the last example of section 6. The example should be GET /rd-lookup/d instead ofGET /rd-lookup/domain in the ASCII figure and the accompanying text beneath it. Regards, Floris On ma 24 sep 2012 14:15:36 CEST, Zach Shelby wrote: > > On Sep 24, 2012, at 11:12 AM, peter van der Stok wrote: > >> >> Hi Zach, >> >> In relation to the point below, Some questions remain. >> >>> >>> >>>> >>>> In sec 5.3 the con parameter is also mentioned to update the entry. >>>> In the case that the host:port changes completely, a new entry is >>>> required IMO. May be remove con from update? >>> >>> >>> The whole point of an update is that it would update a change in the >>> ip:port, as this can happen often. This way the endpoint name in the >>> RD is stable, and does not change even though the ip:port tuple >>> changes. >>> >> >> >> I understood that con could also be used with a scheme and a FQDN >> e.g. con=coap://mynode.example.com >> I hope that is correct. > > > Sure, assuming such an FQDN exists (often times that is not the case > in M2M however). > >> >> Following your reasoning when using host:port, then >> by reassigning changing IP addresses continuously to the RD >> end-points, the RD takes over DNS functionality? > > > Not at all. DNS just really isn't used in M2M today, as it is usually > not practical or even possible to update DNS entries when nodes are > often changing their IPv6 address due to changes in point of > attachment or getting dynamic IP address assignment e.g. in Cellular > networks. > >> >> Would it not be better to keep DNS functionality outside the RD, use >> FQDNs, and only use IP addresses when the environment does not >> support DNS. >> In the latter case I do not see the IP addresses changing very >> frequently, because there is no IP provider either. > > > In theory an RD could keep track of the IP addresses of registered > nodes using DNS, but that is really an implementation issue and not an > interface specification one. > > Zach > >> >> >> Greetings, >> >> peter --------------000903010604030007070107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Zach&all,

I read and implemented the draft and interpreted the usage of the con parameter the same way as Zach did, i.e. to be used to update volatile IP addresses thus ensuring the reachability of the registered endpoint.

I also have a couple of comments/questions about draft-shelby-core-resource-directory-04:
* Shouldn't the default value for the con parameter in section 5.2 also be the 'default discovery URI' as in section 4? The draft states to use the source port as the context port, however this port will usually be a client port and will differ from the port the endpoint is listening on (e.g. port 60000 vs 5683).
* In draft-bormann-core-simple-server-discovery-00 a definition is given for the 'default discovery URI', I would suggest referencing it or adding it to the document in section 4. This definition does include the listening port instead of the source port.
* Peter wrote:
In the example of sec 5.3, the last line, </sensors/light>;ct=41;rt=”lightLux;if=”sensor” is identical to the 2nd line in the payload of the Registration example. This contradicts the last line of the intro of sec 5.32 Parameters (not Paremeters) that have not changed SHOULD NOT be included in an update. Better remove or change the last line in the Update example.
Good eye. Will change that.
I don't agree that this a contradiction, the last line of 5.32 refers to the URI query parameters that are passed on (e.g. con, rt and lt) and not the CoAP Payload. So in my view this shouldn't be altered. Enforcing this on the payload as well, would seem to imply that the payload would be a patch of some sort (which seems to be out of the scope of the document).
* Why reuse the rt accronym for end point type? This is confusing with the resource type that is defined in RFC 6690. 
* There is small mistake in the last example of section 6. The example should be GET /rd-lookup/d instead of GET /rd-lookup/domain in the ASCII figure and the accompanying text beneath it.

Regards,
Floris
On ma 24 sep 2012 14:15:36 CEST, Zach Shelby wrote:

On Sep 24, 2012, at 11:12 AM, peter van der Stok wrote:


Hi Zach,

In relation to the point below, Some questions remain.




In sec 5.3 the con parameter is also mentioned to update the entry. In the case that the host:port changes completely, a new entry is required IMO. May be remove con from update?


The whole point of an update is that it would update a change in the
ip:port, as this can happen often. This way the endpoint name in the
RD is stable, and does not change even though the ip:port tuple
changes.



I understood that con could also be used with a scheme and a FQDN
e.g. con=coap://mynode.example.com
I hope that is correct.


Sure, assuming such an FQDN exists (often times that is not the case in M2M however).


Following your reasoning when using host:port, then
by reassigning changing IP addresses continuously to the RD end-points, the RD takes over DNS functionality?


Not at all. DNS just really isn't used in M2M today, as it is usually not practical or even possible to update DNS entries when nodes are often changing their IPv6 address due to changes in point of attachment or getting dynamic IP address assignment e.g. in Cellular networks.


Would it not be better to keep DNS functionality outside the RD, use FQDNs, and only use IP addresses when the environment does not support DNS.
In the latter case I do not see the IP addresses changing very frequently, because there is no IP provider either.


In theory an RD could keep track of the IP addresses of registered nodes using DNS, but that is really an implementation issue and not an interface specification one.

Zach



Greetings,

peter
--------------000903010604030007070107-- From trac+core@trac.tools.ietf.org Mon Jan 28 04:34:06 2013 Return-Path: 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 6BD8021F8740 for ; Mon, 28 Jan 2013 04:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 eo3E5SDzJXJX for ; Mon, 28 Jan 2013 04:34:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AE9E621F86FF for ; Mon, 28 Jan 2013 04:34:05 -0800 (PST) Received: from localhost ([127.0.0.1]:54347 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TznuP-0001i7-U7; Mon, 28 Jan 2013 13:33:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 28 Jan 2013 12:33:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/275 Message-ID: <060.2b194b08521b8e50525de5005e1f6720@trac.tools.ietf.org> X-Trac-Ticket-ID: 275 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130128123405.AE9E621F86FF@ietfa.amsl.com> Resent-Date: Mon, 28 Jan 2013 04:34:05 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #275: Add multicast congestion control guideline: use of core-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 12:34:06 -0000 #275: Add multicast congestion control guideline: use of core-block Useful multicast congestion control guideline to add: CoAP server uses blockwise transfer (core-block) to only return a first block of a large resource, e.g. the link-format description in /.well-known/core -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Mon Jan 28 05:05:00 2013 Return-Path: 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 1D55521F8472 for ; Mon, 28 Jan 2013 05:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] 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 3U0l7XcnXNHj for ; Mon, 28 Jan 2013 05:04:59 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4D86D21F8430 for ; Mon, 28 Jan 2013 05:04:57 -0800 (PST) Received: from mail16-db3-R.bigfish.com (10.3.81.233) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 28 Jan 2013 13:04:56 +0000 Received: from mail16-db3 (localhost [127.0.0.1]) by mail16-db3-R.bigfish.com (Postfix) with ESMTP id 40FF46018F; Mon, 28 Jan 2013 13:04:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zz217bI98dI15d6O9371I9251Jc89bhd6eahc857hzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail16-db3 (localhost.localdomain [127.0.0.1]) by mail16-db3 (MessageSwitch) id 1359378242964436_23965; Mon, 28 Jan 2013 13:04:02 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.244]) by mail16-db3.bigfish.com (Postfix) with ESMTP id D9D55400E3; Mon, 28 Jan 2013 13:04:02 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 28 Jan 2013 13:04:02 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.86]) by 011-DB3MMR1-003.MGDPHG.emi.philips.com ([10.128.28.53]) with mapi id 14.02.0318.003; Mon, 28 Jan 2013 13:03:42 +0000 From: "Dijk, Esko" To: Floris Van den Abeele , Zach Shelby Thread-Topic: [core] resource-directory-4 Thread-Index: AQHNlwPuSFBVc6snmU+8MvoMJOpdo5eYOWGAgADgcQCAAEP9AIDF+ecAgAAnLoA= Date: Mon, 28 Jan 2013 13:03:42 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B76082@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <30a64b4fc85a612b82a5ed4fe685476e@xs4all.nl> <5F948749-91FB-4687-B0F6-CD0B713E3931@sensinode.com> <7e66b0ef133d031d61a4cd103108bb0f@xs4all.nl> <14303B24-14FE-4026-BA9F-CA4444E2492D@sensinode.com> <510653E8.4060109@intec.ugent.be> In-Reply-To: <510653E8.4060109@intec.ugent.be> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618B76082011DB3MPN2081MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: Core Subject: Re: [core] resource-directory-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:05:00 -0000 --_000_031DD135F9160444ABBE3B0C36CED618B76082011DB3MPN2081MGDP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRmxvcmlzLCBaYWNoLA0KDQo+IFNob3VsZG4ndCB0aGUgZGVmYXVsdCB2YWx1ZSBmb3Ig dGhlIGNvbiBwYXJhbWV0ZXIgaW4gc2VjdGlvbiA1LjIgYWxzbyBiZSB0aGUgJ2RlZmF1bHQgZGlz Y292ZXJ5IFVSSScgYXMgaW4gc2VjdGlvbiA0PyBUaGUgZHJhZnQgc3RhdGVzIHRvIHVzZSB0aGUg c291cmNlIHBvcnQgYXMgdGhlIGNvbnRleHQgcG9ydCwgaG93ZXZlciB0aGlzIHBvcnQgd2lsbCB1 c3VhbGx5IGJlIGEgY2xpZW50IHBvcnQgYW5kIHdpbGwgZGlmZmVyIGZyb20gdGhlIHBvcnQgdGhl IGVuZHBvaW50IGlzIGxpc3RlbmluZyBvbiAoZS5nLiBwb3J0IDYwMDAwIHZzIDU2ODMpLg0KDQpH b29kIHBvaW50OyBtYXliZSB0aGUgcmVhc29uIHRoYXQgc291cmNlIHBvcnQgaXMgd3JpdHRlbiBo ZXJlIGlzLCB0aGF0IGl04oCZcyB0aGUgb25seSBpbmZvcm1hdGlvbiB0aGF0IGlzIGF2YWlsYWJs ZSAoaW4gdGhlIGFic2VuY2Ugb2YgaW5mb3JtYXRpb24gb24gdGhlIHBvcnQgdGhlIGVuZHBvaW50 IGlzIGxpc3RlbmluZyBvbiB3aGVuIOKAmGNvbuKAmSBpcyBub3QgaW5jbHVkZWQpLiBUaGF0IGlt cGxpZXMgdGhlIGNsaWVudCBoYXMgdG8gdXNlIGFzIHNvdXJjZSBwb3J0IHRoZSBzYW1lIHBvcnQg dGhhdCBpdCBpcyBsaXN0ZW5pbmcgb24uDQoNCg0KPiBJIGRvbid0IGFncmVlIHRoYXQgdGhpcyBh IGNvbnRyYWRpY3Rpb24sIHRoZSBsYXN0IGxpbmUgb2YgNS4zMiByZWZlcnMgdG8gdGhlIFVSSSBx dWVyeSBwYXJhbWV0ZXJzIHRoYXQgYXJlIHBhc3NlZCBvbiAoZS5nLiBjb24sIHJ0IGFuZCBsdCkg YW5kIG5vdCB0aGUgQ29BUCBQYXlsb2FkLiBTbyBpbiBteSB2aWV3IHRoaXMgc2hvdWxkbid0IGJl IGFsdGVyZWQuIEVuZm9yY2luZyB0aGlzIG9uIHRoZSBwYXlsb2FkIGFzIHdlbGwsIHdvdWxkIHNl ZW0gdG8gaW1wbHkgdGhhdCB0aGUgcGF5bG9hZCB3b3VsZCBiZSBhIHBhdGNoIG9mIHNvbWUgc29y dCAod2hpY2ggc2VlbXMgdG8gYmUgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQpLg0K DQpUbyBtZSBpdOKAmXMgbm90IGNsZWFyIGZyb20gdGhlIHRleHQgd2hldGhlciB0aGUgUFVUIHJl cXVlc3QgdG8gZG8gYW4gdXBkYXRlIG92ZXJ3cml0ZXMgdGhlIHByZXZpb3VzIGVudHJpZXMgZW50 aXJlbHkgKHdoaWNoIHdvdWxkIGJlIG1vc3QgUkVTVGZ1bCkgb3IgdGhhdCDigJx1cGRhdGXigJ0g aW1wbGllcyB0aGF0IG9ubHkgbmV3IGFuZC9vciBjaGFuZ2VkIHJlc291cmNlcyBhcmUgaW5jbHVk ZWQgaW4gdGhlIHBheWxvYWQuIChUaGVuIEkgd291bGQgZXhwZWN0IGEgUE9TVCByYXRoZXIgdGhh biBQVVQpDQpNYXliZSBhbiBpZGVhIGlzIGFsbG93aW5nIGJvdGggUFVUICh0byBvdmVyd3JpdGUg ZXhpc3RpbmcpIG9yIFBPU1QgKHRvIHVwZGF0ZSBleGlzdGluZykgPw0KDQpFc2tvDQoNCg0KRnJv bTogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRmxvcmlzIFZhbiBkZW4gQWJlZWxlDQpTZW50OiBNb25kYXkgMjggSmFudWFy eSAyMDEzIDExOjMzDQpUbzogWmFjaCBTaGVsYnkNCkNjOiBDb3JlDQpTdWJqZWN0OiBSZTogW2Nv cmVdIHJlc291cmNlLWRpcmVjdG9yeS00DQoNCkhpIFphY2gmYWxsLA0KDQpJIHJlYWQgYW5kIGlt cGxlbWVudGVkIHRoZSBkcmFmdCBhbmQgaW50ZXJwcmV0ZWQgdGhlIHVzYWdlIG9mIHRoZSBjb24g cGFyYW1ldGVyIHRoZSBzYW1lIHdheSBhcyBaYWNoIGRpZCwgaS5lLiB0byBiZSB1c2VkIHRvIHVw ZGF0ZSB2b2xhdGlsZSBJUCBhZGRyZXNzZXMgdGh1cyBlbnN1cmluZyB0aGUgcmVhY2hhYmlsaXR5 IG9mIHRoZSByZWdpc3RlcmVkIGVuZHBvaW50Lg0KDQpJIGFsc28gaGF2ZSBhIGNvdXBsZSBvZiBj b21tZW50cy9xdWVzdGlvbnMgYWJvdXQgZHJhZnQtc2hlbGJ5LWNvcmUtcmVzb3VyY2UtZGlyZWN0 b3J5LTA0Og0KKiBTaG91bGRuJ3QgdGhlIGRlZmF1bHQgdmFsdWUgZm9yIHRoZSBjb24gcGFyYW1l dGVyIGluIHNlY3Rpb24gNS4yIGFsc28gYmUgdGhlICdkZWZhdWx0IGRpc2NvdmVyeSBVUkknIGFz IGluIHNlY3Rpb24gND8gVGhlIGRyYWZ0IHN0YXRlcyB0byB1c2UgdGhlIHNvdXJjZSBwb3J0IGFz IHRoZSBjb250ZXh0IHBvcnQsIGhvd2V2ZXIgdGhpcyBwb3J0IHdpbGwgdXN1YWxseSBiZSBhIGNs aWVudCBwb3J0IGFuZCB3aWxsIGRpZmZlciBmcm9tIHRoZSBwb3J0IHRoZSBlbmRwb2ludCBpcyBs aXN0ZW5pbmcgb24gKGUuZy4gcG9ydCA2MDAwMCB2cyA1NjgzKS4NCiogSW4gZHJhZnQtYm9ybWFu bi1jb3JlLXNpbXBsZS1zZXJ2ZXItZGlzY292ZXJ5LTAwIGEgZGVmaW5pdGlvbiBpcyBnaXZlbiBm b3IgdGhlICdkZWZhdWx0IGRpc2NvdmVyeSBVUkknLCBJIHdvdWxkIHN1Z2dlc3QgcmVmZXJlbmNp bmcgaXQgb3IgYWRkaW5nIGl0IHRvIHRoZSBkb2N1bWVudCBpbiBzZWN0aW9uIDQuIFRoaXMgZGVm aW5pdGlvbiBkb2VzIGluY2x1ZGUgdGhlIGxpc3RlbmluZyBwb3J0IGluc3RlYWQgb2YgdGhlIHNv dXJjZSBwb3J0Lg0KKiBQZXRlciB3cm90ZToNCg0KSW4gdGhlIGV4YW1wbGUgb2Ygc2VjIDUuMywg dGhlIGxhc3QgbGluZSwgPC9zZW5zb3JzL2xpZ2h0PjtjdD00MTtydD3igJ1saWdodEx1eDtpZj3i gJ1zZW5zb3LigJ0gaXMgaWRlbnRpY2FsIHRvIHRoZSAybmQgbGluZSBpbiB0aGUgcGF5bG9hZCBv ZiB0aGUgUmVnaXN0cmF0aW9uIGV4YW1wbGUuIFRoaXMgY29udHJhZGljdHMgdGhlIGxhc3QgbGlu ZSBvZiB0aGUgaW50cm8gb2Ygc2VjIDUuMzIgUGFyYW1ldGVycyAobm90IFBhcmVtZXRlcnMpIHRo YXQgaGF2ZSBub3QgY2hhbmdlZCBTSE9VTEQgTk9UIGJlIGluY2x1ZGVkIGluIGFuIHVwZGF0ZS4g QmV0dGVyIHJlbW92ZSBvciBjaGFuZ2UgdGhlIGxhc3QgbGluZSBpbiB0aGUgVXBkYXRlIGV4YW1w bGUuDQpHb29kIGV5ZS4gV2lsbCBjaGFuZ2UgdGhhdC4NCg0KDQoNCkkgZG9uJ3QgYWdyZWUgdGhh dCB0aGlzIGEgY29udHJhZGljdGlvbiwgdGhlIGxhc3QgbGluZSBvZiA1LjMyIHJlZmVycyB0byB0 aGUgVVJJIHF1ZXJ5IHBhcmFtZXRlcnMgdGhhdCBhcmUgcGFzc2VkIG9uIChlLmcuIGNvbiwgcnQg YW5kIGx0KSBhbmQgbm90IHRoZSBDb0FQIFBheWxvYWQuIFNvIGluIG15IHZpZXcgdGhpcyBzaG91 bGRuJ3QgYmUgYWx0ZXJlZC4gRW5mb3JjaW5nIHRoaXMgb24gdGhlIHBheWxvYWQgYXMgd2VsbCwg d291bGQgc2VlbSB0byBpbXBseSB0aGF0IHRoZSBwYXlsb2FkIHdvdWxkIGJlIGEgcGF0Y2ggb2Yg c29tZSBzb3J0ICh3aGljaCBzZWVtcyB0byBiZSBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoZSBkb2N1 bWVudCkuDQoNCiogV2h5IHJldXNlIHRoZSBydCBhY2Nyb255bSBmb3IgZW5kIHBvaW50IHR5cGU/ IFRoaXMgaXMgY29uZnVzaW5nIHdpdGggdGhlIHJlc291cmNlIHR5cGUgdGhhdCBpcyBkZWZpbmVk IGluIFJGQyA2NjkwLg0KDQoqIFRoZXJlIGlzIHNtYWxsIG1pc3Rha2UgaW4gdGhlIGxhc3QgZXhh bXBsZSBvZiBzZWN0aW9uIDYuIFRoZSBleGFtcGxlIHNob3VsZCBiZSBHRVQgL3JkLWxvb2t1cC9k IGluc3RlYWQgb2YgR0VUIC9yZC1sb29rdXAvZG9tYWluIGluIHRoZSBBU0NJSSBmaWd1cmUgYW5k IHRoZSBhY2NvbXBhbnlpbmcgdGV4dCBiZW5lYXRoIGl0Lg0KDQoNCg0KUmVnYXJkcywNCg0KRmxv cmlzDQpPbiBtYSAyNCBzZXAgMjAxMiAxNDoxNTozNiBDRVNULCBaYWNoIFNoZWxieSB3cm90ZToN Cg0KDQpPbiBTZXAgMjQsIDIwMTIsIGF0IDExOjEyIEFNLCBwZXRlciB2YW4gZGVyIFN0b2sgd3Jv dGU6DQoNCg0KDQpIaSBaYWNoLA0KDQpJbiByZWxhdGlvbiB0byB0aGUgcG9pbnQgYmVsb3csIFNv bWUgcXVlc3Rpb25zIHJlbWFpbi4NCg0KDQoNCg0KDQoNCkluIHNlYyA1LjMgdGhlIGNvbiBwYXJh bWV0ZXIgaXMgYWxzbyBtZW50aW9uZWQgdG8gdXBkYXRlIHRoZSBlbnRyeS4gSW4gdGhlIGNhc2Ug dGhhdCB0aGUgaG9zdDpwb3J0IGNoYW5nZXMgY29tcGxldGVseSwgYSBuZXcgZW50cnkgaXMgcmVx dWlyZWQgSU1PLiBNYXkgYmUgcmVtb3ZlIGNvbiBmcm9tIHVwZGF0ZT8NCg0KDQpUaGUgd2hvbGUg cG9pbnQgb2YgYW4gdXBkYXRlIGlzIHRoYXQgaXQgd291bGQgdXBkYXRlIGEgY2hhbmdlIGluIHRo ZQ0KaXA6cG9ydCwgYXMgdGhpcyBjYW4gaGFwcGVuIG9mdGVuLiBUaGlzIHdheSB0aGUgZW5kcG9p bnQgbmFtZSBpbiB0aGUNClJEIGlzIHN0YWJsZSwgYW5kIGRvZXMgbm90IGNoYW5nZSBldmVuIHRo b3VnaCB0aGUgaXA6cG9ydCB0dXBsZQ0KY2hhbmdlcy4NCg0KDQpJIHVuZGVyc3Rvb2QgdGhhdCBj b24gY291bGQgYWxzbyBiZSB1c2VkIHdpdGggYSBzY2hlbWUgYW5kIGEgRlFETg0KZS5nLiBjb249 Y29hcDovL215bm9kZS5leGFtcGxlLmNvbQ0KSSBob3BlIHRoYXQgaXMgY29ycmVjdC4NCg0KDQpT dXJlLCBhc3N1bWluZyBzdWNoIGFuIEZRRE4gZXhpc3RzIChvZnRlbiB0aW1lcyB0aGF0IGlzIG5v dCB0aGUgY2FzZSBpbiBNMk0gaG93ZXZlcikuDQoNCg0KDQpGb2xsb3dpbmcgeW91ciByZWFzb25p bmcgd2hlbiB1c2luZyBob3N0OnBvcnQsIHRoZW4NCmJ5IHJlYXNzaWduaW5nIGNoYW5naW5nIElQ IGFkZHJlc3NlcyBjb250aW51b3VzbHkgdG8gdGhlIFJEIGVuZC1wb2ludHMsIHRoZSBSRCB0YWtl cyBvdmVyIEROUyBmdW5jdGlvbmFsaXR5Pw0KDQoNCk5vdCBhdCBhbGwuIEROUyBqdXN0IHJlYWxs eSBpc24ndCB1c2VkIGluIE0yTSB0b2RheSwgYXMgaXQgaXMgdXN1YWxseSBub3QgcHJhY3RpY2Fs IG9yIGV2ZW4gcG9zc2libGUgdG8gdXBkYXRlIEROUyBlbnRyaWVzIHdoZW4gbm9kZXMgYXJlIG9m dGVuIGNoYW5naW5nIHRoZWlyIElQdjYgYWRkcmVzcyBkdWUgdG8gY2hhbmdlcyBpbiBwb2ludCBv ZiBhdHRhY2htZW50IG9yIGdldHRpbmcgZHluYW1pYyBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgZS5n LiBpbiBDZWxsdWxhciBuZXR3b3Jrcy4NCg0KDQoNCldvdWxkIGl0IG5vdCBiZSBiZXR0ZXIgdG8g a2VlcCBETlMgZnVuY3Rpb25hbGl0eSBvdXRzaWRlIHRoZSBSRCwgdXNlIEZRRE5zLCBhbmQgb25s eSB1c2UgSVAgYWRkcmVzc2VzIHdoZW4gdGhlIGVudmlyb25tZW50IGRvZXMgbm90IHN1cHBvcnQg RE5TLg0KSW4gdGhlIGxhdHRlciBjYXNlIEkgZG8gbm90IHNlZSB0aGUgSVAgYWRkcmVzc2VzIGNo YW5naW5nIHZlcnkgZnJlcXVlbnRseSwgYmVjYXVzZSB0aGVyZSBpcyBubyBJUCBwcm92aWRlciBl aXRoZXIuDQoNCg0KSW4gdGhlb3J5IGFuIFJEIGNvdWxkIGtlZXAgdHJhY2sgb2YgdGhlIElQIGFk ZHJlc3NlcyBvZiByZWdpc3RlcmVkIG5vZGVzIHVzaW5nIEROUywgYnV0IHRoYXQgaXMgcmVhbGx5 IGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIGFuZCBub3QgYW4gaW50ZXJmYWNlIHNwZWNpZmljYXRp b24gb25lLg0KDQpaYWNoDQoNCg0KDQoNCkdyZWV0aW5ncywNCg0KcGV0ZXINCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVy IGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBh ZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBh cmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlv biwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJv eSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K --_000_031DD135F9160444ABBE3B0C36CED618B76082011DB3MPN2081MGDP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hfQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhc30NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiOw0KCWNvbG9yOmJsYWNrfQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmV9DQpwcmUNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNr fQ0KdHQNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3In0NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bWFyZ2luLXRvcDow Y207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVm dDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFja30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6 YmxhY2t9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0R9DQouTXNvQ2hwRGVmYXVsdA0KCXtmb250LXNpemU6MTAu MHB0fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe21hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHR9DQpkaXYuV29yZFNlY3Rpb24xDQoJe30NCi0tPg0KPC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVs bG8gRmxvcmlzLCBaYWNoLDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgU2hvdWxkbid0IHRoZSBkZWZhdWx0IHZhbHVlIGZvciB0 aGUgY29uIHBhcmFtZXRlciBpbiBzZWN0aW9uIDUuMiBhbHNvIGJlIHRoZSAnZGVmYXVsdCBkaXNj b3ZlcnkgVVJJJyBhcyBpbiBzZWN0aW9uIDQ/IFRoZSBkcmFmdCBzdGF0ZXMgdG8gdXNlIHRoZSBz b3VyY2UgcG9ydCBhcyB0aGUgY29udGV4dCBwb3J0LCBob3dldmVyIHRoaXMgcG9ydCB3aWxsIHVz dWFsbHkgYmUgYSBjbGllbnQgcG9ydCBhbmQgd2lsbA0KIGRpZmZlciBmcm9tIHRoZSBwb3J0IHRo ZSBlbmRwb2ludCBpcyBsaXN0ZW5pbmcgb24gKGUuZy4gcG9ydCA2MDAwMCB2cyA1NjgzKS4gPGJy Pg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7IGNvbG9yOiMxRjQ5N0QiPkdvb2QgcG9pbnQ7IG1heWJlIHRoZSByZWFzb24gdGhhdCBzb3Vy Y2UgcG9ydCBpcyB3cml0dGVuIGhlcmUgaXMsIHRoYXQgaXTigJlzIHRoZSBvbmx5IGluZm9ybWF0 aW9uIHRoYXQgaXMgYXZhaWxhYmxlIChpbiB0aGUgYWJzZW5jZSBvZiBpbmZvcm1hdGlvbiBvbiB0 aGUgcG9ydA0KIHRoZSBlbmRwb2ludCBpcyBsaXN0ZW5pbmcgb24gd2hlbiDigJhjb27igJkgaXMg bm90IGluY2x1ZGVkKS4gVGhhdCBpbXBsaWVzIHRoZSBjbGllbnQgaGFzIHRvIHVzZSBhcyBzb3Vy Y2UgcG9ydCB0aGUgc2FtZSBwb3J0IHRoYXQgaXQgaXMgbGlzdGVuaW5nIG9uLjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBkb24ndCBhZ3Jl ZSB0aGF0IHRoaXMgYSBjb250cmFkaWN0aW9uLCB0aGUgbGFzdCBsaW5lIG9mIDUuMzIgcmVmZXJz IHRvIHRoZSBVUkkgcXVlcnkgcGFyYW1ldGVycyB0aGF0IGFyZSBwYXNzZWQgb24gKGUuZy4gY29u LCBydCBhbmQgbHQpIGFuZCBub3QgdGhlIENvQVAgUGF5bG9hZC4gU28gaW4gbXkgdmlldyB0aGlz IHNob3VsZG4ndCBiZSBhbHRlcmVkLiBFbmZvcmNpbmcgdGhpcyBvbiB0aGUgcGF5bG9hZCBhcyB3 ZWxsLCB3b3VsZCBzZWVtIHRvIGltcGx5IHRoYXQgdGhlIHBheWxvYWQgd291bGQgYmUgYSBwYXRj aCBvZiBzb21lIHNvcnQgKHdoaWNoIHNlZW1zIHRvIGJlIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhl IGRvY3VtZW50KS48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFG NDk3RCI+VG8gbWUgaXTigJlzIG5vdCBjbGVhciBmcm9tIHRoZSB0ZXh0IHdoZXRoZXIgdGhlIFBV VCByZXF1ZXN0IHRvIGRvIGFuIHVwZGF0ZSBvdmVyd3JpdGVzIHRoZSBwcmV2aW91cyBlbnRyaWVz IGVudGlyZWx5ICh3aGljaCB3b3VsZCBiZSBtb3N0IFJFU1RmdWwpIG9yIHRoYXQNCiDigJx1cGRh dGXigJ0gaW1wbGllcyB0aGF0IG9ubHkgbmV3IGFuZC9vciBjaGFuZ2VkIHJlc291cmNlcyBhcmUg aW5jbHVkZWQgaW4gdGhlIHBheWxvYWQuIChUaGVuIEkgd291bGQgZXhwZWN0IGEgUE9TVCByYXRo ZXIgdGhhbiBQVVQpPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPk1heWJlIGFuIGlkZWEgaXMgYWxsb3dp bmcgYm90aCBQVVQgKHRvIG92ZXJ3cml0ZSBleGlzdGluZykgb3IgUE9TVCAodG8gdXBkYXRlIGV4 aXN0aW5nKSA/PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdE Ij5Fc2tvPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjp3 aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBj b2xvcjp3aW5kb3d0ZXh0Ij4gY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5GbG9yaXMgVmFuIGRlbiBBYmVlbGU8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5IDI4IEphbnVhcnkgMjAxMyAxMTozMzxicj4NCjxiPlRv OjwvYj4gWmFjaCBTaGVsYnk8YnI+DQo8Yj5DYzo8L2I+IENvcmU8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtjb3JlXSByZXNvdXJjZS1kaXJlY3RvcnktNDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgWmFjaCZhbXA7YWxsLDxicj4NCjxicj4NCkkgcmVhZCBhbmQgaW1wbGVtZW50ZWQgdGhl IGRyYWZ0IGFuZCBpbnRlcnByZXRlZCB0aGUgdXNhZ2Ugb2YgdGhlIGNvbiBwYXJhbWV0ZXIgdGhl IHNhbWUgd2F5IGFzIFphY2ggZGlkLCBpLmUuIHRvIGJlIHVzZWQgdG8gdXBkYXRlIHZvbGF0aWxl IElQIGFkZHJlc3NlcyB0aHVzIGVuc3VyaW5nIHRoZSByZWFjaGFiaWxpdHkgb2YgdGhlIHJlZ2lz dGVyZWQgZW5kcG9pbnQuPGJyPg0KPGJyPg0KSSBhbHNvIGhhdmUgYSBjb3VwbGUgb2YgY29tbWVu dHMvcXVlc3Rpb25zIGFib3V0IGRyYWZ0LXNoZWxieS1jb3JlLXJlc291cmNlLWRpcmVjdG9yeS0w NDo8YnI+DQoqIFNob3VsZG4ndCB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgdGhlIGNvbiBwYXJhbWV0 ZXIgaW4gc2VjdGlvbiA1LjIgYWxzbyBiZSB0aGUgJ2RlZmF1bHQgZGlzY292ZXJ5IFVSSScgYXMg aW4gc2VjdGlvbiA0PyBUaGUgZHJhZnQgc3RhdGVzIHRvIHVzZSB0aGUgc291cmNlIHBvcnQgYXMg dGhlIGNvbnRleHQgcG9ydCwgaG93ZXZlciB0aGlzIHBvcnQgd2lsbCB1c3VhbGx5IGJlIGEgY2xp ZW50IHBvcnQgYW5kIHdpbGwgZGlmZmVyIGZyb20gdGhlIHBvcnQNCiB0aGUgZW5kcG9pbnQgaXMg bGlzdGVuaW5nIG9uIChlLmcuIHBvcnQgNjAwMDAgdnMgNTY4MykuIDxicj4NCiogSW4gZHJhZnQt Ym9ybWFubi1jb3JlLXNpbXBsZS1zZXJ2ZXItZGlzY292ZXJ5LTAwIGEgZGVmaW5pdGlvbiBpcyBn aXZlbiBmb3IgdGhlICdkZWZhdWx0IGRpc2NvdmVyeSBVUkknLCBJIHdvdWxkIHN1Z2dlc3QgcmVm ZXJlbmNpbmcgaXQgb3IgYWRkaW5nIGl0IHRvIHRoZSBkb2N1bWVudCBpbiBzZWN0aW9uIDQuIFRo aXMgZGVmaW5pdGlvbiBkb2VzIGluY2x1ZGUgdGhlIGxpc3RlbmluZyBwb3J0IGluc3RlYWQgb2Yg dGhlIHNvdXJjZSBwb3J0Ljxicj4NCiogUGV0ZXIgd3JvdGU6PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7IG1hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5JbiB0aGUg ZXhhbXBsZSBvZiBzZWMgNS4zLCB0aGUgbGFzdCBsaW5lLCAmbHQ7L3NlbnNvcnMvbGlnaHQmZ3Q7 O2N0PTQxO3J0PeKAnWxpZ2h0THV4O2lmPeKAnXNlbnNvcuKAnSBpcyBpZGVudGljYWwgdG8gdGhl IDJuZCBsaW5lIGluIHRoZSBwYXlsb2FkIG9mIHRoZSBSZWdpc3RyYXRpb24gZXhhbXBsZS4gVGhp cyBjb250cmFkaWN0cyB0aGUgbGFzdCBsaW5lIG9mIHRoZSBpbnRybyBvZiBzZWMgNS4zMiBQYXJh bWV0ZXJzIChub3QgUGFyZW1ldGVycykgdGhhdCBoYXZlIG5vdCBjaGFuZ2VkIFNIT1VMRCBOT1Qg YmUgaW5jbHVkZWQgaW4gYW4gdXBkYXRlLiBCZXR0ZXIgcmVtb3ZlIG9yIGNoYW5nZSB0aGUgbGFz dCBsaW5lIGluIHRoZSBVcGRhdGUgZXhhbXBsZS48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+R29vZCBl eWUuIFdpbGwgY2hhbmdlIHRoYXQuPC9zcGFuPjwvdHQ+PC9wPg0KPHByZT4mbmJzcDs8L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkkgZG9uJ3QgYWdyZWUgdGhhdCB0aGlzIGEgY29udHJhZGljdGlvbiwg dGhlIGxhc3QgbGluZSBvZiA1LjMyIHJlZmVycyB0byB0aGUgVVJJIHF1ZXJ5IHBhcmFtZXRlcnMg dGhhdCBhcmUgcGFzc2VkIG9uIChlLmcuIGNvbiwgcnQgYW5kIGx0KSBhbmQgbm90IHRoZSBDb0FQ IFBheWxvYWQuIFNvIGluIG15IHZpZXcgdGhpcyBzaG91bGRuJ3QgYmUgYWx0ZXJlZC4gRW5mb3Jj aW5nIHRoaXMgb24gdGhlIHBheWxvYWQgYXMgd2VsbCwgd291bGQgc2VlbSB0byBpbXBseSB0aGF0 IHRoZSBwYXlsb2FkIHdvdWxkIGJlIGEgcGF0Y2ggb2Ygc29tZSBzb3J0ICh3aGljaCBzZWVtcyB0 byBiZSBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCkuPC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+KiBXaHkgcmV1c2UgdGhlIHJ0IGFjY3JvbnltIGZvciBlbmQgcG9pbnQgdHlw ZT8gVGhpcyBpcyBjb25mdXNpbmcgd2l0aCB0aGUgcmVzb3VyY2UgdHlwZSB0aGF0IGlzIGRlZmlu ZWQgaW4gUkZDIDY2OTAuIDwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiogVGhlcmUgaXMg c21hbGwgbWlzdGFrZSBpbiB0aGUgbGFzdCBleGFtcGxlIG9mIHNlY3Rpb24gNi4gVGhlIGV4YW1w bGUgc2hvdWxkIGJlIEdFVCAvcmQtbG9va3VwL2QgaW5zdGVhZCBvZiBHRVQgL3JkLWxvb2t1cC9k b21haW4gaW4gdGhlIEFTQ0lJIGZpZ3VyZSBhbmQgdGhlIGFjY29tcGFueWluZyB0ZXh0IGJlbmVh dGggaXQuPC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+UmVnYXJkcyw8L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GbG9y aXMgPC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gbWEgMjQgc2VwIDIwMTIg MTQ6MTU6MzYgQ0VTVCwgWmFjaCBTaGVsYnkgd3JvdGU6PGJyPg0KPGJyPg0KPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gU2VwIDI0LCAyMDEyLCBhdCAxMToxMiBBTSwgcGV0ZXIg dmFuIGRlciBTdG9rIHdyb3RlOjxicj4NCjxicj4NCjxicj4NCjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCkhpIFphY2gsPGJyPg0KPGJyPg0KSW4gcmVsYXRpb24gdG8gdGhlIHBvaW50 IGJlbG93LCBTb21lIHF1ZXN0aW9ucyByZW1haW4uPGJyPg0KPGJyPg0KPGJyPg0KPC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KSW4gc2VjIDUuMyB0aGUgY29uIHBhcmFtZXRlciBpcyBhbHNvIG1lbnRpb25l ZCB0byB1cGRhdGUgdGhlIGVudHJ5LiBJbiB0aGUgY2FzZSB0aGF0IHRoZSBob3N0OnBvcnQgY2hh bmdlcyBjb21wbGV0ZWx5LCBhIG5ldyBlbnRyeSBpcyByZXF1aXJlZCBJTU8uIE1heSBiZSByZW1v dmUgY29uIGZyb20gdXBkYXRlPzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KVGhlIHdob2xlIHBvaW50IG9mIGFuIHVwZGF0 ZSBpcyB0aGF0IGl0IHdvdWxkIHVwZGF0ZSBhIGNoYW5nZSBpbiB0aGU8YnI+DQppcDpwb3J0LCBh cyB0aGlzIGNhbiBoYXBwZW4gb2Z0ZW4uIFRoaXMgd2F5IHRoZSBlbmRwb2ludCBuYW1lIGluIHRo ZTxicj4NClJEIGlzIHN0YWJsZSwgYW5kIGRvZXMgbm90IGNoYW5nZSBldmVuIHRob3VnaCB0aGUg aXA6cG9ydCB0dXBsZTxicj4NCmNoYW5nZXMuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KSSB1bmRlcnN0b29kIHRoYXQgY29uIGNvdWxkIGFsc28gYmUgdXNlZCB3aXRoIGEg c2NoZW1lIGFuZCBhIEZRRE48YnI+DQplLmcuIGNvbj1jb2FwOi8vbXlub2RlLmV4YW1wbGUuY29t PGJyPg0KSSBob3BlIHRoYXQgaXMgY29ycmVjdC48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQpTdXJlLCBhc3N1bWluZyBzdWNoIGFuIEZRRE4gZXhpc3RzIChvZnRlbiB0aW1l cyB0aGF0IGlzIG5vdCB0aGUgY2FzZSBpbiBNMk0gaG93ZXZlcikuPGJyPg0KPGJyPg0KPGJyPg0K PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KRm9sbG93aW5nIHlvdXIgcmVhc29uaW5n IHdoZW4gdXNpbmcgaG9zdDpwb3J0LCB0aGVuPGJyPg0KYnkgcmVhc3NpZ25pbmcgY2hhbmdpbmcg SVAgYWRkcmVzc2VzIGNvbnRpbnVvdXNseSB0byB0aGUgUkQgZW5kLXBvaW50cywgdGhlIFJEIHRh a2VzIG92ZXIgRE5TIGZ1bmN0aW9uYWxpdHk/PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KTm90IGF0IGFsbC4gRE5TIGp1c3QgcmVhbGx5IGlzbid0IHVzZWQgaW4gTTJNIHRv ZGF5LCBhcyBpdCBpcyB1c3VhbGx5IG5vdCBwcmFjdGljYWwgb3IgZXZlbiBwb3NzaWJsZSB0byB1 cGRhdGUgRE5TIGVudHJpZXMgd2hlbiBub2RlcyBhcmUgb2Z0ZW4gY2hhbmdpbmcgdGhlaXIgSVB2 NiBhZGRyZXNzIGR1ZSB0byBjaGFuZ2VzIGluIHBvaW50IG9mIGF0dGFjaG1lbnQgb3IgZ2V0dGlu ZyBkeW5hbWljIElQIGFkZHJlc3MgYXNzaWdubWVudCBlLmcuIGluDQogQ2VsbHVsYXIgbmV0d29y a3MuPGJyPg0KPGJyPg0KPGJyPg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV291 bGQgaXQgbm90IGJlIGJldHRlciB0byBrZWVwIEROUyBmdW5jdGlvbmFsaXR5IG91dHNpZGUgdGhl IFJELCB1c2UgRlFETnMsIGFuZCBvbmx5IHVzZSBJUCBhZGRyZXNzZXMgd2hlbiB0aGUgZW52aXJv bm1lbnQgZG9lcyBub3Qgc3VwcG9ydCBETlMuPGJyPg0KSW4gdGhlIGxhdHRlciBjYXNlIEkgZG8g bm90IHNlZSB0aGUgSVAgYWRkcmVzc2VzIGNoYW5naW5nIHZlcnkgZnJlcXVlbnRseSwgYmVjYXVz ZSB0aGVyZSBpcyBubyBJUCBwcm92aWRlciBlaXRoZXIuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KSW4gdGhlb3J5IGFuIFJEIGNvdWxkIGtlZXAgdHJhY2sgb2YgdGhlIElQ IGFkZHJlc3NlcyBvZiByZWdpc3RlcmVkIG5vZGVzIHVzaW5nIEROUywgYnV0IHRoYXQgaXMgcmVh bGx5IGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIGFuZCBub3QgYW4gaW50ZXJmYWNlIHNwZWNpZmlj YXRpb24gb25lLjxicj4NCjxicj4NClphY2g8YnI+DQo8YnI+DQo8YnI+DQo8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpHcmVldGluZ3MsPGJyPg0KPGJyPg0KcGV0ZXI8L3A+ DQo8L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6 ZT0iMSI+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNv bmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRo ZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQN CiB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlv biBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFj dCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0 aGUgb3JpZ2luYWwgbWVzc2FnZS48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_031DD135F9160444ABBE3B0C36CED618B76082011DB3MPN2081MGDP_-- From trac+core@trac.tools.ietf.org Mon Jan 28 05:59:39 2013 Return-Path: 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 9BC3A21F86E8 for ; Mon, 28 Jan 2013 05:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7FVxQA+8-gIw for ; Mon, 28 Jan 2013 05:59:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D018D21F846B for ; Mon, 28 Jan 2013 05:59:38 -0800 (PST) Received: from localhost ([127.0.0.1]:60326 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TzpFE-0002Mn-I5; Mon, 28 Jan 2013 14:59:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 28 Jan 2013 13:59:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/275#comment:1 Message-ID: <075.c956481bb7200784ed68f9f7a0d010e5@trac.tools.ietf.org> References: <060.2b194b08521b8e50525de5005e1f6720@trac.tools.ietf.org> X-Trac-Ticket-ID: 275 In-Reply-To: <060.2b194b08521b8e50525de5005e1f6720@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130128135938.D018D21F846B@ietfa.amsl.com> Resent-Date: Mon, 28 Jan 2013 05:59:38 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #275: Add multicast congestion control guideline: use of core-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:59:39 -0000 #275: Add multicast congestion control guideline: use of core-block Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Added in r1176 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Jan 28 06:32:33 2013 Return-Path: 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 26A6921F8918 for ; Mon, 28 Jan 2013 06:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 86JGs3rlxvPO for ; Mon, 28 Jan 2013 06:32:32 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2C721F8467 for ; Mon, 28 Jan 2013 06:32:32 -0800 (PST) Received: from localhost ([127.0.0.1]:34151 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tzpl9-0002lD-1v; Mon, 28 Jan 2013 15:32:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Mon, 28 Jan 2013 14:32:31 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/273#comment:2 Message-ID: <075.ee190f01b3fdbabaf16ebc2d754a59c5@trac.tools.ietf.org> References: <060.a27f62e00f2d05b781ab5068c8e0d20e@trac.tools.ietf.org> X-Trac-Ticket-ID: 273 In-Reply-To: <060.a27f62e00f2d05b781ab5068c8e0d20e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #273: Include guidelines on when (not) to use CoAP response to multicast request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 14:32:33 -0000 #273: Include guidelines on when (not) to use CoAP response to multicast request Changes (by esko.dijk@philips.com): * status: assigned => closed * resolution: => fixed Comment: Added in r1177 -- -----------------------------------+------------------------------------ Reporter: esko.dijk@philips.com | Owner: esko.dijk@philips.com Type: task | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------------+------------------------------------ Ticket URL: core From wasilak@gmail.com Mon Jan 28 11:42:57 2013 Return-Path: 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 1CDF221F8783 for ; Mon, 28 Jan 2013 11:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 DsNWGQm8FqFI for ; Mon, 28 Jan 2013 11:42:53 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id E97C221F8763 for ; Mon, 28 Jan 2013 11:42:52 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id fn15so2017500wgb.32 for ; Mon, 28 Jan 2013 11:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=roESdGoLl1qcGpcwrhhti3imI0Ba7TaL8YkFY6WPzUQ=; b=sBicKpkXda8wtC5sPATXDya5utXgu7se9R/4m5lPVSm+FGQxQeYwTsfWac/Xgb6RX2 R3yNFMFBiPf9bcYd1ywiwKLZ4P15JxW2mBkTERqL8oDtdK2DkmqQk7b/W+hdJDyhu62T ix7q86XQRYpf9Z7m+ZusPbbv1/m38ZKB9AmuVdM7Ee+EYTKE/PA1zJeCRoqlQwedumoC Kt0ssNjrplnhk0EJWJ9l1C9rz4NHEb4NsTrRndHZQb5nbfVpvD60po/HQQHP+X4Gl2xj RoY+o2TRSjvo606pleC33Kb7BGyeyBYWTQlqDOVQlNfzjwHvcVQkBq17UaIb9wvXlcPP GqMA== MIME-Version: 1.0 X-Received: by 10.180.103.136 with SMTP id fw8mr11689140wib.27.1359402171902; Mon, 28 Jan 2013 11:42:51 -0800 (PST) Received: by 10.216.255.140 with HTTP; Mon, 28 Jan 2013 11:42:51 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D8F3@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <4AE25BDF-9CAA-4AF6-BBD3-4460D7086E02@tzi.org> <46A1DF3F04371240B504290A071B4DB63CB1D8F3@szxeml509-mbx> Date: Mon, 28 Jan 2013 20:42:51 +0100 Message-ID: From: Maciej Wasilak To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=f46d04430446902a4504d45e7b4e Cc: "core@ietf.org WG" Subject: Re: [core] BG4 -- empty ACKs (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 19:42:57 -0000 --f46d04430446902a4504d45e7b4e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I think we should add text that server MUST echo the token from the last client request in every separate response block. Without it it's hard to tell apart two incoming blockwise responses (even for different resources). Best Regards Maciej Wasilak 2012/12/27 Bert Greevenbosch > Hi Carsten, > > > We had a long discussion of this in Sophia-Antipolis (ETSI CoAP2). > This needs to be fixed in -block. > ... > The conclusion from this discussion was that it is a good thing to keep > empty ACKs empty so they can be left out when running CoAP over alternate > transports that have their own reliability mechanisms, such as SMS or TCP= . > > > Yes, that makes a lot of sense. Then indeed it is best to fix it in the > Block draft. > > B.T.W. The below sequence could also make sense when the client sent a > PUT/POST request without Block, but the server needs to use Block in its > response. Would it then would be something like below? > > CLIENT SERVER > | | > | CON [MID=3D1234], POST, /soap ------> | > | | > | <------ ACK [MID=3D1236], 0 | > | | > | <------ CON [MID=3D4712], 2.01 Created, 2/0/1/128 | > | | > | ACK [MID=3D4712], 0 ------> | > | | > | <------ CON [MID=3D4713], 2.01 Created, 2/1/1/128 | > | | > | ACK [MID=3D4713], 0 ------> | > | | > | <------ CON [MID=3D4714], 2.01 Created, 2/2/1/128 | > | | > | ACK [MID=3D4714], 0 ------> | > | | > | <------ CON [MID=3D4715], 2.01 Created, 2/3/0/128 | > | | > | ACK [MID=3D4715], 0 ------> | > > Best regards, > Bert > > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: 21 December 2012 15:47 > To: Bert Greevenbosch > Cc: core@ietf.org WG > Subject: BG4 -- empty ACKs (Re: [core] draft-ietf-core-coap-13 WGLC - my > comments) > > On Dec 21, 2012, at 03:42, Bert Greevenbosch > wrote: > > > 4,T) p.21: "An empty message has a Code field set to 0. The Token Lengt= h > field MUST be set to 0 and no bytes MUST be present after the Message ID > field. If there are any bytes, they MUST be processed as a message format > error." > > p.32: "The Acknowledgement to the Confirmable response MUST also be an > empty message, i.e. one that carries neither a request nor a response." > > This is violated by figure 10 in the block-10 draft, where a block > option is included in the ACK from a CON response. Change here or in bloc= k? > > We had a long discussion of this in Sophia-Antipolis (ETSI CoAP2). > This needs to be fixed in -block. > (See my notes below.) > > > Maybe there will be future options that may need inclusion in ACKs to > CON responses too? > > The conclusion from this discussion was that it is a good thing to keep > empty ACKs empty so they can be left out when running CoAP over alternate > transports that have their own reliability mechanisms, such as SMS or TCP= . > > Gr=C3=BC=C3=9Fe, Carsten > > > Fixed examples for Block1-Block2 interaction: > (Needs to add discussion of "Initiative".) > > > Block options may be used in both directions of a single exchange. > The following example demonstrates a blockwise POST request, resulting > in a separate blockwise response. > > ~~~~~~~~~~~ > CLIENT SERVER > | | > | CON [MID=3D1234], POST, /soap, 1/0/1/128 ------> | > | | > | <------ ACK [MID=3D1234], 2.01 Created, 1/0/1/128 | > | | > | CON [MID=3D1235], POST, /soap, 1/1/1/128 ------> | > | | > | <------ ACK [MID=3D1235], 2.01 Created, 1/1/1/128 | > | | > | CON [MID=3D1236], POST, /soap, 1/2/0/128 ------> | > | | > | <------ ACK [MID=3D1236], 0 | > | | > | <------ CON [MID=3D4712], 2.01 Created, 2/0/1/128, 1/2/0/128 | > | | > | ACK [MID=3D4712], 0 ------> | > | | > | <------ CON [MID=3D4713], 2.01 Created, 2/1/1/128 | > | | > | ACK [MID=3D4713], 0 ------> | > | | > | <------ CON [MID=3D4714], 2.01 Created, 2/2/1/128 | > | | > | ACK [MID=3D4714], 0 ------> | > | | > | <------ CON [MID=3D4715], 2.01 Created, 2/3/0/128 | > | | > | ACK [MID=3D4715], 0 ------> | > ~~~~~~~~~~~ > {: #post-response title=3D"Atomic blockwise POST with separate blockwise > response" } > > This model does provide for early negotiation input to the > > ~~~~~~~~~~~ > CLIENT SERVER > | | > | CON [MID=3D1234], POST, /soap, 1/0/1/128 ------> | > | | > | <------ ACK [MID=3D1234], 2.01 Created, 1/0/1/128 | > | | > | CON [MID=3D1235], POST, /soap, 1/1/1/128 ------> | > | | > | <------ ACK [MID=3D1235], 2.01 Created, 1/1/1/128 | > | | > | CON [MID=3D1236], POST, /soap, 1/2/0/128, 2/0/0/64 ------> | > | | > | <------ ACK [MID=3D1236], 0 | > | | > | <------ CON [MID=3D4712], 2.01 Created, 1/2/0/128, 2/0/1/64 | > | | > | ACK [MID=3D4712], 0 ------> | > | | > | <------ CON [MID=3D4713], 2.01 Created, 2/1/1/64 | > | | > | ACK [MID=3D4713], 0 ------> | > | | > | <------ CON [MID=3D4714], 2.01 Created, 2/2/1/64 | > | | > | ACK [MID=3D4714], 0 ------> | > | | > | <------ CON [MID=3D4715], 2.01 Created, 2/3/0/64 | > | | > | ACK [MID=3D4715], 0 ------> | > ~~~~~~~~~~~ > {: #post-response-e title=3D"Atomic blockwise POST with separate blockwis= e > response, early negotiation" } > > THERE IS NO LATE NEGOTIATION... > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --f46d04430446902a4504d45e7b4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 SGVsbG8sPGJyPjxicj5JIHRoaW5rIHdlIHNob3VsZCBhZGQgdGV4dCB0aGF0IHNlcnZlciBNVVNU IGVjaG8gdGhlIHRva2VuIGZyb20gdGhlIGxhc3QgY2xpZW50IHJlcXVlc3QgaW4gZXZlcnkgc2Vw YXJhdGUgcmVzcG9uc2UgYmxvY2suIFdpdGhvdXQgaXQgaXQmIzM5O3MgaGFyZCB0byB0ZWxsIGFw YXJ0IHR3byBpbmNvbWluZyBibG9ja3dpc2UgcmVzcG9uc2VzIChldmVuIGZvciBkaWZmZXJlbnQg cmVzb3VyY2VzKS48ZGl2Pg0KPGJyPjwvZGl2PjxkaXY+QmVzdCBSZWdhcmRzPC9kaXY+PGRpdj5N YWNpZWogV2FzaWxhazxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTIvMTIvMjcg QmVydCBHcmVldmVuYm9zY2ggPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86QmVy dC5HcmVldmVuYm9zY2hAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkJlcnQuR3JlZXZlbmJv c2NoQGh1YXdlaS5jb208L2E+Jmd0Ozwvc3Bhbj48YnI+DQoNCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPkhpIENhcnN0ZW4sPGJyPg0KPGJyPg0KJmx0O3F1b3Rl Jmd0Ozxicj4NCjxkaXY+V2UgaGFkIGEgbG9uZyBkaXNjdXNzaW9uIG9mIHRoaXMgaW4gU29waGlh LUFudGlwb2xpcyAoRVRTSSBDb0FQMikuPGJyPg0KVGhpcyBuZWVkcyB0byBiZSBmaXhlZCBpbiAt YmxvY2suPGJyPg0KPC9kaXY+Li4uPGJyPg0KPGRpdj5UaGUgY29uY2x1c2lvbiBmcm9tIHRoaXMg ZGlzY3Vzc2lvbiB3YXMgdGhhdCBpdCBpcyBhIGdvb2QgdGhpbmcgdG8ga2VlcCBlbXB0eSBBQ0tz IGVtcHR5IHNvIHRoZXkgY2FuIGJlIGxlZnQgb3V0IHdoZW4gcnVubmluZyBDb0FQIG92ZXIgYWx0 ZXJuYXRlIHRyYW5zcG9ydHMgdGhhdCBoYXZlIHRoZWlyIG93biByZWxpYWJpbGl0eSBtZWNoYW5p c21zLCBzdWNoIGFzIFNNUyBvciBUQ1AuPGJyPg0KDQoNCjwvZGl2PiZsdDsvcXVvdGUmZ3Q7PGJy Pg0KPGJyPg0KWWVzLCB0aGF0IG1ha2VzIGEgbG90IG9mIHNlbnNlLiBUaGVuIGluZGVlZCBpdCBp cyBiZXN0IHRvIGZpeCBpdCBpbiB0aGUgQmxvY2sgZHJhZnQuPGJyPg0KPGJyPg0KQi5ULlcuIFRo ZSBiZWxvdyBzZXF1ZW5jZSBjb3VsZCBhbHNvIG1ha2Ugc2Vuc2Ugd2hlbiB0aGUgY2xpZW50IHNl bnQgYSBQVVQvUE9TVCByZXF1ZXN0IHdpdGhvdXQgQmxvY2ssIGJ1dCB0aGUgc2VydmVyIG5lZWRz IHRvIHVzZSBCbG9jayBpbiBpdHMgcmVzcG9uc2UuIFdvdWxkIGl0IHRoZW4gd291bGQgYmUgc29t ZXRoaW5nIGxpa2UgYmVsb3c/PGJyPg0KPGJyPg0KQ0xJRU5UIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgU0VSVkVS PGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgfCBDT04gW01JRD0xMjM0 XSwgUE9TVCwgL3NvYXAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS0tJmd0OyB8PGJyPg0K PGRpdj7CoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCB8ICZsdDstLS0tLS0gwqAg QUNLIFtNSUQ9MTIzNl0sIDAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxi cj4NCsKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCjwvZGl2PsKgIHwgJmx0Oy0tLS0t LSDCoCBDT04gW01JRD00NzEyXSwgMi4wMSBDcmVhdGVkLCAyLzAvMS8xMjggwqAgfDxicj4NCjxk aXY+wqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgfCBBQ0sgW01JRD00NzEyXSwg MCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLS0mZ3Q7IHw8YnI+ DQrCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCB8ICZsdDstLS0tLS0gwqAgQ09O IFtNSUQ9NDcxM10sIDIuMDEgQ3JlYXRlZCwgMi8xLzEvMTI4IMKgIHw8YnI+DQrCoCB8IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCB8IEFDSyBbTUlEPTQ3MTNdLCAwIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tLSZndDsgfDxicj4NCsKgIHwgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIHwgJmx0Oy0tLS0tLSDCoCBDT04gW01JRD00NzE0XSwg Mi4wMSBDcmVhdGVkLCAyLzIvMS8xMjggwqAgfDxicj4NCsKgIHwgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfDxicj4NCsKgIHwgQUNLIFtNSUQ9NDcxNF0sIDAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgLS0tLS0tJmd0OyB8PGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8PGJyPg0KwqAgfCAmbHQ7LS0tLS0tIMKgIENPTiBbTUlEPTQ3MTVdLCAyLjAxIENyZWF0ZWQs IDIvMy8wLzEyOCDCoCB8PGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAg fCBBQ0sgW01JRD00NzE1XSwgMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCAtLS0tLS0mZ3Q7IHw8YnI+DQo8YnI+DQo8L2Rpdj5CZXN0IHJlZ2FyZHMsPGJyPg0KQmVydDxi cj4NCjxkaXY+PGRpdj48YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciIHRh cmdldD0iX2JsYW5rIj5jYWJvQHR6aS5vcmc8L2E+XTxicj4NClNlbnQ6IDIxIERlY2VtYmVyIDIw MTIgMTU6NDc8YnI+DQpUbzogQmVydCBHcmVldmVuYm9zY2g8YnI+DQpDYzogPGEgaHJlZj0ibWFp bHRvOmNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jb3JlQGlldGYub3JnPC9hPiBXRzxi cj4NClN1YmplY3Q6IEJHNCAtLSBlbXB0eSBBQ0tzIChSZTogW2NvcmVdIGRyYWZ0LWlldGYtY29y ZS1jb2FwLTEzIFdHTEMgLSBteSBjb21tZW50cyk8YnI+DQo8YnI+DQpPbiBEZWMgMjEsIDIwMTIs IGF0IDAzOjQyLCBCZXJ0IEdyZWV2ZW5ib3NjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkJlcnQuR3Jl ZXZlbmJvc2NoQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5CZXJ0LkdyZWV2ZW5ib3NjaEBo dWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyA0LFQpIHAuMjE6ICZxdW90 O0FuIGVtcHR5IG1lc3NhZ2UgaGFzIGEgQ29kZSBmaWVsZCBzZXQgdG8gMC4gVGhlIFRva2VuIExl bmd0aCBmaWVsZCBNVVNUIGJlIHNldCB0byAwIGFuZCBubyBieXRlcyBNVVNUIGJlIHByZXNlbnQg YWZ0ZXIgdGhlIE1lc3NhZ2UgSUQgZmllbGQuIElmIHRoZXJlIGFyZSBhbnkgYnl0ZXMsIHRoZXkg TVVTVCBiZSBwcm9jZXNzZWQgYXMgYSBtZXNzYWdlIGZvcm1hdCBlcnJvci4mcXVvdDs8YnI+DQoN Cg0KJmd0OyBwLjMyOiAmcXVvdDtUaGUgQWNrbm93bGVkZ2VtZW50IHRvIHRoZSBDb25maXJtYWJs ZSByZXNwb25zZSBNVVNUIGFsc28gYmUgYW4gZW1wdHkgbWVzc2FnZSwgaS5lLiBvbmUgdGhhdCBj YXJyaWVzIG5laXRoZXIgYSByZXF1ZXN0IG5vciBhIHJlc3BvbnNlLiZxdW90Ozxicj4NCiZndDsg VGhpcyBpcyB2aW9sYXRlZCBieSBmaWd1cmUgMTAgaW4gdGhlIGJsb2NrLTEwIGRyYWZ0LCB3aGVy ZSBhIGJsb2NrIG9wdGlvbiBpcyBpbmNsdWRlZCBpbiB0aGUgQUNLIGZyb20gYSBDT04gcmVzcG9u c2UuIENoYW5nZSBoZXJlIG9yIGluIGJsb2NrPzxicj4NCjxicj4NCldlIGhhZCBhIGxvbmcgZGlz Y3Vzc2lvbiBvZiB0aGlzIGluIFNvcGhpYS1BbnRpcG9saXMgKEVUU0kgQ29BUDIpLjxicj4NClRo aXMgbmVlZHMgdG8gYmUgZml4ZWQgaW4gLWJsb2NrLjxicj4NCihTZWUgbXkgbm90ZXMgYmVsb3cu KTxicj4NCjxicj4NCiZndDsgTWF5YmUgdGhlcmUgd2lsbCBiZSBmdXR1cmUgb3B0aW9ucyB0aGF0 IG1heSBuZWVkIGluY2x1c2lvbiBpbiBBQ0tzIHRvIENPTiByZXNwb25zZXMgdG9vPzxicj4NCjxi cj4NClRoZSBjb25jbHVzaW9uIGZyb20gdGhpcyBkaXNjdXNzaW9uIHdhcyB0aGF0IGl0IGlzIGEg Z29vZCB0aGluZyB0byBrZWVwIGVtcHR5IEFDS3MgZW1wdHkgc28gdGhleSBjYW4gYmUgbGVmdCBv dXQgd2hlbiBydW5uaW5nIENvQVAgb3ZlciBhbHRlcm5hdGUgdHJhbnNwb3J0cyB0aGF0IGhhdmUg dGhlaXIgb3duIHJlbGlhYmlsaXR5IG1lY2hhbmlzbXMsIHN1Y2ggYXMgU01TIG9yIFRDUC48YnI+ DQoNCg0KPGJyPg0KR3LDvMOfZSwgQ2Fyc3Rlbjxicj4NCjxicj4NCjxicj4NCkZpeGVkIGV4YW1w bGVzIGZvciBCbG9jazEtQmxvY2syIGludGVyYWN0aW9uOjxicj4NCihOZWVkcyB0byBhZGQgZGlz Y3Vzc2lvbiBvZiAmcXVvdDtJbml0aWF0aXZlJnF1b3Q7Lik8YnI+DQo8YnI+DQo8YnI+DQpCbG9j ayBvcHRpb25zIG1heSBiZSB1c2VkIGluIGJvdGggZGlyZWN0aW9ucyBvZiBhIHNpbmdsZSBleGNo YW5nZS48YnI+DQpUaGUgZm9sbG93aW5nIGV4YW1wbGUgZGVtb25zdHJhdGVzIGEgYmxvY2t3aXNl IFBPU1QgcmVxdWVzdCwgcmVzdWx0aW5nPGJyPg0KaW4gYSBzZXBhcmF0ZSBibG9ja3dpc2UgcmVz cG9uc2UuPGJyPg0KPGJyPg0Kfn5+fn5+fn5+fn48YnI+DQpDTElFTlQgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgU0VSVkVSPGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHw8YnI+DQrCoCB8IENPTiBbTUlEPTEyMzRdLCBQT1NULCAvc29hcCwgMS8wLzEvMTI4IMKgIMKg IMKgLS0tLS0tJmd0OyDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCB8IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIHwgJmx0Oy0tLS0tLSDCoCBBQ0sgW01JRD0xMjM0 XSwgMi4wMSBDcmVhdGVkLCAxLzAvMS8xMjggwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgfCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCB8IENPTiBbTUlEPTEy MzVdLCBQT1NULCAvc29hcCwgMS8xLzEvMTI4IMKgIMKgIMKgLS0tLS0tJmd0OyDCoCDCoCDCoCDC oCDCoHw8YnI+DQrCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4N CsKgIHwgJmx0Oy0tLS0tLSDCoCBBQ0sgW01JRD0xMjM1XSwgMi4wMSBDcmVhdGVkLCAxLzEvMS8x MjggwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHw8YnI+DQrCoCB8IENPTiBbTUlEPTEyMzZdLCBQT1NULCAvc29hcCwgMS8yLzAv MTI4IMKgIMKgIMKgLS0tLS0tJmd0OyDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCB8IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIHwgJmx0Oy0tLS0tLSDCoCBBQ0sg W01JRD0xMjM2XSwgMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHw8YnI+DQrCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxi cj4NCsKgIHwgJmx0Oy0tLS0tLSDCoCBDT04gW01JRD00NzEyXSwgMi4wMSBDcmVhdGVkLCAyLzAv MS8xMjgsIDEvMi8wLzEyOCB8PGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHw8YnI+DQrCoCB8IEFDSyBbTUlEPTQ3MTJdLCAwIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tLSZndDsgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgfCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCB8ICZsdDstLS0tLS0g wqAgQ09OIFtNSUQ9NDcxM10sIDIuMDEgQ3JlYXRlZCwgMi8xLzEvMTI4IMKgIMKgIMKgIMKgIMKg IMKgfDxicj4NCsKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0K wqAgfCBBQ0sgW01JRD00NzEzXSwgMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCAtLS0tLS0mZ3Q7IMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIHwgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgfCAmbHQ7LS0tLS0tIMKgIENPTiBbTUlEPTQ3 MTRdLCAyLjAxIENyZWF0ZWQsIDIvMi8xLzEyOCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCB8 IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIHwgQUNLIFtNSUQ9 NDcxNF0sIDAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS0tJmd0 OyDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgfDxicj4NCsKgIHwgJmx0Oy0tLS0tLSDCoCBDT04gW01JRD00NzE1XSwgMi4wMSBDcmVh dGVkLCAyLzMvMC8xMjggwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCB8IEFDSyBbTUlEPTQ3MTVdLCAwIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tLSZndDsgwqAgwqAgwqAgwqAg wqB8PGJyPg0Kfn5+fn5+fn5+fn48YnI+DQp7OiAjcG9zdC1yZXNwb25zZSB0aXRsZT0mcXVvdDtB dG9taWMgYmxvY2t3aXNlIFBPU1Qgd2l0aCBzZXBhcmF0ZSBibG9ja3dpc2UgcmVzcG9uc2UmcXVv dDsgfTxicj4NCjxicj4NClRoaXMgbW9kZWwgZG9lcyBwcm92aWRlIGZvciBlYXJseSBuZWdvdGlh dGlvbiBpbnB1dCB0byB0aGU8YnI+DQo8YnI+DQp+fn5+fn5+fn5+fjxicj4NCkNMSUVOVCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBTRVJWRVI8YnI+DQrCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHw8YnI+DQrCoCB8IENPTiBbTUlEPTEyMzRdLCBQT1NULCAvc29hcCwgMS8wLzEv MTI4IC0tLS0tLSZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgfCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgfCAmbHQ7LS0tLS0tIMKgIEFDSyBbTUlE PTEyMzRdLCAyLjAxIENyZWF0ZWQsIDEvMC8xLzEyOCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAg fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgfCBDT04gW01JRD0x MjM1XSwgUE9TVCwgL3NvYXAsIDEvMS8xLzEyOCAtLS0tLS0mZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IMKgfDxicj4NCsKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKg IHwgJmx0Oy0tLS0tLSDCoCBBQ0sgW01JRD0xMjM1XSwgMi4wMSBDcmVhdGVkLCAxLzEvMS8xMjgg wqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfDxicj4NCsKgIHwgQ09OIFtNSUQ9MTIzNl0sIFBPU1QsIC9zb2FwLCAxLzIvMC8xMjgsIDIv MC8wLzY0IC0tLS0tLSZndDsgwqAgwqB8PGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8PGJyPg0KwqAgfCAmbHQ7LS0tLS0tIMKgIEFDSyBbTUlEPTEyMzZdLCAwIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCB8 IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCB8ICZsdDstLS0tLS0g wqAgQ09OIFtNSUQ9NDcxMl0sIDIuMDEgQ3JlYXRlZCwgMS8yLzAvMTI4LCAyLzAvMS82NCB8PGJy Pg0KwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgfCBBQ0sg W01JRD00NzEyXSwgMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0t LS0mZ3Q7IMKgIMKgIMKgIMKgIHw8YnI+DQrCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHw8YnI+DQrCoCB8ICZsdDstLS0tLS0gwqAgQ09OIFtNSUQ9NDcxM10sIDIuMDEgQ3Jl YXRlZCwgMi8xLzEvNjQgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgfCBBQ0sgW01JRD00NzEzXSwgMCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLS0mZ3Q7IMKgIMKgIMKgIMKgIHw8 YnI+DQrCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCB8ICZs dDstLS0tLS0gwqAgQ09OIFtNSUQ9NDcxNF0sIDIuMDEgQ3JlYXRlZCwgMi8yLzEvNjQgwqAgwqAg wqAgwqAgwqAgwqB8PGJyPg0KwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 PGJyPg0KwqAgfCBBQ0sgW01JRD00NzE0XSwgMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAtLS0tLS0mZ3Q7IMKgIMKgIMKgIMKgIHw8YnI+DQrCoCB8IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCB8ICZsdDstLS0tLS0gwqAgQ09OIFtNSUQ9 NDcxNV0sIDIuMDEgQ3JlYXRlZCwgMi8zLzAvNjQgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAg fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgfCBBQ0sgW01JRD00 NzE1XSwgMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLS0mZ3Q7 IMKgIMKgIMKgIMKgIHw8YnI+DQp+fn5+fn5+fn5+fjxicj4NCns6ICNwb3N0LXJlc3BvbnNlLWUg dGl0bGU9JnF1b3Q7QXRvbWljIGJsb2Nrd2lzZSBQT1NUIHdpdGggc2VwYXJhdGUgYmxvY2t3aXNl IHJlc3BvbnNlLCBlYXJseSBuZWdvdGlhdGlvbiZxdW90OyB9PGJyPg0KPGJyPg0KVEhFUkUgSVMg Tk8gTEFURSBORUdPVElBVElPTi4uLjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KY29yZSBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmVAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlPC9hPjxicj4NCjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+ DQo8L2Rpdj4NCg== --f46d04430446902a4504d45e7b4e-- From chrysn@fsfe.org Thu Jan 31 09:22:45 2013 Return-Path: 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 56D2A21F8414 for ; Thu, 31 Jan 2013 09:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_AT=0.745, J_CHICKENPOX_43=0.6, RDNS_DYNAMIC=0.1] 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 MTA1B7u7lQxr for ; Thu, 31 Jan 2013 09:22:44 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49D7721F84FC for ; Thu, 31 Jan 2013 09:22:42 -0800 (PST) Received: from mail.amsuess.com (vie-188-118-253-253.dsl.sil.at [188.118.253.253]) by prometheus.amsuess.com (Postfix) with ESMTPS id 22EC342AFB for ; Thu, 31 Jan 2013 18:22:38 +0100 (CET) Received: from hephaistos.amsuess.com (poseidon-stable [10.13.14.225]) by mail.amsuess.com (Postfix) with SMTP id EA8894C138 for ; Thu, 31 Jan 2013 18:22:36 +0100 (CET) Received: (nullmailer pid 3336 invoked by uid 1000); Thu, 31 Jan 2013 17:06:07 -0000 Date: Thu, 31 Jan 2013 18:06:07 +0100 From: chrysn To: core@ietf.org Message-ID: <20130131170606.GA14325@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [core] application/senml+json in coap content format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 17:22:45 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hello core people, as of experimenting with coap (especially core-interfaces), i'd like to transfer sensor data as application/senml+json. however, i didn't find any attempt to register that mime type at the content-format registry set up in draft-ietf-core-coap-13 -- even though extensive use thereof is made in the examples in draft-shelby-core-interfaces-03. * is there a type in use even though it's not yet published? * if not, what should i use until one gets allocated? * which document do i need to watch for a future allocation? (i'd assume draft-jennings-senml-10) * (being new here,) is this list the right place for such questions? * researching current use, i found a glitch in draft-shelby-core-interfaces-03 section 5.8 -- given what the response looks like, the answer to the GET request should be typed application/link-format. are there better places to report such things than here? best regards chrysn --=20 A beginning is the time for taking the most delicate care that the balances are correct. -- Princess Irulan, Manual of Muad'Dib --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRCqR2AAoJEDmNERLTpL3hAAcP/3byE0wAi6AZEqk4Q1KiqvtW NGeg8FxlNps+q+9PYnheLfybvmWK5WRrDgWKyrX2et/pM3T0IYU4RCrrr/zc8HZR 84gJz8H6kV/IJ8YwOLspXkU6tDYb6ANqvQWWdSWZ/490MTejxu33jeeYnB2uCt0E PPyythaE+IG1i25CKyJFtMO6ZjZUC6zG92CvBKgsEq6SegBpZg73N139ngAn7QNu xf9RH947lEAsOMmTkaH38QveWuPv8YI6mRK2rkQVrORTFoEmtxbvoDxu2RPLFy/s 5CF11B1l5C69Lst0Q3NU5L6TxNI7qF1PVs0Q+5pARQfrtB+kPzHNZ7tUY4sEMPSI PFltjPJwtx4g4b9m/KzN5wX02CLoihtq+CLelKlcZfbCN3+C3G6xt2PUqZFKlYRz 1lG0crRzmpJfLrTVptTFRjOTOvNfTlt9QZTsrh+GsYPiqTYx3gmU05aAWmx3PCGl EQ2ey6JXfV3+LFsdp4LgcgKaBZ97iW7Gh3jGHao3p/xr4CTu7fIxpqKvaJDZMcvG 0qY08hCT9Mim+Wii8jMSyyZQ7BthU8W171/7k3wme5+Kjoqnnvs7OBey6SSXTAzo 3Y9TImaDMCyiMEX6ORNc8GCQGsmAwprpwq/zATmxwsLCsetzzJcDzhd48K+iDOF6 wU+9W84hADuiBrDFOo4j =nEx9 -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From hartke@tzi.org Thu Jan 31 10:55:40 2013 Return-Path: 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 B2D7B21F8887 for ; Thu, 31 Jan 2013 10:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 u-NtHCCu3IPT for ; Thu, 31 Jan 2013 10:55:40 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A692421F86A9 for ; Thu, 31 Jan 2013 10:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r0VItVuW019316 for ; Thu, 31 Jan 2013 19:55:31 +0100 (CET) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0D277D2B for ; Thu, 31 Jan 2013 19:55:30 +0100 (CET) Received: by mail-vc0-f170.google.com with SMTP id p16so1982807vcq.1 for ; Thu, 31 Jan 2013 10:55:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.26.229 with SMTP id o5mr7869168vdg.66.1359658529449; Thu, 31 Jan 2013 10:55:29 -0800 (PST) Received: by 10.58.64.82 with HTTP; Thu, 31 Jan 2013 10:55:29 -0800 (PST) In-Reply-To: <20130131170606.GA14325@hephaistos.amsuess.com> References: <20130131170606.GA14325@hephaistos.amsuess.com> Date: Thu, 31 Jan 2013 20:55:29 +0200 Message-ID: From: Klaus Hartke To: chrysn Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] application/senml+json in coap content format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 18:55:40 -0000 Hi chrysn, chrysn wrote: > * is there a type in use even though it's not yet published? Not that I'm aware of. > * if not, what should i use until one gets allocated? For experimentation, you can use one of the numbers between 65000 and 65535 which have been reserved for this purpose. They must not be used in operational deployments though. > * which document do i need to watch for a future allocation? (i'd assume > draft-jennings-senml-10) IANA will maintain a registry of allocated numbers at [1], once draft-ietf-core-coap becomes an RFC. > * (being new here,) is this list the right place for such questions? The core-parameters mailing list [2] doesn't see much traffic yet. So, for the time being, I'd say yes. > * researching current use, i found a glitch in > draft-shelby-core-interfaces-03 section 5.8 -- given what the response > looks like, the answer to the GET request should be typed > application/link-format. are there better places to report such things > than here? You can contact the authors directly at [3]. But if the issue is of general interest, reporting it to this mailing list is appropriate as well. Best regards, Klaus [1] http://www.iana.org/assignments/core-parameters/core-parameters.xml [2] http://www.ietf.org/mailman/listinfo/core-parameters [3] mailto:draft-shelby-core-interfaces@tools.ietf.org