From nobody Thu Oct 9 01:25:17 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF581A0151 for ; Thu, 9 Oct 2014 01:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjX63CoY4Y9A for ; Thu, 9 Oct 2014 01:25:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E751A0074 for ; Thu, 9 Oct 2014 01:25:13 -0700 (PDT) Received: from localhost ([::1]:57349 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xc91y-0007SP-Kg; Thu, 09 Oct 2014 01:25:02 -0700 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-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 09 Oct 2014 08:25:01 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/366#comment:2 Message-ID: <075.35518c1a0997ca65cedaab15131a3c40@trac.tools.ietf.org> References: <060.d08ddf762931f56b1e0855733864e9d9@trac.tools.ietf.org> X-Trac-Ticket-ID: 366 In-Reply-To: <060.d08ddf762931f56b1e0855733864e9d9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, thomas.fossati@alcatel-lucent.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/bHUsI9ls0qKSzOG2kCHcSCGtvYA Cc: core@ietf.org Subject: Re: [core] #366 (http-mapping): Mapping of Link Format payloads to be valid in HTTP domain X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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, 09 Oct 2014 08:25:15 -0000 #366: Mapping of Link Format payloads to be valid in HTTP domain Comment (by esko.dijk@philips.com): Some discussion at the CoRE WG meeting at IETF90: - The Reverse Proxy (also called Gateway, RFC 7230) definition is that the proxy acts as if it is the origin server. That means it could include in its /.well-known/core resource all the entries of the origin CoAP servers that it proxies. This way the CoAP domain link-format is mapped correctly into the HTTP domain. - However, payload of CoAP messages may also contains URI links that are only valid in the CoAP domain. Translation of these is difficult for the proxy in the general case. - We may include some recommendation how to handle the above links (or links within links) case. - This problem is not CoAP specific, also HTTP cross-domain proxy has these issues -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: http- | Resolution: mapping | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Sun Oct 12 01:40:49 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E6F1A8956; Sun, 12 Oct 2014 01:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTBwLSVLyPRY; Sun, 12 Oct 2014 01:40:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D06D1A1B69; Sun, 12 Oct 2014 01:40:36 -0700 (PDT) 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.5/8.14.5) with ESMTP id s9C8eXPj015897; Sun, 12 Oct 2014 10:40:33 +0200 (CEST) Received: from [192.168.217.106] (p54891112.dip0.t-ipconnect.de [84.137.17.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 66B0CABA; Sun, 12 Oct 2014 10:40:32 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> Date: Sun, 12 Oct 2014 10:40:30 +0200 X-Mao-Original-Outgoing-Id: 434796030.617112-58a1dc33bdaf36152d29474fb6880c05 Content-Transfer-Encoding: quoted-printable Message-Id: <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, lwip@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/Ub0-k8_xpnVhjbREbupIz5YcTes Subject: [core] Constrained Node/Network Cluster @ IETF91, early draft version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 12 Oct 2014 08:40:41 -0000 A first draft version of the IETF91 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution, so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. =20 I notice there is no ROLL meeting in the agenda. The Constrained Node/Network group meetings are nicely spread out over = Mon-Thu, with a peak on Wednesday. I hope the social is bad, because that is about the only time between = the two CoRE meetings... All times are HST (UTC-1000) (use = https://datatracker.ietf.org/meeting/agenda-utc and press the button to = get your local time in case you want to listen in from remote). Gr=FC=DFe, Carsten MONDAY, November 10, 2014 0900-1130 Morning Session I Coral 2 APP appsawg Applications Area Working Group WG - = Combined with APPAREA Coral 4 OPS v6ops IPv6 Operations WG 1300-1500 Afternoon Session I Coral 4 RTG bier Bit Indexed Explicit Replication BOF 1520-1720 Afternoon Session II Coral 1 INT detnet Deterministic Networking BOF Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF Coral 3 OPS v6ops IPv6 Operations WG 1730-1830 Afternoon Session III Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF Coral 1 SEC *** dice DTLS In Constrained Environments WG TUESDAY, November 11, 2014 0900-1130 Morning Session I Coral 2 APP uta Using TLS in Applications WG Kahili 1/2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Coral 5 TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Coral 1 APP httpbis Hypertext Transfer Protocol WG Coral 4 RTG rtgarea Routing Area Open Meeting Coral 2 TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Coral 2 APP *** core Constrained RESTful Environments WG Coral 5 RAI webpush Web-Based Push Notifications WG WEDNESDAY, November 12, 2014 0900-1130 Morning Session I Kahili 1/2 APP *** core Constrained RESTful Environments WG Coral 3 INT homenet Home Networking WG Lehua Suite SEC oauth Web Authorization Protocol WG Coral 4 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1300-1500 Afternoon Session I Coral 5 SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Coral 4 APP httpbis Hypertext Transfer Protocol WG Kahili 1/2 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG THURSDAY, November 13, 2014 0900-1130 Morning Session I Coral 5 SEC tls Transport Layer Security WG Coral 2 TSV taps Transport Services WG 1300-1500 Afternoon Session I Coral 4 INT dnssd Extensions for Scalable DNS Service = Discovery WG Coral 3 SEC saag Security Area Open Meeting Coral 1 TSV tsvwg Transport Area Working Group WG 1520-1620 Afternoon Session II Coral 4 INT *** lwig Light-Weight Implementation Guidance WG FRIDAY, November 14, 2014 0900-1130 Morning Session I Coral 3 INT 6man IPv6 Maintenance WG Coral 1 TSV tcpinc TCP Increased Security WG 1150-1320 Afternoon Session I Coral 4 INT intarea Internet Area Working Group WG Coral 2 SEC httpauth Hypertext Transfer Protocol = Authentication WG From nobody Mon Oct 13 00:24:52 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9E41A88BD for ; Mon, 13 Oct 2014 00:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCTmszXssQyG for ; Mon, 13 Oct 2014 00:24:46 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 060161A88B8 for ; Mon, 13 Oct 2014 00:24:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEACp9O1SsEhcE/2dsb2JhbABbg2FYu0yNVYFjAQmHTYEuAX2EdwsfAwYgEk0iCBuIMK1yAQGVZgEBAQEGAQEBAQEdhU1ZiU4BAUsEEQyCIA9EJIEeBYtchySDO4g+PIMKlRxkAYEOgTsBAQE X-IPAS-Result: AqgEACp9O1SsEhcE/2dsb2JhbABbg2FYu0yNVYFjAQmHTYEuAX2EdwsfAwYgEk0iCBuIMK1yAQGVZgEBAQEGAQEBAQEdhU1ZiU4BAUsEEQyCIA9EJIEeBYtchySDO4g+PIMKlRxkAYEOgTsBAQE X-IronPort-AV: E=Sophos;i="5.04,708,1406572200"; d="scan'208";a="597987241" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id DBA6ADAC16; Mon, 13 Oct 2014 12:54:17 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id B1626DAC02; Mon, 13 Oct 2014 12:54:17 +0530 (IST) To: cabo@tzi.org MIME-Version: 1.0 X-KeepSent: 51D7B706:78AA14FF-65257D70:00268DDF; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Mon, 13 Oct 2014 12:54:15 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 10/13/2014 12:54:17, Serialize complete at 10/13/2014 12:54:17, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 10/13/2014 12:54:17 Content-Type: multipart/alternative; boundary="=_alternative 0028AC2C65257D70_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/qLFLZeA4frSrIxai8TQQTfsnnwY Cc: Arpan Pal , core@ietf.org Subject: [core] Regarding adoption of No-Response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 07:24:49 -0000 This is a multipart message in MIME format. --=_alternative 0028AC2C65257D70_= Content-Type: text/plain; charset="US-ASCII" Hi Carsten, The proposed no-response option for CoAP has been discussed in the mailing list for quite some time now and after the Toronto meeting it was decided to attempt for a consensus on whether the proposal should be adopted by the WG. We have already received couple of supportive responses in the mailing list: https://www.ietf.org/mail-archive/web/core/current/msg05523.html https://www.ietf.org/mail-archive/web/core/current/msg05525.html Also, many people expressed interest in such a useful-yet-simple-to-implement option in the past meetings and took part in several technical discussions in the mailing-list to share their views to take care of practical issues related to use of this option. The latest draft takes into account all of those and is available at: http://tools.ietf.org/id/draft-tcs-coap-no-response-option-07.txt Can we now come to a decision regarding whther to continue this work as a WG item prior to the IETF91 at Hawaii, or, may be, keep it in the agenda during the IETF91 to take a decision on this please? Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 0028AC2C65257D70_= Content-Type: text/html; charset="US-ASCII" Hi Carsten,
The proposed no-response option for CoAP has been discussed in the mailing list for quite some time now and after the Toronto meeting it was decided to attempt for a consensus on whether the proposal should be adopted by the WG. We have already received couple of supportive responses in the mailing list:
https://www.ietf.org/mail-archive/web/core/current/msg05523.html
https://www.ietf.org/mail-archive/web/core/current/msg05525.html

Also, many people expressed interest in such a useful-yet-simple-to-implement option in the past meetings and took part in several technical  discussions in the mailing-list to share their views to take care of practical issues related to use of this option.
The latest draft takes into account all of those and is available at: http://tools.ietf.org/id/draft-tcs-coap-no-response-option-07.txt

Can we now come to a decision regarding whther to continue this work as a WG item prior to the IETF91 at Hawaii, or, may be, keep it in the agenda during the IETF91 to take a decision on this please?

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 0028AC2C65257D70_=-- From nobody Mon Oct 13 07:08:48 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8220E1A8AEA; Mon, 13 Oct 2014 07:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47SbQ3mzzTzz; Mon, 13 Oct 2014 07:08:02 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF15E1A1AB5; Mon, 13 Oct 2014 07:08:01 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id uq10so10533246igb.13 for ; Mon, 13 Oct 2014 07:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jfihb82DIIkdckPyB32OtbTYa9yeSny+IPB5ndh0Eso=; b=EKB0sf/S8RQbXDSEd8U/BtqU94EFs4mE2vDI8SpzJfDBCwVrXQHUkP+lyEHhk6OxWh Q8zV6c0xtplrRp9t0eMwFLnfkRqxoAjQgNvwjjF1C0+aQMKvZILva/4lDvfb4tQj2JYw hyspeVBu01WwhyWPKqFvHpShQwgf+zZonSqKQq/+dkWH2/+SoSoq8B6pushVtSHdNO8b vGDfbuPxq0eJbmFt9CiCt1qjTl0HWQ0LGSoACfK/v5eM3G8m6hy/aT1rljVJQAGYQhe0 x5U/ZsBb7vsiu/0uq+bFeTzv9m2OjAWeOqeRGMh8PRt5BI8qCDzVuvaZzuxQI5WSNvcx 1fbg== MIME-Version: 1.0 X-Received: by 10.42.236.142 with SMTP id kk14mr37427059icb.9.1413209281164; Mon, 13 Oct 2014 07:08:01 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.163.3 with HTTP; Mon, 13 Oct 2014 07:08:01 -0700 (PDT) In-Reply-To: <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> Date: Mon, 13 Oct 2014 10:08:01 -0400 X-Google-Sender-Auth: M0_EFXlEBh63nqszumW0mnOngpc Message-ID: From: Barry Leiba To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/core/UFW24hoRaynso7CwPRgALKGSFEc Cc: lwip@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, dtls-iot@ietf.org, core , ace@ietf.org Subject: Re: [core] [Dtls-iot] Constrained Node/Network Cluster @ IETF91, early draft version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 14:08:04 -0000 Do you think the conflict between CORE and WEBPUSH is an issue that we should try to resolve? Barry From nobody Mon Oct 13 07:32:03 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8337B1A0146; Mon, 13 Oct 2014 07:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiIVMxUQGUJB; Mon, 13 Oct 2014 07:31:53 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194221A011B; Mon, 13 Oct 2014 07:30:34 -0700 (PDT) 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.5/8.14.5) with ESMTP id s9DEURKZ013492; Mon, 13 Oct 2014 16:30:27 +0200 (CEST) Received: from [192.168.217.113] (p54893EA6.dip0.t-ipconnect.de [84.137.62.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D40D14A6; Mon, 13 Oct 2014 16:30:26 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 13 Oct 2014 16:30:25 +0200 X-Mao-Original-Outgoing-Id: 434903424.999653-fad1173128c59a861aa97f8549987f5b Content-Transfer-Encoding: quoted-printable Message-Id: References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/4VC_t_Cnhkwh7JJ9VkCwH7ojb6g Cc: core , ace@ietf.org Subject: Re: [core] [Dtls-iot] Constrained Node/Network Cluster @ IETF91, early draft version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 14:31:55 -0000 On 13 Oct 2014, at 16:08, Barry Leiba wrote: > Do you think the conflict between CORE and WEBPUSH is an issue that we > should try to resolve? That is indeed a good question. I listed webpush in the cluster agenda because it could be of interest = in the context of proxying Observe and CoAP-MQ functionality into the = HTTP world and vice versa. I don=92t know whether there are going to be CoRE people in Hawaii who = would want to go contribute to the webpush WG. (I know that Klaus is = not coming, and I have heard a lot of grumpy noises about being able to = travel to Hawaii.) I certainly would like to go. But then I don=92t = know whether webpush will be relevant for the above mentioned purpose or = not. What do other CoRE/ACE people think? (Trimming the CC list a bit, because this is mostly an application space = issue.) (Oh, and I also wouldn=92t mind increasing the separation of the two = CoRE slots by moving the first around.) Gr=FC=DFe, Carsten From nobody Mon Oct 13 07:36:25 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7049E1A00F7; Mon, 13 Oct 2014 07:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq_HdxnUyyHS; Mon, 13 Oct 2014 07:36:22 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8848A1A0100; Mon, 13 Oct 2014 07:36:13 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so6466943lbv.5 for ; Mon, 13 Oct 2014 07:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jQY/3qPg3COHDBEWgTNs+N8wo2+JbZyuK5LaNTstMLk=; b=nwj3DzSJobiOe3BZzqseft+6XdR3ZcsjiU5hoO6LLlNKLHT4NwcUvL24XcR5fV9Tlh 3ydOhohn4cDlXr235mYxLVWTyQAgbjuXdl3EjC4XKfprm5TRwIZ99FATUm0LiBx/VVNZ KmXnM/jAogzjQXXaYB4VkzvqIlC2AiK6MCbUjVL4TLGV+Pzz89R8YzNGtOaF33Zs6Qw7 HRB9wlJoPcoIUI3fdhldmCh9cxsNCKbEYqnhqcnllCv3aTPvQ6zOmlBhjpmnQUqbOgdc 6fY2WX4YY9SlRU8MR5L8emQbTGmbtPmLHeMf8IncvmxlPM60041iB6Wc5UI7jivDJbyI FkpQ== MIME-Version: 1.0 X-Received: by 10.152.88.1 with SMTP id bc1mr842280lab.28.1413210970705; Mon, 13 Oct 2014 07:36:10 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Mon, 13 Oct 2014 07:36:10 -0700 (PDT) In-Reply-To: References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> Date: Mon, 13 Oct 2014 10:36:10 -0400 X-Google-Sender-Auth: xuaEFoTD7x6ZJyPd8VO2S5sMsxk Message-ID: From: Barry Leiba To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/TFwkLWZrO5m3THj3TufbJYepC00 Cc: core , "ace@ietf.org" Subject: Re: [core] [Dtls-iot] Constrained Node/Network Cluster @ IETF91, early draft version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 14:36:23 -0000 > (Oh, and I also wouldn't mind increasing the separation of the two CoRE slots by moving the first around.) It's VERY hard to move core... it has a very challenging conflict list. Barry From nobody Mon Oct 13 13:11:49 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986AF1A001A; Mon, 13 Oct 2014 13:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlTY4USWuLRA; Mon, 13 Oct 2014 13:10:42 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767A71A000E; Mon, 13 Oct 2014 13:10:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D2CF3E2035; Mon, 13 Oct 2014 16:10:40 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 03112-01; Mon, 13 Oct 2014 16:10:38 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 15302E2031; Mon, 13 Oct 2014 16:10:38 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s9DKAbMe016454; Mon, 13 Oct 2014 16:10:37 -0400 From: Derek Atkins To: Barry Leiba References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> Date: Mon, 13 Oct 2014 16:10:37 -0400 In-Reply-To: (Barry Leiba's message of "Mon, 13 Oct 2014 10:36:10 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/core/id_YvfEMPn4eSIFjVZCgIbOsjyE X-Mailman-Approved-At: Mon, 13 Oct 2014 13:11:47 -0700 Cc: core , "ace@ietf.org" Subject: Re: [core] [Ace] [Dtls-iot] Constrained Node/Network Cluster @ IETF91, early draft version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 20:10:51 -0000 Barry Leiba writes: >> (Oh, and I also wouldn't mind increasing the separation of the two > CoRE slots by moving the first around.) > > It's VERY hard to move core... it has a very challenging conflict list. As it is, half of core conflicts with oauth. :( > Barry -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Oct 13 13:39:54 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF32A1A000E; Mon, 13 Oct 2014 13:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vir9k_EocanA; Mon, 13 Oct 2014 13:39:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A981A000A; Mon, 13 Oct 2014 13:39:48 -0700 (PDT) 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.5/8.14.5) with ESMTP id s9DKdieX009748; Mon, 13 Oct 2014 22:39:45 +0200 (CEST) Received: from [192.168.217.113] (p54893EA6.dip0.t-ipconnect.de [84.137.62.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BF9376E0; Mon, 13 Oct 2014 22:39:43 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 13 Oct 2014 22:39:42 +0200 X-Mao-Original-Outgoing-Id: 434925581.810006-02f1d5cceedcffd8a3321d08850da60d Content-Transfer-Encoding: quoted-printable Message-Id: <4C043B72-A4C2-421F-A983-91BE6F4C48E3@tzi.org> References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> To: Derek Atkins X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/-IehAtQQQsEpP1DvgmXkwAbMEkQ Cc: Barry Leiba , core , "ace@ietf.org" Subject: Re: [core] [Ace] [Dtls-iot] Constrained Node/Network Cluster @ IETF91, early draft version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 20:39:50 -0000 On 13 Oct 2014, at 22:10, Derek Atkins wrote: >> It's VERY hard to move core... it has a very challenging conflict = list. >=20 > As it is, half of core conflicts with oauth. :( Yes, that is one of the compromises we incurred to keep scheduling = manageable. In the last few meetings, we asked to have at least *half* of the core = meeting to be free of conflicts with the most relevant security WGs. = Asking to have no such conflict on both meeting slots would make = scheduling even more impossible. (Both homenet and rmcat are additional = painful conflicts.) Gr=FC=DFe, Carsten From nobody Wed Oct 15 17:47:57 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599561A0070 for ; Wed, 15 Oct 2014 17:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WjJUa1TiSNZ for ; Wed, 15 Oct 2014 17:47:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907CC1A0059 for ; Wed, 15 Oct 2014 17:47:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNR69918; Thu, 16 Oct 2014 00:47:49 +0000 (GMT) Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Oct 2014 01:47:48 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.205]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 08:47:44 +0800 From: Likepeng To: "core@ietf.org" Thread-Topic: New Version Notification for draft-li-core-conditional-observe-05.txt Thread-Index: AQHP6GQLZwQnNNxBm0mVDW74cqFpPpwx5B/Q Date: Thu, 16 Oct 2014 00:47:43 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A5D53@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/3ZDVoQ1o9jYuu74i2PaXTvx9xpk Subject: [core] Fw: New Version Notification for draft-li-core-conditional-observe-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 00:47:54 -0000 SGVsbG8gYWxsLA0KDQpXZSB1cGRhdGVkIGNvbmRpdGlvbmFsIG9ic2VydmUgZHJhZnQuDQoNClRo aXMgdmVyc2lvbiBpcyBzaW1wbGlmaWVkIHRvIGNvbnRhaW4ganVzdCB0d28gb3B0aW9uczogTWF4 aW11bS1JbnRlcnZhbCBhbmQgTWluaW11bS1JbnRlcnZhbC4NCg0KV2VsY29tZSB5b3VyIGZlZWRi YWNrLg0KDQpUaGFua3MsDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCi0tLS0t6YKu5Lu25Y6f 5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNOW5tDEw5pyIMTXml6Ug MTg6MjUNCuaUtuS7tuS6ujogSmVyb2VuIEhvZWJla2U7IEplcm9lbiBIb2ViZWtlOyBMaWtlcGVu ZzsgQW50b25pbyBKLiBKYXJhOyBBbnRvbmlvIEouIEphcmE7IEZsb3JpcyBWYW4gZGVuIEFiZWVs ZTsgTGlzaGl0YW87IExpc2hpdGFvOyBGbG9yaXMgVmFuIGRlbiBBYmVlbGU7IExpa2VwZW5nDQrk uLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktY29yZS1jb25kaXRp b25hbC1vYnNlcnZlLTA1LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saS1j b3JlLWNvbmRpdGlvbmFsLW9ic2VydmUtMDUudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEtlcGVuZyBMaSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN Ck5hbWU6CQlkcmFmdC1saS1jb3JlLWNvbmRpdGlvbmFsLW9ic2VydmUNClJldmlzaW9uOgkwNQ0K VGl0bGU6CQlDb25kaXRpb25hbCBvYnNlcnZlIGluIENvQVANCkRvY3VtZW50IGRhdGU6CTIwMTQt MTAtMTUNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTE0DQpVUkw6ICAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktY29y ZS1jb25kaXRpb25hbC1vYnNlcnZlLTA1LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWNvcmUtY29uZGl0aW9uYWwtb2JzZXJ2ZS8N Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1jb3Jl LWNvbmRpdGlvbmFsLW9ic2VydmUtMDUNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saS1jb3JlLWNvbmRpdGlvbmFsLW9ic2VydmUtMDUNCg0K QWJzdHJhY3Q6DQogICBDb0FQIGlzIGEgUkVTVGZ1bCBhcHBsaWNhdGlvbiBwcm90b2NvbCBmb3Ig Y29uc3RyYWluZWQgbm9kZXMgYW5kDQogICBuZXR3b3Jrcy4gIFRocm91Z2ggdGhlIE9ic2VydmUg b3B0aW9uLCBjbGllbnRzIGNhbiBvYnNlcnZlIGNoYW5nZXMgaW4NCiAgIHRoZSBzdGF0ZSBvZiBy ZXNvdXJjZXMgYW5kIG9idGFpbiBhIGN1cnJlbnQgcmVwcmVzZW50YXRpb24gb2YgdGhlDQogICBs YXN0IHJlc291cmNlIHN0YXRlLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBuZXcgb3B0aW9u cyBmb3IgQ29BUA0KICAgT2JzZXJ2ZSBzbyB0aGF0IGEgQ29BUCBjbGllbnQgY2FuIHNwZWNpZnkg dGltaW5nIGNvbmRpdGlvbnMgd2hlbg0KICAgb2JzZXJ2aW5nIGEgcmVzb3VyY2Ugb24gYSBDb0FQ IHNlcnZlci4gIEFzIGEgcmVzdWx0LCB0aGUgQ29BUCBjbGllbnQNCiAgIGlzIG9ubHkgaW5mb3Jt ZWQgYWJvdXQgcmVzb3VyY2Ugc3RhdGUgY2hhbmdlcyB3aGVuIHRoZSB0aW1pbmcNCiAgIGNvbmRp dGlvbnMgYXJlIG1ldC4gIFRoaXMgb2ZmZXJzIHBvc3NpYmlsaXRpZXMgdG8gZXh0ZW5kIG5ldHdv cmsNCiAgIGludGVsbGlnZW5jZSwgZW5oYW5jZSBzY2FsYWJpbGl0eSwgYW5kIG9wdGltaXplIHRo ZSBsaWZldGltZSBhbmQNCiAgIHBlcmZvcm1hbmNlIGluIG9yZGVyIHRvIGFkZHJlc3MgdGhlIHJl cXVpcmVtZW50cyBmcm9tIHRoZSBDb25zdHJhaW5lZA0KICAgTm9kZXMgYW5kIE5ldHdvcmtzLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sat Oct 18 04:35:50 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17CE1A6FB9; Sat, 18 Oct 2014 04:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stMgleWfmA9Y; Sat, 18 Oct 2014 04:35:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B671A6F9A; Sat, 18 Oct 2014 04:35:36 -0700 (PDT) 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 mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9IBZWHE000960; Sat, 18 Oct 2014 13:35:33 +0200 (CEST) Received: from [192.168.217.113] (p54892213.dip0.t-ipconnect.de [84.137.34.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7A253E12; Sat, 18 Oct 2014 13:35:32 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> Date: Sat, 18 Oct 2014 13:35:31 +0200 X-Mao-Original-Outgoing-Id: 435324931.27575-9f5700bb96d21423e37a9b0134ec2caf Content-Transfer-Encoding: quoted-printable Message-Id: References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, lwip@ietf.org X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/core/HM3DzPpnq_a3ZCmabh1h7jJLDjM Subject: Re: [core] Constrained Node/Network Cluster @ IETF91, "final" version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 11:35:41 -0000 On 12 Oct 2014, at 10:40, Carsten Bormann wrote: > A first draft version of the IETF91 agenda is out. > ** THIS IS GOING TO CHANGE ** for conflict resolution, > so please don't make travel arrangements based on it. >=20 > Here is my usual eclectic condensed agenda built from that. =20 > All times are HST (UTC-1000) (use = https://datatracker.ietf.org/meeting/agenda-utc and press the button to = get your local time in case you want to listen in from remote). Here is an update with the =93final=94 agenda (caveat viator). Note the 6TiSCH move, and the newly scheduled JOSE meeting (across DICE, = ouch). Gr=FC=DFe, Carsten MONDAY, November 10, 2014 0900-1130 Morning Session I Coral 2 APP appsawg Applications Area Working Group WG - = Combined with APPAREA Coral 4 OPS v6ops IPv6 Operations WG 1300-1500 Afternoon Session I Coral 4 RTG bier Bit Indexed Explicit Replication BOF 1520-1720 Afternoon Session II Coral 1 INT detnet Deterministic Networking BOF Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF Coral 3 OPS v6ops IPv6 Operations WG 1730-1830 Afternoon Session III Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF Coral 1 SEC *** dice DTLS In Constrained Environments WG Rainbow Ste 1/2 SEC jose Javascript Object Signing and Encryption = WG TUESDAY, November 11, 2014 0900-1130 Morning Session I Coral 2 APP uta Using TLS in Applications WG Kahili 1/2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Coral 5 TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Coral 1 APP httpbis Hypertext Transfer Protocol WG Coral 4 RTG rtgarea Routing Area Open Meeting Coral 2 TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Coral 2 APP *** core Constrained RESTful Environments WG Coral 5 RAI webpush Web-Based Push Notifications WG WEDNESDAY, November 12, 2014 0900-1130 Morning Session I Kahili 1/2 APP *** core Constrained RESTful Environments WG Coral 3 INT homenet Home Networking WG Lehua Suite SEC oauth Web Authorization Protocol WG Coral 4 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1300-1500 Afternoon Session I Coral 5 SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Coral 4 APP httpbis Hypertext Transfer Protocol WG THURSDAY, November 13, 2014 0900-1130 Morning Session I Hibiscus 1/2 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Coral 5 SEC tls Transport Layer Security WG Coral 2 TSV taps Transport Services WG 1300-1500 Afternoon Session I Coral 4 INT dnssd Extensions for Scalable DNS Service = Discovery WG Coral 3 SEC saag Security Area Open Meeting Coral 1 TSV tsvwg Transport Area Working Group WG 1520-1620 Afternoon Session II Coral 4 INT *** lwig Light-Weight Implementation Guidance WG FRIDAY, November 14, 2014 0900-1130 Morning Session I Coral 3 INT 6man IPv6 Maintenance WG Coral 1 TSV tcpinc TCP Increased Security WG 1150-1320 Afternoon Session I Coral 4 INT intarea Internet Area Working Group WG Coral 2 SEC httpauth Hypertext Transfer Protocol = Authentication WG From nobody Mon Oct 20 02:23:28 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53481A7016 for ; Mon, 20 Oct 2014 02:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi-PWv_2_YAF for ; Mon, 20 Oct 2014 02:23:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1074F1A7013 for ; Mon, 20 Oct 2014 02:23:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNV35975; Mon, 20 Oct 2014 09:23:21 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Oct 2014 10:21:26 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.205]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Mon, 20 Oct 2014 17:21:20 +0800 From: Likepeng To: "core@ietf.org" Thread-Topic: Conflict endpoint idenfier for resource directory draft Thread-Index: Ac/sRzUGJ73qkLxbScuymQVXebZh0w== Date: Mon, 20 Oct 2014 09:21:19 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/VEfNLBcuZNepMJamtwUk7oveNnA Subject: [core] Conflict endpoint idenfier for resource directory draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 09:23:25 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38SZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Zach and all, I have one suggestion to the resource directory draft: https://tools.ietf.org/html/draft-ietf-core-resource-directory-01 Section 3.2: ep :=3D Endpoint (mandatory). The endpoint identifier or name of the registering node, unique within that domain. The maximum length of this parameter is 63 bytes. If an Endpoint registered itself to Resource Directory Server with a confli= cted ID, RD Server should return an error code to ask the endpoint to choos= e another identifier. Maybe we can add an error code to indicate the registered endpoint ID is co= nflict. Something like this: Failure: 5.0X "Endpoint Identifier Conflict". Endpoint identifier is con= flict. Thanks, Kind Regards Kepeng --_000_34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38SZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Zach and all,<= /span>

 

I have one suggestion to the re= source directory draft:

https://tools.ietf.org/html/= draft-ietf-core-resource-directory-01

 

Section 3.2:<= /p>

    &nbs= p; ep :=3D   Endpoint (mandatory).  The endpoint identifier = or name of

    &nbs= p;    the registering node, unique within that domain. = The maximum

    &nbs= p;    length of this parameter is 63 bytes.

 

If an Endpoint registered it= self to Resource Directory Server with a conflicted ID, RD Server should re= turn an error code to ask the endpoint to choose another identifier.

 

Maybe we can add an error co= de to indicate the registered endpoint ID is conflict. Something like this:=

 

Failure:  5.0X  &q= uot;Endpoint Identifier Conflict".  Endpoint identifier is confli= ct.

 

Thanks,

 

Kind Regards<= /p>

Kepeng

 

 

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38SZXEMA501MBSchi_-- From nobody Mon Oct 20 02:33:45 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796721A7022 for ; Mon, 20 Oct 2014 02:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhJqegj2EjJd for ; Mon, 20 Oct 2014 02:33:41 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53051A7020 for ; Mon, 20 Oct 2014 02:33:40 -0700 (PDT) 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 mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9K9XOxG026649; Mon, 20 Oct 2014 11:33:25 +0200 (CEST) Received: from [172.16.42.100] (p54891423.dip0.t-ipconnect.de [84.137.20.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B22EC6F5; Mon, 20 Oct 2014 11:33:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> Date: Mon, 20 Oct 2014 11:33:22 +0200 X-Mao-Original-Outgoing-Id: 435490402.281062-e3a51892bffe311d913148c06e0816d9 Content-Transfer-Encoding: quoted-printable Message-Id: <6253A048-6A69-49CA-B0CC-438D1789856F@tzi.org> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> To: Likepeng X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/core/QFLF8byExIgzzfAnkerkcqXm0no Cc: "core@ietf.org" Subject: Re: [core] Conflict endpoint idenfier for resource directory draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 09:33:42 -0000 Hi Kepeng, > Failure: 5.0X "Endpoint Identifier Conflict". Endpoint identifier = is conflict. Since this is not a server error, but a client error, this should be a = 4.xx. HTTP has 409, Conflict. RFC 7231: 6.5.8. 409 Conflict The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict. [=E2=80=A6] Should we aim at assigning 4.09? And what would be a good error payload? (cf. draft-ietf-appsawg-http-problem-00.txt) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 20 02:36:52 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1801A7026 for ; Mon, 20 Oct 2014 02:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49aKkJR65db2 for ; Mon, 20 Oct 2014 02:36:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91631A007E for ; Mon, 20 Oct 2014 02:36:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS68897; Mon, 20 Oct 2014 09:36:47 +0000 (GMT) Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Oct 2014 10:36:10 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.205]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Mon, 20 Oct 2014 17:36:07 +0800 From: Likepeng To: Carsten Bormann Thread-Topic: [core] Conflict endpoint idenfier for resource directory draft Thread-Index: Ac/sRzUGJ73qkLxbScuymQVXebZh0///fUEA//95iPA= Date: Mon, 20 Oct 2014 09:36:06 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C94@SZXEMA501-MBS.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> <6253A048-6A69-49CA-B0CC-438D1789856F@tzi.org> In-Reply-To: <6253A048-6A69-49CA-B0CC-438D1789856F@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/BrmhLt38Vx8yYGbZ-a9TnLljn5w Cc: "core@ietf.org" Subject: Re: [core] Conflict endpoint idenfier for resource directory draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 09:36:51 -0000 SGkgQ2Fyc3RlbiwNCg0KPlNob3VsZCB3ZSBhaW0gYXQgYXNzaWduaW5nIDQuMDk/DQoNCkFncmVl Lg0KDQo+QW5kIHdoYXQgd291bGQgYmUgYSBnb29kIGVycm9yIHBheWxvYWQ/DQoNCk1heWJlIHRo ZSBSRCBTZXJ2ZXIgY2FuIGdpdmUgYmFjayBhIHJlY29tbWVuZGVkIGlkZW50aWZpZXIuDQoNCktp bmQgUmVnYXJkcw0KS2VwZW5nDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bk uro6IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10NCj4g5Y+R6YCB5pe26Ze0 OiAyMDE05bm0MTDmnIgyMOaXpSAxNzozMw0KPiDmlLbku7bkuro6IExpa2VwZW5nDQo+IOaKhOmA gTogY29yZUBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbY29yZV0gQ29uZmxpY3QgZW5kcG9pbnQg aWRlbmZpZXIgZm9yIHJlc291cmNlIGRpcmVjdG9yeSBkcmFmdA0KPiANCj4gSGkgS2VwZW5nLA0K PiANCj4gPiBGYWlsdXJlOiAgNS4wWCAgIkVuZHBvaW50IElkZW50aWZpZXIgQ29uZmxpY3QiLiAg RW5kcG9pbnQgaWRlbnRpZmllciBpcw0KPiBjb25mbGljdC4NCj4gDQo+IFNpbmNlIHRoaXMgaXMg bm90IGEgc2VydmVyIGVycm9yLCBidXQgYSBjbGllbnQgZXJyb3IsIHRoaXMgc2hvdWxkIGJlIGEg NC54eC4NCj4gDQo+IEhUVFAgaGFzIDQwOSwgQ29uZmxpY3QuDQo+IA0KPiBSRkMgNzIzMToNCj4g DQo+IDYuNS44LiAgNDA5IENvbmZsaWN0DQo+IA0KPiAgICBUaGUgNDA5IChDb25mbGljdCkgc3Rh dHVzIGNvZGUgaW5kaWNhdGVzIHRoYXQgdGhlIHJlcXVlc3QgY291bGQgbm90DQo+ICAgIGJlIGNv bXBsZXRlZCBkdWUgdG8gYSBjb25mbGljdCB3aXRoIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSB0 YXJnZXQNCj4gICAgcmVzb3VyY2UuICBUaGlzIGNvZGUgaXMgdXNlZCBpbiBzaXR1YXRpb25zIHdo ZXJlIHRoZSB1c2VyIG1pZ2h0IGJlDQo+ICAgIGFibGUgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3Qg YW5kIHJlc3VibWl0IHRoZSByZXF1ZXN0LiAgVGhlIHNlcnZlcg0KPiAgICBTSE9VTEQgZ2VuZXJh dGUgYSBwYXlsb2FkIHRoYXQgaW5jbHVkZXMgZW5vdWdoIGluZm9ybWF0aW9uIGZvciBhIHVzZXIN Cj4gICAgdG8gcmVjb2duaXplIHRoZSBzb3VyY2Ugb2YgdGhlIGNvbmZsaWN0LiBb4oCmXQ0KPiAN Cj4gU2hvdWxkIHdlIGFpbSBhdCBhc3NpZ25pbmcgNC4wOT8NCj4gQW5kIHdoYXQgd291bGQgYmUg YSBnb29kIGVycm9yIHBheWxvYWQ/DQo+IChjZi4gZHJhZnQtaWV0Zi1hcHBzYXdnLWh0dHAtcHJv YmxlbS0wMC50eHQpDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQoNCg== From nobody Mon Oct 20 05:09:28 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908141A702C for ; Mon, 20 Oct 2014 05:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgsJOFYOsB5k for ; Mon, 20 Oct 2014 05:09:09 -0700 (PDT) Received: from ip2.rz.uni-luebeck.de (ip2.rz.uni-luebeck.de [141.83.100.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2529D1A7D84 for ; Mon, 20 Oct 2014 05:09:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAHT6RFSNU0Rk/2dsb2JhbABZA4MOU4NeyRoKh00CgREWAX2EAwEBAwEBAQEgJiUbCQIhHgMCAgINAhYfERMGAgEBiDMMCZIinE+UGAEBCAEBAQEejgyCKgsXEQWCYYFUBZQOgVCJK4YzBYcehxyDeWoBgkoBAQE X-IPAS-Result: AggFAHT6RFSNU0Rk/2dsb2JhbABZA4MOU4NeyRoKh00CgREWAX2EAwEBAwEBAQEgJiUbCQIhHgMCAgINAhYfERMGAgEBiDMMCZIinE+UGAEBCAEBAQEejgyCKgsXEQWCYYFUBZQOgVCJK4YzBYcehxyDeWoBgkoBAQE Received: from itm01.itm.uni-luebeck.de ([141.83.68.100]) by ip2.rz.uni-luebeck.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2014 14:09:03 +0200 Received: from [141.83.68.39] (belladonna.itm.uni-luebeck.de [141.83.68.39]) by itm01.itm.uni-luebeck.de (Postfix) with ESMTPA id 181CD83F8E4 for ; Mon, 20 Oct 2014 14:09:03 +0200 (CEST) Message-ID: <5444FB5E.60503@itm.uni-luebeck.de> Date: Mon, 20 Oct 2014 14:09:02 +0200 From: Oliver Kleine User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: core@ietf.org References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> <6253A048-6A69-49CA-B0CC-438D1789856F@tzi.org> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C94@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C94@SZXEMA501-MBS.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060805080904050604050508" Archived-At: http://mailarchive.ietf.org/arch/msg/core/mWOlv5FOQxPOrFRIjLQAllh12f8 Subject: Re: [core] Conflict endpoint idenfier for resource directory draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 12:09:18 -0000 This is a cryptographically signed message in MIME format. --------------ms060805080904050604050508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Kepeng and I already had a short discussion on the "level of uniqueness" for endpoint identifiers, i.e. unique per resource directory or global. >> And what would be a good error payload? >=20 > Maybe the RD Server can give back a recommended identifier. I think, that is a good approach to ensure unique identifiers per resource directory. Furthermore, I think, such an ID can be reused to replace the "additional address information" for request/response matching according to Section 5.3 of the CoAP RFC. I will update my draft on endpoint identification accordingly. Best, Oliver >=20 > Kind Regards > Kepeng >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Carsten Bormann [mailto:cabo@tzi.org] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B410=E6=9C=8820=E6=97= =A5 17:33 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Likepeng >> =E6=8A=84=E9=80=81: core@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [core] Conflict endpoint idenfier for resource= directory draft >> >> Hi Kepeng, >> >>> Failure: 5.0X "Endpoint Identifier Conflict". Endpoint identifier = is >> conflict. >> >> Since this is not a server error, but a client error, this should be a= 4.xx. >> >> HTTP has 409, Conflict. >> >> RFC 7231: >> >> 6.5.8. 409 Conflict >> >> The 409 (Conflict) status code indicates that the request could not= >> be completed due to a conflict with the current state of the target= >> resource. This code is used in situations where the user might be >> able to resolve the conflict and resubmit the request. The server >> SHOULD generate a payload that includes enough information for a us= er >> to recognize the source of the conflict. [=E2=80=A6] >> >> Should we aim at assigning 4.09? >> And what would be a good error payload? >> (cf. draft-ietf-appsawg-http-problem-00.txt) >> >> Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --=20 Oliver Kleine, M.Sc. UNIVERSIT=C3=84T ZU L=C3=9CBECK INSTITUT F=C3=9CR TELEMATIK Ratzeburger Allee 160 23538 L=C3=BCbeck Tel +49 451 500 5396 Fax +49 451 500 5382 kleine@itm.uni-luebeck.de www.itm.uni-luebeck.de/people/kleine --------------ms060805080904050604050508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPfDCC BNUwggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRww GgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3Qg Q2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIx MjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg LSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9 YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2Q RdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/B CaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7Pb D8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs 6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJ ei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGt IYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2 LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5o dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/D stU1gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTu IfJ1AuxSPtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23 NQIZz/U5RFhjpyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnY C8aEHwTG6x7on321e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIF RDCCBCygAwIBAgIHE0IjRucGSTANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJERTEgMB4G A1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJz aXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlMB4X DTEyMDEyNzEzMjUxMVoXDTE1MDEyNjEzMjUxMVowaTELMAkGA1UEBhMCREUxIDAeBgNVBAoT F1VuaXZlcnNpdGFldCB6dSBMdWViZWNrMSAwHgYDVQQLExdJbnN0aXR1dCBmdWVyIFRlbGVt YXRpazEWMBQGA1UEAxMNT2xpdmVyIEtsZWluZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALgYtjqHzX1LCD/4MZQaszSw5FlHUV+Xlupgjz/WU8QW8lYKxof09XP3fnvRpYfW MWs/QQzdmB4MS4w7VZpQ9azyt2BtQcT2lMHXxvi7N216uMFAu+hx5zc4GirYGhNLqID/hE8K zigxqIc4nW0bBWHnqTcra/eZp4FYWFDQ00E5FlCu5iBfKaDlQ3I22znxNhUmIIO2piFNo1Ls yvLFsxhge6FwnRb0fAXR2DAHOMOd+6zsaOoWUiHT2kXSpTgytadx3YLMBqVQE4t6P8ry+DH4 ge9iNRxVYIKPXt4V1aCAywUU/OTaXXWDhkYSdjvlvRLHg47eJRMxZOW2oaz0P0MCAwEAAaOC Ad0wggHZMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggr BgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUGaokk2F5DZlyqvd7U5PuTIn07tYwHwYD VR0jBBgwFoAUtytvwMcYEDE2F1IQdaHQQMM5NB8wJAYDVR0RBB0wG4EZa2xlaW5lQGl0bS51 bmktbHVlYmVjay5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvdW5pLWx1ZWJlY2stY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAy LnBjYS5kZm4uZGUvdW5pLWx1ZWJlY2stY2EvcHViL2NybC9jYWNybC5jcmwwgaIGCCsGAQUF BwEBBIGVMIGSMEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVi ZWNrLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIu cGNhLmRmbi5kZS91bmktbHVlYmVjay1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQEFBQADggEBADYFSngNYr+hIAIPFbRf7aF0aY1lwHNJdVyFKtCWNu/K7qqKXiXhTSg4 LGazzbriTAgHdvgcMoRvolspjhgsJ7SdOAtRyPFta/QTPeJMj4Hd/mAxkykuNVqYR18LYXyv VGhRHtOt19rXxpL40vl0OQGRBune06/XfnF5SHCAU+N2KTjbK+jLr77gZFa39nWLBIGB9fZK smTMclVvw2vBmPs6/uhoEzkYEAiDAmHnfOYYFPxAFFlwEIpLaHFKp5ZKxIZgvLdIZOGM0a2b oS2bHJhM3dsLNObw8GjvI8sizq79WWZxlMFqAInetvsd7aWCndOwpjUSi4fw1ZG4zWXlmpgw ggVXMIIEP6ADAgECAgcXr/bsXKnqMA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNVBAYTAkRFMRMw EQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVy ZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNjIxWhcNMTkwNzA5MjM1OTAwWjB7 MQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNV BAMTHkNBIGRlciBVbml2ZXJzaXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtp QHVuaS1sdWViZWNrLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlmUu5q+1 448Is2yl8dx0GMZN+vQcONK99YxpZzdJSZdnvlQsymtijkhp3UNnXzxBXxk0tegRIaX/Ejz2 AzxLDM/FkfxZ2XRRiuKqVdG+/qczey+MYJyqBti11miUdocoAm+nxthIj1k+3qLzeDyv7DV4 /+XpD313ciqw/X2zD4ZZfpk00fQ7AsqR+aAxjhQLDQJ94dIhOHWD05eu09yxoWJe1ne2fc0m UXw+mvpTpifOo4LgS9a36ucL3n8CL7BmWGMDk3/rmcjKLBWGZRjCQmNJvSTv2TaERnQxnb9Y hVUsXi9IptvIGc6ERGj23O6hWkysNMNpAqEThGIV5q6hQwIDAQABo4IB/zCCAfswEgYDVR0T AQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAowCDAGBgRVHSAAMB0GA1Ud DgQWBBS3K2/AxxgQMTYXUhB1odBAwzk0HzAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EK cD7eZDAdBgNVHREEFjAUgRJwa2lAdW5pLWx1ZWJlY2suZGUwgYgGA1UdHwSBgDB+MD2gO6A5 hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2Fjcmwu Y3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j cmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggrBgEFBQcwAYYnaHR0cDovL29j c3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsGAQUFBzAChjtodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggr BgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2Fj ZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAHWHmI/9W/Qy90CeDlzlpBibL8qt WOa1F5AafYH61r+IcB66IyQIM4En+g/X+HpkQJfOaufYPzG3BGuspMRWlasA53+9rz/PshO5 UU3+31+UcLV+Dlnakr3cC/8hEUXF5AtTkmaCzYFm1dy4FcdaqK0pURX9YOxhRqUc+vlnuVKc a20TS6QnLbvJyN4/v2H9IB3pj3eO/lLKicqiUhkdj0cHrNteObDd0ijSBsDbhg/ck99TBCBm 0GLOfrb1cMuHTy+et5K68npIgAojCHZZgLqtO4BGN3CXEKcUX0E+0xixOgNgQRxDgiP25qr8 X97JXm5RY6m1/+EPX7wQVeUYtokxggOzMIIDrwIBATCBhjB7MQswCQYDVQQGEwJERTEgMB4G A1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJz aXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlAgcT QiNG5wZJMAkGBSsOAwIaBQCgggIBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTAyMDEyMDkwMlowIwYJKoZIhvcNAQkEMRYEFDA6/DDJFm0pvalS5dBK vY5TH+vsMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgZcGCSsGAQQBgjcQBDGBiTCBhjB7MQswCQYDVQQGEwJERTEgMB4GA1UEChMX VW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJzaXRhZXQg enUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlAgcTQiNG5wZJ MIGZBgsqhkiG9w0BCRACCzGBiaCBhjB7MQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVy c2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJzaXRhZXQgenUgTHVl YmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlAgcTQiNG5wZJMA0GCSqG SIb3DQEBAQUABIIBAJpUjbWBXUnmrLRrS4TGAhUptwXPM29aGyenLdSW2d007G87V4FpqtDd YQzzk7YaKfwE8k972ZdikiQ7+eHeVxbsB9P6PaavF/Wnu/5UQEJuSFbe/+qKqJNYjtAT/Q4W ADQgVs+LXWgqJi5jIjm3b2yGiNwEKBppCLgLC2g/G5xSWw99KYdofXidsQy4IBPKJfo7+URI 3+4N/LoLAzf53+2UG0jBVB2vAbja2kVK7D3cQ5jndeUgGcKDdq1tHNeqKaW+9mIMh4VjxctZ /yG2Zmczu9wgR3aUxO4dZ4bX+Q/yZOVg/lxH+2yz3fYjBxNaM21Mgw+ffyMa3PsWpC1ThwkA AAAAAAA= --------------ms060805080904050604050508-- From nobody Mon Oct 20 08:16:04 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27551A8A7A for ; Mon, 20 Oct 2014 08:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNLuLakRmvHN for ; Mon, 20 Oct 2014 08:15:59 -0700 (PDT) Received: from smtp1.ugent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id E3DA71A8F3F for ; Mon, 20 Oct 2014 07:58:08 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp1.ugent.be (Postfix) with ESMTP id 182BD831F for ; Mon, 20 Oct 2014 16:58:08 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp1.ugent.be ([IPv6:::ffff:157.193.71.182]) by localhost (mcheck2.UGent.be [::ffff:157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 3LZtDOhcGPcr for ; Mon, 20 Oct 2014 16:58:04 +0200 (CEST) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp1.ugent.be (Postfix) with ESMTP id 6B82C815E for ; Mon, 20 Oct 2014 16:58:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 5BF2A33 for ; Mon, 20 Oct 2014 16:58:04 +0200 (CEST) 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 L8B4MTDsI3NR for ; Mon, 20 Oct 2014 16:58:04 +0200 (CEST) Received: from [157.193.135.206] (dhcp-zdpt-206.intec.ugent.be [157.193.135.206]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 468B730 for ; Mon, 20 Oct 2014 16:58:04 +0200 (CEST) Message-ID: <544522FC.3060809@intec.ugent.be> Date: Mon, 20 Oct 2014 16:58:04 +0200 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: core@ietf.org References: <54194E6E.7080902@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819D479@SZXEMA501-MBS.china.huawei.com> <541AC053.9000106@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819DB58@SZXEMA501-MBS.china.huawei.com> <541BEF16.2040200@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819E136@SZXEMA501-MBS.china.huawei.com> <5422BBF7.6070402@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819F6D5@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25819F986@SZXEMA501-MBS.china.huawei.com> <87tx3wp08d.fsf@tzi.org> <542920F9.8070006@itm.uni-luebeck.de> In-Reply-To: <542920F9.8070006@itm.uni-luebeck.de> Content-Type: multipart/alternative; boundary="------------080503000604030805080800" X-Miltered: at jchkm1 with ID 544522FC.008 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 544522FC.008 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 544522FC.008 on smtp1.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/core/y9i4AIntSE2mXkLIMHw4UYhtQ9g Subject: Re: [core] CoAP Endpoint Identification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 15:16:03 -0000 This is a multi-part message in MIME format. --------------080503000604030805080800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Apologies for reviving a three week old thread, but it might be interesting to poll the list on how people are addressing the issue of servers with changing IP addresses (i.e. mobile servers) today? I have considered using a proxy for this purpose (so that at least from the client's POV there is a stable IP address for its server), but the issue raised in Oliver's draft is obviously still present between the proxy and server. For the latter, I intended to use a Resource Directory to signal IP address changes (via the context parameter) and either have the proxy update its observe 'relationships' or just re-establish all observe 'relationships' with the server (with some information loss being a likely possibility, but as this is in-line with the eventual consistency goal of observe this might be OK for some use-cases). A simpler work-around (!) could be to use something like a mirror proxy and omit the problem entirely. By forcing the server to become a client this doesn't fall under the category of problems addressed by Oliver's, but it is a fairly straight-forward method for supporting mobile CoAP endpoints (with the added issue of synchronization between mirror server and the mobile client). Any comments from what people on the list have running today? Floris On 29-09-14 11:06, Oliver Kleine wrote: > Hi, > > Am 28.09.2014 um 07:12 schrieb weigengyu: > >> When Node ID (NID) or Endpoint ID (EID) is defined and every CoAP >> Endpoint has a unique ID that is never changed. > the term "never changed" is not exactly true for EIDs. Let me explain > that. I wanted the EIDs to be independent from any layers or other > components but the CoAP layer on just both endpoints. Every other layer= > has its identifiers with a certain lifetime, e.g. MAC addresses on the > network layer, IP addresses on the Internet layer and ports on the > transport layer. All of them are necessary to transfer data from one > source process to the other (maybe remote) destination process. > > The EID approach follows that well established tradition by defining an= > independent new identifier for the specific purpose of relating request= s > to responses and update notifications just for the necessary lifetime. > > In CoAP the mutually assigned EIDs are valid for the duration of one > conversation. A conversation is considered the the set of all messages > between two endpoints that share the same token instance, e.g. a single= > request/response pair or one request and an unbound set of update > notifications. > > Best, > Oliver > > >> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Olaf Bergmann >> Sent: Thursday, September 25, 2014 4:34 PM >> To: Likepeng >> Cc: core@ietf.org >> Subject: Re: [core] CoAP Endpoint Identification >> >> Kepeng, >> >> Likepeng writes: >> >>> Endpoint ID can be used as "Description" parameter in the >>> authorization request as mentioned in this draft. >>> http://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-authorize/ >>> >>> D: Description. A descriptive label of the initiator of the >>> authorization request. This label MAY be a fully qualified dom= ain >>> name, an IP address, or any other character literal that is use= d >>> by the Authorization Server to decide whether or not access is >>> granted to the requesting entity. >>> >>> For this parameter, IP address is not stable, domain name may not be >>> available. Endpoint ID is a good candidate. >> This was indeed our general mindset. >> >> Gruesse >> Olaf >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------080503000604030805080800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Apologies for reviving a three week old thread, but it might be interesting to poll the list on how people are addressing the issue of servers with changing IP addresses (i.e. mobile servers) today?

I have considered using a proxy for this purpose (so that at least from the client's POV there is a stable IP address for its server), but the issue raised in Oliver's draft is obviously still present between the proxy and server. For the latter, I intended to use a Resource Directory to signal IP address changes (via the context parameter) and either have the proxy update its observe 'relationships' or just re-establish all observe 'relationships' with the server (with some information loss being a likely possibility, but as this is in-line with the eventual consistency goal of observe this might be OK for some use-cases).

A simpler work-around (!) could be to use something like a mirror proxy and omit the problem entirely. By forcing the server to become a client this doesn't fall under the category of problems addressed by Oliver's, but it is a fairly straight-forward method for supporting mobile CoAP endpoints (with the added issue of synchronization between mirror server and the mobile client).

Any comments from what people on the list have running today?

Floris
On 29-09-14 11:06, Oliver Kleine wrote:
Hi,

Am 28.09.2014 um 07:12 schrieb weigengyu:


When Node ID (NID) or Endpoint ID (EID) is defined and every CoAP
Endpoint has a unique ID that is never changed.

the term "never changed" is not exactly true for EIDs. Let me explain
that. I wanted the EIDs to be independent from any layers or other
components but the CoAP layer on just both endpoints. Every other layer
has its identifiers with a certain lifetime, e.g. MAC addresses on the
network layer, IP addresses on the Internet layer and ports on the
transport layer. All of them are necessary to transfer data from one
source process to the other (maybe remote) destination process.

The EID approach follows that well established tradition by defining an
independent new identifier for the specific purpose of relating requests
to responses and update notifications just for the necessary lifetime.

In CoAP the mutually assigned EIDs are valid for the duration of one
conversation. A conversation is considered the the set of all messages
between two endpoints that share the same token instance, e.g. a single
request/response pair or one request and an unbound set of update
notifications.

Best,
Oliver



-----原始邮件----- From: Olaf Bergmann
Sent: Thursday, September 25, 2014 4:34 PM
To: Likepeng
Cc: core@ietf.org
Subject: Re: [core] CoAP Endpoint Identification

Kepeng,

Likepeng <likepeng@huawei.com> writes:


Endpoint ID can be used as "Description" parameter in the
authorization request as mentioned in this draft.
http://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-authorize/

      D: Description.  A descriptive label of the initiator of the
      authorization request.  This label MAY be a fully qualified domain
      name, an IP address, or any other character literal that is used
      by the Authorization Server to decide whether or not access is
      granted to the requesting entity.

For this parameter, IP address is not stable, domain name may not be
available. Endpoint ID is a good candidate.

This was indeed our general mindset.

Gruesse
Olaf

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


      

      

      

      
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


    

    

    

  


--------------080503000604030805080800--


From nobody Tue Oct 21 06:38:59 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93021A6F24 for ; Tue, 21 Oct 2014 06:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qHvNq8i6izc for ; Tue, 21 Oct 2014 06:38:56 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9223D1A6F21 for ; Tue, 21 Oct 2014 06:38:56 -0700 (PDT)
Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 21 Oct 2014 15:38:52 +0200
Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.03.0195.001;  Tue, 21 Oct 2014 15:38:54 +0200
From: "Kovatsch  Matthias" 
To: "core@ietf.org" 
Thread-Topic: [core] Conflict endpoint idenfier for resource directory draft
Thread-Index: Ac/sRzUGJ73qkLxbScuymQVXebZh0///4dYAgAAAwwCAACq7AP/+Ni4A
Date: Tue, 21 Oct 2014 13:38:53 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B52729395B@MBX110.d.ethz.ch>
References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> <6253A048-6A69-49CA-B0CC-438D1789856F@tzi.org> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C94@SZXEMA501-MBS.china.huawei.com> <5444FB5E.60503@itm.uni-luebeck.de>
In-Reply-To: <5444FB5E.60503@itm.uni-luebeck.de>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [211.221.118.252]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/core/HxDS_cIBylXMb1lawMvcYKi6IsE
Subject: Re: [core] Conflict endpoint idenfier for resource directory draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Oct 2014 13:38:59 -0000

PiBJZiBhbiBFbmRwb2ludCByZWdpc3RlcmVkIGl0c2VsZiB0byBSZXNvdXJjZSBEaXJlY3Rvcnkg
U2VydmVyDQo+IHdpdGggYSBjb25mbGljdGVkIElELCBSRCBTZXJ2ZXIgc2hvdWxkIHJldHVybiBh
biBlcnJvciBjb2RlIHRvDQo+ICBhc2sgdGhlIGVuZHBvaW50IHRvIGNob29zZSBhbm90aGVyIGlk
ZW50aWZpZXIuDQoNCk15IHF1ZXN0aW9uIGhlcmUgaXM6IEhvdyBzaG91bGQgdGhlIFJEIGtub3cg
dGhhdCB0aGlzIGlzIGEgY29uZmxpY3Q/DQpUaGUgcG9pbnQgb2YgdXNpbmcgdGhpcyBJRCBpcyB0
byBpZGVudGlmeSB0aGUgc2FtZSBlbmRwb2ludCBvdmVyIGNoYW5naW5nIGFkZHJlc3NlcyBvciBl
dmVuIHRyYW5zcG9ydHMgKGUuZy4sIFVEUCBhbmQgU01TKS4NCg0KVGhlIG5hdHVyYWwgcmVhY3Rp
b24gd291bGQgYmUgdG8gYXNzdW1lIHRoZSBlbmRwb2ludCBjcmFzaGVkIGFuZCBpcyBub3cgcmVn
aXN0ZXJpbmcgYWZ0ZXIgYSByZWJvb3QuIEFzIFphY2ggbWVudGlvbmVkIGluIHRoZSBvdGhlciB0
aHJlYWQsIHRoaXMgSUQgaXMgc29tZWhvdyBsaW5rZWQgdG8gdGhlIGVuZHBvaW50IGNlcnRpZmlj
YXRlLiBTbyB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZXJlIGlzIGFub3RoZXIgZW50aXR5IHRo
YXQgZW5zdXJlcyB1bmlxdWVuZXNzLg0KDQo+IFNob3VsZCB3ZSBhaW0gYXQgYXNzaWduaW5nIDQu
MDk/DQo+IEFuZCB3aGF0IHdvdWxkIGJlIGEgZ29vZCBlcnJvciBwYXlsb2FkPw0KDQpDb25zaWRl
cmluZyA0LjA5IGlzIHVzZWQgaW4gdGhlIE9NQSBMaWdodHdlaWdodCBNMk0gc3BlY2lmaWNhdGlv
biwgd2UgcHJvYmFibHkgc2hvdWxkIGRlZmluZSBpdC4gQXQgbGVhc3QgdGhlcmUgaXMgYSB1c2Ug
Y2FzZSBvdXQgdGhlcmUsIGdpdmVuIHRoYXQgd2UgY2FuIGZpZ3VyZSBvdXQgaG93IHRvIGtub3cg
dGhhdCBzb21ldGhpbmcgaXMgYSBjb25mbGljdCA6KQ0KDQpDaWFvDQpNYXR0aGlhcw0K


From nobody Tue Oct 21 07:09:14 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86E11A6F05 for ; Tue, 21 Oct 2014 07:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbTTGkZU8xZK for ; Tue, 21 Oct 2014 07:08:56 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E891A6EEC for ; Tue, 21 Oct 2014 07:08:55 -0700 (PDT)
Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 21 Oct 2014 16:08:51 +0200
Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0195.001;  Tue, 21 Oct 2014 16:08:53 +0200
From: "Kovatsch  Matthias" 
To: Floris Van den Abeele , "core@ietf.org" 
Thread-Topic: [core] CoAP Endpoint Identification
Thread-Index: AQHP0lZTZZ/1TyTTWU2wpWs2mQiGXJwGhy8AgAAYHoCAAVA/gIAAGK0AgAGbCgCABoBAgIAAwzoAgABpmACAABxygIAAJbcqgARc14CAAdOlgIAhY1IAgAGd1DA=
Date: Tue, 21 Oct 2014 14:08:52 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B5272BD487@MBX110.d.ethz.ch>
References: <54194E6E.7080902@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819D479@SZXEMA501-MBS.china.huawei.com> <541AC053.9000106@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819DB58@SZXEMA501-MBS.china.huawei.com> <541BEF16.2040200@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819E136@SZXEMA501-MBS.china.huawei.com> <5422BBF7.6070402@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819F6D5@SZXEMA501-MBS.china.huawei.com>  <34966E97BE8AD64EAE9D3D6E4DEE36F25819F986@SZXEMA501-MBS.china.huawei.com> <87tx3wp08d.fsf@tzi.org>  <542920F9.8070006@itm.uni-luebeck.de> <544522FC.3060809@intec.ugent.be>
In-Reply-To: <544522FC.3060809@intec.ugent.be>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [211.221.118.252]
Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B5272BD487MBX110dethzch_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/core/HFDRMh4Xz34kL7F424vIRK8yenc
Subject: Re: [core] CoAP Endpoint Identification
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Oct 2014 14:09:10 -0000

--_000_55877B3AFB359744BA0F2140E36F52B5272BD487MBX110dethzch_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRmxvcmlzDQoNCkkgdGhpbmsgaXQgaXMgZ29vZCB0byByZXZpdmUgdGhpcyB0aHJlYWQsIHNp
bmNlIHRoaXMgaXMgc3RpbGwgYW4gYWN0dWFsIHByb2JsZW0gYW5kIHRoZXJlIGlzIG5vIGdvb2Qg
c29sdXRpb24geWV0LCBhdCBsZWFzdCBubyBnb29kIG92ZXJhbGwgZGVzY3JpcHRpb24uDQoNCkEg
ZmVhc2libGUgd2F5IGlzIGRlZmluaXRlbHkgdG8gdXNlIHRoZSBSRCBhbm5vdW5jZSBhZGRyZXNz
IGNoYW5nZXMuDQpSZS1yZWdpc3RlcmluZyBvYnNlcnZlIHJlbGF0aW9uc2hpcHMgaXMgYWxzbyBu
b3QgdGhhdCBleHBlbnNpdmUsIHNvIEkgd291bGQgZG8gdGhpcyBpbnN0ZWFkIG9mIGEgZGlydHkg
aGFjayB0aGF0IG1vZGlmaWVzIHRoZSBvYnNlcnZlIHNlbWFudGljcy4NCklmIHRoZSBnb2FsIGlz
IGFsc28gdG8gcHJldmVudCBsb3Npbmcgbm90aWZpY2F0aW9uIChPbGl2ZXLigJlzIHByb2JsZW0p
LCBkcmFmdC1rb3N0ZXItY29yZS1jb2FwbXEgaXMgc29tZXRoaW5nIHRvIGxvb2sgaW50by4NCg0K
QSBwcm9ibGVtIEkgc2VlIHdpdGggdGhlIG1pcnJvciBwcm94eSBpcyB0aGF0IEkgd2lsbCBub3Qg
d29yayBmb3IgYWN0dWF0aW9uLCBpLmUuLCBpbiB0aGUgY2FzZSB3ZSB3YW50IHRvIHNlbmQgY29t
bWFuZHMgdG8gYSBkZXZpY2Ugd2l0aCBjaGFuZ2luZyBhZGRyZXNzZXMuDQoNCkNvbW1lbnRzIG9u
IE9saXZlcuKAmXMgcHJvcG9zYWw6IEFzIEhhbm5lcyBtZW50aW9uZWQsIGFuIElQIGFkZHJlc3Mg
Y2hhbmdlIHdpbGwgcmVxdWlyZSBhIG5ldyBEVExTIGhhbmRzaGFrZSBhbmQgbWVzc2FnZSBtYXRj
aGluZyBpcyBvbmx5IGFsbG93ZWQgd2l0aGluIHRoZSBzYW1lIHNlY3VyaXR5IGNvbnRleHQgKElJ
UkMpLiBIZW5jZSwgdGhlIGNsaWVudCBpcyByZXF1aXJlZCB0byByZS1yZWdpc3RlciBhbnl3YXku
IFRoZSAyNGggeW91IG1lbnRpb25lZCBhcmUgZm9yIHNvbWV0aGluZyBkaWZmZXJlbnQ7IHRoZSBj
bGllbnQgY2FuIHJlLXJlZ2lzdGVyIHdoZW5ldmVyIGl0IHdhbnRzIHRvIGFuZCB0aGUgTWF4LUFn
ZSBpcyBhIGdvb2QgaGludCBmb3IgdGhlIHRpbWUgc3BhbiB0byBleHBlY3QgYSBub3RpZmljYXRp
b24uIEFzIHN0YXRlZCBhYm92ZSwgbWVzc2FnZSBxdWV1ZWluZyBpcyBhIG11Y2ggYmV0dGVyIGFw
cHJvYWNoIHRvIHByZXZlbnQgaW5mb3JtYXRpb24gbG9zcyAoYWx0aG91Z2ggaXQgY29uZmxpY3Rz
IHdpdGggdGhlIGV2ZW50dWFsIGNvbnNpc3RlbmN5IHBoaWxvc29waHkgb2YgT2JzZXJ2ZSwgYnV0
IGl0IGdldHMgdGhlIGpvYiBkb25lIGZvciB0aGUgdXNlIGNhc2Vz4oCmKS4NCg0KQ2lhbw0KTWF0
dGhpYXMNCg0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgRmxvcmlzIFZhbiBkZW4gQWJlZWxlDQpTZW50OiBNb250YWcsIDIwLiBPa3RvYmVy
IDIwMTQgMTY6NTgNClRvOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIENvQVAg
RW5kcG9pbnQgSWRlbnRpZmljYXRpb24NCg0KQXBvbG9naWVzIGZvciByZXZpdmluZyBhIHRocmVl
IHdlZWsgb2xkIHRocmVhZCwgYnV0IGl0IG1pZ2h0IGJlIGludGVyZXN0aW5nIHRvIHBvbGwgdGhl
IGxpc3Qgb24gaG93IHBlb3BsZSBhcmUgYWRkcmVzc2luZyB0aGUgaXNzdWUgb2Ygc2VydmVycyB3
aXRoIGNoYW5naW5nIElQIGFkZHJlc3NlcyAoaS5lLiBtb2JpbGUgc2VydmVycykgdG9kYXk/DQoN
CkkgaGF2ZSBjb25zaWRlcmVkIHVzaW5nIGEgcHJveHkgZm9yIHRoaXMgcHVycG9zZSAoc28gdGhh
dCBhdCBsZWFzdCBmcm9tIHRoZSBjbGllbnQncyBQT1YgdGhlcmUgaXMgYSBzdGFibGUgSVAgYWRk
cmVzcyBmb3IgaXRzIHNlcnZlciksIGJ1dCB0aGUgaXNzdWUgcmFpc2VkIGluIE9saXZlcidzIGRy
YWZ0IGlzIG9idmlvdXNseSBzdGlsbCBwcmVzZW50IGJldHdlZW4gdGhlIHByb3h5IGFuZCBzZXJ2
ZXIuIEZvciB0aGUgbGF0dGVyLCBJIGludGVuZGVkIHRvIHVzZSBhIFJlc291cmNlIERpcmVjdG9y
eSB0byBzaWduYWwgSVAgYWRkcmVzcyBjaGFuZ2VzICh2aWEgdGhlIGNvbnRleHQgcGFyYW1ldGVy
KSBhbmQgZWl0aGVyIGhhdmUgdGhlIHByb3h5IHVwZGF0ZSBpdHMgb2JzZXJ2ZSAncmVsYXRpb25z
aGlwcycgb3IganVzdCByZS1lc3RhYmxpc2ggYWxsIG9ic2VydmUgJ3JlbGF0aW9uc2hpcHMnIHdp
dGggdGhlIHNlcnZlciAod2l0aCBzb21lIGluZm9ybWF0aW9uIGxvc3MgYmVpbmcgYSBsaWtlbHkg
cG9zc2liaWxpdHksIGJ1dCBhcyB0aGlzIGlzIGluLWxpbmUgd2l0aCB0aGUgZXZlbnR1YWwgY29u
c2lzdGVuY3kgZ29hbCBvZiBvYnNlcnZlIHRoaXMgbWlnaHQgYmUgT0sgZm9yIHNvbWUgdXNlLWNh
c2VzKS4NCg0KQSBzaW1wbGVyIHdvcmstYXJvdW5kICghKSBjb3VsZCBiZSB0byB1c2Ugc29tZXRo
aW5nIGxpa2UgYSBtaXJyb3IgcHJveHkgYW5kIG9taXQgdGhlIHByb2JsZW0gZW50aXJlbHkuIEJ5
IGZvcmNpbmcgdGhlIHNlcnZlciB0byBiZWNvbWUgYSBjbGllbnQgdGhpcyBkb2Vzbid0IGZhbGwg
dW5kZXIgdGhlIGNhdGVnb3J5IG9mIHByb2JsZW1zIGFkZHJlc3NlZCBieSBPbGl2ZXIncywgYnV0
IGl0IGlzIGEgZmFpcmx5IHN0cmFpZ2h0LWZvcndhcmQgbWV0aG9kIGZvciBzdXBwb3J0aW5nIG1v
YmlsZSBDb0FQIGVuZHBvaW50cyAod2l0aCB0aGUgYWRkZWQgaXNzdWUgb2Ygc3luY2hyb25pemF0
aW9uIGJldHdlZW4gbWlycm9yIHNlcnZlciBhbmQgdGhlIG1vYmlsZSBjbGllbnQpLg0KDQpBbnkg
Y29tbWVudHMgZnJvbSB3aGF0IHBlb3BsZSBvbiB0aGUgbGlzdCBoYXZlIHJ1bm5pbmcgdG9kYXk/
DQoNCkZsb3Jpcw0KT24gMjktMDktMTQgMTE6MDYsIE9saXZlciBLbGVpbmUgd3JvdGU6DQoNCkhp
LA0KDQoNCg0KQW0gMjguMDkuMjAxNCB1bSAwNzoxMiBzY2hyaWViIHdlaWdlbmd5dToNCg0KDQoN
CldoZW4gTm9kZSBJRCAoTklEKSBvciBFbmRwb2ludCBJRCAoRUlEKSBpcyBkZWZpbmVkIGFuZCBl
dmVyeSBDb0FQDQoNCkVuZHBvaW50IGhhcyBhIHVuaXF1ZSBJRCB0aGF0IGlzIG5ldmVyIGNoYW5n
ZWQuDQoNCg0KDQp0aGUgdGVybSAibmV2ZXIgY2hhbmdlZCIgaXMgbm90IGV4YWN0bHkgdHJ1ZSBm
b3IgRUlEcy4gTGV0IG1lIGV4cGxhaW4NCg0KdGhhdC4gSSB3YW50ZWQgdGhlIEVJRHMgdG8gYmUg
aW5kZXBlbmRlbnQgZnJvbSBhbnkgbGF5ZXJzIG9yIG90aGVyDQoNCmNvbXBvbmVudHMgYnV0IHRo
ZSBDb0FQIGxheWVyIG9uIGp1c3QgYm90aCBlbmRwb2ludHMuIEV2ZXJ5IG90aGVyIGxheWVyDQoN
CmhhcyBpdHMgaWRlbnRpZmllcnMgd2l0aCBhIGNlcnRhaW4gbGlmZXRpbWUsIGUuZy4gTUFDIGFk
ZHJlc3NlcyBvbiB0aGUNCg0KbmV0d29yayBsYXllciwgSVAgYWRkcmVzc2VzIG9uIHRoZSBJbnRl
cm5ldCBsYXllciBhbmQgcG9ydHMgb24gdGhlDQoNCnRyYW5zcG9ydCBsYXllci4gQWxsIG9mIHRo
ZW0gYXJlIG5lY2Vzc2FyeSB0byB0cmFuc2ZlciBkYXRhIGZyb20gb25lDQoNCnNvdXJjZSBwcm9j
ZXNzIHRvIHRoZSBvdGhlciAobWF5YmUgcmVtb3RlKSBkZXN0aW5hdGlvbiBwcm9jZXNzLg0KDQoN
Cg0KVGhlIEVJRCBhcHByb2FjaCBmb2xsb3dzIHRoYXQgd2VsbCBlc3RhYmxpc2hlZCB0cmFkaXRp
b24gYnkgZGVmaW5pbmcgYW4NCg0KaW5kZXBlbmRlbnQgbmV3IGlkZW50aWZpZXIgZm9yIHRoZSBz
cGVjaWZpYyBwdXJwb3NlIG9mIHJlbGF0aW5nIHJlcXVlc3RzDQoNCnRvIHJlc3BvbnNlcyBhbmQg
dXBkYXRlIG5vdGlmaWNhdGlvbnMganVzdCBmb3IgdGhlIG5lY2Vzc2FyeSBsaWZldGltZS4NCg0K
DQoNCkluIENvQVAgdGhlIG11dHVhbGx5IGFzc2lnbmVkIEVJRHMgYXJlIHZhbGlkIGZvciB0aGUg
ZHVyYXRpb24gb2Ygb25lDQoNCmNvbnZlcnNhdGlvbi4gQSBjb252ZXJzYXRpb24gaXMgY29uc2lk
ZXJlZCB0aGUgdGhlIHNldCBvZiBhbGwgbWVzc2FnZXMNCg0KYmV0d2VlbiB0d28gZW5kcG9pbnRz
IHRoYXQgc2hhcmUgdGhlIHNhbWUgdG9rZW4gaW5zdGFuY2UsIGUuZy4gYSBzaW5nbGUNCg0KcmVx
dWVzdC9yZXNwb25zZSBwYWlyIG9yIG9uZSByZXF1ZXN0IGFuZCBhbiB1bmJvdW5kIHNldCBvZiB1
cGRhdGUNCg0Kbm90aWZpY2F0aW9ucy4NCg0KDQoNCkJlc3QsDQoNCk9saXZlcg0KDQoNCg0KDQoN
Ci0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0gRnJvbTogT2xhZiBCZXJnbWFubg0KDQpTZW50OiBUaHVy
c2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0IDQ6MzQgUE0NCg0KVG86IExpa2VwZW5nDQoNCkNjOiBj
b3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW2NvcmVd
IENvQVAgRW5kcG9pbnQgSWRlbnRpZmljYXRpb24NCg0KDQoNCktlcGVuZywNCg0KDQoNCkxpa2Vw
ZW5nIDxsaWtlcGVuZ0BodWF3ZWkuY29tPjxtYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbT4gd3Jp
dGVzOg0KDQoNCg0KRW5kcG9pbnQgSUQgY2FuIGJlIHVzZWQgYXMgIkRlc2NyaXB0aW9uIiBwYXJh
bWV0ZXIgaW4gdGhlDQoNCmF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBtZW50aW9uZWQgaW4gdGhp
cyBkcmFmdC4NCg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nZXJkZXMt
YWNlLWRjYWYtYXV0aG9yaXplLw0KDQoNCg0KICAgICAgRDogRGVzY3JpcHRpb24uICBBIGRlc2Ny
aXB0aXZlIGxhYmVsIG9mIHRoZSBpbml0aWF0b3Igb2YgdGhlDQoNCiAgICAgIGF1dGhvcml6YXRp
b24gcmVxdWVzdC4gIFRoaXMgbGFiZWwgTUFZIGJlIGEgZnVsbHkgcXVhbGlmaWVkIGRvbWFpbg0K
DQogICAgICBuYW1lLCBhbiBJUCBhZGRyZXNzLCBvciBhbnkgb3RoZXIgY2hhcmFjdGVyIGxpdGVy
YWwgdGhhdCBpcyB1c2VkDQoNCiAgICAgIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciB0byBk
ZWNpZGUgd2hldGhlciBvciBub3QgYWNjZXNzIGlzDQoNCiAgICAgIGdyYW50ZWQgdG8gdGhlIHJl
cXVlc3RpbmcgZW50aXR5Lg0KDQoNCg0KRm9yIHRoaXMgcGFyYW1ldGVyLCBJUCBhZGRyZXNzIGlz
IG5vdCBzdGFibGUsIGRvbWFpbiBuYW1lIG1heSBub3QgYmUNCg0KYXZhaWxhYmxlLiBFbmRwb2lu
dCBJRCBpcyBhIGdvb2QgY2FuZGlkYXRlLg0KDQoNCg0KVGhpcyB3YXMgaW5kZWVkIG91ciBnZW5l
cmFsIG1pbmRzZXQuDQoNCg0KDQpHcnVlc3NlDQoNCk9sYWYNCg0KDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmNvcmUgbWFpbGluZyBsaXN0DQoN
CmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KDQpjb3JlIG1haWxpbmcgbGlzdA0KDQpjb3JlQGlldGYub3Jn
PG1haWx0bzpjb3JlQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2NvcmUNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNCmNvcmUgbWFpbGluZyBsaXN0DQoNCmNvcmVAaWV0Zi5vcmc8bWFp
bHRvOmNvcmVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vY29yZQ0KDQo=

--_000_55877B3AFB359744BA0F2140E36F52B5272BD487MBX110dethzch_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz
Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgSmhlbmdIZWkiOw0KCXBhbm9zZS0x
OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWlj
cm9zb2Z0IEpoZW5nSGVpIjsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBT
dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v
cm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6
YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl
ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh
ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ
cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNw
YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46
NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl
OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i
REUtQ0giIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkg
RmxvcmlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdGhpbmsgaXQgaXMgZ29v
ZCB0byByZXZpdmUgdGhpcyB0aHJlYWQsIHNpbmNlIHRoaXMgaXMgc3RpbGwgYW4gYWN0dWFsIHBy
b2JsZW0gYW5kIHRoZXJlIGlzIG5vIGdvb2Qgc29sdXRpb24geWV0LCBhdA0KIGxlYXN0IG5vIGdv
b2Qgb3ZlcmFsbCBkZXNjcmlwdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
QSBmZWFzaWJsZSB3YXkgaXMgZGVmaW5pdGVseSB0byB1c2UgdGhlIFJEIGFubm91bmNlIGFkZHJl
c3MgY2hhbmdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNv
LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlLXJlZ2lzdGVyaW5nIG9ic2VydmUgcmVsYXRpb25z
aGlwcyBpcyBhbHNvIG5vdCB0aGF0IGV4cGVuc2l2ZSwgc28gSSB3b3VsZCBkbyB0aGlzIGluc3Rl
YWQgb2YgYSBkaXJ0eSBoYWNrIHRoYXQgbW9kaWZpZXMNCiB0aGUgb2JzZXJ2ZSBzZW1hbnRpY3Mu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh
bmd1YWdlOkVOLVVTIj5JZiB0aGUgZ29hbCBpcyBhbHNvIHRvIHByZXZlbnQgbG9zaW5nIG5vdGlm
aWNhdGlvbiAoT2xpdmVy4oCZcyBwcm9ibGVtKSwgZHJhZnQta29zdGVyLWNvcmUtY29hcG1xIGlz
IHNvbWV0aGluZyB0byBsb29rDQogaW50by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+QSBwcm9ibGVtIEkgc2VlIHdpdGggdGhlIG1pcnJvciBwcm94eSBpcyB0aGF0IEkgd2lsbCBu
b3Qgd29yayBmb3IgYWN0dWF0aW9uLCBpLmUuLCBpbiB0aGUgY2FzZSB3ZSB3YW50IHRvIHNlbmQg
Y29tbWFuZHMNCiB0byBhIGRldmljZSB3aXRoIGNoYW5naW5nIGFkZHJlc3Nlcy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t
ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q29tbWVudHMgb24gT2xpdmVy4oCZcyBwcm9wb3NhbDog
QXMgSGFubmVzIG1lbnRpb25lZCwgYW4gSVAgYWRkcmVzcyBjaGFuZ2Ugd2lsbCByZXF1aXJlIGEg
bmV3IERUTFMgaGFuZHNoYWtlIGFuZCBtZXNzYWdlDQogbWF0Y2hpbmcgaXMgb25seSBhbGxvd2Vk
IHdpdGhpbiB0aGUgc2FtZSBzZWN1cml0eSBjb250ZXh0IChJSVJDKS4gSGVuY2UsIHRoZSBjbGll
bnQgaXMgcmVxdWlyZWQgdG8gcmUtcmVnaXN0ZXIgYW55d2F5LiBUaGUgMjRoIHlvdSBtZW50aW9u
ZWQgYXJlIGZvciBzb21ldGhpbmcgZGlmZmVyZW50OyB0aGUgY2xpZW50IGNhbiByZS1yZWdpc3Rl
ciB3aGVuZXZlciBpdCB3YW50cyB0byBhbmQgdGhlIE1heC1BZ2UgaXMgYSBnb29kIGhpbnQgZm9y
IHRoZQ0KIHRpbWUgc3BhbiB0byBleHBlY3QgYSBub3RpZmljYXRpb24uIEFzIHN0YXRlZCBhYm92
ZSwgbWVzc2FnZSBxdWV1ZWluZyBpcyBhIG11Y2ggYmV0dGVyIGFwcHJvYWNoIHRvIHByZXZlbnQg
aW5mb3JtYXRpb24gbG9zcyAoYWx0aG91Z2ggaXQgY29uZmxpY3RzIHdpdGggdGhlIGV2ZW50dWFs
IGNvbnNpc3RlbmN5IHBoaWxvc29waHkgb2YgT2JzZXJ2ZSwgYnV0IGl0IGdldHMgdGhlIGpvYiBk
b25lIGZvciB0aGUgdXNlIGNhc2Vz4oCmKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWF0dGhpYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0
Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx
RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv
d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYu
b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5GbG9yaXMgVmFuIGRlbiBBYmVlbGU8YnI+DQo8Yj5T
ZW50OjwvYj4gTW9udGFnLCAyMC4gT2t0b2JlciAyMDE0IDE2OjU4PGJyPg0KPGI+VG86PC9iPiBj
b3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gQ29BUCBFbmRwb2lu
dCBJZGVudGlmaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFwb2xv
Z2llcyBmb3IgcmV2aXZpbmcgYSB0aHJlZSB3ZWVrIG9sZCB0aHJlYWQsIGJ1dCBpdCBtaWdodCBi
ZSBpbnRlcmVzdGluZyB0byBwb2xsIHRoZSBsaXN0IG9uIGhvdyBwZW9wbGUgYXJlIGFkZHJlc3Np
bmcgdGhlIGlzc3VlIG9mIHNlcnZlcnMgd2l0aCBjaGFuZ2luZyBJUCBhZGRyZXNzZXMgKGkuZS4g
bW9iaWxlIHNlcnZlcnMpIHRvZGF5Pzxicj4NCjxicj4NCkkgaGF2ZSBjb25zaWRlcmVkIHVzaW5n
IGEgcHJveHkgZm9yIHRoaXMgcHVycG9zZSAoc28gdGhhdCBhdCBsZWFzdCBmcm9tIHRoZSBjbGll
bnQncyBQT1YgdGhlcmUgaXMgYSBzdGFibGUgSVAgYWRkcmVzcyBmb3IgaXRzIHNlcnZlciksIGJ1
dCB0aGUgaXNzdWUgcmFpc2VkIGluIE9saXZlcidzIGRyYWZ0IGlzIG9idmlvdXNseSBzdGlsbCBw
cmVzZW50IGJldHdlZW4gdGhlIHByb3h5IGFuZCBzZXJ2ZXIuIEZvciB0aGUgbGF0dGVyLCBJIGlu
dGVuZGVkDQogdG8gdXNlIGEgUmVzb3VyY2UgRGlyZWN0b3J5IHRvIHNpZ25hbCBJUCBhZGRyZXNz
IGNoYW5nZXMgKHZpYSB0aGUgY29udGV4dCBwYXJhbWV0ZXIpIGFuZCBlaXRoZXIgaGF2ZSB0aGUg
cHJveHkgdXBkYXRlIGl0cyBvYnNlcnZlICdyZWxhdGlvbnNoaXBzJyBvciBqdXN0IHJlLWVzdGFi
bGlzaCBhbGwgb2JzZXJ2ZSAncmVsYXRpb25zaGlwcycgd2l0aCB0aGUgc2VydmVyICh3aXRoIHNv
bWUgaW5mb3JtYXRpb24gbG9zcyBiZWluZyBhIGxpa2VseSBwb3NzaWJpbGl0eSwNCiBidXQgYXMg
dGhpcyBpcyBpbi1saW5lIHdpdGggdGhlIGV2ZW50dWFsIGNvbnNpc3RlbmN5IGdvYWwgb2Ygb2Jz
ZXJ2ZSB0aGlzIG1pZ2h0IGJlIE9LIGZvciBzb21lIHVzZS1jYXNlcykuPGJyPg0KPGJyPg0KQSBz
aW1wbGVyIHdvcmstYXJvdW5kICghKSBjb3VsZCBiZSB0byB1c2Ugc29tZXRoaW5nIGxpa2UgYSBt
aXJyb3IgcHJveHkgYW5kIG9taXQgdGhlIHByb2JsZW0gZW50aXJlbHkuIEJ5IGZvcmNpbmcgdGhl
IHNlcnZlciB0byBiZWNvbWUgYSBjbGllbnQgdGhpcyBkb2Vzbid0IGZhbGwgdW5kZXIgdGhlIGNh
dGVnb3J5IG9mIHByb2JsZW1zIGFkZHJlc3NlZCBieSBPbGl2ZXIncywgYnV0IGl0IGlzIGEgZmFp
cmx5IHN0cmFpZ2h0LWZvcndhcmQgbWV0aG9kDQogZm9yIHN1cHBvcnRpbmcgbW9iaWxlIENvQVAg
ZW5kcG9pbnRzICh3aXRoIHRoZSBhZGRlZCBpc3N1ZSBvZiBzeW5jaHJvbml6YXRpb24gYmV0d2Vl
biBtaXJyb3Igc2VydmVyIGFuZCB0aGUgbW9iaWxlIGNsaWVudCkuPGJyPg0KPGJyPg0KQW55IGNv
bW1lbnRzIGZyb20gd2hhdCBwZW9wbGUgb24gdGhlIGxpc3QgaGF2ZSBydW5uaW5nIHRvZGF5Pzxi
cj4NCjxicj4NCjwvc3Bhbj5GbG9yaXM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5PbiAyOS0wOS0xNCAxMTowNiwgT2xpdmVyIEtsZWluZSB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhpLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFtIDI4LjA5LjIwMTQgdW0gMDc6MTIgc2NocmllYiB3
ZWlnZW5neXU6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+V2hlbiBOb2RlIElEIChOSUQpIG9yIEVuZHBvaW50
IElEIChFSUQpIGlzIGRlZmluZWQgYW5kIGV2ZXJ5IENvQVA8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkVuZHBvaW50IGhhcyBhIHVuaXF1ZSBJRCB0aGF0
IGlzIG5ldmVyIGNoYW5nZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSB0ZXJtICZxdW90O25ldmVyIGNoYW5nZWQmcXVv
dDsgaXMgbm90IGV4YWN0bHkgdHJ1ZSBmb3IgRUlEcy4gTGV0IG1lIGV4cGxhaW48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRoYXQuIEkgd2FudGVkIHRo
ZSBFSURzIHRvIGJlIGluZGVwZW5kZW50IGZyb20gYW55IGxheWVycyBvciBvdGhlcjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Y29tcG9uZW50cyBidXQg
dGhlIENvQVAgbGF5ZXIgb24ganVzdCBib3RoIGVuZHBvaW50cy4gRXZlcnkgb3RoZXIgbGF5ZXI8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmhhcyBpdHMg
aWRlbnRpZmllcnMgd2l0aCBhIGNlcnRhaW4gbGlmZXRpbWUsIGUuZy4gTUFDIGFkZHJlc3NlcyBv
biB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPm5l
dHdvcmsgbGF5ZXIsIElQIGFkZHJlc3NlcyBvbiB0aGUgSW50ZXJuZXQgbGF5ZXIgYW5kIHBvcnRz
IG9uIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+
dHJhbnNwb3J0IGxheWVyLiBBbGwgb2YgdGhlbSBhcmUgbmVjZXNzYXJ5IHRvIHRyYW5zZmVyIGRh
dGEgZnJvbSBvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t
VVMiPnNvdXJjZSBwcm9jZXNzIHRvIHRoZSBvdGhlciAobWF5YmUgcmVtb3RlKSBkZXN0aW5hdGlv
biBwcm9jZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT
Ij5UaGUgRUlEIGFwcHJvYWNoIGZvbGxvd3MgdGhhdCB3ZWxsIGVzdGFibGlzaGVkIHRyYWRpdGlv
biBieSBkZWZpbmluZyBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJFTi1VUyI+aW5kZXBlbmRlbnQgbmV3IGlkZW50aWZpZXIgZm9yIHRoZSBzcGVjaWZpYyBwdXJw
b3NlIG9mIHJlbGF0aW5nIHJlcXVlc3RzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkVOLVVTIj50byByZXNwb25zZXMgYW5kIHVwZGF0ZSBub3RpZmljYXRpb25zIGp1
c3QgZm9yIHRoZSBuZWNlc3NhcnkgbGlmZXRpbWUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRU4tVVMiPkluIENvQVAgdGhlIG11dHVhbGx5IGFzc2lnbmVkIEVJRHMg
YXJlIHZhbGlkIGZvciB0aGUgZHVyYXRpb24gb2Ygb25lPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5jb252ZXJzYXRpb24uIEEgY29udmVyc2F0aW9uIGlz
IGNvbnNpZGVyZWQgdGhlIHRoZSBzZXQgb2YgYWxsIG1lc3NhZ2VzPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5iZXR3ZWVuIHR3byBlbmRwb2ludHMgdGhh
dCBzaGFyZSB0aGUgc2FtZSB0b2tlbiBpbnN0YW5jZSwgZS5nLiBhIHNpbmdsZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cmVxdWVzdC9yZXNwb25zZSBw
YWlyIG9yIG9uZSByZXF1ZXN0IGFuZCBhbiB1bmJvdW5kIHNldCBvZiB1cGRhdGU8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPm5vdGlmaWNhdGlvbnMuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QsPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PbGl2ZXI8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPuWOn+Wnizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWlj
cm9zb2Z0IEpoZW5nSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPumCruS7tjwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0gRnJvbTogT2xhZiBCZXJnbWFubjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+U2VudDogVGh1cnNkYXksIFNl
cHRlbWJlciAyNSwgMjAxNCA0OjM0IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkVOLVVTIj5UbzogTGlrZXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRU4tVVMiPkNjOiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0
Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5jb3JlQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBs
YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO
LVVTIj5TdWJqZWN0OiBSZTogW2NvcmVdIENvQVAgRW5kcG9pbnQgSWRlbnRpZmljYXRpb248bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+S2VwZW5nLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5MaWtlcGVuZyA8L3Nw
YW4+PGEgaHJlZj0ibWFpbHRvOmxpa2VwZW5nQGh1YXdlaS5jb20iPjxzcGFuIGxhbmc9IkVOLVVT
Ij4mbHQ7bGlrZXBlbmdAaHVhd2VpLmNvbSZndDs8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVT
Ij4gd3JpdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t
VVMiPkVuZHBvaW50IElEIGNhbiBiZSB1c2VkIGFzICZxdW90O0Rlc2NyaXB0aW9uJnF1b3Q7IHBh
cmFtZXRlciBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RU4tVVMiPmF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBtZW50aW9uZWQgaW4gdGhpcyBkcmFmdC48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1nZXJkZXMtYWNlLWRjYWYtYXV0aG9yaXplLyI+PHNwYW4gbGFu
Zz0iRU4tVVMiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2VyZGVzLWFj
ZS1kY2FmLWF1dGhvcml6ZS88L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IEQ6IERlc2NyaXB0aW9uLiZuYnNwOyBBIGRlc2NyaXB0aXZlIGxhYmVsIG9m
IHRoZSBpbml0aWF0b3Igb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0aG9yaXphdGlv
biByZXF1ZXN0LiZuYnNwOyBUaGlzIGxhYmVsIE1BWSBiZSBhIGZ1bGx5IHF1YWxpZmllZCBkb21h
aW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuYW1lLCBhbiBJUCBhZGRyZXNzLCBvciBhbnkgb3Ro
ZXIgY2hhcmFjdGVyIGxpdGVyYWwgdGhhdCBpcyB1c2VkPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
YnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRvIGRlY2lkZSB3aGV0aGVyIG9yIG5vdCBhY2Nl
c3MgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBncmFudGVkIHRvIHRoZSByZXF1ZXN0aW5nIGVu
dGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Rm9y
IHRoaXMgcGFyYW1ldGVyLCBJUCBhZGRyZXNzIGlzIG5vdCBzdGFibGUsIGRvbWFpbiBuYW1lIG1h
eSBub3QgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi
PmF2YWlsYWJsZS4gRW5kcG9pbnQgSUQgaXMgYSBnb29kIGNhbmRpZGF0ZS48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyB3
YXMgaW5kZWVkIG91ciBnZW5lcmFsIG1pbmRzZXQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRU4tVVMiPkdydWVzc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRU4tVVMiPk9sYWY8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi
PmNvcmUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxhIGhyZWY9
Im1haWx0bzpjb3JlQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+Y29yZUBpZXRmLm9yZzwv
c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiPjxz
cGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv
cmU8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj5jb3JlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPmNvcmVAaWV0
Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j
b3JlIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9jb3JlPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFu
IGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Y29y
ZSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFp
bHRvOmNvcmVAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5jb3JlQGlldGYub3JnPC9zcGFu
PjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSI+PHNwYW4g
bGFuZz0iRU4tVVMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwv
c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9i
bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_55877B3AFB359744BA0F2140E36F52B5272BD487MBX110dethzch_--


From nobody Tue Oct 21 07:09:54 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC2B1A6F3C for ; Tue, 21 Oct 2014 07:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqC_zJTJHeVk for ; Tue, 21 Oct 2014 07:09:31 -0700 (PDT)
Received: from ip2.rz.uni-luebeck.de (ip2.rz.uni-luebeck.de [141.83.100.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58281A1C04 for ; Tue, 21 Oct 2014 07:09:30 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFACtoRlSNU0Rk/2dsb2JhbABSBwODDlNYAcwnh00CgRAWAX2EAwEBAwFJLwYLCyEWDwIHAwIBAgFFEwYCAQGIMwwJwzoBCwEfjgyBaUELFxEFhDUFlA+BUI9eBY46g3lqAYJKAQEB
X-IPAS-Result: AhwFACtoRlSNU0Rk/2dsb2JhbABSBwODDlNYAcwnh00CgRAWAX2EAwEBAwFJLwYLCyEWDwIHAwIBAgFFEwYCAQGIMwwJwzoBCwEfjgyBaUELFxEFhDUFlA+BUI9eBY46g3lqAYJKAQEB
Received: from itm01.itm.uni-luebeck.de ([141.83.68.100]) by ip2.rz.uni-luebeck.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2014 16:09:28 +0200
Received: from [141.83.68.39] (belladonna.itm.uni-luebeck.de [141.83.68.39]) by itm01.itm.uni-luebeck.de (Postfix) with ESMTPA id 4C80483F8E5 for ; Tue, 21 Oct 2014 16:09:28 +0200 (CEST)
Message-ID: <54466917.1020505@itm.uni-luebeck.de>
Date: Tue, 21 Oct 2014 16:09:27 +0200
From: Oliver Kleine 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: core@ietf.org
References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> <6253A048-6A69-49CA-B0CC-438D1789856F@tzi.org> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C94@SZXEMA501-MBS.china.huawei.com> <5444FB5E.60503@itm.uni-luebeck.de> <55877B3AFB359744BA0F2140E36F52B52729395B@MBX110.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B52729395B@MBX110.d.ethz.ch>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020503010008040301090107"
Archived-At: http://mailarchive.ietf.org/arch/msg/core/KzSBNoTmw4Avm67ml1KTGufY0Xg
Subject: Re: [core] Conflict endpoint idenfier for resource directory draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Oct 2014 14:09:44 -0000

This is a cryptographically signed message in MIME format.

--------------ms020503010008040301090107
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

>> If an Endpoint registered itself to Resource Directory Server with
>> a conflicted ID, RD Server should return an error code to ask the
>> endpoint to choose another identifier.
>=20
> My question here is: How should the RD know that this is a conflict?=20
> The point of using this ID is to identify the same endpoint over
> changing addresses or even transports (e.g., UDP and SMS).

It is my understanding of the RD draft that there is no need for global
uniqueness of IDs but only uniqueness per RD. Thus, it is easy for an RD
to determine if the ID in an inbound registration request is already in
use with another server.

> The natural reaction would be to assume the endpoint crashed and is
> now registering after a reboot. As Zach mentioned in the other
> thread, this ID is somehow linked to the endpoint certificate. So the
> assumption is that there is another entity that ensures uniqueness.

Is it really a good idea to more or less "bind" the ID to some kind of
certificate? Wouldn't that exclude servers without certificates from
registration at an RD?

Wouldn't it instead be possible for a server to autonomously choose a
(maybe even random) ID to register at the RD? If that ID is already in
use on the RD the registration request is answered with a 4.09 and a
proposal for another ID which is not yet in use.

Best,
Oliver
--=20

Oliver Kleine, M.Sc.


UNIVERSIT=C4T ZU L=DCBECK
    INSTITUT F=DCR TELEMATIK

    Ratzeburger Allee 160
    23538 L=FCbeck

    Tel +49 451 500 5396
    Fax +49 451 500 5382
    kleine@itm.uni-luebeck.de

    www.itm.uni-luebeck.de/people/kleine


--------------ms020503010008040301090107
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPfDCC
BNUwggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRww
GgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3Qg
Q2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIx
MjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy
ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg
LSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9
YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2Q
RdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/B
CaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7Pb
D8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs
6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8EBAMCAQYw
HQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJ
ei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs
AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGt
IYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2
LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYB
BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5o
dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3
DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/D
stU1gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTu
IfJ1AuxSPtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23
NQIZz/U5RFhjpyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnY
C8aEHwTG6x7on321e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIF
RDCCBCygAwIBAgIHE0IjRucGSTANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJERTEgMB4G
A1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJz
aXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlMB4X
DTEyMDEyNzEzMjUxMVoXDTE1MDEyNjEzMjUxMVowaTELMAkGA1UEBhMCREUxIDAeBgNVBAoT
F1VuaXZlcnNpdGFldCB6dSBMdWViZWNrMSAwHgYDVQQLExdJbnN0aXR1dCBmdWVyIFRlbGVt
YXRpazEWMBQGA1UEAxMNT2xpdmVyIEtsZWluZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALgYtjqHzX1LCD/4MZQaszSw5FlHUV+Xlupgjz/WU8QW8lYKxof09XP3fnvRpYfW
MWs/QQzdmB4MS4w7VZpQ9azyt2BtQcT2lMHXxvi7N216uMFAu+hx5zc4GirYGhNLqID/hE8K
zigxqIc4nW0bBWHnqTcra/eZp4FYWFDQ00E5FlCu5iBfKaDlQ3I22znxNhUmIIO2piFNo1Ls
yvLFsxhge6FwnRb0fAXR2DAHOMOd+6zsaOoWUiHT2kXSpTgytadx3YLMBqVQE4t6P8ry+DH4
ge9iNRxVYIKPXt4V1aCAywUU/OTaXXWDhkYSdjvlvRLHg47eJRMxZOW2oaz0P0MCAwEAAaOC
Ad0wggHZMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggr
BgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUGaokk2F5DZlyqvd7U5PuTIn07tYwHwYD
VR0jBBgwFoAUtytvwMcYEDE2F1IQdaHQQMM5NB8wJAYDVR0RBB0wG4EZa2xlaW5lQGl0bS51
bmktbHVlYmVjay5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u
ZGUvdW5pLWx1ZWJlY2stY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAy
LnBjYS5kZm4uZGUvdW5pLWx1ZWJlY2stY2EvcHViL2NybC9jYWNybC5jcmwwgaIGCCsGAQUF
BwEBBIGVMIGSMEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVi
ZWNrLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIu
cGNhLmRmbi5kZS91bmktbHVlYmVjay1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI
hvcNAQEFBQADggEBADYFSngNYr+hIAIPFbRf7aF0aY1lwHNJdVyFKtCWNu/K7qqKXiXhTSg4
LGazzbriTAgHdvgcMoRvolspjhgsJ7SdOAtRyPFta/QTPeJMj4Hd/mAxkykuNVqYR18LYXyv
VGhRHtOt19rXxpL40vl0OQGRBune06/XfnF5SHCAU+N2KTjbK+jLr77gZFa39nWLBIGB9fZK
smTMclVvw2vBmPs6/uhoEzkYEAiDAmHnfOYYFPxAFFlwEIpLaHFKp5ZKxIZgvLdIZOGM0a2b
oS2bHJhM3dsLNObw8GjvI8sizq79WWZxlMFqAInetvsd7aWCndOwpjUSi4fw1ZG4zWXlmpgw
ggVXMIIEP6ADAgECAgcXr/bsXKnqMA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNVBAYTAkRFMRMw
EQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVy
ZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNjIxWhcNMTkwNzA5MjM1OTAwWjB7
MQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNV
BAMTHkNBIGRlciBVbml2ZXJzaXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtp
QHVuaS1sdWViZWNrLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlmUu5q+1
448Is2yl8dx0GMZN+vQcONK99YxpZzdJSZdnvlQsymtijkhp3UNnXzxBXxk0tegRIaX/Ejz2
AzxLDM/FkfxZ2XRRiuKqVdG+/qczey+MYJyqBti11miUdocoAm+nxthIj1k+3qLzeDyv7DV4
/+XpD313ciqw/X2zD4ZZfpk00fQ7AsqR+aAxjhQLDQJ94dIhOHWD05eu09yxoWJe1ne2fc0m
UXw+mvpTpifOo4LgS9a36ucL3n8CL7BmWGMDk3/rmcjKLBWGZRjCQmNJvSTv2TaERnQxnb9Y
hVUsXi9IptvIGc6ERGj23O6hWkysNMNpAqEThGIV5q6hQwIDAQABo4IB/zCCAfswEgYDVR0T
AQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAowCDAGBgRVHSAAMB0GA1Ud
DgQWBBS3K2/AxxgQMTYXUhB1odBAwzk0HzAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EK
cD7eZDAdBgNVHREEFjAUgRJwa2lAdW5pLWx1ZWJlY2suZGUwgYgGA1UdHwSBgDB+MD2gO6A5
hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2Fjcmwu
Y3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j
cmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggrBgEFBQcwAYYnaHR0cDovL29j
c3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsGAQUFBzAChjtodHRwOi8vY2Rw
MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggr
BgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2Fj
ZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAHWHmI/9W/Qy90CeDlzlpBibL8qt
WOa1F5AafYH61r+IcB66IyQIM4En+g/X+HpkQJfOaufYPzG3BGuspMRWlasA53+9rz/PshO5
UU3+31+UcLV+Dlnakr3cC/8hEUXF5AtTkmaCzYFm1dy4FcdaqK0pURX9YOxhRqUc+vlnuVKc
a20TS6QnLbvJyN4/v2H9IB3pj3eO/lLKicqiUhkdj0cHrNteObDd0ijSBsDbhg/ck99TBCBm
0GLOfrb1cMuHTy+et5K68npIgAojCHZZgLqtO4BGN3CXEKcUX0E+0xixOgNgQRxDgiP25qr8
X97JXm5RY6m1/+EPX7wQVeUYtokxggOzMIIDrwIBATCBhjB7MQswCQYDVQQGEwJERTEgMB4G
A1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJz
aXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlAgcT
QiNG5wZJMAkGBSsOAwIaBQCgggIBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTE0MTAyMTE0MDkyN1owIwYJKoZIhvcNAQkEMRYEFNtOogVq9EsXDKWxezhi
NK83E3eVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgZcGCSsGAQQBgjcQBDGBiTCBhjB7MQswCQYDVQQGEwJERTEgMB4GA1UEChMX
VW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJzaXRhZXQg
enUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlAgcTQiNG5wZJ
MIGZBgsqhkiG9w0BCRACCzGBiaCBhjB7MQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVy
c2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJzaXRhZXQgenUgTHVl
YmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlAgcTQiNG5wZJMA0GCSqG
SIb3DQEBAQUABIIBAAs0Mwj61m7BvvZ0IG5f+ZWFVQ5GtJCFPAgH092EsWnvkLUZCokva16r
rqI2xGVdHc0scl6hFxHh/AUkfWeWEJWAMIkSIGKBMMo7R+RGz9XyJ0xNP90sGX8kxSLwSQRS
BIox+pZimghuTWWyzZFDkV5w0lgCwmlYo7uEfkD/QSuubbDT1YNwN8SMX9Beq9w9kxfNF2zM
FaRzZ848F0VNxrcERF8Jj5L0nGtmYOcQg50rqN/cajPjYC+xuEI/H6GJCGGGjBSv1P0Ik9oe
bjSfO9zrJcqBPDByYcHEouPj87CBqEDgewIn5zt2BafqaRW46SF80iQDiDBLhleqLZwDooQA
AAAAAAA=
--------------ms020503010008040301090107--


From nobody Tue Oct 21 08:13:18 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DADB1A8722 for ; Tue, 21 Oct 2014 08:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level: 
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs1LAHVo-sEb for ; Tue, 21 Oct 2014 08:13:00 -0700 (PDT)
Received: from ip2.rz.uni-luebeck.de (ip2.rz.uni-luebeck.de [141.83.100.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B67C1A875C for ; Tue, 21 Oct 2014 08:11:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFADJxRlSNU0Rk/2dsb2JhbABZA4MOU1iDBskYCodNAoERFgF9hAIBAQEDAQEBASAmJQQGBgsJAhEEAQEBCRYIAwICAgcDAgECARUfCQgQAwYCAQGIMwwJkjKcT5RpAQEBAQEFAQEBAQEBAQEailODOYIqCxcGC4JmgVQFlA+BUGiIQzyFdwWHHoMbhAGDeWoBgkoBAQE
X-IPAS-Result: AhQFADJxRlSNU0Rk/2dsb2JhbABZA4MOU1iDBskYCodNAoERFgF9hAIBAQEDAQEBASAmJQQGBgsJAhEEAQEBCRYIAwICAgcDAgECARUfCQgQAwYCAQGIMwwJkjKcT5RpAQEBAQEFAQEBAQEBAQEailODOYIqCxcGC4JmgVQFlA+BUGiIQzyFdwWHHoMbhAGDeWoBgkoBAQE
Received: from itm01.itm.uni-luebeck.de ([141.83.68.100]) by ip2.rz.uni-luebeck.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2014 17:11:15 +0200
Received: from [141.83.68.39] (belladonna.itm.uni-luebeck.de [141.83.68.39]) by itm01.itm.uni-luebeck.de (Postfix) with ESMTPA id BAA9083F8E5 for ; Tue, 21 Oct 2014 17:11:14 +0200 (CEST)
Message-ID: <54467792.4010408@itm.uni-luebeck.de>
Date: Tue, 21 Oct 2014 17:11:14 +0200
From: Oliver Kleine 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: core@ietf.org
References: <54194E6E.7080902@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819D479@SZXEMA501-MBS.china.huawei.com> <541AC053.9000106@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819DB58@SZXEMA501-MBS.china.huawei.com> <541BEF16.2040200@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819E136@SZXEMA501-MBS.china.huawei.com> <5422BBF7.6070402@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819F6D5@SZXEMA501-MBS.china.huawei.com>  <34966E97BE8AD64EAE9D3D6E4DEE36F25819F986@SZXEMA501-MBS.china.huawei.com> <87tx3wp08d.fsf@tzi.org>  <542920F9.8070006@itm.uni-luebeck.de> <544522FC.3060809@intec.ugent.be> <55877B3AFB359744BA0F2140E36F52B5272BD487@MBX110.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B5272BD487@MBX110.d.ethz.ch>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010202010003000605090005"
Archived-At: http://mailarchive.ietf.org/arch/msg/core/1EOiVQR634V_lINfkAbPnqlomp4
Subject: Re: [core] CoAP Endpoint Identification
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Oct 2014 15:13:04 -0000

This is a cryptographically signed message in MIME format.

--------------ms010202010003000605090005
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> If the goal is also to prevent losing notification (Oliver=E2=80=99s pr=
oblem),
> draft-koster-core-coapmq is something to look into.

For sure this avoids loss of information but it does not avoid loss of
actuality. There are certain use cases where you want the information in
(or close to) real-time and not at some time in the future.

You e.g. want to know that your home is burning at the time the fire
starts (or even before) and not that it was burning hours ago...

> A problem I see with the mirror proxy is that I will not work for
> actuation, i.e., in the case we want to send commands to a device with
> changing addresses.

> Comments on Oliver=E2=80=99s proposal: As Hannes mentioned, an IP addre=
ss change
> will require a new DTLS handshake and message matching is only allowed
> within the same security context (IIRC). Hence, the client is required
> to re-register anyway.

Thank you! I didn't know that. Is that procedure already standardized or
still in draft status? Could you provide me with a link to the relevant
document(s)?

> The 24h you mentioned are for something
> different; the client can re-register whenever it wants to and the
> Max-Age is a good hint for the time span to expect a notification.

Sure, but by strictly following the standards (CoAP core and observe) a
client wouldn't know that it was the observed server but with a new
source IP that sent an update notification. Thus, the notification is
either ignored or answered with an RST that causes the server to stop
the observation. However, the client keeps the observation running for
up to 24 hours (CON notification timeout). The client does not detect a
need to restart the observation with the new server IP.

Furthermore, as you said the max-age option can only be considered a
hint. Taking the example from above you would probably set the max-age
of the status "house is not burning" to a rather high value as this
status is likely to be valid for a long time and you want to avoid
frequent update notifications. However, you want to be as sure as
possible that your observation is still running despite long max-age
values and despite any need for new DTLS handshakes. You just want to be
notified also about unexpected changes ("house is burning") before
max-age ends. And my proposal also aims to increase that certainty.

However, in a previous draft of observe it was mandatory to send new
update notifications whenever the last max-age ends (independent from a
status change). This was changed for some (probably good) reason.

> As stated above, message queueing is a much better approach to prevent
> information loss (although it conflicts with the eventual consistency
> philosophy of Observe, but it gets the job done for the use cases=E2=80=
=A6).

Apparently not all of them. See above...

Best,
Oliver

> *From:*core [mailto:core-bounces@ietf.org] *On Behalf Of *Floris Van de=
n
> Abeele
> *Sent:* Montag, 20. Oktober 2014 16:58
> *To:* core@ietf.org
> *Subject:* Re: [core] CoAP Endpoint Identification
>=20
> =20
>=20
> Apologies for reviving a three week old thread, but it might be
> interesting to poll the list on how people are addressing the issue of
> servers with changing IP addresses (i.e. mobile servers) today?
>=20
> I have considered using a proxy for this purpose (so that at least from=

> the client's POV there is a stable IP address for its server), but the
> issue raised in Oliver's draft is obviously still present between the
> proxy and server. For the latter, I intended to use a Resource Director=
y
> to signal IP address changes (via the context parameter) and either hav=
e
> the proxy update its observe 'relationships' or just re-establish all
> observe 'relationships' with the server (with some information loss
> being a likely possibility, but as this is in-line with the eventual
> consistency goal of observe this might be OK for some use-cases).
>=20
> A simpler work-around (!) could be to use something like a mirror proxy=

> and omit the problem entirely. By forcing the server to become a client=

> this doesn't fall under the category of problems addressed by Oliver's,=

> but it is a fairly straight-forward method for supporting mobile CoAP
> endpoints (with the added issue of synchronization between mirror serve=
r
> and the mobile client).
>=20
> Any comments from what people on the list have running today?
>=20
> Floris
>=20
> On 29-09-14 11:06, Oliver Kleine wrote:
>=20
>     Hi,
>=20
>     =20
>=20
>     Am 28.09.2014 um 07:12 schrieb weigengyu:
>=20
>     =20
>=20
>         When Node ID (NID) or Endpoint ID (EID) is defined and every Co=
AP
>=20
>         Endpoint has a unique ID that is never changed.
>=20
>     =20
>=20
>     the term "never changed" is not exactly true for EIDs. Let me expla=
in
>=20
>     that. I wanted the EIDs to be independent from any layers or other
>=20
>     components but the CoAP layer on just both endpoints. Every other l=
ayer
>=20
>     has its identifiers with a certain lifetime, e.g. MAC addresses on =
the
>=20
>     network layer, IP addresses on the Internet layer and ports on the
>=20
>     transport layer. All of them are necessary to transfer data from on=
e
>=20
>     source process to the other (maybe remote) destination process.
>=20
>     =20
>=20
>     The EID approach follows that well established tradition by definin=
g an
>=20
>     independent new identifier for the specific purpose of relating req=
uests
>=20
>     to responses and update notifications just for the necessary lifeti=
me.
>=20
>     =20
>=20
>     In CoAP the mutually assigned EIDs are valid for the duration of on=
e
>=20
>     conversation. A conversation is considered the the set of all messa=
ges
>=20
>     between two endpoints that share the same token instance, e.g. a si=
ngle
>=20
>     request/response pair or one request and an unbound set of update
>=20
>     notifications.
>=20
>     =20
>=20
>     Best,
>=20
>     Oliver
>=20
>     =20
>=20
>     =20
>=20
>         -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Olaf Bergm=
ann
>=20
>         Sent: Thursday, September 25, 2014 4:34 PM
>=20
>         To: Likepeng
>=20
>         Cc: core@ietf.org 
>=20
>         Subject: Re: [core] CoAP Endpoint Identification
>=20
>         =20
>=20
>         Kepeng,
>=20
>         =20
>=20
>         Likepeng   wri=
tes:
>=20
>         =20
>=20
>             Endpoint ID can be used as "Description" parameter in the
>=20
>             authorization request as mentioned in this draft.
>=20
>             http://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-autho=
rize/
>=20
>             =20
>=20
>                   D: Description.  A descriptive label of the initiator=
 of the
>=20
>                   authorization request.  This label MAY be a fully qua=
lified domain
>=20
>                   name, an IP address, or any other character literal t=
hat is used
>=20
>                   by the Authorization Server to decide whether or not =
access is
>=20
>                   granted to the requesting entity.
>=20
>             =20
>=20
>             For this parameter, IP address is not stable, domain name m=
ay not be
>=20
>             available. Endpoint ID is a good candidate.
>=20
>         =20
>=20
>         This was indeed our general mindset.
>=20
>         =20
>=20
>         Gruesse
>=20
>         Olaf
>=20
>         =20
>=20
>         _______________________________________________
>=20
>         core mailing list
>=20
>         core@ietf.org 
>=20
>         https://www.ietf.org/mailman/listinfo/core
>=20
>         _______________________________________________
>=20
>         core mailing list
>=20
>         core@ietf.org 
>=20
>         https://www.ietf.org/mailman/listinfo/core
>=20
>     =20
>=20
>=20
>=20
>=20
>     _______________________________________________
>=20
>     core mailing list
>=20
>     core@ietf.org 
>=20
>     https://www.ietf.org/mailman/listinfo/core
>=20
> =20
>=20
>=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>=20

--=20

Oliver Kleine, M.Sc.


UNIVERSIT=C3=84T ZU L=C3=9CBECK
    INSTITUT F=C3=9CR TELEMATIK

    Ratzeburger Allee 160
    23538 L=C3=BCbeck

    Tel +49 451 500 5396
    Fax +49 451 500 5382
    kleine@itm.uni-luebeck.de

    www.itm.uni-luebeck.de/people/kleine


--------------ms010202010003000605090005
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPfDCC
BNUwggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRww
GgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3Qg
Q2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIx
MjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy
ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg
LSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9
YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2Q
RdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/B
CaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7Pb
D8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs
6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8EBAMCAQYw
HQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJ
ei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs
AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGt
IYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2
LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYB
BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5o
dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3
DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/D
stU1gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTu
IfJ1AuxSPtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23
NQIZz/U5RFhjpyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnY
C8aEHwTG6x7on321e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIF
RDCCBCygAwIBAgIHE0IjRucGSTANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJERTEgMB4G
A1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJz
aXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlMB4X
DTEyMDEyNzEzMjUxMVoXDTE1MDEyNjEzMjUxMVowaTELMAkGA1UEBhMCREUxIDAeBgNVBAoT
F1VuaXZlcnNpdGFldCB6dSBMdWViZWNrMSAwHgYDVQQLExdJbnN0aXR1dCBmdWVyIFRlbGVt
YXRpazEWMBQGA1UEAxMNT2xpdmVyIEtsZWluZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALgYtjqHzX1LCD/4MZQaszSw5FlHUV+Xlupgjz/WU8QW8lYKxof09XP3fnvRpYfW
MWs/QQzdmB4MS4w7VZpQ9azyt2BtQcT2lMHXxvi7N216uMFAu+hx5zc4GirYGhNLqID/hE8K
zigxqIc4nW0bBWHnqTcra/eZp4FYWFDQ00E5FlCu5iBfKaDlQ3I22znxNhUmIIO2piFNo1Ls
yvLFsxhge6FwnRb0fAXR2DAHOMOd+6zsaOoWUiHT2kXSpTgytadx3YLMBqVQE4t6P8ry+DH4
ge9iNRxVYIKPXt4V1aCAywUU/OTaXXWDhkYSdjvlvRLHg47eJRMxZOW2oaz0P0MCAwEAAaOC
Ad0wggHZMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggr
BgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUGaokk2F5DZlyqvd7U5PuTIn07tYwHwYD
VR0jBBgwFoAUtytvwMcYEDE2F1IQdaHQQMM5NB8wJAYDVR0RBB0wG4EZa2xlaW5lQGl0bS51
bmktbHVlYmVjay5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u
ZGUvdW5pLWx1ZWJlY2stY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAy
LnBjYS5kZm4uZGUvdW5pLWx1ZWJlY2stY2EvcHViL2NybC9jYWNybC5jcmwwgaIGCCsGAQUF
BwEBBIGVMIGSMEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVi
ZWNrLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIu
cGNhLmRmbi5kZS91bmktbHVlYmVjay1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI
hvcNAQEFBQADggEBADYFSngNYr+hIAIPFbRf7aF0aY1lwHNJdVyFKtCWNu/K7qqKXiXhTSg4
LGazzbriTAgHdvgcMoRvolspjhgsJ7SdOAtRyPFta/QTPeJMj4Hd/mAxkykuNVqYR18LYXyv
VGhRHtOt19rXxpL40vl0OQGRBune06/XfnF5SHCAU+N2KTjbK+jLr77gZFa39nWLBIGB9fZK
smTMclVvw2vBmPs6/uhoEzkYEAiDAmHnfOYYFPxAFFlwEIpLaHFKp5ZKxIZgvLdIZOGM0a2b
oS2bHJhM3dsLNObw8GjvI8sizq79WWZxlMFqAInetvsd7aWCndOwpjUSi4fw1ZG4zWXlmpgw
ggVXMIIEP6ADAgECAgcXr/bsXKnqMA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNVBAYTAkRFMRMw
EQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVy
ZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNjIxWhcNMTkwNzA5MjM1OTAwWjB7
MQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNV
BAMTHkNBIGRlciBVbml2ZXJzaXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtp
QHVuaS1sdWViZWNrLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlmUu5q+1
448Is2yl8dx0GMZN+vQcONK99YxpZzdJSZdnvlQsymtijkhp3UNnXzxBXxk0tegRIaX/Ejz2
AzxLDM/FkfxZ2XRRiuKqVdG+/qczey+MYJyqBti11miUdocoAm+nxthIj1k+3qLzeDyv7DV4
/+XpD313ciqw/X2zD4ZZfpk00fQ7AsqR+aAxjhQLDQJ94dIhOHWD05eu09yxoWJe1ne2fc0m
UXw+mvpTpifOo4LgS9a36ucL3n8CL7BmWGMDk3/rmcjKLBWGZRjCQmNJvSTv2TaERnQxnb9Y
hVUsXi9IptvIGc6ERGj23O6hWkysNMNpAqEThGIV5q6hQwIDAQABo4IB/zCCAfswEgYDVR0T
AQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAowCDAGBgRVHSAAMB0GA1Ud
DgQWBBS3K2/AxxgQMTYXUhB1odBAwzk0HzAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EK
cD7eZDAdBgNVHREEFjAUgRJwa2lAdW5pLWx1ZWJlY2suZGUwgYgGA1UdHwSBgDB+MD2gO6A5
hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2Fjcmwu
Y3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j
cmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggrBgEFBQcwAYYnaHR0cDovL29j
c3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsGAQUFBzAChjtodHRwOi8vY2Rw
MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggr
BgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2Fj
ZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAHWHmI/9W/Qy90CeDlzlpBibL8qt
WOa1F5AafYH61r+IcB66IyQIM4En+g/X+HpkQJfOaufYPzG3BGuspMRWlasA53+9rz/PshO5
UU3+31+UcLV+Dlnakr3cC/8hEUXF5AtTkmaCzYFm1dy4FcdaqK0pURX9YOxhRqUc+vlnuVKc
a20TS6QnLbvJyN4/v2H9IB3pj3eO/lLKicqiUhkdj0cHrNteObDd0ijSBsDbhg/ck99TBCBm
0GLOfrb1cMuHTy+et5K68npIgAojCHZZgLqtO4BGN3CXEKcUX0E+0xixOgNgQRxDgiP25qr8
X97JXm5RY6m1/+EPX7wQVeUYtokxggOzMIIDrwIBATCBhjB7MQswCQYDVQQGEwJERTEgMB4G
A1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJz
aXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlAgcT
QiNG5wZJMAkGBSsOAwIaBQCgggIBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTE0MTAyMTE1MTExNFowIwYJKoZIhvcNAQkEMRYEFCXibsfTGEnWQnePqiAy
F7E1tB3LMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgZcGCSsGAQQBgjcQBDGBiTCBhjB7MQswCQYDVQQGEwJERTEgMB4GA1UEChMX
VW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJzaXRhZXQg
enUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlAgcTQiNG5wZJ
MIGZBgsqhkiG9w0BCRACCzGBiaCBhjB7MQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVy
c2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJzaXRhZXQgenUgTHVl
YmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRlAgcTQiNG5wZJMA0GCSqG
SIb3DQEBAQUABIIBAC6tdevnRLWaKlhmBsh6jC/kUXMbLR6Y0bi3rmO5XDyWhdrUPX5PIVPT
gdDf7lqhM7+2FHRAMYvriqUzh1iiD/ahcFC939EI2UeBvY/P7+mzqWxMHzYBLCMlH61WWw7l
IopijomVWfZgmaStd9eXAOXeeMuZw/TpqDinkNU5/7Bq0VTEn3XrGJcLn6jyI6ue8ulZxLfp
gXsWYgcclQxMZ7kLEissbd1yXtgkvdd5JykkFwgiLNk0+HViNko0HsTMG59YUyJAHaYwCTt+
ar6/nzOb71NxKu6omyxQlZbLAtDz7spEvwB28C/zU1kK9U306z8QLlV7t4G71EOFTixRgBYA
AAAAAAA=
--------------ms010202010003000605090005--


From nobody Tue Oct 21 08:29:04 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8B1A882A for ; Tue, 21 Oct 2014 08:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level: 
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBgSTb1M-V5F for ; Tue, 21 Oct 2014 08:29:00 -0700 (PDT)
Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 524321A87F1 for ; Tue, 21 Oct 2014 08:28:59 -0700 (PDT)
Received: from USA-SJC-GW2.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Tue, 21 Oct 2014 16:28:57 +0100
Received: from Spock.usa.Arm.com ([fe80::4116:859a:65b1:2f84]) by USA-SJC-GW2.usa.Arm.com ([::1]) with mapi; Tue, 21 Oct 2014 08:28:53 -0700
From: Zach Shelby 
To: Kovatsch Matthias 
Date: Tue, 21 Oct 2014 08:28:56 -0700
Thread-Topic: [core] Conflict endpoint idenfier for resource directory draft
Thread-Index: Ac/tQ7iT2Ag/H/3hTOu2d08+m2bKcg==
Message-ID: <1367F1AB-B8C1-41A3-921F-926252375F47@arm.com>
References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> <6253A048-6A69-49CA-B0CC-438D1789856F@tzi.org> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C94@SZXEMA501-MBS.china.huawei.com> <5444FB5E.60503@itm.uni-luebeck.de> <55877B3AFB359744BA0F2140E36F52B52729395B@MBX110.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B52729395B@MBX110.d.ethz.ch>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
MIME-Version: 1.0
X-MC-Unique: 114102116285708402
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/core/FyCYNMI0hZY5VOioKMq7LTG4yKE
Cc: "core@ietf.org" 
Subject: Re: [core] Conflict endpoint idenfier for resource directory draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Oct 2014 15:29:03 -0000

Hi Matthias,

Thanks for picking this up, you are correct. The Endpoint Name is required =
to be unique per RD, however it is used to update the Context (protocol, IP=
, port) of the endpoint. Thus the RD is not able to determine if this is a =
conflicting endpoint or the same endpoint with a new IP address when using =
plain CoAP or HTTP.

However, we do recommend the use of DTLS or TLS with an RD and there is alw=
ays a binding between the endpoint name and the security credential (whethe=
r it is a PSK, RPK or Certificate). Trying to register as an endpoint name =
without the matching credentials would result in a failed authentication ra=
ther than a duplicate RD. Uniqueness of endpoint names goes hand-in-hand wi=
th security management in practice.

Now that I am working on an RD update this week (finally, I know!), I'll ch=
eck through the clarity of this in the draft. If anyone has some text to co=
ntribute or comments for improvement that would of course be helpful.

Yes, 4.09 should be registered in general as per OMA Lightweight M2M (the w=
hole spec really needs an IANA review, as there are plenty of things still =
to be registered).

Zach

On Oct 21, 2014, at 4:38 PM, "Kovatsch  Matthias"  wr=
ote:

>> If an Endpoint registered itself to Resource Directory Server
>> with a conflicted ID, RD Server should return an error code to
>> ask the endpoint to choose another identifier.
>
> My question here is: How should the RD know that this is a conflict?
> The point of using this ID is to identify the same endpoint over changing=
 addresses or even transports (e.g., UDP and SMS).
>
> The natural reaction would be to assume the endpoint crashed and is now r=
egistering after a reboot. As Zach mentioned in the other thread, this ID i=
s somehow linked to the endpoint certificate. So the assumption is that the=
re is another entity that ensures uniqueness.
>
>> Should we aim at assigning 4.09?
>> And what would be a good error payload?
>
> Considering 4.09 is used in the OMA Lightweight M2M specification, we pro=
bably should define it. At least there is a use case out there, given that =
we can figure out how to know that something is a conflict :)
>
> Ciao
> Matthias
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

Zach Shelby
Director of Technical Marketing
ARM Internet of Things BU
www.arm.com
US: +1 (408) 203-9434
Finland: +358 407796297
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/


-- IMPORTANT NOTICE: The contents of this email and any attachments are con=
fidential and may also be privileged. If you are not the intended recipient=
, please notify the sender immediately and do not disclose the contents to =
any other person, use it for any purpose, or store or copy the information =
in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist=
ered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R=
egistered in England & Wales, Company No:  2548782


From nobody Tue Oct 21 09:21:51 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE9C1A88BB for ; Tue, 21 Oct 2014 09:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MU4mF1Dvgxgp for ; Tue, 21 Oct 2014 09:21:45 -0700 (PDT)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F201A8919 for ; Tue, 21 Oct 2014 09:21:42 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id ft15so1666559pdb.3 for ; Tue, 21 Oct 2014 09:21:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uCIfaSVageBQ802TIBnBARnNnvxvGrproGk1CapLzJ8=; b=twEl9c5uav7cQPE5b45wjDuIPRVBLjjLK2xFJVB+7JL7g5t/fFy3p3BtPbanycJnDD PPhgVxSDwI0oOkRkH1/lhAtM4R95lcZB+REkPuZ2Br6iydtARv8x3aUQw/4EZN5VhKsU PGwAMs2EVb4/1lGkUvPkiWyuWcHAg0Bvbwnlpmxnmb2AHJX5ISirj/q8+0ZGfH7LnRnA h+9w2YfbYvudTMSDLmUItsOEpWWssDI7fLwUViBuk0wz6Ipm5wfurw43yDYXToOAw1il KcwCUtLAHrCRbJ3Xw8fFkpz8czWRS90NCnwBB8QVptBWknMk0K15TdJJB2cVW9o0dtFt N0Bg==
X-Received: by 10.66.171.135 with SMTP id au7mr14108302pac.80.1413908502300; Tue, 21 Oct 2014 09:21:42 -0700 (PDT)
Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by mx.google.com with ESMTPSA id fz1sm5430662pbb.80.2014.10.21.09.21.39 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 09:21:40 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Koster 
In-Reply-To: <1367F1AB-B8C1-41A3-921F-926252375F47@arm.com>
Date: Tue, 21 Oct 2014 09:21:43 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B37443C-72A5-49B9-B5DD-4258DC1A592C@gmail.com>
References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> <6253A048-6A69-49CA-B0CC-438D1789856F@tzi.org> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C94@SZXEMA501-MBS.china.huawei.com> <5444FB5E.60503@itm.uni-luebeck.de> <55877B3AFB359744BA0F2140E36F52B52729395B@MBX110.d.ethz.ch> <1367F1AB-B8C1-41A3-921F-926252375F47@arm.com>
To: Zach Shelby 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/core/PkczjWYOWPUw2sRmTg4H0KuD-HI
Cc: "core@ietf.org" 
Subject: Re: [core] Conflict endpoint idenfier for resource directory draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Oct 2014 16:21:47 -0000

Rebooting an endpoint with a new IP address is very common, and is a =
reasonable assumption. It=92s also reasonable IMO to require a =
certificate check to differentiate between the normal case of changing =
IP address and duplicate EP name errors, i.e. without security you can=92t=
 identify duplicate endpoint name errors.

Michael

On Oct 21, 2014, at 8:28 AM, Zach Shelby  wrote:

> Hi Matthias,
>=20
> Thanks for picking this up, you are correct. The Endpoint Name is =
required to be unique per RD, however it is used to update the Context =
(protocol, IP, port) of the endpoint. Thus the RD is not able to =
determine if this is a conflicting endpoint or the same endpoint with a =
new IP address when using plain CoAP or HTTP.
>=20
> However, we do recommend the use of DTLS or TLS with an RD and there =
is always a binding between the endpoint name and the security =
credential (whether it is a PSK, RPK or Certificate). Trying to register =
as an endpoint name without the matching credentials would result in a =
failed authentication rather than a duplicate RD. Uniqueness of endpoint =
names goes hand-in-hand with security management in practice.
>=20
> Now that I am working on an RD update this week (finally, I know!), =
I'll check through the clarity of this in the draft. If anyone has some =
text to contribute or comments for improvement that would of course be =
helpful.
>=20
> Yes, 4.09 should be registered in general as per OMA Lightweight M2M =
(the whole spec really needs an IANA review, as there are plenty of =
things still to be registered).
>=20
> Zach
>=20
> On Oct 21, 2014, at 4:38 PM, "Kovatsch  Matthias" =
 wrote:
>=20
>>> If an Endpoint registered itself to Resource Directory Server
>>> with a conflicted ID, RD Server should return an error code to
>>> ask the endpoint to choose another identifier.
>>=20
>> My question here is: How should the RD know that this is a conflict?
>> The point of using this ID is to identify the same endpoint over =
changing addresses or even transports (e.g., UDP and SMS).
>>=20
>> The natural reaction would be to assume the endpoint crashed and is =
now registering after a reboot. As Zach mentioned in the other thread, =
this ID is somehow linked to the endpoint certificate. So the assumption =
is that there is another entity that ensures uniqueness.
>>=20
>>> Should we aim at assigning 4.09?
>>> And what would be a good error payload?
>>=20
>> Considering 4.09 is used in the OMA Lightweight M2M specification, we =
probably should define it. At least there is a use case out there, given =
that we can figure out how to know that something is a conflict :)
>>=20
>> Ciao
>> Matthias
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>=20
>=20
> Zach Shelby
> Director of Technical Marketing
> ARM Internet of Things BU
> www.arm.com
> US: +1 (408) 203-9434
> Finland: +358 407796297
> Skype: zdshelby
> LinkedIn: fi.linkedin.com/in/zachshelby/
>=20
>=20
> -- IMPORTANT NOTICE: The contents of this email and any attachments =
are confidential and may also be privileged. If you are not the intended =
recipient, please notify the sender immediately and do not disclose the =
contents to any other person, use it for any purpose, or store or copy =
the information in any medium.  Thank you.
>=20
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, =
Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 =
9NJ, Registered in England & Wales, Company No:  2548782
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From nobody Thu Oct 23 14:12:19 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1E1ACFD2; Thu, 23 Oct 2014 14:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1STBjnuLZaAl; Thu, 23 Oct 2014 14:12:09 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A6F1A1B0A; Thu, 23 Oct 2014 14:12:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141023211209.25198.63186.idtracker@ietfa.amsl.com>
Date: Thu, 23 Oct 2014 14:12:09 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/core/FD4dQHVLsWjSwoAGZJDNoeJpi2o
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-http-mapping-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 21:12:13 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.

        Title           : Guidelines for HTTP-CoAP Mapping Implementations
        Authors         : Angelo P. Castellani
                          Salvatore Loreto
                          Akbar Rahman
                          Thomas Fossati
                          Esko Dijk
	Filename        : draft-ietf-core-http-mapping-05.txt
	Pages           : 30
	Date            : 2014-10-23

Abstract:
   This draft provides reference information for HTTP-CoAP protocol
   translation proxy implementation, focusing on the reverse proxy case.
   It details deployment options, defines a template for URI mapping,
   and provides a set of guidelines and considerations related to
   protocol translation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-http-mapping-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Oct 23 14:17:42 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3376F1A6F0D for ; Thu, 23 Oct 2014 14:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYpqi3TKq8tT for ; Thu, 23 Oct 2014 14:17:37 -0700 (PDT)
Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24FA1A870D for ; Thu, 23 Oct 2014 14:17:36 -0700 (PDT)
X-ASG-Debug-ID: 1414099055-06daaa130c0a7f0001-aa7cYp
Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id K0vECmDAuicRqfAv for ; Thu, 23 Oct 2014 17:17:35 -0400 (EDT)
X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com
Received: from interdigital.com ([10.0.128.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 23 Oct 2014 17:17:34 -0400
Received: from KYANITE.InterDigital.com ([10.1.64.253]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 23 Oct 2014 17:17:34 -0400
Received: from NISSONITE.InterDigital.com (10.2.64.252) by KYANITE.InterDigital.com (10.1.64.253) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 23 Oct 2014 17:17:33 -0400
Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0210.002; Thu, 23 Oct 2014 17:17:32 -0400
From: "Rahman, Akbar" 
To: "core@ietf.org" 
Thread-Topic: [core] I-D Action: draft-ietf-core-http-mapping-05.txt
X-ASG-Orig-Subj: RE: [core] I-D Action: draft-ietf-core-http-mapping-05.txt
Thread-Index: AQHP7wYZCAXRrgEitke0Dyys6tvXlpw+LkUw
Date: Thu, 23 Oct 2014 21:17:32 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F022EE6@NABESITE.InterDigital.com>
References: <20141023211209.25198.63186.idtracker@ietfa.amsl.com>
In-Reply-To: <20141023211209.25198.63186.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.1.158]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 23 Oct 2014 21:17:34.0381 (UTC) FILETIME=[C3614DD0:01CFEF06]
X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27]
X-Barracuda-Start-Time: 1414099055
X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at interdigital.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.10863 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Archived-At: http://mailarchive.ietf.org/arch/msg/core/XRhxU3U5cu8YOGVMQTTAn4qkSdU
Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Oct 2014 21:17:40 -0000

Hi,


We have updated the draft to address the following points:

   Changes from ietf-04 to ietf-05:

   o  Addressed Ticket #366 (Mapping of CoRE Link Format payloads to be
      valid in HTTP Domain?) in section 6.3.3.2 (Content Transcoding -
      CORE Link Format);

   o  Addressed Ticket #375 (Add requirement on mapping of CoAP
      diagnostic payload) in section 6.3.3.3 (Content Transcoding -
      Diagnostic Messages);

   o  Addressed comment from Yusuke (http://www.ietf.org/mail-
      archive/web/core/current/msg05491.html) in section 6.3.3.1
      (Content Transcoding - General);

   o  Various editorial improvements.


Please feel free to comment.

Best Regards,


Akbar

-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf=
.org
Sent: Thursday, October 23, 2014 5:12 PM
To: i-d-announce@ietf.org
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-http-mapping-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Constrained RESTful Environments Working =
Group of the IETF.

        Title           : Guidelines for HTTP-CoAP Mapping Implementations
        Authors         : Angelo P. Castellani
                          Salvatore Loreto
                          Akbar Rahman
                          Thomas Fossati
                          Esko Dijk
	Filename        : draft-ietf-core-http-mapping-05.txt
	Pages           : 30
	Date            : 2014-10-23

Abstract:
   This draft provides reference information for HTTP-CoAP protocol
   translation proxy implementation, focusing on the reverse proxy case.
   It details deployment options, defines a template for URI mapping,
   and provides a set of guidelines and considerations related to
   protocol translation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-http-mapping-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-http-mapping-05


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


From nobody Thu Oct 23 16:30:02 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F131A1BDA; Thu, 23 Oct 2014 16:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.349
X-Spam-Level: 
X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFtBq50p-q0h; Thu, 23 Oct 2014 16:29:53 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F9C1A1BCA; Thu, 23 Oct 2014 16:29:52 -0700 (PDT)
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 mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9NNTlA3021730; Fri, 24 Oct 2014 01:29:47 +0200 (CEST)
Received: from [192.168.217.113] (p54890BCA.dip0.t-ipconnect.de [84.137.11.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4E0EDA16; Fri, 24 Oct 2014 01:29:47 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Carsten Bormann 
In-Reply-To: 
Date: Fri, 24 Oct 2014 01:29:46 +0200
X-Mao-Original-Outgoing-Id: 435799786.17433-f6619cc07cfa9dbde4abfc5548d6f7db
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140820195839.24268.61215.idtracker@ietfa.amsl.com> 
To: Richard Barnes 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/core/gB14tAwaHxfcHamg7kSFmRk12os
Cc: draft-ietf-core-observe@tools.ietf.org, "core-chairs@tools.ietf.org" , "core@ietf.org WG" , The IESG , Klaus Hartke 
Subject: Re: [core] Richard Barnes' Discuss on draft-ietf-core-observe-14: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Oct 2014 23:29:55 -0000

Richard,

I=E2=80=99m assuming the best way forward is for Klaus to write up the =
changes resulting from the discussion below (and the other COMMENTs), =
submit a -15, and take it from there?

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



> On 23 Sep 2014, at 15:50, Klaus Hartke  wrote:
>=20
> Hi Richard,
>=20
> thank you for your review and questions.
>=20
>=20
> Richard Barnes wrote:
>> One very temporary point: Has anyone done a comparison between this =
work
>> and the server push aspects of HTTP/2?  Is there any value in trying =
to
>> align the two?
>=20
> If I'm not mistaken, the server push in HTTP/2 is used when a server
> can predict which resources the client is going to request next. For
> example, when an HTML document contains an  element, it's highly
> likely that a web browser will request the linked image next. However,
> once the representation has been pushed to the browser, the server
> cannot update the displayed page by pushing updated representations.
>=20
> The "CoAP observe" protocol is used when a client wants to have a
> fresh representation over a period of time. The server pushes updated
> representations, but it cannot push representations of resources that
> the client didn't request. In a web browser, a similar effect can be
> achieved using  or some =
ad-hoc
> solution based on repeated AJAX calls, Long-Polling, Server-Sent
> Events or WebSockets, except that any of these mechanisms either cause
> a lot of unnecessary traffic, bypass the cache, or break REST in some
> other way.
>=20
> The closest equivalent to "CoAP observe" in the HTTP world that I'm
> aware of is the MONITOR verb in Roy Fielding's Waka.
>=20
>=20
>> It's unclear to me from the text of Section 2 how the 0/1
>> register/deregister values are used.  Are these reserved values out =
of
>> the sequence number space?  Or are they carried somewhere else in the
>> option?  I infer from Section 3.6 that the answer is the former, but
>> Section 2 should be explicit about this.
>=20
> The value of the Observe Option depends on where it's used: in
> requests or in notifications/responses. In notifications/responses,
> the value is a sequence number. In a request, the value is either
> 'register' or 'unregister'. The two spaces do not overlap.
>=20
>> In fact, it seems like it's not necessary to reserve the value 1 at =
all,
>> since the server must interpret any positive value as deregistration.
>> Calling out 1 as special invites server implementations to screw this
>> up.
>=20
> I could have written: "The client MUST be conservative in what it
> sends; the server MUST be liberal in what it accepts."
>=20
>=20
>> "the time elapsed between the two incoming messages is not so large =
that
>> the difference between V1 and V2 has become larger than the largest
>> integer that it is meaningful to add to a 24-bit serial number"
>> The text seems confused about whether the value of the Observe option =
is
>> a serial number or a time value.  The definition says that it's a =
serial
>> number, but this sentence implies that it's somehow related to time.  =
In
>> order to avoid clients making unwarranted assumptions about the value =
of
>> the Observe option, it seems important to clarify this.
>=20
> We want implementations to be able to generate the sequence number
> from a client-local clock, so the client doesn't have to maintain any
> counters. That makes the sequence number a "temporal serial number".
> I'm aware that the draft doesn't fully explain how they work (temporal
> serial number arithmetic is hard), but the requirements for
> implementations have been verified multiple times and validated in
> interop events.
>=20
>=20
>> "And third, the server may erroneously come to the conclusion that =
the
>> client is no longer interested"
>> To mitigate this, might it be useful for a client to sometimes send
>> "gratuitous ACKs"? That is, to periodically re-ACK the last =
notification
>> to re-confirm its interest?
>=20
> The server makes several attempts to contact the client before it
> removes an entry from the list of observers. So a client is really
> only removed when there is a network partition or heavy congestion. In
> that case, a periodic acknowledgement wouldn't help as well. At some
> point, an unresponsive client has to be declared dead and removed from
> the list of observers. If a client wants to make sure that it's still
> on the list (for example, if it hasn't heard from the server for some
> time), then it can easily re-register by sending another GET request
> with Observe Option and the previously used token.
>=20
>=20
>> "If the server returns a 2.xx response that includes an Observe =
Option as
>> well..."
>> Does the value of this option matter at all?  Could the server, for
>> example, simply mirror the client's option?
>=20
> At this stage (send a request, get a response) it's only important
> that the Observe Option is present. However, when it comes to
> reordering detection, the value is important; it must be a sequence
> number. This is specified in section 4.4 of the document [1].
>=20
> [1] https://tools.ietf.org/html/draft-ietf-core-observe-14#section-4.4
>=20
>=20
>> "Notifications are additional responses..."
>> Might be helpful to re-word to emphasize that the only difference =
between
>> a "notification" and a normal response is the presence of the Observe
>> option.
>=20
> I've added this to the end of that paragraph:
>=20
>   Notifications are additional responses sent by the server in reply =
to
>   the single extended GET request that created the registration.  Each
>   notification includes the token specified by the client in the
>   request.  The only difference between a notification and a normal
>   response is the presence of the Observe Option.
>=20
>=20
>> "Non-2.xx responses do not include an Observe Option..."
>> Should this be a MUST NOT?  It seems like an interop requirement, in =
the
>> sense of maintaining a consistent view of subscription state between
>> server and client.
>=20
> This sentence is just a non-normative summary of the normative
> requirements for servers in section 4.2 [2]:
>=20
>   "A 2.xx notification MUST include an Observe Option with a sequence
>   number as specified in Section 4.4 below; a non-2.xx notification
>   MUST NOT include an Observe Option."
>=20
> [2] http://tools.ietf.org/html/draft-ietf-core-observe-14#section-4.2
>=20
>=20
> Klaus
>=20


From nobody Fri Oct 24 09:11:51 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FC01A1BC2 for ; Fri, 24 Oct 2014 09:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_H14cDCJSGJ for ; Fri, 24 Oct 2014 09:11:46 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5BB1A1BA0 for ; Fri, 24 Oct 2014 09:11:45 -0700 (PDT)
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 mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9OGBgRW028151 for ; Fri, 24 Oct 2014 18:11:42 +0200 (CEST)
Received: from eduroam-pool7-0064.wlan.uni-bremen.de (eduroam-pool7-0064.wlan.uni-bremen.de [134.102.112.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 576A293; Fri, 24 Oct 2014 18:11:42 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Carsten Bormann 
Date: Fri, 24 Oct 2014 18:11:39 +0200
X-Mao-Original-Outgoing-Id: 435859899.341694-29f77cb47c52bbbe3fa9fbaeb0a64723
Content-Transfer-Encoding: quoted-printable
Message-Id: 
To: "core@ietf.org WG" 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/core/_70csY4vfJaBiWickdw_4cEXPkw
Subject: [core] CoAP over TCP
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Oct 2014 16:11:49 -0000

In alternative transports, I believe we have three hot topics:

1) General issues.  draft-silverajan-core-coap-alternative-transports is =
a good basis for this and we will do the call for adoption soon.

2) CoAP over SMS.  This is also related to the question of DTLS over =
SMS.  We have a good draft for the former, which is mostly waiting for =
(1).  draft-fossati-dtls-over-gsm-sms merits some discussion.

3) CoAP over TCP.  draft-bormann-core-coap-tcp-01 is a summary of the =
design choices. draft-tschofenig-core-coap-tcp-tls selects one option =
without explaining why.  draft-savolainen-core-coap-websockets (apart =
from being focused on web sockets, so it would need the addition of a =
length field) selects a different set of options, also not really =
explaining why.  This merits a discussion.

I believe we should have a quick round of discussion about (3).  CoAP =
over TCP is of strong interest to people building scalable cloud-side =
CoAP implementations.  CoAP over TCP also is a NAT traversal strategy =
(where the server builds the connection to a client in the cloud).  =
Finally, CoAP over TCP can be useful to combine the better congestion =
control of TCP with the economy of CoAP.  So there are enough reasons to =
get this going.

The main questions I see are:

a) what is the delimiting mechanism?
   =E2=80=94 length field
     =E2=80=94 fixed 4-byte, fixed 2-byte, variable?
   =E2=80=94 MINION-style (delimiters)
   =E2=80=94 extending the payload marker
b) what part of the CoAP header remains active over a reliable =
transport?  Can we lose
   =E2=80=94 the message id,
   =E2=80=94 the message type,
   =E2=80=94 the version number?
c) any negotiation/version indication mechanisms?
   =E2=80=94 starttls???
   =E2=80=94 server/client prompts
   =E2=80=94 ALPN
   =E2=80=94 other payloads, e.g. stream errors?

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


From nobody Fri Oct 24 23:08:55 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C5D1A6FAD for ; Fri, 24 Oct 2014 23:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3qTIDj3Nnwa for ; Fri, 24 Oct 2014 23:08:42 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12771A6FB1 for ; Fri, 24 Oct 2014 23:08:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOA35260; Sat, 25 Oct 2014 06:08:40 +0000 (GMT)
Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 25 Oct 2014 07:08:39 +0100
Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.205]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Sat, 25 Oct 2014 14:08:35 +0800
From: Likepeng 
To: "core@ietf.org" 
Thread-Topic: New Version Notification for draft-li-core-coap-patience-option-05.txt
Thread-Index: AQHP8BlVnf8QuSUrt0mgaMTqG6sGwpxAUorg
Date: Sat, 25 Oct 2014 06:08:34 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A8CD1@SZXEMA501-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.167.122]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/core/3FbjzSi06jmqTuB3JNlbjZXuKXY
Subject: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Oct 2014 06:08:48 -0000

SGVsbG8gYWxsLA0KDQpQbGVhc2UgZmluZCB1cGRhdGVkIFBhdGllbmNlIG9wdGlvbiBkcmFmdC4N
Cg0KSW4gdGhpcyB2ZXJzaW9uLCB3ZSByZW1vdmVkIOKAnG11bHRpY2FzdCB1c2FnZeKAnSBhbmQg
4oCcb2JzZXJ2YXRpb24gbm90aWZpY2F0aW9uIHVzYWdl4oCdLCBqdXN0IGZvY3VzIG9uIHRoZSDi
gJx1bmljYXN0IHJlcXVlc3QgdXNhZ2XigJ0uIFRoaXMgY2FuIG1ha2UgdGhlIHNlbWFudGljcyBj
bGVhciwgZG9u4oCZdCBjb21iaW5lIGRpZmZlcmVudCB1c2FnZXMuIFRoaXMgY2FuIGFsc28gYXZv
aWQgY29uZnVzaW9ucyBhbmQgbWFrZSB0aGUgaW1wbGVtZW50YXRpb24gZWFzaWVyLiBUaGlzIGNo
YW5nZSB3YXMgYmFzZWQgb24gb2ZmbGluZSBkaXNjdXNzaW9uIHdpdGggaW50ZXJlc3RlZCBwYXJ0
aWVzLg0KDQpBbHNvIHdlIHNpbXBsaWZpZWQgdGhlIGFsZ29yaXRobSwganVzdCB1c2VkIHR3byBi
eXRlcyB0byBzcGVjaWZ5IGludGVnZXJzIGZvciB0aGUgcGF0aWVuY2UgdGltZS4gUHJldmlvdXNs
eSB0aGUgZGVzaWduIHdhcyB0byBhbGxvdyB2ZXJ5IHNob3J0IHRpbWUgbWVhc3VyZWQgaW4gbWls
bGUtc2Vjb25kcy4gQWZ0ZXIgc29tZSBjb25zaWRlcmF0aW9uIGFuZCBvZmZsaW5lIGRpc2N1c3Np
b24sIHdlIHRlbmQgdG8gbWFrZSBpdCBsb25nZXIuIFVzdWFsbHkgcmVxdWVzdCBhbmQgcmVzcG9u
c2Ugc2hvdWxkIHRha2Ugc29tZSB0aW1lLCBhbmQgYWxsIHRoZSBkZWZhdWx0IHRpbWVvdXQgcGFy
YW1ldGVycyBpbiBDb0FQIGFyZSBzZXQgaW4gc2Vjb25kcy4gU28gaXQgd291bGQgbWFrZSBzZW5z
ZSB0byBkZXNpZ24gUGF0aWVuY2UgbWVhc3VyZWQgaW4gc2Vjb25kcywgaW5zdGVhZCBvZiBtaWxs
ZS1zZWNvbmRzLiBDbGllbnQgc2hvdWxkIGhhdmUgdGhpcyBsZXZlbCBvZiBwYXRpZW5jZS4NCg0K
V2VsY29tZSB5b3VyIGZlZWRiYWNrIG9uIHRoaXMgZHJhZnQuDQoNClRoYW5rcw0KS2luZCBSZWdh
cmRzDQpLZXBlbmcgTGkgDQpPbiBiZWhhbGYgb2YgY28tYXV0aG9ycw0KDQotLS0tLemCruS7tuWO
n+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu
dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQxMOaciDI15pel
IDE0OjAzDQrmlLbku7bkuro6IEJlcnQgR3JlZXZlbmJvc2NoOyBMaWtlcGVuZzsgU2FsdmF0b3Jl
IExvcmV0bzsgU2FsdmF0b3JlIExvcmV0bzsgRXNrbyBEaWprOyBFc2tvIERpams7IEJlcnQgR3Jl
ZXZlbmJvc2NoOyBMaWtlcGVuZw0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y
IGRyYWZ0LWxpLWNvcmUtY29hcC1wYXRpZW5jZS1vcHRpb24tMDUudHh0DQoNCg0KQSBuZXcgdmVy
c2lvbiBvZiBJLUQsIGRyYWZ0LWxpLWNvcmUtY29hcC1wYXRpZW5jZS1vcHRpb24tMDUudHh0DQpo
YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEtlcGVuZyBMaSBhbmQgcG9zdGVkIHRv
IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1saS1jb3JlLWNvYXAtcGF0aWVu
Y2Utb3B0aW9uDQpSZXZpc2lvbjoJMDUNClRpdGxlOgkJQ29BUCBPcHRpb24gRXh0ZW5zaW9uOiBQ
YXRpZW5jZQ0KRG9jdW1lbnQgZGF0ZToJMjAxNC0xMC0yNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1
Ym1pc3Npb24NClBhZ2VzOgkJNg0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv
aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpLWNvcmUtY29hcC1wYXRpZW5jZS1vcHRpb24tMDUudHh0
DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
bGktY29yZS1jb2FwLXBhdGllbmNlLW9wdGlvbi8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1jb3JlLWNvYXAtcGF0aWVuY2Utb3B0aW9uLTA1DQpE
aWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGkt
Y29yZS1jb2FwLXBhdGllbmNlLW9wdGlvbi0wNQ0KDQpBYnN0cmFjdDoNCiAgIENvQVAgaXMgYSBS
RVNUZnVsIGFwcGxpY2F0aW9uIHByb3RvY29sIGZvciBjb25zdHJhaW5lZCBub2RlcyBhbmQNCiAg
IG5ldHdvcmtzLiAgVGhpcyBzcGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEgc2ltcGxlIGV4dGVuc2lv
biBmb3IgQ29BUCwNCiAgIHRoZSBQYXRpZW5jZSBvcHRpb24uICBUaGlzIG9wdGlvbiBpcyB1c2Vk
IGJ5IGEgQ29BUCBjbGllbnQgdG8NCiAgIGluZGljYXRlIHRoZSBtYXhpbXVtIHRpbWUgYSBjbGll
bnQgaXMgcHJlcGFyZWQgdG8gd2FpdCBmb3IgYQ0KICAgcmVzcG9uc2UuICBUaGUgQ29BUCBzZXJ2
ZXIgc2hvdWxkIHRyeSB0byByZXR1cm4gdGhlIHJlc3BvbnNlIHdpdGhpbg0KICAgdGhlIHNwZWNp
ZmllZCB0aW1lIGZyYW1lLg0KDQpOb3RlDQoNCiAgIERpc2N1c3Npb24gYW5kIHN1Z2dlc3Rpb25z
IGZvciBpbXByb3ZlbWVudCBhcmUgcmVxdWVzdGVkLCBhbmQgc2hvdWxkDQogICBiZSBzZW50IHRv
IGNvcmVAaWV0Zi5vcmcuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ug
bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv
ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp
bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==


From nobody Sat Oct 25 12:23:45 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC631A1BF1 for ; Sat, 25 Oct 2014 12:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1ZbzwsDByN9 for ; Sat, 25 Oct 2014 12:23:41 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9F11A1BC9 for ; Sat, 25 Oct 2014 12:23:41 -0700 (PDT)
Received: from localhost ([::1]:57318 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xi6vz-0006Mm-MX; Sat, 25 Oct 2014 12:23:31 -0700
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-resource-directory@tools.ietf.org, zach@sensinode.com
X-Trac-Project: core
Date: Sat, 25 Oct 2014 19:23:31 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/369#comment:1
Message-ID: <072.b5840e62a300869e4ed6a9a5851d0531@trac.tools.ietf.org>
References: <057.b46cf6744929bebb46803c866d11b1d0@trac.tools.ietf.org>
X-Trac-Ticket-ID: 369
In-Reply-To: <057.b46cf6744929bebb46803c866d11b1d0@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, srdjan.krco@ericsson.com, zach.shelby@arm.com
Archived-At: http://mailarchive.ietf.org/arch/msg/core/K4b37miLY6eHGbInY-IlUbQXIhk
Cc: core@ietf.org
Subject: Re: [core] #369 (resource-directory): Semantic Catalogue use case addition
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: trac+core@zinfandel.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: Sat, 25 Oct 2014 19:23:44 -0000

#369: Semantic Catalogue use case addition

Changes (by zach@sensinode.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Closed in -02.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-resource-
  zach@sensinode.com     |  directory@tools.ietf.org
     Type:  editorial    |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  resource-    |     Version:
  directory              |  Resolution:  fixed
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Sat Oct 25 12:25:05 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC181A2119 for ; Sat, 25 Oct 2014 12:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VHlrSkKnYMA for ; Sat, 25 Oct 2014 12:25:02 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956DC1A1BF1 for ; Sat, 25 Oct 2014 12:25:02 -0700 (PDT)
Received: from localhost ([::1]:57360 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xi6xM-00054q-9E; Sat, 25 Oct 2014 12:24:56 -0700
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-resource-directory@tools.ietf.org, zach@sensinode.com
X-Trac-Project: core
Date: Sat, 25 Oct 2014 19:24:56 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/373#comment:1
Message-ID: <072.ab06b1c72cc3f3b83a6734e264250290@trac.tools.ietf.org>
References: <057.ce12f57512efcbd1b1311e8fc126139b@trac.tools.ietf.org>
X-Trac-Ticket-ID: 373
In-Reply-To: <057.ce12f57512efcbd1b1311e8fc126139b@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, srdjan.krco@ericsson.com, zach.shelby@arm.com
Archived-At: http://mailarchive.ietf.org/arch/msg/core/TMvq2riI7egu3LcC6xboTB8APQs
Cc: core@ietf.org
Subject: Re: [core] #373 (resource-directory): Fix the registration update interface
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: trac+core@zinfandel.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: Sat, 25 Oct 2014 19:25:04 -0000

#373: Fix the registration update interface

Changes (by zach@sensinode.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done in -02.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-resource-
  zach@sensinode.com     |  directory@tools.ietf.org
     Type:  protocol     |      Status:  closed
  enhancement            |   Milestone:
 Priority:  major        |     Version:
Component:  resource-    |  Resolution:  fixed
  directory              |
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Sat Oct 25 12:54:24 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C491A6EDC for ; Sat, 25 Oct 2014 12:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level: 
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe7OVHQdDrrB for ; Sat, 25 Oct 2014 12:54:22 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26B51A1AB8 for ; Sat, 25 Oct 2014 12:54:21 -0700 (PDT)
Received: from localhost ([::1]:58826 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xi7Pi-000813-1Y; Sat, 25 Oct 2014 12:54:14 -0700
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-resource-directory@tools.ietf.org, zach@sensinode.com
X-Trac-Project: core
Date: Sat, 25 Oct 2014 19:54:14 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/370#comment:1
Message-ID: <072.253219cf983a3861c17347d0c2f68cdd@trac.tools.ietf.org>
References: <057.cd8c89deadfdd946c0ce9b786e500868@trac.tools.ietf.org>
X-Trac-Ticket-ID: 370
In-Reply-To: <057.cd8c89deadfdd946c0ce9b786e500868@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, srdjan.krco@ericsson.com, zach.shelby@arm.com
Archived-At: http://mailarchive.ietf.org/arch/msg/core/3DuKBs0UTzhZhgItK_aD1bzQrHQ
Cc: core@ietf.org
Subject: Re: [core] #370 (resource-directory): Integrate the DNS-SD mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: trac+core@zinfandel.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: Sat, 25 Oct 2014 19:54:24 -0000

#370: Integrate the DNS-SD mapping

Changes (by zach@sensinode.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Integrated contribution from Peter Van Der Stok in -02.

 9.  DNS-SD Mapping

    CoRE Resource Discovery is intended to support fine-grained discovery
    of hosted resources, their attributes, and possibly other resource
    relations [RFC6690].  In contrast, service discovery generally refers
    to a coarse-grained resolution of an end-point's IP address, port
    number, and protocol.

    Resource and service discovery are complementary in the case of large
    networks, where the latter can facilitate scaling.  This document
    defines a mapping between CoRE Link Format attributes and DNS-Based
    Service Discovery [RFC6763] fields that permits discovery of CoAP
    services by either means.

 9.1.  DNS-based Service discovery

    DNS-Based Service Discovery (DNS-SD) defines a conventional method of
    configuring DNS PTR, SRV, and TXT resource records to facilitate
    discovery of services (such as CoAP servers in a subdomain) using the
    existing DNS infrastructure.  This section gives a brief overview of
    DNS-SD; see [RFC6763] for a detailed specification.

    DNS-SD service names are limited to 255 octets and are of the form:

    Service Name = ...

    The service name is the label of SRV/TXT resource records.  The SRV
    RR specifies the host and the port of the endpoint.  The TXT RR



 Shelby & Bormann         Expires April 28, 2015                [Page 25]

 Internet-Draft           CoRE Resource Directory            October 2014


    provides additional information.

    The  part of the service name is identical to the global (DNS
    subdomain) part of the authority in URIs that identify servers or
    groups of servers.

    The  part is composed of at least two labels.  The first
    label of the pair is the application protocol name [RFC6335] preceded
    by an underscore character.  The second label indicates the transport
    and is always "_udp" for CoAP services.  In cases where narrowing the
    scope of the search may be useful, these labels may be optionally
    preceded by a subtype name followed by the "_sub" label.  An example
    of this more specific  is "lamp._sub._dali._udp".

    The default  part of the service name may be set at the
    factory or during the commissioning process.  It SHOULD uniquely
    identify an instance of  within a .  Taken
    together, these three elements comprise a unique name for an SRV/ TXT
    record pair within the DNS subdomain.

    The granularity of a service name MAY be that of a host or group, or
    it could represent a particular resource within a CoAP server.  The
    SRV record contains the host name (AAAA record name) and port of the
    service while protocol is part of the service name.  In the case
    where a service name identifies a particular resource, the path part
    of the URI must be carried in a corresponding TXT record.

    A DNS TXT record is in practice limited to a few hundred octets in
    length, which is indicated in the resource record header in the DNS
    response message.  The data consists of one or more strings
    comprising a key=value pair.  By convention, the first pair is
    txtver= (to support different versions of a service
    description).

 9.2.  mapping ins to 

    The Resource Instance "ins" attribute maps to the  part of
    a DNS-SD service name.  It is stored directly in the DNS as a single
    DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode"
    (Unicode Normalization Form C) [RFC5198] text.  However, to the
    extent that the "ins" attribute may be chosen to match the DNS host
    name of a service, it SHOULD use the syntax defined in Section 3.5 of
    [RFC1034] and Section 2.1 of [RFC1123].

    The  part of the name of a service being offered on the
    network SHOULD be configurable by the user setting up the service, so
    that he or she may give it an informative name.  However, the device
    or service SHOULD NOT require the user to configure a name before it



 Shelby & Bormann         Expires April 28, 2015                [Page 26]

 Internet-Draft           CoRE Resource Directory            October 2014


    can be used.  A sensible choice of default name can allow the device
    or service to be accessed in many cases without any manual
    configuration at all.  The default name should be short and
    descriptive, and MAY include a collision-resistent substring such as
    the lower bits of the device's MAC address, serial number,
    fingerprint, or other identifier in an attempt to make the name
    relatively unique.

    DNS labels are currently limited to 63 octets in length and the
    entire service name may not exceed 255 octets.

 9.3.  Mapping rt to 

    The resource type "rt" attribute is mapped into the 
    part of a DNS-SD service name and SHOULD conform to the reg-rel-type
    production of the Link Format defined in Section 2 of [RFC6690].  The
    "rt" attribute MUST be composed of at least a single Net-Unicode text
    string, without underscore '_' or period '.' and limited to 15 octets
    in length, which represents the application protocol name.  This
    string is mapped to the DNS-SD  by prepending an
    underscore and appending a period followed by the "_udp" label.  For
    example, rt="dali" is mapped into "_dali._udp".

    The application protocol name may be optionally followed by a period
    and a service subtype name consisting of a Net-Unicode text string,
    without underscore or period and limited to 63 octets.  This string
    is mapped to the DNS-SD  by appending a period followed
    by the "_sub" label and then appending a period followed by the
    service type label pair derived as in the previous paragraph.  For
    example, rt="dali.light" is mapped into "light._sub._dali._udp".

    The resulting string is used to form labels for DNS-SD records which
    are stored directly in the DNS.

 9.4.  Domain mapping

    DNS zones are defined from the "d" attribute.The domain attribute is
    suffixed to the host name and should be consistent with the domain
    name attributed to the hosting network segment.

 9.5.  TXT Record key=value strings

    The resource  is exported to the TXT record key=value string
    "path=".

    The Interface Description "if" attribute is exported to the TXT
    record key=value string "if=".




 Shelby & Bormann         Expires April 28, 2015                [Page 27]

 Internet-Draft           CoRE Resource Directory            October 2014


    The DNS TXT record can be further populated by importing any other
    resource description attributes as they share the same key=value
    format specified in Section 6 of [RFC6763].

 9.6.  Importing resource links into DNS-SD

    Assuming the ability to query a Resource Directory or multicast a GET
    (?exp) over the local link, CoAP resource discovery may be used to
    populate the DNS-SD database in an automated fashion.  CoAP resource
    descriptions (links) can be exported to DNS-SD for exposure to
    service discovery by using the Resource Instance attribute as the
    basis for a unique service name, composed with the Resource Type as
    the , and registered in the correct .  The agent
    responsible for exporting records to the DNS zone file SHOULD be
    authenticated to the DNS server.  The following example shows an
    agent discovering a resource to be exported:


        Agent                                                          RD
          |                                                             |
          | --- GET /rd-lookup/res?exp ------------------------------>  |
          |                                                             |
          |                                                             |
          | <-- 2.05 Content ";exp; ------------  |
          |                   rt="dali.light";ins="FrontSpot"           |
          |                   d="example.com"                           |
          |                                                             |




       Req: GET /rd-lookup/res?exp

       Res: 2.05 Content
       ;
         exp;ct=41;rt="dali.light";ins="FrontSpot";
                   d="example.com"


    The agent subsequenly registers the following DNS-SD RRs:











 Shelby & Bormann         Expires April 28, 2015                [Page 28]

 Internet-Draft           CoRE Resource Directory            October 2014


    node1.example.com.                IN AAAA
                              FDFD::1234
    _dali._udp.example.com            IN PTR
                              FrontSpot._dali._udp.example.com
    light._sub._dali._udp.example.com IN PTR
                              FrontSpot._dali._udp.example.com
    FrontSpot._dali._udp.example.com  IN SRV  0 0 5678
                              node1.example.com.
    FrontSpot._dali._udp.example.com  IN TXT
                              txtver=1;path=/light/1

    In the above figure the Service Name is chosen as
    FrontSpot._dali._udp.example.com without the light._sub service
    prefix.  An alternative Service Name would be:
    FrontSpot.light._sub._dali._udp.example.com.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-resource-
  zach@sensinode.com     |  directory@tools.ietf.org
     Type:  task         |      Status:  closed
 Priority:  major        |   Milestone:
Component:  resource-    |     Version:
  directory              |  Resolution:  fixed
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Sat Oct 25 12:54:55 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563A31A6F03 for ; Sat, 25 Oct 2014 12:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRlUgaROvtcQ for ; Sat, 25 Oct 2014 12:54:53 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032431A6EDE for ; Sat, 25 Oct 2014 12:54:53 -0700 (PDT)
Received: from localhost ([::1]:58862 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xi7QF-00087Q-5u; Sat, 25 Oct 2014 12:54:47 -0700
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-resource-directory@tools.ietf.org, zach@sensinode.com
X-Trac-Project: core
Date: Sat, 25 Oct 2014 19:54:46 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/371#comment:1
Message-ID: <072.b23b566ca62ed4dc7a63a641576f6690@trac.tools.ietf.org>
References: <057.e17d33b0f25c13497bad6895c0b8378b@trac.tools.ietf.org>
X-Trac-Ticket-ID: 371
In-Reply-To: <057.e17d33b0f25c13497bad6895c0b8378b@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, srdjan.krco@ericsson.com, zach.shelby@arm.com
Archived-At: http://mailarchive.ietf.org/arch/msg/core/tMvVba56XJuMohOcxAt9ZE4QP7Y
Cc: core@ietf.org
Subject: Re: [core] #371 (resource-directory): DDoS security consideration
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: trac+core@zinfandel.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: Sat, 25 Oct 2014 19:54:54 -0000

#371: DDoS security consideration

Changes (by zach@sensinode.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done in -02.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-resource-
  zach@sensinode.com     |  directory@tools.ietf.org
     Type:  task         |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  resource-    |     Version:
  directory              |  Resolution:  fixed
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Mon Oct 27 08:19:59 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD811A8994 for ; Mon, 27 Oct 2014 08:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7941vfI-B-Zr; Mon, 27 Oct 2014 08:01:16 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 633FD1ACCE3; Mon, 27 Oct 2014 08:01:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org, barryleiba@computer.org, rlb@ipv.sx
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141027150109.29682.8950.idtracker@ietfa.amsl.com>
Date: Mon, 27 Oct 2014 08:01:09 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/core/pQqUhpBc6oEV0MKhN7VHYBpOwdc
Subject: [core] New Version Notification - draft-ietf-core-observe-15.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 15:01:18 -0000

A new version (-15) has been submitted for draft-ietf-core-observe:
http://www.ietf.org/internet-drafts/draft-ietf-core-observe-15.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-observe/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


From nobody Mon Oct 27 08:20:01 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479D31ACD1D; Mon, 27 Oct 2014 08:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt2CF9giX9WQ; Mon, 27 Oct 2014 08:01:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 405111ACCDC; Mon, 27 Oct 2014 08:01:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141027150109.29682.57053.idtracker@ietfa.amsl.com>
Date: Mon, 27 Oct 2014 08:01:09 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/core/OI3MJ0ppR-aeb5mH3oJSU4Zm8_M
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-observe-15.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 15:01:24 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.

        Title           : Observing Resources in CoAP
        Author          : Klaus Hartke
	Filename        : draft-ietf-core-observe-15.txt
	Pages           : 34
	Date            : 2014-10-27

Abstract:
   The Constrained Application Protocol (CoAP) is a RESTful application
   protocol for constrained nodes and networks.  The state of a resource
   on a CoAP server can change over time.  This document specifies a
   simple protocol extension for CoAP that enables CoAP clients to
   "observe" resources, i.e., to retrieve a representation of a resource
   and keep this representation updated by the server over a period of
   time.  The protocol follows a best-effort approach for sending new
   representations to clients and provides eventual consistency between
   the state observed by each client and the actual resource state at
   the server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-observe/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-observe-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Oct 27 08:46:20 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DDC1ACE37 for ; Mon, 27 Oct 2014 08:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1GPlbKXjL0U for ; Mon, 27 Oct 2014 08:46:05 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506A61A9073 for ; Mon, 27 Oct 2014 08:46:03 -0700 (PDT)
Received: from localhost ([::1]:42734 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XimUd-0000NS-5d; Mon, 27 Oct 2014 08:46:03 -0700
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: cabo@tzi.org
X-Trac-Project: core
Date: Mon, 27 Oct 2014 15:46:03 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: /ticket/368#comment:1
Message-ID: <066.fdc0491d500c4138889ff852cf6d6998@trac.tools.ietf.org>
References: <051.982738dd70bf31f802961c9bbcb44442@trac.tools.ietf.org>
X-Trac-Ticket-ID: 368
In-Reply-To: <051.982738dd70bf31f802961c9bbcb44442@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/core/bYXROMVcHcbQgeqsF7AhsCM0WBk
Cc: core@ietf.org
Subject: Re: [core] #368 (block): Clarify that there is nothing special about tokens in -block
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: trac+core@zinfandel.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, 27 Oct 2014 15:46:10 -0000

#368: Clarify that there is nothing special about tokens in -block

Changes (by cabo@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Fixed in [1723]:

 Fix #368, fix #367, ship as block-16

-- 
-----------------------------+---------------------------
 Reporter:  cabo@tzi.org     |       Owner:  cabo@tzi.org
     Type:  editorial        |      Status:  closed
 Priority:  minor            |   Milestone:  post-WGLC-2
Component:  block            |     Version:
 Severity:  In WG Last Call  |  Resolution:  fixed
 Keywords:                   |
-----------------------------+---------------------------

Ticket URL: 
core 


From nobody Mon Oct 27 08:46:21 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00711ACE0B for ; Mon, 27 Oct 2014 08:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3535TG2k-fLC for ; Mon, 27 Oct 2014 08:46:10 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079A11A9076 for ; Mon, 27 Oct 2014 08:46:08 -0700 (PDT)
Received: from localhost ([::1]:42732 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XimUd-0000NO-3v; Mon, 27 Oct 2014 08:46:03 -0700
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-block@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Mon, 27 Oct 2014 15:46:03 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: /ticket/367#comment:1
Message-ID: <074.e14c1b6c6c4f58877774629fbb500d06@trac.tools.ietf.org>
References: <059.c382556ea7a7abaeb2001d71014e58e2@trac.tools.ietf.org>
X-Trac-Ticket-ID: 367
In-Reply-To: <059.c382556ea7a7abaeb2001d71014e58e2@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, zach.shelby@arm.com
Archived-At: http://mailarchive.ietf.org/arch/msg/core/852ehPMBWIL2r34xv4UtaRcYUig
Cc: core@ietf.org
Subject: Re: [core] #367 (block): Reaction for Content-Format mismatch
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: trac+core@zinfandel.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, 27 Oct 2014 15:46:16 -0000

#367: Reaction for Content-Format mismatch

Changes (by cabo@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Fixed in [1723]:

 Fix #368, fix #367, ship as block-16

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  kovatsch@inf.ethz.ch   |  block@tools.ietf.org
     Type:  protocol     |      Status:  closed
  defect                 |   Milestone:
 Priority:  minor        |     Version:  block-14
Component:  block        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Mon Oct 27 08:46:24 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0A01ACE3A; Mon, 27 Oct 2014 08:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdgUXeQB496B; Mon, 27 Oct 2014 08:46:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0841ACE07; Mon, 27 Oct 2014 08:46:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141027154609.4598.86468.idtracker@ietfa.amsl.com>
Date: Mon, 27 Oct 2014 08:46:09 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/core/tH_UDwlvTnxFweVdQi3bAgmmG-0
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-block-16.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 15:46:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.

        Title           : Blockwise transfers in CoAP
        Authors         : Carsten Bormann
                          Zach Shelby
	Filename        : draft-ietf-core-block-16.txt
	Pages           : 33
	Date            : 2014-10-27

Abstract:
   CoAP is a RESTful transfer protocol for constrained nodes and
   networks.  Basic CoAP messages work well for the small payloads we
   expect from temperature sensors, light switches, and similar
   building-automation devices.  Occasionally, however, applications
   will need to transfer larger payloads -- for instance, for firmware
   updates.  With HTTP, TCP does the grunt work of slicing large
   payloads up into multiple packets and ensuring that they all arrive
   and are handled in the right order.

   CoAP is based on datagram transports such as UDP or DTLS, which
   limits the maximum size of resource representations that can be
   transferred without too much fragmentation.  Although UDP supports
   larger payloads through IP fragmentation, it is limited to 64 KiB
   and, more importantly, doesn't really work well for constrained
   applications and networks.

   Instead of relying on IP fragmentation, this specification extends
   basic CoAP with a pair of "Block" options, for transferring multiple
   blocks of information from a resource representation in multiple
   request-response pairs.  In many important cases, the Block options
   enable a server to be truly stateless: the server can handle each
   block transfer separately, with no need for a connection setup or
   other server-side memory of previous block transfers.

   In summary, the Block options provide a minimal way to transfer
   larger representations in a block-wise fashion.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-block/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-block-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Oct 28 00:32:26 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CA71A0545 for ; Tue, 28 Oct 2014 00:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M683QVSm2nVl for ; Tue, 28 Oct 2014 00:32:22 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88A41A0398 for ; Tue, 28 Oct 2014 00:32:21 -0700 (PDT)
Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Oct 2014 08:32:18 +0100
Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 08:32:19 +0100
From: "Kovatsch  Matthias" 
To: Oliver Kleine , "core@ietf.org" 
Thread-Topic: [core] CoAP Endpoint Identification
Thread-Index: AQHP0lZTZZ/1TyTTWU2wpWs2mQiGXJwGhy8AgAAYHoCAAVA/gIAAGK0AgAGbCgCABoBAgIAAwzoAgABpmACAABxygIAAJbcqgARc14CAAdOlgIAhY1IAgAGd1DD///guAIAKmxfA
Date: Tue, 28 Oct 2014 07:32:18 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B5296E57AC@MBX110.d.ethz.ch>
References: <54194E6E.7080902@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819D479@SZXEMA501-MBS.china.huawei.com> <541AC053.9000106@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819DB58@SZXEMA501-MBS.china.huawei.com> <541BEF16.2040200@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819E136@SZXEMA501-MBS.china.huawei.com> <5422BBF7.6070402@itm.uni-luebeck.de> <34966E97BE8AD64EAE9D3D6E4DEE36F25819F6D5@SZXEMA501-MBS.china.huawei.com>  <34966E97BE8AD64EAE9D3D6E4DEE36F25819F986@SZXEMA501-MBS.china.huawei.com> <87tx3wp08d.fsf@tzi.org>  <542920F9.8070006@itm.uni-luebeck.de> <544522FC.3060809@intec.ugent.be> <55877B3AFB359744BA0F2140E36F52B5272BD487@MBX110.d.ethz.ch> <54467792.4010408@itm.uni-luebeck.de>
In-Reply-To: <54467792.4010408@itm.uni-luebeck.de>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [46.126.158.240]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/core/CCAoilF9OlXh4nYHUkjInEGN2Ag
Subject: Re: [core] CoAP Endpoint Identification
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Oct 2014 07:32:25 -0000

PiBGb3Igc3VyZSBbZHJhZnQta29zdGVyLWNvcmUtY29hcG1xXSBhdm9pZHMgbG9zcyBvZiBpbmZv
cm1hdGlvbiBidXQgaXQgZG9lcyBub3QgYXZvaWQgbG9zcyBvZiBhY3R1YWxpdHkuDQo+IFRoZXJl
IGFyZSBjZXJ0YWluIHVzZSBjYXNlcyB3aGVyZSB5b3Ugd2FudCB0aGUgaW5mb3JtYXRpb24gaW4g
KG9yIGNsb3NlIHRvKSByZWFsLQ0KPiB0aW1lIGFuZCBub3QgYXQgc29tZSB0aW1lIGluIHRoZSBm
dXR1cmUuDQoNCllvdSBzaW1wbHkgbmVlZCB0byB0cmlnZ2VyIHRoZSBxdWV1ZWQgbWVzc2FnZXMg
YXMgc29vbiBhcyBwb3NzaWJsZS4gVGhlIGdlbmVyYWwgcHJvYmxlbSByZW1haW5zIHRoZSBzYW1l
OiBob3cgc2hvdWxkIGEgZGV2aWNlIHByb3BhZ2F0ZSBhbiBhZGRyZXNzIGNoYW5nZSAod2l0aG91
dCB1c2luZyBhbiBSRCBpbiB0aGlzIHVzZSBjYXNlKT8gRnJvbSB0aGVyZSBhbGwgZXhpc3Rpbmcg
bWVjaGFuaXNtcyB3b3JrLiBNeSBtYWluIGludGVudCBpcyB0byBtYWtlIHRoZSBiZXN0IChyZS0p
dXNlIG9mIHRoZSBlY29zeXN0ZW0gYW5kIGF2b2lkIG1hbnkgb3ZlcmxhcHBpbmcgcGF0Y2h3b3Jr
IHNvbHV0aW9ucy4gSnVzdCBjb250aW51aW5nIHdpdGggbm90aWZpY2F0aW9ucyBhZnRlciBhbiBh
ZGRyZXNzIGNoYW5nZSBtaWdodCBiZSBhIGNhbmRpZGF0ZSwgaG93ZXZlciwgdGhlcmUgaXMgdGhp
cyBjb25mbGljdCB3aXRoIERUTFMgKHNlZSBiZWxvdykuIEFub3RoZXIgcXVlc3Rpb24gaXM6IHdv
dWxkIHlvdSBhY3R1YWxseSBkZXNpZ24gYSBjcml0aWNhbCBhcHBsaWNhdGlvbiBsaWtlIGZpcmUg
YWxhcm1zIHdpdGhvdXQgYW4gUkQgYW5kIHByb3BlciBkZXZpY2UgbWFuYWdlbWVudD8NCg0KPiA+
IENvbW1lbnRzIG9uIE9saXZlcuKAmXMgcHJvcG9zYWw6IEFzIEhhbm5lcyBtZW50aW9uZWQsIGFu
IElQIGFkZHJlc3MNCj4gPiBjaGFuZ2Ugd2lsbCByZXF1aXJlIGEgbmV3IERUTFMgaGFuZHNoYWtl
IGFuZCBtZXNzYWdlIG1hdGNoaW5nIGlzIG9ubHkNCj4gPiBhbGxvd2VkIHdpdGhpbiB0aGUgc2Ft
ZSBzZWN1cml0eSBjb250ZXh0IChJSVJDKS4gSGVuY2UsIHRoZSBjbGllbnQgaXMNCj4gPiByZXF1
aXJlZCB0byByZS1yZWdpc3RlciBhbnl3YXkuDQo+IA0KPiBUaGFuayB5b3UhIEkgZGlkbid0IGtu
b3cgdGhhdC4gSXMgdGhhdCBwcm9jZWR1cmUgYWxyZWFkeSBzdGFuZGFyZGl6ZWQgb3Igc3RpbGwg
aW4NCj4gZHJhZnQgc3RhdHVzPyBDb3VsZCB5b3UgcHJvdmlkZSBtZSB3aXRoIGEgbGluayB0byB0
aGUgcmVsZXZhbnQgZG9jdW1lbnQocyk/DQoNClNlZSBuZXcgLW9ic2VydmUtMTU6DQoJUmVzb3Vy
Y2VzIGNhbiBiZSBvYnNlcnZlZCBvdmVyIERUTFMtc2VjdXJlZCBDb0FQIHVzaW5nIGFueSBvZiB0
aGUJDQoJc2VjdXJpdHkgbW9kZXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gOSBvZiBSRkMgNzI1Mi4g
VGhlIHVzZSBvZiBEVExTCQ0KCWlzIGluZGljYXRlZCBieSB0aGUgImNvYXBzIiBVUkkgc2NoZW1l
LiBBbGwgbm90aWZpY2F0aW9ucyByZXN1bHRpbmcJDQoJZnJvbSBhIEdFVCByZXF1ZXN0IHdpdGgg
YW4gT2JzZXJ2ZSBPcHRpb24gTVVTVCBiZSByZXR1cm5lZCB3aXRoaW4gdGhlCQ0KCXNhbWUgZXBv
Y2ggb2YgdGhlIHNhbWUgY29ubmVjdGlvbiBhcyB0aGUgcmVxdWVzdC4NCg0KPiBIb3dldmVyLCB0
aGUgY2xpZW50DQo+IGtlZXBzIHRoZSBvYnNlcnZhdGlvbiBydW5uaW5nIGZvciB1cCB0byAyNCBo
b3VycyAoQ09OIG5vdGlmaWNhdGlvbiB0aW1lb3V0KS4NCg0KTm8sIHRoZSAyNCBob3VycyBjb3Jy
ZXNwb25kIHRvIHNlcnZlcnMuIEl0IGlzIHRoZSBtYXhpbXVtIGludGVydmFsIGEgc2VydmVyIE1V
U1QgY2hlY2sgdGhlIHByZXNlbmNlL2ludGVyZXN0IG9mIG9ic2VydmVycyB3aXRoIGEgQ09OIG5v
dGlmaWNhdGlvbi4gQ2xpZW50cyBjYW4gZm9sZCB0aGVpciBpbnRlcmVzdCBhdCBhbnkgdGltZSwg
ZXZlbiB3aXRob3V0IHRlbGxpbmcgdGhlIHNlcnZlci4NCg0KPiBUaGUgY2xpZW50IGRvZXMgbm90
IGRldGVjdCBhIG5lZWQgdG8gcmVzdGFydCB0aGUgb2JzZXJ2YXRpb24gd2l0aCB0aGUgbmV3IHNl
cnZlcg0KPiBJUC4NCg0KVGhlIG1haW4gcHJvYmxlbSBpcyBob3cgdGhlIGNsaWVudCBjYW4gbGVh
cm4gYWJvdXQgdGhlIG5ldyBhZGRyZXNzIChzZWUgZ2VuZXJhbCBwcm9ibGVtIGFib3ZlKS4NCg0K
PiBIb3dldmVyLCBpbiBhIHByZXZpb3VzIGRyYWZ0IG9mIG9ic2VydmUgaXQgd2FzIG1hbmRhdG9y
eSB0byBzZW5kIG5ldyB1cGRhdGUNCj4gbm90aWZpY2F0aW9ucyB3aGVuZXZlciB0aGUgbGFzdCBt
YXgtYWdlIGVuZHMgKGluZGVwZW5kZW50IGZyb20gYSBzdGF0dXMNCj4gY2hhbmdlKS4gVGhpcyB3
YXMgY2hhbmdlZCBmb3Igc29tZSAocHJvYmFibHkgZ29vZCkgcmVhc29uLg0KDQpUaGUgcmVhc29u
IGlzIHRoYXQgYSBjbGllbnQgY2FuIG5ldmVyIGJlIHN1cmUgd2h5IGl0IGRpZCBub3QgcmVjZWl2
ZSBhIG5vdGlmaWNhdGlvbiAodGhlcmUgd2FzIG5vIGNoYW5nZSwgdGhlIG1lc3NhZ2Ugd2FzIGxv
c3QsIHRoZSBzZXJ2ZXIgaXMgZG93bikuIEluIHNvbWUgc2Vuc2UsIGV2ZXJ5IHNvbHV0aW9uIGZv
ciB0aGlzIHVsdGltYXRlbHkgcmVzdWx0cyBpbiBmcmVxdWVudCBwb2xsaW5nIG9mIHRoZSBzZXJ2
ZXIuIFdpdGggdGhlIGN1cnJlbnQgc29sdXRpb24sIHRoZSBhcHBsaWNhdGlvbiBjYW4gZGVjaWRl
IGhvdyBjcml0aWNhbCB0aGUgbm90aWZpY2F0aW9ucyBhcmUuIElmIGl0IGlzIGNyaXRpY2FsLCB0
aGUgY2xpZW50IGNhbiByZS1yZWdpc3RlciBkaXJlY3RseSBhZnRlciBNYXgtQWdlIGVuZHMgKHdo
aWNoIGNhbiBiZSBzZXQgdmVyeSBsb3cgYnkgdGhlIHNlcnZlcikuIE90aGVyd2lzZSwgdGhlIGNs
aWVudCBvbmx5IGFjdHMgd2hlbiB0aGUgYXBwbGljYXRpb24gd2FudHMgdG8gYWNjZXNzIHRoZSBj
dXJyZW50IHJlcHJlc2VudGF0aW9uOiBlaXRoZXIgaXQgc3RpbGwgaGFzIGEgZnJlc2ggb25lIG9y
IHJlLXJlZ2lzdGVycyB3aGVuIGl0IGlzIHN0YWxlIChNYXgtQWdlIGVuZGVkKS4NCg0KQ2lhbw0K
TWF0dGhpYXMNCg0K


From nobody Tue Oct 28 05:24:05 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10A61A6F3B for ; Tue, 28 Oct 2014 05:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.185
X-Spam-Level: 
X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CKf5YpVjvSf for ; Tue, 28 Oct 2014 05:23:28 -0700 (PDT)
Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2102C1A6F3D for ; Tue, 28 Oct 2014 05:19:19 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9SCJHMl028142 for ; Tue, 28 Oct 2014 13:19:18 +0100 (CET) (envelope-from stokcons@xs4all.nl)
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 28 Oct 2014 13:19:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 28 Oct 2014 13:19:16 +0100
From: peter van der Stok 
To: Core 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <019908c4d3a9073f6eb7c857921452db@xs4all.nl>
X-Sender: stokcons@xs4all.nl (1Xo9EUCj0UXSHBrzdO0nYSBx75q26QM2)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Archived-At: http://mailarchive.ietf.org/arch/msg/core/p9Op3ml7v663zqVyML1yQz6fauQ
Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 12:23:29 -0000

Dear CoRE WG,

We have submitted a new CoAP Management Interface (CoMI) draft to the 
WG.
Contrary to the former versions, this draft version focusses on YANG 
modules.
Further the draft minimizes the payload by using CBOR and hashing name 
strings.

We are looking forward to hear your opinion on this new approach.
We should also like to hear if you think this work should be done in the 
context of the CoRE wg.

Peter

-------- Oorspronkelijke bericht --------
Onderwerp: New Version Notification for 
draft-vanderstok-core-comi-05.txt
Datum: 2014-10-28 01:25
Afzender: internet-drafts@ietf.org
Ontvanger: Anuj Sehgal , "Anuj Sehgal" 
, "Juergen Schoenwaelder" 
, Juergen Schoenwaelder 
, "Peter Van der Stok" 
, Peter van der Stok 
, Bert Greevenbosch 
, "Bert Greevenbosch" 
, Andy Bierman , "Andy 
Bierman" 

A new version of I-D, draft-vanderstok-core-comi-05.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Name:		draft-vanderstok-core-comi
Revision:	05
Title:		CoAP Management Interface
Document date:	2014-10-27
Group:		Individual Submission
Pages:		37
URL:            
http://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-05.txt
Status:         
https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/
Htmlized:       http://tools.ietf.org/html/draft-vanderstok-core-comi-05
Diff:           
http://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-05

Abstract:
    This document describes a network management interface for
    constrained devices, called CoMI.  CoMI is an adaptation of the
    RESTCONF protocol for use in constrained devices and networks.  It is
    designed to reduce the message sizes, server code size, and
    application development complexity.  The Constrained Application
    Protocol (CoAP) is used to access management data resources specified
    in YANG, or SMIv2 converted to YANG.  The payload of the CoMI message
    is encoded in Concise Binary Object Representation (CBOR).




Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


From nobody Tue Oct 28 05:40:44 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF291A874D for ; Tue, 28 Oct 2014 05:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfT6kIWqF9aU for ; Tue, 28 Oct 2014 05:40:16 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9E51A6F11 for ; Tue, 28 Oct 2014 05:34:43 -0700 (PDT)
Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Oct 2014 13:34:40 +0100
Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0195.001;  Tue, 28 Oct 2014 13:34:41 +0100
From: "Kovatsch  Matthias" 
To: Zach Shelby , "core@ietf.org" 
Thread-Topic: [core] Conflict endpoint idenfier for resource directory draft
Thread-Index: Ac/sRzUGJ73qkLxbScuymQVXebZh0///4dYAgAAAwwCAACq7AP/+Ni4AgAOUAQD/9RB18A==
Date: Tue, 28 Oct 2014 12:34:40 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B5296E9B50@MBX110.d.ethz.ch>
References: <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C38@SZXEMA501-MBS.china.huawei.com> <6253A048-6A69-49CA-B0CC-438D1789856F@tzi.org> <34966E97BE8AD64EAE9D3D6E4DEE36F2581A6C94@SZXEMA501-MBS.china.huawei.com> <5444FB5E.60503@itm.uni-luebeck.de> <55877B3AFB359744BA0F2140E36F52B52729395B@MBX110.d.ethz.ch> <1367F1AB-B8C1-41A3-921F-926252375F47@arm.com>
In-Reply-To: <1367F1AB-B8C1-41A3-921F-926252375F47@arm.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [129.132.130.253]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/core/vJZxxWLHjopJBHb03p56_jUA6oA
Subject: Re: [core] Conflict endpoint idenfier for resource directory draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Oct 2014 12:40:18 -0000

> Yes, 4.09 should be registered in general as per OMA Lightweight M2M (the
> whole spec really needs an IANA review, as there are plenty of things sti=
ll to
> be registered).

At the moment, the Registration operation is the only one using the 4.09 Co=
nflict. Question is, if we really need it, since a 4.03 Forbidden would nic=
ely express that the server refuses the registration due to the missing cre=
dentials. On the other hand, a 4.09 Conflict would nicely fit with the Crea=
te operation when the Instance ID already exists. Yet the spec currently us=
es a generic 4.00 Bad Request for this...

Ciao
Matthias


From nobody Tue Oct 28 06:10:09 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD4C1A6F41 for ; Tue, 28 Oct 2014 06:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSz560_jub-U for ; Tue, 28 Oct 2014 06:09:31 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4651A8711 for ; Tue, 28 Oct 2014 06:09:26 -0700 (PDT)
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 mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9SD9Nci003300; Tue, 28 Oct 2014 14:09:23 +0100 (CET)
Received: from [192.168.217.113] (p54892441.dip0.t-ipconnect.de [84.137.36.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BB41B913; Tue, 28 Oct 2014 14:09:22 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Carsten Bormann 
In-Reply-To: <019908c4d3a9073f6eb7c857921452db@xs4all.nl>
Date: Tue, 28 Oct 2014 14:09:21 +0100
X-Mao-Original-Outgoing-Id: 436194561.43327-2414929bd9f7e09823a7b2b8126b2c49
Content-Transfer-Encoding: quoted-printable
Message-Id: <4DB58CA4-A5EC-48D4-A580-8057633C6239@tzi.org>
References: <019908c4d3a9073f6eb7c857921452db@xs4all.nl>
To: peter van der Stok 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/core/qULsWMQByJnMeYSDHh_zZfioqxU
Cc: Core 
Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Oct 2014 13:09:33 -0000

Nice!

Some minor comments on the CBOR mappings of the data types:

I don=E2=80=99t know how much decimal64 is being used in YANG modules =
today, but CBOR actually has Tag 4 mirroring that: See section 2.4.3 of =
RFC 7049.  Of course, you can factor out the fraction-digits and get it =
from the schema, in that case just sending the mantissa makes sense.

Re smiv2:oid you maybe want to have a look at =
draft-bormann-cbor-tags-oid =E2=80=94 that may be a closer fit.

                        oOo

More importantly, I=E2=80=99m trying to wrap my mind around the hashing =
concept.  Interesting.  Is that maybe something that should be extracted =
and made available for a more general use?  (Maybe not now.)

Is the shape of the identifier space stable enough that a client can =
read /mg/yang-hash once and then be done with it?  Or do you need to =
observe that resource?

(Nit: I would probably use more than 4 bits per byte in the URIs.)

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


From nobody Tue Oct 28 12:51:47 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4807F1ACD72 for ; Tue, 28 Oct 2014 12:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKyUfwr4C4Kl for ; Tue, 28 Oct 2014 12:51:40 -0700 (PDT)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF031ACDA5 for ; Tue, 28 Oct 2014 12:50:46 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id o8so1181707qcw.24 for ; Tue, 28 Oct 2014 12:50:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6anzzJB87SehSBvySAkIoA00poVILssfPjGafHeFELA=; b=hxlRpWQyUAVKG7K5MJ7j3pQcg7uGX5JhVvF5hzIaPxE3IRcRuCf6ZGa+gffmLgCj4J J+2sb7sJgK66luBKtqXGmqD1SNOGe7g/N2kY6bxzds2tDgsIOSWwcPoAmiqwfQ3V+wEp IGn3vvret/vxjcbxFsA3O2Ajhzr5IjdUx56iOx49l0Q3N2KpBt0VqLsXrabYj7TH8M0d /MItUU22zBe+dx+RpzznhDLPs5S4h9arwtoCwafdbTGx1Ozle97YVNUjLpDvbTn0vT/X qG5NFGs7eAS9KGk0xxt+PzkwgAjZgvwxG0hGUAirknoffeimszdHGcP8VBSF4BGeLTGk jD2A==
X-Gm-Message-State: ALoCoQklXrWTtm/EjupJ4WnJa3k4NA7R5+LiLBukwYf1MknKyysx3S43RkLdyKsCvSN2nWWlj2UP
MIME-Version: 1.0
X-Received: by 10.140.109.102 with SMTP id k93mr7980623qgf.83.1414525846185; Tue, 28 Oct 2014 12:50:46 -0700 (PDT)
Received: by 10.140.37.52 with HTTP; Tue, 28 Oct 2014 12:50:46 -0700 (PDT)
In-Reply-To: <4DB58CA4-A5EC-48D4-A580-8057633C6239@tzi.org>
References: <019908c4d3a9073f6eb7c857921452db@xs4all.nl> <4DB58CA4-A5EC-48D4-A580-8057633C6239@tzi.org>
Date: Tue, 28 Oct 2014 12:50:46 -0700
Message-ID: 
From: Andy Bierman 
To: Carsten Bormann 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/core/vcvpcgLpbSSFhNcgqcXfX-4Wdzo
Cc: Core 
Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Oct 2014 19:51:44 -0000

On Tue, Oct 28, 2014 at 6:09 AM, Carsten Bormann  wrote:
> Nice!
>
> Some minor comments on the CBOR mappings of the data types:
>
> I don=E2=80=99t know how much decimal64 is being used in YANG modules tod=
ay, but CBOR actually has Tag 4 mirroring that: See section 2.4.3 of RFC 70=
49.  Of course, you can factor out the fraction-digits and get it from the =
schema, in that case just sending the mantissa makes sense.
>
> Re smiv2:oid you maybe want to have a look at draft-bormann-cbor-tags-oid=
 =E2=80=94 that may be a closer fit.
>
>                         oOo
>
> More importantly, I=E2=80=99m trying to wrap my mind around the hashing c=
oncept.  Interesting.  Is that maybe something that should be extracted and=
 made available for a more general use?  (Maybe not now.)
>
> Is the shape of the identifier space stable enough that a client can read=
 /mg/yang-hash once and then be done with it?  Or do you need to observe th=
at resource?
>

It is expected that the hashes and the contents of this table will be
known at boot-time
(maybe even compile-time) for constrained devices.  However, a client that =
polls
a server periodically cannot really tell the difference between a new modul=
e
loaded at runtime or the server rebooting with a new image that has a
new module.
Both events are expected to be very rare, but possible.

> (Nit: I would probably use more than 4 bits per byte in the URIs.)
>

OK

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

Andy

> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From nobody Wed Oct 29 08:54:18 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FADC1A1A0B; Wed, 29 Oct 2014 08:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbYMtqya9-qI; Wed, 29 Oct 2014 08:54:13 -0700 (PDT)
Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id A63821A010E; Wed, 29 Oct 2014 08:54:12 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmwFABMLUVSsEhcE/2dsb2JhbABcg2JYvjCPYwEJh02BMwEBAQEBfYUhAQIGMk0XAQkBCBuIM7FWAQGVcQEBCAEBAQEehVliikqCQQ9EJIEeBYtmhy2DQqFLZIJLAQEB
X-IPAS-Result: AmwFABMLUVSsEhcE/2dsb2JhbABcg2JYvjCPYwEJh02BMwEBAQEBfYUhAQIGMk0XAQkBCBuIM7FWAQGVcQEBCAEBAQEehVliikqCQQ9EJIEeBYtmhy2DQqFLZIJLAQEB
X-IronPort-AV: E=Sophos;i="5.04,810,1406572200"; d="scan'208";a="604903405"
Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id B19DFDAC12; Wed, 29 Oct 2014 21:24:10 +0530 (IST)
Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 940DBDAC02; Wed, 29 Oct 2014 21:24:10 +0530 (IST)
To: Core , "core" 
MIME-Version: 1.0
X-KeepSent: 6E0241C1:5DCBA81C-65257D80:00565FCA; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: 
From: Abhijan Bhattacharyya 
Date: Wed, 29 Oct 2014 21:24:08 +0530
X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 10/29/2014 21:24:10, Serialize complete at 10/29/2014 21:24:10, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 10/29/2014 21:24:10
Content-Type: multipart/alternative; boundary="=_alternative 00575AB565257D80_="
Archived-At: http://mailarchive.ietf.org/arch/msg/core/L8NTzet1qz0vsQNM7f9kGO7GorI
Subject: [core] Real Time Video over CoAP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 15:54:16 -0000

This is a multipart message in MIME format.
--=_alternative 00575AB565257D80_=
Content-Type: text/plain; charset="US-ASCII"

Hi All,
Just wonder if some effort is going on regarding transfer of real-time 
video over CoAP.
I could find an old draft on streaming over CoAP: 
https://tools.ietf.org/html/draft-loreto-core-coap-streaming-00

But, has there been any further progress on this recently, or, any effort 
being put on this problem by anyone?

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you



--=_alternative 00575AB565257D80_=
Content-Type: text/html; charset="US-ASCII"

Hi All,

Just wonder if some effort is going
on regarding transfer of real-time video over CoAP.

I could find an old draft on streaming
over CoAP: https://tools.ietf.org/html/draft-loreto-core-coap-streaming-00



But, has there been any further progress
on this recently, or, any effort being put on this problem by anyone?



Regards

Abhijan Bhattacharyya

Associate Consultant

Scientist, Innovation Lab, Kolkata, India

Tata Consultancy Services

Mailto: abhijan.bhattacharyya@tcs.com

Website: http://www.tcs.com

____________________________________________

Experience certainty.        IT Services

                
       Business Solutions

                
       Consulting

____________________________________________
=====-----=====-----=====

Notice: The information contained in this e-mail

message and/or attachments to it may contain 

confidential or privileged information. If you are 

not the intended recipient, any dissemination, use, 

review, distribution, printing or copying of the 

information contained in this e-mail message 

and/or attachments to it are strictly prohibited. If 

you have received this communication in error, 

please notify us by reply e-mail or telephone and 

immediately and permanently delete the message 

and any attachments. Thank you




--=_alternative 00575AB565257D80_=--


From nobody Wed Oct 29 09:42:10 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5275C1A0A85 for ; Wed, 29 Oct 2014 09:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHcPKL-T6BBf for ; Wed, 29 Oct 2014 09:42:01 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C031A0187 for ; Wed, 29 Oct 2014 09:42:00 -0700 (PDT)
X-AuditID: c1b4fb25-f791c6d00000617b-e7-545118d6b334
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.87.24955.6D811545; Wed, 29 Oct 2014 17:41:58 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.73]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 17:41:57 +0100
From: Salvatore Loreto 
To: Abhijan Bhattacharyya 
Thread-Topic: [core] Real Time Video over CoAP?
Thread-Index: AQHP85CatEnU4A9n4E6r5WdnXFS/CpxHNp+A
Date: Wed, 29 Oct 2014 16:41:57 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_B08F708CEE1C4B71A112F3B2C0FB2EADericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvje41icAQg0n75SyezN7LZrHv7Xpm ByaPJUt+MnnMeD+VNYApissmJTUnsyy1SN8ugStj+rZeloIJOhUvmxcxNjB2qnUxcnJICJhI dLy8ygRhi0lcuLeerYuRi0NI4AijxLNDxxkhnMWMErN33GQEqWITMJN4/nALM4gtImApsfXn ZBYQm1lAQmLq5EZWEFtYQE9iw0aQqRxANfoSM55pQ5hGEpcPx4JUsAioSkz+tQWsk1fAXuL5 iclgnUIC/hIfJqxhA7E5BQIkvn18CRZnBLrt+6k1TBCbxCVuPZkPdbOAxJI955khbFGJl4// sULYShJrD2+HuixZYvmB+2wQuwQlTs58wjKBUXQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFr Zhj7zIHHUL3WEueW3GNHVrOAkWMVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmAUHtzyW3UH 4+U3jocYBTgYlXh4CyYEhAixJpYVV+YeYpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsa89X139AJ5P2s3fi/mkmoX9BHg0vT4vy76lMt13SyGqis+Zjqa4T+E5vHuq7dQ 10x86Tdf92rhlncrX90L7Ho9/dv3g3+Xiz5dbWeb7ho2de7tdyG516T51mkWrgltv3P43sQ3 qr9W/zm/QYLVqPLOesZjXt0zuU9FdLL/vFWw66jLkf/tk72VWIozEg21mIuKEwGqOcx+owIA AA==
Archived-At: http://mailarchive.ietf.org/arch/msg/core/k2kSfiufCdiTWND0mnSRpbk1r7k
Cc: Core 
Subject: Re: [core] Real Time Video over CoAP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 16:42:07 -0000

--_000_B08F708CEE1C4B71A112F3B2C0FB2EADericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Abjian

I haven't had almost any cycle to further progress the old proposal since m=
y initial proposal.

However if people are interested in helping and supporting I can resurrect =
the drag and update
with all the improvements done meanwhile in observe

br
Salvatore

On Oct 29, 2014, at 5:54 PM, Abhijan Bhattacharyya > wrote:

Hi All,
Just wonder if some effort is going on regarding transfer of real-time vide=
o over CoAP.
I could find an old draft on streaming over CoAP: https://tools.ietf.org/ht=
ml/draft-loreto-core-coap-streaming-00

But, has there been any further progress on this recently, or, any effort b=
eing put on this problem by anyone?

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


--_000_B08F708CEE1C4B71A112F3B2C0FB2EADericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <9751DB072FECE24DB731466A4807581B@ericsson.com>
Content-Transfer-Encoding: quoted-printable






Hi Abjian






I haven't had almost any cycle to further progress the old proposal si=
nce my initial proposal.







However if people are interested in helping and supporting I can resur=
rect the drag and update


with all the improvements done meanwhile in observe 







br


Salvatore







On Oct 29, 2014, at 5:54 PM, Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com> wro=
te:




Hi All, 

Just wonder if some effort is going on=
 regarding transfer of real-time video over CoAP.


I could find an old draft on streaming=
 over CoAP:
https://tools.i=
etf.org/html/draft-loreto-core-coap-streaming-00




But, has there been any further progre=
ss on this recently, or, any effort being put on this problem by anyone?


Regards

Abhijan Bhattacharyya

Associate Consultant

Scientist, Innovation Lab, Kolkata, India

Tata Consultancy Services

Mailto: abhijan.bhattachar=
yya@tcs.com

Website: http://www.tcs.com

____________________________________________

Experience certainty.        IT Services

                     =
;  Business Solutions

                     =
;  Consulting

____________________________________________

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D

Notice: The information contained in this e-mail

message and/or attachments to it may contain 

confidential or privileged information. If you are 

not the intended recipient, any dissemination, use, 

review, distribution, printing or copying of the 

information contained in this e-mail message 

and/or attachments to it are strictly prohibited. If 

you have received this communication in error, 

please notify us by reply e-mail or telephone and 

immediately and permanently delete the message 

and any attachments. Thank you






_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/mailman/listinfo/core












--_000_B08F708CEE1C4B71A112F3B2C0FB2EADericssoncom_--


From nobody Wed Oct 29 10:24:04 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B611A6FC7 for ; Wed, 29 Oct 2014 10:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzk9IQ5Vsn_V for ; Wed, 29 Oct 2014 10:23:58 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950AB1A6F6B for ; Wed, 29 Oct 2014 10:23:58 -0700 (PDT)
Received: by mail-pa0-f41.google.com with SMTP id rd3so3583736pab.14 for ; Wed, 29 Oct 2014 10:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=GWYpCZfPA+5cb3a2GnIDgq50+w7X4fhHK1ncjJV81uk=; b=kDiaXs+nVqPRbJ/wbFTYziy1iIfatXScG6pSYJKs7RKLpcbW4EcmWhbNJBuLZ1hduO 9cm7HiBz7pf487u9bUpA+72/6Bc4OM8BgUARa01GUuGKR3tmk8o6dYsLBnS6u7TZDHFt fDNWGgja69O3lJHZ8HtyI02sc6GWaP9iP5ck9AXoGHKSbvnsXK8vjFIBZeJhJjydIjjJ ixMzuTmMGtUUStfBDVP49jiBrQUz4+MMVhKKOKbjMVRsxwn0J8RdyHsQf/c9iblwRNWf z1K7X2SkYknXzPsdwTes/zbk2BLm3eR4lM2kwLW0yjV3w1UNhuZQKIlfk8Nu6NuVFNN0 b8Dg==
X-Received: by 10.68.108.36 with SMTP id hh4mr11822139pbb.108.1414603438278; Wed, 29 Oct 2014 10:23:58 -0700 (PDT)
Received: from Sids-MacBook-Pro.local (ip72-211-183-219.tc.ph.cox.net. [72.211.183.219]) by mx.google.com with ESMTPSA id fl15sm4845404pdb.92.2014.10.29.10.23.56 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 10:23:57 -0700 (PDT)
Message-ID: <545122AB.40401@gmail.com>
Date: Wed, 29 Oct 2014 10:23:55 -0700
From: Siddharth Heroor 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: core@ietf.org
References:  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060809060406020503070208"
Archived-At: http://mailarchive.ietf.org/arch/msg/core/TzW7RZHDUfap_kIInWjYVuLwiqY
Subject: Re: [core] Real Time Video over CoAP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 17:24:01 -0000

This is a multi-part message in MIME format.
--------------060809060406020503070208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Salvatore, Abhijan

I too interested in seeing more on this. There are several applications 
where streaming are an usecase. However, there are a few questions that 
I have

1. How similar to RTP would this extension be and what would be the 
differences?
2. The old draft does not cover resource capabilities and would that be 
considered?

Thanks and Regards,
Sid

On 29/10/14 9:41 am, Salvatore Loreto wrote:
> Hi Abjian
>
> I haven't had almost any cycle to further progress the old proposal 
> since my initial proposal.
>
> However if people are interested in helping and supporting I can 
> resurrect the drag and update
> with all the improvements done meanwhile in observe
>
> br
> Salvatore
>
> On Oct 29, 2014, at 5:54 PM, Abhijan Bhattacharyya 
> > 
> wrote:
>
>> Hi All,
>> Just wonder if some effort is going on regarding transfer of 
>> real-time video over CoAP.
>> I could find an old draft on streaming over CoAP: 
>> https://tools.ietf.org/html/draft-loreto-core-coap-streaming-00
>>
>> But, has there been any further progress on this recently, or, any 
>> effort being put on this problem by anyone?
>>
>> Regards
>> Abhijan Bhattacharyya
>> Associate Consultant
>> Scientist, Innovation Lab, Kolkata, India
>> Tata Consultancy Services
>> Mailto: abhijan.bhattacharyya@tcs.com 
>> 
>> Website: http://www.tcs.com 
>> ____________________________________________
>> Experience certainty.        IT Services
>>                        Business Solutions
>>                        Consulting
>> ____________________________________________
>>
>> =====-----=====-----=====
>> Notice: The information contained in this e-mail
>> message and/or attachments to it may contain
>> confidential or privileged information. If you are
>> not the intended recipient, any dissemination, use,
>> review, distribution, printing or copying of the
>> information contained in this e-mail message
>> and/or attachments to it are strictly prohibited. If
>> you have received this communication in error,
>> please notify us by reply e-mail or telephone and
>> immediately and permanently delete the message
>> and any attachments. Thank you
>>
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org 
>> https://www.ietf.org/mailman/listinfo/core
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


--------------060809060406020503070208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Salvatore, Abhijan

    

    I too interested in seeing more on this. There are several
    applications where streaming are an usecase. However, there are a
    few questions that I have

    

    1. How similar to RTP would this extension be and what would be the
    differences?

    2. The old draft does not cover resource capabilities and would that
    be considered?

    

    Thanks and Regards,

    Sid

    

    
On 29/10/14 9:41 am, Salvatore Loreto
      wrote:

    

    

      
      Hi Abjian
      


      

      
I haven't had almost any cycle to further progress the old
        proposal since my initial proposal.

      


      

      
However if people are interested in helping and supporting I
        can resurrect the drag and update

      
with all the improvements done meanwhile in observe 

      


      

      
br

      
Salvatore

      


        

          
On Oct 29, 2014, at 5:54 PM, Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
            wrote:

          

          
Hi
              All, 

            Just wonder if some effort
              is going on regarding transfer of real-time video over
              CoAP.
            

            I could find an old draft
              on streaming over CoAP:
            https://tools.ietf.org/html/draft-loreto-core-coap-streaming-00
            

            

            But, has there been any
              further progress on this recently, or, any effort being
              put on this problem by anyone?

              

              Regards

              Abhijan Bhattacharyya

              Associate Consultant

              Scientist, Innovation Lab, Kolkata, India

              Tata Consultancy Services

              Mailto: abhijan.bhattacharyya@tcs.com

              Website: http://www.tcs.com

              ____________________________________________

              Experience certainty.        IT Services

                                     Business Solutions

                                     Consulting

              ____________________________________________
            
=====-----=====-----=====

              Notice: The information contained in this e-mail

              message and/or attachments to it may contain 

              confidential or privileged information. If you are 

              not the intended recipient, any dissemination, use, 

              review, distribution, printing or copying of the 

              information contained in this e-mail message 

              and/or attachments to it are strictly prohibited. If 

              you have received this communication in error, 

              please notify us by reply e-mail or telephone and 

              immediately and permanently delete the message 

              and any attachments. Thank you

            


            

            _______________________________________________

            core mailing list

            core@ietf.org

            https://www.ietf.org/mailman/listinfo/core

          

        

        

      

      

      

      

      
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


    

    

  


--------------060809060406020503070208--


From nobody Wed Oct 29 11:01:28 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725ED1A8764 for ; Wed, 29 Oct 2014 11:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5nNGzpQUmCZ for ; Wed, 29 Oct 2014 11:01:18 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364FD1A876C for ; Wed, 29 Oct 2014 11:01:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9568; q=dns/txt; s=iport; t=1414605670; x=1415815270; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=cKQh1IKfK+nJ6FOaCTIxPpVcM51AokUN4AvC2+TA3VU=; b=ADpX33dG83DIaXy+3D3pkeE/KxCQap3SqE/UpMA7GA0IGqJoyiJ617cI DCLBCecnO1RLIzoAKPw2u05cY4WbXj8FmdZKR3tyeavr98WtrLx5i0tNM w7tMRkna75vU0e6ZMM361O2tTsaINtTc3ZqWu1LftAQD0kculVHACyhB0 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqwEAIYqUVStJssW/2dsb2JhbABcg2JYzhwBCYdNAoEzAQEBAQF9hAMBAQQBAQFrChELBxEJFggHCQMCAQIBFR8REAMGAgEBF4gmDboajgIBAQEBAQEEAQEBAQEBAQEakQsMhEsBBI9uhmmEQYJSgTERgzmCdIcmgyKECYQUIS+CSwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,278,1413244800";  d="scan'208,217";a="229255975"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 29 Oct 2014 18:01:08 +0000
Received: from [10.131.65.104] (dhcp-10-131-65-104.cisco.com [10.131.65.104]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9TI17DO009251 for ; Wed, 29 Oct 2014 18:01:07 GMT
Message-ID: <54512B62.2040505@cisco.com>
Date: Wed, 29 Oct 2014 14:01:06 -0400
From: Paul Duffy 
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: core@ietf.org
References:   <545122AB.40401@gmail.com>
In-Reply-To: <545122AB.40401@gmail.com>
Content-Type: multipart/alternative; boundary="------------010307080008080404040102"
Archived-At: http://mailarchive.ietf.org/arch/msg/core/xcwCONMynXVr0KV9LWFrMLNZmZ4
Subject: Re: [core] Real Time Video over CoAP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: paduffy@cisco.com
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 18:01:25 -0000

This is a multi-part message in MIME format.
--------------010307080008080404040102
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Same questions.

How do RTP and RTSP not meet your needs?


On 10/29/2014 1:23 PM, Siddharth Heroor wrote:
> Hi Salvatore, Abhijan
>
> I too interested in seeing more on this. There are several 
> applications where streaming are an usecase. However, there are a few 
> questions that I have
>
> 1. How similar to RTP would this extension be and what would be the 
> differences?
> 2. The old draft does not cover resource capabilities and would that 
> be considered?
>
> Thanks and Regards,
> Sid
>
> On 29/10/14 9:41 am, Salvatore Loreto wrote:
>> Hi Abjian
>>
>> I haven't had almost any cycle to further progress the old proposal 
>> since my initial proposal.
>>
>> However if people are interested in helping and supporting I can 
>> resurrect the drag and update
>> with all the improvements done meanwhile in observe
>>
>> br
>> Salvatore
>>
>> On Oct 29, 2014, at 5:54 PM, Abhijan Bhattacharyya 
>> > > wrote:
>>
>>> Hi All,
>>> Just wonder if some effort is going on regarding transfer of 
>>> real-time video over CoAP.
>>> I could find an old draft on streaming over CoAP: 
>>> https://tools.ietf.org/html/draft-loreto-core-coap-streaming-00
>>>
>>> But, has there been any further progress on this recently, or, any 
>>> effort being put on this problem by anyone?
>>>
>>> Regards
>>> Abhijan Bhattacharyya
>>> Associate Consultant
>>> Scientist, Innovation Lab, Kolkata, India
>>> Tata Consultancy Services
>>> Mailto: abhijan.bhattacharyya@tcs.com 
>>> 
>>> Website: http://www.tcs.com 
>>> ____________________________________________
>>> Experience certainty.        IT Services
>>>                        Business Solutions
>>>                        Consulting
>>> ____________________________________________
>>>
>>> =====-----=====-----=====
>>> Notice: The information contained in this e-mail
>>> message and/or attachments to it may contain
>>> confidential or privileged information. If you are
>>> not the intended recipient, any dissemination, use,
>>> review, distribution, printing or copying of the
>>> information contained in this e-mail message
>>> and/or attachments to it are strictly prohibited. If
>>> you have received this communication in error,
>>> please notify us by reply e-mail or telephone and
>>> immediately and permanently delete the message
>>> and any attachments. Thank you
>>>
>>>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/core
>>
>>
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


--------------010307080008080404040102
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Same questions.

      

      How do RTP and RTSP not meet your needs?

      

      

      On 10/29/2014 1:23 PM, Siddharth Heroor wrote:

    

    

      
      Hi Salvatore, Abhijan

      

      I too interested in seeing more on this. There are several
      applications where streaming are an usecase. However, there are a
      few questions that I have

      

      1. How similar to RTP would this extension be and what would be
      the differences?

      2. The old draft does not cover resource capabilities and would
      that be considered?

      

      Thanks and Regards,

      Sid

      

      
On 29/10/14 9:41 am, Salvatore Loreto
        wrote:

      

      
 Hi Abjian
        


        

        
I haven't had almost any cycle to further progress the old
          proposal since my initial proposal.

        


        

        
However if people are interested in helping and supporting
          I can resurrect the drag and update

        
with all the improvements done meanwhile in observe 

        


        

        
br

        
Salvatore

        


          

            
On Oct 29, 2014, at 5:54 PM, Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>

              wrote:

            

            
Hi
                All, 

              Just wonder if some
                effort is going on regarding transfer of real-time video
                over CoAP. 

              I could find an old draft
                on streaming over CoAP: https://tools.ietf.org/html/draft-loreto-core-coap-streaming-00
              

              

              But, has there been any
                further progress on this recently, or, any effort being
                put on this problem by anyone?

                

                Regards

                Abhijan Bhattacharyya

                Associate Consultant

                Scientist, Innovation Lab, Kolkata, India

                Tata Consultancy Services

                Mailto: abhijan.bhattacharyya@tcs.com

                Website: http://www.tcs.com

                ____________________________________________

                Experience certainty.        IT Services

                                       Business Solutions

                                       Consulting

                ____________________________________________
              
=====-----=====-----=====

                Notice: The information contained in this e-mail

                message and/or attachments to it may contain 

                confidential or privileged information. If you are 

                not the intended recipient, any dissemination, use, 

                review, distribution, printing or copying of the 

                information contained in this e-mail message 

                and/or attachments to it are strictly prohibited. If 

                you have received this communication in error, 

                please notify us by reply e-mail or telephone and 

                immediately and permanently delete the message 

                and any attachments. Thank you

              


              

              _______________________________________________

              core mailing list

              core@ietf.org

              https://www.ietf.org/mailman/listinfo/core

            

          

          

        

        

        

        

        
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


      

      

      

      

      

      
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


    

    

  


--------------010307080008080404040102--


From nobody Wed Oct 29 13:19:13 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619241A1AF0 for ; Wed, 29 Oct 2014 13:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwtsK_nncNMJ for ; Wed, 29 Oct 2014 13:19:10 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8FB1A87AD for ; Wed, 29 Oct 2014 13:19:09 -0700 (PDT)
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 mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9TKJ2qY026878; Wed, 29 Oct 2014 21:19:02 +0100 (CET)
Received: from [192.168.217.113] (p5489343F.dip0.t-ipconnect.de [84.137.52.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8287E59D; Wed, 29 Oct 2014 21:19:02 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Carsten Bormann 
In-Reply-To: <54512B62.2040505@cisco.com>
Date: Wed, 29 Oct 2014 21:19:01 +0100
X-Mao-Original-Outgoing-Id: 436306740.367184-29c68a2cd3d6e0e82a4e7e9957c696b6
Content-Transfer-Encoding: quoted-printable
Message-Id: <58D5756B-9B65-4379-B8CA-42FDE4411291@tzi.org>
References:   <545122AB.40401@gmail.com> <54512B62.2040505@cisco.com>
To: paduffy@cisco.com
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/core/lCl87P57RbYicrW60kSJ_Bfot8s
Cc: core@ietf.org
Subject: Re: [core] Real Time Video over CoAP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 20:19:11 -0000

> How do RTP and RTSP not meet your needs?

RTP is actually a great protocol for streaming real-time video.

I=92m not sure that RTSP is such a great match in a more constrained =
environment.
(And which RTSP do you like =97 1.0 or 2.0?)
Obviously, if you have power and network bandwidth to do video, you are =
not that constrained.
But I could still imagine a more REST-style way to control the video =
streams.

Gr=FC=DFe, Carsten


From nobody Thu Oct 30 02:53:43 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DCE1AD094; Thu, 30 Oct 2014 02:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.709
X-Spam-Level: 
X-Spam-Status: No, score=-3.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEVhmcNPLYht; Thu, 30 Oct 2014 02:53:39 -0700 (PDT)
Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 256C11A86FA; Thu, 30 Oct 2014 02:53:37 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoGAEgHUlSsEhcE/2dsb2JhbABcg2JYzU8BCYdNAhyBHgEBAQEBfYQCAQEBAwEBAQEgSwQHBQsJAgcGAQMDAQIoAwICAiUfCQgGCgEIG4gdFpY4m2YBAXeUfgEBAQEBAQEBAQEBAQEBAQEBAQEZhVljigYzCg0EB4J3gVQFi2eHLoNCiESRBogIZIJLAQEB
X-IPAS-Result: AhoGAEgHUlSsEhcE/2dsb2JhbABcg2JYzU8BCYdNAhyBHgEBAQEBfYQCAQEBAwEBAQEgSwQHBQsJAgcGAQMDAQIoAwICAiUfCQgGCgEIG4gdFpY4m2YBAXeUfgEBAQEBAQEBAQEBAQEBAQEBAQEZhVljigYzCg0EB4J3gVQFi2eHLoNCiESRBogIZIJLAQEB
X-IronPort-AV: E=Sophos;i="5.07,284,1413225000"; d="scan'208";a="605216553"
Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 6A533DAC12; Thu, 30 Oct 2014 15:23:34 +0530 (IST)
Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 1A7B1DAC02; Thu, 30 Oct 2014 15:23:33 +0530 (IST)
In-Reply-To: <58D5756B-9B65-4379-B8CA-42FDE4411291@tzi.org>
References:   <545122AB.40401@gmail.com> <54512B62.2040505@cisco.com> <58D5756B-9B65-4379-B8CA-42FDE4411291@tzi.org>
To: Carsten Bormann 
MIME-Version: 1.0
X-KeepSent: 09389B72:6596EC38-65257D81:00331231; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: 
From: Abhijan Bhattacharyya 
Date: Thu, 30 Oct 2014 15:23:30 +0530
X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 10/30/2014 15:23:32, Serialize complete at 10/30/2014 15:23:32, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 10/30/2014 15:23:32
Content-Type: multipart/alternative; boundary="=_alternative 0036567765257D81_="
Archived-At: http://mailarchive.ietf.org/arch/msg/core/gSd6awIb0Y_WigJO2kWk4akUUXc
Cc: core , core@ietf.org
Subject: Re: [core] Real Time Video over CoAP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Oct 2014 09:53:42 -0000

This is a multipart message in MIME format.
--=_alternative 0036567765257D81_=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiA+IEhvdyBkbyBSVFAgYW5kIFJUU1Agbm90IG1lZXQgeW91ciBuZWVkcz8NCj4gDQo+IFJUUCBp
cyBhY3R1YWxseSBhIGdyZWF0IHByb3RvY29sIGZvciBzdHJlYW1pbmcgcmVhbC10aW1lIHZpZGVv
Lg0KDQpUaGlzIHdhcyBleGFjdGx5IHdoYXQgY2FtZSB0byBteSBtaW5kIGZpcnN0IHVwLg0KDQo+
IE9idmlvdXNseSwgaWYgeW91IGhhdmUgcG93ZXIgYW5kIG5ldHdvcmsgYmFuZHdpZHRoIHRvIGRv
IHZpZGVvLCB5b3UgDQo+IGFyZSBub3QgdGhhdCBjb25zdHJhaW5lZC4NCj4gQnV0IEkgY291bGQg
c3RpbGwgaW1hZ2luZSBhIG1vcmUgUkVTVC1zdHlsZSB3YXkgdG8gY29udHJvbCB0aGUgdmlkZW8g
DQpzdHJlYW1zLg0KDQpNb2RlbGluZyByZWFsLXRpbWUgc3RyZWFtaW5nIGFzIFJFU1RmdWwgZXhj
aGFuZ2UgaXMgcmVhbGx5IGEgZ29vZCANCnByb3Bvc2l0aW9uLiBCdXQsIGhhcyBhbnlvbmUgZG9u
ZSBhbnkgc3R1ZHkgKG1heSBiZSB2ZXJ5IHNwZWNpZmljIHRvIHNvbWUgDQp1c2VjYXNlKSByZWdh
cmRpbmcgd2hldGhlciB0aGVyZSBpcyBhbnkgc2NlbmFyaW8gd2hlcmUgZXhpc3Rpbmcgc3R1ZmZz
IA0KbGlrZSBSVFAgbWF5IG5vdCBiZSBhIGdvb2QgY2hvaWNlIGFuZCB3b3VsZCBuZWVkIHNvbWUg
bmV3IGxpZ2h0d2VpZ2h0IA0Kc29sdXRpb24gKG1heSBiZSBvbiBDb0FQKT8gSXQgc2VlbXMgUmVh
bC10aW1lIHZpZGVvIHN0cmVhbWluZyBmb3IgSW9UIA0KYXBwbGljYXRpb25zIG1heSBmaW5kIGdv
b2QgIHRyYWN0aW9uIGluIGZ1dHVyZSAobm90IHlldCBzdXJlIGFib3V0IGV4YWN0IA0KdXNlY2Fz
ZSBwZW9wbGUgbWF5IGhhdmUpLg0KDQpXaGF0IEkgaW5mZXJyZWQgZnJvbSANCmh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb3JldG8tY29yZS1jb2FwLXN0cmVhbWluZy0wMCBpcyB0
aGF0IGl0IA0KaXMgYmFzaWNhbGx5IGEgdmFyaWF0aW9uIG9mIGJsb2NrLXdpc2UgdHJhbnNmZXIg
b3ZlciBDb0FQLCBidXQgd2l0aCANCm9ic2VydmUgcmVsYXRpb25zaGlwLiBUaGUgc2l6ZSBvZiB0
aGUgYmxvY2sgKGNodW5rKSBpcyBub3QgbmVnb3RpYXRlZCANCnRob3VnaC4gUHJvYmFibHkgaXQg
aXMgYXNzdW1lZCB0aGF0IGNodW5rLXNpemUgaGFzIGRpcmVjdCBtYXBwaW5nIHdpdGggdGhlIA0K
RW5jb2RlciBjaG9zZW4gYWZ0ZXIgdGhlIGRpc2NvdmVyIHBoYXNlLig/KSANCiANClJlZ2FyZHMN
CkFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVudGlzdCwg
SW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2Vz
DQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tDQpXZWJzaXRlOiBodHRwOi8v
d3d3LnRjcy5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpFeHBlcmllbmNlIGNlcnRhaW50eS4gICBJVCBTZXJ2aWNlcw0KICAgICAgICAgICAgICAgICAg
ICAgICAgQnVzaW5lc3MgU29sdXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgICBDb25zdWx0
aW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoiY29y
ZSIgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gd3JvdGUgb24gMTAvMzAvMjAxNCAwMTo0OTowMSBB
TToNCg0KPiBGcm9tOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NCj4gVG86IHBhZHVm
ZnlAY2lzY28uY29tDQo+IENjOiBjb3JlQGlldGYub3JnDQo+IERhdGU6IDEwLzMwLzIwMTQgMDE6
NDkgQU0NCj4gU3ViamVjdDogUmU6IFtjb3JlXSBSZWFsIFRpbWUgVmlkZW8gb3ZlciBDb0FQPw0K
PiBTZW50IGJ5OiAiY29yZSIgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4NCj4gDQo+ID4gSG93IGRv
IFJUUCBhbmQgUlRTUCBub3QgbWVldCB5b3VyIG5lZWRzPw0KPiANCj4gUlRQIGlzIGFjdHVhbGx5
IGEgZ3JlYXQgcHJvdG9jb2wgZm9yIHN0cmVhbWluZyByZWFsLXRpbWUgdmlkZW8uDQo+IA0KPiBJ
4oCZbSBub3Qgc3VyZSB0aGF0IFJUU1AgaXMgc3VjaCBhIGdyZWF0IG1hdGNoIGluIGEgbW9yZSBj
b25zdHJhaW5lZCANCj4gZW52aXJvbm1lbnQuDQo+IChBbmQgd2hpY2ggUlRTUCBkbyB5b3UgbGlr
ZSDigJQgMS4wIG9yIDIuMD8pDQo+IE9idmlvdXNseSwgaWYgeW91IGhhdmUgcG93ZXIgYW5kIG5l
dHdvcmsgYmFuZHdpZHRoIHRvIGRvIHZpZGVvLCB5b3UgDQo+IGFyZSBub3QgdGhhdCBjb25zdHJh
aW5lZC4NCj4gQnV0IEkgY291bGQgc3RpbGwgaW1hZ2luZSBhIG1vcmUgUkVTVC1zdHlsZSB3YXkg
dG8gY29udHJvbCB0aGUgdmlkZW8gDQpzdHJlYW1zLg0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0K
PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
Y29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0KPT09PT0tLS0tLT09PT09LS0tLS09PT09PQpOb3Rp
Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwKbWVzc2FnZSBhbmQv
b3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gCmNvbmZpZGVudGlhbCBvciBwcml2aWxl
Z2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIApub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg
YW55IGRpc3NlbWluYXRpb24sIHVzZSwgCnJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBv
ciBjb3B5aW5nIG9mIHRoZSAKaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1l
c3NhZ2UgCmFuZC9vciBhdHRhY2htZW50cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4g
SWYgCnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgCnBsZWFz
ZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9yIHRlbGVwaG9uZSBhbmQgCmltbWVkaWF0ZWx5
IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgCmFuZCBhbnkgYXR0YWNobWVudHMu
IFRoYW5rIHlvdQoKCg==

--=_alternative 0036567765257D81_=
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgSG93IGRvIFJUUCBhbmQgUlRTUCBub3QgbWVldCB5
b3VyIG5lZWRzPzxicj4NCiZndDsgPGJyPg0KJmd0OyBSVFAgaXMgYWN0dWFsbHkgYSBncmVhdCBw
cm90b2NvbCBmb3Igc3RyZWFtaW5nIHJlYWwtdGltZSB2aWRlby48L2ZvbnQ+PC90dD4NCjxicj4N
Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhpcyB3YXMgZXhhY3RseSB3aGF0
IGNhbWUgdG8gbXkgbWluZA0KZmlyc3QgdXAuPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz
aXplPTI+Jmd0OyBPYnZpb3VzbHksIGlmIHlvdSBoYXZlIHBvd2VyIGFuZCBuZXR3b3JrIGJhbmR3
aWR0aA0KdG8gZG8gdmlkZW8sIHlvdSA8YnI+DQomZ3Q7IGFyZSBub3QgdGhhdCBjb25zdHJhaW5l
ZC48YnI+DQomZ3Q7IEJ1dCBJIGNvdWxkIHN0aWxsIGltYWdpbmUgYSBtb3JlIFJFU1Qtc3R5bGUg
d2F5IHRvIGNvbnRyb2wgdGhlIHZpZGVvDQpzdHJlYW1zLjwvZm9udD48L3R0Pjxmb250IHNpemU9
MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPk1vZGVsaW5nIHJlYWwtdGltZSBzdHJlYW1pbmcgYXMgUkVTVGZ1bA0KZXhj
aGFuZ2UgaXMgcmVhbGx5IGEgZ29vZCBwcm9wb3NpdGlvbi4gQnV0LCBoYXMgYW55b25lIGRvbmUg
YW55IHN0dWR5IChtYXkNCmJlIHZlcnkgc3BlY2lmaWMgdG8gc29tZSB1c2VjYXNlKSByZWdhcmRp
bmcgd2hldGhlciB0aGVyZSBpcyBhbnkgc2NlbmFyaW8NCndoZXJlIGV4aXN0aW5nIHN0dWZmcyBs
aWtlIFJUUCBtYXkgbm90IGJlIGEgZ29vZCBjaG9pY2UgYW5kIHdvdWxkIG5lZWQNCnNvbWUgbmV3
IGxpZ2h0d2VpZ2h0IHNvbHV0aW9uIChtYXkgYmUgb24gQ29BUCk/IEl0IHNlZW1zIFJlYWwtdGlt
ZSB2aWRlbw0Kc3RyZWFtaW5nIGZvciBJb1QgYXBwbGljYXRpb25zIG1heSBmaW5kIGdvb2QgJm5i
c3A7dHJhY3Rpb24gaW4gZnV0dXJlIChub3QNCnlldCBzdXJlIGFib3V0IGV4YWN0IHVzZWNhc2Ug
cGVvcGxlIG1heSBoYXZlKS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh
bnMtc2VyaWYiPldoYXQgSSBpbmZlcnJlZCBmcm9tIDwvZm9udD48YSBocmVmPSJodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9yZXRvLWNvcmUtY29hcC1zdHJlYW1pbmctMDAiPjxm
b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPmh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1sb3JldG8tY29yZS1jb2FwLXN0cmVhbWluZy0wMDwvZm9udD48L2E+
PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPg0KaXMgdGhhdCBpdCBpcyBiYXNpY2FsbHkg
YSB2YXJpYXRpb24gb2YgYmxvY2std2lzZSB0cmFuc2ZlciBvdmVyIENvQVAsIGJ1dA0Kd2l0aCBv
YnNlcnZlIHJlbGF0aW9uc2hpcC4gVGhlIHNpemUgb2YgdGhlIGJsb2NrIChjaHVuaykgaXMgbm90
IG5lZ290aWF0ZWQNCnRob3VnaC4gUHJvYmFibHkgaXQgaXMgYXNzdW1lZCB0aGF0IGNodW5rLXNp
emUgaGFzIGRpcmVjdCBtYXBwaW5nIHdpdGgNCnRoZSBFbmNvZGVyIGNob3NlbiBhZnRlciB0aGUg
ZGlzY292ZXIgcGhhc2UuKD8pICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
c2Fucy1zZXJpZiI+Jm5ic3A7PGJyPg0KUmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hhcnl5
YTxicj4NCkFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExh
YiwgS29sa2F0YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KTWFp
bHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxicj4NCldlYnNpdGU6IDwvZm9udD48
YSBocmVmPWh0dHA6Ly93d3cudGNzLmNvbS8+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
Pmh0dHA6Ly93d3cudGNzLmNvbTwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNl
cnZpY2VzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9u
czxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2ZvbnQ+DQo8YnI+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtjb3JlJnF1b3Q7ICZsdDtjb3JlLWJvdW5jZXNAaWV0Zi5v
cmcmZ3Q7IHdyb3RlDQpvbiAxMC8zMC8yMDE0IDAxOjQ5OjAxIEFNOjxicj4NCjxicj4NCiZndDsg
RnJvbTogQ2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7PC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRvOiBwYWR1ZmZ5QGNpc2NvLmNvbTwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDYzogY29yZUBpZXRmLm9yZzwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBEYXRlOiAxMC8zMC8yMDE0IDAxOjQ5IEFNPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFN1YmplY3Q6IFJlOiBbY29yZV0g
UmVhbCBUaW1lIFZpZGVvIG92ZXIgQ29BUD88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgU2VudCBieTogJnF1b3Q7Y29yZSZxdW90OyAmbHQ7Y29yZS1ib3VuY2VzQGlldGYu
b3JnJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7
ICZndDsgSG93IGRvIFJUUCBhbmQgUlRTUCBub3QgbWVldCB5b3VyIG5lZWRzPzxicj4NCiZndDsg
PGJyPg0KJmd0OyBSVFAgaXMgYWN0dWFsbHkgYSBncmVhdCBwcm90b2NvbCBmb3Igc3RyZWFtaW5n
IHJlYWwtdGltZSB2aWRlby48YnI+DQomZ3Q7IDxicj4NCiZndDsgSeKAmW0gbm90IHN1cmUgdGhh
dCBSVFNQIGlzIHN1Y2ggYSBncmVhdCBtYXRjaCBpbiBhIG1vcmUgY29uc3RyYWluZWQNCjxicj4N
CiZndDsgZW52aXJvbm1lbnQuPGJyPg0KJmd0OyAoQW5kIHdoaWNoIFJUU1AgZG8geW91IGxpa2Ug
4oCUIDEuMCBvciAyLjA/KTxicj4NCiZndDsgT2J2aW91c2x5LCBpZiB5b3UgaGF2ZSBwb3dlciBh
bmQgbmV0d29yayBiYW5kd2lkdGggdG8gZG8gdmlkZW8sIHlvdQ0KPGJyPg0KJmd0OyBhcmUgbm90
IHRoYXQgY29uc3RyYWluZWQuPGJyPg0KJmd0OyBCdXQgSSBjb3VsZCBzdGlsbCBpbWFnaW5lIGEg
bW9yZSBSRVNULXN0eWxlIHdheSB0byBjb250cm9sIHRoZSB2aWRlbw0Kc3RyZWFtcy48YnI+DQom
Z3Q7IDxicj4NCiZndDsgR3LDvMOfZSwgQ2Fyc3Rlbjxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgY29y
ZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IGNvcmVAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9udD48
L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPjx0
dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl
PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DTxwPj09
PT09LS0tLS09PT09PS0tLS0tPT09PT08YnI+Ck5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh
aW5lZCBpbiB0aGlzIGUtbWFpbDxicj4KbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQg
bWF5IGNvbnRhaW4gPGJyPgpjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4g
SWYgeW91IGFyZSA8YnI+Cm5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzc2VtaW5h
dGlvbiwgdXNlLCA8YnI+CnJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5n
IG9mIHRoZSA8YnI+CmluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdl
IDxicj4KYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IGFyZSBzdHJpY3RseSBwcm9oaWJpdGVkLiBJ
ZiA8YnI+CnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgPGJy
PgpwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kIDxicj4K
aW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgbWVzc2FnZSA8YnI+CmFuZCBh
bnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdTwvcD4KCjxwPjwvcD4=

--=_alternative 0036567765257D81_=--


From nobody Thu Oct 30 05:20:29 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F381A0040 for ; Thu, 30 Oct 2014 05:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level: 
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hLvudwWIWER for ; Thu, 30 Oct 2014 05:20:18 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id DE0D91A000A for ; Thu, 30 Oct 2014 05:20:17 -0700 (PDT)
Received: from WeiGengyuPC (unknown [222.131.12.112]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id CAD6719F3AE; Thu, 30 Oct 2014 20:20:14 +0800 (HKT)
Message-ID: <1535E27B75FB4C228D3BB15424B69ECB@WeiGengyuPC>
From: "weigengyu" 
To: "Carsten Bormann" , "Abhijan Bhattacharyya" 
References:   <545122AB.40401@gmail.com> <54512B62.2040505@cisco.com> <58D5756B-9B65-4379-B8CA-42FDE4411291@tzi.org> 
In-Reply-To: 
Date: Thu, 30 Oct 2014 20:20:13 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0305_01CFF47E.E996E230"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: http://mailarchive.ietf.org/arch/msg/core/r0ywRj-UMF2CgX7BdPewWEAsKVI
Cc: core@ietf.org
Subject: Re: [core] Real Time Video over CoAP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Oct 2014 12:20:24 -0000

ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£

------=_NextPart_000_0305_01CFF47E.E996E230
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi=EF=BC=8C=20

If the CoAP server is supposed to have enough capabilities in terms of =
power and wireless link,
tranfering streaming data should be considered.=20
And, supporting what kind of treaming data should be based on usage =
scenarios.=20

This opinion is based a work serveral years ago.
The work is to develop a communication software between a watch and a =
smart mobilephone.=20
The watch can transfer a file of electrocardiogram to the smart =
mobilephone after finishing detection.=20
There are requirements for real-time monitoring and transfering;=20
but, at that time it was regarded  invalid to deliver real time data  =
due the power and wireless link capacity.=20

Best regards,

Gengyu WEI
Network Technology Center
School of Computer=20
Beijing University of Posts and Telecommunications

From: Abhijan Bhattacharyya=20
Sent: Thursday, October 30, 2014 5:53 PM
To: Carsten Bormann=20
Cc: core ; core@ietf.org=20
Subject: Re: [core] Real Time Video over CoAP?

> > How do RTP and RTSP not meet your needs?
>=20
> RTP is actually a great protocol for streaming real-time video.=20

This was exactly what came to my mind first up.=20

> Obviously, if you have power and network bandwidth to do video, you=20
> are not that constrained.
> But I could still imagine a more REST-style way to control the video =
streams.

Modeling real-time streaming as RESTful exchange is really a good =
proposition. But, has anyone done any study (may be very specific to =
some usecase) regarding whether there is any scenario where existing =
stuffs like RTP may not be a good choice and would need some new =
lightweight solution (may be on CoAP)? It seems Real-time video =
streaming for IoT applications may find good  traction in future (not =
yet sure about exact usecase people may have).=20

What I inferred from =
https://tools.ietf.org/html/draft-loreto-core-coap-streaming-00 is that =
it is basically a variation of block-wise transfer over CoAP, but with =
observe relationship. The size of the block (chunk) is not negotiated =
though. Probably it is assumed that chunk-size has direct mapping with =
the Encoder chosen after the discover phase.(?) =20
=20
Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________=20

"core"  wrote on 10/30/2014 01:49:01 AM:

> From: Carsten Bormann =20
> To: paduffy@cisco.com=20
> Cc: core@ietf.org=20
> Date: 10/30/2014 01:49 AM=20
> Subject: Re: [core] Real Time Video over CoAP?=20
> Sent by: "core" =20
>=20
> > How do RTP and RTSP not meet your needs?
>=20
> RTP is actually a great protocol for streaming real-time video.
>=20
> I=E2=80=99m not sure that RTSP is such a great match in a more =
constrained=20
> environment.
> (And which RTSP do you like =E2=80=94 1.0 or 2.0?)
> Obviously, if you have power and network bandwidth to do video, you=20
> are not that constrained.
> But I could still imagine a more REST-style way to control the video =
streams.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain=20
confidential or privileged information. If you are=20
not the intended recipient, any dissemination, use,=20
review, distribution, printing or copying of the=20
information contained in this e-mail message=20
and/or attachments to it are strictly prohibited. If=20
you have received this communication in error,=20
please notify us by reply e-mail or telephone and=20
immediately and permanently delete the message=20
and any attachments. Thank you



-------------------------------------------------------------------------=
-------
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

------=_NextPart_000_0305_01CFF47E.E996E230
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable








Hi=EF=BC=8C 


 


If the CoAP server is supposed to have =
enough=20
capabilities in terms of power and wireless=20
link,


tranfering streaming data should be =
considered.=20



And, supporting what kind of treaming data should be based on usage =

scenarios. 


 


This opinion is based a work serveral years ago.


The work is to develop a communication software between a watch and =
a smart=20
mobilephone. 


The watch can transfer a file of electrocardiogram to=20
the smart mobilephone after finishing =
detection. 


There are requirements for real-time monitoring =
and=20
transfering; 


but, at that time it =
was regarded  invalid to deliver real time data  =
due the=20
power and wireless link capacity.=20



 


Best=20
regards,


 


Gengyu=20
WEI
Network Technology Center
School of Computer 
Beijing =
University of=20
Posts and Telecommunications





 




From: Abhijan Bhattacharyya =



Sent: Thursday, October 30, 2014 5:53 PM




Subject: Re: [core] Real Time Video over =
CoAP?


 

> > How do RTP and RTSP not meet your needs?
> =

> RTP=20
is actually a great protocol for streaming real-time video.=20


This was exactly what came to =
my mind first=20
up. 

> Obviously, if you have power =
and=20
network bandwidth to do video, you 
> are not that =
constrained.
>=20
But I could still imagine a more REST-style way to control the video=20
streams.

Modeling real-time streaming as RESTful exchange is =
really a=20
good proposition. But, has anyone done any study (may be very specific =
to some=20
usecase) regarding whether there is any scenario where existing stuffs =
like RTP=20
may not be a good choice and would need some new lightweight solution =
(may be on=20
CoAP)? It seems Real-time video streaming for IoT applications may find=20
good  traction in future (not yet sure about exact usecase people =
may=20
have). 

What I inferred =
from=20
=
https://tools.ietf.org/html/draft-loreto-core-coap-stre=
aming-00 is that it is basically a variation of =
block-wise=20
transfer over CoAP, but with observe relationship. The size of the block =
(chunk)=20
is not negotiated though. Probably it is assumed that chunk-size has =
direct=20
mapping with the Encoder chosen after the discover phase.(?) =20

 
Regards
Abhijan =

Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, =
Kolkata,=20
India
Tata Consultancy Services
Mailto:=20
abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Exp=
erience=20
certainty.        IT=20
Services
          &=
nbsp;           =20
Business=20
Solutions
          =
             =

Consulting
____________________________________________=20


"core" <core-bounces@ietf.org> wrote on =

10/30/2014 01:49:01 AM:

> From: Carsten Bormann=20
<cabo@tzi.org> 
> To:=20
paduffy@cisco.com 
> Cc:=20
core@ietf.org 
> Date: 10/30/2014 =
01:49=20
AM 
> Subject: Re: [core] Real Time =
Video=20
over CoAP? 
> Sent by: "core"=20
<core-bounces@ietf.org> 
> =

>=20
> How do RTP and RTSP not meet your needs?
> 
> RTP is =
actually a=20
great protocol for streaming real-time video.
> 
> =
I=E2=80=99m not sure that=20
RTSP is such a great match in a more constrained 
> =
environment.
>=20
(And which RTSP do you like =E2=80=94 1.0 or 2.0?)
> Obviously, if =
you have power=20
and network bandwidth to do video, you 
> are not that=20
constrained.
> But I could still imagine a more REST-style way to =
control=20
the video streams.
> 
> Gr=C3=BC=C3=9Fe, Carsten
> =

>=20
_______________________________________________
> core mailing=20
list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: =
The information contained in this=20
e-mail
message and/or attachments to it may contain 
confidential =
or=20
privileged information. If you are 
not the intended recipient, any=20
dissemination, use, 
review, distribution, printing or copying of the =


information contained in this e-mail message 
and/or attachments =
to it=20
are strictly prohibited. If 
you have received this communication in =
error,=20

please notify us by reply e-mail or telephone and 
immediately =
and=20
permanently delete the message 
and any attachments. Thank you





_______________________________________________
core mailing=20
list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


------=_NextPart_000_0305_01CFF47E.E996E230--


From nobody Thu Oct 30 06:41:15 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C241AD0BC for ; Thu, 30 Oct 2014 06:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pE6OPfLL3DS for ; Thu, 30 Oct 2014 06:41:11 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99AD11A0053 for ; Thu, 30 Oct 2014 06:41:11 -0700 (PDT)
Received: from localhost ([::1]:54351 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XjpyJ-00084A-6c; Thu, 30 Oct 2014 06:41:03 -0700
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-http-mapping@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Thu, 30 Oct 2014 13:41:03 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/366#comment:3
Message-ID: <075.f812b88d140965a1cdd0fcac99bbdcda@trac.tools.ietf.org>
References: <060.d08ddf762931f56b1e0855733864e9d9@trac.tools.ietf.org>
X-Trac-Ticket-ID: 366
In-Reply-To: <060.d08ddf762931f56b1e0855733864e9d9@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, thomas.fossati@alcatel-lucent.com
Archived-At: http://mailarchive.ietf.org/arch/msg/core/l3F4TS_SzFQvoSbanQaP4Irmg4s
Cc: core@ietf.org
Subject: Re: [core] #366 (http-mapping): Mapping of Link Format payloads to be valid in HTTP domain
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: trac+core@zinfandel.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, 30 Oct 2014 13:41:13 -0000

#366: Mapping of Link Format payloads to be valid in HTTP domain

Changes (by esko.dijk@philips.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Now addressed in the version -05. Inclusion of all /.well-known/core
 resources of all CoAP devices proxied for, is not incorporated due to some
 issues we see with this.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-http-
  esko.dijk@philips.com  |  mapping@tools.ietf.org
     Type:  protocol     |      Status:  closed
  enhancement            |   Milestone:
 Priority:  major        |     Version:
Component:  http-        |  Resolution:  fixed
  mapping                |
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Thu Oct 30 06:41:40 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E1C1AD367 for ; Thu, 30 Oct 2014 06:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkidjaJrn2sR for ; Thu, 30 Oct 2014 06:41:36 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931CA1AD35B for ; Thu, 30 Oct 2014 06:41:36 -0700 (PDT)
Received: from localhost ([::1]:54381 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xjpyl-0008G3-Ni; Thu, 30 Oct 2014 06:41:31 -0700
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-http-mapping@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Thu, 30 Oct 2014 13:41:31 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/375#comment:1
Message-ID: <075.1f2727bbcfa5f032ef87528298c4155a@trac.tools.ietf.org>
References: <060.57742d50691ea88699e0826ea2600aad@trac.tools.ietf.org>
X-Trac-Ticket-ID: 375
In-Reply-To: <060.57742d50691ea88699e0826ea2600aad@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, thomas.fossati@alcatel-lucent.com
Archived-At: http://mailarchive.ietf.org/arch/msg/core/EleeBzPxXnUYK7cojrX0TIQLDzU
Cc: core@ietf.org
Subject: Re: [core] #375 (http-mapping): Add requirement on mapping of CoAP diagnostic payload
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: trac+core@zinfandel.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, 30 Oct 2014 13:41:38 -0000

#375: Add requirement on mapping of CoAP diagnostic payload

Changes (by esko.dijk@philips.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done in version -05

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-http-
  esko.dijk@philips.com  |  mapping@tools.ietf.org
     Type:  protocol     |      Status:  closed
  enhancement            |   Milestone:
 Priority:  minor        |     Version:
Component:  http-        |  Resolution:  fixed
  mapping                |
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Thu Oct 30 17:16:54 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68B81A8A28; Thu, 30 Oct 2014 17:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level: 
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2VQzxnCjZKU; Thu, 30 Oct 2014 17:16:35 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 939361A8A1E; Thu, 30 Oct 2014 17:16:30 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 3A39C181C8B; Thu, 30 Oct 2014 17:15:41 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20141031001541.3A39C181C8B@rfc-editor.org>
Date: Thu, 30 Oct 2014 17:15:41 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/core/xXGJmKLdaqGbiwJbAxLs6sZkqwc
Cc: drafts-update-ref@iana.org, core@ietf.org, rfc-editor@rfc-editor.org
Subject: [core] RFC 7390 on Group Communication for the Constrained Application Protocol (CoAP)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 31 Oct 2014 00:16:44 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7390

        Title:      Group Communication for the Constrained 
                    Application Protocol (CoAP) 
        Author:     A. Rahman, Ed.,
                    E. Dijk, Ed.
        Status:     Experimental
        Stream:     IETF
        Date:       October 2014
        Mailbox:    Akbar.Rahman@InterDigital.com, 
                    esko.dijk@philips.com
        Pages:      46
        Characters: 106675
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-core-groupcomm-25.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7390.txt

The Constrained Application Protocol (CoAP) is a specialized web
transfer protocol for constrained devices and constrained networks.
It is anticipated that constrained devices will often naturally
operate in groups (e.g., in a building automation scenario, all
lights in a given room may need to be switched on/off as a group).
This specification defines how CoAP should be used in a group
communication context.  An approach for using CoAP on top of IP
multicast is detailed based on existing CoAP functionality as well as
new features introduced in this specification.  Also, various use
cases and corresponding protocol flows are provided to illustrate
important concepts.  Finally, guidance is provided for deployment in
various network topologies.

This document is a product of the Constrained RESTful Environments Working Group of the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Fri Oct 31 02:26:57 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5921A86E3 for ; Fri, 31 Oct 2014 02:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level: 
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_ETWOqaxO0D for ; Fri, 31 Oct 2014 02:26:51 -0700 (PDT)
Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id C69EB1A86E4 for ; Fri, 31 Oct 2014 02:26:48 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8FAPxUU1SsEhcE/2dsb2JhbABcDoNUWIMGygUBCYdNAhyBFAEBAQEBfYQCAQEBAwEBAQEgSwQHBQsJAgcGBAMBAQEoAwICAiUfCQgGCgEIG4gdFpgEm2YBAXeUbQEBAQEBAQEBAQEBAQEBAQEBAQEBAReFWmOEN4VOMwoMAQQHBoJxNoEeBYtvhy+DRIREhAMRgzmNRIdBSGSCSwEBAQ
X-IPAS-Result: Ai8FAPxUU1SsEhcE/2dsb2JhbABcDoNUWIMGygUBCYdNAhyBFAEBAQEBfYQCAQEBAwEBAQEgSwQHBQsJAgcGBAMBAQEoAwICAiUfCQgGCgEIG4gdFpgEm2YBAXeUbQEBAQEBAQEBAQEBAQEBAQEBAQEBAReFWmOEN4VOMwoMAQQHBoJxNoEeBYtvhy+DRIREhAMRgzmNRIdBSGSCSwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,293,1413225000"; d="scan'208";a="605732323"
X-DISCLAIMER: FALSE
Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 05D8DDAC12; Fri, 31 Oct 2014 14:56:39 +0530 (IST)
Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 7D798DAC02; Fri, 31 Oct 2014 14:56:38 +0530 (IST)
In-Reply-To: <1535E27B75FB4C228D3BB15424B69ECB@WeiGengyuPC>
References:   <545122AB.40401@gmail.com> <54512B62.2040505@cisco.com> <58D5756B-9B65-4379-B8CA-42FDE4411291@tzi.org>  <1535E27B75FB4C228D3BB15424B69ECB@WeiGengyuPC>
To: "weigengyu" 
MIME-Version: 1.0
X-KeepSent: D3997807:1ED537CE-65257D82:0031B98A; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: 
From: Abhijan Bhattacharyya 
Date: Fri, 31 Oct 2014 14:55:44 +0530
X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 10/31/2014 14:55:46, Serialize complete at 10/31/2014 14:55:46, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 10/31/2014 14:56:38, Serialize complete at 10/31/2014 14:56:38
Content-Type: multipart/alternative; boundary="=_alternative 0033C9D165257D82_="
Archived-At: http://mailarchive.ietf.org/arch/msg/core/ETh_ndDIoMfaovnXNNHL4ylPb64
Cc: core@ietf.org
Subject: Re: [core] Real Time Video over CoAP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 31 Oct 2014 09:26:55 -0000

This is a multipart message in MIME format.
--=_alternative 0033C9D165257D82_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

PiBUaGVyZSBhcmUgcmVxdWlyZW1lbnRzIGZvciByZWFsLXRpbWUgbW9uaXRvcmluZyBhbmQgdHJh
bnNmZXJpbmc7IA0KVGhhdCB3aWxsIGFsc28gYmUgbXkgdGFrZS4gQnV0IHdlIG5lZWQgdG8ga25v
dyBob3cgY3VycmVudCANCnN0YXRlLW9mLXRoZS1hcnQgKGxpa2UgUlRQKSBmYXJlcy4gTWF5IGJl
IGEgc29sdXRpb24gb3ZlciBDb0FQIHdpbGwgZ2V0IA0KcmlkIG9mIGFueSBjb25uZWN0aW9uIGVz
dGFibGlzaG1lbnQgb3ZlcmhlYWQgYW5kIHRydWVseSByZWFsLXRpbWUgdGhhbiANClJUUD8gVGhh
dCBpcyB3aGF0IEkgZmVsdCBsb29raW5nIGF0IHRoZSBDb0FQIFN0cmVhbWluZyBkcmFmdC4gDQoN
ClJlZ2FyZHMNCkFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNj
aWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5
IFNlcnZpY2VzDQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tDQpXZWJzaXRl
OiBodHRwOi8vd3d3LnRjcy5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpFeHBlcmllbmNlIGNlcnRhaW50eS4gICBJVCBTZXJ2aWNlcw0KICAgICAgICAg
ICAgICAgICAgICAgICAgQnVzaW5lc3MgU29sdXRpb25zDQogICAgICAgICAgICAgICAgICAgICAg
ICBDb25zdWx0aW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KDQoid2VpZ2VuZ3l1IiA8d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuPiB3cm90ZSBvbiAxMC8zMC8y
MDE0IDA1OjUwOjEzIFBNOg0KDQo+IEZyb206ICJ3ZWlnZW5neXUiIDx3ZWlnZW5neXVAYnVwdC5l
ZHUuY24+DQo+IFRvOiAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fib0B0emkub3JnPiwgIkFiaGlqYW4g
QmhhdHRhY2hhcnl5YSIgDQo+IDxhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT4NCj4gQ2M6
IDxjb3JlQGlldGYub3JnPg0KPiBEYXRlOiAxMC8zMC8yMDE0IDA1OjUwIFBNDQo+IFN1YmplY3Q6
IFJlOiBbY29yZV0gUmVhbCBUaW1lIFZpZGVvIG92ZXIgQ29BUD8NCj4gDQo+IEhp77yMIA0KPiAN
Cj4gSWYgdGhlIENvQVAgc2VydmVyIGlzIHN1cHBvc2VkIHRvIGhhdmUgZW5vdWdoIGNhcGFiaWxp
dGllcyBpbiB0ZXJtcyANCj4gb2YgcG93ZXIgYW5kIHdpcmVsZXNzIGxpbmssDQo+IHRyYW5mZXJp
bmcgc3RyZWFtaW5nIGRhdGEgc2hvdWxkIGJlIGNvbnNpZGVyZWQuIA0KPiBBbmQsIHN1cHBvcnRp
bmcgd2hhdCBraW5kIG9mIHRyZWFtaW5nIGRhdGEgc2hvdWxkIGJlIGJhc2VkIG9uIHVzYWdlIA0K
PiBzY2VuYXJpb3MuIA0KPiANCj4gVGhpcyBvcGluaW9uIGlzIGJhc2VkIGEgd29yayBzZXJ2ZXJh
bCB5ZWFycyBhZ28uDQo+IFRoZSB3b3JrIGlzIHRvIGRldmVsb3AgYSBjb21tdW5pY2F0aW9uIHNv
ZnR3YXJlIGJldHdlZW4gYSB3YXRjaCBhbmQgDQo+IGEgc21hcnQgbW9iaWxlcGhvbmUuIA0KPiBU
aGUgd2F0Y2ggY2FuIHRyYW5zZmVyIGEgZmlsZSBvZiBlbGVjdHJvY2FyZGlvZ3JhbSB0byB0aGUg
c21hcnQgDQo+IG1vYmlsZXBob25lIGFmdGVyIGZpbmlzaGluZyBkZXRlY3Rpb24uIA0KPiBUaGVy
ZSBhcmUgcmVxdWlyZW1lbnRzIGZvciByZWFsLXRpbWUgbW9uaXRvcmluZyBhbmQgdHJhbnNmZXJp
bmc7IA0KPiBidXQsIGF0IHRoYXQgdGltZSBpdCB3YXMgcmVnYXJkZWQgIGludmFsaWQgdG8gZGVs
aXZlciByZWFsIHRpbWUgZGF0YQ0KPiBkdWUgdGhlIHBvd2VyIGFuZCB3aXJlbGVzcyBsaW5rIGNh
cGFjaXR5LiANCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gDQo+IEdlbmd5dSBXRUkNCj4gTmV0d29y
ayBUZWNobm9sb2d5IENlbnRlcg0KPiBTY2hvb2wgb2YgQ29tcHV0ZXIgDQo+IEJlaWppbmcgVW5p
dmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zDQo+IA0KPiBGcm9tOiBBYmhp
amFuIEJoYXR0YWNoYXJ5eWEgDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDMwLCAyMDE0IDU6
NTMgUE0NCj4gVG86IENhcnN0ZW4gQm9ybWFubiANCj4gQ2M6IGNvcmUgOyBjb3JlQGlldGYub3Jn
IA0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIFJlYWwgVGltZSBWaWRlbyBvdmVyIENvQVA/DQo+IA0K
PiA+ID4gSG93IGRvIFJUUCBhbmQgUlRTUCBub3QgbWVldCB5b3VyIG5lZWRzPw0KPiA+IA0KPiA+
IFJUUCBpcyBhY3R1YWxseSBhIGdyZWF0IHByb3RvY29sIGZvciBzdHJlYW1pbmcgcmVhbC10aW1l
IHZpZGVvLiANCj4gDQo+IFRoaXMgd2FzIGV4YWN0bHkgd2hhdCBjYW1lIHRvIG15IG1pbmQgZmly
c3QgdXAuIA0KPiANCj4gPiBPYnZpb3VzbHksIGlmIHlvdSBoYXZlIHBvd2VyIGFuZCBuZXR3b3Jr
IGJhbmR3aWR0aCB0byBkbyB2aWRlbywgeW91IA0KPiA+IGFyZSBub3QgdGhhdCBjb25zdHJhaW5l
ZC4NCj4gPiBCdXQgSSBjb3VsZCBzdGlsbCBpbWFnaW5lIGEgbW9yZSBSRVNULXN0eWxlIHdheSB0
byBjb250cm9sIHRoZSANCj4gdmlkZW8gc3RyZWFtcy4NCj4gDQo+IE1vZGVsaW5nIHJlYWwtdGlt
ZSBzdHJlYW1pbmcgYXMgUkVTVGZ1bCBleGNoYW5nZSBpcyByZWFsbHkgYSBnb29kIA0KPiBwcm9w
b3NpdGlvbi4gQnV0LCBoYXMgYW55b25lIGRvbmUgYW55IHN0dWR5IChtYXkgYmUgdmVyeSBzcGVj
aWZpYyB0bw0KPiBzb21lIHVzZWNhc2UpIHJlZ2FyZGluZyB3aGV0aGVyIHRoZXJlIGlzIGFueSBz
Y2VuYXJpbyB3aGVyZSBleGlzdGluZw0KPiBzdHVmZnMgbGlrZSBSVFAgbWF5IG5vdCBiZSBhIGdv
b2QgY2hvaWNlIGFuZCB3b3VsZCBuZWVkIHNvbWUgbmV3IA0KPiBsaWdodHdlaWdodCBzb2x1dGlv
biAobWF5IGJlIG9uIENvQVApPyBJdCBzZWVtcyBSZWFsLXRpbWUgdmlkZW8gDQo+IHN0cmVhbWlu
ZyBmb3IgSW9UIGFwcGxpY2F0aW9ucyBtYXkgZmluZCBnb29kICB0cmFjdGlvbiBpbiBmdXR1cmUg
DQo+IChub3QgeWV0IHN1cmUgYWJvdXQgZXhhY3QgdXNlY2FzZSBwZW9wbGUgbWF5IGhhdmUpLiAN
Cj4gDQo+IFdoYXQgSSBpbmZlcnJlZCBmcm9tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1sb3JldG8tY29yZS0NCj4gY29hcC1zdHJlYW1pbmctMDAgaXMgdGhhdCBpdCBpcyBiYXNp
Y2FsbHkgYSB2YXJpYXRpb24gb2YgYmxvY2std2lzZSANCj4gdHJhbnNmZXIgb3ZlciBDb0FQLCBi
dXQgd2l0aCBvYnNlcnZlIHJlbGF0aW9uc2hpcC4gVGhlIHNpemUgb2YgdGhlIA0KPiBibG9jayAo
Y2h1bmspIGlzIG5vdCBuZWdvdGlhdGVkIHRob3VnaC4gUHJvYmFibHkgaXQgaXMgYXNzdW1lZCB0
aGF0IA0KPiBjaHVuay1zaXplIGhhcyBkaXJlY3QgbWFwcGluZyB3aXRoIHRoZSBFbmNvZGVyIGNo
b3NlbiBhZnRlciB0aGUgDQo+IGRpc2NvdmVyIHBoYXNlLig/KSANCj4gDQo+IFJlZ2FyZHMNCj4g
QWJoaWphbiBCaGF0dGFjaGFyeXlhDQo+IEFzc29jaWF0ZSBDb25zdWx0YW50DQo+IFNjaWVudGlz
dCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQo+IFRhdGEgQ29uc3VsdGFuY3kgU2Vy
dmljZXMNCj4gTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbQ0KPiBXZWJzaXRl
OiBodHRwOi8vd3d3LnRjcy5jb20NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4gRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgICAgICBJVCBTZXJ2aWNlcw0K
PiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KPiAgICAgICAgICAg
ICAgICAgICAgICAgIENvbnN1bHRpbmcNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18gDQo+IA0KPiAiY29yZSIgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gd3Jv
dGUgb24gMTAvMzAvMjAxNCAwMTo0OTowMSBBTToNCj4gDQo+ID4gRnJvbTogQ2Fyc3RlbiBCb3Jt
YW5uIDxjYWJvQHR6aS5vcmc+IA0KPiA+IFRvOiBwYWR1ZmZ5QGNpc2NvLmNvbSANCj4gPiBDYzog
Y29yZUBpZXRmLm9yZyANCj4gPiBEYXRlOiAxMC8zMC8yMDE0IDAxOjQ5IEFNIA0KPiA+IFN1Ympl
Y3Q6IFJlOiBbY29yZV0gUmVhbCBUaW1lIFZpZGVvIG92ZXIgQ29BUD8gDQo+ID4gU2VudCBieTog
ImNvcmUiIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IA0KPiA+IA0KPiA+ID4gSG93IGRvIFJUUCBh
bmQgUlRTUCBub3QgbWVldCB5b3VyIG5lZWRzPw0KPiA+IA0KPiA+IFJUUCBpcyBhY3R1YWxseSBh
IGdyZWF0IHByb3RvY29sIGZvciBzdHJlYW1pbmcgcmVhbC10aW1lIHZpZGVvLg0KPiA+IA0KPiA+
IEnigJltIG5vdCBzdXJlIHRoYXQgUlRTUCBpcyBzdWNoIGEgZ3JlYXQgbWF0Y2ggaW4gYSBtb3Jl
IGNvbnN0cmFpbmVkIA0KPiA+IGVudmlyb25tZW50Lg0KPiA+IChBbmQgd2hpY2ggUlRTUCBkbyB5
b3UgbGlrZSDigJQgMS4wIG9yIDIuMD8pDQo+ID4gT2J2aW91c2x5LCBpZiB5b3UgaGF2ZSBwb3dl
ciBhbmQgbmV0d29yayBiYW5kd2lkdGggdG8gZG8gdmlkZW8sIHlvdSANCj4gPiBhcmUgbm90IHRo
YXQgY29uc3RyYWluZWQuDQo+ID4gQnV0IEkgY291bGQgc3RpbGwgaW1hZ2luZSBhIG1vcmUgUkVT
VC1zdHlsZSB3YXkgdG8gY29udHJvbCB0aGUgDQo+IHZpZGVvIHN0cmVhbXMuDQo+ID4gDQo+ID4g
R3LDvMOfZSwgQ2Fyc3Rlbg0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+ID4gY29yZSBtYWlsaW5nIGxpc3QNCj4gPiBjb3JlQGlldGYu
b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+ID09
PT09LS0tLS09PT09PS0tLS0tPT09PT0NCj4gTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp
bmVkIGluIHRoaXMgZS1tYWlsDQo+IG1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1h
eSBjb250YWluIA0KPiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYg
eW91IGFyZSANCj4gbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9u
LCB1c2UsIA0KPiByZXZpZXcsIGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0
aGUgDQo+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIA0KPiBh
bmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIA0KPiB5
b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIA0KPiBwbGVhc2Ug
bm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kIA0KPiBpbW1lZGlhdGVs
eSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIA0KPiBhbmQgYW55IGF0dGFjaG1l
bnRzLiBUaGFuayB5b3UNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg==
--=_alternative 0033C9D165257D82_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoZXJlIGFyZSByZXF1aXJlbWVudHMgZm9yIHJlYWwtdGlt
ZSBtb25pdG9yaW5nDQphbmQgdHJhbnNmZXJpbmc7IDwvZm9udD48L3R0Pg0KPGJyPjxmb250IHNp
emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGF0IHdpbGwgYWxzbyBiZSBteSB0YWtlLiBCdXQgd2Ug
bmVlZA0KdG8ga25vdyBob3cgY3VycmVudCBzdGF0ZS1vZi10aGUtYXJ0IChsaWtlIFJUUCkgZmFy
ZXMuIE1heSBiZSBhIHNvbHV0aW9uDQpvdmVyIENvQVAgd2lsbCBnZXQgcmlkIG9mIGFueSBjb25u
ZWN0aW9uIGVzdGFibGlzaG1lbnQgb3ZlcmhlYWQgYW5kIHRydWVseQ0KcmVhbC10aW1lIHRoYW4g
UlRQPyBUaGF0IGlzIHdoYXQgSSBmZWx0IGxvb2tpbmcgYXQgdGhlIENvQVAgU3RyZWFtaW5nIGRy
YWZ0Lg0KPGJyPg0KPGJyPg0KUmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4N
CkFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29s
a2F0YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KTWFpbHRvOiBh
YmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxicj4NCldlYnNpdGU6IDwvZm9udD48YSBocmVm
PWh0dHA6Ly93d3cudGNzLmNvbS8+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6
Ly93d3cudGNzLmNvbTwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxi
cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRXhw
ZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2Vz
PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4N
CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxm
b250IHNpemU9Mj4mcXVvdDt3ZWlnZW5neXUmcXVvdDsgJmx0O3dlaWdlbmd5dUBidXB0LmVkdS5j
biZndDsNCndyb3RlIG9uIDEwLzMwLzIwMTQgMDU6NTA6MTMgUE06PGJyPg0KPGJyPg0KJmd0OyBG
cm9tOiAmcXVvdDt3ZWlnZW5neXUmcXVvdDsgJmx0O3dlaWdlbmd5dUBidXB0LmVkdS5jbiZndDs8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVG86ICZxdW90O0NhcnN0ZW4g
Qm9ybWFubiZxdW90OyAmbHQ7Y2Fib0B0emkub3JnJmd0OywNCiZxdW90O0FiaGlqYW4gQmhhdHRh
Y2hhcnl5YSZxdW90OyA8YnI+DQomZ3Q7ICZsdDthYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv
bSZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQ2M6ICZsdDtjb3Jl
QGlldGYub3JnJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBEYXRl
OiAxMC8zMC8yMDE0IDA1OjUwIFBNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7IFN1YmplY3Q6IFJlOiBbY29yZV0gUmVhbCBUaW1lIFZpZGVvIG92ZXIgQ29BUD88L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBIae+8jCA8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IElmIHRoZSBDb0FQIHNlcnZlciBpcyBzdXBwb3NlZCB0byBo
YXZlIGVub3VnaA0KY2FwYWJpbGl0aWVzIGluIHRlcm1zIDxicj4NCiZndDsgb2YgcG93ZXIgYW5k
IHdpcmVsZXNzIGxpbmssPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHRy
YW5mZXJpbmcgc3RyZWFtaW5nIGRhdGEgc2hvdWxkIGJlIGNvbnNpZGVyZWQuDQo8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQW5kLCBzdXBwb3J0aW5nIHdoYXQga2luZCBv
ZiB0cmVhbWluZyBkYXRhIHNob3VsZA0KYmUgYmFzZWQgb24gdXNhZ2UgPGJyPg0KJmd0OyBzY2Vu
YXJpb3MuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhpcyBvcGluaW9uIGlzIGJhc2Vk
IGEgd29yayBzZXJ2ZXJhbCB5ZWFycyBhZ28uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj4mZ3Q7IFRoZSB3b3JrIGlzIHRvIGRldmVsb3AgYSBjb21tdW5pY2F0aW9uIHNvZnR3YXJl
DQpiZXR3ZWVuIGEgd2F0Y2ggYW5kIDxicj4NCiZndDsgYSBzbWFydCBtb2JpbGVwaG9uZS4gPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoZSB3YXRjaCBjYW4gdHJhbnNm
ZXIgYSBmaWxlIG9mIGVsZWN0cm9jYXJkaW9ncmFtDQp0byB0aGUgc21hcnQgPGJyPg0KJmd0OyBt
b2JpbGVwaG9uZSBhZnRlciBmaW5pc2hpbmcgZGV0ZWN0aW9uLiA8L2ZvbnQ+PC90dD4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhlcmUgYXJlIHJlcXVpcmVtZW50cyBmb3IgcmVhbC10aW1l
IG1vbml0b3JpbmcNCmFuZCB0cmFuc2ZlcmluZzsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj4mZ3Q7IGJ1dCwgYXQgdGhhdCB0aW1lIGl0IHdhcyByZWdhcmRlZCAmbmJzcDtpbnZh
bGlkDQp0byBkZWxpdmVyIHJlYWwgdGltZSBkYXRhPGJyPg0KJmd0OyBkdWUgdGhlIHBvd2VyIGFu
ZCB3aXJlbGVzcyBsaW5rIGNhcGFjaXR5LiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEJl
c3QgcmVnYXJkcyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEdlbmd5dSBXRUk8YnI+DQom
Z3Q7IE5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXI8YnI+DQomZ3Q7IFNjaG9vbCBvZiBDb21wdXRl
ciA8YnI+DQomZ3Q7IEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmlj
YXRpb25zPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9u
dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBBYmhpamFuIEJoYXR0YWNo
YXJ5eWEgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFNlbnQ6IFRodXJz
ZGF5LCBPY3RvYmVyIDMwLCAyMDE0IDU6NTMgUE08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgVG86IENhcnN0ZW4gQm9ybWFubiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgQ2M6IGNvcmUgOyBjb3JlQGlldGYub3JnIDwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTdWJqZWN0OiBSZTogW2NvcmVdIFJlYWwgVGltZSBWaWRl
byBvdmVyIENvQVA/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw
OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7ICZndDsgSG93IGRv
IFJUUCBhbmQgUlRTUCBub3QgbWVldCB5b3VyIG5lZWRzPzxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgUlRQIGlzIGFjdHVhbGx5IGEgZ3JlYXQgcHJvdG9jb2wgZm9yIHN0cmVhbWluZyBy
ZWFsLXRpbWUgdmlkZW8uDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyB3YXMgZXhhY3RseSB3
aGF0IGNhbWUgdG8gbXkgbWluZCBmaXJzdCB1cC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg
T2J2aW91c2x5LCBpZiB5b3UgaGF2ZSBwb3dlciBhbmQgbmV0d29yayBiYW5kd2lkdGggdG8gZG8g
dmlkZW8sDQp5b3UgPGJyPg0KJmd0OyAmZ3Q7IGFyZSBub3QgdGhhdCBjb25zdHJhaW5lZC48YnI+
DQomZ3Q7ICZndDsgQnV0IEkgY291bGQgc3RpbGwgaW1hZ2luZSBhIG1vcmUgUkVTVC1zdHlsZSB3
YXkgdG8gY29udHJvbCB0aGUNCjxicj4NCiZndDsgdmlkZW8gc3RyZWFtcy48YnI+DQomZ3Q7IDxi
cj4NCiZndDsgTW9kZWxpbmcgcmVhbC10aW1lIHN0cmVhbWluZyBhcyBSRVNUZnVsIGV4Y2hhbmdl
IGlzIHJlYWxseSBhIGdvb2QNCjxicj4NCiZndDsgcHJvcG9zaXRpb24uIEJ1dCwgaGFzIGFueW9u
ZSBkb25lIGFueSBzdHVkeSAobWF5IGJlIHZlcnkgc3BlY2lmaWMNCnRvPGJyPg0KJmd0OyBzb21l
IHVzZWNhc2UpIHJlZ2FyZGluZyB3aGV0aGVyIHRoZXJlIGlzIGFueSBzY2VuYXJpbyB3aGVyZSBl
eGlzdGluZzxicj4NCiZndDsgc3R1ZmZzIGxpa2UgUlRQIG1heSBub3QgYmUgYSBnb29kIGNob2lj
ZSBhbmQgd291bGQgbmVlZCBzb21lIG5ldyA8YnI+DQomZ3Q7IGxpZ2h0d2VpZ2h0IHNvbHV0aW9u
IChtYXkgYmUgb24gQ29BUCk/IEl0IHNlZW1zIFJlYWwtdGltZSB2aWRlbyA8YnI+DQomZ3Q7IHN0
cmVhbWluZyBmb3IgSW9UIGFwcGxpY2F0aW9ucyBtYXkgZmluZCBnb29kICZuYnNwO3RyYWN0aW9u
IGluIGZ1dHVyZQ0KPGJyPg0KJmd0OyAobm90IHlldCBzdXJlIGFib3V0IGV4YWN0IHVzZWNhc2Ug
cGVvcGxlIG1heSBoYXZlKS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoYXQgSSBpbmZlcnJlZCBm
cm9tIDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1sb3JldG8tY29yZS0iPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWxvcmV0by1jb3JlLTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxi
cj4NCiZndDsgY29hcC1zdHJlYW1pbmctMDAgaXMgdGhhdCBpdCBpcyBiYXNpY2FsbHkgYSB2YXJp
YXRpb24gb2YgYmxvY2std2lzZQ0KPGJyPg0KJmd0OyB0cmFuc2ZlciBvdmVyIENvQVAsIGJ1dCB3
aXRoIG9ic2VydmUgcmVsYXRpb25zaGlwLiBUaGUgc2l6ZSBvZiB0aGUNCjxicj4NCiZndDsgYmxv
Y2sgKGNodW5rKSBpcyBub3QgbmVnb3RpYXRlZCB0aG91Z2guIFByb2JhYmx5IGl0IGlzIGFzc3Vt
ZWQgdGhhdA0KPGJyPg0KJmd0OyBjaHVuay1zaXplIGhhcyBkaXJlY3QgbWFwcGluZyB3aXRoIHRo
ZSBFbmNvZGVyIGNob3NlbiBhZnRlciB0aGUgPGJyPg0KJmd0OyBkaXNjb3ZlciBwaGFzZS4oPykg
Jm5ic3A7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7IFJlZ2FyZHM8YnI+DQomZ3Q7IEFiaGlq
YW4gQmhhdHRhY2hhcnl5YTxicj4NCiZndDsgQXNzb2NpYXRlIENvbnN1bHRhbnQ8YnI+DQomZ3Q7
IFNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhPGJyPg0KJmd0OyBUYXRh
IENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KJmd0OyBNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hh
cnl5YUB0Y3MuY29tPGJyPg0KJmd0OyBXZWJzaXRlOiA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHA6
Ly93d3cudGNzLmNvbS8+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LnRjcy5jb208L2ZvbnQ+
PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBFeHBlcmllbmNlIGNlcnRhaW50eS4g
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8YnI+DQomZ3Q7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOw0KJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiZndDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7DQombmJzcDsgJm5ic3A7Q29uc3VsdGluZzxicj4NCiZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90O2Nv
cmUmcXVvdDsgJmx0O2NvcmUtYm91bmNlc0BpZXRmLm9yZyZndDsgd3JvdGUgb24gMTAvMzAvMjAx
NA0KMDE6NDk6MDEgQU06PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgRnJvbTogQ2Fyc3RlbiBC
b3JtYW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7IDxicj4NCiZndDsgJmd0OyBUbzogcGFkdWZmeUBj
aXNjby5jb20gPGJyPg0KJmd0OyAmZ3Q7IENjOiBjb3JlQGlldGYub3JnIDxicj4NCiZndDsgJmd0
OyBEYXRlOiAxMC8zMC8yMDE0IDAxOjQ5IEFNIDxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTog
W2NvcmVdIFJlYWwgVGltZSBWaWRlbyBvdmVyIENvQVA/IDxicj4NCiZndDsgJmd0OyBTZW50IGJ5
OiAmcXVvdDtjb3JlJnF1b3Q7ICZsdDtjb3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBIb3cgZG8gUlRQIGFuZCBSVFNQIG5vdCBtZWV0
IHlvdXIgbmVlZHM/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBSVFAgaXMgYWN0dWFs
bHkgYSBncmVhdCBwcm90b2NvbCBmb3Igc3RyZWFtaW5nIHJlYWwtdGltZSB2aWRlby48YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEnigJltIG5vdCBzdXJlIHRoYXQgUlRTUCBpcyBzdWNo
IGEgZ3JlYXQgbWF0Y2ggaW4gYSBtb3JlIGNvbnN0cmFpbmVkDQo8YnI+DQomZ3Q7ICZndDsgZW52
aXJvbm1lbnQuPGJyPg0KJmd0OyAmZ3Q7IChBbmQgd2hpY2ggUlRTUCBkbyB5b3UgbGlrZSDigJQg
MS4wIG9yIDIuMD8pPGJyPg0KJmd0OyAmZ3Q7IE9idmlvdXNseSwgaWYgeW91IGhhdmUgcG93ZXIg
YW5kIG5ldHdvcmsgYmFuZHdpZHRoIHRvIGRvIHZpZGVvLA0KeW91IDxicj4NCiZndDsgJmd0OyBh
cmUgbm90IHRoYXQgY29uc3RyYWluZWQuPGJyPg0KJmd0OyAmZ3Q7IEJ1dCBJIGNvdWxkIHN0aWxs
IGltYWdpbmUgYSBtb3JlIFJFU1Qtc3R5bGUgd2F5IHRvIGNvbnRyb2wgdGhlDQo8YnI+DQomZ3Q7
IHZpZGVvIHN0cmVhbXMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBHcsO8w59lLCBD
YXJzdGVuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBjb3JlIG1haWxpbmcg
bGlzdDxicj4NCiZndDsgJmd0OyBjb3JlQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48
L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPjx0
dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl
PC9mb250PjwvdHQ+PC9hPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA9PT09PS0tLS0tPT09
PT0tLS0tLT09PT09PGJyPg0KJmd0OyBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg
aW4gdGhpcyBlLW1haWw8YnI+DQomZ3Q7IG1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0
IG1heSBjb250YWluIDxicj4NCiZndDsgY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt
YXRpb24uIElmIHlvdSBhcmUgPGJyPg0KJmd0OyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg
YW55IGRpc3NlbWluYXRpb24sIHVzZSwgPGJyPg0KJmd0OyByZXZpZXcsIGRpc3RyaWJ1dGlvbiwg
cHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWlu
ZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSA8YnI+DQomZ3Q7IGFuZC9vciBhdHRhY2htZW50cyB0
byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgPGJyPg0KJmd0OyB5b3UgaGF2ZSByZWNl
aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIDxicj4NCiZndDsgcGxlYXNlIG5vdGlm
eSB1cyBieSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCA8YnI+DQomZ3Q7IGltbWVkaWF0
ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgPGJyPg0KJmd0OyBhbmQgYW55
IGF0dGFjaG1lbnRzLiBUaGFuayB5b3U8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y
PiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQomZ3Q7IGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBjb3JlQGlldGYub3JnPGJyPg0KJmd0
OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vY29yZT48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vY29yZTwvZm9udD48L3R0PjwvYT4NCg==
--=_alternative 0033C9D165257D82_=--


From nobody Fri Oct 31 04:15:17 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E3F1A1A56 for ; Fri, 31 Oct 2014 04:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtcF63jvuHrB for ; Fri, 31 Oct 2014 04:15:09 -0700 (PDT)
Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8206B1A03A8 for ; Fri, 31 Oct 2014 04:15:07 -0700 (PDT)
X-ASG-Debug-ID: 1414754105-06daaa130c7d9f0001-aa7cYp
Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id RAuOh9I87SdOvgJA for ; Fri, 31 Oct 2014 07:15:05 -0400 (EDT)
X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com
Received: from interdigital.com ([10.0.128.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 31 Oct 2014 07:15:04 -0400
Received: from KYANITE.InterDigital.com ([10.1.64.253]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 31 Oct 2014 07:15:04 -0400
Received: from NALENITE.InterDigital.com (10.2.64.253) by KYANITE.InterDigital.com (10.1.64.253) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 31 Oct 2014 07:15:03 -0400
Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0210.002; Fri, 31 Oct 2014 07:15:03 -0400
From: "Rahman, Akbar" 
To: "core@ietf.org" 
Thread-Topic: Group Communication published as RFC 7390
X-ASG-Orig-Subj: Group Communication published as RFC 7390
Thread-Index: Ac/0+7S3LtGeIPJdQa6cxMGPmNNqiw==
Date: Fri, 31 Oct 2014 11:15:02 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F05AADF@NABESITE.InterDigital.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.247.200]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Oct 2014 11:15:04.0421 (UTC) FILETIME=[EBA12950:01CFF4FB]
X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27]
X-Barracuda-Start-Time: 1414754105
X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at interdigital.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.11072 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Archived-At: http://mailarchive.ietf.org/arch/msg/core/X6tynpOmumBdz2x_epHPYU1kMMg
Subject: [core] Group Communication published as RFC 7390
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 31 Oct 2014 11:15:14 -0000

FYI - As you may have noticed Groupcomm was just published as RFC 7390:

http://tools.ietf.org/html/rfc7390


 Thanks to Carsten, Zach and the many people in the WG who have supported u=
s along the way.


Best Regards,


Akbar & Esko


-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of rfc-editor@rfc-edito=
r.org
Sent: Thursday, October 30, 2014 8:16 PM
To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.org; core@ietf.org; rfc-editor@rfc-editor.org
Subject: [core] RFC 7390 on Group Communication for the Constrained Applica=
tion Protocol (CoAP)

A new Request for Comments is now available in online RFC libraries.

       =20
        RFC 7390

        Title:      Group Communication for the Constrained=20
                    Application Protocol (CoAP)=20
        Author:     A. Rahman, Ed.,
                    E. Dijk, Ed.
        Status:     Experimental
        Stream:     IETF
        Date:       October 2014
        Mailbox:    Akbar.Rahman@InterDigital.com,=20
                    esko.dijk@philips.com
        Pages:      46
        Characters: 106675
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-core-groupcomm-25.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7390.txt

The Constrained Application Protocol (CoAP) is a specialized web transfer p=
rotocol for constrained devices and constrained networks.
It is anticipated that constrained devices will often naturally operate in =
groups (e.g., in a building automation scenario, all lights in a given room=
 may need to be switched on/off as a group).
This specification defines how CoAP should be used in a group communication=
 context.  An approach for using CoAP on top of IP multicast is detailed ba=
sed on existing CoAP functionality as well as new features introduced in th=
is specification.  Also, various use cases and corresponding protocol flows=
 are provided to illustrate important concepts.  Finally, guidance is provi=
ded for deployment in various network topologies.

This document is a product of the Constrained RESTful Environments Working =
Group of the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet c=
ommunity.  It does not specify an Internet standard of any kind. Discussion=
 and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search For dow=
nloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the author =
of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless specifical=
ly noted otherwise on the RFC itself, all RFCs are for unlimited distributi=
on.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


From nobody Fri Oct 31 05:05:14 2014
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8059A1A8A4A for ; Fri, 31 Oct 2014 05:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tau7hEi9ZDy for ; Fri, 31 Oct 2014 05:05:10 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319881A8A5A for ; Fri, 31 Oct 2014 05:05:10 -0700 (PDT)
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 mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9VC5674002544; Fri, 31 Oct 2014 13:05:06 +0100 (CET)
Received: from alma.local.informatik.uni-bremen.de (robin.informatik.uni-bremen.de [134.102.218.1]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5346D329; Fri, 31 Oct 2014 13:05:06 +0100 (CET)
X-Mailer: emacs 25.0.50.1 (via feedmail 11-beta-1 I)
From: Carsten Bormann 
To: "Rahman\, Akbar" 
References: <36F5869FE31AB24485E5E3222C288E1F05AADF@NABESITE.InterDigital.com>
Date: Fri, 31 Oct 2014 13:04:54 +0100
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F05AADF@NABESITE.InterDigital.com> (Akbar Rahman's message of "Fri, 31 Oct 2014 11:15:02 +0000")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/core/lLLYclx53v7_HeZCqfl2V1xMQ10
Cc: "core@ietf.org" 
Subject: Re: [core] Group Communication published as RFC 7390
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 31 Oct 2014 12:05:12 -0000

"Rahman, Akbar"  writes:

> http://tools.ietf.org/html/rfc7390

Thanks, Akbar and Esko, for keeping up the flame on this subject!

I have seen considerable interest in making group communication over
CoAP more useful, and this document is a good first start.
I expect that more people will come to the IETF with work in this area.

Gruesse, Carsten