From weigengyu@bupt.edu.cn Sat Nov 2 06:16:13 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD72B21E80C3 for ; Sat, 2 Nov 2013 06:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPY3auC9rucx for ; Sat, 2 Nov 2013 06:16:08 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 53CE121E80C1 for ; Sat, 2 Nov 2013 06:15:51 -0700 (PDT) Received: from WeiGengyuPC (unknown [221.218.43.3]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id B2E5719F372; Sat, 2 Nov 2013 21:15:48 +0800 (HKT) Message-ID: <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> From: "weigengyu" To: "Dijk, Esko" , References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl> <031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Sat, 2 Nov 2013 21:15:47 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: Core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 13:16:13 -0000 Hi, Esko I would like to give some comments on the GROUP-COMM draft. There have use cases for reliable and unreliable multicast communications. If this draft only for providing unreliable multicast over IP multicast, it is OK; just write it clearly. If the draft intends to have the reliable or partial multicast facility, the dtaft needs to give what mechanisms can gurantte that. The draft should define mechnisms that the server can register its capability of supporting multicast, this may be put to RD server; and wether to request reliable groupcomm shoule be the client's request. > To clarify: under the assumption that a server MAY respond to a multicast > request, A mechanism is required to make the server registers its capability. i.e. whether to support multicast; > and the client doesn't know a priori how many servers will respond to a > multicast, The client may lookup the information from the RD server (if the rerver's registeration processe were possible); > (since there are no guidelines/rules for that), the safest thing to do is > not send the multicast in the first place. If not first, when to make available? So, whether it is required should be determined by the client request, and there should have some authority or priority control to client. > Therefore the advice is to carefully control sending of multicast > requests. Not only to tell that, the draft should have clear descriptions about how the protocol supports multicast requiests and/or reliable multicast when required. regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Dijk, Esko Sent: Thursday, December 20, 2012 6:56 PM To: consultancy@vanderstok.org Cc: Core Subject: Re: [core] group-comm comments Thanks Peter, I would agree we need to include guidelines on returning of responses to CoAP multicast requests. (Note the CoAP spec ensures that a CoAP server will never ACK a multicast but that does not help a thing if it still sends a response packet...) I'll make a ticket for this. If anyone disagrees we'll hear it. > Then I do not understand the text, because "request", "reply" and > "response" are overloaded in my mind. To clarify: under the assumption that a server MAY respond to a multicast request, and the client doesn't know a priori how many servers will respond to a multicast, (since there are no guidelines/rules for that), the safest thing to do is not send the multicast in the first place. Therefore the advice is to carefully control sending of multicast requests. Esko -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: Thursday 20 December 2012 11:26 To: Dijk, Esko Cc: consultancy@vanderstok.org; akbar rahman; Core Subject: RE: group-comm comments Hi Esko, thanks for your reactions. I will group my answers, to better explain my points on the return of packets to MC senders. 1) Return of packets to multicast As I understand the multicast message is preferably sent with no confirmation (ack) because the return of all the acks may overwhelm the network and the sender of the multicast. The acknowledgement is not needed for MPL as the protocol has all the machinery to assure that all destinations receive it, (given constraints on network load and configuration density and size). Supposing an ack is needed, then it would be advisable to staffle the responses and an additional acknowledgement protocol could be added to the multicast protocol. The same is true if a message is returned (as in the case of mDNS). One can then wonder whether the application protocol (e.g. mDNS) should take care of the staffled response or that an additional protocol needs to be specified. I have no opinion on the choice, but see the need for the one or the other. Coming with a recommendation (explanation) on the subject of returning responses (acks) would be my recommendation for the GroupComm document. Below some reactions on your reactions. Hope this helps to clarify misunderstandings. Peter Dijk, Esko schreef op 2012-12-19 14:24: > Hi Peter, > > still a fair number of comments! I would agree with most. Below I have > selected some which we should discuss further, or ones I don’t agree > with: > > 1. Group communication definition -> > Why can't a source node be part of the group that it sends to? E.g. > combined sensor+luminaire use case. The IP stack would deliver sent > multicast CoAP requests also to the local application if it is > subscribed to the multicast IP address. source can of course be member of destination group. source may be part of the group (remove the "or may be not" part of the phrase) > > 2. I don’t see why we should add “the use of group communication for > mDNS is out of scope.” -> mDNS obviously is not CoAP, and the > document should define the scope anyway clearly as CoAP group > communication. So we don’t have to list any other protocols than CoAP. See my answer on return of packets. I wanted a clear statement on (NOT) specifying how applications handle the return of MC responses. > > 3. “so setting a multicast address in a source at installation is > forbidden?” -> No, that should not be forbidden :) It should also be > possible to set a CoAP path and/or port at installation time. That > means the two presented measures have to change or be removed. No comment > > 4. “there are 2 ways: (1) the node queries to which group it belongs > or (2) an instalation tools instructs the node to which groups” -> > Good point. (2) has been chosen because it works without relying on a > service to query (e.g. DNS or RD). Is that sufficient argumentation? > The mechanism is optional in any case so it does not block others from > defining a DNS or RD variant. I would point out both variants and mention that the draft focusses on (2) > > 5. “/s requests /s replies” -> > multicast replies (if you mean responses) do not exist in CoAP. It’s > about requests that should be carefully controlled since they generate > unicast responses. Then I do not understand the text, because "request", "reply" and "response" are overloaded in my mind. > > 6. “/comment what about the reply?” -> based on core-coap “If the > request message is Non-confirmable, then the response SHOULD be > returned in a Non-confirmable message as well.” > . Do you think we should quote this from the core-coap spec? As explained above The subject of returning packets to the MC sender needs careful consideration. the response being NOn-confirmable does not solve a lot I am afraid. > > 7. “/comment invoking as many certificates?” -> > core-coap-13 now loosens the concept of authentication to also > include other measures, not needing certificates. No comment > > 8. Network configuration: 2 subnets vs 1 -> maybe a one-subnet > configuration is worth adding? Here an overview of present/absent use > cases: > > - Link-local CoAP multicast with responses: Present, Appendix A of > core-coap > - Site-local CoAP multicast, single subnet: > - Site-local CoAP multicast, multi subnet, with or without responses > (in the new -04 groupcomm): Present > - Global CoAP multicast, single or multi subnet, with or without > responses: / dependency on IANA IPv6 allocation > - any configurations with a central controller on the backbone > multicasting: Again, the draft should go for the most frequent use cases and not try to be complete. Actually explicitly excluding use cases looks ineresting to me. > > 9. “It might be useful if the practical impossibility of some > configurations is high lighted” -> any thoughts, which would be > impossible? During the coap meeting in Atlanta, Cullen Jennings presented some horrifying examples, as far as I remember. > > 10.“the RD discovery will be more complex when there is a router > between light-2 and switch” -> yes, there are issues in RD/discovery > especially when more than one is present in a network. So, adapt the use case and exclude this possibility. > > 11.“additional reason to remove router from the multicast > configuration”-> hmm, I think that we should opt for having a single > RD in the system to avoid complexity. Routers are ok. (One of our > goals is to define how CoAP groupcomm works even across routers) Looking forward to the supporting protocol. > > 12.“MLD is used to form groups, correct? but that was already done by > enabling the MC address in the lights (point 2)” -> Step 1 is putting > the MC address in the lights, then step 2 is the Lights use MLD to > *ADVERTIZE* this address to any MLD-enabled Routers present > link-local. > So MLD is not a commissioning-time protocol but runs all the time > during operation. > Note that in groupcomm -04 we will remove MLD in the basic use case > and present it as an option later. Sounds good. The point is not to add protocols because they exist but because they are needed. > > 13.“WHY are the multicast destinations sending back results?” -> we > remove responses in the new -04 groupcomm. They are presented as an > optional thing that servers can do. > CoAP servers normally MUST respond to a request with a response > (core-coap-13) but an exception is now made for multicast where a > server MAY choose not to. This choice is completely independent from > confirmable/non-confirmable. Non-confirmable only means that an ACK > must not be sent. And an ACK is something different from a CoAP > response. > Agree that a protocol like MPL comes very close to ‘reliable > multicast’. see my worries at the beginning. > > Esko > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Tuesday 18 December 2012 12:06 > To: akbar rahman; Dijk, Esko; Core > Subject: group-comm comments > > Hi Akbar and Esko, > > I had promised to review, comment the group comm draft. > > Below the commented text. > > I have not gone very detailed with my comments. I hope that it is > clear from my comments that a reorganization of the draft and a review > of the uses cases are necessary to get a clearer picture of the > feasibility of group comm in the context of Coap. > > Especialy difficult to understand for me were: > > - the use case network configuration > > - the forming and enabling of groups > > - use of responses > > Hope this helps. > > Greetings, > > peter > > ______________________________________________________________________ > _______________________________ > > > Abstract > > CoAP is a RESTful transfer protocol for constrained devices. 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 document > > defines how the CoAP protocol should be used in a group communication > > context. An approach for using CoAP on top of IP multicast is > > detailed for both constrained and un-constrained networks. Also, > > various use > > /s causes /s cases/ > > and corresponding protocol flows are provided to > > illustrate important concepts. Finally, guidance is provided for > > deployment in various network topologies. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF). Note that other groups may also distribute > > working documents as Internet-Drafts. The list of current Internet- > > Drafts is at http://datatracker.ietf.org/drafts/current/ [1]. > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on April 22, 2013. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > > Provisions Relating to IETF Documents > > (http://trustee.ietf.org/license-info [2]) in effect on the date of > > Rahman & Dijk Expires April 22, 2013 [Page > > 1] > > Internet-Draft Group Communication for CoAP October > > 2012 > > publication of this document. Please review these documents > > carefully, as they describe your rights and restrictions with respect > > to this document. Code Components extracted from this document must > > include Simplified BSD License text as described in Section 4.e of > > the Trust Legal Provisions and are provided without warranty as > > described in the Simplified BSD License. > > 1. Conventions and Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > > This document assumes readers are familiar with the terms and > > concepts that are used in [I-D.ietf-core-coap]. In addition, this > > document defines the following terminology: > > Group Communication > > A source node sends a single message which is delivered to > > multiple destination nodes, where all destinations are identified > > to belong to a specific group. The source node may > > /remove or may not > > be > > part of the group. The underlying mechanism for group > > communication is assumed to be multicast based. > > /remove > > The network where > > the group communication takes place can be either a constrained > > or > > a regular (un-constrained) network/ > > /comment not sure about the meaning and consequences > > Multicast > > Sending a message to multiple destination nodes > > /s simultaneously./ > > /s with one network invocation / > > There are various options to implement multicast including layer > > 2 > > (Media Access Control) or layer 3 (IP) mechanisms. > > IP Multicast > > A specific multicast solution based on the use of IP multicast > > addresses as defined in "IANA Guidelines for IPv4 Multicast > > Address Assignments" [RFC5771] and "IP Version 6 Addressing > > Architecture" [RFC4291]. > > Low power and Lossy Network (LLN) > > Low power and Lossy Network (LLN): A type of constrained network > > where the devices are interconnected by a variety of low power, > > lossy links such as IEEE 802.15.4, Bluetooth, > > WiFi, wired > > or low > > power power-line communication links. > > 2. Introduction > > 2.1. Background > > The Constrained Application Protocol (CoAP) is an application > > protocol (analogous to HTTP) for resource constrained devices > > operating in an IP network [I-D.ietf-core-coap]. Constrained > > devices > > can be large in number, but are often highly correlated to each > > other > > (e.g. by type or location). For example, all the light switches in > > a > > building may belong to one group and all the thermostats may belong > > to another group. Groups may be composed by function. For example, > > Rahman & Dijk Expires April 22, 2013 [Page > > 3] > > Internet-Draft Group Communication for CoAP October > > 2012 > > the group "all lights in building one" may consist of the groups > > "all > > lights on floor one of building one", "all lights on floor two of > > building one", etc. Groups may be preconfigured > > /add before deployment > > or dynamically > > formed > > /add during operation > > . If information needs to be sent to or received from a group > > of devices, group communication mechanisms can improve efficiency > > and > > latency of communication and reduce bandwidth requirements for a > > given application. HTTP does not support any equivalent > > functionality to CoAP group communication. > > 2.2. Scope > > In this draft, we address the issues related to CoAP group > > communication in detail, with use cases, recommended approaches and > > analysis of the impact to the CoAP protocol and to implementations. > > /add the use of group communication for mDNS is out of scope. > > The guiding principle is to apply wherever possible existing IETF > > protocols to achieve group communication functionality. In many > > cases the contribution of this document lies in explaining how > > existing mechanisms may be used to > > /remove together > > fulfill CoAP group > > communication needs for specific use cases. > > 2.3. Potential Solutions for Group Communication > > The classic concept of group > > /s communications /s communication > > is that of a single > > source distributing content to multiple destination recipients that > > are all part of a group. Before content can be distributed, there > > is > > a separate process to form the group. The source may be either a > > member or non-member of the group. > > Group communication solutions have evolved from "bottom" to "top", > > i.e., from layer 2 (Media Access Control broadcast/multicast) and > > layer 3 (IP multicast) to application layer group communication, > > also > > referred to as application layer multicast. A study published in > > 2005 [Lao05] identified new solutions in the "middle" (referred to > > as > > overlay multicast) that utilize an infrastructure based on proxies. > > Each of these classes of solutions may be compared [Lao05] using > > metrics such as link stress and level of host complexity > > [Banerjee01]. The results show for a realistic internet topology > > that IP Multicast is the most resource-efficient, with the downside > > being that it requires > > /s the most /s more organizational > > effort to deploy in the > > infrastructure. IP Multicast is the solution adopted by this draft > > for CoAP group communication. > > 3. CoAP Group Communication Based On IP Multicast > > Rahman & Dijk Expires April 22, 2013 [Page > > 4] > > Internet-Draft Group Communication for CoAP October > > 2012 > > 3.1. IP Multicast Background > > IP Multicast routing protocols have been evolving for decades, > > resulting in proposed standards such as Protocol Independent > > Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various > > technical and marketing reasons, IP Multicast routing is not widely > > deployed on the general Internet. However, IP Multicast is very > > popular in specific deployments such as in enterprise networks (e.g. > > for video conferencing), smart home networks (e.g. UPnP/mDNS) and > > carrier IPTV deployments. The packet economy and minimal host > > complexity of IP multicast make it attractive for group > > communication > > in constrained environments. Therefore IP multicast is the > > recommended underlying mechanism for CoAP group communication, and > > the approach assumed in this document. > > To achieve IP multicast beyond a subnet, an IP multicast routing > > protocol needs to be active on routers. The RPL protocol [RFC6550] > > for example is able to route multicast traffic in constrained LLNs. > > While PIM-SM [RFC4601] is often used for multicast routing in un- > > constrained networks. > > IP multicast can also be run in a Link-Local (LL) scope. This means > > that there is no routing involved and an IP multicast message is > > only > > received > > /s on the network /s over the > > link on which it was sent. > > 3.2. CoAP Group Definition and Naming > > A group is defined as a set of CoAP endpoints, where each endpoint > > is > > configured to receive a multicast CoAP request that is sent to the > > group's associated IP multicast address. The group MAY have more > > than one associated IP multicast address. An endpoint MAY be a > > member of multiple groups. Group membership of an endpoint MAY > > dynamically change over time. The group MAY be identified by a > > Group > > Name ([I-D.vanderstok-core-dna]) which is defined as a prefix string > > of a Group FQDN. The Group FQDN can be uniquely mapped to a site- > > local or global multicast IP address via DNS resolution. > > A CoAP multicast request that addresses a group includes a Group URI > > as the request URI. A Group URI has the scheme 'coap' and includes > > in the authority part either a group IP address > > /add + optional port > > or a hostname > > /add + optional port > > that > > can be resolved to the group IP address (e.g., a Group Name or Group > > FQDN). Group URIs MUST follow the URI syntax [RFC3986]. > > A CoAP > > /s node /s end-point > > becomes a group member by listening for CoAP messages on > > the group's IP multicast address, assuming the default CoAP UDP > > port. > > Note that a non-default UDP port MAY be specified for the group; in > > which case implementers MUST ensure that all group members are > > configured to use this same port. > > Rahman & Dijk Expires April 22, 2013 [Page > > 5] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Examples of hierarchical group naming (and scoping) for a building > > control application are shown below. > > URI authority Targeted group > > all.bldg6.example.com "all nodes in building 6" > > all.west.bldg6.example.com "all nodes in west wing, building > > 6" > > all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, > > building 6" > > all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, > > west wing, building 6" > > Reverse mapping (from IP multicast address to group FQDN) is > > supported using the reverse DNS resolution technique > > ([I-D.vanderstok-core-dna]). > > 3.3. Group Discovery and Member Discovery > > CoAP defines a resource discovery capability, but does not yet > > specify how to discover groups (e.g. find a group to join or send a > > multicast message to) or to discover members of a group (e.g. to > > address selected group members by unicast). These topics are > > elaborated in more detail in [I-D.vanderstok-core-dna] including > > examples for using DNS-SD and CoRE Resource Directory. > > 3.3.1. DNS-SD > > DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a > > conventional way to configure DNS PTR, SRV, and TXT records to > > enable > > enumeration of services, such as services offered by CoAP nodes, or > > enumeration of all CoAP nodes, within specified subdomains. A > > service is specified by a name of the form > > .., where the service type for CoAP > > nodes is _coap._udp and the domain is a DNS domain name that > > identifies a group as in the examples above. For each CoAP > > end-point > > in a group, a PTR record with the name _coap._udp and/or a PTR > > record > > with the name _coap._udp. is defined and it points to an SRV > > record having the .. name. > > All CoAP nodes in a given subdomain may be enumerated by sending a > > query for PTR records named _coap._udp to the authoritative DNS > > server for that zone. A list of SRV records is returned. Each SRV > > record contains the port and host name (AAAA record) of a CoAP node. > > The IP address of the node is obtained by resolving the host name. > > DNS-SD also specifies an optional TXT record, having the same name > > as > > the SRV record, which can contain "key=value" attributes. This can > > be used to store information about the device, e.g. schema=DALI, > > type=switch, group=lighting.bldg6, etc. > > Rahman & Dijk Expires April 22, 2013 [Page > > 6] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Another feature of DNS-SD is the ability to specify service subtypes > > using PTR records. For example, one could represent all the CoAP > > groups in a subdomain by PTR records with the name > > _group._sub._coap._udp or alternatively > > _group._sub._coap._udp.. > > 3.3.2. CoRE Resource Directory > > CoRE Resource Directory [I-D.shelby-core-resource-directory] defines > > the concept of a Resource Directory (RD) server where CoAP servers > > can register their resources offered and CoAP clients can discover > > these resources by querying the RD server. RD syntax can be mapped > > to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], > > such that the above approach can be reused for group discovery and > > group member discovery. > > /remove Specifically, the Domain (d) parameter can be set to the > > group URI by > > an end-point registering to the RD. If an end-point wants to join > > multiple groups, it has to repeat the registration process for each > > group it wants to join. > > /end remove > > /comment d parameter semantics not clear > > 3.4. Group Resource Manipulation > > Group communications SHALL only be used for idempotent methods (i.e. > > CoAP GET, PUT, DELETE). The CoAP messages that are sent via > > multicast SHALL be Non-Confirmable. > > A unicast response per server MAY be sent back to answer the group > > request (e.g. response "2.05 Content" to a group GET request) taking > > into account the congestion control rules defined in > > [I-D.ietf-core-coap]. The unicast responses may be a mixture of > > success (e.g. 2.05 Content) and failure (e.g. 4.04 Not Found) codes > > depending on the individual server processing result. > > Group communications SHALL NOT be used for non-idempotent methods > > (i.e. CoAP POST). This is because not all group members are > > guaranteed to receive the multicast request, and the sender can not > > readily find out which group members did not receive it. > > All nodes in a given group SHOULD receive the same request > > /remove with high probability. > > /comment I don't see where probability comes in. > > This will not be the case if there is diversity in the > > authority port (i.e. a diversity of dynamic port addresses across > > the > > group) or if the targeted resource is located at different paths on > > different nodes. > > Therefore, some measures must be present to ensure uniformity in > > port > > number and resource names/locations within a group. This document > > proposes the following measures: > > Rahman & Dijk Expires April 22, 2013 [Page > > 7] > > Internet-Draft Group Communication for CoAP October > > 2012 > > o All CoAP multicast requests MUST be sent either to the default > > CoAP UDP port (i.e. default Uri-Port as defined in > > [I-D.ietf-core-coap]), or to a port number obtained via a service > > discovery lookup operation as a valid CoAP port for the targeted > > multicast group. > > o All CoAP multicast requests SHOULD operate only on URIs (links) > > which were > > /s retreived /s retrieved > > either from a "/.well-known/core" lookup on > > at least one group member node, or from an equivalent service > > discovery lookup which returns either the resources supported by > > all group members or resources supported by one particular group > > member. > > /comment so setting a multicast address in a source at installation is > > forbidden? > > 3.5. Configuring Group Membership In Endpoints > > In some use cases, the group membership of endpoints needs to be > > configurable after the network has been deployed. Example use cases > > can be found in building control: a commissioning tool determines to > > which groups a light or sensor node belongs, and writes this > > information to all nodes, which can subsequently join the correct > > group. > > To achieve smoother interoperability between nodes/endpoints from > > different manufacturers, it is proposed here to define an OPTIONAL > > standardized RESTful means of configuring CoAP endpoints with > > relevant group information. > > CoAP endpoints implementing this mechanism MUST support a > > discoverable "Group Configuration" resource of resource type (rt) > > [RFC6690] "core.gp". This resource (and perhaps its sub-resources, > > TBD) are used to manage group membership. Three design options for > > this mechanism are presented here as a placeholder (TBD). > > Design 1: use CoRE link format payloads to communicate group > > membership to endpoints. (TBD Not clear how this should be > > realized.) > > /comment, not clear what you mean either. Remove design 1 in this > state > > Design 2: use a JSON type resource. For example, a GET on the > > "core.gp" resource returns a JSON array of group objects. > > Req: GET /gp > > Res: 2.05 Content (Content-Format: application/json) > > [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", > > "ip": "ff05::4200:f7fe:ed37:14ca" } > > ] > > where "n" defines the Group FQDN and "ip" defines the associated > > multicast IP address. As a next example, the same endpoint can be > > Rahman & Dijk Expires April 22, 2013 [Page > > 8] > > Internet-Draft Group Communication for CoAP October > > 2012 > > added to another group by a POST on the resource with a JSON group > > object: > > Req: POST /gp (Content-Format: application/json) > > { "n": "floor1.west.bldg6.example.com", > > "ip": "ff05::4200:f7fe:ed37:14cb" } > > Res: 2.04 Changed > > Design 3: define named sub-resources, each sub-resource representing > > a group membership. The payload of the sub-resource may be JSON or > > a > > simple pre-defined format. Or alternatively, information is > > provided > > via POST with query parameters. > > /comment are these mutually exclusive designs? > > /comment design 2 without JSON is als possible > > /comment design with SRV and TXt records is also possible > > /comment there are 2 ways: (1) the node queries to which group it > > belongs > > /comment (2) an instalation tools instructs the node to which groups > > it belongs > > /comment not clear in text that this choice exists or that a choice > was > > made. > > 3.6. Congestion Control > > Multicast CoAP requests may result in a multitude of replies from > > different nodes, potentially causing congestion. Therefore sending > > multicast > > /s requests /s replies > > should be conservatively controlled. > > The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific > > congestion risks through the following measures: > > o A server MAY choose not to respond to a multicast request if > > there's nothing useful to respond (e.g. error or empty response). > > o A server SHOULD limit the support for multicast requests to > > specific resources where multicast operation is required. > > o A multicast request MUST be Non-Confirmable. > > /comment what about the reply? > > o A server does not respond immediately to a multicast request, but > > SHOULD first wait for a time that is randomly picked within a > > predetermined time interval called the Leisure. > > o A server SHOULD NOT accept multicast requests that can not be > > authenticated. > > /comment invoking as many certificates? > > Additional guidelines to reduce congestion risks are: > > o A server in an LLN should only support multicast GET for > > resources > > that are small, e.g. > > /remove for an LLN that could mean > > the payload of the > > response fits into a single link-layer frame. > > o A server can minimize the payload length in response to a > > multicast GET on "/.well-known/core" by using hierarchy in > > arranging link descriptions for the response. An example of this > > is given in Section 5 of [RFC6690]. > > Rahman & Dijk Expires April 22, 2013 [Page > > 9] > > Internet-Draft Group Communication for CoAP October > > 2012 > > o Preferably IP multicast with link-local scope should be used, > > rather than global or site-local. > > o The Hop Limit field in the IPv6 packet should be chosen as low as > > possible (if the CoAP/IP stack allows setting of this value. TBD > > - discuss whether this guideline is relevant/realistic in CoAP > > context) > > 3.7. CoAP Multicast and HTTP Unicast Interworking > > /comment a reference will suffice > > CoAP supports operation over UDP multicast, while HTTP does not. > > For > > use cases where it is required that CoAP group communication is > > initiated from an HTTP end-point, it would be advantageous if the > > HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group > > communication based on IP multicast. > > /remove One possible way of operation > > /remove of such HTTP-CoAP Proxy is illustrated in Figure 1. > > Note that this > > topic is covered in more detail in > > [I-D.castellani-core-advanced-http-mapping]. > > /remove > > CoAP Mcast CoAP Mcast HTTP-CoAP HTTP > > Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 > > | | | | | | > > |MLD REQUEST | | | | > > |(Join Group X) | | | | > > |--LL-->| | | | | > > | | |MLD REQUEST | | > > | | |(Join Group X) | | > > | | |--LL-->| | | > > | | | | | HTTP REQUEST | > > | | | | | (URI to | > > | | | | | unicast addr) | > > | | | | |< -----------------| > > | | | | | | > > | | | Resolve HTTP Request-Line URI | > > | | | to Group X multicast address | > > | | | | | | > > | CoAP REQUEST (to multicast addr)| | > > |< ------<---------<-------<------| | > > | | | | | | > > | | | | > > | (optional) CoAP RESPONSE(s) | | > > | |-------------->| | > > |-----------------|-------------->| Aggregated | > > | | | HTTP RESPONSE | > > | | |------------------>| > > | | | | > > Rahman & Dijk Expires April 22, 2013 [Page > > 10] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Figure 1: CoAP Multicast and HTTP Unicast Interworking > > Note that Figure 1 illustrates the case of IP multicast as the > > underlying group communications mechanism. MLD denotes the > > Multicast > > Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a > > Link-Local multicast. > > A key point in Figure 1 is that the incoming HTTP Request (from node > > 3) will carry a Host request-header field that resolves in the > > general Internet to the proxy node. At the proxy node, this > > hostname > > and/or the Request-Line URI will then possibly be mapped (as > > detailed > > in [I-D.castellani-core-http-mapping]) and again resolved (with the > > CoAP scheme) to an IP multicast address. This may be accomplished, > > for example, by using DNS or DNS-SD (Section 3.3). The proxy node > > will then IP multicast the CoAP Request (corresponding to the > > received HTTP Request) via multicast routers to the appropriate > > nodes > > (i.e. nodes 1 and 2). > > In terms of the HTTP Response, Figure 1 illustrates that it will be > > generated by the proxy node based on aggregated responses of the > > CoAP > > nodes and sent back to the client in the general Internet that sent > > the HTTP Request (i.e. node 1). In > > [I-D.castellani-core-advanced-http-mapping] the HTTP Response that > > the Proxy may use to aggregate multiple CoAP responses is described > > in more detail. So in terms of overall operation, the CoAP proxy > > can > > be considered to be a "non-transparent" proxy according to > > [RFC2616]. > > Specifically, [RFC2616] states that a "non-transparent proxy is a > > proxy that modifies the request or response in order to provide some > > added service to the user agent, such as group annotation services, > > media type transformation, protocol reduction or anonymity > > filtering." > > An alternative to the above is using a Forward Proxy. In this case, > > the CoAP request URI is carried in the HTTP Request-Line (as defined > > in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the > > IP address of the Proxy. > > /end remove > > 4. Use Cases and Corresponding Protocol Flows > > 4.1. Introduction > > The use of CoAP group communication is shown in the context of the > > following use cases and corresponding protocol flows: > > o Discovery of Resource Directory: discovering the local CoRE RD > > which contains links (URIs) to resources stored on other servers > > [RFC6690]. > > Rahman & Dijk Expires April 22, 2013 [Page > > 11] > > Internet-Draft Group Communication for CoAP October > > 2012 > > o Lighting Control: synchronous operation of a group of 6LoWPAN > > [RFC4944] IPv6-connected lights > > o Parameter Update: updating parameters/settings simultaneously in > > a > > large group of devices in a building/campus control > > ([I-D.vanderstok-core-bc]) application --- TBD > > / comment I suggest to remove Firmware Update and Groups status report > > /comment the ones above are difficult enough, and I doubt that > > simultaneity > > /comment (motivation of multicast) is involved here > > o Firmware Update: efficiently updating firmware simultaneously in > > a > > large group of devices in a building/campus control > > ([I-D.vanderstok-core-bc]) application --- TBD suggests a > > multicast extension of core-block. > > o Group Status Report: requesting status information or event > > reports from a group of devices in a building/campus control > > application --- TBD, may require reliable group communication to > > be feasible. > > 4.2. Network Configuration > > We assume the following network configuration for all the use cases > > as shown in Figure 2: > > /comment the configurations frighten me > > /comment from completeness considerations I can imagine even more > > complex ones > > /comment It might be useful if the practical impossibility of some > > configurations is high lighted > > o A large room (Room-A) with three lights (Light-1, Light-2, > > Light-3) controlled by a Light Switch. The devices are organized > > into two 6LoWPAN subnets. > > /comment one subnet is enough for me > > /remove > > o Light-1 and the Light Switch are connected to a router (Rtr-1) > > which is also a CoAP Proxy, a CoAP Resource Directory (RD) and a > > 6LoWPAN Border Router (6LBR). > > o Light-2 and the Light-3 are connected to another router (Rtr-2) > > which is also a CoAP Proxy, a CoAP RD and a 6LBR. > > o The routers are connected to an IPv6 network backbone which is > > also multicast enabled. In the general case, this means the > > network backbone and 6LBRs support a PIM based multicast routing > > protocol, and MLD for forming groups. In a limited case, if the > > network backbone is one link, then the routers only have to > > support MLD-snooping (Appendix A) for the following use cases to > > work. > > /end remove > > /comment I can imagine that an central control is present on the > > backbone > > /comment switch or sensor send unicast to central control > > /comment central control sends multicast to multicast group within > > single lowpan > > Rahman & Dijk Expires April 22, 2013 [Page > > 12] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Network > > Backbone > > | > > ################################################ > > | > > # Room-A # > > | > > # ********************** # > > | > > # ** LoWPAN-1 (subnet-1) ** # > > | > > # * * # > > | > > # * +----------+ * # > > | > > # * | Light |-------+ * # > > | > > # * | Switch | | * # > > | > > # * +----------+ +---------+ * # > > | > > # * | Rtr-1 > > |-----------------------------| > > # * +---------+ * # > > | > > # * +----------+ | * # > > | > > # * | Light-1 |--------+ * # > > | > > # * +----------+ * # > > | > > # * * # > > | > > # ** ** # > > | > > # ********************** # > > | > > # # > > | > > # # > > | > > # ********************** # > > | > > # ** LoWPAN-2 (subnet-2) ** # > > | > > # * * # > > | > > # * +----------+ * # > > | > > # * | Light-2 |-------+ * # > > | > > # * | | | * # > > | > > # * +----------+ +---------+ * # > > | > > # * | Rtr-2 > > |-----------------------------| > > # * +---------+ * # > > | > > # * +----------+ | * # > > | > > # * | Light-3 |--------+ * # > > | > > # * +----------+ * # > > | > > # * * # > > | > > # ** ** # > > | > > # ********************** # > > | > > # # > > | > > ################################################# > > | > > | > > +--------+ > > | > > | DNS > > |------------------| > > | Server | > > +--------+ > > Figure 2: Network Topology of a Large Room (Room-A) > > Rahman & Dijk Expires April 22, 2013 [Page > > 13] > > Internet-Draft Group Communication for CoAP October > > 2012 > > 4.3. Discovery of Resource Directory > > The protocol flow for discovery of a RD for the given network (of > > Figure 2) is shown in Figure 3: > > o The fixture for Light-2 is installed and powered on for the first > > time. > > o Light-2 will then search for the local RD (RD-2) by sending out a > > GET request (with the "/.well-known/core?rt=core.rd" request URI) > > to the site-local "All CoAP Nodes" address. In this case, the > > site is assumed to include all nodes in the subnet. > > o This multicast message will then go to each node in subnet-2. > > However, only Rtr-2 (RD-2) will respond because the GET is > > qualified by the query string "?rt=core.rd". > > o Note that the flow is shown only for Light-2 for clarity. > > Similar > > flows will happen for Light-1, Light-3 and the Light Switch when > > they are first powered on. > > The RD may also be discovered by other means such as by assuming a > > default location (e.g. on a 6LBR), using DHCP, anycast address, etc. > > However, these approaches do not invoke CoAP group communication so > > are not further discussed here. > > For other discovery use cases such as discovering local CoAP > > servers, > > services or resources group communication can be used in a similar > > fashion as in the above use case. Both Link-Local (LL) and site- > > local discovery are possible this way. > > /comment the RD discovery will be more complex when there is a router > > between light-2 and switch > > /comment Via which RD will light switch discover light-2? > > /comment additional reason to remove router from the multicast > > configuration > > Rahman & Dijk Expires April 22, 2013 [Page > > 14] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (RD-1) (RD-2) > > Backbone > > | | | | | | | > > | | | | | | | > > ********************************** | | | > > * Light-2 is installed * | | | > > * and powers on for first time * | | | > > ********************************** | | | > > | | | | | | | > > | | | | | | | > > | | COAP NON (GET | | > > | | /.well-known/core?rt=core.rd) | | > > | |--------->-------------------------------->| | > > | | | | | | | > > | | | | | | | > > | | | | | | | > > | | COAP NON (2.05 Content | | > > | | ;rt="core.rd";ins="Primary") | | > > | |<------------------------------------------| | > > | | | | | | | > > Figure 3: Resource Directory Discovery via Multicast Message > > 4.4. Lighting Control > > /comment I am confused about the use of protocols > > /comment MLD is used to form groups, correct? > > /comment but that was already done by enabling the MC address in the > > lights (point 2) > > /comment There are several ways to set up groups, pointing them out > and > > when to use them would be an asset. > > The protocol flow for a building automation lighting control > > scenario > > for the network (Figure 2) is shown in sequence in Figure 4, > > Figure 5, and Figure 6. We assume the following steps occur before > > the illustrated flow: > > o 1) Startup phase: 6LoWPANs are formed. IPv6 addresses assigned > > to > > all devices. The CoAP network is formed. > > o 2) Commissioning phase (by applications): The IP multicast > > address > > of the group (Room-A-Lights) has been > > /s set /s enable > > in all the Lights. The > > URI of the group (Room-A-Lights) has been > > /s set /s resolved > > in the Light Switch. > > o 3) The indicated MLD Report messages are link-local multicast. > > In > > each LoWPAN, it is assumed that a multicast routing/forwarding > > protocol in 6LRs will then propagate the Join information > > contained in the MLD Report over multiple hops to the 6LBR. > > /comment Don't see the need > > Rahman & Dijk Expires April 22, 2013 [Page > > 15] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (CoAP (CoAP > > Backbone > > | | | | Proxy) Proxy) | > > | | | | | | | > > | | | | | | | > > | MLD Report: Join | | | | | > > | Group (Room-A-Lights) | | | | > > |---LL------------------------------------->| | | > > | | | | |MLD Report: Join | > > | | | | |Group (Room-A-Lights)| > > | | | | |---LL--------------->| > > | | | | | | | > > | | MLD Report: Join | | | | > > | | Group (Room-A-Lights) | | | > > | |---LL------------------------------------->| | > > | | | | | | | > > | | | MLD Report: Join | | | > > | | | Group (Room-A-Lights) | | > > | | |---LL-------------------------->| | > > | | | | | | | > > | | | | |MLD Report: Join | > > | | | | |Group (Room-A-Lights)| > > | | | | | |---LL---->| > > | | | | | | | > > | | | | | | | > > Figure 4: Joining Lighting Groups Using MLD > > /comment possibly remove from text, or do separate section on use of > > MLD > > /comment anyway separating commissioning from operation in separate > > sections is a good idea. > > /comment the proxies are a complication in the picture not elaborated > > in the text. > > /comment the subject of proxies is another one, to be treated > > elsewhere. > > /comment also for proxies the do's and don't's from a simple > > performance perspective will be interesting > > Rahman & Dijk Expires April 22, 2013 [Page > > 16] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (CoAP (CoAP > > Backbone > > | | | | Proxy) Proxy) | > > | | | | | | | > > | | *********************** | | > > | | * User flips on * | | > > | | * light switch to * | | > > | | * turn on all the * | | > > | | * lights in Room A * | | > > | | *********************** | | > > | | | | | | | > > | | | | | | | > > | | | COAP NON (PUT | | | > > | | | Proxy-URI | | | > > | | | URI for Room-A-Lights | > > | | | Payload=turn on lights) | > > | | | |--------->| | | > > | | | | | | | > > | | | | | | | > > | | | | Request DNS resolution of | > > | | | | URI for Room-A-Lights | > > | | | | |-------------------->| > > | | | | | | | > > | | | | | | | > > | | | | DNS returns: AAAA | > > | | | | Group (Room-A-Lights) | > > | | | | IPv6 multicast address | > > | | | | |<--------------------| > > | | | | | | | > > | | | | | | | > > | | | COAP NON (Put | > > | | | | URI Path | > > | | | | Payload=turn on lights)| > > | | | | Destination IP Address = | > > | | | | IP multicast address | > > | | | | for Group (Room-A-Lights)| > > | | | | Originating IP Address = | > > | | | | RTR-1 | > > | | | | |-------------------->| > > |<------------------------------------------| | | > > | | | | | | | > > | | | | | |<---------| > > | |<---------|<-------------------------------| | > > | | | | | | | > > | | | | | | | > > Figure 5: Sending Lighting Control Multicast Message > > Rahman & Dijk Expires April 22, 2013 [Page > > 17] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (CoAP (CoAP > > Backbone > > | | | | Proxy) Proxy) | > > | | | | | | | > > *********************** | | | | > > * Lights in Room-A * | | | | > > * turn on (nearly * | | | | > > * simultaneously) * | | | | > > *********************** | | | | > > | | | | | | | > > | | | | | | | > > | COAP NON (2.04 Changed) | | | | > > |------------------------------------------>| | | > > | | | | | | | > > | | | | | | | > > | COAP NON (2.04 Changed) | | | > > | |------------------------------->| | | > > | | | | | | | > > | | | | | | | > > | | COAP NON (5.00 Internal Server Error) | > > | | |-------------------->| | | > > | | | | | | | > > | | | ****************************** | > > | | | * Rtr-1 as CoAP Proxy * | > > | | | * | sends the individual * | > > | | | * | responses back to * | > > | | | * v originator * | > > | | | ****************************** | > > | | | | | | | > > | | | COAP NON (2.04 Changed) | | > > | | | |<---------| | | > > | | | | | | | > > | | | COAP NON (2.04 Changed) | | > > | | | |<---------| | | > > | | | | | | | > > | | | COAP NON (5.00 Internal Server Error) | > > | | | |<---------| | | > > | | | | | | | > > Figure 6: Sending Lighting Control Response to Multicast Message > > NOTE: In the last step of Figure 6, Rtr-1 acting as CoAP proxy, > > returns multiple individual CoAP responses to the client. Each > > response echoes the Token of the client's request. The client can > > identify the original source of each response by ...TBD. > > /comment WHY are the multicast destinations sending back results? > > /comment I thought that you wanted MC messages to be non confirmable > > /comment sending responses seems to contradict this . > > /comment please remove sending back of responses. > > /comment one may assume that the MC algorithm within the lowpan is > > reliable (all destinations receive the message) > > /comment anyway MPL comes close enough to the reliability requirement > > given a specifiable range of configurations > > ______________________________________________________________________ > _____________________________________________________ > > > -- > > Peter van der Stok > > mailto: consultancy@vanderstok.org > > www: www.vanderstok.org [3] > > tel NL: +31(0)492474673 F: +33(0)966015248 > > ------------------------- > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. > > > Links: > ------ > [1] http://datatracker.ietf.org/drafts/current/ > [2] http://trustee.ietf.org/license-info > [3] http://www.vanderstok.org ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Sat Nov 2 13:56:29 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86DC21E80E2 for ; Sat, 2 Nov 2013 13:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVXmeQREMOWZ for ; Sat, 2 Nov 2013 13:56:14 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A9DF121E805D for ; Sat, 2 Nov 2013 13:56:08 -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.4/8.14.4) with ESMTP id rA2Ku3vG006617; Sat, 2 Nov 2013 21:56:03 +0100 (CET) Received: from dhcp-9c27.meeting.ietf.org (dhcp-9c27.meeting.ietf.org [31.133.156.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 64DDA374; Sat, 2 Nov 2013 21:56:00 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Carsten Bormann Date: Sat, 2 Nov 2013 13:55:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: To: core X-Mailer: Apple Mail (2.1816) Cc: core-chairs@tools.ietf.org Subject: [core] First slide set posted X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 20:56:29 -0000 I have posted the first stack of slides for Monday=92s and Thursday=92s = meeting. http://www.ietf.org/proceedings/88/slides/slides-88-core-0.pdf I took the opportunity to also upload the agenda (oops): http://www.ietf.org/proceedings/88/agenda/agenda-88-core If you think you have (or need) meeting time, and aren=92t on there (or = your slides are missing), please contact the chairs. (Today, if you = are on-site, you might catch us at the Tennyson room in the fourth = floor.) As usual, I need the slides 24 h before the meeting at the = latest. Gr=FC=DFe, Carsten From cabo@tzi.org Sat Nov 2 15:22:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33D311E8255 for ; Sat, 2 Nov 2013 15:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6kgDc8ir4My for ; Sat, 2 Nov 2013 15:22:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 98DC711E824B for ; Sat, 2 Nov 2013 15:22:24 -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.4/8.14.4) with ESMTP id rA2MMMsW025599; Sat, 2 Nov 2013 23:22:22 +0100 (CET) Received: from dhcp-9c27.meeting.ietf.org (dhcp-9c27.meeting.ietf.org [31.133.156.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7F24638A; Sat, 2 Nov 2013 23:22:20 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Sat, 2 Nov 2013 15:22:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75C11E4A-D661-4841-B44E-ADBF28EF80C6@tzi.org> References: To: core X-Mailer: Apple Mail (2.1816) Cc: core-chairs@tools.ietf.org Subject: Re: [core] First slide set posted X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 22:22:32 -0000 =85 and already updated (alternative transport slides; thanks, Teemu). Agenda and slides will continue to change frequently in the next couple = of hours; I=92ll not announce every change (maybe I=92ll code up a = proceedings atom feed next :-). Gr=FC=DFe, Carsten From cabo@tzi.org Sat Nov 2 16:06:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE58421E80C3 for ; Sat, 2 Nov 2013 16:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.249 X-Spam-Level: X-Spam-Status: No, score=-107.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp-N4jOsEauY for ; Sat, 2 Nov 2013 16:06:20 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A2CF521E811B for ; Sat, 2 Nov 2013 16:06:13 -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.4/8.14.4) with ESMTP id rA2N62Z5019759 for ; Sun, 3 Nov 2013 00:06:02 +0100 (CET) Received: from dhcp-9c27.meeting.ietf.org (dhcp-9c27.meeting.ietf.org [31.133.156.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ECD11393; Sun, 3 Nov 2013 00:06:00 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <5268FF91.7050301@tzi.de> Date: Sat, 2 Nov 2013 16:05:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <780B703E-3DF5-4780-B90C-639BAF1363B7@tzi.org> References: <5268FF91.7050301@tzi.de> To: Stefanie Gerdes X-Mailer: Apple Mail (2.1816) Cc: "core@ietf.org" Subject: Re: [core] Invitation to Core-AA Meeting on Sunday 3rd Nov X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 23:06:25 -0000 On 24 Oct 2013, at 04:08, Stefanie Gerdes wrote: > Carsten is collecting one slide per attendee for the roll call. = Details > will follow. A little bit late at 20 hours before the meeting, but: If you haven=92t sent me a slide yet, maybe you want to use the template = at http://www.tzi.org/~cabo/Core-AA-template.ppt which has a template slide and an example filled in. Gr=FC=DFe, Carsten From cabo@tzi.org Sat Nov 2 17:18:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A550321E8133 for ; Sat, 2 Nov 2013 17:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.449 X-Spam-Level: X-Spam-Status: No, score=-107.449 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mvFfa-qUHiE for ; Sat, 2 Nov 2013 17:17:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B43A521E8139 for ; Sat, 2 Nov 2013 17:17:56 -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.4/8.14.4) with ESMTP id rA30HsZU009601 for ; Sun, 3 Nov 2013 01:17:54 +0100 (CET) Received: from dhcp-9c27.meeting.ietf.org (dhcp-9c27.meeting.ietf.org [31.133.156.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AFE0C39E; Sun, 3 Nov 2013 01:17:52 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Carsten Bormann In-Reply-To: <5268FF91.7050301@tzi.de> Date: Sat, 2 Nov 2013 17:17:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52E62492-A2FF-45BF-8AE1-016F71BF8A3D@tzi.org> References: <5268FF91.7050301@tzi.de> To: "core@ietf.org" X-Mailer: Apple Mail (2.1816) Subject: Re: [core] Invitation to Core-AA Meeting on Sunday 3rd Nov X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 00:18:01 -0000 =85 and the room is: Lord Byron. This is on the fourth floor, see page 2 of http://www.ietf.org/meeting/88/floor-plans.pdf for the exact location. See you tomorrow at 12. =20 And don=92t forget to bring lunch bags... Gr=FC=DFe, Carsten From cabo@tzi.org Sat Nov 2 21:19:06 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE76C11E8295 for ; Sat, 2 Nov 2013 21:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.582 X-Spam-Level: X-Spam-Status: No, score=-107.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg9M1CjZgLZQ for ; Sat, 2 Nov 2013 21:19:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B377511E8171 for ; Sat, 2 Nov 2013 21:19:01 -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.4/8.14.4) with ESMTP id rA34Isqr028286 for ; Sun, 3 Nov 2013 05:18:54 +0100 (CET) Received: from dhcp-9560.meeting.ietf.org (dhcp-9560.meeting.ietf.org [31.133.149.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 90D963A8; Sun, 3 Nov 2013 05:18:52 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Carsten Bormann In-Reply-To: <52E62492-A2FF-45BF-8AE1-016F71BF8A3D@tzi.org> Date: Sat, 2 Nov 2013 21:18:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5268FF91.7050301@tzi.de> <52E62492-A2FF-45BF-8AE1-016F71BF8A3D@tzi.org> To: "core@ietf.org" X-Mailer: Apple Mail (2.1816) Subject: Re: [core] Invitation to Core-AA Meeting on Sunday 3rd Nov X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 04:19:07 -0000 You can find a first consolidated slide set at http://www.tzi.org/~cabo/Core-AA-show.pdf If your slides aren=92t in there, please send them! (If they are, please check for any mangling.) Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Sun Nov 3 06:56:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF811E8115 for ; Sun, 3 Nov 2013 06:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_50=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLQoLXit78Lx for ; Sun, 3 Nov 2013 06:56:23 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6C55A11E8278 for ; Sun, 3 Nov 2013 06:56:21 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Nov 2013 09:56:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 3 Nov 2013 09:56:28 -0500 Message-ID: In-Reply-To: <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] group-comm comments Thread-Index: Ac7Xzfh1PIiDb0KWS6aVBZZLK1oPRgA1V5wQ References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> From: "Rahman, Akbar" To: "weigengyu" X-OriginalArrivalTime: 03 Nov 2013 14:56:38.0568 (UTC) FILETIME=[E6058280:01CED8A4] Cc: Core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 14:56:27 -0000 SGkgR2VuZ3l1LA0KDQoNCkp1c3Qgc29tZSBxdWljayBmZWVkYmFjay4gIFRoZSBncm91cGNvbW0g ZHJhZnQgYXNzdW1lcyBvbmx5IHVucmVsaWFibGUgKGkuZS4gbm90IGd1YXJhbnRlZWQpIElQIG11 bHRpY2FzdC4gIFRoaXMgaXMgc3BlY2lmaWVkIGluIA0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLTE2I3NlY3Rpb24tMi40IChzZWUgMXN0IHBh cmFncmFwaCkNCg0KYW5kIA0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWNvcmUtZ3JvdXBjb21tLTE2I3NlY3Rpb24tMy40IChzZWUgM3JkIHBhcmFncmFwaCkNCg0KDQpS ZWxpYWJsZSBtdWx0aWNhc3QgaXMgbm90IHN1cHBvcnRlZC4gIFdlIGNhbiBwZXJoYXBzIG1ha2Ug dGhpcyBtb3JlIGNsZWFyIGJ5IGFkZGluZyBhIHNlbnRlbmNlIGluIHRoZSBTY29wZSAoaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS0xNiNzZWN0aW9u LTEuMikuDQoNCg0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LA0KDQoNCkFrYmFyDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHdlaWdlbmd5dQ0KU2VudDog U2F0dXJkYXksIE5vdmVtYmVyIDAyLCAyMDEzIDk6MTYgQU0NClRvOiBEaWprLCBFc2tvOyBjb25z dWx0YW5jeUB2YW5kZXJzdG9rLm9yZw0KQ2M6IENvcmUNClN1YmplY3Q6IFJlOiBbY29yZV0gZ3Jv dXAtY29tbSBjb21tZW50cw0KDQpIaSwgRXNrbw0KDQpJIHdvdWxkIGxpa2UgdG8gZ2l2ZSBzb21l IGNvbW1lbnRzIG9uIHRoZSBHUk9VUC1DT01NIGRyYWZ0Lg0KDQpUaGVyZSBoYXZlIHVzZSBjYXNl cyBmb3IgcmVsaWFibGUgYW5kIHVucmVsaWFibGUgbXVsdGljYXN0IGNvbW11bmljYXRpb25zLg0K SWYgdGhpcyBkcmFmdCBvbmx5IGZvciBwcm92aWRpbmcgdW5yZWxpYWJsZSBtdWx0aWNhc3Qgb3Zl ciBJUCBtdWx0aWNhc3QsIGl0IA0KaXMgT0s7ICBqdXN0IHdyaXRlIGl0IGNsZWFybHkuDQoNCklm IHRoZSBkcmFmdCBpbnRlbmRzIHRvIGhhdmUgdGhlIHJlbGlhYmxlIG9yIHBhcnRpYWwgbXVsdGlj YXN0IGZhY2lsaXR5LA0KdGhlIGR0YWZ0IG5lZWRzIHRvIGdpdmUgd2hhdCBtZWNoYW5pc21zIGNh biBndXJhbnR0ZSB0aGF0Lg0KDQpUaGUgZHJhZnQgc2hvdWxkIGRlZmluZSBtZWNobmlzbXMgdGhh dCB0aGUgc2VydmVyIGNhbiByZWdpc3RlciBpdHMgDQpjYXBhYmlsaXR5IG9mIHN1cHBvcnRpbmcg bXVsdGljYXN0LA0KdGhpcyBtYXkgYmUgcHV0IHRvIFJEIHNlcnZlcjsNCmFuZCB3ZXRoZXIgdG8g cmVxdWVzdCByZWxpYWJsZSBncm91cGNvbW0gc2hvdWxlIGJlIHRoZSBjbGllbnQncyByZXF1ZXN0 Lg0KDQo+IFRvIGNsYXJpZnk6IHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQgYSBzZXJ2ZXIgTUFZ IHJlc3BvbmQgdG8gYSBtdWx0aWNhc3QgDQo+IHJlcXVlc3QsDQpBIG1lY2hhbmlzbSBpcyByZXF1 aXJlZCB0byBtYWtlIHRoZSBzZXJ2ZXIgcmVnaXN0ZXJzIGl0cyBjYXBhYmlsaXR5LiBpLmUuIA0K d2hldGhlciB0byBzdXBwb3J0IG11bHRpY2FzdDsNCg0KPiBhbmQgdGhlIGNsaWVudCBkb2Vzbid0 IGtub3cgYSBwcmlvcmkgaG93IG1hbnkgc2VydmVycyB3aWxsIHJlc3BvbmQgdG8gYSANCj4gbXVs dGljYXN0LA0KVGhlIGNsaWVudCBtYXkgbG9va3VwIHRoZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBS RCBzZXJ2ZXIgKGlmIHRoZSByZXJ2ZXIncyANCnJlZ2lzdGVyYXRpb24gcHJvY2Vzc2Ugd2VyZSBw b3NzaWJsZSk7DQoNCj4gKHNpbmNlIHRoZXJlIGFyZSBubyBndWlkZWxpbmVzL3J1bGVzIGZvciB0 aGF0KSwgdGhlIHNhZmVzdCB0aGluZyB0byBkbyBpcyANCj4gbm90IHNlbmQgdGhlIG11bHRpY2Fz dCBpbiB0aGUgZmlyc3QgcGxhY2UuDQpJZiBub3QgZmlyc3QsIHdoZW4gdG8gbWFrZSBhdmFpbGFi bGU/DQpTbywgd2hldGhlciBpdCBpcyByZXF1aXJlZCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBieSB0 aGUgY2xpZW50IHJlcXVlc3QsIGFuZCANCnRoZXJlIHNob3VsZCBoYXZlIHNvbWUgYXV0aG9yaXR5 IG9yIHByaW9yaXR5IGNvbnRyb2wgdG8gY2xpZW50Lg0KDQo+IFRoZXJlZm9yZSB0aGUgYWR2aWNl IGlzIHRvIGNhcmVmdWxseSBjb250cm9sIHNlbmRpbmcgb2YgbXVsdGljYXN0IA0KPiByZXF1ZXN0 cy4NCk5vdCBvbmx5IHRvIHRlbGwgdGhhdCwgdGhlIGRyYWZ0IHNob3VsZCBoYXZlIGNsZWFyIGRl c2NyaXB0aW9ucyBhYm91dCBob3cgDQp0aGUgcHJvdG9jb2wgc3VwcG9ydHMgbXVsdGljYXN0IHJl cXVpZXN0cyBhbmQvb3IgcmVsaWFibGUgbXVsdGljYXN0IHdoZW4gDQpyZXF1aXJlZC4NCg0KcmVn YXJkcywNCg0KR2VuZ3l1DQoNCk5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINClNjaG9vbCBvZiBD b21wdXRlcg0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzICYgVGVsZWNvbW11bmljYXRpb25z DQoNCi0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0gDQpGcm9tOiBEaWprLCBFc2tvDQpTZW50OiBUaHVy c2RheSwgRGVjZW1iZXIgMjAsIDIwMTIgNjo1NiBQTQ0KVG86IGNvbnN1bHRhbmN5QHZhbmRlcnN0 b2sub3JnDQpDYzogQ29yZQ0KU3ViamVjdDogUmU6IFtjb3JlXSBncm91cC1jb21tIGNvbW1lbnRz DQoNClRoYW5rcyBQZXRlciwNCg0KSSB3b3VsZCBhZ3JlZSB3ZSBuZWVkIHRvIGluY2x1ZGUgZ3Vp ZGVsaW5lcyBvbiByZXR1cm5pbmcgb2YgcmVzcG9uc2VzIHRvIA0KQ29BUCBtdWx0aWNhc3QgcmVx dWVzdHMuIChOb3RlIHRoZSBDb0FQIHNwZWMgZW5zdXJlcyB0aGF0IGEgQ29BUCBzZXJ2ZXIgd2ls bCANCm5ldmVyIEFDSyBhIG11bHRpY2FzdCBidXQgdGhhdCBkb2VzIG5vdCBoZWxwIGEgdGhpbmcg aWYgaXQgc3RpbGwgc2VuZHMgYSANCnJlc3BvbnNlIHBhY2tldC4uLikgSSdsbCBtYWtlIGEgdGlj a2V0IGZvciB0aGlzLiBJZiBhbnlvbmUgZGlzYWdyZWVzIHdlJ2xsIA0KaGVhciBpdC4NCg0KPiBU aGVuIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHRleHQsIGJlY2F1c2UgInJlcXVlc3QiLCAicmVw bHkiIGFuZCANCj4gInJlc3BvbnNlIiBhcmUgb3ZlcmxvYWRlZCBpbiBteSBtaW5kLg0KVG8gY2xh cmlmeTogdW5kZXIgdGhlIGFzc3VtcHRpb24gdGhhdCBhIHNlcnZlciBNQVkgcmVzcG9uZCB0byBh IG11bHRpY2FzdCANCnJlcXVlc3QsIGFuZCB0aGUgY2xpZW50IGRvZXNuJ3Qga25vdyBhIHByaW9y aSBob3cgbWFueSBzZXJ2ZXJzIHdpbGwgcmVzcG9uZCANCnRvIGEgbXVsdGljYXN0LCAoc2luY2Ug dGhlcmUgYXJlIG5vIGd1aWRlbGluZXMvcnVsZXMgZm9yIHRoYXQpLCB0aGUgc2FmZXN0IA0KdGhp bmcgdG8gZG8gaXMgbm90IHNlbmQgdGhlIG11bHRpY2FzdCBpbiB0aGUgZmlyc3QgcGxhY2UuIFRo ZXJlZm9yZSB0aGUgDQphZHZpY2UgaXMgdG8gY2FyZWZ1bGx5IGNvbnRyb2wgc2VuZGluZyBvZiBt dWx0aWNhc3QgcmVxdWVzdHMuDQoNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHBldGVyIHZhbiBkZXIgU3RvayBbbWFpbHRvOnN0b2tjb25zQHhzNGFsbC5ubF0NClNl bnQ6IFRodXJzZGF5IDIwIERlY2VtYmVyIDIwMTIgMTE6MjYNClRvOiBEaWprLCBFc2tvDQpDYzog Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc7IGFrYmFyIHJhaG1hbjsgQ29yZQ0KU3ViamVjdDog UkU6IGdyb3VwLWNvbW0gY29tbWVudHMNCg0KDQpIaSBFc2tvLA0KDQp0aGFua3MgZm9yIHlvdXIg cmVhY3Rpb25zLiBJIHdpbGwgZ3JvdXAgbXkgYW5zd2VycywgdG8gYmV0dGVyIGV4cGxhaW4gbXkg DQpwb2ludHMgb24gdGhlIHJldHVybiBvZiBwYWNrZXRzIHRvIE1DIHNlbmRlcnMuDQoNCjEpIFJl dHVybiBvZiBwYWNrZXRzIHRvIG11bHRpY2FzdA0KDQpBcyBJIHVuZGVyc3RhbmQgdGhlIG11bHRp Y2FzdCBtZXNzYWdlIGlzIHByZWZlcmFibHkgc2VudCB3aXRoIG5vIA0KY29uZmlybWF0aW9uIChh Y2spIGJlY2F1c2UgdGhlIHJldHVybiBvZiBhbGwgdGhlIGFja3MgbWF5IG92ZXJ3aGVsbSB0aGUg DQpuZXR3b3JrIGFuZCB0aGUgc2VuZGVyIG9mIHRoZSBtdWx0aWNhc3QuDQpUaGUgYWNrbm93bGVk Z2VtZW50IGlzIG5vdCBuZWVkZWQgZm9yIE1QTCBhcyB0aGUgcHJvdG9jb2wgaGFzIGFsbCB0aGUg DQptYWNoaW5lcnkgdG8gYXNzdXJlIHRoYXQgYWxsIGRlc3RpbmF0aW9ucyByZWNlaXZlIGl0LCAo Z2l2ZW4gY29uc3RyYWludHMgb24gDQpuZXR3b3JrIGxvYWQgYW5kIGNvbmZpZ3VyYXRpb24gZGVu c2l0eSBhbmQgc2l6ZSkuDQoNClN1cHBvc2luZyBhbiBhY2sgaXMgbmVlZGVkLCB0aGVuIGl0IHdv dWxkIGJlIGFkdmlzYWJsZSB0byBzdGFmZmxlIHRoZSANCnJlc3BvbnNlcyBhbmQgYW4gYWRkaXRp b25hbCBhY2tub3dsZWRnZW1lbnQgcHJvdG9jb2wgY291bGQgYmUgYWRkZWQgdG8gdGhlIA0KbXVs dGljYXN0IHByb3RvY29sLiBUaGUgc2FtZSBpcyB0cnVlIGlmIGEgbWVzc2FnZSBpcyByZXR1cm5l ZCAoYXMgaW4gdGhlIA0KY2FzZSBvZiBtRE5TKS4NCg0KT25lIGNhbiB0aGVuIHdvbmRlciB3aGV0 aGVyIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbCAoZS5nLiBtRE5TKSBzaG91bGQgdGFrZSANCmNh cmUgb2YgdGhlIHN0YWZmbGVkIHJlc3BvbnNlIG9yIHRoYXQgYW4gYWRkaXRpb25hbCBwcm90b2Nv bCBuZWVkcyB0byBiZSANCnNwZWNpZmllZC4NCkkgaGF2ZSBubyBvcGluaW9uIG9uIHRoZSBjaG9p Y2UsIGJ1dCBzZWUgdGhlIG5lZWQgZm9yIHRoZSBvbmUgb3IgdGhlIG90aGVyLiANCkNvbWluZyB3 aXRoIGEgcmVjb21tZW5kYXRpb24gKGV4cGxhbmF0aW9uKSBvbiB0aGUgc3ViamVjdCBvZiByZXR1 cm5pbmcgDQpyZXNwb25zZXMgKGFja3MpIHdvdWxkIGJlIG15IHJlY29tbWVuZGF0aW9uIGZvciB0 aGUgR3JvdXBDb21tIGRvY3VtZW50Lg0KDQpCZWxvdyBzb21lIHJlYWN0aW9ucyBvbiB5b3VyIHJl YWN0aW9ucy4gSG9wZSB0aGlzIGhlbHBzIHRvIGNsYXJpZnkgDQptaXN1bmRlcnN0YW5kaW5ncy4N Cg0KUGV0ZXINCg0KRGlqaywgRXNrbyBzY2hyZWVmIG9wIDIwMTItMTItMTkgMTQ6MjQ6DQo+IEhp IFBldGVyLA0KPg0KPiBzdGlsbCBhIGZhaXIgbnVtYmVyIG9mIGNvbW1lbnRzISBJIHdvdWxkIGFn cmVlIHdpdGggbW9zdC4gQmVsb3cgSSBoYXZlDQo+IHNlbGVjdGVkIHNvbWUgd2hpY2ggd2Ugc2hv dWxkIGRpc2N1c3MgZnVydGhlciwgb3Igb25lcyBJIGRvbuKAmXQgYWdyZWUNCj4gd2l0aDoNCj4N Cj4gMS4gR3JvdXAgY29tbXVuaWNhdGlvbiBkZWZpbml0aW9uIC0+DQo+ICBXaHkgY2FuJ3QgYSBz b3VyY2Ugbm9kZSBiZSBwYXJ0IG9mIHRoZSBncm91cCB0aGF0IGl0IHNlbmRzIHRvPyBFLmcuDQo+ IGNvbWJpbmVkIHNlbnNvcitsdW1pbmFpcmUgdXNlIGNhc2UuIFRoZSBJUCBzdGFjayB3b3VsZCBk ZWxpdmVyIHNlbnQNCj4gbXVsdGljYXN0IENvQVAgcmVxdWVzdHMgYWxzbyB0byB0aGUgbG9jYWwg YXBwbGljYXRpb24gaWYgaXQgaXMNCj4gc3Vic2NyaWJlZCB0byB0aGUgbXVsdGljYXN0IElQIGFk ZHJlc3MuDQpzb3VyY2UgY2FuIG9mIGNvdXJzZSBiZSBtZW1iZXIgb2YgZGVzdGluYXRpb24gZ3Jv dXAuDQpzb3VyY2UgbWF5IGJlIHBhcnQgb2YgdGhlIGdyb3VwIChyZW1vdmUgdGhlICJvciBtYXkg YmUgbm90IiBwYXJ0IG9mIHRoZQ0KcGhyYXNlKQ0KPg0KPiAyLiBJIGRvbuKAmXQgc2VlIHdoeSB3 ZSBzaG91bGQgYWRkIOKAnHRoZSB1c2Ugb2YgZ3JvdXAgY29tbXVuaWNhdGlvbiBmb3INCj4gbURO UyBpcyBvdXQgb2Ygc2NvcGUu4oCdIC0+ICBtRE5TIG9idmlvdXNseSBpcyBub3QgQ29BUCwgYW5k IHRoZQ0KPiBkb2N1bWVudCBzaG91bGQgZGVmaW5lIHRoZSBzY29wZSBhbnl3YXkgY2xlYXJseSBh cyBDb0FQIGdyb3VwDQo+IGNvbW11bmljYXRpb24uIFNvIHdlIGRvbuKAmXQgaGF2ZSB0byBsaXN0 IGFueSBvdGhlciBwcm90b2NvbHMgdGhhbiBDb0FQLg0KU2VlIG15IGFuc3dlciBvbiByZXR1cm4g b2YgcGFja2V0cy4gSSB3YW50ZWQgYSBjbGVhciBzdGF0ZW1lbnQgb24gKE5PVCkgDQpzcGVjaWZ5 aW5nIGhvdyBhcHBsaWNhdGlvbnMgaGFuZGxlIHRoZSByZXR1cm4gb2YgTUMgcmVzcG9uc2VzLg0K DQo+DQo+IDMuIOKAnHNvIHNldHRpbmcgYSBtdWx0aWNhc3QgYWRkcmVzcyBpbiBhIHNvdXJjZSBh dCBpbnN0YWxsYXRpb24gaXMNCj4gZm9yYmlkZGVuP+KAnSAtPiAgTm8sIHRoYXQgc2hvdWxkIG5v dCBiZSBmb3JiaWRkZW4gOikgSXQgc2hvdWxkIGFsc28gYmUNCj4gcG9zc2libGUgdG8gc2V0IGEg Q29BUCBwYXRoIGFuZC9vciBwb3J0IGF0IGluc3RhbGxhdGlvbiB0aW1lLiBUaGF0DQo+IG1lYW5z IHRoZSB0d28gcHJlc2VudGVkIG1lYXN1cmVzIGhhdmUgdG8gY2hhbmdlIG9yIGJlIHJlbW92ZWQu DQpObyBjb21tZW50DQo+DQo+IDQuIOKAnHRoZXJlIGFyZSAyIHdheXM6ICgxKSB0aGUgbm9kZSBx dWVyaWVzIHRvIHdoaWNoIGdyb3VwIGl0IGJlbG9uZ3MNCj4gb3IgKDIpIGFuIGluc3RhbGF0aW9u IHRvb2xzIGluc3RydWN0cyB0aGUgbm9kZSB0byB3aGljaCBncm91cHPigJ0gLT4NCj4gR29vZCBw b2ludC4gKDIpIGhhcyBiZWVuIGNob3NlbiBiZWNhdXNlIGl0IHdvcmtzIHdpdGhvdXQgcmVseWlu ZyBvbiBhDQo+IHNlcnZpY2UgdG8gcXVlcnkgKGUuZy4gRE5TIG9yIFJEKS4gSXMgdGhhdCBzdWZm aWNpZW50IGFyZ3VtZW50YXRpb24/DQo+IFRoZSBtZWNoYW5pc20gaXMgb3B0aW9uYWwgaW4gYW55 IGNhc2Ugc28gaXQgZG9lcyBub3QgYmxvY2sgb3RoZXJzIGZyb20NCj4gZGVmaW5pbmcgYSBETlMg b3IgUkQgdmFyaWFudC4NCkkgd291bGQgcG9pbnQgb3V0IGJvdGggdmFyaWFudHMgYW5kIG1lbnRp b24gdGhhdCB0aGUgZHJhZnQgZm9jdXNzZXMgb24NCigyKQ0KPg0KPiA1LiDigJwvcyByZXF1ZXN0 cyAvcyByZXBsaWVz4oCdIC0+DQo+ICBtdWx0aWNhc3QgcmVwbGllcyAoaWYgeW91IG1lYW4gcmVz cG9uc2VzKSBkbyBub3QgZXhpc3QgaW4gQ29BUC4gSXTigJlzDQo+IGFib3V0IHJlcXVlc3RzIHRo YXQgc2hvdWxkIGJlIGNhcmVmdWxseSBjb250cm9sbGVkIHNpbmNlIHRoZXkgZ2VuZXJhdGUNCj4g dW5pY2FzdCByZXNwb25zZXMuDQpUaGVuIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHRleHQsIGJl Y2F1c2UgInJlcXVlc3QiLCAicmVwbHkiIGFuZCAicmVzcG9uc2UiIA0KYXJlIG92ZXJsb2FkZWQg aW4gbXkgbWluZC4NCj4NCj4gNi4g4oCcL2NvbW1lbnQgd2hhdCBhYm91dCB0aGUgcmVwbHk/4oCd IC0+ICBiYXNlZCBvbiBjb3JlLWNvYXAg4oCcSWYgdGhlDQo+IHJlcXVlc3QgbWVzc2FnZSBpcyBO b24tY29uZmlybWFibGUsIHRoZW4gdGhlIHJlc3BvbnNlIFNIT1VMRCBiZQ0KPiByZXR1cm5lZCBp biBhIE5vbi1jb25maXJtYWJsZSBtZXNzYWdlIGFzIHdlbGwu4oCdDQo+IC4gRG8geW91IHRoaW5r IHdlIHNob3VsZCBxdW90ZSB0aGlzIGZyb20gdGhlIGNvcmUtY29hcCBzcGVjPw0KQXMgZXhwbGFp bmVkIGFib3ZlIFRoZSBzdWJqZWN0IG9mIHJldHVybmluZyBwYWNrZXRzIHRvIHRoZSBNQyBzZW5k ZXIgbmVlZHMgDQpjYXJlZnVsIGNvbnNpZGVyYXRpb24uDQp0aGUgcmVzcG9uc2UgYmVpbmcgTk9u LWNvbmZpcm1hYmxlIGRvZXMgbm90IHNvbHZlIGEgbG90IEkgYW0gYWZyYWlkLg0KPg0KPiA3LiDi gJwvY29tbWVudCBpbnZva2luZyBhcyBtYW55IGNlcnRpZmljYXRlcz/igJ0gLT4NCj4gIGNvcmUt Y29hcC0xMyBub3cgbG9vc2VucyB0aGUgY29uY2VwdCBvZiBhdXRoZW50aWNhdGlvbiB0byBhbHNv DQo+IGluY2x1ZGUgb3RoZXIgbWVhc3VyZXMsIG5vdCBuZWVkaW5nIGNlcnRpZmljYXRlcy4NCk5v IGNvbW1lbnQNCj4NCj4gOC4gTmV0d29yayBjb25maWd1cmF0aW9uOiAyIHN1Ym5ldHMgdnMgMSAt PiAgbWF5YmUgYSBvbmUtc3VibmV0DQo+IGNvbmZpZ3VyYXRpb24gaXMgd29ydGggYWRkaW5nPyBI ZXJlIGFuIG92ZXJ2aWV3IG9mIHByZXNlbnQvYWJzZW50IHVzZQ0KPiBjYXNlczoNCj4NCj4gIC0g TGluay1sb2NhbCBDb0FQIG11bHRpY2FzdCB3aXRoIHJlc3BvbnNlczogUHJlc2VudCwgQXBwZW5k aXggQSBvZg0KPiBjb3JlLWNvYXANCj4gIC0gU2l0ZS1sb2NhbCBDb0FQIG11bHRpY2FzdCwgc2lu Z2xlIHN1Ym5ldDogPG1pc3Npbmc+DQo+ICAtIFNpdGUtbG9jYWwgQ29BUCBtdWx0aWNhc3QsIG11 bHRpIHN1Ym5ldCwgd2l0aCBvciB3aXRob3V0IHJlc3BvbnNlcw0KPiAoaW4gdGhlIG5ldyAtMDQg Z3JvdXBjb21tKTogUHJlc2VudA0KPiAgLSBHbG9iYWwgQ29BUCBtdWx0aWNhc3QsIHNpbmdsZSBv ciBtdWx0aSBzdWJuZXQsIHdpdGggb3Igd2l0aG91dA0KPiByZXNwb25zZXM6IDxtaXNzaW5nPiAv IGRlcGVuZGVuY3kgb24gSUFOQSBJUHY2IGFsbG9jYXRpb24NCj4gIC0gYW55IGNvbmZpZ3VyYXRp b25zIHdpdGggYSBjZW50cmFsIGNvbnRyb2xsZXIgb24gdGhlIGJhY2tib25lDQo+IG11bHRpY2Fz dGluZzogPG1pc3Npbmc+DQoNCkFnYWluLCB0aGUgZHJhZnQgc2hvdWxkIGdvIGZvciB0aGUgbW9z dCBmcmVxdWVudCB1c2UgY2FzZXMgYW5kIG5vdCB0cnkgdG8gYmUgDQpjb21wbGV0ZS4NCkFjdHVh bGx5IGV4cGxpY2l0bHkgZXhjbHVkaW5nIHVzZSBjYXNlcyBsb29rcyBpbmVyZXN0aW5nIHRvIG1l Lg0KPg0KPiA5LiDigJxJdCBtaWdodCBiZSB1c2VmdWwgaWYgdGhlIHByYWN0aWNhbCBpbXBvc3Np YmlsaXR5IG9mIHNvbWUNCj4gY29uZmlndXJhdGlvbnMgaXMgaGlnaCBsaWdodGVk4oCdIC0+ICBh bnkgdGhvdWdodHMsIHdoaWNoIHdvdWxkIGJlDQo+IGltcG9zc2libGU/DQpEdXJpbmcgdGhlIGNv YXAgbWVldGluZyBpbiBBdGxhbnRhLCBDdWxsZW4gSmVubmluZ3MgcHJlc2VudGVkIHNvbWUgDQpo b3JyaWZ5aW5nIGV4YW1wbGVzLCBhcyBmYXIgYXMgSSByZW1lbWJlci4NCg0KPg0KPiAxMC7igJx0 aGUgUkQgZGlzY292ZXJ5IHdpbGwgYmUgbW9yZSBjb21wbGV4IHdoZW4gdGhlcmUgaXMgYSByb3V0 ZXINCj4gYmV0d2VlbiBsaWdodC0yIGFuZCBzd2l0Y2jigJ0gLT4gIHllcywgdGhlcmUgYXJlIGlz c3VlcyBpbiBSRC9kaXNjb3ZlcnkNCj4gZXNwZWNpYWxseSB3aGVuIG1vcmUgdGhhbiBvbmUgaXMg cHJlc2VudCBpbiBhIG5ldHdvcmsuDQpTbywgYWRhcHQgdGhlIHVzZSBjYXNlIGFuZCBleGNsdWRl IHRoaXMgcG9zc2liaWxpdHkuDQo+DQo+IDExLuKAnGFkZGl0aW9uYWwgcmVhc29uIHRvIHJlbW92 ZSByb3V0ZXIgZnJvbSB0aGUgbXVsdGljYXN0DQo+IGNvbmZpZ3VyYXRpb27igJ0tPiAgaG1tLCBJ IHRoaW5rIHRoYXQgd2Ugc2hvdWxkIG9wdCBmb3IgaGF2aW5nIGEgc2luZ2xlDQo+IFJEIGluIHRo ZSBzeXN0ZW0gdG8gYXZvaWQgY29tcGxleGl0eS4gUm91dGVycyBhcmUgb2suIChPbmUgb2Ygb3Vy DQo+IGdvYWxzIGlzIHRvIGRlZmluZSBob3cgQ29BUCBncm91cGNvbW0gd29ya3MgZXZlbiBhY3Jv c3Mgcm91dGVycykNCkxvb2tpbmcgZm9yd2FyZCB0byB0aGUgc3VwcG9ydGluZyBwcm90b2NvbC4N Cj4NCj4gMTIu4oCcTUxEIGlzIHVzZWQgdG8gZm9ybSBncm91cHMsIGNvcnJlY3Q/IGJ1dCB0aGF0 IHdhcyBhbHJlYWR5IGRvbmUgYnkNCj4gZW5hYmxpbmcgdGhlIE1DIGFkZHJlc3MgaW4gdGhlIGxp Z2h0cyAocG9pbnQgMinigJ0gLT4gIFN0ZXAgMSBpcyBwdXR0aW5nDQo+IHRoZSBNQyBhZGRyZXNz IGluIHRoZSBsaWdodHMsIHRoZW4gc3RlcCAyIGlzIHRoZSBMaWdodHMgdXNlIE1MRCB0bw0KPiAq QURWRVJUSVpFKiB0aGlzIGFkZHJlc3MgdG8gYW55IE1MRC1lbmFibGVkIFJvdXRlcnMgcHJlc2Vu dA0KPiBsaW5rLWxvY2FsLg0KPiAgU28gTUxEIGlzIG5vdCBhIGNvbW1pc3Npb25pbmctdGltZSBw cm90b2NvbCBidXQgcnVucyBhbGwgdGhlIHRpbWUNCj4gZHVyaW5nIG9wZXJhdGlvbi4NCj4gIE5v dGUgdGhhdCBpbiBncm91cGNvbW0gLTA0IHdlIHdpbGwgcmVtb3ZlIE1MRCBpbiB0aGUgYmFzaWMg dXNlIGNhc2UNCj4gYW5kIHByZXNlbnQgaXQgYXMgYW4gb3B0aW9uIGxhdGVyLg0KDQpTb3VuZHMg Z29vZC4gVGhlIHBvaW50IGlzIG5vdCB0byBhZGQgcHJvdG9jb2xzIGJlY2F1c2UgdGhleSBleGlz dCBidXQgDQpiZWNhdXNlIHRoZXkgYXJlIG5lZWRlZC4NCj4NCj4gMTMu4oCcV0hZIGFyZSB0aGUg bXVsdGljYXN0IGRlc3RpbmF0aW9ucyBzZW5kaW5nIGJhY2sgcmVzdWx0cz/igJ0gLT4gIHdlDQo+ IHJlbW92ZSByZXNwb25zZXMgaW4gdGhlIG5ldyAtMDQgZ3JvdXBjb21tLiBUaGV5IGFyZSBwcmVz ZW50ZWQgYXMgYW4NCj4gb3B0aW9uYWwgdGhpbmcgdGhhdCBzZXJ2ZXJzIGNhbiBkby4NCj4gIENv QVAgc2VydmVycyBub3JtYWxseSBNVVNUIHJlc3BvbmQgdG8gYSByZXF1ZXN0IHdpdGggYSByZXNw b25zZQ0KPiAoY29yZS1jb2FwLTEzKSBidXQgYW4gZXhjZXB0aW9uIGlzIG5vdyBtYWRlIGZvciBt dWx0aWNhc3Qgd2hlcmUgYQ0KPiBzZXJ2ZXIgTUFZIGNob29zZSBub3QgdG8uIFRoaXMgY2hvaWNl IGlzIGNvbXBsZXRlbHkgaW5kZXBlbmRlbnQgZnJvbQ0KPiBjb25maXJtYWJsZS9ub24tY29uZmly bWFibGUuIE5vbi1jb25maXJtYWJsZSBvbmx5IG1lYW5zIHRoYXQgYW4gQUNLDQo+IG11c3Qgbm90 IGJlIHNlbnQuIEFuZCBhbiBBQ0sgaXMgc29tZXRoaW5nIGRpZmZlcmVudCBmcm9tIGEgQ29BUA0K PiByZXNwb25zZS4NCj4gIEFncmVlIHRoYXQgYSBwcm90b2NvbCBsaWtlIE1QTCBjb21lcyB2ZXJ5 IGNsb3NlIHRvIOKAmHJlbGlhYmxlDQo+IG11bHRpY2FzdOKAmS4NCg0Kc2VlIG15IHdvcnJpZXMg YXQgdGhlIGJlZ2lubmluZy4NCj4NCj4gRXNrbw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiAgRnJvbTogcGV0ZXIgdmFuIGRlciBTdG9rIFttYWlsdG86c3Rva2NvbnNAeHM0YWxs Lm5sXQ0KPiAgU2VudDogVHVlc2RheSAxOCBEZWNlbWJlciAyMDEyIDEyOjA2DQo+ICBUbzogYWti YXIgcmFobWFuOyBEaWprLCBFc2tvOyBDb3JlDQo+ICBTdWJqZWN0OiBncm91cC1jb21tIGNvbW1l bnRzDQo+DQo+IEhpIEFrYmFyIGFuZCBFc2tvLA0KPg0KPiBJIGhhZCBwcm9taXNlZCB0byByZXZp ZXcsIGNvbW1lbnQgdGhlIGdyb3VwIGNvbW0gZHJhZnQuDQo+DQo+IEJlbG93IHRoZSBjb21tZW50 ZWQgdGV4dC4NCj4NCj4gSSBoYXZlIG5vdCBnb25lIHZlcnkgZGV0YWlsZWQgd2l0aCBteSBjb21t ZW50cy4gSSBob3BlIHRoYXQgaXQgaXMNCj4gY2xlYXIgZnJvbSBteSBjb21tZW50cyB0aGF0IGEg cmVvcmdhbml6YXRpb24gb2YgdGhlIGRyYWZ0IGFuZCBhIHJldmlldw0KPiBvZiB0aGUgdXNlcyBj YXNlcyBhcmUgbmVjZXNzYXJ5IHRvIGdldCBhIGNsZWFyZXIgcGljdHVyZSBvZiB0aGUNCj4gZmVh c2liaWxpdHkgb2YgZ3JvdXAgY29tbSBpbiB0aGUgY29udGV4dCBvZiBDb2FwLg0KPg0KPiBFc3Bl Y2lhbHkgZGlmZmljdWx0IHRvIHVuZGVyc3RhbmQgZm9yIG1lIHdlcmU6DQo+DQo+IC0gdGhlIHVz ZSBjYXNlIG5ldHdvcmsgY29uZmlndXJhdGlvbg0KPg0KPiAtIHRoZSBmb3JtaW5nIGFuZCBlbmFi bGluZyBvZiBncm91cHMNCj4NCj4gLSB1c2Ugb2YgcmVzcG9uc2VzDQo+DQo+IEhvcGUgdGhpcyBo ZWxwcy4NCj4NCj4gR3JlZXRpbmdzLA0KPg0KPiBwZXRlcg0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4NCj4gQWJzdHJhY3QNCj4NCj4g IENvQVAgaXMgYSBSRVNUZnVsIHRyYW5zZmVyIHByb3RvY29sIGZvciBjb25zdHJhaW5lZCBkZXZp Y2VzLiBJdCBpcw0KPg0KPiAgYW50aWNpcGF0ZWQgdGhhdCBjb25zdHJhaW5lZCBkZXZpY2VzIHdp bGwgb2Z0ZW4gbmF0dXJhbGx5IG9wZXJhdGUgaW4NCj4NCj4gIGdyb3VwcyAoZS5nLiBpbiBhIGJ1 aWxkaW5nIGF1dG9tYXRpb24gc2NlbmFyaW8gYWxsIGxpZ2h0cyBpbiBhIGdpdmVuDQo+DQo+ICBy b29tIG1heSBuZWVkIHRvIGJlIHN3aXRjaGVkIG9uL29mZiBhcyBhIGdyb3VwKS4gVGhpcyBkb2N1 bWVudA0KPg0KPiAgZGVmaW5lcyBob3cgdGhlIENvQVAgcHJvdG9jb2wgc2hvdWxkIGJlIHVzZWQg aW4gYSBncm91cCBjb21tdW5pY2F0aW9uDQo+DQo+ICBjb250ZXh0LiBBbiBhcHByb2FjaCBmb3Ig dXNpbmcgQ29BUCBvbiB0b3Agb2YgSVAgbXVsdGljYXN0IGlzDQo+DQo+ICBkZXRhaWxlZCBmb3Ig Ym90aCBjb25zdHJhaW5lZCBhbmQgdW4tY29uc3RyYWluZWQgbmV0d29ya3MuIEFsc28sDQo+DQo+ ICB2YXJpb3VzIHVzZQ0KPg0KPiAvcyBjYXVzZXMgL3MgY2FzZXMvDQo+DQo+ICBhbmQgY29ycmVz cG9uZGluZyBwcm90b2NvbCBmbG93cyBhcmUgcHJvdmlkZWQgdG8NCj4NCj4gIGlsbHVzdHJhdGUg aW1wb3J0YW50IGNvbmNlcHRzLiBGaW5hbGx5LCBndWlkYW5jZSBpcyBwcm92aWRlZCBmb3INCj4N Cj4gIGRlcGxveW1lbnQgaW4gdmFyaW91cyBuZXR3b3JrIHRvcG9sb2dpZXMuDQo+DQo+IFN0YXR1 cyBvZiB0aGlzIE1lbW8NCj4NCj4gIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNCj4NCj4gIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFu ZCBCQ1AgNzkuDQo+DQo+ICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KPg0KPiAgVGFzayBGb3JjZSAoSUVURikuIE5vdGUg dGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KPg0KPiAgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0K Pg0KPiAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3Vy cmVudC8gWzFdLg0KPg0KPiAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQo+DQo+ICBhbmQgbWF5IGJlIHVwZGF0ZWQs IHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KPg0KPiAg dGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy ZW5jZQ0KPg0KPiAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsg aW4gcHJvZ3Jlc3MuIg0KPg0KPiAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBB cHJpbCAyMiwgMjAxMy4NCj4NCj4gQ29weXJpZ2h0IE5vdGljZQ0KPg0KPiAgQ29weXJpZ2h0IChj KSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQo+DQo+ ICBkb2N1bWVudCBhdXRob3JzLiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KPg0KPiAgVGhpcyBkb2N1 bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KPg0K PiAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KPg0KPiAgKGh0dHA6Ly90 cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbyBbMl0pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBv Zg0KPg0KPiBSYWhtYW4gJiBEaWprIEV4cGlyZXMgQXByaWwgMjIsIDIwMTMgW1BhZ2UNCj4NCj4g MV0NCj4NCj4gSW50ZXJuZXQtRHJhZnQgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCBPY3Rv YmVyDQo+DQo+IDIwMTINCj4NCj4gIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFBsZWFz ZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQo+DQo+ICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3Jp YmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCj4NCj4gIHRvIHRo aXMgZG9jdW1lbnQuIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50 IG11c3QNCj4NCj4gIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KPg0KPiAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMg YW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQo+DQo+ICBkZXNjcmliZWQgaW4g dGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQo+DQo+IDEuIENvbnZlbnRpb25zIGFuZCBUZXJt aW5vbG9neQ0KPg0KPiAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJF RCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KPg0KPiAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwg IlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCj4NCj4gIGRvY3Vt ZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0KPg0K PiAgVGhpcyBkb2N1bWVudCBhc3N1bWVzIHJlYWRlcnMgYXJlIGZhbWlsaWFyIHdpdGggdGhlIHRl cm1zIGFuZA0KPg0KPiAgY29uY2VwdHMgdGhhdCBhcmUgdXNlZCBpbiBbSS1ELmlldGYtY29yZS1j b2FwXS4gSW4gYWRkaXRpb24sIHRoaXMNCj4NCj4gIGRvY3VtZW50IGRlZmluZXMgdGhlIGZvbGxv d2luZyB0ZXJtaW5vbG9neToNCj4NCj4gIEdyb3VwIENvbW11bmljYXRpb24NCj4NCj4gIEEgc291 cmNlIG5vZGUgc2VuZHMgYSBzaW5nbGUgbWVzc2FnZSB3aGljaCBpcyBkZWxpdmVyZWQgdG8NCj4N Cj4gIG11bHRpcGxlIGRlc3RpbmF0aW9uIG5vZGVzLCB3aGVyZSBhbGwgZGVzdGluYXRpb25zIGFy ZSBpZGVudGlmaWVkDQo+DQo+ICB0byBiZWxvbmcgdG8gYSBzcGVjaWZpYyBncm91cC4gVGhlIHNv dXJjZSBub2RlIG1heQ0KPg0KPiAvcmVtb3ZlIG9yIG1heSBub3QNCj4NCj4gIGJlDQo+DQo+ICBw YXJ0IG9mIHRoZSBncm91cC4gVGhlIHVuZGVybHlpbmcgbWVjaGFuaXNtIGZvciBncm91cA0KPg0K PiAgY29tbXVuaWNhdGlvbiBpcyBhc3N1bWVkIHRvIGJlIG11bHRpY2FzdCBiYXNlZC4NCj4NCj4g L3JlbW92ZQ0KPg0KPiAgVGhlIG5ldHdvcmsgd2hlcmUNCj4NCj4gIHRoZSBncm91cCBjb21tdW5p Y2F0aW9uIHRha2VzIHBsYWNlIGNhbiBiZSBlaXRoZXIgYSBjb25zdHJhaW5lZA0KPg0KPiBvcg0K Pg0KPiAgYSByZWd1bGFyICh1bi1jb25zdHJhaW5lZCkgbmV0d29yay8NCj4NCj4gL2NvbW1lbnQg bm90IHN1cmUgYWJvdXQgdGhlIG1lYW5pbmcgYW5kIGNvbnNlcXVlbmNlcw0KPg0KPiAgTXVsdGlj YXN0DQo+DQo+ICBTZW5kaW5nIGEgbWVzc2FnZSB0byBtdWx0aXBsZSBkZXN0aW5hdGlvbiBub2Rl cw0KPg0KPiAvcyBzaW11bHRhbmVvdXNseS4vDQo+DQo+IC9zIHdpdGggb25lIG5ldHdvcmsgaW52 b2NhdGlvbiAvDQo+DQo+ICBUaGVyZSBhcmUgdmFyaW91cyBvcHRpb25zIHRvIGltcGxlbWVudCBt dWx0aWNhc3QgaW5jbHVkaW5nIGxheWVyDQo+DQo+IDINCj4NCj4gIChNZWRpYSBBY2Nlc3MgQ29u dHJvbCkgb3IgbGF5ZXIgMyAoSVApIG1lY2hhbmlzbXMuDQo+DQo+ICBJUCBNdWx0aWNhc3QNCj4N Cj4gIEEgc3BlY2lmaWMgbXVsdGljYXN0IHNvbHV0aW9uIGJhc2VkIG9uIHRoZSB1c2Ugb2YgSVAg bXVsdGljYXN0DQo+DQo+ICBhZGRyZXNzZXMgYXMgZGVmaW5lZCBpbiAiSUFOQSBHdWlkZWxpbmVz IGZvciBJUHY0IE11bHRpY2FzdA0KPg0KPiAgQWRkcmVzcyBBc3NpZ25tZW50cyIgW1JGQzU3NzFd IGFuZCAiSVAgVmVyc2lvbiA2IEFkZHJlc3NpbmcNCj4NCj4gIEFyY2hpdGVjdHVyZSIgW1JGQzQy OTFdLg0KPg0KPiAgTG93IHBvd2VyIGFuZCBMb3NzeSBOZXR3b3JrIChMTE4pDQo+DQo+ICBMb3cg cG93ZXIgYW5kIExvc3N5IE5ldHdvcmsgKExMTik6IEEgdHlwZSBvZiBjb25zdHJhaW5lZCBuZXR3 b3JrDQo+DQo+ICB3aGVyZSB0aGUgZGV2aWNlcyBhcmUgaW50ZXJjb25uZWN0ZWQgYnkgYSB2YXJp ZXR5IG9mIGxvdyBwb3dlciwNCj4NCj4gIGxvc3N5IGxpbmtzIHN1Y2ggYXMgSUVFRSA4MDIuMTUu NCwgQmx1ZXRvb3RoLA0KPg0KPiA8bm90IHNvIGNvbnN0cmFpbmVkPiBXaUZpLCB3aXJlZCA8Lz4N Cj4NCj4gIG9yIGxvdw0KPg0KPiAgcG93ZXIgcG93ZXItbGluZSBjb21tdW5pY2F0aW9uIGxpbmtz Lg0KPg0KPiAyLiBJbnRyb2R1Y3Rpb24NCj4NCj4gMi4xLiBCYWNrZ3JvdW5kDQo+DQo+ICBUaGUg Q29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApIGlzIGFuIGFwcGxpY2F0aW9u DQo+DQo+ICBwcm90b2NvbCAoYW5hbG9nb3VzIHRvIEhUVFApIGZvciByZXNvdXJjZSBjb25zdHJh aW5lZCBkZXZpY2VzDQo+DQo+ICBvcGVyYXRpbmcgaW4gYW4gSVAgbmV0d29yayBbSS1ELmlldGYt Y29yZS1jb2FwXS4gQ29uc3RyYWluZWQNCj4NCj4gZGV2aWNlcw0KPg0KPiAgY2FuIGJlIGxhcmdl IGluIG51bWJlciwgYnV0IGFyZSBvZnRlbiBoaWdobHkgY29ycmVsYXRlZCB0byBlYWNoDQo+DQo+ IG90aGVyDQo+DQo+ICAoZS5nLiBieSB0eXBlIG9yIGxvY2F0aW9uKS4gRm9yIGV4YW1wbGUsIGFs bCB0aGUgbGlnaHQgc3dpdGNoZXMgaW4NCj4NCj4gYQ0KPg0KPiAgYnVpbGRpbmcgbWF5IGJlbG9u ZyB0byBvbmUgZ3JvdXAgYW5kIGFsbCB0aGUgdGhlcm1vc3RhdHMgbWF5IGJlbG9uZw0KPg0KPiAg dG8gYW5vdGhlciBncm91cC4gR3JvdXBzIG1heSBiZSBjb21wb3NlZCBieSBmdW5jdGlvbi4gRm9y IGV4YW1wbGUsDQo+DQo+IFJhaG1hbiAmIERpamsgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyBbUGFn ZQ0KPg0KPiAzXQ0KPg0KPiBJbnRlcm5ldC1EcmFmdCBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBD b0FQIE9jdG9iZXINCj4NCj4gMjAxMg0KPg0KPiAgdGhlIGdyb3VwICJhbGwgbGlnaHRzIGluIGJ1 aWxkaW5nIG9uZSIgbWF5IGNvbnNpc3Qgb2YgdGhlIGdyb3Vwcw0KPg0KPiAiYWxsDQo+DQo+ICBs aWdodHMgb24gZmxvb3Igb25lIG9mIGJ1aWxkaW5nIG9uZSIsICJhbGwgbGlnaHRzIG9uIGZsb29y IHR3byBvZg0KPg0KPiAgYnVpbGRpbmcgb25lIiwgZXRjLiBHcm91cHMgbWF5IGJlIHByZWNvbmZp Z3VyZWQNCj4NCj4gL2FkZCBiZWZvcmUgZGVwbG95bWVudA0KPg0KPiAgb3IgZHluYW1pY2FsbHkN Cj4NCj4gIGZvcm1lZA0KPg0KPiAvYWRkIGR1cmluZyBvcGVyYXRpb24NCj4NCj4gIC4gSWYgaW5m b3JtYXRpb24gbmVlZHMgdG8gYmUgc2VudCB0byBvciByZWNlaXZlZCBmcm9tIGEgZ3JvdXANCj4N Cj4gIG9mIGRldmljZXMsIGdyb3VwIGNvbW11bmljYXRpb24gbWVjaGFuaXNtcyBjYW4gaW1wcm92 ZSBlZmZpY2llbmN5DQo+DQo+IGFuZA0KPg0KPiAgbGF0ZW5jeSBvZiBjb21tdW5pY2F0aW9uIGFu ZCByZWR1Y2UgYmFuZHdpZHRoIHJlcXVpcmVtZW50cyBmb3IgYQ0KPg0KPiAgZ2l2ZW4gYXBwbGlj YXRpb24uIEhUVFAgZG9lcyBub3Qgc3VwcG9ydCBhbnkgZXF1aXZhbGVudA0KPg0KPiAgZnVuY3Rp b25hbGl0eSB0byBDb0FQIGdyb3VwIGNvbW11bmljYXRpb24uDQo+DQo+IDIuMi4gU2NvcGUNCj4N Cj4gIEluIHRoaXMgZHJhZnQsIHdlIGFkZHJlc3MgdGhlIGlzc3VlcyByZWxhdGVkIHRvIENvQVAg Z3JvdXANCj4NCj4gIGNvbW11bmljYXRpb24gaW4gZGV0YWlsLCB3aXRoIHVzZSBjYXNlcywgcmVj b21tZW5kZWQgYXBwcm9hY2hlcyBhbmQNCj4NCj4gIGFuYWx5c2lzIG9mIHRoZSBpbXBhY3QgdG8g dGhlIENvQVAgcHJvdG9jb2wgYW5kIHRvIGltcGxlbWVudGF0aW9ucy4NCj4NCj4gL2FkZCB0aGUg dXNlIG9mIGdyb3VwIGNvbW11bmljYXRpb24gZm9yIG1ETlMgaXMgb3V0IG9mIHNjb3BlLg0KPg0K PiAgVGhlIGd1aWRpbmcgcHJpbmNpcGxlIGlzIHRvIGFwcGx5IHdoZXJldmVyIHBvc3NpYmxlIGV4 aXN0aW5nIElFVEYNCj4NCj4gIHByb3RvY29scyB0byBhY2hpZXZlIGdyb3VwIGNvbW11bmljYXRp b24gZnVuY3Rpb25hbGl0eS4gSW4gbWFueQ0KPg0KPiAgY2FzZXMgdGhlIGNvbnRyaWJ1dGlvbiBv ZiB0aGlzIGRvY3VtZW50IGxpZXMgaW4gZXhwbGFpbmluZyBob3cNCj4NCj4gIGV4aXN0aW5nIG1l Y2hhbmlzbXMgbWF5IGJlIHVzZWQgdG8NCj4NCj4gL3JlbW92ZSB0b2dldGhlcg0KPg0KPiAgZnVs ZmlsbCBDb0FQIGdyb3VwDQo+DQo+ICBjb21tdW5pY2F0aW9uIG5lZWRzIGZvciBzcGVjaWZpYyB1 c2UgY2FzZXMuDQo+DQo+IDIuMy4gUG90ZW50aWFsIFNvbHV0aW9ucyBmb3IgR3JvdXAgQ29tbXVu aWNhdGlvbg0KPg0KPiAgVGhlIGNsYXNzaWMgY29uY2VwdCBvZiBncm91cA0KPg0KPiAvcyBjb21t dW5pY2F0aW9ucyAvcyBjb21tdW5pY2F0aW9uDQo+DQo+ICBpcyB0aGF0IG9mIGEgc2luZ2xlDQo+ DQo+ICBzb3VyY2UgZGlzdHJpYnV0aW5nIGNvbnRlbnQgdG8gbXVsdGlwbGUgZGVzdGluYXRpb24g cmVjaXBpZW50cyB0aGF0DQo+DQo+ICBhcmUgYWxsIHBhcnQgb2YgYSBncm91cC4gQmVmb3JlIGNv bnRlbnQgY2FuIGJlIGRpc3RyaWJ1dGVkLCB0aGVyZQ0KPg0KPiBpcw0KPg0KPiAgYSBzZXBhcmF0 ZSBwcm9jZXNzIHRvIGZvcm0gdGhlIGdyb3VwLiBUaGUgc291cmNlIG1heSBiZSBlaXRoZXIgYQ0K Pg0KPiAgbWVtYmVyIG9yIG5vbi1tZW1iZXIgb2YgdGhlIGdyb3VwLg0KPg0KPiAgR3JvdXAgY29t bXVuaWNhdGlvbiBzb2x1dGlvbnMgaGF2ZSBldm9sdmVkIGZyb20gImJvdHRvbSIgdG8gInRvcCIs DQo+DQo+ICBpLmUuLCBmcm9tIGxheWVyIDIgKE1lZGlhIEFjY2VzcyBDb250cm9sIGJyb2FkY2Fz dC9tdWx0aWNhc3QpIGFuZA0KPg0KPiAgbGF5ZXIgMyAoSVAgbXVsdGljYXN0KSB0byBhcHBsaWNh dGlvbiBsYXllciBncm91cCBjb21tdW5pY2F0aW9uLA0KPg0KPiBhbHNvDQo+DQo+ICByZWZlcnJl ZCB0byBhcyBhcHBsaWNhdGlvbiBsYXllciBtdWx0aWNhc3QuIEEgc3R1ZHkgcHVibGlzaGVkIGlu DQo+DQo+ICAyMDA1IFtMYW8wNV0gaWRlbnRpZmllZCBuZXcgc29sdXRpb25zIGluIHRoZSAibWlk ZGxlIiAocmVmZXJyZWQgdG8NCj4NCj4gYXMNCj4NCj4gIG92ZXJsYXkgbXVsdGljYXN0KSB0aGF0 IHV0aWxpemUgYW4gaW5mcmFzdHJ1Y3R1cmUgYmFzZWQgb24gcHJveGllcy4NCj4NCj4gIEVhY2gg b2YgdGhlc2UgY2xhc3NlcyBvZiBzb2x1dGlvbnMgbWF5IGJlIGNvbXBhcmVkIFtMYW8wNV0gdXNp bmcNCj4NCj4gIG1ldHJpY3Mgc3VjaCBhcyBsaW5rIHN0cmVzcyBhbmQgbGV2ZWwgb2YgaG9zdCBj b21wbGV4aXR5DQo+DQo+ICBbQmFuZXJqZWUwMV0uIFRoZSByZXN1bHRzIHNob3cgZm9yIGEgcmVh bGlzdGljIGludGVybmV0IHRvcG9sb2d5DQo+DQo+ICB0aGF0IElQIE11bHRpY2FzdCBpcyB0aGUg bW9zdCByZXNvdXJjZS1lZmZpY2llbnQsIHdpdGggdGhlIGRvd25zaWRlDQo+DQo+ICBiZWluZyB0 aGF0IGl0IHJlcXVpcmVzDQo+DQo+IC9zIHRoZSBtb3N0IC9zIG1vcmUgb3JnYW5pemF0aW9uYWwN Cj4NCj4gIGVmZm9ydCB0byBkZXBsb3kgaW4gdGhlDQo+DQo+ICBpbmZyYXN0cnVjdHVyZS4gSVAg TXVsdGljYXN0IGlzIHRoZSBzb2x1dGlvbiBhZG9wdGVkIGJ5IHRoaXMgZHJhZnQNCj4NCj4gIGZv ciBDb0FQIGdyb3VwIGNvbW11bmljYXRpb24uDQo+DQo+IDMuIENvQVAgR3JvdXAgQ29tbXVuaWNh dGlvbiBCYXNlZCBPbiBJUCBNdWx0aWNhc3QNCj4NCj4gUmFobWFuICYgRGlqayBFeHBpcmVzIEFw cmlsIDIyLCAyMDEzIFtQYWdlDQo+DQo+IDRdDQo+DQo+IEludGVybmV0LURyYWZ0IEdyb3VwIENv bW11bmljYXRpb24gZm9yIENvQVAgT2N0b2Jlcg0KPg0KPiAyMDEyDQo+DQo+IDMuMS4gSVAgTXVs dGljYXN0IEJhY2tncm91bmQNCj4NCj4gIElQIE11bHRpY2FzdCByb3V0aW5nIHByb3RvY29scyBo YXZlIGJlZW4gZXZvbHZpbmcgZm9yIGRlY2FkZXMsDQo+DQo+ICByZXN1bHRpbmcgaW4gcHJvcG9z ZWQgc3RhbmRhcmRzIHN1Y2ggYXMgUHJvdG9jb2wgSW5kZXBlbmRlbnQNCj4NCj4gIE11bHRpY2Fz dCAtIFNwYXJzZSBNb2RlIChQSU0tU00pIFtSRkM0NjAxXS4gWWV0LCBkdWUgdG8gdmFyaW91cw0K Pg0KPiAgdGVjaG5pY2FsIGFuZCBtYXJrZXRpbmcgcmVhc29ucywgSVAgTXVsdGljYXN0IHJvdXRp bmcgaXMgbm90IHdpZGVseQ0KPg0KPiAgZGVwbG95ZWQgb24gdGhlIGdlbmVyYWwgSW50ZXJuZXQu IEhvd2V2ZXIsIElQIE11bHRpY2FzdCBpcyB2ZXJ5DQo+DQo+ICBwb3B1bGFyIGluIHNwZWNpZmlj IGRlcGxveW1lbnRzIHN1Y2ggYXMgaW4gZW50ZXJwcmlzZSBuZXR3b3JrcyAoZS5nLg0KPg0KPiAg Zm9yIHZpZGVvIGNvbmZlcmVuY2luZyksIHNtYXJ0IGhvbWUgbmV0d29ya3MgKGUuZy4gVVBuUC9t RE5TKSBhbmQNCj4NCj4gIGNhcnJpZXIgSVBUViBkZXBsb3ltZW50cy4gVGhlIHBhY2tldCBlY29u b215IGFuZCBtaW5pbWFsIGhvc3QNCj4NCj4gIGNvbXBsZXhpdHkgb2YgSVAgbXVsdGljYXN0IG1h a2UgaXQgYXR0cmFjdGl2ZSBmb3IgZ3JvdXANCj4NCj4gY29tbXVuaWNhdGlvbg0KPg0KPiAgaW4g Y29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBUaGVyZWZvcmUgSVAgbXVsdGljYXN0IGlzIHRoZQ0K Pg0KPiAgcmVjb21tZW5kZWQgdW5kZXJseWluZyBtZWNoYW5pc20gZm9yIENvQVAgZ3JvdXAgY29t bXVuaWNhdGlvbiwgYW5kDQo+DQo+ICB0aGUgYXBwcm9hY2ggYXNzdW1lZCBpbiB0aGlzIGRvY3Vt ZW50Lg0KPg0KPiAgVG8gYWNoaWV2ZSBJUCBtdWx0aWNhc3QgYmV5b25kIGEgc3VibmV0LCBhbiBJ UCBtdWx0aWNhc3Qgcm91dGluZw0KPg0KPiAgcHJvdG9jb2wgbmVlZHMgdG8gYmUgYWN0aXZlIG9u IHJvdXRlcnMuIFRoZSBSUEwgcHJvdG9jb2wgW1JGQzY1NTBdDQo+DQo+ICBmb3IgZXhhbXBsZSBp cyBhYmxlIHRvIHJvdXRlIG11bHRpY2FzdCB0cmFmZmljIGluIGNvbnN0cmFpbmVkIExMTnMuDQo+ DQo+ICBXaGlsZSBQSU0tU00gW1JGQzQ2MDFdIGlzIG9mdGVuIHVzZWQgZm9yIG11bHRpY2FzdCBy b3V0aW5nIGluIHVuLQ0KPg0KPiAgY29uc3RyYWluZWQgbmV0d29ya3MuDQo+DQo+ICBJUCBtdWx0 aWNhc3QgY2FuIGFsc28gYmUgcnVuIGluIGEgTGluay1Mb2NhbCAoTEwpIHNjb3BlLiBUaGlzIG1l YW5zDQo+DQo+ICB0aGF0IHRoZXJlIGlzIG5vIHJvdXRpbmcgaW52b2x2ZWQgYW5kIGFuIElQIG11 bHRpY2FzdCBtZXNzYWdlIGlzDQo+DQo+IG9ubHkNCj4NCj4gIHJlY2VpdmVkDQo+DQo+IC9zIG9u IHRoZSBuZXR3b3JrIC9zIG92ZXIgdGhlDQo+DQo+ICBsaW5rIG9uIHdoaWNoIGl0IHdhcyBzZW50 Lg0KPg0KPiAzLjIuIENvQVAgR3JvdXAgRGVmaW5pdGlvbiBhbmQgTmFtaW5nDQo+DQo+ICBBIGdy b3VwIGlzIGRlZmluZWQgYXMgYSBzZXQgb2YgQ29BUCBlbmRwb2ludHMsIHdoZXJlIGVhY2ggZW5k cG9pbnQNCj4NCj4gaXMNCj4NCj4gIGNvbmZpZ3VyZWQgdG8gcmVjZWl2ZSBhIG11bHRpY2FzdCBD b0FQIHJlcXVlc3QgdGhhdCBpcyBzZW50IHRvIHRoZQ0KPg0KPiAgZ3JvdXAncyBhc3NvY2lhdGVk IElQIG11bHRpY2FzdCBhZGRyZXNzLiBUaGUgZ3JvdXAgTUFZIGhhdmUgbW9yZQ0KPg0KPiAgdGhh biBvbmUgYXNzb2NpYXRlZCBJUCBtdWx0aWNhc3QgYWRkcmVzcy4gQW4gZW5kcG9pbnQgTUFZIGJl IGENCj4NCj4gIG1lbWJlciBvZiBtdWx0aXBsZSBncm91cHMuIEdyb3VwIG1lbWJlcnNoaXAgb2Yg YW4gZW5kcG9pbnQgTUFZDQo+DQo+ICBkeW5hbWljYWxseSBjaGFuZ2Ugb3ZlciB0aW1lLiBUaGUg Z3JvdXAgTUFZIGJlIGlkZW50aWZpZWQgYnkgYQ0KPg0KPiBHcm91cA0KPg0KPiAgTmFtZSAoW0kt RC52YW5kZXJzdG9rLWNvcmUtZG5hXSkgd2hpY2ggaXMgZGVmaW5lZCBhcyBhIHByZWZpeCBzdHJp bmcNCj4NCj4gIG9mIGEgR3JvdXAgRlFETi4gVGhlIEdyb3VwIEZRRE4gY2FuIGJlIHVuaXF1ZWx5 IG1hcHBlZCB0byBhIHNpdGUtDQo+DQo+ICBsb2NhbCBvciBnbG9iYWwgbXVsdGljYXN0IElQIGFk ZHJlc3MgdmlhIEROUyByZXNvbHV0aW9uLg0KPg0KPiAgQSBDb0FQIG11bHRpY2FzdCByZXF1ZXN0 IHRoYXQgYWRkcmVzc2VzIGEgZ3JvdXAgaW5jbHVkZXMgYSBHcm91cCBVUkkNCj4NCj4gIGFzIHRo ZSByZXF1ZXN0IFVSSS4gQSBHcm91cCBVUkkgaGFzIHRoZSBzY2hlbWUgJ2NvYXAnIGFuZCBpbmNs dWRlcw0KPg0KPiAgaW4gdGhlIGF1dGhvcml0eSBwYXJ0IGVpdGhlciBhIGdyb3VwIElQIGFkZHJl c3MNCj4NCj4gL2FkZCArIG9wdGlvbmFsIHBvcnQNCj4NCj4gIG9yIGEgaG9zdG5hbWUNCj4NCj4g L2FkZCArIG9wdGlvbmFsIHBvcnQNCj4NCj4gIHRoYXQNCj4NCj4gIGNhbiBiZSByZXNvbHZlZCB0 byB0aGUgZ3JvdXAgSVAgYWRkcmVzcyAoZS5nLiwgYSBHcm91cCBOYW1lIG9yIEdyb3VwDQo+DQo+ ICBGUUROKS4gR3JvdXAgVVJJcyBNVVNUIGZvbGxvdyB0aGUgVVJJIHN5bnRheCBbUkZDMzk4Nl0u DQo+DQo+ICBBIENvQVANCj4NCj4gL3Mgbm9kZSAvcyBlbmQtcG9pbnQNCj4NCj4gIGJlY29tZXMg YSBncm91cCBtZW1iZXIgYnkgbGlzdGVuaW5nIGZvciBDb0FQIG1lc3NhZ2VzIG9uDQo+DQo+ICB0 aGUgZ3JvdXAncyBJUCBtdWx0aWNhc3QgYWRkcmVzcywgYXNzdW1pbmcgdGhlIGRlZmF1bHQgQ29B UCBVRFANCj4NCj4gcG9ydC4NCj4NCj4gIE5vdGUgdGhhdCBhIG5vbi1kZWZhdWx0IFVEUCBwb3J0 IE1BWSBiZSBzcGVjaWZpZWQgZm9yIHRoZSBncm91cDsgaW4NCj4NCj4gIHdoaWNoIGNhc2UgaW1w bGVtZW50ZXJzIE1VU1QgZW5zdXJlIHRoYXQgYWxsIGdyb3VwIG1lbWJlcnMgYXJlDQo+DQo+ICBj b25maWd1cmVkIHRvIHVzZSB0aGlzIHNhbWUgcG9ydC4NCj4NCj4gUmFobWFuICYgRGlqayBFeHBp cmVzIEFwcmlsIDIyLCAyMDEzIFtQYWdlDQo+DQo+IDVdDQo+DQo+IEludGVybmV0LURyYWZ0IEdy b3VwIENvbW11bmljYXRpb24gZm9yIENvQVAgT2N0b2Jlcg0KPg0KPiAyMDEyDQo+DQo+ICBFeGFt cGxlcyBvZiBoaWVyYXJjaGljYWwgZ3JvdXAgbmFtaW5nIChhbmQgc2NvcGluZykgZm9yIGEgYnVp bGRpbmcNCj4NCj4gIGNvbnRyb2wgYXBwbGljYXRpb24gYXJlIHNob3duIGJlbG93Lg0KPg0KPiAg VVJJIGF1dGhvcml0eSBUYXJnZXRlZCBncm91cA0KPg0KPiAgYWxsLmJsZGc2LmV4YW1wbGUuY29t ICJhbGwgbm9kZXMgaW4gYnVpbGRpbmcgNiINCj4NCj4gIGFsbC53ZXN0LmJsZGc2LmV4YW1wbGUu Y29tICJhbGwgbm9kZXMgaW4gd2VzdCB3aW5nLCBidWlsZGluZw0KPg0KPiA2Ig0KPg0KPiAgYWxs LmZsb29yMS53ZXN0LmJsZGc2LmV4YW1wLi4uICJhbGwgbm9kZXMgaW4gZmxvb3IgMSwgd2VzdCB3 aW5nLA0KPg0KPiAgYnVpbGRpbmcgNiINCj4NCj4gIGFsbC5idTAzNi5mbG9vcjEud2VzdC5ibGRn Ni4uLiAiYWxsIG5vZGVzIGluIG9mZmljZSBidTAzNiwgZmxvb3IxLA0KPg0KPiAgd2VzdCB3aW5n LCBidWlsZGluZyA2Ig0KPg0KPiAgUmV2ZXJzZSBtYXBwaW5nIChmcm9tIElQIG11bHRpY2FzdCBh ZGRyZXNzIHRvIGdyb3VwIEZRRE4pIGlzDQo+DQo+ICBzdXBwb3J0ZWQgdXNpbmcgdGhlIHJldmVy c2UgRE5TIHJlc29sdXRpb24gdGVjaG5pcXVlDQo+DQo+ICAoW0ktRC52YW5kZXJzdG9rLWNvcmUt ZG5hXSkuDQo+DQo+IDMuMy4gR3JvdXAgRGlzY292ZXJ5IGFuZCBNZW1iZXIgRGlzY292ZXJ5DQo+ DQo+ICBDb0FQIGRlZmluZXMgYSByZXNvdXJjZSBkaXNjb3ZlcnkgY2FwYWJpbGl0eSwgYnV0IGRv ZXMgbm90IHlldA0KPg0KPiAgc3BlY2lmeSBob3cgdG8gZGlzY292ZXIgZ3JvdXBzIChlLmcuIGZp bmQgYSBncm91cCB0byBqb2luIG9yIHNlbmQgYQ0KPg0KPiAgbXVsdGljYXN0IG1lc3NhZ2UgdG8p IG9yIHRvIGRpc2NvdmVyIG1lbWJlcnMgb2YgYSBncm91cCAoZS5nLiB0bw0KPg0KPiAgYWRkcmVz cyBzZWxlY3RlZCBncm91cCBtZW1iZXJzIGJ5IHVuaWNhc3QpLiBUaGVzZSB0b3BpY3MgYXJlDQo+ DQo+ICBlbGFib3JhdGVkIGluIG1vcmUgZGV0YWlsIGluIFtJLUQudmFuZGVyc3Rvay1jb3JlLWRu YV0gaW5jbHVkaW5nDQo+DQo+ICBleGFtcGxlcyBmb3IgdXNpbmcgRE5TLVNEIGFuZCBDb1JFIFJl c291cmNlIERpcmVjdG9yeS4NCj4NCj4gMy4zLjEuIEROUy1TRA0KPg0KPiAgRE5TLWJhc2VkIFNl cnZpY2UgRGlzY292ZXJ5IFtJLUQuY2hlc2hpcmUtZG5zZXh0LWRucy1zZF0gZGVmaW5lcyBhDQo+ DQo+ICBjb252ZW50aW9uYWwgd2F5IHRvIGNvbmZpZ3VyZSBETlMgUFRSLCBTUlYsIGFuZCBUWFQg cmVjb3JkcyB0bw0KPg0KPiBlbmFibGUNCj4NCj4gIGVudW1lcmF0aW9uIG9mIHNlcnZpY2VzLCBz dWNoIGFzIHNlcnZpY2VzIG9mZmVyZWQgYnkgQ29BUCBub2Rlcywgb3INCj4NCj4gIGVudW1lcmF0 aW9uIG9mIGFsbCBDb0FQIG5vZGVzLCB3aXRoaW4gc3BlY2lmaWVkIHN1YmRvbWFpbnMuIEENCj4N Cj4gIHNlcnZpY2UgaXMgc3BlY2lmaWVkIGJ5IGEgbmFtZSBvZiB0aGUgZm9ybQ0KPg0KPiAgPElu c3RhbmNlPi48U2VydmljZVR5cGU+LjxEb21haW4+LCB3aGVyZSB0aGUgc2VydmljZSB0eXBlIGZv ciBDb0FQDQo+DQo+ICBub2RlcyBpcyBfY29hcC5fdWRwIGFuZCB0aGUgZG9tYWluIGlzIGEgRE5T IGRvbWFpbiBuYW1lIHRoYXQNCj4NCj4gIGlkZW50aWZpZXMgYSBncm91cCBhcyBpbiB0aGUgZXhh bXBsZXMgYWJvdmUuIEZvciBlYWNoIENvQVANCj4NCj4gZW5kLXBvaW50DQo+DQo+ICBpbiBhIGdy b3VwLCBhIFBUUiByZWNvcmQgd2l0aCB0aGUgbmFtZSBfY29hcC5fdWRwIGFuZC9vciBhIFBUUg0K Pg0KPiByZWNvcmQNCj4NCj4gIHdpdGggdGhlIG5hbWUgX2NvYXAuX3VkcC48RG9tYWluPiBpcyBk ZWZpbmVkIGFuZCBpdCBwb2ludHMgdG8gYW4gU1JWDQo+DQo+ICByZWNvcmQgaGF2aW5nIHRoZSA8 SW5zdGFuY2U+LjxTZXJ2aWNlVHlwZT4uPERvbWFpbj4gbmFtZS4NCj4NCj4gIEFsbCBDb0FQIG5v ZGVzIGluIGEgZ2l2ZW4gc3ViZG9tYWluIG1heSBiZSBlbnVtZXJhdGVkIGJ5IHNlbmRpbmcgYQ0K Pg0KPiAgcXVlcnkgZm9yIFBUUiByZWNvcmRzIG5hbWVkIF9jb2FwLl91ZHAgdG8gdGhlIGF1dGhv cml0YXRpdmUgRE5TDQo+DQo+ICBzZXJ2ZXIgZm9yIHRoYXQgem9uZS4gQSBsaXN0IG9mIFNSViBy ZWNvcmRzIGlzIHJldHVybmVkLiBFYWNoIFNSVg0KPg0KPiAgcmVjb3JkIGNvbnRhaW5zIHRoZSBw b3J0IGFuZCBob3N0IG5hbWUgKEFBQUEgcmVjb3JkKSBvZiBhIENvQVAgbm9kZS4NCj4NCj4gIFRo ZSBJUCBhZGRyZXNzIG9mIHRoZSBub2RlIGlzIG9idGFpbmVkIGJ5IHJlc29sdmluZyB0aGUgaG9z dCBuYW1lLg0KPg0KPiAgRE5TLVNEIGFsc28gc3BlY2lmaWVzIGFuIG9wdGlvbmFsIFRYVCByZWNv cmQsIGhhdmluZyB0aGUgc2FtZSBuYW1lDQo+DQo+IGFzDQo+DQo+ICB0aGUgU1JWIHJlY29yZCwg d2hpY2ggY2FuIGNvbnRhaW4gImtleT12YWx1ZSIgYXR0cmlidXRlcy4gVGhpcyBjYW4NCj4NCj4g IGJlIHVzZWQgdG8gc3RvcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGRldmljZSwgZS5nLiBzY2hl bWE9REFMSSwNCj4NCj4gIHR5cGU9c3dpdGNoLCBncm91cD1saWdodGluZy5ibGRnNiwgZXRjLg0K Pg0KPiBSYWhtYW4gJiBEaWprIEV4cGlyZXMgQXByaWwgMjIsIDIwMTMgW1BhZ2UNCj4NCj4gNl0N Cj4NCj4gSW50ZXJuZXQtRHJhZnQgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCBPY3RvYmVy DQo+DQo+IDIwMTINCj4NCj4gIEFub3RoZXIgZmVhdHVyZSBvZiBETlMtU0QgaXMgdGhlIGFiaWxp dHkgdG8gc3BlY2lmeSBzZXJ2aWNlIHN1YnR5cGVzDQo+DQo+ICB1c2luZyBQVFIgcmVjb3Jkcy4g Rm9yIGV4YW1wbGUsIG9uZSBjb3VsZCByZXByZXNlbnQgYWxsIHRoZSBDb0FQDQo+DQo+ICBncm91 cHMgaW4gYSBzdWJkb21haW4gYnkgUFRSIHJlY29yZHMgd2l0aCB0aGUgbmFtZQ0KPg0KPiAgX2dy b3VwLl9zdWIuX2NvYXAuX3VkcCBvciBhbHRlcm5hdGl2ZWx5DQo+DQo+ICBfZ3JvdXAuX3N1Yi5f Y29hcC5fdWRwLjxEb21haW4+Lg0KPg0KPiAzLjMuMi4gQ29SRSBSZXNvdXJjZSBEaXJlY3RvcnkN Cj4NCj4gIENvUkUgUmVzb3VyY2UgRGlyZWN0b3J5IFtJLUQuc2hlbGJ5LWNvcmUtcmVzb3VyY2Ut ZGlyZWN0b3J5XSBkZWZpbmVzDQo+DQo+ICB0aGUgY29uY2VwdCBvZiBhIFJlc291cmNlIERpcmVj dG9yeSAoUkQpIHNlcnZlciB3aGVyZSBDb0FQIHNlcnZlcnMNCj4NCj4gIGNhbiByZWdpc3RlciB0 aGVpciByZXNvdXJjZXMgb2ZmZXJlZCBhbmQgQ29BUCBjbGllbnRzIGNhbiBkaXNjb3Zlcg0KPg0K PiAgdGhlc2UgcmVzb3VyY2VzIGJ5IHF1ZXJ5aW5nIHRoZSBSRCBzZXJ2ZXIuIFJEIHN5bnRheCBj YW4gYmUgbWFwcGVkDQo+DQo+ICB0byBETlMtU0Qgc3ludGF4IGFuZCB2aWNlIHZlcnNhIFtJLUQu bHlubi1jb3JlLWRpc2NvdmVyeS1tYXBwaW5nXSwNCj4NCj4gIHN1Y2ggdGhhdCB0aGUgYWJvdmUg YXBwcm9hY2ggY2FuIGJlIHJldXNlZCBmb3IgZ3JvdXAgZGlzY292ZXJ5IGFuZA0KPg0KPiAgZ3Jv dXAgbWVtYmVyIGRpc2NvdmVyeS4NCj4NCj4gIC9yZW1vdmUgU3BlY2lmaWNhbGx5LCB0aGUgRG9t YWluIChkKSBwYXJhbWV0ZXIgY2FuIGJlIHNldCB0byB0aGUNCj4NCj4gZ3JvdXAgVVJJIGJ5DQo+ DQo+ICBhbiBlbmQtcG9pbnQgcmVnaXN0ZXJpbmcgdG8gdGhlIFJELiBJZiBhbiBlbmQtcG9pbnQg d2FudHMgdG8gam9pbg0KPg0KPiAgbXVsdGlwbGUgZ3JvdXBzLCBpdCBoYXMgdG8gcmVwZWF0IHRo ZSByZWdpc3RyYXRpb24gcHJvY2VzcyBmb3IgZWFjaA0KPg0KPiAgZ3JvdXAgaXQgd2FudHMgdG8g am9pbi4NCj4NCj4gL2VuZCByZW1vdmUNCj4NCj4gL2NvbW1lbnQgZCBwYXJhbWV0ZXIgc2VtYW50 aWNzIG5vdCBjbGVhcg0KPg0KPiAzLjQuIEdyb3VwIFJlc291cmNlIE1hbmlwdWxhdGlvbg0KPg0K PiAgR3JvdXAgY29tbXVuaWNhdGlvbnMgU0hBTEwgb25seSBiZSB1c2VkIGZvciBpZGVtcG90ZW50 IG1ldGhvZHMgKGkuZS4NCj4NCj4gIENvQVAgR0VULCBQVVQsIERFTEVURSkuIFRoZSBDb0FQIG1l c3NhZ2VzIHRoYXQgYXJlIHNlbnQgdmlhDQo+DQo+ICBtdWx0aWNhc3QgU0hBTEwgYmUgTm9uLUNv bmZpcm1hYmxlLg0KPg0KPiAgQSB1bmljYXN0IHJlc3BvbnNlIHBlciBzZXJ2ZXIgTUFZIGJlIHNl bnQgYmFjayB0byBhbnN3ZXIgdGhlIGdyb3VwDQo+DQo+ICByZXF1ZXN0IChlLmcuIHJlc3BvbnNl ICIyLjA1IENvbnRlbnQiIHRvIGEgZ3JvdXAgR0VUIHJlcXVlc3QpIHRha2luZw0KPg0KPiAgaW50 byBhY2NvdW50IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgcnVsZXMgZGVmaW5lZCBpbg0KPg0KPiAg W0ktRC5pZXRmLWNvcmUtY29hcF0uIFRoZSB1bmljYXN0IHJlc3BvbnNlcyBtYXkgYmUgYSBtaXh0 dXJlIG9mDQo+DQo+ICBzdWNjZXNzIChlLmcuIDIuMDUgQ29udGVudCkgYW5kIGZhaWx1cmUgKGUu Zy4gNC4wNCBOb3QgRm91bmQpIGNvZGVzDQo+DQo+ICBkZXBlbmRpbmcgb24gdGhlIGluZGl2aWR1 YWwgc2VydmVyIHByb2Nlc3NpbmcgcmVzdWx0Lg0KPg0KPiAgR3JvdXAgY29tbXVuaWNhdGlvbnMg U0hBTEwgTk9UIGJlIHVzZWQgZm9yIG5vbi1pZGVtcG90ZW50IG1ldGhvZHMNCj4NCj4gIChpLmUu IENvQVAgUE9TVCkuIFRoaXMgaXMgYmVjYXVzZSBub3QgYWxsIGdyb3VwIG1lbWJlcnMgYXJlDQo+ DQo+ICBndWFyYW50ZWVkIHRvIHJlY2VpdmUgdGhlIG11bHRpY2FzdCByZXF1ZXN0LCBhbmQgdGhl IHNlbmRlciBjYW4gbm90DQo+DQo+ICByZWFkaWx5IGZpbmQgb3V0IHdoaWNoIGdyb3VwIG1lbWJl cnMgZGlkIG5vdCByZWNlaXZlIGl0Lg0KPg0KPiAgQWxsIG5vZGVzIGluIGEgZ2l2ZW4gZ3JvdXAg U0hPVUxEIHJlY2VpdmUgdGhlIHNhbWUgcmVxdWVzdA0KPg0KPiAvcmVtb3ZlIHdpdGggaGlnaCBw cm9iYWJpbGl0eS4NCj4NCj4gL2NvbW1lbnQgSSBkb24ndCBzZWUgd2hlcmUgcHJvYmFiaWxpdHkg Y29tZXMgaW4uDQo+DQo+ICBUaGlzIHdpbGwgbm90IGJlIHRoZSBjYXNlIGlmIHRoZXJlIGlzIGRp dmVyc2l0eSBpbiB0aGUNCj4NCj4gIGF1dGhvcml0eSBwb3J0IChpLmUuIGEgZGl2ZXJzaXR5IG9m IGR5bmFtaWMgcG9ydCBhZGRyZXNzZXMgYWNyb3NzDQo+DQo+IHRoZQ0KPg0KPiAgZ3JvdXApIG9y IGlmIHRoZSB0YXJnZXRlZCByZXNvdXJjZSBpcyBsb2NhdGVkIGF0IGRpZmZlcmVudCBwYXRocyBv bg0KPg0KPiAgZGlmZmVyZW50IG5vZGVzLg0KPg0KPiAgVGhlcmVmb3JlLCBzb21lIG1lYXN1cmVz IG11c3QgYmUgcHJlc2VudCB0byBlbnN1cmUgdW5pZm9ybWl0eSBpbg0KPg0KPiBwb3J0DQo+DQo+ ICBudW1iZXIgYW5kIHJlc291cmNlIG5hbWVzL2xvY2F0aW9ucyB3aXRoaW4gYSBncm91cC4gVGhp cyBkb2N1bWVudA0KPg0KPiAgcHJvcG9zZXMgdGhlIGZvbGxvd2luZyBtZWFzdXJlczoNCj4NCj4g UmFobWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzIFtQYWdlDQo+DQo+IDddDQo+DQo+ IEludGVybmV0LURyYWZ0IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAgT2N0b2Jlcg0KPg0K PiAyMDEyDQo+DQo+ICBvIEFsbCBDb0FQIG11bHRpY2FzdCByZXF1ZXN0cyBNVVNUIGJlIHNlbnQg ZWl0aGVyIHRvIHRoZSBkZWZhdWx0DQo+DQo+ICBDb0FQIFVEUCBwb3J0IChpLmUuIGRlZmF1bHQg VXJpLVBvcnQgYXMgZGVmaW5lZCBpbg0KPg0KPiAgW0ktRC5pZXRmLWNvcmUtY29hcF0pLCBvciB0 byBhIHBvcnQgbnVtYmVyIG9idGFpbmVkIHZpYSBhIHNlcnZpY2UNCj4NCj4gIGRpc2NvdmVyeSBs b29rdXAgb3BlcmF0aW9uIGFzIGEgdmFsaWQgQ29BUCBwb3J0IGZvciB0aGUgdGFyZ2V0ZWQNCj4N Cj4gIG11bHRpY2FzdCBncm91cC4NCj4NCj4gIG8gQWxsIENvQVAgbXVsdGljYXN0IHJlcXVlc3Rz IFNIT1VMRCBvcGVyYXRlIG9ubHkgb24gVVJJcyAobGlua3MpDQo+DQo+ICB3aGljaCB3ZXJlDQo+ DQo+IC9zIHJldHJlaXZlZCAvcyByZXRyaWV2ZWQNCj4NCj4gIGVpdGhlciBmcm9tIGEgIi8ud2Vs bC1rbm93bi9jb3JlIiBsb29rdXAgb24NCj4NCj4gIGF0IGxlYXN0IG9uZSBncm91cCBtZW1iZXIg bm9kZSwgb3IgZnJvbSBhbiBlcXVpdmFsZW50IHNlcnZpY2UNCj4NCj4gIGRpc2NvdmVyeSBsb29r dXAgd2hpY2ggcmV0dXJucyBlaXRoZXIgdGhlIHJlc291cmNlcyBzdXBwb3J0ZWQgYnkNCj4NCj4g IGFsbCBncm91cCBtZW1iZXJzIG9yIHJlc291cmNlcyBzdXBwb3J0ZWQgYnkgb25lIHBhcnRpY3Vs YXIgZ3JvdXANCj4NCj4gIG1lbWJlci4NCj4NCj4gL2NvbW1lbnQgc28gc2V0dGluZyBhIG11bHRp Y2FzdCBhZGRyZXNzIGluIGEgc291cmNlIGF0IGluc3RhbGxhdGlvbiBpcw0KPg0KPiBmb3JiaWRk ZW4/DQo+DQo+IDMuNS4gQ29uZmlndXJpbmcgR3JvdXAgTWVtYmVyc2hpcCBJbiBFbmRwb2ludHMN Cj4NCj4gIEluIHNvbWUgdXNlIGNhc2VzLCB0aGUgZ3JvdXAgbWVtYmVyc2hpcCBvZiBlbmRwb2lu dHMgbmVlZHMgdG8gYmUNCj4NCj4gIGNvbmZpZ3VyYWJsZSBhZnRlciB0aGUgbmV0d29yayBoYXMg YmVlbiBkZXBsb3llZC4gRXhhbXBsZSB1c2UgY2FzZXMNCj4NCj4gIGNhbiBiZSBmb3VuZCBpbiBi dWlsZGluZyBjb250cm9sOiBhIGNvbW1pc3Npb25pbmcgdG9vbCBkZXRlcm1pbmVzIHRvDQo+DQo+ ICB3aGljaCBncm91cHMgYSBsaWdodCBvciBzZW5zb3Igbm9kZSBiZWxvbmdzLCBhbmQgd3JpdGVz IHRoaXMNCj4NCj4gIGluZm9ybWF0aW9uIHRvIGFsbCBub2Rlcywgd2hpY2ggY2FuIHN1YnNlcXVl bnRseSBqb2luIHRoZSBjb3JyZWN0DQo+DQo+ICBncm91cC4NCj4NCj4gIFRvIGFjaGlldmUgc21v b3RoZXIgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIG5vZGVzL2VuZHBvaW50cyBmcm9tDQo+DQo+ ICBkaWZmZXJlbnQgbWFudWZhY3R1cmVycywgaXQgaXMgcHJvcG9zZWQgaGVyZSB0byBkZWZpbmUg YW4gT1BUSU9OQUwNCj4NCj4gIHN0YW5kYXJkaXplZCBSRVNUZnVsIG1lYW5zIG9mIGNvbmZpZ3Vy aW5nIENvQVAgZW5kcG9pbnRzIHdpdGgNCj4NCj4gIHJlbGV2YW50IGdyb3VwIGluZm9ybWF0aW9u Lg0KPg0KPiAgQ29BUCBlbmRwb2ludHMgaW1wbGVtZW50aW5nIHRoaXMgbWVjaGFuaXNtIE1VU1Qg c3VwcG9ydCBhDQo+DQo+ICBkaXNjb3ZlcmFibGUgIkdyb3VwIENvbmZpZ3VyYXRpb24iIHJlc291 cmNlIG9mIHJlc291cmNlIHR5cGUgKHJ0KQ0KPg0KPiAgW1JGQzY2OTBdICJjb3JlLmdwIi4gVGhp cyByZXNvdXJjZSAoYW5kIHBlcmhhcHMgaXRzIHN1Yi1yZXNvdXJjZXMsDQo+DQo+ICBUQkQpIGFy ZSB1c2VkIHRvIG1hbmFnZSBncm91cCBtZW1iZXJzaGlwLiBUaHJlZSBkZXNpZ24gb3B0aW9ucyBm b3INCj4NCj4gIHRoaXMgbWVjaGFuaXNtIGFyZSBwcmVzZW50ZWQgaGVyZSBhcyBhIHBsYWNlaG9s ZGVyIChUQkQpLg0KPg0KPiAgRGVzaWduIDE6IHVzZSBDb1JFIGxpbmsgZm9ybWF0IHBheWxvYWRz IHRvIGNvbW11bmljYXRlIGdyb3VwDQo+DQo+ICBtZW1iZXJzaGlwIHRvIGVuZHBvaW50cy4gKFRC RCBOb3QgY2xlYXIgaG93IHRoaXMgc2hvdWxkIGJlDQo+DQo+ICByZWFsaXplZC4pDQo+DQo+IC9j b21tZW50LCBub3QgY2xlYXIgd2hhdCB5b3UgbWVhbiBlaXRoZXIuIFJlbW92ZSBkZXNpZ24gMSBp biB0aGlzDQo+IHN0YXRlDQo+DQo+ICBEZXNpZ24gMjogdXNlIGEgSlNPTiB0eXBlIHJlc291cmNl LiBGb3IgZXhhbXBsZSwgYSBHRVQgb24gdGhlDQo+DQo+ICAiY29yZS5ncCIgcmVzb3VyY2UgcmV0 dXJucyBhIEpTT04gYXJyYXkgb2YgZ3JvdXAgb2JqZWN0cy4NCj4NCj4gIFJlcTogR0VUIC9ncA0K Pg0KPiAgUmVzOiAyLjA1IENvbnRlbnQgKENvbnRlbnQtRm9ybWF0OiBhcHBsaWNhdGlvbi9qc29u KQ0KPg0KPiAgWyB7ICJuIjogIlJvb20tQS1MaWdodHMuZmxvb3IxLndlc3QuYmxkZzYuZXhhbXBs ZS5jb20iLA0KPg0KPiAgImlwIjogImZmMDU6OjQyMDA6ZjdmZTplZDM3OjE0Y2EiIH0NCj4NCj4g IF0NCj4NCj4gIHdoZXJlICJuIiBkZWZpbmVzIHRoZSBHcm91cCBGUUROIGFuZCAiaXAiIGRlZmlu ZXMgdGhlIGFzc29jaWF0ZWQNCj4NCj4gIG11bHRpY2FzdCBJUCBhZGRyZXNzLiBBcyBhIG5leHQg ZXhhbXBsZSwgdGhlIHNhbWUgZW5kcG9pbnQgY2FuIGJlDQo+DQo+IFJhaG1hbiAmIERpamsgRXhw aXJlcyBBcHJpbCAyMiwgMjAxMyBbUGFnZQ0KPg0KPiA4XQ0KPg0KPiBJbnRlcm5ldC1EcmFmdCBH cm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQIE9jdG9iZXINCj4NCj4gMjAxMg0KPg0KPiAgYWRk ZWQgdG8gYW5vdGhlciBncm91cCBieSBhIFBPU1Qgb24gdGhlIHJlc291cmNlIHdpdGggYSBKU09O IGdyb3VwDQo+DQo+ICBvYmplY3Q6DQo+DQo+ICBSZXE6IFBPU1QgL2dwIChDb250ZW50LUZvcm1h dDogYXBwbGljYXRpb24vanNvbikNCj4NCj4gIHsgIm4iOiAiZmxvb3IxLndlc3QuYmxkZzYuZXhh bXBsZS5jb20iLA0KPg0KPiAgImlwIjogImZmMDU6OjQyMDA6ZjdmZTplZDM3OjE0Y2IiIH0NCj4N Cj4gIFJlczogMi4wNCBDaGFuZ2VkDQo+DQo+ICBEZXNpZ24gMzogZGVmaW5lIG5hbWVkIHN1Yi1y ZXNvdXJjZXMsIGVhY2ggc3ViLXJlc291cmNlIHJlcHJlc2VudGluZw0KPg0KPiAgYSBncm91cCBt ZW1iZXJzaGlwLiBUaGUgcGF5bG9hZCBvZiB0aGUgc3ViLXJlc291cmNlIG1heSBiZSBKU09OIG9y DQo+DQo+IGENCj4NCj4gIHNpbXBsZSBwcmUtZGVmaW5lZCBmb3JtYXQuIE9yIGFsdGVybmF0aXZl bHksIGluZm9ybWF0aW9uIGlzDQo+DQo+IHByb3ZpZGVkDQo+DQo+ICB2aWEgUE9TVCB3aXRoIHF1 ZXJ5IHBhcmFtZXRlcnMuDQo+DQo+IC9jb21tZW50IGFyZSB0aGVzZSBtdXR1YWxseSBleGNsdXNp dmUgZGVzaWducz8NCj4NCj4gL2NvbW1lbnQgZGVzaWduIDIgd2l0aG91dCBKU09OIGlzIGFscyBw b3NzaWJsZQ0KPg0KPiAvY29tbWVudCBkZXNpZ24gd2l0aCBTUlYgYW5kIFRYdCByZWNvcmRzIGlz IGFsc28gcG9zc2libGUNCj4NCj4gL2NvbW1lbnQgdGhlcmUgYXJlIDIgd2F5czogKDEpIHRoZSBu b2RlIHF1ZXJpZXMgdG8gd2hpY2ggZ3JvdXAgaXQNCj4NCj4gYmVsb25ncw0KPg0KPiAvY29tbWVu dCAoMikgYW4gaW5zdGFsYXRpb24gdG9vbHMgaW5zdHJ1Y3RzIHRoZSBub2RlIHRvIHdoaWNoIGdy b3Vwcw0KPg0KPiBpdCBiZWxvbmdzDQo+DQo+IC9jb21tZW50IG5vdCBjbGVhciBpbiB0ZXh0IHRo YXQgdGhpcyBjaG9pY2UgZXhpc3RzIG9yIHRoYXQgYSBjaG9pY2UNCj4gd2FzDQo+DQo+IG1hZGUu DQo+DQo+IDMuNi4gQ29uZ2VzdGlvbiBDb250cm9sDQo+DQo+ICBNdWx0aWNhc3QgQ29BUCByZXF1 ZXN0cyBtYXkgcmVzdWx0IGluIGEgbXVsdGl0dWRlIG9mIHJlcGxpZXMgZnJvbQ0KPg0KPiAgZGlm ZmVyZW50IG5vZGVzLCBwb3RlbnRpYWxseSBjYXVzaW5nIGNvbmdlc3Rpb24uIFRoZXJlZm9yZSBz ZW5kaW5nDQo+DQo+ICBtdWx0aWNhc3QNCj4NCj4gL3MgcmVxdWVzdHMgL3MgcmVwbGllcw0KPg0K PiAgc2hvdWxkIGJlIGNvbnNlcnZhdGl2ZWx5IGNvbnRyb2xsZWQuDQo+DQo+ICBUaGUgYmFzZSBD b0FQIGRyYWZ0IFtJLUQuaWV0Zi1jb3JlLWNvYXBdIHJlZHVjZXMgbXVsdGljYXN0LXNwZWNpZmlj DQo+DQo+ICBjb25nZXN0aW9uIHJpc2tzIHRocm91Z2ggdGhlIGZvbGxvd2luZyBtZWFzdXJlczoN Cj4NCj4gIG8gQSBzZXJ2ZXIgTUFZIGNob29zZSBub3QgdG8gcmVzcG9uZCB0byBhIG11bHRpY2Fz dCByZXF1ZXN0IGlmDQo+DQo+ICB0aGVyZSdzIG5vdGhpbmcgdXNlZnVsIHRvIHJlc3BvbmQgKGUu Zy4gZXJyb3Igb3IgZW1wdHkgcmVzcG9uc2UpLg0KPg0KPiAgbyBBIHNlcnZlciBTSE9VTEQgbGlt aXQgdGhlIHN1cHBvcnQgZm9yIG11bHRpY2FzdCByZXF1ZXN0cyB0bw0KPg0KPiAgc3BlY2lmaWMg cmVzb3VyY2VzIHdoZXJlIG11bHRpY2FzdCBvcGVyYXRpb24gaXMgcmVxdWlyZWQuDQo+DQo+ICBv IEEgbXVsdGljYXN0IHJlcXVlc3QgTVVTVCBiZSBOb24tQ29uZmlybWFibGUuDQo+DQo+IC9jb21t ZW50IHdoYXQgYWJvdXQgdGhlIHJlcGx5Pw0KPg0KPiAgbyBBIHNlcnZlciBkb2VzIG5vdCByZXNw b25kIGltbWVkaWF0ZWx5IHRvIGEgbXVsdGljYXN0IHJlcXVlc3QsIGJ1dA0KPg0KPiAgU0hPVUxE IGZpcnN0IHdhaXQgZm9yIGEgdGltZSB0aGF0IGlzIHJhbmRvbWx5IHBpY2tlZCB3aXRoaW4gYQ0K Pg0KPiAgcHJlZGV0ZXJtaW5lZCB0aW1lIGludGVydmFsIGNhbGxlZCB0aGUgTGVpc3VyZS4NCj4N Cj4gIG8gQSBzZXJ2ZXIgU0hPVUxEIE5PVCBhY2NlcHQgbXVsdGljYXN0IHJlcXVlc3RzIHRoYXQg Y2FuIG5vdCBiZQ0KPg0KPiAgYXV0aGVudGljYXRlZC4NCj4NCj4gL2NvbW1lbnQgaW52b2tpbmcg YXMgbWFueSBjZXJ0aWZpY2F0ZXM/DQo+DQo+ICBBZGRpdGlvbmFsIGd1aWRlbGluZXMgdG8gcmVk dWNlIGNvbmdlc3Rpb24gcmlza3MgYXJlOg0KPg0KPiAgbyBBIHNlcnZlciBpbiBhbiBMTE4gc2hv dWxkIG9ubHkgc3VwcG9ydCBtdWx0aWNhc3QgR0VUIGZvcg0KPg0KPiByZXNvdXJjZXMNCj4NCj4g IHRoYXQgYXJlIHNtYWxsLCBlLmcuDQo+DQo+IC9yZW1vdmUgZm9yIGFuIExMTiB0aGF0IGNvdWxk IG1lYW4NCj4NCj4gIHRoZSBwYXlsb2FkIG9mIHRoZQ0KPg0KPiAgcmVzcG9uc2UgZml0cyBpbnRv IGEgc2luZ2xlIGxpbmstbGF5ZXIgZnJhbWUuDQo+DQo+ICBvIEEgc2VydmVyIGNhbiBtaW5pbWl6 ZSB0aGUgcGF5bG9hZCBsZW5ndGggaW4gcmVzcG9uc2UgdG8gYQ0KPg0KPiAgbXVsdGljYXN0IEdF VCBvbiAiLy53ZWxsLWtub3duL2NvcmUiIGJ5IHVzaW5nIGhpZXJhcmNoeSBpbg0KPg0KPiAgYXJy YW5naW5nIGxpbmsgZGVzY3JpcHRpb25zIGZvciB0aGUgcmVzcG9uc2UuIEFuIGV4YW1wbGUgb2Yg dGhpcw0KPg0KPiAgaXMgZ2l2ZW4gaW4gU2VjdGlvbiA1IG9mIFtSRkM2NjkwXS4NCj4NCj4gUmFo bWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzIFtQYWdlDQo+DQo+IDldDQo+DQo+IElu dGVybmV0LURyYWZ0IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAgT2N0b2Jlcg0KPg0KPiAy MDEyDQo+DQo+ICBvIFByZWZlcmFibHkgSVAgbXVsdGljYXN0IHdpdGggbGluay1sb2NhbCBzY29w ZSBzaG91bGQgYmUgdXNlZCwNCj4NCj4gIHJhdGhlciB0aGFuIGdsb2JhbCBvciBzaXRlLWxvY2Fs Lg0KPg0KPiAgbyBUaGUgSG9wIExpbWl0IGZpZWxkIGluIHRoZSBJUHY2IHBhY2tldCBzaG91bGQg YmUgY2hvc2VuIGFzIGxvdyBhcw0KPg0KPiAgcG9zc2libGUgKGlmIHRoZSBDb0FQL0lQIHN0YWNr IGFsbG93cyBzZXR0aW5nIG9mIHRoaXMgdmFsdWUuIFRCRA0KPg0KPiAgLSBkaXNjdXNzIHdoZXRo ZXIgdGhpcyBndWlkZWxpbmUgaXMgcmVsZXZhbnQvcmVhbGlzdGljIGluIENvQVANCj4NCj4gIGNv bnRleHQpDQo+DQo+IDMuNy4gQ29BUCBNdWx0aWNhc3QgYW5kIEhUVFAgVW5pY2FzdCBJbnRlcndv cmtpbmcNCj4NCj4gL2NvbW1lbnQgYSByZWZlcmVuY2Ugd2lsbCBzdWZmaWNlDQo+DQo+ICBDb0FQ IHN1cHBvcnRzIG9wZXJhdGlvbiBvdmVyIFVEUCBtdWx0aWNhc3QsIHdoaWxlIEhUVFAgZG9lcyBu b3QuDQo+DQo+IEZvcg0KPg0KPiAgdXNlIGNhc2VzIHdoZXJlIGl0IGlzIHJlcXVpcmVkIHRoYXQg Q29BUCBncm91cCBjb21tdW5pY2F0aW9uIGlzDQo+DQo+ICBpbml0aWF0ZWQgZnJvbSBhbiBIVFRQ IGVuZC1wb2ludCwgaXQgd291bGQgYmUgYWR2YW50YWdlb3VzIGlmIHRoZQ0KPg0KPiAgSFRUUC1D b0FQIFByb3h5IHN1cHBvcnRzIG1hcHBpbmcgb2YgSFRUUCB1bmljYXN0IHRvIENvQVAgZ3JvdXAN Cj4NCj4gIGNvbW11bmljYXRpb24gYmFzZWQgb24gSVAgbXVsdGljYXN0Lg0KPg0KPiAvcmVtb3Zl IE9uZSBwb3NzaWJsZSB3YXkgb2Ygb3BlcmF0aW9uDQo+DQo+IC9yZW1vdmUgb2Ygc3VjaCBIVFRQ LUNvQVAgUHJveHkgaXMgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDEuDQo+DQo+ICBOb3RlIHRoYXQg dGhpcw0KPg0KPiAgdG9waWMgaXMgY292ZXJlZCBpbiBtb3JlIGRldGFpbCBpbg0KPg0KPiAgW0kt RC5jYXN0ZWxsYW5pLWNvcmUtYWR2YW5jZWQtaHR0cC1tYXBwaW5nXS4NCj4NCj4gL3JlbW92ZQ0K Pg0KPiAgQ29BUCBNY2FzdCBDb0FQIE1jYXN0IEhUVFAtQ29BUCBIVFRQDQo+DQo+ICBOb2RlIDEg UnRyMSBOb2RlIDIgUnRyMiBQcm94eSBOb2RlIDMNCj4NCj4gIHwgfCB8IHwgfCB8DQo+DQo+ICB8 TUxEIFJFUVVFU1QgfCB8IHwgfA0KPg0KPiAgfChKb2luIEdyb3VwIFgpIHwgfCB8IHwNCj4NCj4g IHwtLUxMLS0+fCB8IHwgfCB8DQo+DQo+ICB8IHwgfE1MRCBSRVFVRVNUIHwgfA0KPg0KPiAgfCB8 IHwoSm9pbiBHcm91cCBYKSB8IHwNCj4NCj4gIHwgfCB8LS1MTC0tPnwgfCB8DQo+DQo+ICB8IHwg fCB8IHwgSFRUUCBSRVFVRVNUIHwNCj4NCj4gIHwgfCB8IHwgfCAoVVJJIHRvIHwNCj4NCj4gIHwg fCB8IHwgfCB1bmljYXN0IGFkZHIpIHwNCj4NCj4gIHwgfCB8IHwgfDwgLS0tLS0tLS0tLS0tLS0t LS18DQo+DQo+ICB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgUmVzb2x2ZSBIVFRQIFJlcXVlc3Qt TGluZSBVUkkgfA0KPg0KPiAgfCB8IHwgdG8gR3JvdXAgWCBtdWx0aWNhc3QgYWRkcmVzcyB8DQo+ DQo+ICB8IHwgfCB8IHwgfA0KPg0KPiAgfCBDb0FQIFJFUVVFU1QgKHRvIG11bHRpY2FzdCBhZGRy KXwgfA0KPg0KPiAgfDwgLS0tLS0tPC0tLS0tLS0tLTwtLS0tLS0tPC0tLS0tLXwgfA0KPg0KPiAg fCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwNCj4NCj4gIHwgKG9wdGlvbmFsKSBDb0FQIFJFU1BP TlNFKHMpIHwgfA0KPg0KPiAgfCB8LS0tLS0tLS0tLS0tLS0+fCB8DQo+DQo+ICB8LS0tLS0tLS0t LS0tLS0tLS18LS0tLS0tLS0tLS0tLS0+fCBBZ2dyZWdhdGVkIHwNCj4NCj4gIHwgfCB8IEhUVFAg UkVTUE9OU0UgfA0KPg0KPiAgfCB8IHwtLS0tLS0tLS0tLS0tLS0tLS0+fA0KPg0KPiAgfCB8IHwg fA0KPg0KPiBSYWhtYW4gJiBEaWprIEV4cGlyZXMgQXByaWwgMjIsIDIwMTMgW1BhZ2UNCj4NCj4g MTBdDQo+DQo+IEludGVybmV0LURyYWZ0IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAgT2N0 b2Jlcg0KPg0KPiAyMDEyDQo+DQo+ICBGaWd1cmUgMTogQ29BUCBNdWx0aWNhc3QgYW5kIEhUVFAg VW5pY2FzdCBJbnRlcndvcmtpbmcNCj4NCj4gIE5vdGUgdGhhdCBGaWd1cmUgMSBpbGx1c3RyYXRl cyB0aGUgY2FzZSBvZiBJUCBtdWx0aWNhc3QgYXMgdGhlDQo+DQo+ICB1bmRlcmx5aW5nIGdyb3Vw IGNvbW11bmljYXRpb25zIG1lY2hhbmlzbS4gTUxEIGRlbm90ZXMgdGhlDQo+DQo+IE11bHRpY2Fz dA0KPg0KPiAgTGlzdGVuZXIgRGlzY292ZXJ5IHByb3RvY29sIChbUkZDMzgxMF0sIEFwcGVuZGl4 IEEpIGFuZCBMTCBkZW5vdGVzIGENCj4NCj4gIExpbmstTG9jYWwgbXVsdGljYXN0Lg0KPg0KPiAg QSBrZXkgcG9pbnQgaW4gRmlndXJlIDEgaXMgdGhhdCB0aGUgaW5jb21pbmcgSFRUUCBSZXF1ZXN0 IChmcm9tIG5vZGUNCj4NCj4gIDMpIHdpbGwgY2FycnkgYSBIb3N0IHJlcXVlc3QtaGVhZGVyIGZp ZWxkIHRoYXQgcmVzb2x2ZXMgaW4gdGhlDQo+DQo+ICBnZW5lcmFsIEludGVybmV0IHRvIHRoZSBw cm94eSBub2RlLiBBdCB0aGUgcHJveHkgbm9kZSwgdGhpcw0KPg0KPiBob3N0bmFtZQ0KPg0KPiAg YW5kL29yIHRoZSBSZXF1ZXN0LUxpbmUgVVJJIHdpbGwgdGhlbiBwb3NzaWJseSBiZSBtYXBwZWQg KGFzDQo+DQo+IGRldGFpbGVkDQo+DQo+ICBpbiBbSS1ELmNhc3RlbGxhbmktY29yZS1odHRwLW1h cHBpbmddKSBhbmQgYWdhaW4gcmVzb2x2ZWQgKHdpdGggdGhlDQo+DQo+ICBDb0FQIHNjaGVtZSkg dG8gYW4gSVAgbXVsdGljYXN0IGFkZHJlc3MuIFRoaXMgbWF5IGJlIGFjY29tcGxpc2hlZCwNCj4N Cj4gIGZvciBleGFtcGxlLCBieSB1c2luZyBETlMgb3IgRE5TLVNEIChTZWN0aW9uIDMuMykuIFRo ZSBwcm94eSBub2RlDQo+DQo+ICB3aWxsIHRoZW4gSVAgbXVsdGljYXN0IHRoZSBDb0FQIFJlcXVl c3QgKGNvcnJlc3BvbmRpbmcgdG8gdGhlDQo+DQo+ICByZWNlaXZlZCBIVFRQIFJlcXVlc3QpIHZp YSBtdWx0aWNhc3Qgcm91dGVycyB0byB0aGUgYXBwcm9wcmlhdGUNCj4NCj4gbm9kZXMNCj4NCj4g IChpLmUuIG5vZGVzIDEgYW5kIDIpLg0KPg0KPiAgSW4gdGVybXMgb2YgdGhlIEhUVFAgUmVzcG9u c2UsIEZpZ3VyZSAxIGlsbHVzdHJhdGVzIHRoYXQgaXQgd2lsbCBiZQ0KPg0KPiAgZ2VuZXJhdGVk IGJ5IHRoZSBwcm94eSBub2RlIGJhc2VkIG9uIGFnZ3JlZ2F0ZWQgcmVzcG9uc2VzIG9mIHRoZQ0K Pg0KPiBDb0FQDQo+DQo+ICBub2RlcyBhbmQgc2VudCBiYWNrIHRvIHRoZSBjbGllbnQgaW4gdGhl IGdlbmVyYWwgSW50ZXJuZXQgdGhhdCBzZW50DQo+DQo+ICB0aGUgSFRUUCBSZXF1ZXN0IChpLmUu IG5vZGUgMSkuIEluDQo+DQo+ICBbSS1ELmNhc3RlbGxhbmktY29yZS1hZHZhbmNlZC1odHRwLW1h cHBpbmddIHRoZSBIVFRQIFJlc3BvbnNlIHRoYXQNCj4NCj4gIHRoZSBQcm94eSBtYXkgdXNlIHRv IGFnZ3JlZ2F0ZSBtdWx0aXBsZSBDb0FQIHJlc3BvbnNlcyBpcyBkZXNjcmliZWQNCj4NCj4gIGlu IG1vcmUgZGV0YWlsLiBTbyBpbiB0ZXJtcyBvZiBvdmVyYWxsIG9wZXJhdGlvbiwgdGhlIENvQVAg cHJveHkNCj4NCj4gY2FuDQo+DQo+ICBiZSBjb25zaWRlcmVkIHRvIGJlIGEgIm5vbi10cmFuc3Bh cmVudCIgcHJveHkgYWNjb3JkaW5nIHRvDQo+DQo+IFtSRkMyNjE2XS4NCj4NCj4gIFNwZWNpZmlj YWxseSwgW1JGQzI2MTZdIHN0YXRlcyB0aGF0IGEgIm5vbi10cmFuc3BhcmVudCBwcm94eSBpcyBh DQo+DQo+ICBwcm94eSB0aGF0IG1vZGlmaWVzIHRoZSByZXF1ZXN0IG9yIHJlc3BvbnNlIGluIG9y ZGVyIHRvIHByb3ZpZGUgc29tZQ0KPg0KPiAgYWRkZWQgc2VydmljZSB0byB0aGUgdXNlciBhZ2Vu dCwgc3VjaCBhcyBncm91cCBhbm5vdGF0aW9uIHNlcnZpY2VzLA0KPg0KPiAgbWVkaWEgdHlwZSB0 cmFuc2Zvcm1hdGlvbiwgcHJvdG9jb2wgcmVkdWN0aW9uIG9yIGFub255bWl0eQ0KPg0KPiAgZmls dGVyaW5nLiINCj4NCj4gIEFuIGFsdGVybmF0aXZlIHRvIHRoZSBhYm92ZSBpcyB1c2luZyBhIEZv cndhcmQgUHJveHkuIEluIHRoaXMgY2FzZSwNCj4NCj4gIHRoZSBDb0FQIHJlcXVlc3QgVVJJIGlz IGNhcnJpZWQgaW4gdGhlIEhUVFAgUmVxdWVzdC1MaW5lIChhcyBkZWZpbmVkDQo+DQo+ICBpbiBb SS1ELmlldGYtY29yZS1jb2FwXSBTZWN0aW9uIDEwLjIpIGluIGEgSFRUUCByZXF1ZXN0IHNlbnQg dG8gdGhlDQo+DQo+ICBJUCBhZGRyZXNzIG9mIHRoZSBQcm94eS4NCj4NCj4gL2VuZCByZW1vdmUN Cj4NCj4gNC4gVXNlIENhc2VzIGFuZCBDb3JyZXNwb25kaW5nIFByb3RvY29sIEZsb3dzDQo+DQo+ IDQuMS4gSW50cm9kdWN0aW9uDQo+DQo+ICBUaGUgdXNlIG9mIENvQVAgZ3JvdXAgY29tbXVuaWNh dGlvbiBpcyBzaG93biBpbiB0aGUgY29udGV4dCBvZiB0aGUNCj4NCj4gIGZvbGxvd2luZyB1c2Ug Y2FzZXMgYW5kIGNvcnJlc3BvbmRpbmcgcHJvdG9jb2wgZmxvd3M6DQo+DQo+ICBvIERpc2NvdmVy eSBvZiBSZXNvdXJjZSBEaXJlY3Rvcnk6IGRpc2NvdmVyaW5nIHRoZSBsb2NhbCBDb1JFIFJEDQo+ DQo+ICB3aGljaCBjb250YWlucyBsaW5rcyAoVVJJcykgdG8gcmVzb3VyY2VzIHN0b3JlZCBvbiBv dGhlciBzZXJ2ZXJzDQo+DQo+ICBbUkZDNjY5MF0uDQo+DQo+IFJhaG1hbiAmIERpamsgRXhwaXJl cyBBcHJpbCAyMiwgMjAxMyBbUGFnZQ0KPg0KPiAxMV0NCj4NCj4gSW50ZXJuZXQtRHJhZnQgR3Jv dXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCBPY3RvYmVyDQo+DQo+IDIwMTINCj4NCj4gIG8gTGln aHRpbmcgQ29udHJvbDogc3luY2hyb25vdXMgb3BlcmF0aW9uIG9mIGEgZ3JvdXAgb2YgNkxvV1BB Tg0KPg0KPiAgW1JGQzQ5NDRdIElQdjYtY29ubmVjdGVkIGxpZ2h0cw0KPg0KPiAgbyBQYXJhbWV0 ZXIgVXBkYXRlOiB1cGRhdGluZyBwYXJhbWV0ZXJzL3NldHRpbmdzIHNpbXVsdGFuZW91c2x5IGlu DQo+DQo+IGENCj4NCj4gIGxhcmdlIGdyb3VwIG9mIGRldmljZXMgaW4gYSBidWlsZGluZy9jYW1w dXMgY29udHJvbA0KPg0KPiAgKFtJLUQudmFuZGVyc3Rvay1jb3JlLWJjXSkgYXBwbGljYXRpb24g LS0tIFRCRA0KPg0KPiAvIGNvbW1lbnQgSSBzdWdnZXN0IHRvIHJlbW92ZSBGaXJtd2FyZSBVcGRh dGUgYW5kIEdyb3VwcyBzdGF0dXMgcmVwb3J0DQo+DQo+IC9jb21tZW50IHRoZSBvbmVzIGFib3Zl IGFyZSBkaWZmaWN1bHQgZW5vdWdoLCBhbmQgSSBkb3VidCB0aGF0DQo+DQo+IHNpbXVsdGFuZWl0 eQ0KPg0KPiAvY29tbWVudCAobW90aXZhdGlvbiBvZiBtdWx0aWNhc3QpIGlzIGludm9sdmVkIGhl cmUNCj4NCj4gIG8gRmlybXdhcmUgVXBkYXRlOiBlZmZpY2llbnRseSB1cGRhdGluZyBmaXJtd2Fy ZSBzaW11bHRhbmVvdXNseSBpbg0KPg0KPiBhDQo+DQo+ICBsYXJnZSBncm91cCBvZiBkZXZpY2Vz IGluIGEgYnVpbGRpbmcvY2FtcHVzIGNvbnRyb2wNCj4NCj4gIChbSS1ELnZhbmRlcnN0b2stY29y ZS1iY10pIGFwcGxpY2F0aW9uIC0tLSBUQkQgc3VnZ2VzdHMgYQ0KPg0KPiAgbXVsdGljYXN0IGV4 dGVuc2lvbiBvZiBjb3JlLWJsb2NrLg0KPg0KPiAgbyBHcm91cCBTdGF0dXMgUmVwb3J0OiByZXF1 ZXN0aW5nIHN0YXR1cyBpbmZvcm1hdGlvbiBvciBldmVudA0KPg0KPiAgcmVwb3J0cyBmcm9tIGEg Z3JvdXAgb2YgZGV2aWNlcyBpbiBhIGJ1aWxkaW5nL2NhbXB1cyBjb250cm9sDQo+DQo+ICBhcHBs aWNhdGlvbiAtLS0gVEJELCBtYXkgcmVxdWlyZSByZWxpYWJsZSBncm91cCBjb21tdW5pY2F0aW9u IHRvDQo+DQo+ICBiZSBmZWFzaWJsZS4NCj4NCj4gNC4yLiBOZXR3b3JrIENvbmZpZ3VyYXRpb24N Cj4NCj4gIFdlIGFzc3VtZSB0aGUgZm9sbG93aW5nIG5ldHdvcmsgY29uZmlndXJhdGlvbiBmb3Ig YWxsIHRoZSB1c2UgY2FzZXMNCj4NCj4gIGFzIHNob3duIGluIEZpZ3VyZSAyOg0KPg0KPiAvY29t bWVudCB0aGUgY29uZmlndXJhdGlvbnMgZnJpZ2h0ZW4gbWUNCj4NCj4gL2NvbW1lbnQgZnJvbSBj b21wbGV0ZW5lc3MgY29uc2lkZXJhdGlvbnMgSSBjYW4gaW1hZ2luZSBldmVuIG1vcmUNCj4NCj4g Y29tcGxleCBvbmVzDQo+DQo+IC9jb21tZW50IEl0IG1pZ2h0IGJlIHVzZWZ1bCBpZiB0aGUgcHJh Y3RpY2FsIGltcG9zc2liaWxpdHkgb2Ygc29tZQ0KPg0KPiBjb25maWd1cmF0aW9ucyBpcyBoaWdo IGxpZ2h0ZWQNCj4NCj4gIG8gQSBsYXJnZSByb29tIChSb29tLUEpIHdpdGggdGhyZWUgbGlnaHRz IChMaWdodC0xLCBMaWdodC0yLA0KPg0KPiAgTGlnaHQtMykgY29udHJvbGxlZCBieSBhIExpZ2h0 IFN3aXRjaC4gVGhlIGRldmljZXMgYXJlIG9yZ2FuaXplZA0KPg0KPiAgaW50byB0d28gNkxvV1BB TiBzdWJuZXRzLg0KPg0KPiAvY29tbWVudCBvbmUgc3VibmV0IGlzIGVub3VnaCBmb3IgbWUNCj4N Cj4gL3JlbW92ZQ0KPg0KPiAgbyBMaWdodC0xIGFuZCB0aGUgTGlnaHQgU3dpdGNoIGFyZSBjb25u ZWN0ZWQgdG8gYSByb3V0ZXIgKFJ0ci0xKQ0KPg0KPiAgd2hpY2ggaXMgYWxzbyBhIENvQVAgUHJv eHksIGEgQ29BUCBSZXNvdXJjZSBEaXJlY3RvcnkgKFJEKSBhbmQgYQ0KPg0KPiAgNkxvV1BBTiBC b3JkZXIgUm91dGVyICg2TEJSKS4NCj4NCj4gIG8gTGlnaHQtMiBhbmQgdGhlIExpZ2h0LTMgYXJl IGNvbm5lY3RlZCB0byBhbm90aGVyIHJvdXRlciAoUnRyLTIpDQo+DQo+ICB3aGljaCBpcyBhbHNv IGEgQ29BUCBQcm94eSwgYSBDb0FQIFJEIGFuZCBhIDZMQlIuDQo+DQo+ICBvIFRoZSByb3V0ZXJz IGFyZSBjb25uZWN0ZWQgdG8gYW4gSVB2NiBuZXR3b3JrIGJhY2tib25lIHdoaWNoIGlzDQo+DQo+ ICBhbHNvIG11bHRpY2FzdCBlbmFibGVkLiBJbiB0aGUgZ2VuZXJhbCBjYXNlLCB0aGlzIG1lYW5z IHRoZQ0KPg0KPiAgbmV0d29yayBiYWNrYm9uZSBhbmQgNkxCUnMgc3VwcG9ydCBhIFBJTSBiYXNl ZCBtdWx0aWNhc3Qgcm91dGluZw0KPg0KPiAgcHJvdG9jb2wsIGFuZCBNTEQgZm9yIGZvcm1pbmcg Z3JvdXBzLiBJbiBhIGxpbWl0ZWQgY2FzZSwgaWYgdGhlDQo+DQo+ICBuZXR3b3JrIGJhY2tib25l IGlzIG9uZSBsaW5rLCB0aGVuIHRoZSByb3V0ZXJzIG9ubHkgaGF2ZSB0bw0KPg0KPiAgc3VwcG9y dCBNTEQtc25vb3BpbmcgKEFwcGVuZGl4IEEpIGZvciB0aGUgZm9sbG93aW5nIHVzZSBjYXNlcyB0 bw0KPg0KPiAgd29yay4NCj4NCj4gL2VuZCByZW1vdmUNCj4NCj4gL2NvbW1lbnQgSSBjYW4gaW1h Z2luZSB0aGF0IGFuIGNlbnRyYWwgY29udHJvbCBpcyBwcmVzZW50IG9uIHRoZQ0KPg0KPiBiYWNr Ym9uZQ0KPg0KPiAvY29tbWVudCBzd2l0Y2ggb3Igc2Vuc29yIHNlbmQgdW5pY2FzdCB0byBjZW50 cmFsIGNvbnRyb2wNCj4NCj4gL2NvbW1lbnQgY2VudHJhbCBjb250cm9sIHNlbmRzIG11bHRpY2Fz dCB0byBtdWx0aWNhc3QgZ3JvdXAgd2l0aGluDQo+DQo+IHNpbmdsZSBsb3dwYW4NCj4NCj4gUmFo bWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzIFtQYWdlDQo+DQo+IDEyXQ0KPg0KPiBJ bnRlcm5ldC1EcmFmdCBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQIE9jdG9iZXINCj4NCj4g MjAxMg0KPg0KPiBOZXR3b3JrDQo+DQo+IEJhY2tib25lDQo+DQo+IHwNCj4NCj4gICMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KPg0KPiB8DQo+DQo+ICAj IFJvb20tQSAjDQo+DQo+IHwNCj4NCj4gICMgKioqKioqKioqKioqKioqKioqKioqKiAjDQo+DQo+ IHwNCj4NCj4gICMgKiogTG9XUEFOLTEgKHN1Ym5ldC0xKSAqKiAjDQo+DQo+IHwNCj4NCj4gICMg KiAqICMNCj4NCj4gfA0KPg0KPiAgIyAqICstLS0tLS0tLS0tKyAqICMNCj4NCj4gfA0KPg0KPiAg IyAqIHwgTGlnaHQgfC0tLS0tLS0rICogIw0KPg0KPiB8DQo+DQo+ICAjICogfCBTd2l0Y2ggfCB8 ICogIw0KPg0KPiB8DQo+DQo+ICAjICogKy0tLS0tLS0tLS0rICstLS0tLS0tLS0rICogIw0KPg0K PiB8DQo+DQo+ICAjICogfCBSdHItMQ0KPg0KPiB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS18DQo+DQo+ICAjICogKy0tLS0tLS0tLSsgKiAjDQo+DQo+IHwNCj4NCj4gICMgKiArLS0tLS0t LS0tLSsgfCAqICMNCj4NCj4gfA0KPg0KPiAgIyAqIHwgTGlnaHQtMSB8LS0tLS0tLS0rICogIw0K Pg0KPiB8DQo+DQo+ICAjICogKy0tLS0tLS0tLS0rICogIw0KPg0KPiB8DQo+DQo+ICAjICogKiAj DQo+DQo+IHwNCj4NCj4gICMgKiogKiogIw0KPg0KPiB8DQo+DQo+ICAjICoqKioqKioqKioqKioq KioqKioqKiogIw0KPg0KPiB8DQo+DQo+ICAjICMNCj4NCj4gfA0KPg0KPiAgIyAjDQo+DQo+IHwN Cj4NCj4gICMgKioqKioqKioqKioqKioqKioqKioqKiAjDQo+DQo+IHwNCj4NCj4gICMgKiogTG9X UEFOLTIgKHN1Ym5ldC0yKSAqKiAjDQo+DQo+IHwNCj4NCj4gICMgKiAqICMNCj4NCj4gfA0KPg0K PiAgIyAqICstLS0tLS0tLS0tKyAqICMNCj4NCj4gfA0KPg0KPiAgIyAqIHwgTGlnaHQtMiB8LS0t LS0tLSsgKiAjDQo+DQo+IHwNCj4NCj4gICMgKiB8IHwgfCAqICMNCj4NCj4gfA0KPg0KPiAgIyAq ICstLS0tLS0tLS0tKyArLS0tLS0tLS0tKyAqICMNCj4NCj4gfA0KPg0KPiAgIyAqIHwgUnRyLTIN Cj4NCj4gfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KPg0KPiAgIyAqICstLS0tLS0t LS0rICogIw0KPg0KPiB8DQo+DQo+ICAjICogKy0tLS0tLS0tLS0rIHwgKiAjDQo+DQo+IHwNCj4N Cj4gICMgKiB8IExpZ2h0LTMgfC0tLS0tLS0tKyAqICMNCj4NCj4gfA0KPg0KPiAgIyAqICstLS0t LS0tLS0tKyAqICMNCj4NCj4gfA0KPg0KPiAgIyAqICogIw0KPg0KPiB8DQo+DQo+ICAjICoqICoq ICMNCj4NCj4gfA0KPg0KPiAgIyAqKioqKioqKioqKioqKioqKioqKioqICMNCj4NCj4gfA0KPg0K PiAgIyAjDQo+DQo+IHwNCj4NCj4gICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMNCj4NCj4gfA0KPg0KPiB8DQo+DQo+ICArLS0tLS0tLS0rDQo+DQo+IHwN Cj4NCj4gIHwgRE5TDQo+DQo+IHwtLS0tLS0tLS0tLS0tLS0tLS18DQo+DQo+ICB8IFNlcnZlciB8 DQo+DQo+ICArLS0tLS0tLS0rDQo+DQo+ICBGaWd1cmUgMjogTmV0d29yayBUb3BvbG9neSBvZiBh IExhcmdlIFJvb20gKFJvb20tQSkNCj4NCj4gUmFobWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIy LCAyMDEzIFtQYWdlDQo+DQo+IDEzXQ0KPg0KPiBJbnRlcm5ldC1EcmFmdCBHcm91cCBDb21tdW5p Y2F0aW9uIGZvciBDb0FQIE9jdG9iZXINCj4NCj4gMjAxMg0KPg0KPiA0LjMuIERpc2NvdmVyeSBv ZiBSZXNvdXJjZSBEaXJlY3RvcnkNCj4NCj4gIFRoZSBwcm90b2NvbCBmbG93IGZvciBkaXNjb3Zl cnkgb2YgYSBSRCBmb3IgdGhlIGdpdmVuIG5ldHdvcmsgKG9mDQo+DQo+ICBGaWd1cmUgMikgaXMg c2hvd24gaW4gRmlndXJlIDM6DQo+DQo+ICBvIFRoZSBmaXh0dXJlIGZvciBMaWdodC0yIGlzIGlu c3RhbGxlZCBhbmQgcG93ZXJlZCBvbiBmb3IgdGhlIGZpcnN0DQo+DQo+ICB0aW1lLg0KPg0KPiAg byBMaWdodC0yIHdpbGwgdGhlbiBzZWFyY2ggZm9yIHRoZSBsb2NhbCBSRCAoUkQtMikgYnkgc2Vu ZGluZyBvdXQgYQ0KPg0KPiAgR0VUIHJlcXVlc3QgKHdpdGggdGhlICIvLndlbGwta25vd24vY29y ZT9ydD1jb3JlLnJkIiByZXF1ZXN0IFVSSSkNCj4NCj4gIHRvIHRoZSBzaXRlLWxvY2FsICJBbGwg Q29BUCBOb2RlcyIgYWRkcmVzcy4gSW4gdGhpcyBjYXNlLCB0aGUNCj4NCj4gIHNpdGUgaXMgYXNz dW1lZCB0byBpbmNsdWRlIGFsbCBub2RlcyBpbiB0aGUgc3VibmV0Lg0KPg0KPiAgbyBUaGlzIG11 bHRpY2FzdCBtZXNzYWdlIHdpbGwgdGhlbiBnbyB0byBlYWNoIG5vZGUgaW4gc3VibmV0LTIuDQo+ DQo+ICBIb3dldmVyLCBvbmx5IFJ0ci0yIChSRC0yKSB3aWxsIHJlc3BvbmQgYmVjYXVzZSB0aGUg R0VUIGlzDQo+DQo+ICBxdWFsaWZpZWQgYnkgdGhlIHF1ZXJ5IHN0cmluZyAiP3J0PWNvcmUucmQi Lg0KPg0KPiAgbyBOb3RlIHRoYXQgdGhlIGZsb3cgaXMgc2hvd24gb25seSBmb3IgTGlnaHQtMiBm b3IgY2xhcml0eS4NCj4NCj4gU2ltaWxhcg0KPg0KPiAgZmxvd3Mgd2lsbCBoYXBwZW4gZm9yIExp Z2h0LTEsIExpZ2h0LTMgYW5kIHRoZSBMaWdodCBTd2l0Y2ggd2hlbg0KPg0KPiAgdGhleSBhcmUg Zmlyc3QgcG93ZXJlZCBvbi4NCj4NCj4gIFRoZSBSRCBtYXkgYWxzbyBiZSBkaXNjb3ZlcmVkIGJ5 IG90aGVyIG1lYW5zIHN1Y2ggYXMgYnkgYXNzdW1pbmcgYQ0KPg0KPiAgZGVmYXVsdCBsb2NhdGlv biAoZS5nLiBvbiBhIDZMQlIpLCB1c2luZyBESENQLCBhbnljYXN0IGFkZHJlc3MsIGV0Yy4NCj4N Cj4gIEhvd2V2ZXIsIHRoZXNlIGFwcHJvYWNoZXMgZG8gbm90IGludm9rZSBDb0FQIGdyb3VwIGNv bW11bmljYXRpb24gc28NCj4NCj4gIGFyZSBub3QgZnVydGhlciBkaXNjdXNzZWQgaGVyZS4NCj4N Cj4gIEZvciBvdGhlciBkaXNjb3ZlcnkgdXNlIGNhc2VzIHN1Y2ggYXMgZGlzY292ZXJpbmcgbG9j YWwgQ29BUA0KPg0KPiBzZXJ2ZXJzLA0KPg0KPiAgc2VydmljZXMgb3IgcmVzb3VyY2VzIGdyb3Vw IGNvbW11bmljYXRpb24gY2FuIGJlIHVzZWQgaW4gYSBzaW1pbGFyDQo+DQo+ICBmYXNoaW9uIGFz IGluIHRoZSBhYm92ZSB1c2UgY2FzZS4gQm90aCBMaW5rLUxvY2FsIChMTCkgYW5kIHNpdGUtDQo+ DQo+ICBsb2NhbCBkaXNjb3ZlcnkgYXJlIHBvc3NpYmxlIHRoaXMgd2F5Lg0KPg0KPiAvY29tbWVu dCB0aGUgUkQgZGlzY292ZXJ5IHdpbGwgYmUgbW9yZSBjb21wbGV4IHdoZW4gdGhlcmUgaXMgYSBy b3V0ZXINCj4NCj4gYmV0d2VlbiBsaWdodC0yIGFuZCBzd2l0Y2gNCj4NCj4gL2NvbW1lbnQgVmlh IHdoaWNoIFJEIHdpbGwgbGlnaHQgc3dpdGNoIGRpc2NvdmVyIGxpZ2h0LTI/DQo+DQo+IC9jb21t ZW50IGFkZGl0aW9uYWwgcmVhc29uIHRvIHJlbW92ZSByb3V0ZXIgZnJvbSB0aGUgbXVsdGljYXN0 DQo+DQo+IGNvbmZpZ3VyYXRpb24NCj4NCj4gUmFobWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIy LCAyMDEzIFtQYWdlDQo+DQo+IDE0XQ0KPg0KPiBJbnRlcm5ldC1EcmFmdCBHcm91cCBDb21tdW5p Y2F0aW9uIGZvciBDb0FQIE9jdG9iZXINCj4NCj4gMjAxMg0KPg0KPiAgTGlnaHQgUnRyLTEgUnRy LTINCj4NCj4gTmV0d29yaw0KPg0KPiAgTGlnaHQtMSBMaWdodC0yIExpZ2h0LTMgU3dpdGNoIChS RC0xKSAoUkQtMikNCj4NCj4gQmFja2JvbmUNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwg fCB8IHwgfCB8IHwNCj4NCj4gICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiogfCB8 IHwNCj4NCj4gICogTGlnaHQtMiBpcyBpbnN0YWxsZWQgKiB8IHwgfA0KPg0KPiAgKiBhbmQgcG93 ZXJzIG9uIGZvciBmaXJzdCB0aW1lICogfCB8IHwNCj4NCj4gICoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKiogfCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwg fCB8IHwNCj4NCj4gIHwgfCBDT0FQIE5PTiAoR0VUIHwgfA0KPg0KPiAgfCB8IC8ud2VsbC1rbm93 bi9jb3JlP3J0PWNvcmUucmQpIHwgfA0KPg0KPiAgfCB8LS0tLS0tLS0tPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPnwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwg fCB8IHwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IENPQVAgTk9OICgyLjA1IENv bnRlbnQgfCB8DQo+DQo+ICB8IHwgPC9yZD47cnQ9ImNvcmUucmQiO2lucz0iUHJpbWFyeSIpIHwg fA0KPg0KPiAgfCB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwg fA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgRmlndXJlIDM6IFJlc291cmNlIERpcmVjdG9y eSBEaXNjb3ZlcnkgdmlhIE11bHRpY2FzdCBNZXNzYWdlDQo+DQo+IDQuNC4gTGlnaHRpbmcgQ29u dHJvbA0KPg0KPiAvY29tbWVudCBJIGFtIGNvbmZ1c2VkIGFib3V0IHRoZSB1c2Ugb2YgcHJvdG9j b2xzDQo+DQo+IC9jb21tZW50IE1MRCBpcyB1c2VkIHRvIGZvcm0gZ3JvdXBzLCBjb3JyZWN0Pw0K Pg0KPiAvY29tbWVudCBidXQgdGhhdCB3YXMgYWxyZWFkeSBkb25lIGJ5IGVuYWJsaW5nIHRoZSBN QyBhZGRyZXNzIGluIHRoZQ0KPg0KPiBsaWdodHMgKHBvaW50IDIpDQo+DQo+IC9jb21tZW50IFRo ZXJlIGFyZSBzZXZlcmFsIHdheXMgdG8gc2V0IHVwIGdyb3VwcywgcG9pbnRpbmcgdGhlbSBvdXQN Cj4gYW5kDQo+DQo+IHdoZW4gdG8gdXNlIHRoZW0gd291bGQgYmUgYW4gYXNzZXQuDQo+DQo+ICBU aGUgcHJvdG9jb2wgZmxvdyBmb3IgYSBidWlsZGluZyBhdXRvbWF0aW9uIGxpZ2h0aW5nIGNvbnRy b2wNCj4NCj4gc2NlbmFyaW8NCj4NCj4gIGZvciB0aGUgbmV0d29yayAoRmlndXJlIDIpIGlzIHNo b3duIGluIHNlcXVlbmNlIGluIEZpZ3VyZSA0LA0KPg0KPiAgRmlndXJlIDUsIGFuZCBGaWd1cmUg Ni4gV2UgYXNzdW1lIHRoZSBmb2xsb3dpbmcgc3RlcHMgb2NjdXIgYmVmb3JlDQo+DQo+ICB0aGUg aWxsdXN0cmF0ZWQgZmxvdzoNCj4NCj4gIG8gMSkgU3RhcnR1cCBwaGFzZTogNkxvV1BBTnMgYXJl IGZvcm1lZC4gSVB2NiBhZGRyZXNzZXMgYXNzaWduZWQNCj4NCj4gdG8NCj4NCj4gIGFsbCBkZXZp Y2VzLiBUaGUgQ29BUCBuZXR3b3JrIGlzIGZvcm1lZC4NCj4NCj4gIG8gMikgQ29tbWlzc2lvbmlu ZyBwaGFzZSAoYnkgYXBwbGljYXRpb25zKTogVGhlIElQIG11bHRpY2FzdA0KPg0KPiBhZGRyZXNz DQo+DQo+ICBvZiB0aGUgZ3JvdXAgKFJvb20tQS1MaWdodHMpIGhhcyBiZWVuDQo+DQo+IC9zIHNl dCAvcyBlbmFibGUNCj4NCj4gIGluIGFsbCB0aGUgTGlnaHRzLiBUaGUNCj4NCj4gIFVSSSBvZiB0 aGUgZ3JvdXAgKFJvb20tQS1MaWdodHMpIGhhcyBiZWVuDQo+DQo+IC9zIHNldCAvcyByZXNvbHZl ZA0KPg0KPiAgaW4gdGhlIExpZ2h0IFN3aXRjaC4NCj4NCj4gIG8gMykgVGhlIGluZGljYXRlZCBN TEQgUmVwb3J0IG1lc3NhZ2VzIGFyZSBsaW5rLWxvY2FsIG11bHRpY2FzdC4NCj4NCj4gSW4NCj4N Cj4gIGVhY2ggTG9XUEFOLCBpdCBpcyBhc3N1bWVkIHRoYXQgYSBtdWx0aWNhc3Qgcm91dGluZy9m b3J3YXJkaW5nDQo+DQo+ICBwcm90b2NvbCBpbiA2TFJzIHdpbGwgdGhlbiBwcm9wYWdhdGUgdGhl IEpvaW4gaW5mb3JtYXRpb24NCj4NCj4gIGNvbnRhaW5lZCBpbiB0aGUgTUxEIFJlcG9ydCBvdmVy IG11bHRpcGxlIGhvcHMgdG8gdGhlIDZMQlIuDQo+DQo+IC9jb21tZW50IERvbid0IHNlZSB0aGUg bmVlZA0KPg0KPiBSYWhtYW4gJiBEaWprIEV4cGlyZXMgQXByaWwgMjIsIDIwMTMgW1BhZ2UNCj4N Cj4gMTVdDQo+DQo+IEludGVybmV0LURyYWZ0IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAg T2N0b2Jlcg0KPg0KPiAyMDEyDQo+DQo+ICBMaWdodCBSdHItMSBSdHItMg0KPg0KPiBOZXR3b3Jr DQo+DQo+ICBMaWdodC0xIExpZ2h0LTIgTGlnaHQtMyBTd2l0Y2ggKENvQVAgKENvQVANCj4NCj4g QmFja2JvbmUNCj4NCj4gIHwgfCB8IHwgUHJveHkpIFByb3h5KSB8DQo+DQo+ICB8IHwgfCB8IHwg fCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IE1MRCBSZXBvcnQ6IEpvaW4gfCB8IHwg fCB8DQo+DQo+ICB8IEdyb3VwIChSb29tLUEtTGlnaHRzKSB8IHwgfCB8DQo+DQo+ICB8LS0tTEwt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgfCB8DQo+DQo+ICB8IHwgfCB8 IHxNTEQgUmVwb3J0OiBKb2luIHwNCj4NCj4gIHwgfCB8IHwgfEdyb3VwIChSb29tLUEtTGlnaHRz KXwNCj4NCj4gIHwgfCB8IHwgfC0tLUxMLS0tLS0tLS0tLS0tLS0tPnwNCj4NCj4gIHwgfCB8IHwg fCB8IHwNCj4NCj4gIHwgfCBNTEQgUmVwb3J0OiBKb2luIHwgfCB8IHwNCj4NCj4gIHwgfCBHcm91 cCAoUm9vbS1BLUxpZ2h0cykgfCB8IHwNCj4NCj4gIHwgfC0tLUxMLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLT58IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8 IE1MRCBSZXBvcnQ6IEpvaW4gfCB8IHwNCj4NCj4gIHwgfCB8IEdyb3VwIChSb29tLUEtTGlnaHRz KSB8IHwNCj4NCj4gIHwgfCB8LS0tTEwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58IHwNCj4N Cj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwgfE1MRCBSZXBvcnQ6IEpvaW4gfA0KPg0K PiAgfCB8IHwgfCB8R3JvdXAgKFJvb20tQS1MaWdodHMpfA0KPg0KPiAgfCB8IHwgfCB8IHwtLS1M TC0tLS0+fA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAg RmlndXJlIDQ6IEpvaW5pbmcgTGlnaHRpbmcgR3JvdXBzIFVzaW5nIE1MRA0KPg0KPiAvY29tbWVu dCBwb3NzaWJseSByZW1vdmUgZnJvbSB0ZXh0LCBvciBkbyBzZXBhcmF0ZSBzZWN0aW9uIG9uIHVz ZSBvZg0KPg0KPiBNTEQNCj4NCj4gL2NvbW1lbnQgYW55d2F5IHNlcGFyYXRpbmcgY29tbWlzc2lv bmluZyBmcm9tIG9wZXJhdGlvbiBpbiBzZXBhcmF0ZQ0KPg0KPiBzZWN0aW9ucyBpcyBhIGdvb2Qg aWRlYS4NCj4NCj4gL2NvbW1lbnQgdGhlIHByb3hpZXMgYXJlIGEgY29tcGxpY2F0aW9uIGluIHRo ZSBwaWN0dXJlIG5vdCBlbGFib3JhdGVkDQo+DQo+IGluIHRoZSB0ZXh0Lg0KPg0KPiAvY29tbWVu dCB0aGUgc3ViamVjdCBvZiBwcm94aWVzIGlzIGFub3RoZXIgb25lLCB0byBiZSB0cmVhdGVkDQo+ DQo+IGVsc2V3aGVyZS4NCj4NCj4gL2NvbW1lbnQgYWxzbyBmb3IgcHJveGllcyB0aGUgZG8ncyBh bmQgZG9uJ3QncyBmcm9tIGEgc2ltcGxlDQo+DQo+IHBlcmZvcm1hbmNlIHBlcnNwZWN0aXZlIHdp bGwgYmUgaW50ZXJlc3RpbmcNCj4NCj4gUmFobWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIyLCAy MDEzIFtQYWdlDQo+DQo+IDE2XQ0KPg0KPiBJbnRlcm5ldC1EcmFmdCBHcm91cCBDb21tdW5pY2F0 aW9uIGZvciBDb0FQIE9jdG9iZXINCj4NCj4gMjAxMg0KPg0KPiAgTGlnaHQgUnRyLTEgUnRyLTIN Cj4NCj4gTmV0d29yaw0KPg0KPiAgTGlnaHQtMSBMaWdodC0yIExpZ2h0LTMgU3dpdGNoIChDb0FQ IChDb0FQDQo+DQo+IEJhY2tib25lDQo+DQo+ICB8IHwgfCB8IFByb3h5KSBQcm94eSkgfA0KPg0K PiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8ICoqKioqKioqKioqKioqKioqKioqKioqIHwgfA0K Pg0KPiAgfCB8ICogVXNlciBmbGlwcyBvbiAqIHwgfA0KPg0KPiAgfCB8ICogbGlnaHQgc3dpdGNo IHRvICogfCB8DQo+DQo+ICB8IHwgKiB0dXJuIG9uIGFsbCB0aGUgKiB8IHwNCj4NCj4gIHwgfCAq IGxpZ2h0cyBpbiBSb29tIEEgKiB8IHwNCj4NCj4gIHwgfCAqKioqKioqKioqKioqKioqKioqKioq KiB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwg fCB8IENPQVAgTk9OIChQVVQgfCB8IHwNCj4NCj4gIHwgfCB8IFByb3h5LVVSSSB8IHwgfA0KPg0K PiAgfCB8IHwgVVJJIGZvciBSb29tLUEtTGlnaHRzIHwNCj4NCj4gIHwgfCB8IFBheWxvYWQ9dHVy biBvbiBsaWdodHMpIHwNCj4NCj4gIHwgfCB8IHwtLS0tLS0tLS0+fCB8IHwNCj4NCj4gIHwgfCB8 IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwgUmVxdWVzdCBETlMg cmVzb2x1dGlvbiBvZiB8DQo+DQo+ICB8IHwgfCB8IFVSSSBmb3IgUm9vbS1BLUxpZ2h0cyB8DQo+ DQo+ICB8IHwgfCB8IHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+DQo+ICB8IHwgfCB8IHwgfCB8 DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IEROUyByZXR1cm5zOiBBQUFBIHwN Cj4NCj4gIHwgfCB8IHwgR3JvdXAgKFJvb20tQS1MaWdodHMpIHwNCj4NCj4gIHwgfCB8IHwgSVB2 NiBtdWx0aWNhc3QgYWRkcmVzcyB8DQo+DQo+ICB8IHwgfCB8IHw8LS0tLS0tLS0tLS0tLS0tLS0t LS18DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwg fCBDT0FQIE5PTiAoUHV0IHwNCj4NCj4gIHwgfCB8IHwgVVJJIFBhdGggfA0KPg0KPiAgfCB8IHwg fCBQYXlsb2FkPXR1cm4gb24gbGlnaHRzKXwNCj4NCj4gIHwgfCB8IHwgRGVzdGluYXRpb24gSVAg QWRkcmVzcyA9IHwNCj4NCj4gIHwgfCB8IHwgSVAgbXVsdGljYXN0IGFkZHJlc3MgfA0KPg0KPiAg fCB8IHwgfCBmb3IgR3JvdXAgKFJvb20tQS1MaWdodHMpfA0KPg0KPiAgfCB8IHwgfCBPcmlnaW5h dGluZyBJUCBBZGRyZXNzID0gfA0KPg0KPiAgfCB8IHwgfCBSVFItMSB8DQo+DQo+ICB8IHwgfCB8 IHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+DQo+ICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLXwgfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwg fCB8IHwgfDwtLS0tLS0tLS18DQo+DQo+ICB8IHw8LS0tLS0tLS0tfDwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IHwg fCB8DQo+DQo+ICBGaWd1cmUgNTogU2VuZGluZyBMaWdodGluZyBDb250cm9sIE11bHRpY2FzdCBN ZXNzYWdlDQo+DQo+IFJhaG1hbiAmIERpamsgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyBbUGFnZQ0K Pg0KPiAxN10NCj4NCj4gSW50ZXJuZXQtRHJhZnQgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29B UCBPY3RvYmVyDQo+DQo+IDIwMTINCj4NCj4gIExpZ2h0IFJ0ci0xIFJ0ci0yDQo+DQo+IE5ldHdv cmsNCj4NCj4gIExpZ2h0LTEgTGlnaHQtMiBMaWdodC0zIFN3aXRjaCAoQ29BUCAoQ29BUA0KPg0K PiBCYWNrYm9uZQ0KPg0KPiAgfCB8IHwgfCBQcm94eSkgUHJveHkpIHwNCj4NCj4gIHwgfCB8IHwg fCB8IHwNCj4NCj4gICoqKioqKioqKioqKioqKioqKioqKioqIHwgfCB8IHwNCj4NCj4gICogTGln aHRzIGluIFJvb20tQSAqIHwgfCB8IHwNCj4NCj4gICogdHVybiBvbiAobmVhcmx5ICogfCB8IHwg fA0KPg0KPiAgKiBzaW11bHRhbmVvdXNseSkgKiB8IHwgfCB8DQo+DQo+ICAqKioqKioqKioqKioq KioqKioqKioqKiB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IHwg fCB8DQo+DQo+ICB8IENPQVAgTk9OICgyLjA0IENoYW5nZWQpIHwgfCB8IHwNCj4NCj4gIHwtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCB8IHwNCj4NCj4gIHwgfCB8 IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgQ09BUCBOT04gKDIuMDQgQ2hh bmdlZCkgfCB8IHwNCj4NCj4gIHwgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCB8 IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCBD T0FQIE5PTiAoNS4wMCBJbnRlcm5hbCBTZXJ2ZXIgRXJyb3IpIHwNCj4NCj4gIHwgfCB8LS0tLS0t LS0tLS0tLS0tLS0tLS0+fCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKiB8DQo+DQo+ICB8IHwgfCAqIFJ0ci0xIGFzIENv QVAgUHJveHkgKiB8DQo+DQo+ICB8IHwgfCAqIHwgc2VuZHMgdGhlIGluZGl2aWR1YWwgKiB8DQo+ DQo+ICB8IHwgfCAqIHwgcmVzcG9uc2VzIGJhY2sgdG8gKiB8DQo+DQo+ICB8IHwgfCAqIHYgb3Jp Z2luYXRvciAqIHwNCj4NCj4gIHwgfCB8ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiB8 DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCBDT0FQIE5PTiAoMi4wNCBDaGFuZ2Vk KSB8IHwNCj4NCj4gIHwgfCB8IHw8LS0tLS0tLS0tfCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwN Cj4NCj4gIHwgfCB8IENPQVAgTk9OICgyLjA0IENoYW5nZWQpIHwgfA0KPg0KPiAgfCB8IHwgfDwt LS0tLS0tLS18IHwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgQ09BUCBOT04g KDUuMDAgSW50ZXJuYWwgU2VydmVyIEVycm9yKSB8DQo+DQo+ICB8IHwgfCB8PC0tLS0tLS0tLXwg fCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICBGaWd1cmUgNjogU2VuZGluZyBMaWdodGlu ZyBDb250cm9sIFJlc3BvbnNlIHRvIE11bHRpY2FzdCBNZXNzYWdlDQo+DQo+ICBOT1RFOiBJbiB0 aGUgbGFzdCBzdGVwIG9mIEZpZ3VyZSA2LCBSdHItMSBhY3RpbmcgYXMgQ29BUCBwcm94eSwNCj4N Cj4gIHJldHVybnMgbXVsdGlwbGUgaW5kaXZpZHVhbCBDb0FQIHJlc3BvbnNlcyB0byB0aGUgY2xp ZW50LiBFYWNoDQo+DQo+ICByZXNwb25zZSBlY2hvZXMgdGhlIFRva2VuIG9mIHRoZSBjbGllbnQn cyByZXF1ZXN0LiBUaGUgY2xpZW50IGNhbg0KPg0KPiAgaWRlbnRpZnkgdGhlIG9yaWdpbmFsIHNv dXJjZSBvZiBlYWNoIHJlc3BvbnNlIGJ5IC4uLlRCRC4NCj4NCj4gL2NvbW1lbnQgV0hZIGFyZSB0 aGUgbXVsdGljYXN0IGRlc3RpbmF0aW9ucyBzZW5kaW5nIGJhY2sgcmVzdWx0cz8NCj4NCj4gL2Nv bW1lbnQgSSB0aG91Z2h0IHRoYXQgeW91IHdhbnRlZCBNQyBtZXNzYWdlcyB0byBiZSBub24gY29u ZmlybWFibGUNCj4NCj4gL2NvbW1lbnQgc2VuZGluZyByZXNwb25zZXMgc2VlbXMgdG8gY29udHJh ZGljdCB0aGlzIC4NCj4NCj4gL2NvbW1lbnQgcGxlYXNlIHJlbW92ZSBzZW5kaW5nIGJhY2sgb2Yg cmVzcG9uc2VzLg0KPg0KPiAvY29tbWVudCBvbmUgbWF5IGFzc3VtZSB0aGF0IHRoZSBNQyBhbGdv cml0aG0gd2l0aGluIHRoZSBsb3dwYW4gaXMNCj4NCj4gcmVsaWFibGUgKGFsbCBkZXN0aW5hdGlv bnMgcmVjZWl2ZSB0aGUgbWVzc2FnZSkNCj4NCj4gL2NvbW1lbnQgYW55d2F5IE1QTCBjb21lcyBj bG9zZSBlbm91Z2ggdG8gdGhlIHJlbGlhYmlsaXR5IHJlcXVpcmVtZW50DQo+DQo+IGdpdmVuIGEg c3BlY2lmaWFibGUgcmFuZ2Ugb2YgY29uZmlndXJhdGlvbnMNCj4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pg0KPg0KPiAtLQ0KPg0KPiBQZXRlciB2YW4gZGVyIFN0b2sNCj4NCj4gbWFpbHRvOiBjb25zdWx0 YW5jeUB2YW5kZXJzdG9rLm9yZw0KPg0KPiB3d3c6IHd3dy52YW5kZXJzdG9rLm9yZyBbM10NCj4N Cj4gdGVsIE5MOiArMzEoMCk0OTI0NzQ2NzMgRjogKzMzKDApOTY2MDE1MjQ4DQo+DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kDQo+IGxlZ2FsbHkgcHJvdGVjdGVkIHVu ZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkNCj4gZm9y IHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHlvdSBhcmUNCj4gaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlz c2VtaW5hdGlvbiwgb3INCj4gcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUNCj4gdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZQ0KPiBzZW5kZXIgYnkgcmV0dXJu IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbA0KPiBtZXNzYWdl Lg0KPg0KPg0KPiBMaW5rczoNCj4gLS0tLS0tDQo+IFsxXSBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZHJhZnRzL2N1cnJlbnQvDQo+IFsyXSBodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNl bnNlLWluZm8NCj4gWzNdIGh0dHA6Ly93d3cudmFuZGVyc3Rvay5vcmcNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt ZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgDQpwcm90ZWN0ZWQgdW5kZXIg YXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIA0K YWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCANCnRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5h dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyANCnN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIA0K cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5k IGRlc3Ryb3kgYWxsIGNvcGllcyANCm9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0 DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmUgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpj b3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlDQo= From cabo@tzi.org Sun Nov 3 09:10:13 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A021E8098 for ; Sun, 3 Nov 2013 09:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.624 X-Spam-Level: X-Spam-Status: No, score=-107.624 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtMfDwa5IBea for ; Sun, 3 Nov 2013 09:10:09 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B99E711E8196 for ; Sun, 3 Nov 2013 09:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA3H9ojT022858 for ; Sun, 3 Nov 2013 18:09:50 +0100 (CET) Received: from dhcp-9560.meeting.ietf.org (dhcp-9560.meeting.ietf.org [31.133.149.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B934C4B0; Sun, 3 Nov 2013 18:09:49 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Carsten Bormann In-Reply-To: Date: Sun, 3 Nov 2013 09:09:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5268FF91.7050301@tzi.de> <52E62492-A2FF-45BF-8AE1-016F71BF8A3D@tzi.org> To: "core@ietf.org" X-Mailer: Apple Mail (2.1816) Subject: Re: [core] Invitation to Core-AA Meeting on Sunday 3rd Nov X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 17:10:13 -0000 =85 and there is an update, now also under a new and improved URI: http://bit.ly/core-aa-slides There are placeholders in there for the slide sets that are still = missing. If you have a placeholder, please send the slides before 11:45 PST. If you don=92t have a placeholder and are preparing slides, please = holler... Gr=FC=DFe, Carsten On 02 Nov 2013, at 21:18, Carsten Bormann wrote: > You can find a first consolidated slide set at >=20 > http://www.tzi.org/~cabo/Core-AA-show.pdf >=20 > If your slides aren=92t in there, please send them! > (If they are, please check for any mangling.) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 From weigengyu@bupt.edu.cn Sun Nov 3 20:28:47 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163A811E8291 for ; Sun, 3 Nov 2013 20:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Eckc+kA6Vci for ; Sun, 3 Nov 2013 20:28:42 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id E81E111E828A for ; Sun, 3 Nov 2013 20:28:41 -0800 (PST) Received: from WeiGengyuPC (unknown [221.218.40.231]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 553FB19F390; Mon, 4 Nov 2013 12:28:39 +0800 (HKT) Message-ID: <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> From: "weigengyu" To: "Rahman, Akbar" References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> In-Reply-To: Date: Mon, 4 Nov 2013 12:28:38 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: Core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 04:28:47 -0000 Hi Akbar, Thank you for your reply. > Reliable multicast is not supported. > We can perhaps make this more clear by adding a sentence in the Scope > (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). I belive it is required. I have misunderstood that it provides unreliable multicast just for the use case of Light Switch Control. And, I also want to ask the List, has anyone considered or been interested in CoAP Reliable Groupcomm or CoAP reliable multicast? Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Rahman, Akbar Sent: Sunday, November 03, 2013 10:56 PM To: weigengyu Cc: Core ; Dijk, Esko ; consultancy@vanderstok.org Subject: RE: [core] group-comm comments Hi Gengyu, Just some quick feedback. The groupcomm draft assumes only unreliable (i.e. not guaranteed) IP multicast. This is specified in http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.4 (see 1st paragraph) and http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-3.4 (see 3rd paragraph) Reliable multicast is not supported. We can perhaps make this more clear by adding a sentence in the Scope (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). Thanks for your review, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of weigengyu Sent: Saturday, November 02, 2013 9:16 AM To: Dijk, Esko; consultancy@vanderstok.org Cc: Core Subject: Re: [core] group-comm comments Hi, Esko I would like to give some comments on the GROUP-COMM draft. There have use cases for reliable and unreliable multicast communications. If this draft only for providing unreliable multicast over IP multicast, it is OK; just write it clearly. If the draft intends to have the reliable or partial multicast facility, the dtaft needs to give what mechanisms can gurantte that. The draft should define mechnisms that the server can register its capability of supporting multicast, this may be put to RD server; and wether to request reliable groupcomm shoule be the client's request. > To clarify: under the assumption that a server MAY respond to a multicast > request, A mechanism is required to make the server registers its capability. i.e. whether to support multicast; > and the client doesn't know a priori how many servers will respond to a > multicast, The client may lookup the information from the RD server (if the rerver's registeration processe were possible); > (since there are no guidelines/rules for that), the safest thing to do is > not send the multicast in the first place. If not first, when to make available? So, whether it is required should be determined by the client request, and there should have some authority or priority control to client. > Therefore the advice is to carefully control sending of multicast > requests. Not only to tell that, the draft should have clear descriptions about how the protocol supports multicast requiests and/or reliable multicast when required. regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Dijk, Esko Sent: Thursday, December 20, 2012 6:56 PM To: consultancy@vanderstok.org Cc: Core Subject: Re: [core] group-comm comments Thanks Peter, I would agree we need to include guidelines on returning of responses to CoAP multicast requests. (Note the CoAP spec ensures that a CoAP server will never ACK a multicast but that does not help a thing if it still sends a response packet...) I'll make a ticket for this. If anyone disagrees we'll hear it. > Then I do not understand the text, because "request", "reply" and > "response" are overloaded in my mind. To clarify: under the assumption that a server MAY respond to a multicast request, and the client doesn't know a priori how many servers will respond to a multicast, (since there are no guidelines/rules for that), the safest thing to do is not send the multicast in the first place. Therefore the advice is to carefully control sending of multicast requests. Esko -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: Thursday 20 December 2012 11:26 To: Dijk, Esko Cc: consultancy@vanderstok.org; akbar rahman; Core Subject: RE: group-comm comments Hi Esko, thanks for your reactions. I will group my answers, to better explain my points on the return of packets to MC senders. 1) Return of packets to multicast As I understand the multicast message is preferably sent with no confirmation (ack) because the return of all the acks may overwhelm the network and the sender of the multicast. The acknowledgement is not needed for MPL as the protocol has all the machinery to assure that all destinations receive it, (given constraints on network load and configuration density and size). Supposing an ack is needed, then it would be advisable to staffle the responses and an additional acknowledgement protocol could be added to the multicast protocol. The same is true if a message is returned (as in the case of mDNS). One can then wonder whether the application protocol (e.g. mDNS) should take care of the staffled response or that an additional protocol needs to be specified. I have no opinion on the choice, but see the need for the one or the other. Coming with a recommendation (explanation) on the subject of returning responses (acks) would be my recommendation for the GroupComm document. Below some reactions on your reactions. Hope this helps to clarify misunderstandings. Peter Dijk, Esko schreef op 2012-12-19 14:24: > Hi Peter, > > still a fair number of comments! I would agree with most. Below I have > selected some which we should discuss further, or ones I don’t agree > with: > > 1. Group communication definition -> > Why can't a source node be part of the group that it sends to? E.g. > combined sensor+luminaire use case. The IP stack would deliver sent > multicast CoAP requests also to the local application if it is > subscribed to the multicast IP address. source can of course be member of destination group. source may be part of the group (remove the "or may be not" part of the phrase) > > 2. I don’t see why we should add “the use of group communication for > mDNS is out of scope.” -> mDNS obviously is not CoAP, and the > document should define the scope anyway clearly as CoAP group > communication. So we don’t have to list any other protocols than CoAP. See my answer on return of packets. I wanted a clear statement on (NOT) specifying how applications handle the return of MC responses. > > 3. “so setting a multicast address in a source at installation is > forbidden?” -> No, that should not be forbidden :) It should also be > possible to set a CoAP path and/or port at installation time. That > means the two presented measures have to change or be removed. No comment > > 4. “there are 2 ways: (1) the node queries to which group it belongs > or (2) an instalation tools instructs the node to which groups” -> > Good point. (2) has been chosen because it works without relying on a > service to query (e.g. DNS or RD). Is that sufficient argumentation? > The mechanism is optional in any case so it does not block others from > defining a DNS or RD variant. I would point out both variants and mention that the draft focusses on (2) > > 5. “/s requests /s replies” -> > multicast replies (if you mean responses) do not exist in CoAP. It’s > about requests that should be carefully controlled since they generate > unicast responses. Then I do not understand the text, because "request", "reply" and "response" are overloaded in my mind. > > 6. “/comment what about the reply?” -> based on core-coap “If the > request message is Non-confirmable, then the response SHOULD be > returned in a Non-confirmable message as well.” > . Do you think we should quote this from the core-coap spec? As explained above The subject of returning packets to the MC sender needs careful consideration. the response being NOn-confirmable does not solve a lot I am afraid. > > 7. “/comment invoking as many certificates?” -> > core-coap-13 now loosens the concept of authentication to also > include other measures, not needing certificates. No comment > > 8. Network configuration: 2 subnets vs 1 -> maybe a one-subnet > configuration is worth adding? Here an overview of present/absent use > cases: > > - Link-local CoAP multicast with responses: Present, Appendix A of > core-coap > - Site-local CoAP multicast, single subnet: > - Site-local CoAP multicast, multi subnet, with or without responses > (in the new -04 groupcomm): Present > - Global CoAP multicast, single or multi subnet, with or without > responses: / dependency on IANA IPv6 allocation > - any configurations with a central controller on the backbone > multicasting: Again, the draft should go for the most frequent use cases and not try to be complete. Actually explicitly excluding use cases looks ineresting to me. > > 9. “It might be useful if the practical impossibility of some > configurations is high lighted” -> any thoughts, which would be > impossible? During the coap meeting in Atlanta, Cullen Jennings presented some horrifying examples, as far as I remember. > > 10.“the RD discovery will be more complex when there is a router > between light-2 and switch” -> yes, there are issues in RD/discovery > especially when more than one is present in a network. So, adapt the use case and exclude this possibility. > > 11.“additional reason to remove router from the multicast > configuration”-> hmm, I think that we should opt for having a single > RD in the system to avoid complexity. Routers are ok. (One of our > goals is to define how CoAP groupcomm works even across routers) Looking forward to the supporting protocol. > > 12.“MLD is used to form groups, correct? but that was already done by > enabling the MC address in the lights (point 2)” -> Step 1 is putting > the MC address in the lights, then step 2 is the Lights use MLD to > *ADVERTIZE* this address to any MLD-enabled Routers present > link-local. > So MLD is not a commissioning-time protocol but runs all the time > during operation. > Note that in groupcomm -04 we will remove MLD in the basic use case > and present it as an option later. Sounds good. The point is not to add protocols because they exist but because they are needed. > > 13.“WHY are the multicast destinations sending back results?” -> we > remove responses in the new -04 groupcomm. They are presented as an > optional thing that servers can do. > CoAP servers normally MUST respond to a request with a response > (core-coap-13) but an exception is now made for multicast where a > server MAY choose not to. This choice is completely independent from > confirmable/non-confirmable. Non-confirmable only means that an ACK > must not be sent. And an ACK is something different from a CoAP > response. > Agree that a protocol like MPL comes very close to ‘reliable > multicast’. see my worries at the beginning. > > Esko > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Tuesday 18 December 2012 12:06 > To: akbar rahman; Dijk, Esko; Core > Subject: group-comm comments > > Hi Akbar and Esko, > > I had promised to review, comment the group comm draft. > > Below the commented text. > > I have not gone very detailed with my comments. I hope that it is > clear from my comments that a reorganization of the draft and a review > of the uses cases are necessary to get a clearer picture of the > feasibility of group comm in the context of Coap. > > Especialy difficult to understand for me were: > > - the use case network configuration > > - the forming and enabling of groups > > - use of responses > > Hope this helps. > > Greetings, > > peter > > ______________________________________________________________________ > _______________________________ > > > Abstract > > CoAP is a RESTful transfer protocol for constrained devices. 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 document > > defines how the CoAP protocol should be used in a group communication > > context. An approach for using CoAP on top of IP multicast is > > detailed for both constrained and un-constrained networks. Also, > > various use > > /s causes /s cases/ > > and corresponding protocol flows are provided to > > illustrate important concepts. Finally, guidance is provided for > > deployment in various network topologies. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF). Note that other groups may also distribute > > working documents as Internet-Drafts. The list of current Internet- > > Drafts is at http://datatracker.ietf.org/drafts/current/ [1]. > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on April 22, 2013. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > > Provisions Relating to IETF Documents > > (http://trustee.ietf.org/license-info [2]) in effect on the date of > > Rahman & Dijk Expires April 22, 2013 [Page > > 1] > > Internet-Draft Group Communication for CoAP October > > 2012 > > publication of this document. Please review these documents > > carefully, as they describe your rights and restrictions with respect > > to this document. Code Components extracted from this document must > > include Simplified BSD License text as described in Section 4.e of > > the Trust Legal Provisions and are provided without warranty as > > described in the Simplified BSD License. > > 1. Conventions and Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > > This document assumes readers are familiar with the terms and > > concepts that are used in [I-D.ietf-core-coap]. In addition, this > > document defines the following terminology: > > Group Communication > > A source node sends a single message which is delivered to > > multiple destination nodes, where all destinations are identified > > to belong to a specific group. The source node may > > /remove or may not > > be > > part of the group. The underlying mechanism for group > > communication is assumed to be multicast based. > > /remove > > The network where > > the group communication takes place can be either a constrained > > or > > a regular (un-constrained) network/ > > /comment not sure about the meaning and consequences > > Multicast > > Sending a message to multiple destination nodes > > /s simultaneously./ > > /s with one network invocation / > > There are various options to implement multicast including layer > > 2 > > (Media Access Control) or layer 3 (IP) mechanisms. > > IP Multicast > > A specific multicast solution based on the use of IP multicast > > addresses as defined in "IANA Guidelines for IPv4 Multicast > > Address Assignments" [RFC5771] and "IP Version 6 Addressing > > Architecture" [RFC4291]. > > Low power and Lossy Network (LLN) > > Low power and Lossy Network (LLN): A type of constrained network > > where the devices are interconnected by a variety of low power, > > lossy links such as IEEE 802.15.4, Bluetooth, > > WiFi, wired > > or low > > power power-line communication links. > > 2. Introduction > > 2.1. Background > > The Constrained Application Protocol (CoAP) is an application > > protocol (analogous to HTTP) for resource constrained devices > > operating in an IP network [I-D.ietf-core-coap]. Constrained > > devices > > can be large in number, but are often highly correlated to each > > other > > (e.g. by type or location). For example, all the light switches in > > a > > building may belong to one group and all the thermostats may belong > > to another group. Groups may be composed by function. For example, > > Rahman & Dijk Expires April 22, 2013 [Page > > 3] > > Internet-Draft Group Communication for CoAP October > > 2012 > > the group "all lights in building one" may consist of the groups > > "all > > lights on floor one of building one", "all lights on floor two of > > building one", etc. Groups may be preconfigured > > /add before deployment > > or dynamically > > formed > > /add during operation > > . If information needs to be sent to or received from a group > > of devices, group communication mechanisms can improve efficiency > > and > > latency of communication and reduce bandwidth requirements for a > > given application. HTTP does not support any equivalent > > functionality to CoAP group communication. > > 2.2. Scope > > In this draft, we address the issues related to CoAP group > > communication in detail, with use cases, recommended approaches and > > analysis of the impact to the CoAP protocol and to implementations. > > /add the use of group communication for mDNS is out of scope. > > The guiding principle is to apply wherever possible existing IETF > > protocols to achieve group communication functionality. In many > > cases the contribution of this document lies in explaining how > > existing mechanisms may be used to > > /remove together > > fulfill CoAP group > > communication needs for specific use cases. > > 2.3. Potential Solutions for Group Communication > > The classic concept of group > > /s communications /s communication > > is that of a single > > source distributing content to multiple destination recipients that > > are all part of a group. Before content can be distributed, there > > is > > a separate process to form the group. The source may be either a > > member or non-member of the group. > > Group communication solutions have evolved from "bottom" to "top", > > i.e., from layer 2 (Media Access Control broadcast/multicast) and > > layer 3 (IP multicast) to application layer group communication, > > also > > referred to as application layer multicast. A study published in > > 2005 [Lao05] identified new solutions in the "middle" (referred to > > as > > overlay multicast) that utilize an infrastructure based on proxies. > > Each of these classes of solutions may be compared [Lao05] using > > metrics such as link stress and level of host complexity > > [Banerjee01]. The results show for a realistic internet topology > > that IP Multicast is the most resource-efficient, with the downside > > being that it requires > > /s the most /s more organizational > > effort to deploy in the > > infrastructure. IP Multicast is the solution adopted by this draft > > for CoAP group communication. > > 3. CoAP Group Communication Based On IP Multicast > > Rahman & Dijk Expires April 22, 2013 [Page > > 4] > > Internet-Draft Group Communication for CoAP October > > 2012 > > 3.1. IP Multicast Background > > IP Multicast routing protocols have been evolving for decades, > > resulting in proposed standards such as Protocol Independent > > Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various > > technical and marketing reasons, IP Multicast routing is not widely > > deployed on the general Internet. However, IP Multicast is very > > popular in specific deployments such as in enterprise networks (e.g. > > for video conferencing), smart home networks (e.g. UPnP/mDNS) and > > carrier IPTV deployments. The packet economy and minimal host > > complexity of IP multicast make it attractive for group > > communication > > in constrained environments. Therefore IP multicast is the > > recommended underlying mechanism for CoAP group communication, and > > the approach assumed in this document. > > To achieve IP multicast beyond a subnet, an IP multicast routing > > protocol needs to be active on routers. The RPL protocol [RFC6550] > > for example is able to route multicast traffic in constrained LLNs. > > While PIM-SM [RFC4601] is often used for multicast routing in un- > > constrained networks. > > IP multicast can also be run in a Link-Local (LL) scope. This means > > that there is no routing involved and an IP multicast message is > > only > > received > > /s on the network /s over the > > link on which it was sent. > > 3.2. CoAP Group Definition and Naming > > A group is defined as a set of CoAP endpoints, where each endpoint > > is > > configured to receive a multicast CoAP request that is sent to the > > group's associated IP multicast address. The group MAY have more > > than one associated IP multicast address. An endpoint MAY be a > > member of multiple groups. Group membership of an endpoint MAY > > dynamically change over time. The group MAY be identified by a > > Group > > Name ([I-D.vanderstok-core-dna]) which is defined as a prefix string > > of a Group FQDN. The Group FQDN can be uniquely mapped to a site- > > local or global multicast IP address via DNS resolution. > > A CoAP multicast request that addresses a group includes a Group URI > > as the request URI. A Group URI has the scheme 'coap' and includes > > in the authority part either a group IP address > > /add + optional port > > or a hostname > > /add + optional port > > that > > can be resolved to the group IP address (e.g., a Group Name or Group > > FQDN). Group URIs MUST follow the URI syntax [RFC3986]. > > A CoAP > > /s node /s end-point > > becomes a group member by listening for CoAP messages on > > the group's IP multicast address, assuming the default CoAP UDP > > port. > > Note that a non-default UDP port MAY be specified for the group; in > > which case implementers MUST ensure that all group members are > > configured to use this same port. > > Rahman & Dijk Expires April 22, 2013 [Page > > 5] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Examples of hierarchical group naming (and scoping) for a building > > control application are shown below. > > URI authority Targeted group > > all.bldg6.example.com "all nodes in building 6" > > all.west.bldg6.example.com "all nodes in west wing, building > > 6" > > all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, > > building 6" > > all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, > > west wing, building 6" > > Reverse mapping (from IP multicast address to group FQDN) is > > supported using the reverse DNS resolution technique > > ([I-D.vanderstok-core-dna]). > > 3.3. Group Discovery and Member Discovery > > CoAP defines a resource discovery capability, but does not yet > > specify how to discover groups (e.g. find a group to join or send a > > multicast message to) or to discover members of a group (e.g. to > > address selected group members by unicast). These topics are > > elaborated in more detail in [I-D.vanderstok-core-dna] including > > examples for using DNS-SD and CoRE Resource Directory. > > 3.3.1. DNS-SD > > DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a > > conventional way to configure DNS PTR, SRV, and TXT records to > > enable > > enumeration of services, such as services offered by CoAP nodes, or > > enumeration of all CoAP nodes, within specified subdomains. A > > service is specified by a name of the form > > .., where the service type for CoAP > > nodes is _coap._udp and the domain is a DNS domain name that > > identifies a group as in the examples above. For each CoAP > > end-point > > in a group, a PTR record with the name _coap._udp and/or a PTR > > record > > with the name _coap._udp. is defined and it points to an SRV > > record having the .. name. > > All CoAP nodes in a given subdomain may be enumerated by sending a > > query for PTR records named _coap._udp to the authoritative DNS > > server for that zone. A list of SRV records is returned. Each SRV > > record contains the port and host name (AAAA record) of a CoAP node. > > The IP address of the node is obtained by resolving the host name. > > DNS-SD also specifies an optional TXT record, having the same name > > as > > the SRV record, which can contain "key=value" attributes. This can > > be used to store information about the device, e.g. schema=DALI, > > type=switch, group=lighting.bldg6, etc. > > Rahman & Dijk Expires April 22, 2013 [Page > > 6] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Another feature of DNS-SD is the ability to specify service subtypes > > using PTR records. For example, one could represent all the CoAP > > groups in a subdomain by PTR records with the name > > _group._sub._coap._udp or alternatively > > _group._sub._coap._udp.. > > 3.3.2. CoRE Resource Directory > > CoRE Resource Directory [I-D.shelby-core-resource-directory] defines > > the concept of a Resource Directory (RD) server where CoAP servers > > can register their resources offered and CoAP clients can discover > > these resources by querying the RD server. RD syntax can be mapped > > to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], > > such that the above approach can be reused for group discovery and > > group member discovery. > > /remove Specifically, the Domain (d) parameter can be set to the > > group URI by > > an end-point registering to the RD. If an end-point wants to join > > multiple groups, it has to repeat the registration process for each > > group it wants to join. > > /end remove > > /comment d parameter semantics not clear > > 3.4. Group Resource Manipulation > > Group communications SHALL only be used for idempotent methods (i.e. > > CoAP GET, PUT, DELETE). The CoAP messages that are sent via > > multicast SHALL be Non-Confirmable. > > A unicast response per server MAY be sent back to answer the group > > request (e.g. response "2.05 Content" to a group GET request) taking > > into account the congestion control rules defined in > > [I-D.ietf-core-coap]. The unicast responses may be a mixture of > > success (e.g. 2.05 Content) and failure (e.g. 4.04 Not Found) codes > > depending on the individual server processing result. > > Group communications SHALL NOT be used for non-idempotent methods > > (i.e. CoAP POST). This is because not all group members are > > guaranteed to receive the multicast request, and the sender can not > > readily find out which group members did not receive it. > > All nodes in a given group SHOULD receive the same request > > /remove with high probability. > > /comment I don't see where probability comes in. > > This will not be the case if there is diversity in the > > authority port (i.e. a diversity of dynamic port addresses across > > the > > group) or if the targeted resource is located at different paths on > > different nodes. > > Therefore, some measures must be present to ensure uniformity in > > port > > number and resource names/locations within a group. This document > > proposes the following measures: > > Rahman & Dijk Expires April 22, 2013 [Page > > 7] > > Internet-Draft Group Communication for CoAP October > > 2012 > > o All CoAP multicast requests MUST be sent either to the default > > CoAP UDP port (i.e. default Uri-Port as defined in > > [I-D.ietf-core-coap]), or to a port number obtained via a service > > discovery lookup operation as a valid CoAP port for the targeted > > multicast group. > > o All CoAP multicast requests SHOULD operate only on URIs (links) > > which were > > /s retreived /s retrieved > > either from a "/.well-known/core" lookup on > > at least one group member node, or from an equivalent service > > discovery lookup which returns either the resources supported by > > all group members or resources supported by one particular group > > member. > > /comment so setting a multicast address in a source at installation is > > forbidden? > > 3.5. Configuring Group Membership In Endpoints > > In some use cases, the group membership of endpoints needs to be > > configurable after the network has been deployed. Example use cases > > can be found in building control: a commissioning tool determines to > > which groups a light or sensor node belongs, and writes this > > information to all nodes, which can subsequently join the correct > > group. > > To achieve smoother interoperability between nodes/endpoints from > > different manufacturers, it is proposed here to define an OPTIONAL > > standardized RESTful means of configuring CoAP endpoints with > > relevant group information. > > CoAP endpoints implementing this mechanism MUST support a > > discoverable "Group Configuration" resource of resource type (rt) > > [RFC6690] "core.gp". This resource (and perhaps its sub-resources, > > TBD) are used to manage group membership. Three design options for > > this mechanism are presented here as a placeholder (TBD). > > Design 1: use CoRE link format payloads to communicate group > > membership to endpoints. (TBD Not clear how this should be > > realized.) > > /comment, not clear what you mean either. Remove design 1 in this > state > > Design 2: use a JSON type resource. For example, a GET on the > > "core.gp" resource returns a JSON array of group objects. > > Req: GET /gp > > Res: 2.05 Content (Content-Format: application/json) > > [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", > > "ip": "ff05::4200:f7fe:ed37:14ca" } > > ] > > where "n" defines the Group FQDN and "ip" defines the associated > > multicast IP address. As a next example, the same endpoint can be > > Rahman & Dijk Expires April 22, 2013 [Page > > 8] > > Internet-Draft Group Communication for CoAP October > > 2012 > > added to another group by a POST on the resource with a JSON group > > object: > > Req: POST /gp (Content-Format: application/json) > > { "n": "floor1.west.bldg6.example.com", > > "ip": "ff05::4200:f7fe:ed37:14cb" } > > Res: 2.04 Changed > > Design 3: define named sub-resources, each sub-resource representing > > a group membership. The payload of the sub-resource may be JSON or > > a > > simple pre-defined format. Or alternatively, information is > > provided > > via POST with query parameters. > > /comment are these mutually exclusive designs? > > /comment design 2 without JSON is als possible > > /comment design with SRV and TXt records is also possible > > /comment there are 2 ways: (1) the node queries to which group it > > belongs > > /comment (2) an instalation tools instructs the node to which groups > > it belongs > > /comment not clear in text that this choice exists or that a choice > was > > made. > > 3.6. Congestion Control > > Multicast CoAP requests may result in a multitude of replies from > > different nodes, potentially causing congestion. Therefore sending > > multicast > > /s requests /s replies > > should be conservatively controlled. > > The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific > > congestion risks through the following measures: > > o A server MAY choose not to respond to a multicast request if > > there's nothing useful to respond (e.g. error or empty response). > > o A server SHOULD limit the support for multicast requests to > > specific resources where multicast operation is required. > > o A multicast request MUST be Non-Confirmable. > > /comment what about the reply? > > o A server does not respond immediately to a multicast request, but > > SHOULD first wait for a time that is randomly picked within a > > predetermined time interval called the Leisure. > > o A server SHOULD NOT accept multicast requests that can not be > > authenticated. > > /comment invoking as many certificates? > > Additional guidelines to reduce congestion risks are: > > o A server in an LLN should only support multicast GET for > > resources > > that are small, e.g. > > /remove for an LLN that could mean > > the payload of the > > response fits into a single link-layer frame. > > o A server can minimize the payload length in response to a > > multicast GET on "/.well-known/core" by using hierarchy in > > arranging link descriptions for the response. An example of this > > is given in Section 5 of [RFC6690]. > > Rahman & Dijk Expires April 22, 2013 [Page > > 9] > > Internet-Draft Group Communication for CoAP October > > 2012 > > o Preferably IP multicast with link-local scope should be used, > > rather than global or site-local. > > o The Hop Limit field in the IPv6 packet should be chosen as low as > > possible (if the CoAP/IP stack allows setting of this value. TBD > > - discuss whether this guideline is relevant/realistic in CoAP > > context) > > 3.7. CoAP Multicast and HTTP Unicast Interworking > > /comment a reference will suffice > > CoAP supports operation over UDP multicast, while HTTP does not. > > For > > use cases where it is required that CoAP group communication is > > initiated from an HTTP end-point, it would be advantageous if the > > HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group > > communication based on IP multicast. > > /remove One possible way of operation > > /remove of such HTTP-CoAP Proxy is illustrated in Figure 1. > > Note that this > > topic is covered in more detail in > > [I-D.castellani-core-advanced-http-mapping]. > > /remove > > CoAP Mcast CoAP Mcast HTTP-CoAP HTTP > > Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 > > | | | | | | > > |MLD REQUEST | | | | > > |(Join Group X) | | | | > > |--LL-->| | | | | > > | | |MLD REQUEST | | > > | | |(Join Group X) | | > > | | |--LL-->| | | > > | | | | | HTTP REQUEST | > > | | | | | (URI to | > > | | | | | unicast addr) | > > | | | | |< -----------------| > > | | | | | | > > | | | Resolve HTTP Request-Line URI | > > | | | to Group X multicast address | > > | | | | | | > > | CoAP REQUEST (to multicast addr)| | > > |< ------<---------<-------<------| | > > | | | | | | > > | | | | > > | (optional) CoAP RESPONSE(s) | | > > | |-------------->| | > > |-----------------|-------------->| Aggregated | > > | | | HTTP RESPONSE | > > | | |------------------>| > > | | | | > > Rahman & Dijk Expires April 22, 2013 [Page > > 10] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Figure 1: CoAP Multicast and HTTP Unicast Interworking > > Note that Figure 1 illustrates the case of IP multicast as the > > underlying group communications mechanism. MLD denotes the > > Multicast > > Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a > > Link-Local multicast. > > A key point in Figure 1 is that the incoming HTTP Request (from node > > 3) will carry a Host request-header field that resolves in the > > general Internet to the proxy node. At the proxy node, this > > hostname > > and/or the Request-Line URI will then possibly be mapped (as > > detailed > > in [I-D.castellani-core-http-mapping]) and again resolved (with the > > CoAP scheme) to an IP multicast address. This may be accomplished, > > for example, by using DNS or DNS-SD (Section 3.3). The proxy node > > will then IP multicast the CoAP Request (corresponding to the > > received HTTP Request) via multicast routers to the appropriate > > nodes > > (i.e. nodes 1 and 2). > > In terms of the HTTP Response, Figure 1 illustrates that it will be > > generated by the proxy node based on aggregated responses of the > > CoAP > > nodes and sent back to the client in the general Internet that sent > > the HTTP Request (i.e. node 1). In > > [I-D.castellani-core-advanced-http-mapping] the HTTP Response that > > the Proxy may use to aggregate multiple CoAP responses is described > > in more detail. So in terms of overall operation, the CoAP proxy > > can > > be considered to be a "non-transparent" proxy according to > > [RFC2616]. > > Specifically, [RFC2616] states that a "non-transparent proxy is a > > proxy that modifies the request or response in order to provide some > > added service to the user agent, such as group annotation services, > > media type transformation, protocol reduction or anonymity > > filtering." > > An alternative to the above is using a Forward Proxy. In this case, > > the CoAP request URI is carried in the HTTP Request-Line (as defined > > in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the > > IP address of the Proxy. > > /end remove > > 4. Use Cases and Corresponding Protocol Flows > > 4.1. Introduction > > The use of CoAP group communication is shown in the context of the > > following use cases and corresponding protocol flows: > > o Discovery of Resource Directory: discovering the local CoRE RD > > which contains links (URIs) to resources stored on other servers > > [RFC6690]. > > Rahman & Dijk Expires April 22, 2013 [Page > > 11] > > Internet-Draft Group Communication for CoAP October > > 2012 > > o Lighting Control: synchronous operation of a group of 6LoWPAN > > [RFC4944] IPv6-connected lights > > o Parameter Update: updating parameters/settings simultaneously in > > a > > large group of devices in a building/campus control > > ([I-D.vanderstok-core-bc]) application --- TBD > > / comment I suggest to remove Firmware Update and Groups status report > > /comment the ones above are difficult enough, and I doubt that > > simultaneity > > /comment (motivation of multicast) is involved here > > o Firmware Update: efficiently updating firmware simultaneously in > > a > > large group of devices in a building/campus control > > ([I-D.vanderstok-core-bc]) application --- TBD suggests a > > multicast extension of core-block. > > o Group Status Report: requesting status information or event > > reports from a group of devices in a building/campus control > > application --- TBD, may require reliable group communication to > > be feasible. > > 4.2. Network Configuration > > We assume the following network configuration for all the use cases > > as shown in Figure 2: > > /comment the configurations frighten me > > /comment from completeness considerations I can imagine even more > > complex ones > > /comment It might be useful if the practical impossibility of some > > configurations is high lighted > > o A large room (Room-A) with three lights (Light-1, Light-2, > > Light-3) controlled by a Light Switch. The devices are organized > > into two 6LoWPAN subnets. > > /comment one subnet is enough for me > > /remove > > o Light-1 and the Light Switch are connected to a router (Rtr-1) > > which is also a CoAP Proxy, a CoAP Resource Directory (RD) and a > > 6LoWPAN Border Router (6LBR). > > o Light-2 and the Light-3 are connected to another router (Rtr-2) > > which is also a CoAP Proxy, a CoAP RD and a 6LBR. > > o The routers are connected to an IPv6 network backbone which is > > also multicast enabled. In the general case, this means the > > network backbone and 6LBRs support a PIM based multicast routing > > protocol, and MLD for forming groups. In a limited case, if the > > network backbone is one link, then the routers only have to > > support MLD-snooping (Appendix A) for the following use cases to > > work. > > /end remove > > /comment I can imagine that an central control is present on the > > backbone > > /comment switch or sensor send unicast to central control > > /comment central control sends multicast to multicast group within > > single lowpan > > Rahman & Dijk Expires April 22, 2013 [Page > > 12] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Network > > Backbone > > | > > ################################################ > > | > > # Room-A # > > | > > # ********************** # > > | > > # ** LoWPAN-1 (subnet-1) ** # > > | > > # * * # > > | > > # * +----------+ * # > > | > > # * | Light |-------+ * # > > | > > # * | Switch | | * # > > | > > # * +----------+ +---------+ * # > > | > > # * | Rtr-1 > > |-----------------------------| > > # * +---------+ * # > > | > > # * +----------+ | * # > > | > > # * | Light-1 |--------+ * # > > | > > # * +----------+ * # > > | > > # * * # > > | > > # ** ** # > > | > > # ********************** # > > | > > # # > > | > > # # > > | > > # ********************** # > > | > > # ** LoWPAN-2 (subnet-2) ** # > > | > > # * * # > > | > > # * +----------+ * # > > | > > # * | Light-2 |-------+ * # > > | > > # * | | | * # > > | > > # * +----------+ +---------+ * # > > | > > # * | Rtr-2 > > |-----------------------------| > > # * +---------+ * # > > | > > # * +----------+ | * # > > | > > # * | Light-3 |--------+ * # > > | > > # * +----------+ * # > > | > > # * * # > > | > > # ** ** # > > | > > # ********************** # > > | > > # # > > | > > ################################################# > > | > > | > > +--------+ > > | > > | DNS > > |------------------| > > | Server | > > +--------+ > > Figure 2: Network Topology of a Large Room (Room-A) > > Rahman & Dijk Expires April 22, 2013 [Page > > 13] > > Internet-Draft Group Communication for CoAP October > > 2012 > > 4.3. Discovery of Resource Directory > > The protocol flow for discovery of a RD for the given network (of > > Figure 2) is shown in Figure 3: > > o The fixture for Light-2 is installed and powered on for the first > > time. > > o Light-2 will then search for the local RD (RD-2) by sending out a > > GET request (with the "/.well-known/core?rt=core.rd" request URI) > > to the site-local "All CoAP Nodes" address. In this case, the > > site is assumed to include all nodes in the subnet. > > o This multicast message will then go to each node in subnet-2. > > However, only Rtr-2 (RD-2) will respond because the GET is > > qualified by the query string "?rt=core.rd". > > o Note that the flow is shown only for Light-2 for clarity. > > Similar > > flows will happen for Light-1, Light-3 and the Light Switch when > > they are first powered on. > > The RD may also be discovered by other means such as by assuming a > > default location (e.g. on a 6LBR), using DHCP, anycast address, etc. > > However, these approaches do not invoke CoAP group communication so > > are not further discussed here. > > For other discovery use cases such as discovering local CoAP > > servers, > > services or resources group communication can be used in a similar > > fashion as in the above use case. Both Link-Local (LL) and site- > > local discovery are possible this way. > > /comment the RD discovery will be more complex when there is a router > > between light-2 and switch > > /comment Via which RD will light switch discover light-2? > > /comment additional reason to remove router from the multicast > > configuration > > Rahman & Dijk Expires April 22, 2013 [Page > > 14] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (RD-1) (RD-2) > > Backbone > > | | | | | | | > > | | | | | | | > > ********************************** | | | > > * Light-2 is installed * | | | > > * and powers on for first time * | | | > > ********************************** | | | > > | | | | | | | > > | | | | | | | > > | | COAP NON (GET | | > > | | /.well-known/core?rt=core.rd) | | > > | |--------->-------------------------------->| | > > | | | | | | | > > | | | | | | | > > | | | | | | | > > | | COAP NON (2.05 Content | | > > | | ;rt="core.rd";ins="Primary") | | > > | |<------------------------------------------| | > > | | | | | | | > > Figure 3: Resource Directory Discovery via Multicast Message > > 4.4. Lighting Control > > /comment I am confused about the use of protocols > > /comment MLD is used to form groups, correct? > > /comment but that was already done by enabling the MC address in the > > lights (point 2) > > /comment There are several ways to set up groups, pointing them out > and > > when to use them would be an asset. > > The protocol flow for a building automation lighting control > > scenario > > for the network (Figure 2) is shown in sequence in Figure 4, > > Figure 5, and Figure 6. We assume the following steps occur before > > the illustrated flow: > > o 1) Startup phase: 6LoWPANs are formed. IPv6 addresses assigned > > to > > all devices. The CoAP network is formed. > > o 2) Commissioning phase (by applications): The IP multicast > > address > > of the group (Room-A-Lights) has been > > /s set /s enable > > in all the Lights. The > > URI of the group (Room-A-Lights) has been > > /s set /s resolved > > in the Light Switch. > > o 3) The indicated MLD Report messages are link-local multicast. > > In > > each LoWPAN, it is assumed that a multicast routing/forwarding > > protocol in 6LRs will then propagate the Join information > > contained in the MLD Report over multiple hops to the 6LBR. > > /comment Don't see the need > > Rahman & Dijk Expires April 22, 2013 [Page > > 15] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (CoAP (CoAP > > Backbone > > | | | | Proxy) Proxy) | > > | | | | | | | > > | | | | | | | > > | MLD Report: Join | | | | | > > | Group (Room-A-Lights) | | | | > > |---LL------------------------------------->| | | > > | | | | |MLD Report: Join | > > | | | | |Group (Room-A-Lights)| > > | | | | |---LL--------------->| > > | | | | | | | > > | | MLD Report: Join | | | | > > | | Group (Room-A-Lights) | | | > > | |---LL------------------------------------->| | > > | | | | | | | > > | | | MLD Report: Join | | | > > | | | Group (Room-A-Lights) | | > > | | |---LL-------------------------->| | > > | | | | | | | > > | | | | |MLD Report: Join | > > | | | | |Group (Room-A-Lights)| > > | | | | | |---LL---->| > > | | | | | | | > > | | | | | | | > > Figure 4: Joining Lighting Groups Using MLD > > /comment possibly remove from text, or do separate section on use of > > MLD > > /comment anyway separating commissioning from operation in separate > > sections is a good idea. > > /comment the proxies are a complication in the picture not elaborated > > in the text. > > /comment the subject of proxies is another one, to be treated > > elsewhere. > > /comment also for proxies the do's and don't's from a simple > > performance perspective will be interesting > > Rahman & Dijk Expires April 22, 2013 [Page > > 16] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (CoAP (CoAP > > Backbone > > | | | | Proxy) Proxy) | > > | | | | | | | > > | | *********************** | | > > | | * User flips on * | | > > | | * light switch to * | | > > | | * turn on all the * | | > > | | * lights in Room A * | | > > | | *********************** | | > > | | | | | | | > > | | | | | | | > > | | | COAP NON (PUT | | | > > | | | Proxy-URI | | | > > | | | URI for Room-A-Lights | > > | | | Payload=turn on lights) | > > | | | |--------->| | | > > | | | | | | | > > | | | | | | | > > | | | | Request DNS resolution of | > > | | | | URI for Room-A-Lights | > > | | | | |-------------------->| > > | | | | | | | > > | | | | | | | > > | | | | DNS returns: AAAA | > > | | | | Group (Room-A-Lights) | > > | | | | IPv6 multicast address | > > | | | | |<--------------------| > > | | | | | | | > > | | | | | | | > > | | | COAP NON (Put | > > | | | | URI Path | > > | | | | Payload=turn on lights)| > > | | | | Destination IP Address = | > > | | | | IP multicast address | > > | | | | for Group (Room-A-Lights)| > > | | | | Originating IP Address = | > > | | | | RTR-1 | > > | | | | |-------------------->| > > |<------------------------------------------| | | > > | | | | | | | > > | | | | | |<---------| > > | |<---------|<-------------------------------| | > > | | | | | | | > > | | | | | | | > > Figure 5: Sending Lighting Control Multicast Message > > Rahman & Dijk Expires April 22, 2013 [Page > > 17] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (CoAP (CoAP > > Backbone > > | | | | Proxy) Proxy) | > > | | | | | | | > > *********************** | | | | > > * Lights in Room-A * | | | | > > * turn on (nearly * | | | | > > * simultaneously) * | | | | > > *********************** | | | | > > | | | | | | | > > | | | | | | | > > | COAP NON (2.04 Changed) | | | | > > |------------------------------------------>| | | > > | | | | | | | > > | | | | | | | > > | COAP NON (2.04 Changed) | | | > > | |------------------------------->| | | > > | | | | | | | > > | | | | | | | > > | | COAP NON (5.00 Internal Server Error) | > > | | |-------------------->| | | > > | | | | | | | > > | | | ****************************** | > > | | | * Rtr-1 as CoAP Proxy * | > > | | | * | sends the individual * | > > | | | * | responses back to * | > > | | | * v originator * | > > | | | ****************************** | > > | | | | | | | > > | | | COAP NON (2.04 Changed) | | > > | | | |<---------| | | > > | | | | | | | > > | | | COAP NON (2.04 Changed) | | > > | | | |<---------| | | > > | | | | | | | > > | | | COAP NON (5.00 Internal Server Error) | > > | | | |<---------| | | > > | | | | | | | > > Figure 6: Sending Lighting Control Response to Multicast Message > > NOTE: In the last step of Figure 6, Rtr-1 acting as CoAP proxy, > > returns multiple individual CoAP responses to the client. Each > > response echoes the Token of the client's request. The client can > > identify the original source of each response by ...TBD. > > /comment WHY are the multicast destinations sending back results? > > /comment I thought that you wanted MC messages to be non confirmable > > /comment sending responses seems to contradict this . > > /comment please remove sending back of responses. > > /comment one may assume that the MC algorithm within the lowpan is > > reliable (all destinations receive the message) > > /comment anyway MPL comes close enough to the reliability requirement > > given a specifiable range of configurations > > ______________________________________________________________________ > _____________________________________________________ > > > -- > > Peter van der Stok > > mailto: consultancy@vanderstok.org > > www: www.vanderstok.org [3] > > tel NL: +31(0)492474673 F: +33(0)966015248 > > ------------------------- > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. > > > Links: > ------ > [1] http://datatracker.ietf.org/drafts/current/ > [2] http://trustee.ietf.org/license-info > [3] http://www.vanderstok.org ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ 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 From stokcons@xs4all.nl Sun Nov 3 20:42:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583C421E80F3 for ; Sun, 3 Nov 2013 20:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.696 X-Spam-Level: X-Spam-Status: No, score=0.696 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-jRgborsFrb for ; Sun, 3 Nov 2013 20:42:53 -0800 (PST) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by ietfa.amsl.com (Postfix) with ESMTP id 44ABE21E80CB for ; Sun, 3 Nov 2013 20:42:47 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id rA44g2Nf083868; Mon, 4 Nov 2013 05:42:06 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from hotel-wireless-v6.meeting.ietf.org ([2001:67c:370:144:d93c:63e3:e6e8:c2cb]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 04 Nov 2013 05:42:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 04 Nov 2013 05:42:02 +0100 From: peter van der Stok To: weigengyu Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> Message-ID: <00bc875979c9100652c83cc262a26dac@xs4all.nl> X-Sender: stokcons@xs4all.nl (/JwzsaAvutf11CuQ23NjuK9d3Bki/9Ph) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 04 Nov 2013 04:42:57 -0000 Hi Weigenyu, With the choice of the density of MPL forwarders and the number of repetitions by MPL forwarders it is possible to estimate the reliability of the MPL multicast as function of the single transmission failure rate under a range of network loads. Does that partially answer your question for wireless meshes? Peter weigengyu schreef op 2013-11-04 05:28: > Hi Akbar, > > Thank you for your reply. > >> Reliable multicast is not supported. >> We can perhaps make this more clear by adding a sentence in the Scope >> (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). > > I belive it is required. > I have misunderstood that it provides unreliable multicast just for > the use case of Light Switch Control. > > And, I also want to ask the List, > has anyone considered or been interested in CoAP Reliable Groupcomm or > CoAP reliable multicast? > > Regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts & Telecommunications > > > -----原始邮件----- From: Rahman, Akbar > Sent: Sunday, November 03, 2013 10:56 PM > To: weigengyu > Cc: Core ; Dijk, Esko ; consultancy@vanderstok.org > Subject: RE: [core] group-comm comments > > Hi Gengyu, > > > Just some quick feedback. The groupcomm draft assumes only unreliable > (i.e. not guaranteed) IP multicast. This is specified in > > http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.4 > (see 1st paragraph) > > and > > http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-3.4 > (see 3rd paragraph) > > > Reliable multicast is not supported. We can perhaps make this more > clear by adding a sentence in the Scope > (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). > > > > Thanks for your review, > > > Akbar > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of weigengyu > Sent: Saturday, November 02, 2013 9:16 AM > To: Dijk, Esko; consultancy@vanderstok.org > Cc: Core > Subject: Re: [core] group-comm comments > > Hi, Esko > > I would like to give some comments on the GROUP-COMM draft. > > There have use cases for reliable and unreliable multicast > communications. > If this draft only for providing unreliable multicast over IP > multicast, it > is OK; just write it clearly. > > If the draft intends to have the reliable or partial multicast > facility, > the dtaft needs to give what mechanisms can gurantte that. > > The draft should define mechnisms that the server can register its > capability of supporting multicast, > this may be put to RD server; > and wether to request reliable groupcomm shoule be the client's > request. > >> To clarify: under the assumption that a server MAY respond to a >> multicast >> request, > A mechanism is required to make the server registers its capability. > i.e. > whether to support multicast; > >> and the client doesn't know a priori how many servers will respond to >> a >> multicast, > The client may lookup the information from the RD server (if the > rerver's > registeration processe were possible); > >> (since there are no guidelines/rules for that), the safest thing to do >> is >> not send the multicast in the first place. > If not first, when to make available? > So, whether it is required should be determined by the client request, > and > there should have some authority or priority control to client. > >> Therefore the advice is to carefully control sending of multicast >> requests. > Not only to tell that, the draft should have clear descriptions about > how > the protocol supports multicast requiests and/or reliable multicast > when > required. > > regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts & Telecommunications > > -----原始邮件----- From: Dijk, Esko > Sent: Thursday, December 20, 2012 6:56 PM > To: consultancy@vanderstok.org > Cc: Core > Subject: Re: [core] group-comm comments > > Thanks Peter, > > I would agree we need to include guidelines on returning of responses > to > CoAP multicast requests. (Note the CoAP spec ensures that a CoAP server > will > never ACK a multicast but that does not help a thing if it still sends > a > response packet...) I'll make a ticket for this. If anyone disagrees > we'll > hear it. > >> Then I do not understand the text, because "request", "reply" and >> "response" are overloaded in my mind. > To clarify: under the assumption that a server MAY respond to a > multicast > request, and the client doesn't know a priori how many servers will > respond > to a multicast, (since there are no guidelines/rules for that), the > safest > thing to do is not send the multicast in the first place. Therefore the > advice is to carefully control sending of multicast requests. > > Esko > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Thursday 20 December 2012 11:26 > To: Dijk, Esko > Cc: consultancy@vanderstok.org; akbar rahman; Core > Subject: RE: group-comm comments > > > Hi Esko, > > thanks for your reactions. I will group my answers, to better explain > my > points on the return of packets to MC senders. > > 1) Return of packets to multicast > > As I understand the multicast message is preferably sent with no > confirmation (ack) because the return of all the acks may overwhelm the > network and the sender of the multicast. > The acknowledgement is not needed for MPL as the protocol has all the > machinery to assure that all destinations receive it, (given > constraints on > network load and configuration density and size). > > Supposing an ack is needed, then it would be advisable to staffle the > responses and an additional acknowledgement protocol could be added to > the > multicast protocol. The same is true if a message is returned (as in > the > case of mDNS). > > One can then wonder whether the application protocol (e.g. mDNS) should > take > care of the staffled response or that an additional protocol needs to > be > specified. > I have no opinion on the choice, but see the need for the one or the > other. > Coming with a recommendation (explanation) on the subject of returning > responses (acks) would be my recommendation for the GroupComm document. > > Below some reactions on your reactions. Hope this helps to clarify > misunderstandings. > > Peter > > Dijk, Esko schreef op 2012-12-19 14:24: >> Hi Peter, >> >> still a fair number of comments! I would agree with most. Below I have >> selected some which we should discuss further, or ones I don’t agree >> with: >> >> 1. Group communication definition -> >> Why can't a source node be part of the group that it sends to? E.g. >> combined sensor+luminaire use case. The IP stack would deliver sent >> multicast CoAP requests also to the local application if it is >> subscribed to the multicast IP address. > source can of course be member of destination group. > source may be part of the group (remove the "or may be not" part of the > phrase) >> >> 2. I don’t see why we should add “the use of group communication for >> mDNS is out of scope.” -> mDNS obviously is not CoAP, and the >> document should define the scope anyway clearly as CoAP group >> communication. So we don’t have to list any other protocols than CoAP. > See my answer on return of packets. I wanted a clear statement on (NOT) > specifying how applications handle the return of MC responses. > >> >> 3. “so setting a multicast address in a source at installation is >> forbidden?” -> No, that should not be forbidden :) It should also be >> possible to set a CoAP path and/or port at installation time. That >> means the two presented measures have to change or be removed. > No comment >> >> 4. “there are 2 ways: (1) the node queries to which group it belongs >> or (2) an instalation tools instructs the node to which groups” -> >> Good point. (2) has been chosen because it works without relying on a >> service to query (e.g. DNS or RD). Is that sufficient argumentation? >> The mechanism is optional in any case so it does not block others from >> defining a DNS or RD variant. > I would point out both variants and mention that the draft focusses on > (2) >> >> 5. “/s requests /s replies” -> >> multicast replies (if you mean responses) do not exist in CoAP. It’s >> about requests that should be carefully controlled since they generate >> unicast responses. > Then I do not understand the text, because "request", "reply" and > "response" > are overloaded in my mind. >> >> 6. “/comment what about the reply?” -> based on core-coap “If the >> request message is Non-confirmable, then the response SHOULD be >> returned in a Non-confirmable message as well.” >> . Do you think we should quote this from the core-coap spec? > As explained above The subject of returning packets to the MC sender > needs > careful consideration. > the response being NOn-confirmable does not solve a lot I am afraid. >> >> 7. “/comment invoking as many certificates?” -> >> core-coap-13 now loosens the concept of authentication to also >> include other measures, not needing certificates. > No comment >> >> 8. Network configuration: 2 subnets vs 1 -> maybe a one-subnet >> configuration is worth adding? Here an overview of present/absent use >> cases: >> >> - Link-local CoAP multicast with responses: Present, Appendix A of >> core-coap >> - Site-local CoAP multicast, single subnet: >> - Site-local CoAP multicast, multi subnet, with or without responses >> (in the new -04 groupcomm): Present >> - Global CoAP multicast, single or multi subnet, with or without >> responses: / dependency on IANA IPv6 allocation >> - any configurations with a central controller on the backbone >> multicasting: > > Again, the draft should go for the most frequent use cases and not try > to be > complete. > Actually explicitly excluding use cases looks ineresting to me. >> >> 9. “It might be useful if the practical impossibility of some >> configurations is high lighted” -> any thoughts, which would be >> impossible? > During the coap meeting in Atlanta, Cullen Jennings presented some > horrifying examples, as far as I remember. > >> >> 10.“the RD discovery will be more complex when there is a router >> between light-2 and switch” -> yes, there are issues in RD/discovery >> especially when more than one is present in a network. > So, adapt the use case and exclude this possibility. >> >> 11.“additional reason to remove router from the multicast >> configuration”-> hmm, I think that we should opt for having a single >> RD in the system to avoid complexity. Routers are ok. (One of our >> goals is to define how CoAP groupcomm works even across routers) > Looking forward to the supporting protocol. >> >> 12.“MLD is used to form groups, correct? but that was already done by >> enabling the MC address in the lights (point 2)” -> Step 1 is putting >> the MC address in the lights, then step 2 is the Lights use MLD to >> *ADVERTIZE* this address to any MLD-enabled Routers present >> link-local. >> So MLD is not a commissioning-time protocol but runs all the time >> during operation. >> Note that in groupcomm -04 we will remove MLD in the basic use case >> and present it as an option later. > > Sounds good. The point is not to add protocols because they exist but > because they are needed. >> >> 13.“WHY are the multicast destinations sending back results?” -> we >> remove responses in the new -04 groupcomm. They are presented as an >> optional thing that servers can do. >> CoAP servers normally MUST respond to a request with a response >> (core-coap-13) but an exception is now made for multicast where a >> server MAY choose not to. This choice is completely independent from >> confirmable/non-confirmable. Non-confirmable only means that an ACK >> must not be sent. And an ACK is something different from a CoAP >> response. >> Agree that a protocol like MPL comes very close to ‘reliable >> multicast’. > > see my worries at the beginning. >> >> Esko >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Tuesday 18 December 2012 12:06 >> To: akbar rahman; Dijk, Esko; Core >> Subject: group-comm comments >> >> Hi Akbar and Esko, >> >> I had promised to review, comment the group comm draft. >> >> Below the commented text. >> >> I have not gone very detailed with my comments. I hope that it is >> clear from my comments that a reorganization of the draft and a review >> of the uses cases are necessary to get a clearer picture of the >> feasibility of group comm in the context of Coap. >> >> Especialy difficult to understand for me were: >> >> - the use case network configuration >> >> - the forming and enabling of groups >> >> - use of responses >> >> Hope this helps. >> >> Greetings, >> >> peter >> >> ______________________________________________________________________ >> _______________________________ >> >> >> Abstract >> >> CoAP is a RESTful transfer protocol for constrained devices. 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 document >> >> defines how the CoAP protocol should be used in a group communication >> >> context. An approach for using CoAP on top of IP multicast is >> >> detailed for both constrained and un-constrained networks. Also, >> >> various use >> >> /s causes /s cases/ >> >> and corresponding protocol flows are provided to >> >> illustrate important concepts. Finally, guidance is provided for >> >> deployment in various network topologies. >> >> Status of this Memo >> >> This Internet-Draft is submitted in full conformance with the >> >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> >> Task Force (IETF). Note that other groups may also distribute >> >> working documents as Internet-Drafts. The list of current Internet- >> >> Drafts is at http://datatracker.ietf.org/drafts/current/ [1]. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> >> and may be updated, replaced, or obsoleted by other documents at any >> >> time. It is inappropriate to use Internet-Drafts as reference >> >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on April 22, 2013. >> >> Copyright Notice >> >> Copyright (c) 2012 IETF Trust and the persons identified as the >> >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> >> Provisions Relating to IETF Documents >> >> (http://trustee.ietf.org/license-info [2]) in effect on the date of >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 1] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> publication of this document. Please review these documents >> >> carefully, as they describe your rights and restrictions with respect >> >> to this document. Code Components extracted from this document must >> >> include Simplified BSD License text as described in Section 4.e of >> >> the Trust Legal Provisions and are provided without warranty as >> >> described in the Simplified BSD License. >> >> 1. Conventions and Terminology >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> >> document are to be interpreted as described in [RFC2119]. >> >> This document assumes readers are familiar with the terms and >> >> concepts that are used in [I-D.ietf-core-coap]. In addition, this >> >> document defines the following terminology: >> >> Group Communication >> >> A source node sends a single message which is delivered to >> >> multiple destination nodes, where all destinations are identified >> >> to belong to a specific group. The source node may >> >> /remove or may not >> >> be >> >> part of the group. The underlying mechanism for group >> >> communication is assumed to be multicast based. >> >> /remove >> >> The network where >> >> the group communication takes place can be either a constrained >> >> or >> >> a regular (un-constrained) network/ >> >> /comment not sure about the meaning and consequences >> >> Multicast >> >> Sending a message to multiple destination nodes >> >> /s simultaneously./ >> >> /s with one network invocation / >> >> There are various options to implement multicast including layer >> >> 2 >> >> (Media Access Control) or layer 3 (IP) mechanisms. >> >> IP Multicast >> >> A specific multicast solution based on the use of IP multicast >> >> addresses as defined in "IANA Guidelines for IPv4 Multicast >> >> Address Assignments" [RFC5771] and "IP Version 6 Addressing >> >> Architecture" [RFC4291]. >> >> Low power and Lossy Network (LLN) >> >> Low power and Lossy Network (LLN): A type of constrained network >> >> where the devices are interconnected by a variety of low power, >> >> lossy links such as IEEE 802.15.4, Bluetooth, >> >> WiFi, wired >> >> or low >> >> power power-line communication links. >> >> 2. Introduction >> >> 2.1. Background >> >> The Constrained Application Protocol (CoAP) is an application >> >> protocol (analogous to HTTP) for resource constrained devices >> >> operating in an IP network [I-D.ietf-core-coap]. Constrained >> >> devices >> >> can be large in number, but are often highly correlated to each >> >> other >> >> (e.g. by type or location). For example, all the light switches in >> >> a >> >> building may belong to one group and all the thermostats may belong >> >> to another group. Groups may be composed by function. For example, >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 3] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> the group "all lights in building one" may consist of the groups >> >> "all >> >> lights on floor one of building one", "all lights on floor two of >> >> building one", etc. Groups may be preconfigured >> >> /add before deployment >> >> or dynamically >> >> formed >> >> /add during operation >> >> . If information needs to be sent to or received from a group >> >> of devices, group communication mechanisms can improve efficiency >> >> and >> >> latency of communication and reduce bandwidth requirements for a >> >> given application. HTTP does not support any equivalent >> >> functionality to CoAP group communication. >> >> 2.2. Scope >> >> In this draft, we address the issues related to CoAP group >> >> communication in detail, with use cases, recommended approaches and >> >> analysis of the impact to the CoAP protocol and to implementations. >> >> /add the use of group communication for mDNS is out of scope. >> >> The guiding principle is to apply wherever possible existing IETF >> >> protocols to achieve group communication functionality. In many >> >> cases the contribution of this document lies in explaining how >> >> existing mechanisms may be used to >> >> /remove together >> >> fulfill CoAP group >> >> communication needs for specific use cases. >> >> 2.3. Potential Solutions for Group Communication >> >> The classic concept of group >> >> /s communications /s communication >> >> is that of a single >> >> source distributing content to multiple destination recipients that >> >> are all part of a group. Before content can be distributed, there >> >> is >> >> a separate process to form the group. The source may be either a >> >> member or non-member of the group. >> >> Group communication solutions have evolved from "bottom" to "top", >> >> i.e., from layer 2 (Media Access Control broadcast/multicast) and >> >> layer 3 (IP multicast) to application layer group communication, >> >> also >> >> referred to as application layer multicast. A study published in >> >> 2005 [Lao05] identified new solutions in the "middle" (referred to >> >> as >> >> overlay multicast) that utilize an infrastructure based on proxies. >> >> Each of these classes of solutions may be compared [Lao05] using >> >> metrics such as link stress and level of host complexity >> >> [Banerjee01]. The results show for a realistic internet topology >> >> that IP Multicast is the most resource-efficient, with the downside >> >> being that it requires >> >> /s the most /s more organizational >> >> effort to deploy in the >> >> infrastructure. IP Multicast is the solution adopted by this draft >> >> for CoAP group communication. >> >> 3. CoAP Group Communication Based On IP Multicast >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 4] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> 3.1. IP Multicast Background >> >> IP Multicast routing protocols have been evolving for decades, >> >> resulting in proposed standards such as Protocol Independent >> >> Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various >> >> technical and marketing reasons, IP Multicast routing is not widely >> >> deployed on the general Internet. However, IP Multicast is very >> >> popular in specific deployments such as in enterprise networks (e.g. >> >> for video conferencing), smart home networks (e.g. UPnP/mDNS) and >> >> carrier IPTV deployments. The packet economy and minimal host >> >> complexity of IP multicast make it attractive for group >> >> communication >> >> in constrained environments. Therefore IP multicast is the >> >> recommended underlying mechanism for CoAP group communication, and >> >> the approach assumed in this document. >> >> To achieve IP multicast beyond a subnet, an IP multicast routing >> >> protocol needs to be active on routers. The RPL protocol [RFC6550] >> >> for example is able to route multicast traffic in constrained LLNs. >> >> While PIM-SM [RFC4601] is often used for multicast routing in un- >> >> constrained networks. >> >> IP multicast can also be run in a Link-Local (LL) scope. This means >> >> that there is no routing involved and an IP multicast message is >> >> only >> >> received >> >> /s on the network /s over the >> >> link on which it was sent. >> >> 3.2. CoAP Group Definition and Naming >> >> A group is defined as a set of CoAP endpoints, where each endpoint >> >> is >> >> configured to receive a multicast CoAP request that is sent to the >> >> group's associated IP multicast address. The group MAY have more >> >> than one associated IP multicast address. An endpoint MAY be a >> >> member of multiple groups. Group membership of an endpoint MAY >> >> dynamically change over time. The group MAY be identified by a >> >> Group >> >> Name ([I-D.vanderstok-core-dna]) which is defined as a prefix string >> >> of a Group FQDN. The Group FQDN can be uniquely mapped to a site- >> >> local or global multicast IP address via DNS resolution. >> >> A CoAP multicast request that addresses a group includes a Group URI >> >> as the request URI. A Group URI has the scheme 'coap' and includes >> >> in the authority part either a group IP address >> >> /add + optional port >> >> or a hostname >> >> /add + optional port >> >> that >> >> can be resolved to the group IP address (e.g., a Group Name or Group >> >> FQDN). Group URIs MUST follow the URI syntax [RFC3986]. >> >> A CoAP >> >> /s node /s end-point >> >> becomes a group member by listening for CoAP messages on >> >> the group's IP multicast address, assuming the default CoAP UDP >> >> port. >> >> Note that a non-default UDP port MAY be specified for the group; in >> >> which case implementers MUST ensure that all group members are >> >> configured to use this same port. >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 5] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Examples of hierarchical group naming (and scoping) for a building >> >> control application are shown below. >> >> URI authority Targeted group >> >> all.bldg6.example.com "all nodes in building 6" >> >> all.west.bldg6.example.com "all nodes in west wing, building >> >> 6" >> >> all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, >> >> building 6" >> >> all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, >> >> west wing, building 6" >> >> Reverse mapping (from IP multicast address to group FQDN) is >> >> supported using the reverse DNS resolution technique >> >> ([I-D.vanderstok-core-dna]). >> >> 3.3. Group Discovery and Member Discovery >> >> CoAP defines a resource discovery capability, but does not yet >> >> specify how to discover groups (e.g. find a group to join or send a >> >> multicast message to) or to discover members of a group (e.g. to >> >> address selected group members by unicast). These topics are >> >> elaborated in more detail in [I-D.vanderstok-core-dna] including >> >> examples for using DNS-SD and CoRE Resource Directory. >> >> 3.3.1. DNS-SD >> >> DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a >> >> conventional way to configure DNS PTR, SRV, and TXT records to >> >> enable >> >> enumeration of services, such as services offered by CoAP nodes, or >> >> enumeration of all CoAP nodes, within specified subdomains. A >> >> service is specified by a name of the form >> >> .., where the service type for CoAP >> >> nodes is _coap._udp and the domain is a DNS domain name that >> >> identifies a group as in the examples above. For each CoAP >> >> end-point >> >> in a group, a PTR record with the name _coap._udp and/or a PTR >> >> record >> >> with the name _coap._udp. is defined and it points to an SRV >> >> record having the .. name. >> >> All CoAP nodes in a given subdomain may be enumerated by sending a >> >> query for PTR records named _coap._udp to the authoritative DNS >> >> server for that zone. A list of SRV records is returned. Each SRV >> >> record contains the port and host name (AAAA record) of a CoAP node. >> >> The IP address of the node is obtained by resolving the host name. >> >> DNS-SD also specifies an optional TXT record, having the same name >> >> as >> >> the SRV record, which can contain "key=value" attributes. This can >> >> be used to store information about the device, e.g. schema=DALI, >> >> type=switch, group=lighting.bldg6, etc. >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 6] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Another feature of DNS-SD is the ability to specify service subtypes >> >> using PTR records. For example, one could represent all the CoAP >> >> groups in a subdomain by PTR records with the name >> >> _group._sub._coap._udp or alternatively >> >> _group._sub._coap._udp.. >> >> 3.3.2. CoRE Resource Directory >> >> CoRE Resource Directory [I-D.shelby-core-resource-directory] defines >> >> the concept of a Resource Directory (RD) server where CoAP servers >> >> can register their resources offered and CoAP clients can discover >> >> these resources by querying the RD server. RD syntax can be mapped >> >> to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], >> >> such that the above approach can be reused for group discovery and >> >> group member discovery. >> >> /remove Specifically, the Domain (d) parameter can be set to the >> >> group URI by >> >> an end-point registering to the RD. If an end-point wants to join >> >> multiple groups, it has to repeat the registration process for each >> >> group it wants to join. >> >> /end remove >> >> /comment d parameter semantics not clear >> >> 3.4. Group Resource Manipulation >> >> Group communications SHALL only be used for idempotent methods (i.e. >> >> CoAP GET, PUT, DELETE). The CoAP messages that are sent via >> >> multicast SHALL be Non-Confirmable. >> >> A unicast response per server MAY be sent back to answer the group >> >> request (e.g. response "2.05 Content" to a group GET request) taking >> >> into account the congestion control rules defined in >> >> [I-D.ietf-core-coap]. The unicast responses may be a mixture of >> >> success (e.g. 2.05 Content) and failure (e.g. 4.04 Not Found) codes >> >> depending on the individual server processing result. >> >> Group communications SHALL NOT be used for non-idempotent methods >> >> (i.e. CoAP POST). This is because not all group members are >> >> guaranteed to receive the multicast request, and the sender can not >> >> readily find out which group members did not receive it. >> >> All nodes in a given group SHOULD receive the same request >> >> /remove with high probability. >> >> /comment I don't see where probability comes in. >> >> This will not be the case if there is diversity in the >> >> authority port (i.e. a diversity of dynamic port addresses across >> >> the >> >> group) or if the targeted resource is located at different paths on >> >> different nodes. >> >> Therefore, some measures must be present to ensure uniformity in >> >> port >> >> number and resource names/locations within a group. This document >> >> proposes the following measures: >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 7] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> o All CoAP multicast requests MUST be sent either to the default >> >> CoAP UDP port (i.e. default Uri-Port as defined in >> >> [I-D.ietf-core-coap]), or to a port number obtained via a service >> >> discovery lookup operation as a valid CoAP port for the targeted >> >> multicast group. >> >> o All CoAP multicast requests SHOULD operate only on URIs (links) >> >> which were >> >> /s retreived /s retrieved >> >> either from a "/.well-known/core" lookup on >> >> at least one group member node, or from an equivalent service >> >> discovery lookup which returns either the resources supported by >> >> all group members or resources supported by one particular group >> >> member. >> >> /comment so setting a multicast address in a source at installation is >> >> forbidden? >> >> 3.5. Configuring Group Membership In Endpoints >> >> In some use cases, the group membership of endpoints needs to be >> >> configurable after the network has been deployed. Example use cases >> >> can be found in building control: a commissioning tool determines to >> >> which groups a light or sensor node belongs, and writes this >> >> information to all nodes, which can subsequently join the correct >> >> group. >> >> To achieve smoother interoperability between nodes/endpoints from >> >> different manufacturers, it is proposed here to define an OPTIONAL >> >> standardized RESTful means of configuring CoAP endpoints with >> >> relevant group information. >> >> CoAP endpoints implementing this mechanism MUST support a >> >> discoverable "Group Configuration" resource of resource type (rt) >> >> [RFC6690] "core.gp". This resource (and perhaps its sub-resources, >> >> TBD) are used to manage group membership. Three design options for >> >> this mechanism are presented here as a placeholder (TBD). >> >> Design 1: use CoRE link format payloads to communicate group >> >> membership to endpoints. (TBD Not clear how this should be >> >> realized.) >> >> /comment, not clear what you mean either. Remove design 1 in this >> state >> >> Design 2: use a JSON type resource. For example, a GET on the >> >> "core.gp" resource returns a JSON array of group objects. >> >> Req: GET /gp >> >> Res: 2.05 Content (Content-Format: application/json) >> >> [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", >> >> "ip": "ff05::4200:f7fe:ed37:14ca" } >> >> ] >> >> where "n" defines the Group FQDN and "ip" defines the associated >> >> multicast IP address. As a next example, the same endpoint can be >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 8] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> added to another group by a POST on the resource with a JSON group >> >> object: >> >> Req: POST /gp (Content-Format: application/json) >> >> { "n": "floor1.west.bldg6.example.com", >> >> "ip": "ff05::4200:f7fe:ed37:14cb" } >> >> Res: 2.04 Changed >> >> Design 3: define named sub-resources, each sub-resource representing >> >> a group membership. The payload of the sub-resource may be JSON or >> >> a >> >> simple pre-defined format. Or alternatively, information is >> >> provided >> >> via POST with query parameters. >> >> /comment are these mutually exclusive designs? >> >> /comment design 2 without JSON is als possible >> >> /comment design with SRV and TXt records is also possible >> >> /comment there are 2 ways: (1) the node queries to which group it >> >> belongs >> >> /comment (2) an instalation tools instructs the node to which groups >> >> it belongs >> >> /comment not clear in text that this choice exists or that a choice >> was >> >> made. >> >> 3.6. Congestion Control >> >> Multicast CoAP requests may result in a multitude of replies from >> >> different nodes, potentially causing congestion. Therefore sending >> >> multicast >> >> /s requests /s replies >> >> should be conservatively controlled. >> >> The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific >> >> congestion risks through the following measures: >> >> o A server MAY choose not to respond to a multicast request if >> >> there's nothing useful to respond (e.g. error or empty response). >> >> o A server SHOULD limit the support for multicast requests to >> >> specific resources where multicast operation is required. >> >> o A multicast request MUST be Non-Confirmable. >> >> /comment what about the reply? >> >> o A server does not respond immediately to a multicast request, but >> >> SHOULD first wait for a time that is randomly picked within a >> >> predetermined time interval called the Leisure. >> >> o A server SHOULD NOT accept multicast requests that can not be >> >> authenticated. >> >> /comment invoking as many certificates? >> >> Additional guidelines to reduce congestion risks are: >> >> o A server in an LLN should only support multicast GET for >> >> resources >> >> that are small, e.g. >> >> /remove for an LLN that could mean >> >> the payload of the >> >> response fits into a single link-layer frame. >> >> o A server can minimize the payload length in response to a >> >> multicast GET on "/.well-known/core" by using hierarchy in >> >> arranging link descriptions for the response. An example of this >> >> is given in Section 5 of [RFC6690]. >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 9] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> o Preferably IP multicast with link-local scope should be used, >> >> rather than global or site-local. >> >> o The Hop Limit field in the IPv6 packet should be chosen as low as >> >> possible (if the CoAP/IP stack allows setting of this value. TBD >> >> - discuss whether this guideline is relevant/realistic in CoAP >> >> context) >> >> 3.7. CoAP Multicast and HTTP Unicast Interworking >> >> /comment a reference will suffice >> >> CoAP supports operation over UDP multicast, while HTTP does not. >> >> For >> >> use cases where it is required that CoAP group communication is >> >> initiated from an HTTP end-point, it would be advantageous if the >> >> HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group >> >> communication based on IP multicast. >> >> /remove One possible way of operation >> >> /remove of such HTTP-CoAP Proxy is illustrated in Figure 1. >> >> Note that this >> >> topic is covered in more detail in >> >> [I-D.castellani-core-advanced-http-mapping]. >> >> /remove >> >> CoAP Mcast CoAP Mcast HTTP-CoAP HTTP >> >> Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 >> >> | | | | | | >> >> |MLD REQUEST | | | | >> >> |(Join Group X) | | | | >> >> |--LL-->| | | | | >> >> | | |MLD REQUEST | | >> >> | | |(Join Group X) | | >> >> | | |--LL-->| | | >> >> | | | | | HTTP REQUEST | >> >> | | | | | (URI to | >> >> | | | | | unicast addr) | >> >> | | | | |< -----------------| >> >> | | | | | | >> >> | | | Resolve HTTP Request-Line URI | >> >> | | | to Group X multicast address | >> >> | | | | | | >> >> | CoAP REQUEST (to multicast addr)| | >> >> |< ------<---------<-------<------| | >> >> | | | | | | >> >> | | | | >> >> | (optional) CoAP RESPONSE(s) | | >> >> | |-------------->| | >> >> |-----------------|-------------->| Aggregated | >> >> | | | HTTP RESPONSE | >> >> | | |------------------>| >> >> | | | | >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 10] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Figure 1: CoAP Multicast and HTTP Unicast Interworking >> >> Note that Figure 1 illustrates the case of IP multicast as the >> >> underlying group communications mechanism. MLD denotes the >> >> Multicast >> >> Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a >> >> Link-Local multicast. >> >> A key point in Figure 1 is that the incoming HTTP Request (from node >> >> 3) will carry a Host request-header field that resolves in the >> >> general Internet to the proxy node. At the proxy node, this >> >> hostname >> >> and/or the Request-Line URI will then possibly be mapped (as >> >> detailed >> >> in [I-D.castellani-core-http-mapping]) and again resolved (with the >> >> CoAP scheme) to an IP multicast address. This may be accomplished, >> >> for example, by using DNS or DNS-SD (Section 3.3). The proxy node >> >> will then IP multicast the CoAP Request (corresponding to the >> >> received HTTP Request) via multicast routers to the appropriate >> >> nodes >> >> (i.e. nodes 1 and 2). >> >> In terms of the HTTP Response, Figure 1 illustrates that it will be >> >> generated by the proxy node based on aggregated responses of the >> >> CoAP >> >> nodes and sent back to the client in the general Internet that sent >> >> the HTTP Request (i.e. node 1). In >> >> [I-D.castellani-core-advanced-http-mapping] the HTTP Response that >> >> the Proxy may use to aggregate multiple CoAP responses is described >> >> in more detail. So in terms of overall operation, the CoAP proxy >> >> can >> >> be considered to be a "non-transparent" proxy according to >> >> [RFC2616]. >> >> Specifically, [RFC2616] states that a "non-transparent proxy is a >> >> proxy that modifies the request or response in order to provide some >> >> added service to the user agent, such as group annotation services, >> >> media type transformation, protocol reduction or anonymity >> >> filtering." >> >> An alternative to the above is using a Forward Proxy. In this case, >> >> the CoAP request URI is carried in the HTTP Request-Line (as defined >> >> in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the >> >> IP address of the Proxy. >> >> /end remove >> >> 4. Use Cases and Corresponding Protocol Flows >> >> 4.1. Introduction >> >> The use of CoAP group communication is shown in the context of the >> >> following use cases and corresponding protocol flows: >> >> o Discovery of Resource Directory: discovering the local CoRE RD >> >> which contains links (URIs) to resources stored on other servers >> >> [RFC6690]. >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 11] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> o Lighting Control: synchronous operation of a group of 6LoWPAN >> >> [RFC4944] IPv6-connected lights >> >> o Parameter Update: updating parameters/settings simultaneously in >> >> a >> >> large group of devices in a building/campus control >> >> ([I-D.vanderstok-core-bc]) application --- TBD >> >> / comment I suggest to remove Firmware Update and Groups status report >> >> /comment the ones above are difficult enough, and I doubt that >> >> simultaneity >> >> /comment (motivation of multicast) is involved here >> >> o Firmware Update: efficiently updating firmware simultaneously in >> >> a >> >> large group of devices in a building/campus control >> >> ([I-D.vanderstok-core-bc]) application --- TBD suggests a >> >> multicast extension of core-block. >> >> o Group Status Report: requesting status information or event >> >> reports from a group of devices in a building/campus control >> >> application --- TBD, may require reliable group communication to >> >> be feasible. >> >> 4.2. Network Configuration >> >> We assume the following network configuration for all the use cases >> >> as shown in Figure 2: >> >> /comment the configurations frighten me >> >> /comment from completeness considerations I can imagine even more >> >> complex ones >> >> /comment It might be useful if the practical impossibility of some >> >> configurations is high lighted >> >> o A large room (Room-A) with three lights (Light-1, Light-2, >> >> Light-3) controlled by a Light Switch. The devices are organized >> >> into two 6LoWPAN subnets. >> >> /comment one subnet is enough for me >> >> /remove >> >> o Light-1 and the Light Switch are connected to a router (Rtr-1) >> >> which is also a CoAP Proxy, a CoAP Resource Directory (RD) and a >> >> 6LoWPAN Border Router (6LBR). >> >> o Light-2 and the Light-3 are connected to another router (Rtr-2) >> >> which is also a CoAP Proxy, a CoAP RD and a 6LBR. >> >> o The routers are connected to an IPv6 network backbone which is >> >> also multicast enabled. In the general case, this means the >> >> network backbone and 6LBRs support a PIM based multicast routing >> >> protocol, and MLD for forming groups. In a limited case, if the >> >> network backbone is one link, then the routers only have to >> >> support MLD-snooping (Appendix A) for the following use cases to >> >> work. >> >> /end remove >> >> /comment I can imagine that an central control is present on the >> >> backbone >> >> /comment switch or sensor send unicast to central control >> >> /comment central control sends multicast to multicast group within >> >> single lowpan >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 12] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Network >> >> Backbone >> >> | >> >> ################################################ >> >> | >> >> # Room-A # >> >> | >> >> # ********************** # >> >> | >> >> # ** LoWPAN-1 (subnet-1) ** # >> >> | >> >> # * * # >> >> | >> >> # * +----------+ * # >> >> | >> >> # * | Light |-------+ * # >> >> | >> >> # * | Switch | | * # >> >> | >> >> # * +----------+ +---------+ * # >> >> | >> >> # * | Rtr-1 >> >> |-----------------------------| >> >> # * +---------+ * # >> >> | >> >> # * +----------+ | * # >> >> | >> >> # * | Light-1 |--------+ * # >> >> | >> >> # * +----------+ * # >> >> | >> >> # * * # >> >> | >> >> # ** ** # >> >> | >> >> # ********************** # >> >> | >> >> # # >> >> | >> >> # # >> >> | >> >> # ********************** # >> >> | >> >> # ** LoWPAN-2 (subnet-2) ** # >> >> | >> >> # * * # >> >> | >> >> # * +----------+ * # >> >> | >> >> # * | Light-2 |-------+ * # >> >> | >> >> # * | | | * # >> >> | >> >> # * +----------+ +---------+ * # >> >> | >> >> # * | Rtr-2 >> >> |-----------------------------| >> >> # * +---------+ * # >> >> | >> >> # * +----------+ | * # >> >> | >> >> # * | Light-3 |--------+ * # >> >> | >> >> # * +----------+ * # >> >> | >> >> # * * # >> >> | >> >> # ** ** # >> >> | >> >> # ********************** # >> >> | >> >> # # >> >> | >> >> ################################################# >> >> | >> >> | >> >> +--------+ >> >> | >> >> | DNS >> >> |------------------| >> >> | Server | >> >> +--------+ >> >> Figure 2: Network Topology of a Large Room (Room-A) >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 13] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> 4.3. Discovery of Resource Directory >> >> The protocol flow for discovery of a RD for the given network (of >> >> Figure 2) is shown in Figure 3: >> >> o The fixture for Light-2 is installed and powered on for the first >> >> time. >> >> o Light-2 will then search for the local RD (RD-2) by sending out a >> >> GET request (with the "/.well-known/core?rt=core.rd" request URI) >> >> to the site-local "All CoAP Nodes" address. In this case, the >> >> site is assumed to include all nodes in the subnet. >> >> o This multicast message will then go to each node in subnet-2. >> >> However, only Rtr-2 (RD-2) will respond because the GET is >> >> qualified by the query string "?rt=core.rd". >> >> o Note that the flow is shown only for Light-2 for clarity. >> >> Similar >> >> flows will happen for Light-1, Light-3 and the Light Switch when >> >> they are first powered on. >> >> The RD may also be discovered by other means such as by assuming a >> >> default location (e.g. on a 6LBR), using DHCP, anycast address, etc. >> >> However, these approaches do not invoke CoAP group communication so >> >> are not further discussed here. >> >> For other discovery use cases such as discovering local CoAP >> >> servers, >> >> services or resources group communication can be used in a similar >> >> fashion as in the above use case. Both Link-Local (LL) and site- >> >> local discovery are possible this way. >> >> /comment the RD discovery will be more complex when there is a router >> >> between light-2 and switch >> >> /comment Via which RD will light switch discover light-2? >> >> /comment additional reason to remove router from the multicast >> >> configuration >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 14] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Light Rtr-1 Rtr-2 >> >> Network >> >> Light-1 Light-2 Light-3 Switch (RD-1) (RD-2) >> >> Backbone >> >> | | | | | | | >> >> | | | | | | | >> >> ********************************** | | | >> >> * Light-2 is installed * | | | >> >> * and powers on for first time * | | | >> >> ********************************** | | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | COAP NON (GET | | >> >> | | /.well-known/core?rt=core.rd) | | >> >> | |--------->-------------------------------->| | >> >> | | | | | | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | COAP NON (2.05 Content | | >> >> | | ;rt="core.rd";ins="Primary") | | >> >> | |<------------------------------------------| | >> >> | | | | | | | >> >> Figure 3: Resource Directory Discovery via Multicast Message >> >> 4.4. Lighting Control >> >> /comment I am confused about the use of protocols >> >> /comment MLD is used to form groups, correct? >> >> /comment but that was already done by enabling the MC address in the >> >> lights (point 2) >> >> /comment There are several ways to set up groups, pointing them out >> and >> >> when to use them would be an asset. >> >> The protocol flow for a building automation lighting control >> >> scenario >> >> for the network (Figure 2) is shown in sequence in Figure 4, >> >> Figure 5, and Figure 6. We assume the following steps occur before >> >> the illustrated flow: >> >> o 1) Startup phase: 6LoWPANs are formed. IPv6 addresses assigned >> >> to >> >> all devices. The CoAP network is formed. >> >> o 2) Commissioning phase (by applications): The IP multicast >> >> address >> >> of the group (Room-A-Lights) has been >> >> /s set /s enable >> >> in all the Lights. The >> >> URI of the group (Room-A-Lights) has been >> >> /s set /s resolved >> >> in the Light Switch. >> >> o 3) The indicated MLD Report messages are link-local multicast. >> >> In >> >> each LoWPAN, it is assumed that a multicast routing/forwarding >> >> protocol in 6LRs will then propagate the Join information >> >> contained in the MLD Report over multiple hops to the 6LBR. >> >> /comment Don't see the need >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 15] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Light Rtr-1 Rtr-2 >> >> Network >> >> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >> >> Backbone >> >> | | | | Proxy) Proxy) | >> >> | | | | | | | >> >> | | | | | | | >> >> | MLD Report: Join | | | | | >> >> | Group (Room-A-Lights) | | | | >> >> |---LL------------------------------------->| | | >> >> | | | | |MLD Report: Join | >> >> | | | | |Group (Room-A-Lights)| >> >> | | | | |---LL--------------->| >> >> | | | | | | | >> >> | | MLD Report: Join | | | | >> >> | | Group (Room-A-Lights) | | | >> >> | |---LL------------------------------------->| | >> >> | | | | | | | >> >> | | | MLD Report: Join | | | >> >> | | | Group (Room-A-Lights) | | >> >> | | |---LL-------------------------->| | >> >> | | | | | | | >> >> | | | | |MLD Report: Join | >> >> | | | | |Group (Room-A-Lights)| >> >> | | | | | |---LL---->| >> >> | | | | | | | >> >> | | | | | | | >> >> Figure 4: Joining Lighting Groups Using MLD >> >> /comment possibly remove from text, or do separate section on use of >> >> MLD >> >> /comment anyway separating commissioning from operation in separate >> >> sections is a good idea. >> >> /comment the proxies are a complication in the picture not elaborated >> >> in the text. >> >> /comment the subject of proxies is another one, to be treated >> >> elsewhere. >> >> /comment also for proxies the do's and don't's from a simple >> >> performance perspective will be interesting >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 16] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Light Rtr-1 Rtr-2 >> >> Network >> >> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >> >> Backbone >> >> | | | | Proxy) Proxy) | >> >> | | | | | | | >> >> | | *********************** | | >> >> | | * User flips on * | | >> >> | | * light switch to * | | >> >> | | * turn on all the * | | >> >> | | * lights in Room A * | | >> >> | | *********************** | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | | COAP NON (PUT | | | >> >> | | | Proxy-URI | | | >> >> | | | URI for Room-A-Lights | >> >> | | | Payload=turn on lights) | >> >> | | | |--------->| | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | | | Request DNS resolution of | >> >> | | | | URI for Room-A-Lights | >> >> | | | | |-------------------->| >> >> | | | | | | | >> >> | | | | | | | >> >> | | | | DNS returns: AAAA | >> >> | | | | Group (Room-A-Lights) | >> >> | | | | IPv6 multicast address | >> >> | | | | |<--------------------| >> >> | | | | | | | >> >> | | | | | | | >> >> | | | COAP NON (Put | >> >> | | | | URI Path | >> >> | | | | Payload=turn on lights)| >> >> | | | | Destination IP Address = | >> >> | | | | IP multicast address | >> >> | | | | for Group (Room-A-Lights)| >> >> | | | | Originating IP Address = | >> >> | | | | RTR-1 | >> >> | | | | |-------------------->| >> >> |<------------------------------------------| | | >> >> | | | | | | | >> >> | | | | | |<---------| >> >> | |<---------|<-------------------------------| | >> >> | | | | | | | >> >> | | | | | | | >> >> Figure 5: Sending Lighting Control Multicast Message >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 17] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Light Rtr-1 Rtr-2 >> >> Network >> >> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >> >> Backbone >> >> | | | | Proxy) Proxy) | >> >> | | | | | | | >> >> *********************** | | | | >> >> * Lights in Room-A * | | | | >> >> * turn on (nearly * | | | | >> >> * simultaneously) * | | | | >> >> *********************** | | | | >> >> | | | | | | | >> >> | | | | | | | >> >> | COAP NON (2.04 Changed) | | | | >> >> |------------------------------------------>| | | >> >> | | | | | | | >> >> | | | | | | | >> >> | COAP NON (2.04 Changed) | | | >> >> | |------------------------------->| | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | COAP NON (5.00 Internal Server Error) | >> >> | | |-------------------->| | | >> >> | | | | | | | >> >> | | | ****************************** | >> >> | | | * Rtr-1 as CoAP Proxy * | >> >> | | | * | sends the individual * | >> >> | | | * | responses back to * | >> >> | | | * v originator * | >> >> | | | ****************************** | >> >> | | | | | | | >> >> | | | COAP NON (2.04 Changed) | | >> >> | | | |<---------| | | >> >> | | | | | | | >> >> | | | COAP NON (2.04 Changed) | | >> >> | | | |<---------| | | >> >> | | | | | | | >> >> | | | COAP NON (5.00 Internal Server Error) | >> >> | | | |<---------| | | >> >> | | | | | | | >> >> Figure 6: Sending Lighting Control Response to Multicast Message >> >> NOTE: In the last step of Figure 6, Rtr-1 acting as CoAP proxy, >> >> returns multiple individual CoAP responses to the client. Each >> >> response echoes the Token of the client's request. The client can >> >> identify the original source of each response by ...TBD. >> >> /comment WHY are the multicast destinations sending back results? >> >> /comment I thought that you wanted MC messages to be non confirmable >> >> /comment sending responses seems to contradict this . >> >> /comment please remove sending back of responses. >> >> /comment one may assume that the MC algorithm within the lowpan is >> >> reliable (all destinations receive the message) >> >> /comment anyway MPL comes close enough to the reliability requirement >> >> given a specifiable range of configurations >> >> ______________________________________________________________________ >> _____________________________________________________ >> >> >> -- >> >> Peter van der Stok >> >> mailto: consultancy@vanderstok.org >> >> www: www.vanderstok.org [3] >> >> tel NL: +31(0)492474673 F: +33(0)966015248 >> >> ------------------------- >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original >> message. >> >> >> Links: >> ------ >> [1] http://datatracker.ietf.org/drafts/current/ >> [2] http://trustee.ietf.org/license-info >> [3] http://www.vanderstok.org > > ________________________________ > The information contained in this message may be confidential and > legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby > notified > that any use, forwarding, dissemination, or reproduction of this > message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all > copies > of the original message. > _______________________________________________ > 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 From ludwig@sics.se Sun Nov 3 20:50:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3F411E8294 for ; Sun, 3 Nov 2013 20:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gucxHB8YOH-y for ; Sun, 3 Nov 2013 20:50:42 -0800 (PST) Received: from fsmsg2.sics.se (fsmsg2.sics.se [193.10.64.244]) by ietfa.amsl.com (Postfix) with ESMTP id F052411E818A for ; Sun, 3 Nov 2013 20:50:40 -0800 (PST) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id rA44oduX023166 for ; Mon, 4 Nov 2013 05:50:39 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1fqkxykpg3-1 for ; Mon, 04 Nov 2013 05:50:39 +0100 Received: from [10.10.3.225] (S0106001517fa65fb.vc.shawcable.net [174.6.163.198]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 29A3A40116 for ; Mon, 4 Nov 2013 05:50:38 +0100 (CET) Message-ID: <5277279C.3020601@sics.se> Date: Sun, 03 Nov 2013 20:50:36 -0800 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "core@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090003000205040509060205" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-03_03:2013-11-03, 2013-11-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311030319 Subject: [core] CoRE-AA security use cases meeting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 04:50:47 -0000 This is a cryptographically signed message in MIME format. --------------ms090003000205040509060205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello all, as discussed at the informal CoRE-AA meeting today, we are trying to=20 arrange a meeting for all those interested in contributing to the CoRE=20 security use cases draft. If you are interested please fill in the Doodle below: http://doodle.com/3kpgrkni4gh75yb7 I will try to find a place for us to sit and discuss. Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms090003000205040509060205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwW1izANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDExNTAyMDUwNloXDTE0MDExNTE0Mzc0OFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqm5Fq+vazAJCxhLsrE6yZ4Fcjf22HECMhhoH QAVWMuk61UnFAxiiKnsGb2iRrw9fFD2ZZP+VVKiojuMaNzlnyrULh84UwJhmkm6Ab2olLQ4x XZqNDvFe7djMtMMgqD8Erf35WuK8mrRjqHPX/imDEw4Ub6XvL5+rnhBKQozCm5FoIHOcol5H EbAO+F4XZA3pgQFyUWpWGlyIMZ3na9fkCBspupWZ68ytytxgB0poqbqJMSZtge6bkP/gZo6e dnbAydjkSkqHHGbpKzMJVI12TyJlJTN70Zg/OF4EMgcwN0tmJvrNqhH3oXlkKkTWk94ojP8M J3eQv6del7mB1tJcuwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAO/qDJzu5Icr9AFUhmI3z qGMpbjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBADhtqCPIvc8t6La1swQso5U7FF3Is5txWrQWPzcttJMyPo1LzdNT/jHEKF93 nOqiKm50NISmDFkBSxKOTTYPFJ4thgFcTZf+K57ucvxL/c+MLj3PlmCMNmtciCa8gxpldYz4 aob7CT02KQZvX+yGUmOTdHkoLd9FaxRq0ei43EAxjGIsU7vliaAoKCSO0pRsdtSrOYNV3fSd ZB6xd8KBjAJsC8P/Q2BfeMT5+fJPvX5pfj8h+qyGkJCPx2RHhkf5tSIrnOAoYkvrUZFk1JJx H+v1KrX2QRCu3fx7L9D3S1QNSCD3d3nDcM2sXdtGg6/KynBtw31O4YqQWgU9XQp+NoYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwW1izAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzExMDQwNDUwMzZaMCMGCSqGSIb3DQEJBDEW BBSC/q5AEGqQVDe+aZFWmwfep1+DTjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFtYswDQYJKoZIhvcNAQEBBQAE ggEAHfAKZfeR7m0tzS/HBCL+Rebb29bP3TtEP54CjoPGMmTmALNhsIDv+V94glPG5Y+mR+oT V0qgrHRHCds+O5xNTk5fVvKGNOd6t/TJj3n4sNJIgv0SeSlqH3F7Mt7V60aK2v3NuE8Mh7ZM 1C9nnrzpi4AKMtOZeFIN+3uGNMVo9qCppI46limRHNn70aZG5GjYNkwdmLJX+YmG3eFhHp/h 9b6QrkyJ+vdclT42rcfXJgtnrdbjNI6+pC1/5KfjdBPvcMO4xFayVQhSrJ6H0wMd/VF8Qj4X SbWmrEwJgQcov0opWSR5aBmjfbjsHUiGHehjNAb0UKtM/YWCWjHb/nbD8gAAAAAAAA== --------------ms090003000205040509060205-- From ludwig@sics.se Sun Nov 3 20:55:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE58011E8181 for ; Sun, 3 Nov 2013 20:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I61jVYlEt6pw for ; Sun, 3 Nov 2013 20:55:33 -0800 (PST) Received: from fsmsg2.sics.se (fsmsg2.sics.se [193.10.64.244]) by ietfa.amsl.com (Postfix) with ESMTP id AA31F11E8182 for ; Sun, 3 Nov 2013 20:55:32 -0800 (PST) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id rA44tARg026353 for ; Mon, 4 Nov 2013 05:55:31 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1fqkxykphu-1 for ; Mon, 04 Nov 2013 05:55:31 +0100 Received: from [10.10.3.225] (S0106001517fa65fb.vc.shawcable.net [174.6.163.198]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id F184140116 for ; Mon, 4 Nov 2013 05:55:30 +0100 (CET) Message-ID: <527728C0.8020108@sics.se> Date: Sun, 03 Nov 2013 20:55:28 -0800 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "core@ietf.org" References: <5277279C.3020601@sics.se> In-Reply-To: <5277279C.3020601@sics.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050902070609030203040403" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-03_03:2013-11-03, 2013-11-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311030320 Subject: Re: [core] CoRE-AA security use cases meeting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 04:55:37 -0000 This is a cryptographically signed message in MIME format. --------------ms050902070609030203040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 11/03/2013 08:50 PM, Ludwig Seitz wrote: > Hello all, > > as discussed at the informal CoRE-AA meeting today, we are trying to > arrange a meeting for all those interested in contributing to the CoRE > security use cases draft. > > If you are interested please fill in the Doodle below: > > http://doodle.com/3kpgrkni4gh75yb7 > > I will try to find a place for us to sit and discuss. > > Regards, > > Ludwig > I forgot to mention: Be sure to include some contact information, so I=20 can reach you without spamming the list. Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms050902070609030203040403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwW1izANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDExNTAyMDUwNloXDTE0MDExNTE0Mzc0OFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqm5Fq+vazAJCxhLsrE6yZ4Fcjf22HECMhhoH QAVWMuk61UnFAxiiKnsGb2iRrw9fFD2ZZP+VVKiojuMaNzlnyrULh84UwJhmkm6Ab2olLQ4x XZqNDvFe7djMtMMgqD8Erf35WuK8mrRjqHPX/imDEw4Ub6XvL5+rnhBKQozCm5FoIHOcol5H EbAO+F4XZA3pgQFyUWpWGlyIMZ3na9fkCBspupWZ68ytytxgB0poqbqJMSZtge6bkP/gZo6e dnbAydjkSkqHHGbpKzMJVI12TyJlJTN70Zg/OF4EMgcwN0tmJvrNqhH3oXlkKkTWk94ojP8M J3eQv6del7mB1tJcuwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAO/qDJzu5Icr9AFUhmI3z qGMpbjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBADhtqCPIvc8t6La1swQso5U7FF3Is5txWrQWPzcttJMyPo1LzdNT/jHEKF93 nOqiKm50NISmDFkBSxKOTTYPFJ4thgFcTZf+K57ucvxL/c+MLj3PlmCMNmtciCa8gxpldYz4 aob7CT02KQZvX+yGUmOTdHkoLd9FaxRq0ei43EAxjGIsU7vliaAoKCSO0pRsdtSrOYNV3fSd ZB6xd8KBjAJsC8P/Q2BfeMT5+fJPvX5pfj8h+qyGkJCPx2RHhkf5tSIrnOAoYkvrUZFk1JJx H+v1KrX2QRCu3fx7L9D3S1QNSCD3d3nDcM2sXdtGg6/KynBtw31O4YqQWgU9XQp+NoYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwW1izAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzExMDQwNDU1MjhaMCMGCSqGSIb3DQEJBDEW BBRJBh30JBwjAdz05Au65KfSVaRPuDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFtYswDQYJKoZIhvcNAQEBBQAE ggEAPsnrspiI4TtA09uGotXMvTGYmQRjafmXty1nS7tk3JTDtj0idkJT4nI/kt+Tln/aNFLv YK0s9HQ06O0DNVO44ddjVPbTEYm+d9t7OfS1xqX1XJmQNVY9dIvl8EjR/dH6BcgUAK3zeMhW 1l3mv04MoJaGASmKlZsGh8P0I5hKb6zZGTDFio79Rwmz3Ev+aWMN4pCRtcaC0VnejO0PmW0V viVteRILlV4J/z/31Uy8plryG4N0YrAA9kExyMlYgKBkHcdMVSuC4ImoLg9X+uwu0L76XEQd I3sHBzURBAQq3hN1DojLXRtBpm0YvzRriao6Ja2De018oNzvhjTe21O32gAAAAAAAA== --------------ms050902070609030203040403-- From alexis.olivereau@cea.fr Mon Nov 4 03:12:44 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F24421E8152 for ; Mon, 4 Nov 2013 03:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ8UrXj5Xz8Y for ; Mon, 4 Nov 2013 03:12:34 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC021E812F for ; Mon, 4 Nov 2013 03:12:34 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rA4BCXnw005442 for ; Mon, 4 Nov 2013 12:12:33 +0100 Received: from nephilia.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EF5141C298F for ; Mon, 4 Nov 2013 12:12:32 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (Postfix) with ESMTP id E43131C2893 for ; Mon, 4 Nov 2013 12:12:32 +0100 (CET) Received: from EXCAH-A1.intra.cea.fr (excah-a1.intra.cea.fr [132.166.88.75]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rA4BCWBo005436 for ; Mon, 4 Nov 2013 12:12:32 +0100 Received: from EXDAG0-A1.intra.cea.fr ([fe80::ac4c:b0e6:f68e:69cf]) by EXCAH-A1.intra.cea.fr ([fe80::5455:9547:c7e7:4610%11]) with mapi id 14.02.0318.004; Mon, 4 Nov 2013 12:12:32 +0100 From: OLIVEREAU Alexis To: "core@ietf.org" Thread-Topic: Announcing a new mode for MIKEY-TICKET for constrained devices - draft-olivereau-sake-mikey-ticket-00 Thread-Index: Ac7ZTi4m4zirUSDGQBq27X/WEyS3ew== Date: Mon, 4 Nov 2013 11:12:32 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.106] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20234.007 x-tm-as-result: No--40.475200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E61AD81200106A4C8D197B043FE38E192241A7DBEXDAG0A1intrace_" MIME-Version: 1.0 Subject: [core] Announcing a new mode for MIKEY-TICKET for constrained devices - draft-olivereau-sake-mikey-ticket-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 11:12:44 -0000 --_000_E61AD81200106A4C8D197B043FE38E192241A7DBEXDAG0A1intrace_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear members of the CORE WG, We have just submitted draft-olivereau-sake-mikey-ticket-00 about a new MIK= EY-TICKET -based key establishment protocol for constrained devices. draft-olivereau-sake-mikey-ticket-00 "Server-Assisted Key Exchange (SAKE): A new mode for MIKEY-TICKET" Alexis Olivereau Aymen Boudguiga Nouha Oualha http://tools.ietf.org/html/draft-olivereau-sake-mikey-ticket-00 Please comment. Yours, Alexis, with co-authors. --_000_E61AD81200106A4C8D197B043FE38E192241A7DBEXDAG0A1intrace_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Dear members of the CORE WG,

 


We have just submitted draft-olivereau-sake-mikey=
-ticket-00 about a new MIKEY-TICKET –based key establishment protocol=
 for constrained devices.


 


draft-olivereau-sake-mikey-ticket-00


"Server-Assisted Key Exchange (SAKE): A new =
mode for MIKEY-TICKET"


 


Alexis Olivereau <alexis.olivereau@cea.fr><=
o:p>


Aymen Boudguiga <aymenboudguiga@gmail.com><=
o:p>


Nouha Oualha <nouha.oualha@cea.fr>


 


http://tools.ietf.org/html/draft-olivereau-sake-mikey-ticket-00


 


Please comment.


 


Yours,


Alexis, with co-authors.


 
--_000_E61AD81200106A4C8D197B043FE38E192241A7DBEXDAG0A1intrace_-- From esko.dijk@philips.com Mon Nov 4 05:57:47 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8297711E81DC for ; Mon, 4 Nov 2013 05:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.033 X-Spam-Level: X-Spam-Status: No, score=-4.033 tagged_above=-999 required=5 tests=[AWL=2.566, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7glGcVhKFdgV for ; Mon, 4 Nov 2013 05:57:40 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1607711E81C5 for ; Mon, 4 Nov 2013 05:57:39 -0800 (PST) Received: from mail91-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.22; Mon, 4 Nov 2013 13:57:38 +0000 Received: from mail91-co9 (localhost [127.0.0.1]) by mail91-co9-R.bigfish.com (Postfix) with ESMTP id 6F3E13C02F4; Mon, 4 Nov 2013 13:57:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(z579ehz217bI98dI15d6O9371I542I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h1155h) Received: from mail91-co9 (localhost.localdomain [127.0.0.1]) by mail91-co9 (MessageSwitch) id 1383573456346431_17303; Mon, 4 Nov 2013 13:57:36 +0000 (UTC) Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.226]) by mail91-co9.bigfish.com (Postfix) with ESMTP id 50E0FB80059; Mon, 4 Nov 2013 13:57:36 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 4 Nov 2013 13:57:36 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.206]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.03.0146.002; Mon, 4 Nov 2013 13:57:33 +0000 From: "Dijk, Esko" To: Thomas Fossati , Klaus Hartke Thread-Topic: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ? Thread-Index: Ac7Obh27ZDRwc2TBQg6X4cmYut8XOwAD0v4AAAMX2QACtvEoAA== Date: Mon, 4 Nov 2013 13:57:33 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC227CF@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180171AFE5@011-DB3MPN2-083.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core \(core@ietf.org\)" Subject: Re: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 13:57:47 -0000 > Then what Esko proposes would be just a Server self-request with a differ= ent observer than the registering node. But that would not be supported by -observe, because it does not have the f= eature of sending notifications to a different node? Esko -----Original Message----- From: Thomas Fossati [mailto:tho@koanlogic.com] Sent: Monday, October 21, 2013 20:17 To: Klaus Hartke Cc: Dijk, Esko; core (core@ietf.org) Subject: Re: [core] WGLC draft-ietf-core-observe-11: support for pre-config= ured observers ? On Mon, Oct 21, 2013 at 5:48 PM, Klaus Hartke wrote: > - IIRC, Zach had some use-case where he wanted to send notifications > to a different node than the one registering. Then what Esko proposes would be just a Server self-request with a differen= t observer than the registering node. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From gerdes@tzi.de Mon Nov 4 10:54:35 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BF121E805F for ; Mon, 4 Nov 2013 10:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJT6lsWnU8M6 for ; Mon, 4 Nov 2013 10:54:29 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0F73421E81BA for ; Mon, 4 Nov 2013 10:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA4IsPAw018504; Mon, 4 Nov 2013 19:54:25 +0100 (CET) Received: from [31.133.165.134] (dhcp-a586.meeting.ietf.org [31.133.165.134]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DA2C1D22; Mon, 4 Nov 2013 19:54:24 +0100 (CET) Message-ID: <5277ED5D.3020705@tzi.de> Date: Mon, 04 Nov 2013 10:54:21 -0800 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "core@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [core] CoRE-AA subgroups X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:54:35 -0000 Hi everybody, As Ludwig's e-mail indicated, we decided yesterday during the informal CoRE-AA meeting to have a couple of subgroups working on specific topics in CoRE-AA, namely Use cases and requirements (coordinator: Ludwig Seitz) Ticket Format (Ludwig Seitz) Ticket Transport (Stefanie Gerdes) Revoking tickets/credentials/access rights (Bert Greevenbosch) Authorization payload (Olaf Bergmann) Note that this is work in flux. If you are interested in any of these topics, please feel free to contact the respective coordinator. We are planning to have meetings for some of these subgroups during the week. They will be announced in separate e-mails. Best regards, Steffi From gerdes@tzi.de Mon Nov 4 10:54:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C01621E81A3 for ; Mon, 4 Nov 2013 10:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phwm6U2J3AJH for ; Mon, 4 Nov 2013 10:54:52 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1215821E815D for ; Mon, 4 Nov 2013 10:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA4Isg12019165; Mon, 4 Nov 2013 19:54:42 +0100 (CET) Received: from [31.133.165.134] (dhcp-a586.meeting.ietf.org [31.133.165.134]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BBB62D23; Mon, 4 Nov 2013 19:54:41 +0100 (CET) Message-ID: <5277ED6F.4010208@tzi.de> Date: Mon, 04 Nov 2013 10:54:39 -0800 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "core@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [core] CoRE-AA transport meeting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:54:58 -0000 Hi everybody, I am organizing a meeting for the ticket transport group which is a (temporary) subgroup of the CoRE-AA group. The purpose of this meeting is to get people together who are interested in working on how to transfer authentication and authorization information. To shorten things up a bit, I propose to meet on Tuesday 2:00 PM - 3:30 PM in the registration area. Please contact me if you are interested in the topic of this subgroup and tell me if this fits into your schedule. Best regards, Steffi From ludwig@sics.se Mon Nov 4 12:53:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B21A21E80A5 for ; Mon, 4 Nov 2013 12:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ba56UFkTgaOB for ; Mon, 4 Nov 2013 12:53:05 -0800 (PST) Received: from fsmsg2.sics.se (fsmsg2.sics.se [193.10.64.244]) by ietfa.amsl.com (Postfix) with ESMTP id 10F8721E8098 for ; Mon, 4 Nov 2013 12:53:00 -0800 (PST) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id rA4Kq7CM014791 for ; Mon, 4 Nov 2013 21:53:00 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1fqkxym6wk-1 for ; Mon, 04 Nov 2013 21:53:00 +0100 Received: from [31.133.163.136] (dhcp-a388.meeting.ietf.org [31.133.163.136]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id A950040116 for ; Mon, 4 Nov 2013 21:52:59 +0100 (CET) Message-ID: <52780929.4080200@sics.se> Date: Mon, 04 Nov 2013 12:52:57 -0800 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "core@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010808010800000202000405" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-04_04:2013-11-04, 2013-11-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311040155 Subject: [core] IETF88 core AA social X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:53:10 -0000 This is a cryptographically signed message in MIME format. --------------ms010808010800000202000405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello all, it was suggested at the informal core AA meeting on sunday to organize a = little social event for the participants and other interested persons. If I may be so bold to make a suggestion: Tuesday evening 20:30 dinner at the Steamworks pub [1]. However I suspect we'd need to make a reservation. So I would ask you to = drop me a short line if you are interested. If I get enough positive=20 response, I'll try to reserve and notify you by tonight at latest. /Ludwig [1] http://steamworks.com --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms010808010800000202000405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwW1izANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDExNTAyMDUwNloXDTE0MDExNTE0Mzc0OFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqm5Fq+vazAJCxhLsrE6yZ4Fcjf22HECMhhoH QAVWMuk61UnFAxiiKnsGb2iRrw9fFD2ZZP+VVKiojuMaNzlnyrULh84UwJhmkm6Ab2olLQ4x XZqNDvFe7djMtMMgqD8Erf35WuK8mrRjqHPX/imDEw4Ub6XvL5+rnhBKQozCm5FoIHOcol5H EbAO+F4XZA3pgQFyUWpWGlyIMZ3na9fkCBspupWZ68ytytxgB0poqbqJMSZtge6bkP/gZo6e dnbAydjkSkqHHGbpKzMJVI12TyJlJTN70Zg/OF4EMgcwN0tmJvrNqhH3oXlkKkTWk94ojP8M J3eQv6del7mB1tJcuwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAO/qDJzu5Icr9AFUhmI3z qGMpbjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBADhtqCPIvc8t6La1swQso5U7FF3Is5txWrQWPzcttJMyPo1LzdNT/jHEKF93 nOqiKm50NISmDFkBSxKOTTYPFJ4thgFcTZf+K57ucvxL/c+MLj3PlmCMNmtciCa8gxpldYz4 aob7CT02KQZvX+yGUmOTdHkoLd9FaxRq0ei43EAxjGIsU7vliaAoKCSO0pRsdtSrOYNV3fSd ZB6xd8KBjAJsC8P/Q2BfeMT5+fJPvX5pfj8h+qyGkJCPx2RHhkf5tSIrnOAoYkvrUZFk1JJx H+v1KrX2QRCu3fx7L9D3S1QNSCD3d3nDcM2sXdtGg6/KynBtw31O4YqQWgU9XQp+NoYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwW1izAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzExMDQyMDUyNTdaMCMGCSqGSIb3DQEJBDEW BBTU+zBQLHgZn39oW3Ck8fKyyghyAzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFtYswDQYJKoZIhvcNAQEBBQAE ggEAh8Il89twaI+jYplek+wFYo2CPA+dTsEGA2fF+mVubXG8lz1Ug/RPM5jQqspSuHIkea1c 6a2xijyJpiFhYGlbu1byRaihLfgSFjQY4+Q5ZMa7jKRl6CKCS6a2iJ4zbWSeSuPXTAobyABr u+F2EWRZpII4PLRZACEfwW/Fn5ErY9ykk9H95DyF+2dJ/7I24i0m/+HsTLZScEhPoG1mUJaX YVVsZbsqSNki3tSsiNOiIP1mDFecSwlMCiHUkkkZeSFu6LptTnD/weYoNPSX52BLPMvWG96e YBf5NqVJ4UZFR3+yJPrTldSR5fr87i3W8kHmXGZmVfe+n6OiE36a4r1UIQAAAAAAAA== --------------ms010808010800000202000405-- From weigengyu@bupt.edu.cn Mon Nov 4 20:20:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62B211E8131 for ; Mon, 4 Nov 2013 20:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_40=-0.185, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVmpjZh6TUjS for ; Mon, 4 Nov 2013 20:20:04 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6718F21F9D23 for ; Mon, 4 Nov 2013 20:20:02 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 47E8619F39C; Tue, 5 Nov 2013 12:20:00 +0800 (HKT) Message-ID: <958625B0F6EC4C44B0E146CD46E4ABBD@WeiGengyuPC> From: "weigengyu" To: References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> <00bc875979c9100652c83cc262a26dac@xs4all.nl> In-Reply-To: <00bc875979c9100652c83cc262a26dac@xs4all.nl> Date: Tue, 5 Nov 2013 12:19:58 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 04:20:09 -0000 Hi，Peter, Thank you for your reply. > Does that partially answer your question for wireless meshes? Yes. "With the choice of the density of MPL forwarders and the number of repetitions by MPL forwarders", could help provide the multicast capability near to reliable. While Unreliable multicast is requried for many senarios, the current groupcomm draft can meet these requirements. But there are really some senarios, such as mobile healthcare, in-home switch control etcs, that need the reliable multicast. I wish that the CoAP groupcomm might evole to cover the CoAP reliable multicast at next stage. regards, Gengyu Network Technology Center, School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: peter van der Stok Sent: Monday, November 04, 2013 12:42 PM To: weigengyu Cc: Rahman, Akbar ; Core ; Dijk, Esko ; consultancy@vanderstok.org Subject: Re: [core] group-comm comments Hi Weigenyu, With the choice of the density of MPL forwarders and the number of repetitions by MPL forwarders it is possible to estimate the reliability of the MPL multicast as function of the single transmission failure rate under a range of network loads. Does that partially answer your question for wireless meshes? Peter weigengyu schreef op 2013-11-04 05:28: > Hi Akbar, > > Thank you for your reply. > >> Reliable multicast is not supported. >> We can perhaps make this more clear by adding a sentence in the Scope >> (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). > > I belive it is required. > I have misunderstood that it provides unreliable multicast just for > the use case of Light Switch Control. > > And, I also want to ask the List, > has anyone considered or been interested in CoAP Reliable Groupcomm or > CoAP reliable multicast? > > Regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts & Telecommunications > > > -----原始邮件----- From: Rahman, Akbar > Sent: Sunday, November 03, 2013 10:56 PM > To: weigengyu > Cc: Core ; Dijk, Esko ; consultancy@vanderstok.org > Subject: RE: [core] group-comm comments > > Hi Gengyu, > > > Just some quick feedback. The groupcomm draft assumes only unreliable > (i.e. not guaranteed) IP multicast. This is specified in > > http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.4 > (see 1st paragraph) > > and > > http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-3.4 > (see 3rd paragraph) > > > Reliable multicast is not supported. We can perhaps make this more > clear by adding a sentence in the Scope > (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). > > > > Thanks for your review, > > > Akbar > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of weigengyu > Sent: Saturday, November 02, 2013 9:16 AM > To: Dijk, Esko; consultancy@vanderstok.org > Cc: Core > Subject: Re: [core] group-comm comments > > Hi, Esko > > I would like to give some comments on the GROUP-COMM draft. > > There have use cases for reliable and unreliable multicast communications. > If this draft only for providing unreliable multicast over IP multicast, > it > is OK; just write it clearly. > > If the draft intends to have the reliable or partial multicast facility, > the dtaft needs to give what mechanisms can gurantte that. > > The draft should define mechnisms that the server can register its > capability of supporting multicast, > this may be put to RD server; > and wether to request reliable groupcomm shoule be the client's request. > >> To clarify: under the assumption that a server MAY respond to a multicast >> request, > A mechanism is required to make the server registers its capability. i.e. > whether to support multicast; > >> and the client doesn't know a priori how many servers will respond to a >> multicast, > The client may lookup the information from the RD server (if the rerver's > registeration processe were possible); > >> (since there are no guidelines/rules for that), the safest thing to do is >> not send the multicast in the first place. > If not first, when to make available? > So, whether it is required should be determined by the client request, and > there should have some authority or priority control to client. > >> Therefore the advice is to carefully control sending of multicast >> requests. > Not only to tell that, the draft should have clear descriptions about how > the protocol supports multicast requiests and/or reliable multicast when > required. > > regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts & Telecommunications > > -----原始邮件----- From: Dijk, Esko > Sent: Thursday, December 20, 2012 6:56 PM > To: consultancy@vanderstok.org > Cc: Core > Subject: Re: [core] group-comm comments > > Thanks Peter, > > I would agree we need to include guidelines on returning of responses to > CoAP multicast requests. (Note the CoAP spec ensures that a CoAP server > will > never ACK a multicast but that does not help a thing if it still sends a > response packet...) I'll make a ticket for this. If anyone disagrees we'll > hear it. > >> Then I do not understand the text, because "request", "reply" and >> "response" are overloaded in my mind. > To clarify: under the assumption that a server MAY respond to a multicast > request, and the client doesn't know a priori how many servers will > respond > to a multicast, (since there are no guidelines/rules for that), the safest > thing to do is not send the multicast in the first place. Therefore the > advice is to carefully control sending of multicast requests. > > Esko > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Thursday 20 December 2012 11:26 > To: Dijk, Esko > Cc: consultancy@vanderstok.org; akbar rahman; Core > Subject: RE: group-comm comments > > > Hi Esko, > > thanks for your reactions. I will group my answers, to better explain my > points on the return of packets to MC senders. > > 1) Return of packets to multicast > > As I understand the multicast message is preferably sent with no > confirmation (ack) because the return of all the acks may overwhelm the > network and the sender of the multicast. > The acknowledgement is not needed for MPL as the protocol has all the > machinery to assure that all destinations receive it, (given constraints > on > network load and configuration density and size). > > Supposing an ack is needed, then it would be advisable to staffle the > responses and an additional acknowledgement protocol could be added to the > multicast protocol. The same is true if a message is returned (as in the > case of mDNS). > > One can then wonder whether the application protocol (e.g. mDNS) should > take > care of the staffled response or that an additional protocol needs to be > specified. > I have no opinion on the choice, but see the need for the one or the > other. > Coming with a recommendation (explanation) on the subject of returning > responses (acks) would be my recommendation for the GroupComm document. > > Below some reactions on your reactions. Hope this helps to clarify > misunderstandings. > > Peter > > Dijk, Esko schreef op 2012-12-19 14:24: >> Hi Peter, >> >> still a fair number of comments! I would agree with most. Below I have >> selected some which we should discuss further, or ones I don’t agree >> with: >> >> 1. Group communication definition -> >> Why can't a source node be part of the group that it sends to? E.g. >> combined sensor+luminaire use case. The IP stack would deliver sent >> multicast CoAP requests also to the local application if it is >> subscribed to the multicast IP address. > source can of course be member of destination group. > source may be part of the group (remove the "or may be not" part of the > phrase) >> >> 2. I don’t see why we should add “the use of group communication for >> mDNS is out of scope.” -> mDNS obviously is not CoAP, and the >> document should define the scope anyway clearly as CoAP group >> communication. So we don’t have to list any other protocols than CoAP. > See my answer on return of packets. I wanted a clear statement on (NOT) > specifying how applications handle the return of MC responses. > >> >> 3. “so setting a multicast address in a source at installation is >> forbidden?” -> No, that should not be forbidden :) It should also be >> possible to set a CoAP path and/or port at installation time. That >> means the two presented measures have to change or be removed. > No comment >> >> 4. “there are 2 ways: (1) the node queries to which group it belongs >> or (2) an instalation tools instructs the node to which groups” -> >> Good point. (2) has been chosen because it works without relying on a >> service to query (e.g. DNS or RD). Is that sufficient argumentation? >> The mechanism is optional in any case so it does not block others from >> defining a DNS or RD variant. > I would point out both variants and mention that the draft focusses on > (2) >> >> 5. “/s requests /s replies” -> >> multicast replies (if you mean responses) do not exist in CoAP. It’s >> about requests that should be carefully controlled since they generate >> unicast responses. > Then I do not understand the text, because "request", "reply" and > "response" > are overloaded in my mind. >> >> 6. “/comment what about the reply?” -> based on core-coap “If the >> request message is Non-confirmable, then the response SHOULD be >> returned in a Non-confirmable message as well.” >> . Do you think we should quote this from the core-coap spec? > As explained above The subject of returning packets to the MC sender needs > careful consideration. > the response being NOn-confirmable does not solve a lot I am afraid. >> >> 7. “/comment invoking as many certificates?” -> >> core-coap-13 now loosens the concept of authentication to also >> include other measures, not needing certificates. > No comment >> >> 8. Network configuration: 2 subnets vs 1 -> maybe a one-subnet >> configuration is worth adding? Here an overview of present/absent use >> cases: >> >> - Link-local CoAP multicast with responses: Present, Appendix A of >> core-coap >> - Site-local CoAP multicast, single subnet: >> - Site-local CoAP multicast, multi subnet, with or without responses >> (in the new -04 groupcomm): Present >> - Global CoAP multicast, single or multi subnet, with or without >> responses: / dependency on IANA IPv6 allocation >> - any configurations with a central controller on the backbone >> multicasting: > > Again, the draft should go for the most frequent use cases and not try to > be > complete. > Actually explicitly excluding use cases looks ineresting to me. >> >> 9. “It might be useful if the practical impossibility of some >> configurations is high lighted” -> any thoughts, which would be >> impossible? > During the coap meeting in Atlanta, Cullen Jennings presented some > horrifying examples, as far as I remember. > >> >> 10.“the RD discovery will be more complex when there is a router >> between light-2 and switch” -> yes, there are issues in RD/discovery >> especially when more than one is present in a network. > So, adapt the use case and exclude this possibility. >> >> 11.“additional reason to remove router from the multicast >> configuration”-> hmm, I think that we should opt for having a single >> RD in the system to avoid complexity. Routers are ok. (One of our >> goals is to define how CoAP groupcomm works even across routers) > Looking forward to the supporting protocol. >> >> 12.“MLD is used to form groups, correct? but that was already done by >> enabling the MC address in the lights (point 2)” -> Step 1 is putting >> the MC address in the lights, then step 2 is the Lights use MLD to >> *ADVERTIZE* this address to any MLD-enabled Routers present >> link-local. >> So MLD is not a commissioning-time protocol but runs all the time >> during operation. >> Note that in groupcomm -04 we will remove MLD in the basic use case >> and present it as an option later. > > Sounds good. The point is not to add protocols because they exist but > because they are needed. >> >> 13.“WHY are the multicast destinations sending back results?” -> we >> remove responses in the new -04 groupcomm. They are presented as an >> optional thing that servers can do. >> CoAP servers normally MUST respond to a request with a response >> (core-coap-13) but an exception is now made for multicast where a >> server MAY choose not to. This choice is completely independent from >> confirmable/non-confirmable. Non-confirmable only means that an ACK >> must not be sent. And an ACK is something different from a CoAP >> response. >> Agree that a protocol like MPL comes very close to ‘reliable >> multicast’. > > see my worries at the beginning. >> >> Esko >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Tuesday 18 December 2012 12:06 >> To: akbar rahman; Dijk, Esko; Core >> Subject: group-comm comments >> >> Hi Akbar and Esko, >> >> I had promised to review, comment the group comm draft. >> >> Below the commented text. >> >> I have not gone very detailed with my comments. I hope that it is >> clear from my comments that a reorganization of the draft and a review >> of the uses cases are necessary to get a clearer picture of the >> feasibility of group comm in the context of Coap. >> >> Especialy difficult to understand for me were: >> >> - the use case network configuration >> >> - the forming and enabling of groups >> >> - use of responses >> >> Hope this helps. >> >> Greetings, >> >> peter >> >> ______________________________________________________________________ >> _______________________________ >> >> >> Abstract >> >> CoAP is a RESTful transfer protocol for constrained devices. 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 document >> >> defines how the CoAP protocol should be used in a group communication >> >> context. An approach for using CoAP on top of IP multicast is >> >> detailed for both constrained and un-constrained networks. Also, >> >> various use >> >> /s causes /s cases/ >> >> and corresponding protocol flows are provided to >> >> illustrate important concepts. Finally, guidance is provided for >> >> deployment in various network topologies. >> >> Status of this Memo >> >> This Internet-Draft is submitted in full conformance with the >> >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> >> Task Force (IETF). Note that other groups may also distribute >> >> working documents as Internet-Drafts. The list of current Internet- >> >> Drafts is at http://datatracker.ietf.org/drafts/current/ [1]. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> >> and may be updated, replaced, or obsoleted by other documents at any >> >> time. It is inappropriate to use Internet-Drafts as reference >> >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on April 22, 2013. >> >> Copyright Notice >> >> Copyright (c) 2012 IETF Trust and the persons identified as the >> >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> >> Provisions Relating to IETF Documents >> >> (http://trustee.ietf.org/license-info [2]) in effect on the date of >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 1] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> publication of this document. Please review these documents >> >> carefully, as they describe your rights and restrictions with respect >> >> to this document. Code Components extracted from this document must >> >> include Simplified BSD License text as described in Section 4.e of >> >> the Trust Legal Provisions and are provided without warranty as >> >> described in the Simplified BSD License. >> >> 1. Conventions and Terminology >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> >> document are to be interpreted as described in [RFC2119]. >> >> This document assumes readers are familiar with the terms and >> >> concepts that are used in [I-D.ietf-core-coap]. In addition, this >> >> document defines the following terminology: >> >> Group Communication >> >> A source node sends a single message which is delivered to >> >> multiple destination nodes, where all destinations are identified >> >> to belong to a specific group. The source node may >> >> /remove or may not >> >> be >> >> part of the group. The underlying mechanism for group >> >> communication is assumed to be multicast based. >> >> /remove >> >> The network where >> >> the group communication takes place can be either a constrained >> >> or >> >> a regular (un-constrained) network/ >> >> /comment not sure about the meaning and consequences >> >> Multicast >> >> Sending a message to multiple destination nodes >> >> /s simultaneously./ >> >> /s with one network invocation / >> >> There are various options to implement multicast including layer >> >> 2 >> >> (Media Access Control) or layer 3 (IP) mechanisms. >> >> IP Multicast >> >> A specific multicast solution based on the use of IP multicast >> >> addresses as defined in "IANA Guidelines for IPv4 Multicast >> >> Address Assignments" [RFC5771] and "IP Version 6 Addressing >> >> Architecture" [RFC4291]. >> >> Low power and Lossy Network (LLN) >> >> Low power and Lossy Network (LLN): A type of constrained network >> >> where the devices are interconnected by a variety of low power, >> >> lossy links such as IEEE 802.15.4, Bluetooth, >> >> WiFi, wired >> >> or low >> >> power power-line communication links. >> >> 2. Introduction >> >> 2.1. Background >> >> The Constrained Application Protocol (CoAP) is an application >> >> protocol (analogous to HTTP) for resource constrained devices >> >> operating in an IP network [I-D.ietf-core-coap]. Constrained >> >> devices >> >> can be large in number, but are often highly correlated to each >> >> other >> >> (e.g. by type or location). For example, all the light switches in >> >> a >> >> building may belong to one group and all the thermostats may belong >> >> to another group. Groups may be composed by function. For example, >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 3] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> the group "all lights in building one" may consist of the groups >> >> "all >> >> lights on floor one of building one", "all lights on floor two of >> >> building one", etc. Groups may be preconfigured >> >> /add before deployment >> >> or dynamically >> >> formed >> >> /add during operation >> >> . If information needs to be sent to or received from a group >> >> of devices, group communication mechanisms can improve efficiency >> >> and >> >> latency of communication and reduce bandwidth requirements for a >> >> given application. HTTP does not support any equivalent >> >> functionality to CoAP group communication. >> >> 2.2. Scope >> >> In this draft, we address the issues related to CoAP group >> >> communication in detail, with use cases, recommended approaches and >> >> analysis of the impact to the CoAP protocol and to implementations. >> >> /add the use of group communication for mDNS is out of scope. >> >> The guiding principle is to apply wherever possible existing IETF >> >> protocols to achieve group communication functionality. In many >> >> cases the contribution of this document lies in explaining how >> >> existing mechanisms may be used to >> >> /remove together >> >> fulfill CoAP group >> >> communication needs for specific use cases. >> >> 2.3. Potential Solutions for Group Communication >> >> The classic concept of group >> >> /s communications /s communication >> >> is that of a single >> >> source distributing content to multiple destination recipients that >> >> are all part of a group. Before content can be distributed, there >> >> is >> >> a separate process to form the group. The source may be either a >> >> member or non-member of the group. >> >> Group communication solutions have evolved from "bottom" to "top", >> >> i.e., from layer 2 (Media Access Control broadcast/multicast) and >> >> layer 3 (IP multicast) to application layer group communication, >> >> also >> >> referred to as application layer multicast. A study published in >> >> 2005 [Lao05] identified new solutions in the "middle" (referred to >> >> as >> >> overlay multicast) that utilize an infrastructure based on proxies. >> >> Each of these classes of solutions may be compared [Lao05] using >> >> metrics such as link stress and level of host complexity >> >> [Banerjee01]. The results show for a realistic internet topology >> >> that IP Multicast is the most resource-efficient, with the downside >> >> being that it requires >> >> /s the most /s more organizational >> >> effort to deploy in the >> >> infrastructure. IP Multicast is the solution adopted by this draft >> >> for CoAP group communication. >> >> 3. CoAP Group Communication Based On IP Multicast >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 4] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> 3.1. IP Multicast Background >> >> IP Multicast routing protocols have been evolving for decades, >> >> resulting in proposed standards such as Protocol Independent >> >> Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various >> >> technical and marketing reasons, IP Multicast routing is not widely >> >> deployed on the general Internet. However, IP Multicast is very >> >> popular in specific deployments such as in enterprise networks (e.g. >> >> for video conferencing), smart home networks (e.g. UPnP/mDNS) and >> >> carrier IPTV deployments. The packet economy and minimal host >> >> complexity of IP multicast make it attractive for group >> >> communication >> >> in constrained environments. Therefore IP multicast is the >> >> recommended underlying mechanism for CoAP group communication, and >> >> the approach assumed in this document. >> >> To achieve IP multicast beyond a subnet, an IP multicast routing >> >> protocol needs to be active on routers. The RPL protocol [RFC6550] >> >> for example is able to route multicast traffic in constrained LLNs. >> >> While PIM-SM [RFC4601] is often used for multicast routing in un- >> >> constrained networks. >> >> IP multicast can also be run in a Link-Local (LL) scope. This means >> >> that there is no routing involved and an IP multicast message is >> >> only >> >> received >> >> /s on the network /s over the >> >> link on which it was sent. >> >> 3.2. CoAP Group Definition and Naming >> >> A group is defined as a set of CoAP endpoints, where each endpoint >> >> is >> >> configured to receive a multicast CoAP request that is sent to the >> >> group's associated IP multicast address. The group MAY have more >> >> than one associated IP multicast address. An endpoint MAY be a >> >> member of multiple groups. Group membership of an endpoint MAY >> >> dynamically change over time. The group MAY be identified by a >> >> Group >> >> Name ([I-D.vanderstok-core-dna]) which is defined as a prefix string >> >> of a Group FQDN. The Group FQDN can be uniquely mapped to a site- >> >> local or global multicast IP address via DNS resolution. >> >> A CoAP multicast request that addresses a group includes a Group URI >> >> as the request URI. A Group URI has the scheme 'coap' and includes >> >> in the authority part either a group IP address >> >> /add + optional port >> >> or a hostname >> >> /add + optional port >> >> that >> >> can be resolved to the group IP address (e.g., a Group Name or Group >> >> FQDN). Group URIs MUST follow the URI syntax [RFC3986]. >> >> A CoAP >> >> /s node /s end-point >> >> becomes a group member by listening for CoAP messages on >> >> the group's IP multicast address, assuming the default CoAP UDP >> >> port. >> >> Note that a non-default UDP port MAY be specified for the group; in >> >> which case implementers MUST ensure that all group members are >> >> configured to use this same port. >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 5] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Examples of hierarchical group naming (and scoping) for a building >> >> control application are shown below. >> >> URI authority Targeted group >> >> all.bldg6.example.com "all nodes in building 6" >> >> all.west.bldg6.example.com "all nodes in west wing, building >> >> 6" >> >> all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, >> >> building 6" >> >> all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, >> >> west wing, building 6" >> >> Reverse mapping (from IP multicast address to group FQDN) is >> >> supported using the reverse DNS resolution technique >> >> ([I-D.vanderstok-core-dna]). >> >> 3.3. Group Discovery and Member Discovery >> >> CoAP defines a resource discovery capability, but does not yet >> >> specify how to discover groups (e.g. find a group to join or send a >> >> multicast message to) or to discover members of a group (e.g. to >> >> address selected group members by unicast). These topics are >> >> elaborated in more detail in [I-D.vanderstok-core-dna] including >> >> examples for using DNS-SD and CoRE Resource Directory. >> >> 3.3.1. DNS-SD >> >> DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a >> >> conventional way to configure DNS PTR, SRV, and TXT records to >> >> enable >> >> enumeration of services, such as services offered by CoAP nodes, or >> >> enumeration of all CoAP nodes, within specified subdomains. A >> >> service is specified by a name of the form >> >> .., where the service type for CoAP >> >> nodes is _coap._udp and the domain is a DNS domain name that >> >> identifies a group as in the examples above. For each CoAP >> >> end-point >> >> in a group, a PTR record with the name _coap._udp and/or a PTR >> >> record >> >> with the name _coap._udp. is defined and it points to an SRV >> >> record having the .. name. >> >> All CoAP nodes in a given subdomain may be enumerated by sending a >> >> query for PTR records named _coap._udp to the authoritative DNS >> >> server for that zone. A list of SRV records is returned. Each SRV >> >> record contains the port and host name (AAAA record) of a CoAP node. >> >> The IP address of the node is obtained by resolving the host name. >> >> DNS-SD also specifies an optional TXT record, having the same name >> >> as >> >> the SRV record, which can contain "key=value" attributes. This can >> >> be used to store information about the device, e.g. schema=DALI, >> >> type=switch, group=lighting.bldg6, etc. >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 6] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Another feature of DNS-SD is the ability to specify service subtypes >> >> using PTR records. For example, one could represent all the CoAP >> >> groups in a subdomain by PTR records with the name >> >> _group._sub._coap._udp or alternatively >> >> _group._sub._coap._udp.. >> >> 3.3.2. CoRE Resource Directory >> >> CoRE Resource Directory [I-D.shelby-core-resource-directory] defines >> >> the concept of a Resource Directory (RD) server where CoAP servers >> >> can register their resources offered and CoAP clients can discover >> >> these resources by querying the RD server. RD syntax can be mapped >> >> to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], >> >> such that the above approach can be reused for group discovery and >> >> group member discovery. >> >> /remove Specifically, the Domain (d) parameter can be set to the >> >> group URI by >> >> an end-point registering to the RD. If an end-point wants to join >> >> multiple groups, it has to repeat the registration process for each >> >> group it wants to join. >> >> /end remove >> >> /comment d parameter semantics not clear >> >> 3.4. Group Resource Manipulation >> >> Group communications SHALL only be used for idempotent methods (i.e. >> >> CoAP GET, PUT, DELETE). The CoAP messages that are sent via >> >> multicast SHALL be Non-Confirmable. >> >> A unicast response per server MAY be sent back to answer the group >> >> request (e.g. response "2.05 Content" to a group GET request) taking >> >> into account the congestion control rules defined in >> >> [I-D.ietf-core-coap]. The unicast responses may be a mixture of >> >> success (e.g. 2.05 Content) and failure (e.g. 4.04 Not Found) codes >> >> depending on the individual server processing result. >> >> Group communications SHALL NOT be used for non-idempotent methods >> >> (i.e. CoAP POST). This is because not all group members are >> >> guaranteed to receive the multicast request, and the sender can not >> >> readily find out which group members did not receive it. >> >> All nodes in a given group SHOULD receive the same request >> >> /remove with high probability. >> >> /comment I don't see where probability comes in. >> >> This will not be the case if there is diversity in the >> >> authority port (i.e. a diversity of dynamic port addresses across >> >> the >> >> group) or if the targeted resource is located at different paths on >> >> different nodes. >> >> Therefore, some measures must be present to ensure uniformity in >> >> port >> >> number and resource names/locations within a group. This document >> >> proposes the following measures: >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 7] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> o All CoAP multicast requests MUST be sent either to the default >> >> CoAP UDP port (i.e. default Uri-Port as defined in >> >> [I-D.ietf-core-coap]), or to a port number obtained via a service >> >> discovery lookup operation as a valid CoAP port for the targeted >> >> multicast group. >> >> o All CoAP multicast requests SHOULD operate only on URIs (links) >> >> which were >> >> /s retreived /s retrieved >> >> either from a "/.well-known/core" lookup on >> >> at least one group member node, or from an equivalent service >> >> discovery lookup which returns either the resources supported by >> >> all group members or resources supported by one particular group >> >> member. >> >> /comment so setting a multicast address in a source at installation is >> >> forbidden? >> >> 3.5. Configuring Group Membership In Endpoints >> >> In some use cases, the group membership of endpoints needs to be >> >> configurable after the network has been deployed. Example use cases >> >> can be found in building control: a commissioning tool determines to >> >> which groups a light or sensor node belongs, and writes this >> >> information to all nodes, which can subsequently join the correct >> >> group. >> >> To achieve smoother interoperability between nodes/endpoints from >> >> different manufacturers, it is proposed here to define an OPTIONAL >> >> standardized RESTful means of configuring CoAP endpoints with >> >> relevant group information. >> >> CoAP endpoints implementing this mechanism MUST support a >> >> discoverable "Group Configuration" resource of resource type (rt) >> >> [RFC6690] "core.gp". This resource (and perhaps its sub-resources, >> >> TBD) are used to manage group membership. Three design options for >> >> this mechanism are presented here as a placeholder (TBD). >> >> Design 1: use CoRE link format payloads to communicate group >> >> membership to endpoints. (TBD Not clear how this should be >> >> realized.) >> >> /comment, not clear what you mean either. Remove design 1 in this >> state >> >> Design 2: use a JSON type resource. For example, a GET on the >> >> "core.gp" resource returns a JSON array of group objects. >> >> Req: GET /gp >> >> Res: 2.05 Content (Content-Format: application/json) >> >> [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", >> >> "ip": "ff05::4200:f7fe:ed37:14ca" } >> >> ] >> >> where "n" defines the Group FQDN and "ip" defines the associated >> >> multicast IP address. As a next example, the same endpoint can be >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 8] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> added to another group by a POST on the resource with a JSON group >> >> object: >> >> Req: POST /gp (Content-Format: application/json) >> >> { "n": "floor1.west.bldg6.example.com", >> >> "ip": "ff05::4200:f7fe:ed37:14cb" } >> >> Res: 2.04 Changed >> >> Design 3: define named sub-resources, each sub-resource representing >> >> a group membership. The payload of the sub-resource may be JSON or >> >> a >> >> simple pre-defined format. Or alternatively, information is >> >> provided >> >> via POST with query parameters. >> >> /comment are these mutually exclusive designs? >> >> /comment design 2 without JSON is als possible >> >> /comment design with SRV and TXt records is also possible >> >> /comment there are 2 ways: (1) the node queries to which group it >> >> belongs >> >> /comment (2) an instalation tools instructs the node to which groups >> >> it belongs >> >> /comment not clear in text that this choice exists or that a choice >> was >> >> made. >> >> 3.6. Congestion Control >> >> Multicast CoAP requests may result in a multitude of replies from >> >> different nodes, potentially causing congestion. Therefore sending >> >> multicast >> >> /s requests /s replies >> >> should be conservatively controlled. >> >> The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific >> >> congestion risks through the following measures: >> >> o A server MAY choose not to respond to a multicast request if >> >> there's nothing useful to respond (e.g. error or empty response). >> >> o A server SHOULD limit the support for multicast requests to >> >> specific resources where multicast operation is required. >> >> o A multicast request MUST be Non-Confirmable. >> >> /comment what about the reply? >> >> o A server does not respond immediately to a multicast request, but >> >> SHOULD first wait for a time that is randomly picked within a >> >> predetermined time interval called the Leisure. >> >> o A server SHOULD NOT accept multicast requests that can not be >> >> authenticated. >> >> /comment invoking as many certificates? >> >> Additional guidelines to reduce congestion risks are: >> >> o A server in an LLN should only support multicast GET for >> >> resources >> >> that are small, e.g. >> >> /remove for an LLN that could mean >> >> the payload of the >> >> response fits into a single link-layer frame. >> >> o A server can minimize the payload length in response to a >> >> multicast GET on "/.well-known/core" by using hierarchy in >> >> arranging link descriptions for the response. An example of this >> >> is given in Section 5 of [RFC6690]. >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 9] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> o Preferably IP multicast with link-local scope should be used, >> >> rather than global or site-local. >> >> o The Hop Limit field in the IPv6 packet should be chosen as low as >> >> possible (if the CoAP/IP stack allows setting of this value. TBD >> >> - discuss whether this guideline is relevant/realistic in CoAP >> >> context) >> >> 3.7. CoAP Multicast and HTTP Unicast Interworking >> >> /comment a reference will suffice >> >> CoAP supports operation over UDP multicast, while HTTP does not. >> >> For >> >> use cases where it is required that CoAP group communication is >> >> initiated from an HTTP end-point, it would be advantageous if the >> >> HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group >> >> communication based on IP multicast. >> >> /remove One possible way of operation >> >> /remove of such HTTP-CoAP Proxy is illustrated in Figure 1. >> >> Note that this >> >> topic is covered in more detail in >> >> [I-D.castellani-core-advanced-http-mapping]. >> >> /remove >> >> CoAP Mcast CoAP Mcast HTTP-CoAP HTTP >> >> Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 >> >> | | | | | | >> >> |MLD REQUEST | | | | >> >> |(Join Group X) | | | | >> >> |--LL-->| | | | | >> >> | | |MLD REQUEST | | >> >> | | |(Join Group X) | | >> >> | | |--LL-->| | | >> >> | | | | | HTTP REQUEST | >> >> | | | | | (URI to | >> >> | | | | | unicast addr) | >> >> | | | | |< -----------------| >> >> | | | | | | >> >> | | | Resolve HTTP Request-Line URI | >> >> | | | to Group X multicast address | >> >> | | | | | | >> >> | CoAP REQUEST (to multicast addr)| | >> >> |< ------<---------<-------<------| | >> >> | | | | | | >> >> | | | | >> >> | (optional) CoAP RESPONSE(s) | | >> >> | |-------------->| | >> >> |-----------------|-------------->| Aggregated | >> >> | | | HTTP RESPONSE | >> >> | | |------------------>| >> >> | | | | >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 10] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Figure 1: CoAP Multicast and HTTP Unicast Interworking >> >> Note that Figure 1 illustrates the case of IP multicast as the >> >> underlying group communications mechanism. MLD denotes the >> >> Multicast >> >> Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a >> >> Link-Local multicast. >> >> A key point in Figure 1 is that the incoming HTTP Request (from node >> >> 3) will carry a Host request-header field that resolves in the >> >> general Internet to the proxy node. At the proxy node, this >> >> hostname >> >> and/or the Request-Line URI will then possibly be mapped (as >> >> detailed >> >> in [I-D.castellani-core-http-mapping]) and again resolved (with the >> >> CoAP scheme) to an IP multicast address. This may be accomplished, >> >> for example, by using DNS or DNS-SD (Section 3.3). The proxy node >> >> will then IP multicast the CoAP Request (corresponding to the >> >> received HTTP Request) via multicast routers to the appropriate >> >> nodes >> >> (i.e. nodes 1 and 2). >> >> In terms of the HTTP Response, Figure 1 illustrates that it will be >> >> generated by the proxy node based on aggregated responses of the >> >> CoAP >> >> nodes and sent back to the client in the general Internet that sent >> >> the HTTP Request (i.e. node 1). In >> >> [I-D.castellani-core-advanced-http-mapping] the HTTP Response that >> >> the Proxy may use to aggregate multiple CoAP responses is described >> >> in more detail. So in terms of overall operation, the CoAP proxy >> >> can >> >> be considered to be a "non-transparent" proxy according to >> >> [RFC2616]. >> >> Specifically, [RFC2616] states that a "non-transparent proxy is a >> >> proxy that modifies the request or response in order to provide some >> >> added service to the user agent, such as group annotation services, >> >> media type transformation, protocol reduction or anonymity >> >> filtering." >> >> An alternative to the above is using a Forward Proxy. In this case, >> >> the CoAP request URI is carried in the HTTP Request-Line (as defined >> >> in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the >> >> IP address of the Proxy. >> >> /end remove >> >> 4. Use Cases and Corresponding Protocol Flows >> >> 4.1. Introduction >> >> The use of CoAP group communication is shown in the context of the >> >> following use cases and corresponding protocol flows: >> >> o Discovery of Resource Directory: discovering the local CoRE RD >> >> which contains links (URIs) to resources stored on other servers >> >> [RFC6690]. >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 11] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> o Lighting Control: synchronous operation of a group of 6LoWPAN >> >> [RFC4944] IPv6-connected lights >> >> o Parameter Update: updating parameters/settings simultaneously in >> >> a >> >> large group of devices in a building/campus control >> >> ([I-D.vanderstok-core-bc]) application --- TBD >> >> / comment I suggest to remove Firmware Update and Groups status report >> >> /comment the ones above are difficult enough, and I doubt that >> >> simultaneity >> >> /comment (motivation of multicast) is involved here >> >> o Firmware Update: efficiently updating firmware simultaneously in >> >> a >> >> large group of devices in a building/campus control >> >> ([I-D.vanderstok-core-bc]) application --- TBD suggests a >> >> multicast extension of core-block. >> >> o Group Status Report: requesting status information or event >> >> reports from a group of devices in a building/campus control >> >> application --- TBD, may require reliable group communication to >> >> be feasible. >> >> 4.2. Network Configuration >> >> We assume the following network configuration for all the use cases >> >> as shown in Figure 2: >> >> /comment the configurations frighten me >> >> /comment from completeness considerations I can imagine even more >> >> complex ones >> >> /comment It might be useful if the practical impossibility of some >> >> configurations is high lighted >> >> o A large room (Room-A) with three lights (Light-1, Light-2, >> >> Light-3) controlled by a Light Switch. The devices are organized >> >> into two 6LoWPAN subnets. >> >> /comment one subnet is enough for me >> >> /remove >> >> o Light-1 and the Light Switch are connected to a router (Rtr-1) >> >> which is also a CoAP Proxy, a CoAP Resource Directory (RD) and a >> >> 6LoWPAN Border Router (6LBR). >> >> o Light-2 and the Light-3 are connected to another router (Rtr-2) >> >> which is also a CoAP Proxy, a CoAP RD and a 6LBR. >> >> o The routers are connected to an IPv6 network backbone which is >> >> also multicast enabled. In the general case, this means the >> >> network backbone and 6LBRs support a PIM based multicast routing >> >> protocol, and MLD for forming groups. In a limited case, if the >> >> network backbone is one link, then the routers only have to >> >> support MLD-snooping (Appendix A) for the following use cases to >> >> work. >> >> /end remove >> >> /comment I can imagine that an central control is present on the >> >> backbone >> >> /comment switch or sensor send unicast to central control >> >> /comment central control sends multicast to multicast group within >> >> single lowpan >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 12] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Network >> >> Backbone >> >> | >> >> ################################################ >> >> | >> >> # Room-A # >> >> | >> >> # ********************** # >> >> | >> >> # ** LoWPAN-1 (subnet-1) ** # >> >> | >> >> # * * # >> >> | >> >> # * +----------+ * # >> >> | >> >> # * | Light |-------+ * # >> >> | >> >> # * | Switch | | * # >> >> | >> >> # * +----------+ +---------+ * # >> >> | >> >> # * | Rtr-1 >> >> |-----------------------------| >> >> # * +---------+ * # >> >> | >> >> # * +----------+ | * # >> >> | >> >> # * | Light-1 |--------+ * # >> >> | >> >> # * +----------+ * # >> >> | >> >> # * * # >> >> | >> >> # ** ** # >> >> | >> >> # ********************** # >> >> | >> >> # # >> >> | >> >> # # >> >> | >> >> # ********************** # >> >> | >> >> # ** LoWPAN-2 (subnet-2) ** # >> >> | >> >> # * * # >> >> | >> >> # * +----------+ * # >> >> | >> >> # * | Light-2 |-------+ * # >> >> | >> >> # * | | | * # >> >> | >> >> # * +----------+ +---------+ * # >> >> | >> >> # * | Rtr-2 >> >> |-----------------------------| >> >> # * +---------+ * # >> >> | >> >> # * +----------+ | * # >> >> | >> >> # * | Light-3 |--------+ * # >> >> | >> >> # * +----------+ * # >> >> | >> >> # * * # >> >> | >> >> # ** ** # >> >> | >> >> # ********************** # >> >> | >> >> # # >> >> | >> >> ################################################# >> >> | >> >> | >> >> +--------+ >> >> | >> >> | DNS >> >> |------------------| >> >> | Server | >> >> +--------+ >> >> Figure 2: Network Topology of a Large Room (Room-A) >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 13] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> 4.3. Discovery of Resource Directory >> >> The protocol flow for discovery of a RD for the given network (of >> >> Figure 2) is shown in Figure 3: >> >> o The fixture for Light-2 is installed and powered on for the first >> >> time. >> >> o Light-2 will then search for the local RD (RD-2) by sending out a >> >> GET request (with the "/.well-known/core?rt=core.rd" request URI) >> >> to the site-local "All CoAP Nodes" address. In this case, the >> >> site is assumed to include all nodes in the subnet. >> >> o This multicast message will then go to each node in subnet-2. >> >> However, only Rtr-2 (RD-2) will respond because the GET is >> >> qualified by the query string "?rt=core.rd". >> >> o Note that the flow is shown only for Light-2 for clarity. >> >> Similar >> >> flows will happen for Light-1, Light-3 and the Light Switch when >> >> they are first powered on. >> >> The RD may also be discovered by other means such as by assuming a >> >> default location (e.g. on a 6LBR), using DHCP, anycast address, etc. >> >> However, these approaches do not invoke CoAP group communication so >> >> are not further discussed here. >> >> For other discovery use cases such as discovering local CoAP >> >> servers, >> >> services or resources group communication can be used in a similar >> >> fashion as in the above use case. Both Link-Local (LL) and site- >> >> local discovery are possible this way. >> >> /comment the RD discovery will be more complex when there is a router >> >> between light-2 and switch >> >> /comment Via which RD will light switch discover light-2? >> >> /comment additional reason to remove router from the multicast >> >> configuration >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 14] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Light Rtr-1 Rtr-2 >> >> Network >> >> Light-1 Light-2 Light-3 Switch (RD-1) (RD-2) >> >> Backbone >> >> | | | | | | | >> >> | | | | | | | >> >> ********************************** | | | >> >> * Light-2 is installed * | | | >> >> * and powers on for first time * | | | >> >> ********************************** | | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | COAP NON (GET | | >> >> | | /.well-known/core?rt=core.rd) | | >> >> | |--------->-------------------------------->| | >> >> | | | | | | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | COAP NON (2.05 Content | | >> >> | | ;rt="core.rd";ins="Primary") | | >> >> | |<------------------------------------------| | >> >> | | | | | | | >> >> Figure 3: Resource Directory Discovery via Multicast Message >> >> 4.4. Lighting Control >> >> /comment I am confused about the use of protocols >> >> /comment MLD is used to form groups, correct? >> >> /comment but that was already done by enabling the MC address in the >> >> lights (point 2) >> >> /comment There are several ways to set up groups, pointing them out >> and >> >> when to use them would be an asset. >> >> The protocol flow for a building automation lighting control >> >> scenario >> >> for the network (Figure 2) is shown in sequence in Figure 4, >> >> Figure 5, and Figure 6. We assume the following steps occur before >> >> the illustrated flow: >> >> o 1) Startup phase: 6LoWPANs are formed. IPv6 addresses assigned >> >> to >> >> all devices. The CoAP network is formed. >> >> o 2) Commissioning phase (by applications): The IP multicast >> >> address >> >> of the group (Room-A-Lights) has been >> >> /s set /s enable >> >> in all the Lights. The >> >> URI of the group (Room-A-Lights) has been >> >> /s set /s resolved >> >> in the Light Switch. >> >> o 3) The indicated MLD Report messages are link-local multicast. >> >> In >> >> each LoWPAN, it is assumed that a multicast routing/forwarding >> >> protocol in 6LRs will then propagate the Join information >> >> contained in the MLD Report over multiple hops to the 6LBR. >> >> /comment Don't see the need >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 15] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Light Rtr-1 Rtr-2 >> >> Network >> >> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >> >> Backbone >> >> | | | | Proxy) Proxy) | >> >> | | | | | | | >> >> | | | | | | | >> >> | MLD Report: Join | | | | | >> >> | Group (Room-A-Lights) | | | | >> >> |---LL------------------------------------->| | | >> >> | | | | |MLD Report: Join | >> >> | | | | |Group (Room-A-Lights)| >> >> | | | | |---LL--------------->| >> >> | | | | | | | >> >> | | MLD Report: Join | | | | >> >> | | Group (Room-A-Lights) | | | >> >> | |---LL------------------------------------->| | >> >> | | | | | | | >> >> | | | MLD Report: Join | | | >> >> | | | Group (Room-A-Lights) | | >> >> | | |---LL-------------------------->| | >> >> | | | | | | | >> >> | | | | |MLD Report: Join | >> >> | | | | |Group (Room-A-Lights)| >> >> | | | | | |---LL---->| >> >> | | | | | | | >> >> | | | | | | | >> >> Figure 4: Joining Lighting Groups Using MLD >> >> /comment possibly remove from text, or do separate section on use of >> >> MLD >> >> /comment anyway separating commissioning from operation in separate >> >> sections is a good idea. >> >> /comment the proxies are a complication in the picture not elaborated >> >> in the text. >> >> /comment the subject of proxies is another one, to be treated >> >> elsewhere. >> >> /comment also for proxies the do's and don't's from a simple >> >> performance perspective will be interesting >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 16] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Light Rtr-1 Rtr-2 >> >> Network >> >> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >> >> Backbone >> >> | | | | Proxy) Proxy) | >> >> | | | | | | | >> >> | | *********************** | | >> >> | | * User flips on * | | >> >> | | * light switch to * | | >> >> | | * turn on all the * | | >> >> | | * lights in Room A * | | >> >> | | *********************** | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | | COAP NON (PUT | | | >> >> | | | Proxy-URI | | | >> >> | | | URI for Room-A-Lights | >> >> | | | Payload=turn on lights) | >> >> | | | |--------->| | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | | | Request DNS resolution of | >> >> | | | | URI for Room-A-Lights | >> >> | | | | |-------------------->| >> >> | | | | | | | >> >> | | | | | | | >> >> | | | | DNS returns: AAAA | >> >> | | | | Group (Room-A-Lights) | >> >> | | | | IPv6 multicast address | >> >> | | | | |<--------------------| >> >> | | | | | | | >> >> | | | | | | | >> >> | | | COAP NON (Put | >> >> | | | | URI Path | >> >> | | | | Payload=turn on lights)| >> >> | | | | Destination IP Address = | >> >> | | | | IP multicast address | >> >> | | | | for Group (Room-A-Lights)| >> >> | | | | Originating IP Address = | >> >> | | | | RTR-1 | >> >> | | | | |-------------------->| >> >> |<------------------------------------------| | | >> >> | | | | | | | >> >> | | | | | |<---------| >> >> | |<---------|<-------------------------------| | >> >> | | | | | | | >> >> | | | | | | | >> >> Figure 5: Sending Lighting Control Multicast Message >> >> Rahman & Dijk Expires April 22, 2013 [Page >> >> 17] >> >> Internet-Draft Group Communication for CoAP October >> >> 2012 >> >> Light Rtr-1 Rtr-2 >> >> Network >> >> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >> >> Backbone >> >> | | | | Proxy) Proxy) | >> >> | | | | | | | >> >> *********************** | | | | >> >> * Lights in Room-A * | | | | >> >> * turn on (nearly * | | | | >> >> * simultaneously) * | | | | >> >> *********************** | | | | >> >> | | | | | | | >> >> | | | | | | | >> >> | COAP NON (2.04 Changed) | | | | >> >> |------------------------------------------>| | | >> >> | | | | | | | >> >> | | | | | | | >> >> | COAP NON (2.04 Changed) | | | >> >> | |------------------------------->| | | >> >> | | | | | | | >> >> | | | | | | | >> >> | | COAP NON (5.00 Internal Server Error) | >> >> | | |-------------------->| | | >> >> | | | | | | | >> >> | | | ****************************** | >> >> | | | * Rtr-1 as CoAP Proxy * | >> >> | | | * | sends the individual * | >> >> | | | * | responses back to * | >> >> | | | * v originator * | >> >> | | | ****************************** | >> >> | | | | | | | >> >> | | | COAP NON (2.04 Changed) | | >> >> | | | |<---------| | | >> >> | | | | | | | >> >> | | | COAP NON (2.04 Changed) | | >> >> | | | |<---------| | | >> >> | | | | | | | >> >> | | | COAP NON (5.00 Internal Server Error) | >> >> | | | |<---------| | | >> >> | | | | | | | >> >> Figure 6: Sending Lighting Control Response to Multicast Message >> >> NOTE: In the last step of Figure 6, Rtr-1 acting as CoAP proxy, >> >> returns multiple individual CoAP responses to the client. Each >> >> response echoes the Token of the client's request. The client can >> >> identify the original source of each response by ...TBD. >> >> /comment WHY are the multicast destinations sending back results? >> >> /comment I thought that you wanted MC messages to be non confirmable >> >> /comment sending responses seems to contradict this . >> >> /comment please remove sending back of responses. >> >> /comment one may assume that the MC algorithm within the lowpan is >> >> reliable (all destinations receive the message) >> >> /comment anyway MPL comes close enough to the reliability requirement >> >> given a specifiable range of configurations >> >> ______________________________________________________________________ >> _____________________________________________________ >> >> >> -- >> >> Peter van der Stok >> >> mailto: consultancy@vanderstok.org >> >> www: www.vanderstok.org [3] >> >> tel NL: +31(0)492474673 F: +33(0)966015248 >> >> ------------------------- >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original >> message. >> >> >> Links: >> ------ >> [1] http://datatracker.ietf.org/drafts/current/ >> [2] http://trustee.ietf.org/license-info >> [3] http://www.vanderstok.org > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby > notified > that any use, forwarding, dissemination, or reproduction of this message > is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all > copies > of the original message. > _______________________________________________ > 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 From stokcons@xs4all.nl Tue Nov 5 07:34:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C9A21F9E36 for ; Tue, 5 Nov 2013 07:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.696 X-Spam-Level: X-Spam-Status: No, score=0.696 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BExXSiJQAiK for ; Tue, 5 Nov 2013 07:34:26 -0800 (PST) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3191311E8112 for ; Tue, 5 Nov 2013 07:34:24 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube3.xs4all.net [194.109.20.199]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id rA5FY6TZ049010; Tue, 5 Nov 2013 16:34:10 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from hotel-wireless-v6.meeting.ietf.org ([2001:67c:370:144:6835:8cad:6647:733f]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 05 Nov 2013 16:34:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 05 Nov 2013 16:34:06 +0100 From: peter van der Stok To: weigengyu Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <958625B0F6EC4C44B0E146CD46E4ABBD@WeiGengyuPC> References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> <00bc875979c9100652c83cc262a26dac@xs4all.nl> <958625B0F6EC4C44B0E146CD46E4ABBD@WeiGengyuPC> Message-ID: <8e1539df1fad55638a5399a3d3ca0b9f@xs4all.nl> X-Sender: stokcons@xs4all.nl (S5gsg9YtLaWkJHoJebrJH5yxJtUHkFSK) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: core@ietf.org Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2013 15:34:31 -0000 Hi Gengyu. The medical case is a bit familiar to me. It involved a limited number of receivers which are not too far removed from the source. You would look for a 2-phase commit style of multicast, I expect. Only when all receivers received the message, can commit take place otherwise, abort. Is that correct? This is a very different approach from the MPL one or the video streaming one. As far as I know algorithms exist, but I don't know about standardization. Peter weigengyu schreef op 2013-11-05 05:19: > Hi，Peter, > > Thank you for your reply. > >> Does that partially answer your question for wireless meshes? > Yes. > > "With the choice of the density of MPL forwarders and the number of > repetitions by MPL forwarders", > could help provide the multicast capability near to reliable. > > While Unreliable multicast is requried for many senarios, the current > groupcomm draft can meet these requirements. > > But there are really some senarios, such as mobile healthcare, in-home > switch control etcs, that need the reliable multicast. > I wish that the CoAP groupcomm might evole to cover the CoAP reliable > multicast at next stage. > > regards, > > Gengyu > > Network Technology Center, > School of Computer > Beijing University of Posts & Telecommunications > > > -----原始邮件----- From: peter van der Stok > Sent: Monday, November 04, 2013 12:42 PM > To: weigengyu > Cc: Rahman, Akbar ; Core ; Dijk, Esko ; consultancy@vanderstok.org > Subject: Re: [core] group-comm comments > > Hi Weigenyu, > > With the choice of the density of MPL forwarders and the number of > repetitions by MPL forwarders it is possible to estimate the > reliability > of the MPL multicast as function of the single transmission failure > rate > under a range of network loads. > > Does that partially answer your question for wireless meshes? > > Peter > > > > weigengyu schreef op 2013-11-04 05:28: >> Hi Akbar, >> >> Thank you for your reply. >> >>> Reliable multicast is not supported. >>> We can perhaps make this more clear by adding a sentence in the Scope >>> (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). >> >> I belive it is required. >> I have misunderstood that it provides unreliable multicast just for >> the use case of Light Switch Control. >> >> And, I also want to ask the List, >> has anyone considered or been interested in CoAP Reliable Groupcomm or >> CoAP reliable multicast? >> >> Regards, >> >> Gengyu >> >> Network Technology Center >> School of Computer >> Beijing University of Posts & Telecommunications >> >> >> -----原始邮件----- From: Rahman, Akbar >> Sent: Sunday, November 03, 2013 10:56 PM >> To: weigengyu >> Cc: Core ; Dijk, Esko ; consultancy@vanderstok.org >> Subject: RE: [core] group-comm comments >> >> Hi Gengyu, >> >> >> Just some quick feedback. The groupcomm draft assumes only unreliable >> (i.e. not guaranteed) IP multicast. This is specified in >> >> http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.4 >> (see 1st paragraph) >> >> and >> >> http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-3.4 >> (see 3rd paragraph) >> >> >> Reliable multicast is not supported. We can perhaps make this more >> clear by adding a sentence in the Scope >> (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). >> >> >> >> Thanks for your review, >> >> >> Akbar >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf >> Of weigengyu >> Sent: Saturday, November 02, 2013 9:16 AM >> To: Dijk, Esko; consultancy@vanderstok.org >> Cc: Core >> Subject: Re: [core] group-comm comments >> >> Hi, Esko >> >> I would like to give some comments on the GROUP-COMM draft. >> >> There have use cases for reliable and unreliable multicast >> communications. >> If this draft only for providing unreliable multicast over IP >> multicast, it >> is OK; just write it clearly. >> >> If the draft intends to have the reliable or partial multicast >> facility, >> the dtaft needs to give what mechanisms can gurantte that. >> >> The draft should define mechnisms that the server can register its >> capability of supporting multicast, >> this may be put to RD server; >> and wether to request reliable groupcomm shoule be the client's >> request. >> >>> To clarify: under the assumption that a server MAY respond to a >>> multicast >>> request, >> A mechanism is required to make the server registers its capability. >> i.e. >> whether to support multicast; >> >>> and the client doesn't know a priori how many servers will respond to >>> a >>> multicast, >> The client may lookup the information from the RD server (if the >> rerver's >> registeration processe were possible); >> >>> (since there are no guidelines/rules for that), the safest thing to >>> do is >>> not send the multicast in the first place. >> If not first, when to make available? >> So, whether it is required should be determined by the client request, >> and >> there should have some authority or priority control to client. >> >>> Therefore the advice is to carefully control sending of multicast >>> requests. >> Not only to tell that, the draft should have clear descriptions about >> how >> the protocol supports multicast requiests and/or reliable multicast >> when >> required. >> >> regards, >> >> Gengyu >> >> Network Technology Center >> School of Computer >> Beijing University of Posts & Telecommunications >> >> -----原始邮件----- From: Dijk, Esko >> Sent: Thursday, December 20, 2012 6:56 PM >> To: consultancy@vanderstok.org >> Cc: Core >> Subject: Re: [core] group-comm comments >> >> Thanks Peter, >> >> I would agree we need to include guidelines on returning of responses >> to >> CoAP multicast requests. (Note the CoAP spec ensures that a CoAP >> server will >> never ACK a multicast but that does not help a thing if it still sends >> a >> response packet...) I'll make a ticket for this. If anyone disagrees >> we'll >> hear it. >> >>> Then I do not understand the text, because "request", "reply" and >>> "response" are overloaded in my mind. >> To clarify: under the assumption that a server MAY respond to a >> multicast >> request, and the client doesn't know a priori how many servers will >> respond >> to a multicast, (since there are no guidelines/rules for that), the >> safest >> thing to do is not send the multicast in the first place. Therefore >> the >> advice is to carefully control sending of multicast requests. >> >> Esko >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Thursday 20 December 2012 11:26 >> To: Dijk, Esko >> Cc: consultancy@vanderstok.org; akbar rahman; Core >> Subject: RE: group-comm comments >> >> >> Hi Esko, >> >> thanks for your reactions. I will group my answers, to better explain >> my >> points on the return of packets to MC senders. >> >> 1) Return of packets to multicast >> >> As I understand the multicast message is preferably sent with no >> confirmation (ack) because the return of all the acks may overwhelm >> the >> network and the sender of the multicast. >> The acknowledgement is not needed for MPL as the protocol has all the >> machinery to assure that all destinations receive it, (given >> constraints on >> network load and configuration density and size). >> >> Supposing an ack is needed, then it would be advisable to staffle the >> responses and an additional acknowledgement protocol could be added to >> the >> multicast protocol. The same is true if a message is returned (as in >> the >> case of mDNS). >> >> One can then wonder whether the application protocol (e.g. mDNS) >> should take >> care of the staffled response or that an additional protocol needs to >> be >> specified. >> I have no opinion on the choice, but see the need for the one or the >> other. >> Coming with a recommendation (explanation) on the subject of returning >> responses (acks) would be my recommendation for the GroupComm >> document. >> >> Below some reactions on your reactions. Hope this helps to clarify >> misunderstandings. >> >> Peter >> >> Dijk, Esko schreef op 2012-12-19 14:24: >>> Hi Peter, >>> >>> still a fair number of comments! I would agree with most. Below I >>> have >>> selected some which we should discuss further, or ones I don’t agree >>> with: >>> >>> 1. Group communication definition -> >>> Why can't a source node be part of the group that it sends to? E.g. >>> combined sensor+luminaire use case. The IP stack would deliver sent >>> multicast CoAP requests also to the local application if it is >>> subscribed to the multicast IP address. >> source can of course be member of destination group. >> source may be part of the group (remove the "or may be not" part of >> the >> phrase) >>> >>> 2. I don’t see why we should add “the use of group communication for >>> mDNS is out of scope.” -> mDNS obviously is not CoAP, and the >>> document should define the scope anyway clearly as CoAP group >>> communication. So we don’t have to list any other protocols than >>> CoAP. >> See my answer on return of packets. I wanted a clear statement on >> (NOT) >> specifying how applications handle the return of MC responses. >> >>> >>> 3. “so setting a multicast address in a source at installation is >>> forbidden?” -> No, that should not be forbidden :) It should also be >>> possible to set a CoAP path and/or port at installation time. That >>> means the two presented measures have to change or be removed. >> No comment >>> >>> 4. “there are 2 ways: (1) the node queries to which group it belongs >>> or (2) an instalation tools instructs the node to which groups” -> >>> Good point. (2) has been chosen because it works without relying on a >>> service to query (e.g. DNS or RD). Is that sufficient argumentation? >>> The mechanism is optional in any case so it does not block others >>> from >>> defining a DNS or RD variant. >> I would point out both variants and mention that the draft focusses on >> (2) >>> >>> 5. “/s requests /s replies” -> >>> multicast replies (if you mean responses) do not exist in CoAP. It’s >>> about requests that should be carefully controlled since they >>> generate >>> unicast responses. >> Then I do not understand the text, because "request", "reply" and >> "response" >> are overloaded in my mind. >>> >>> 6. “/comment what about the reply?” -> based on core-coap “If the >>> request message is Non-confirmable, then the response SHOULD be >>> returned in a Non-confirmable message as well.” >>> . Do you think we should quote this from the core-coap spec? >> As explained above The subject of returning packets to the MC sender >> needs >> careful consideration. >> the response being NOn-confirmable does not solve a lot I am afraid. >>> >>> 7. “/comment invoking as many certificates?” -> >>> core-coap-13 now loosens the concept of authentication to also >>> include other measures, not needing certificates. >> No comment >>> >>> 8. Network configuration: 2 subnets vs 1 -> maybe a one-subnet >>> configuration is worth adding? Here an overview of present/absent use >>> cases: >>> >>> - Link-local CoAP multicast with responses: Present, Appendix A of >>> core-coap >>> - Site-local CoAP multicast, single subnet: >>> - Site-local CoAP multicast, multi subnet, with or without responses >>> (in the new -04 groupcomm): Present >>> - Global CoAP multicast, single or multi subnet, with or without >>> responses: / dependency on IANA IPv6 allocation >>> - any configurations with a central controller on the backbone >>> multicasting: >> >> Again, the draft should go for the most frequent use cases and not try >> to be >> complete. >> Actually explicitly excluding use cases looks ineresting to me. >>> >>> 9. “It might be useful if the practical impossibility of some >>> configurations is high lighted” -> any thoughts, which would be >>> impossible? >> During the coap meeting in Atlanta, Cullen Jennings presented some >> horrifying examples, as far as I remember. >> >>> >>> 10.“the RD discovery will be more complex when there is a router >>> between light-2 and switch” -> yes, there are issues in RD/discovery >>> especially when more than one is present in a network. >> So, adapt the use case and exclude this possibility. >>> >>> 11.“additional reason to remove router from the multicast >>> configuration”-> hmm, I think that we should opt for having a single >>> RD in the system to avoid complexity. Routers are ok. (One of our >>> goals is to define how CoAP groupcomm works even across routers) >> Looking forward to the supporting protocol. >>> >>> 12.“MLD is used to form groups, correct? but that was already done by >>> enabling the MC address in the lights (point 2)” -> Step 1 is >>> putting >>> the MC address in the lights, then step 2 is the Lights use MLD to >>> *ADVERTIZE* this address to any MLD-enabled Routers present >>> link-local. >>> So MLD is not a commissioning-time protocol but runs all the time >>> during operation. >>> Note that in groupcomm -04 we will remove MLD in the basic use case >>> and present it as an option later. >> >> Sounds good. The point is not to add protocols because they exist but >> because they are needed. >>> >>> 13.“WHY are the multicast destinations sending back results?” -> we >>> remove responses in the new -04 groupcomm. They are presented as an >>> optional thing that servers can do. >>> CoAP servers normally MUST respond to a request with a response >>> (core-coap-13) but an exception is now made for multicast where a >>> server MAY choose not to. This choice is completely independent from >>> confirmable/non-confirmable. Non-confirmable only means that an ACK >>> must not be sent. And an ACK is something different from a CoAP >>> response. >>> Agree that a protocol like MPL comes very close to ‘reliable >>> multicast’. >> >> see my worries at the beginning. >>> >>> Esko >>> >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Tuesday 18 December 2012 12:06 >>> To: akbar rahman; Dijk, Esko; Core >>> Subject: group-comm comments >>> >>> Hi Akbar and Esko, >>> >>> I had promised to review, comment the group comm draft. >>> >>> Below the commented text. >>> >>> I have not gone very detailed with my comments. I hope that it is >>> clear from my comments that a reorganization of the draft and a >>> review >>> of the uses cases are necessary to get a clearer picture of the >>> feasibility of group comm in the context of Coap. >>> >>> Especialy difficult to understand for me were: >>> >>> - the use case network configuration >>> >>> - the forming and enabling of groups >>> >>> - use of responses >>> >>> Hope this helps. >>> >>> Greetings, >>> >>> peter >>> >>> ______________________________________________________________________ >>> _______________________________ >>> >>> >>> Abstract >>> >>> CoAP is a RESTful transfer protocol for constrained devices. 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 document >>> >>> defines how the CoAP protocol should be used in a group >>> communication >>> >>> context. An approach for using CoAP on top of IP multicast is >>> >>> detailed for both constrained and un-constrained networks. Also, >>> >>> various use >>> >>> /s causes /s cases/ >>> >>> and corresponding protocol flows are provided to >>> >>> illustrate important concepts. Finally, guidance is provided for >>> >>> deployment in various network topologies. >>> >>> Status of this Memo >>> >>> This Internet-Draft is submitted in full conformance with the >>> >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> >>> Task Force (IETF). Note that other groups may also distribute >>> >>> working documents as Internet-Drafts. The list of current Internet- >>> >>> Drafts is at http://datatracker.ietf.org/drafts/current/ [1]. >>> >>> Internet-Drafts are draft documents valid for a maximum of six >>> months >>> >>> and may be updated, replaced, or obsoleted by other documents at any >>> >>> time. It is inappropriate to use Internet-Drafts as reference >>> >>> material or to cite them other than as "work in progress." >>> >>> This Internet-Draft will expire on April 22, 2013. >>> >>> Copyright Notice >>> >>> Copyright (c) 2012 IETF Trust and the persons identified as the >>> >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> >>> Provisions Relating to IETF Documents >>> >>> (http://trustee.ietf.org/license-info [2]) in effect on the date of >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 1] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> publication of this document. Please review these documents >>> >>> carefully, as they describe your rights and restrictions with >>> respect >>> >>> to this document. Code Components extracted from this document must >>> >>> include Simplified BSD License text as described in Section 4.e of >>> >>> the Trust Legal Provisions and are provided without warranty as >>> >>> described in the Simplified BSD License. >>> >>> 1. Conventions and Terminology >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>> >>> document are to be interpreted as described in [RFC2119]. >>> >>> This document assumes readers are familiar with the terms and >>> >>> concepts that are used in [I-D.ietf-core-coap]. In addition, this >>> >>> document defines the following terminology: >>> >>> Group Communication >>> >>> A source node sends a single message which is delivered to >>> >>> multiple destination nodes, where all destinations are identified >>> >>> to belong to a specific group. The source node may >>> >>> /remove or may not >>> >>> be >>> >>> part of the group. The underlying mechanism for group >>> >>> communication is assumed to be multicast based. >>> >>> /remove >>> >>> The network where >>> >>> the group communication takes place can be either a constrained >>> >>> or >>> >>> a regular (un-constrained) network/ >>> >>> /comment not sure about the meaning and consequences >>> >>> Multicast >>> >>> Sending a message to multiple destination nodes >>> >>> /s simultaneously./ >>> >>> /s with one network invocation / >>> >>> There are various options to implement multicast including layer >>> >>> 2 >>> >>> (Media Access Control) or layer 3 (IP) mechanisms. >>> >>> IP Multicast >>> >>> A specific multicast solution based on the use of IP multicast >>> >>> addresses as defined in "IANA Guidelines for IPv4 Multicast >>> >>> Address Assignments" [RFC5771] and "IP Version 6 Addressing >>> >>> Architecture" [RFC4291]. >>> >>> Low power and Lossy Network (LLN) >>> >>> Low power and Lossy Network (LLN): A type of constrained network >>> >>> where the devices are interconnected by a variety of low power, >>> >>> lossy links such as IEEE 802.15.4, Bluetooth, >>> >>> WiFi, wired >>> >>> or low >>> >>> power power-line communication links. >>> >>> 2. Introduction >>> >>> 2.1. Background >>> >>> The Constrained Application Protocol (CoAP) is an application >>> >>> protocol (analogous to HTTP) for resource constrained devices >>> >>> operating in an IP network [I-D.ietf-core-coap]. Constrained >>> >>> devices >>> >>> can be large in number, but are often highly correlated to each >>> >>> other >>> >>> (e.g. by type or location). For example, all the light switches in >>> >>> a >>> >>> building may belong to one group and all the thermostats may belong >>> >>> to another group. Groups may be composed by function. For example, >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 3] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> the group "all lights in building one" may consist of the groups >>> >>> "all >>> >>> lights on floor one of building one", "all lights on floor two of >>> >>> building one", etc. Groups may be preconfigured >>> >>> /add before deployment >>> >>> or dynamically >>> >>> formed >>> >>> /add during operation >>> >>> . If information needs to be sent to or received from a group >>> >>> of devices, group communication mechanisms can improve efficiency >>> >>> and >>> >>> latency of communication and reduce bandwidth requirements for a >>> >>> given application. HTTP does not support any equivalent >>> >>> functionality to CoAP group communication. >>> >>> 2.2. Scope >>> >>> In this draft, we address the issues related to CoAP group >>> >>> communication in detail, with use cases, recommended approaches and >>> >>> analysis of the impact to the CoAP protocol and to implementations. >>> >>> /add the use of group communication for mDNS is out of scope. >>> >>> The guiding principle is to apply wherever possible existing IETF >>> >>> protocols to achieve group communication functionality. In many >>> >>> cases the contribution of this document lies in explaining how >>> >>> existing mechanisms may be used to >>> >>> /remove together >>> >>> fulfill CoAP group >>> >>> communication needs for specific use cases. >>> >>> 2.3. Potential Solutions for Group Communication >>> >>> The classic concept of group >>> >>> /s communications /s communication >>> >>> is that of a single >>> >>> source distributing content to multiple destination recipients that >>> >>> are all part of a group. Before content can be distributed, there >>> >>> is >>> >>> a separate process to form the group. The source may be either a >>> >>> member or non-member of the group. >>> >>> Group communication solutions have evolved from "bottom" to "top", >>> >>> i.e., from layer 2 (Media Access Control broadcast/multicast) and >>> >>> layer 3 (IP multicast) to application layer group communication, >>> >>> also >>> >>> referred to as application layer multicast. A study published in >>> >>> 2005 [Lao05] identified new solutions in the "middle" (referred to >>> >>> as >>> >>> overlay multicast) that utilize an infrastructure based on proxies. >>> >>> Each of these classes of solutions may be compared [Lao05] using >>> >>> metrics such as link stress and level of host complexity >>> >>> [Banerjee01]. The results show for a realistic internet topology >>> >>> that IP Multicast is the most resource-efficient, with the downside >>> >>> being that it requires >>> >>> /s the most /s more organizational >>> >>> effort to deploy in the >>> >>> infrastructure. IP Multicast is the solution adopted by this draft >>> >>> for CoAP group communication. >>> >>> 3. CoAP Group Communication Based On IP Multicast >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 4] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> 3.1. IP Multicast Background >>> >>> IP Multicast routing protocols have been evolving for decades, >>> >>> resulting in proposed standards such as Protocol Independent >>> >>> Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various >>> >>> technical and marketing reasons, IP Multicast routing is not widely >>> >>> deployed on the general Internet. However, IP Multicast is very >>> >>> popular in specific deployments such as in enterprise networks (e.g. >>> >>> for video conferencing), smart home networks (e.g. UPnP/mDNS) and >>> >>> carrier IPTV deployments. The packet economy and minimal host >>> >>> complexity of IP multicast make it attractive for group >>> >>> communication >>> >>> in constrained environments. Therefore IP multicast is the >>> >>> recommended underlying mechanism for CoAP group communication, and >>> >>> the approach assumed in this document. >>> >>> To achieve IP multicast beyond a subnet, an IP multicast routing >>> >>> protocol needs to be active on routers. The RPL protocol [RFC6550] >>> >>> for example is able to route multicast traffic in constrained LLNs. >>> >>> While PIM-SM [RFC4601] is often used for multicast routing in un- >>> >>> constrained networks. >>> >>> IP multicast can also be run in a Link-Local (LL) scope. This means >>> >>> that there is no routing involved and an IP multicast message is >>> >>> only >>> >>> received >>> >>> /s on the network /s over the >>> >>> link on which it was sent. >>> >>> 3.2. CoAP Group Definition and Naming >>> >>> A group is defined as a set of CoAP endpoints, where each endpoint >>> >>> is >>> >>> configured to receive a multicast CoAP request that is sent to the >>> >>> group's associated IP multicast address. The group MAY have more >>> >>> than one associated IP multicast address. An endpoint MAY be a >>> >>> member of multiple groups. Group membership of an endpoint MAY >>> >>> dynamically change over time. The group MAY be identified by a >>> >>> Group >>> >>> Name ([I-D.vanderstok-core-dna]) which is defined as a prefix string >>> >>> of a Group FQDN. The Group FQDN can be uniquely mapped to a site- >>> >>> local or global multicast IP address via DNS resolution. >>> >>> A CoAP multicast request that addresses a group includes a Group URI >>> >>> as the request URI. A Group URI has the scheme 'coap' and includes >>> >>> in the authority part either a group IP address >>> >>> /add + optional port >>> >>> or a hostname >>> >>> /add + optional port >>> >>> that >>> >>> can be resolved to the group IP address (e.g., a Group Name or Group >>> >>> FQDN). Group URIs MUST follow the URI syntax [RFC3986]. >>> >>> A CoAP >>> >>> /s node /s end-point >>> >>> becomes a group member by listening for CoAP messages on >>> >>> the group's IP multicast address, assuming the default CoAP UDP >>> >>> port. >>> >>> Note that a non-default UDP port MAY be specified for the group; in >>> >>> which case implementers MUST ensure that all group members are >>> >>> configured to use this same port. >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 5] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Examples of hierarchical group naming (and scoping) for a building >>> >>> control application are shown below. >>> >>> URI authority Targeted group >>> >>> all.bldg6.example.com "all nodes in building 6" >>> >>> all.west.bldg6.example.com "all nodes in west wing, building >>> >>> 6" >>> >>> all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, >>> >>> building 6" >>> >>> all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, >>> >>> west wing, building 6" >>> >>> Reverse mapping (from IP multicast address to group FQDN) is >>> >>> supported using the reverse DNS resolution technique >>> >>> ([I-D.vanderstok-core-dna]). >>> >>> 3.3. Group Discovery and Member Discovery >>> >>> CoAP defines a resource discovery capability, but does not yet >>> >>> specify how to discover groups (e.g. find a group to join or send a >>> >>> multicast message to) or to discover members of a group (e.g. to >>> >>> address selected group members by unicast). These topics are >>> >>> elaborated in more detail in [I-D.vanderstok-core-dna] including >>> >>> examples for using DNS-SD and CoRE Resource Directory. >>> >>> 3.3.1. DNS-SD >>> >>> DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a >>> >>> conventional way to configure DNS PTR, SRV, and TXT records to >>> >>> enable >>> >>> enumeration of services, such as services offered by CoAP nodes, or >>> >>> enumeration of all CoAP nodes, within specified subdomains. A >>> >>> service is specified by a name of the form >>> >>> .., where the service type for CoAP >>> >>> nodes is _coap._udp and the domain is a DNS domain name that >>> >>> identifies a group as in the examples above. For each CoAP >>> >>> end-point >>> >>> in a group, a PTR record with the name _coap._udp and/or a PTR >>> >>> record >>> >>> with the name _coap._udp. is defined and it points to an SRV >>> >>> record having the .. name. >>> >>> All CoAP nodes in a given subdomain may be enumerated by sending a >>> >>> query for PTR records named _coap._udp to the authoritative DNS >>> >>> server for that zone. A list of SRV records is returned. Each SRV >>> >>> record contains the port and host name (AAAA record) of a CoAP node. >>> >>> The IP address of the node is obtained by resolving the host name. >>> >>> DNS-SD also specifies an optional TXT record, having the same name >>> >>> as >>> >>> the SRV record, which can contain "key=value" attributes. This can >>> >>> be used to store information about the device, e.g. schema=DALI, >>> >>> type=switch, group=lighting.bldg6, etc. >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 6] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Another feature of DNS-SD is the ability to specify service subtypes >>> >>> using PTR records. For example, one could represent all the CoAP >>> >>> groups in a subdomain by PTR records with the name >>> >>> _group._sub._coap._udp or alternatively >>> >>> _group._sub._coap._udp.. >>> >>> 3.3.2. CoRE Resource Directory >>> >>> CoRE Resource Directory [I-D.shelby-core-resource-directory] defines >>> >>> the concept of a Resource Directory (RD) server where CoAP servers >>> >>> can register their resources offered and CoAP clients can discover >>> >>> these resources by querying the RD server. RD syntax can be mapped >>> >>> to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], >>> >>> such that the above approach can be reused for group discovery and >>> >>> group member discovery. >>> >>> /remove Specifically, the Domain (d) parameter can be set to the >>> >>> group URI by >>> >>> an end-point registering to the RD. If an end-point wants to join >>> >>> multiple groups, it has to repeat the registration process for each >>> >>> group it wants to join. >>> >>> /end remove >>> >>> /comment d parameter semantics not clear >>> >>> 3.4. Group Resource Manipulation >>> >>> Group communications SHALL only be used for idempotent methods (i.e. >>> >>> CoAP GET, PUT, DELETE). The CoAP messages that are sent via >>> >>> multicast SHALL be Non-Confirmable. >>> >>> A unicast response per server MAY be sent back to answer the group >>> >>> request (e.g. response "2.05 Content" to a group GET request) taking >>> >>> into account the congestion control rules defined in >>> >>> [I-D.ietf-core-coap]. The unicast responses may be a mixture of >>> >>> success (e.g. 2.05 Content) and failure (e.g. 4.04 Not Found) codes >>> >>> depending on the individual server processing result. >>> >>> Group communications SHALL NOT be used for non-idempotent methods >>> >>> (i.e. CoAP POST). This is because not all group members are >>> >>> guaranteed to receive the multicast request, and the sender can not >>> >>> readily find out which group members did not receive it. >>> >>> All nodes in a given group SHOULD receive the same request >>> >>> /remove with high probability. >>> >>> /comment I don't see where probability comes in. >>> >>> This will not be the case if there is diversity in the >>> >>> authority port (i.e. a diversity of dynamic port addresses across >>> >>> the >>> >>> group) or if the targeted resource is located at different paths on >>> >>> different nodes. >>> >>> Therefore, some measures must be present to ensure uniformity in >>> >>> port >>> >>> number and resource names/locations within a group. This document >>> >>> proposes the following measures: >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 7] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> o All CoAP multicast requests MUST be sent either to the default >>> >>> CoAP UDP port (i.e. default Uri-Port as defined in >>> >>> [I-D.ietf-core-coap]), or to a port number obtained via a service >>> >>> discovery lookup operation as a valid CoAP port for the targeted >>> >>> multicast group. >>> >>> o All CoAP multicast requests SHOULD operate only on URIs (links) >>> >>> which were >>> >>> /s retreived /s retrieved >>> >>> either from a "/.well-known/core" lookup on >>> >>> at least one group member node, or from an equivalent service >>> >>> discovery lookup which returns either the resources supported by >>> >>> all group members or resources supported by one particular group >>> >>> member. >>> >>> /comment so setting a multicast address in a source at installation >>> is >>> >>> forbidden? >>> >>> 3.5. Configuring Group Membership In Endpoints >>> >>> In some use cases, the group membership of endpoints needs to be >>> >>> configurable after the network has been deployed. Example use cases >>> >>> can be found in building control: a commissioning tool determines to >>> >>> which groups a light or sensor node belongs, and writes this >>> >>> information to all nodes, which can subsequently join the correct >>> >>> group. >>> >>> To achieve smoother interoperability between nodes/endpoints from >>> >>> different manufacturers, it is proposed here to define an OPTIONAL >>> >>> standardized RESTful means of configuring CoAP endpoints with >>> >>> relevant group information. >>> >>> CoAP endpoints implementing this mechanism MUST support a >>> >>> discoverable "Group Configuration" resource of resource type (rt) >>> >>> [RFC6690] "core.gp". This resource (and perhaps its sub-resources, >>> >>> TBD) are used to manage group membership. Three design options for >>> >>> this mechanism are presented here as a placeholder (TBD). >>> >>> Design 1: use CoRE link format payloads to communicate group >>> >>> membership to endpoints. (TBD Not clear how this should be >>> >>> realized.) >>> >>> /comment, not clear what you mean either. Remove design 1 in this >>> state >>> >>> Design 2: use a JSON type resource. For example, a GET on the >>> >>> "core.gp" resource returns a JSON array of group objects. >>> >>> Req: GET /gp >>> >>> Res: 2.05 Content (Content-Format: application/json) >>> >>> [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", >>> >>> "ip": "ff05::4200:f7fe:ed37:14ca" } >>> >>> ] >>> >>> where "n" defines the Group FQDN and "ip" defines the associated >>> >>> multicast IP address. As a next example, the same endpoint can be >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 8] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> added to another group by a POST on the resource with a JSON group >>> >>> object: >>> >>> Req: POST /gp (Content-Format: application/json) >>> >>> { "n": "floor1.west.bldg6.example.com", >>> >>> "ip": "ff05::4200:f7fe:ed37:14cb" } >>> >>> Res: 2.04 Changed >>> >>> Design 3: define named sub-resources, each sub-resource representing >>> >>> a group membership. The payload of the sub-resource may be JSON or >>> >>> a >>> >>> simple pre-defined format. Or alternatively, information is >>> >>> provided >>> >>> via POST with query parameters. >>> >>> /comment are these mutually exclusive designs? >>> >>> /comment design 2 without JSON is als possible >>> >>> /comment design with SRV and TXt records is also possible >>> >>> /comment there are 2 ways: (1) the node queries to which group it >>> >>> belongs >>> >>> /comment (2) an instalation tools instructs the node to which groups >>> >>> it belongs >>> >>> /comment not clear in text that this choice exists or that a choice >>> was >>> >>> made. >>> >>> 3.6. Congestion Control >>> >>> Multicast CoAP requests may result in a multitude of replies from >>> >>> different nodes, potentially causing congestion. Therefore sending >>> >>> multicast >>> >>> /s requests /s replies >>> >>> should be conservatively controlled. >>> >>> The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific >>> >>> congestion risks through the following measures: >>> >>> o A server MAY choose not to respond to a multicast request if >>> >>> there's nothing useful to respond (e.g. error or empty response). >>> >>> o A server SHOULD limit the support for multicast requests to >>> >>> specific resources where multicast operation is required. >>> >>> o A multicast request MUST be Non-Confirmable. >>> >>> /comment what about the reply? >>> >>> o A server does not respond immediately to a multicast request, but >>> >>> SHOULD first wait for a time that is randomly picked within a >>> >>> predetermined time interval called the Leisure. >>> >>> o A server SHOULD NOT accept multicast requests that can not be >>> >>> authenticated. >>> >>> /comment invoking as many certificates? >>> >>> Additional guidelines to reduce congestion risks are: >>> >>> o A server in an LLN should only support multicast GET for >>> >>> resources >>> >>> that are small, e.g. >>> >>> /remove for an LLN that could mean >>> >>> the payload of the >>> >>> response fits into a single link-layer frame. >>> >>> o A server can minimize the payload length in response to a >>> >>> multicast GET on "/.well-known/core" by using hierarchy in >>> >>> arranging link descriptions for the response. An example of this >>> >>> is given in Section 5 of [RFC6690]. >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 9] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> o Preferably IP multicast with link-local scope should be used, >>> >>> rather than global or site-local. >>> >>> o The Hop Limit field in the IPv6 packet should be chosen as low as >>> >>> possible (if the CoAP/IP stack allows setting of this value. TBD >>> >>> - discuss whether this guideline is relevant/realistic in CoAP >>> >>> context) >>> >>> 3.7. CoAP Multicast and HTTP Unicast Interworking >>> >>> /comment a reference will suffice >>> >>> CoAP supports operation over UDP multicast, while HTTP does not. >>> >>> For >>> >>> use cases where it is required that CoAP group communication is >>> >>> initiated from an HTTP end-point, it would be advantageous if the >>> >>> HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group >>> >>> communication based on IP multicast. >>> >>> /remove One possible way of operation >>> >>> /remove of such HTTP-CoAP Proxy is illustrated in Figure 1. >>> >>> Note that this >>> >>> topic is covered in more detail in >>> >>> [I-D.castellani-core-advanced-http-mapping]. >>> >>> /remove >>> >>> CoAP Mcast CoAP Mcast HTTP-CoAP HTTP >>> >>> Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 >>> >>> | | | | | | >>> >>> |MLD REQUEST | | | | >>> >>> |(Join Group X) | | | | >>> >>> |--LL-->| | | | | >>> >>> | | |MLD REQUEST | | >>> >>> | | |(Join Group X) | | >>> >>> | | |--LL-->| | | >>> >>> | | | | | HTTP REQUEST | >>> >>> | | | | | (URI to | >>> >>> | | | | | unicast addr) | >>> >>> | | | | |< -----------------| >>> >>> | | | | | | >>> >>> | | | Resolve HTTP Request-Line URI | >>> >>> | | | to Group X multicast address | >>> >>> | | | | | | >>> >>> | CoAP REQUEST (to multicast addr)| | >>> >>> |< ------<---------<-------<------| | >>> >>> | | | | | | >>> >>> | | | | >>> >>> | (optional) CoAP RESPONSE(s) | | >>> >>> | |-------------->| | >>> >>> |-----------------|-------------->| Aggregated | >>> >>> | | | HTTP RESPONSE | >>> >>> | | |------------------>| >>> >>> | | | | >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 10] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Figure 1: CoAP Multicast and HTTP Unicast Interworking >>> >>> Note that Figure 1 illustrates the case of IP multicast as the >>> >>> underlying group communications mechanism. MLD denotes the >>> >>> Multicast >>> >>> Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a >>> >>> Link-Local multicast. >>> >>> A key point in Figure 1 is that the incoming HTTP Request (from node >>> >>> 3) will carry a Host request-header field that resolves in the >>> >>> general Internet to the proxy node. At the proxy node, this >>> >>> hostname >>> >>> and/or the Request-Line URI will then possibly be mapped (as >>> >>> detailed >>> >>> in [I-D.castellani-core-http-mapping]) and again resolved (with the >>> >>> CoAP scheme) to an IP multicast address. This may be accomplished, >>> >>> for example, by using DNS or DNS-SD (Section 3.3). The proxy node >>> >>> will then IP multicast the CoAP Request (corresponding to the >>> >>> received HTTP Request) via multicast routers to the appropriate >>> >>> nodes >>> >>> (i.e. nodes 1 and 2). >>> >>> In terms of the HTTP Response, Figure 1 illustrates that it will be >>> >>> generated by the proxy node based on aggregated responses of the >>> >>> CoAP >>> >>> nodes and sent back to the client in the general Internet that sent >>> >>> the HTTP Request (i.e. node 1). In >>> >>> [I-D.castellani-core-advanced-http-mapping] the HTTP Response that >>> >>> the Proxy may use to aggregate multiple CoAP responses is described >>> >>> in more detail. So in terms of overall operation, the CoAP proxy >>> >>> can >>> >>> be considered to be a "non-transparent" proxy according to >>> >>> [RFC2616]. >>> >>> Specifically, [RFC2616] states that a "non-transparent proxy is a >>> >>> proxy that modifies the request or response in order to provide some >>> >>> added service to the user agent, such as group annotation services, >>> >>> media type transformation, protocol reduction or anonymity >>> >>> filtering." >>> >>> An alternative to the above is using a Forward Proxy. In this case, >>> >>> the CoAP request URI is carried in the HTTP Request-Line (as defined >>> >>> in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the >>> >>> IP address of the Proxy. >>> >>> /end remove >>> >>> 4. Use Cases and Corresponding Protocol Flows >>> >>> 4.1. Introduction >>> >>> The use of CoAP group communication is shown in the context of the >>> >>> following use cases and corresponding protocol flows: >>> >>> o Discovery of Resource Directory: discovering the local CoRE RD >>> >>> which contains links (URIs) to resources stored on other servers >>> >>> [RFC6690]. >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 11] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> o Lighting Control: synchronous operation of a group of 6LoWPAN >>> >>> [RFC4944] IPv6-connected lights >>> >>> o Parameter Update: updating parameters/settings simultaneously in >>> >>> a >>> >>> large group of devices in a building/campus control >>> >>> ([I-D.vanderstok-core-bc]) application --- TBD >>> >>> / comment I suggest to remove Firmware Update and Groups status >>> report >>> >>> /comment the ones above are difficult enough, and I doubt that >>> >>> simultaneity >>> >>> /comment (motivation of multicast) is involved here >>> >>> o Firmware Update: efficiently updating firmware simultaneously in >>> >>> a >>> >>> large group of devices in a building/campus control >>> >>> ([I-D.vanderstok-core-bc]) application --- TBD suggests a >>> >>> multicast extension of core-block. >>> >>> o Group Status Report: requesting status information or event >>> >>> reports from a group of devices in a building/campus control >>> >>> application --- TBD, may require reliable group communication to >>> >>> be feasible. >>> >>> 4.2. Network Configuration >>> >>> We assume the following network configuration for all the use cases >>> >>> as shown in Figure 2: >>> >>> /comment the configurations frighten me >>> >>> /comment from completeness considerations I can imagine even more >>> >>> complex ones >>> >>> /comment It might be useful if the practical impossibility of some >>> >>> configurations is high lighted >>> >>> o A large room (Room-A) with three lights (Light-1, Light-2, >>> >>> Light-3) controlled by a Light Switch. The devices are organized >>> >>> into two 6LoWPAN subnets. >>> >>> /comment one subnet is enough for me >>> >>> /remove >>> >>> o Light-1 and the Light Switch are connected to a router (Rtr-1) >>> >>> which is also a CoAP Proxy, a CoAP Resource Directory (RD) and a >>> >>> 6LoWPAN Border Router (6LBR). >>> >>> o Light-2 and the Light-3 are connected to another router (Rtr-2) >>> >>> which is also a CoAP Proxy, a CoAP RD and a 6LBR. >>> >>> o The routers are connected to an IPv6 network backbone which is >>> >>> also multicast enabled. In the general case, this means the >>> >>> network backbone and 6LBRs support a PIM based multicast routing >>> >>> protocol, and MLD for forming groups. In a limited case, if the >>> >>> network backbone is one link, then the routers only have to >>> >>> support MLD-snooping (Appendix A) for the following use cases to >>> >>> work. >>> >>> /end remove >>> >>> /comment I can imagine that an central control is present on the >>> >>> backbone >>> >>> /comment switch or sensor send unicast to central control >>> >>> /comment central control sends multicast to multicast group within >>> >>> single lowpan >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 12] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Network >>> >>> Backbone >>> >>> | >>> >>> ################################################ >>> >>> | >>> >>> # Room-A # >>> >>> | >>> >>> # ********************** # >>> >>> | >>> >>> # ** LoWPAN-1 (subnet-1) ** # >>> >>> | >>> >>> # * * # >>> >>> | >>> >>> # * +----------+ * # >>> >>> | >>> >>> # * | Light |-------+ * # >>> >>> | >>> >>> # * | Switch | | * # >>> >>> | >>> >>> # * +----------+ +---------+ * # >>> >>> | >>> >>> # * | Rtr-1 >>> >>> |-----------------------------| >>> >>> # * +---------+ * # >>> >>> | >>> >>> # * +----------+ | * # >>> >>> | >>> >>> # * | Light-1 |--------+ * # >>> >>> | >>> >>> # * +----------+ * # >>> >>> | >>> >>> # * * # >>> >>> | >>> >>> # ** ** # >>> >>> | >>> >>> # ********************** # >>> >>> | >>> >>> # # >>> >>> | >>> >>> # # >>> >>> | >>> >>> # ********************** # >>> >>> | >>> >>> # ** LoWPAN-2 (subnet-2) ** # >>> >>> | >>> >>> # * * # >>> >>> | >>> >>> # * +----------+ * # >>> >>> | >>> >>> # * | Light-2 |-------+ * # >>> >>> | >>> >>> # * | | | * # >>> >>> | >>> >>> # * +----------+ +---------+ * # >>> >>> | >>> >>> # * | Rtr-2 >>> >>> |-----------------------------| >>> >>> # * +---------+ * # >>> >>> | >>> >>> # * +----------+ | * # >>> >>> | >>> >>> # * | Light-3 |--------+ * # >>> >>> | >>> >>> # * +----------+ * # >>> >>> | >>> >>> # * * # >>> >>> | >>> >>> # ** ** # >>> >>> | >>> >>> # ********************** # >>> >>> | >>> >>> # # >>> >>> | >>> >>> ################################################# >>> >>> | >>> >>> | >>> >>> +--------+ >>> >>> | >>> >>> | DNS >>> >>> |------------------| >>> >>> | Server | >>> >>> +--------+ >>> >>> Figure 2: Network Topology of a Large Room (Room-A) >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 13] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> 4.3. Discovery of Resource Directory >>> >>> The protocol flow for discovery of a RD for the given network (of >>> >>> Figure 2) is shown in Figure 3: >>> >>> o The fixture for Light-2 is installed and powered on for the first >>> >>> time. >>> >>> o Light-2 will then search for the local RD (RD-2) by sending out a >>> >>> GET request (with the "/.well-known/core?rt=core.rd" request URI) >>> >>> to the site-local "All CoAP Nodes" address. In this case, the >>> >>> site is assumed to include all nodes in the subnet. >>> >>> o This multicast message will then go to each node in subnet-2. >>> >>> However, only Rtr-2 (RD-2) will respond because the GET is >>> >>> qualified by the query string "?rt=core.rd". >>> >>> o Note that the flow is shown only for Light-2 for clarity. >>> >>> Similar >>> >>> flows will happen for Light-1, Light-3 and the Light Switch when >>> >>> they are first powered on. >>> >>> The RD may also be discovered by other means such as by assuming a >>> >>> default location (e.g. on a 6LBR), using DHCP, anycast address, etc. >>> >>> However, these approaches do not invoke CoAP group communication so >>> >>> are not further discussed here. >>> >>> For other discovery use cases such as discovering local CoAP >>> >>> servers, >>> >>> services or resources group communication can be used in a similar >>> >>> fashion as in the above use case. Both Link-Local (LL) and site- >>> >>> local discovery are possible this way. >>> >>> /comment the RD discovery will be more complex when there is a router >>> >>> between light-2 and switch >>> >>> /comment Via which RD will light switch discover light-2? >>> >>> /comment additional reason to remove router from the multicast >>> >>> configuration >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 14] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Light Rtr-1 Rtr-2 >>> >>> Network >>> >>> Light-1 Light-2 Light-3 Switch (RD-1) (RD-2) >>> >>> Backbone >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> ********************************** | | | >>> >>> * Light-2 is installed * | | | >>> >>> * and powers on for first time * | | | >>> >>> ********************************** | | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | COAP NON (GET | | >>> >>> | | /.well-known/core?rt=core.rd) | | >>> >>> | |--------->-------------------------------->| | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | COAP NON (2.05 Content | | >>> >>> | | ;rt="core.rd";ins="Primary") | | >>> >>> | |<------------------------------------------| | >>> >>> | | | | | | | >>> >>> Figure 3: Resource Directory Discovery via Multicast Message >>> >>> 4.4. Lighting Control >>> >>> /comment I am confused about the use of protocols >>> >>> /comment MLD is used to form groups, correct? >>> >>> /comment but that was already done by enabling the MC address in the >>> >>> lights (point 2) >>> >>> /comment There are several ways to set up groups, pointing them out >>> and >>> >>> when to use them would be an asset. >>> >>> The protocol flow for a building automation lighting control >>> >>> scenario >>> >>> for the network (Figure 2) is shown in sequence in Figure 4, >>> >>> Figure 5, and Figure 6. We assume the following steps occur before >>> >>> the illustrated flow: >>> >>> o 1) Startup phase: 6LoWPANs are formed. IPv6 addresses assigned >>> >>> to >>> >>> all devices. The CoAP network is formed. >>> >>> o 2) Commissioning phase (by applications): The IP multicast >>> >>> address >>> >>> of the group (Room-A-Lights) has been >>> >>> /s set /s enable >>> >>> in all the Lights. The >>> >>> URI of the group (Room-A-Lights) has been >>> >>> /s set /s resolved >>> >>> in the Light Switch. >>> >>> o 3) The indicated MLD Report messages are link-local multicast. >>> >>> In >>> >>> each LoWPAN, it is assumed that a multicast routing/forwarding >>> >>> protocol in 6LRs will then propagate the Join information >>> >>> contained in the MLD Report over multiple hops to the 6LBR. >>> >>> /comment Don't see the need >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 15] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Light Rtr-1 Rtr-2 >>> >>> Network >>> >>> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >>> >>> Backbone >>> >>> | | | | Proxy) Proxy) | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | MLD Report: Join | | | | | >>> >>> | Group (Room-A-Lights) | | | | >>> >>> |---LL------------------------------------->| | | >>> >>> | | | | |MLD Report: Join | >>> >>> | | | | |Group (Room-A-Lights)| >>> >>> | | | | |---LL--------------->| >>> >>> | | | | | | | >>> >>> | | MLD Report: Join | | | | >>> >>> | | Group (Room-A-Lights) | | | >>> >>> | |---LL------------------------------------->| | >>> >>> | | | | | | | >>> >>> | | | MLD Report: Join | | | >>> >>> | | | Group (Room-A-Lights) | | >>> >>> | | |---LL-------------------------->| | >>> >>> | | | | | | | >>> >>> | | | | |MLD Report: Join | >>> >>> | | | | |Group (Room-A-Lights)| >>> >>> | | | | | |---LL---->| >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> Figure 4: Joining Lighting Groups Using MLD >>> >>> /comment possibly remove from text, or do separate section on use of >>> >>> MLD >>> >>> /comment anyway separating commissioning from operation in separate >>> >>> sections is a good idea. >>> >>> /comment the proxies are a complication in the picture not elaborated >>> >>> in the text. >>> >>> /comment the subject of proxies is another one, to be treated >>> >>> elsewhere. >>> >>> /comment also for proxies the do's and don't's from a simple >>> >>> performance perspective will be interesting >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 16] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Light Rtr-1 Rtr-2 >>> >>> Network >>> >>> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >>> >>> Backbone >>> >>> | | | | Proxy) Proxy) | >>> >>> | | | | | | | >>> >>> | | *********************** | | >>> >>> | | * User flips on * | | >>> >>> | | * light switch to * | | >>> >>> | | * turn on all the * | | >>> >>> | | * lights in Room A * | | >>> >>> | | *********************** | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | COAP NON (PUT | | | >>> >>> | | | Proxy-URI | | | >>> >>> | | | URI for Room-A-Lights | >>> >>> | | | Payload=turn on lights) | >>> >>> | | | |--------->| | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | | Request DNS resolution of | >>> >>> | | | | URI for Room-A-Lights | >>> >>> | | | | |-------------------->| >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | | DNS returns: AAAA | >>> >>> | | | | Group (Room-A-Lights) | >>> >>> | | | | IPv6 multicast address | >>> >>> | | | | |<--------------------| >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | COAP NON (Put | >>> >>> | | | | URI Path | >>> >>> | | | | Payload=turn on lights)| >>> >>> | | | | Destination IP Address = | >>> >>> | | | | IP multicast address | >>> >>> | | | | for Group (Room-A-Lights)| >>> >>> | | | | Originating IP Address = | >>> >>> | | | | RTR-1 | >>> >>> | | | | |-------------------->| >>> >>> |<------------------------------------------| | | >>> >>> | | | | | | | >>> >>> | | | | | |<---------| >>> >>> | |<---------|<-------------------------------| | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> Figure 5: Sending Lighting Control Multicast Message >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 17] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Light Rtr-1 Rtr-2 >>> >>> Network >>> >>> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >>> >>> Backbone >>> >>> | | | | Proxy) Proxy) | >>> >>> | | | | | | | >>> >>> *********************** | | | | >>> >>> * Lights in Room-A * | | | | >>> >>> * turn on (nearly * | | | | >>> >>> * simultaneously) * | | | | >>> >>> *********************** | | | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | COAP NON (2.04 Changed) | | | | >>> >>> |------------------------------------------>| | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | COAP NON (2.04 Changed) | | | >>> >>> | |------------------------------->| | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | COAP NON (5.00 Internal Server Error) | >>> >>> | | |-------------------->| | | >>> >>> | | | | | | | >>> >>> | | | ****************************** | >>> >>> | | | * Rtr-1 as CoAP Proxy * | >>> >>> | | | * | sends the individual * | >>> >>> | | | * | responses back to * | >>> >>> | | | * v originator * | >>> >>> | | | ****************************** | >>> >>> | | | | | | | >>> >>> | | | COAP NON (2.04 Changed) | | >>> >>> | | | |<---------| | | >>> >>> | | | | | | | >>> >>> | | | COAP NON (2.04 Changed) | | >>> >>> | | | |<---------| | | >>> >>> | | | | | | | >>> >>> | | | COAP NON (5.00 Internal Server Error) | >>> >>> | | | |<---------| | | >>> >>> | | | | | | | >>> >>> Figure 6: Sending Lighting Control Response to Multicast Message >>> >>> NOTE: In the last step of Figure 6, Rtr-1 acting as CoAP proxy, >>> >>> returns multiple individual CoAP responses to the client. Each >>> >>> response echoes the Token of the client's request. The client can >>> >>> identify the original source of each response by ...TBD. >>> >>> /comment WHY are the multicast destinations sending back results? >>> >>> /comment I thought that you wanted MC messages to be non confirmable >>> >>> /comment sending responses seems to contradict this . >>> >>> /comment please remove sending back of responses. >>> >>> /comment one may assume that the MC algorithm within the lowpan is >>> >>> reliable (all destinations receive the message) >>> >>> /comment anyway MPL comes close enough to the reliability requirement >>> >>> given a specifiable range of configurations >>> >>> ______________________________________________________________________ >>> _____________________________________________________ >>> >>> >>> -- >>> >>> Peter van der Stok >>> >>> mailto: consultancy@vanderstok.org >>> >>> www: www.vanderstok.org [3] >>> >>> tel NL: +31(0)492474673 F: +33(0)966015248 >>> >>> ------------------------- >>> The information contained in this message may be confidential and >>> legally protected under applicable law. The message is intended >>> solely >>> for the addressee(s). If you are not the intended recipient, you are >>> hereby notified that any use, forwarding, dissemination, or >>> reproduction of this message is strictly prohibited and may be >>> unlawful. If you are not the intended recipient, please contact the >>> sender by return e-mail and destroy all copies of the original >>> message. >>> >>> >>> Links: >>> ------ >>> [1] http://datatracker.ietf.org/drafts/current/ >>> [2] http://trustee.ietf.org/license-info >>> [3] http://www.vanderstok.org >> >> ________________________________ >> The information contained in this message may be confidential and >> legally >> protected under applicable law. The message is intended solely for the >> addressee(s). If you are not the intended recipient, you are hereby >> notified >> that any use, forwarding, dissemination, or reproduction of this >> message is >> strictly prohibited and may be unlawful. If you are not the intended >> recipient, please contact the sender by return e-mail and destroy all >> copies >> of the original message. >> _______________________________________________ >> 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 From cabo@tzi.org Tue Nov 5 08:13:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AE521E825D for ; Tue, 5 Nov 2013 08:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZLNN8dR-SMU for ; Tue, 5 Nov 2013 08:12:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D4B1821E8249 for ; Tue, 5 Nov 2013 08:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA5GCaMb024931; Tue, 5 Nov 2013 17:12:36 +0100 (CET) Received: from dhcp-956b.meeting.ietf.org (dhcp-956b.meeting.ietf.org [31.133.149.107]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1ADD241F; Tue, 5 Nov 2013 17:12:33 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <8e1539df1fad55638a5399a3d3ca0b9f@xs4all.nl> Date: Tue, 5 Nov 2013 08:12:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3B0D81D9-BC1C-4280-BB4B-442FB454D719@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> <00bc875979c9100652c83cc262a26dac@xs4all.nl> <958625B0F6EC4C44B0E146CD46E4ABBD@WeiGengyuPC> <8e1539df1fad55638a5399a3d3ca0b9f@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.1816) Cc: core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:13:04 -0000 On 05 Nov 2013, at 07:34, peter van der Stok wrote: > As far as I know algorithms exist, but I don't know about = standardization. Reliable multicast has a long history in the IETF. It is not an easy problem, so there even was an IRTF research group for = it: http://irtf.org/concluded/rmrg The RMT (reliable multicast transport) working group has concluded in = 2006: http://tools.ietf.org/wg/rmt/ The main standards document to look at is RFC5401 in conjunction with = RFC 5740 (NORM). Another output of the RMRG, RFC 3208 (PGM) has never been advanced to = the standards track, but enjoys some deployment. Other approaches such = as RFC 6726 (FLUTE, File Delivery over Unidirectional Transport) are = more oriented towards content distribution. None of these attempt to achieve group-wide consistency. RFC 1301 did, = as did follow-on proposals such as draft-bormann-mtp-so, but there are = strong limitations. If you really need this, you are looking for = algorithms such as Paxos: http://en.wikipedia.org/wiki/Paxos_(computer_science) More generally speaking, the CAP theorem applies: http://en.wikipedia.org/wiki/CAP_theorem I.e., you only get at most two out of the three: =95 Consistency (all nodes see the same data at the same time) =95 Availability (a guarantee that every request receives a response = about whether it was successful or failed) =95 Partition tolerance (the system continues to operate despite = arbitrary message loss or failure of part of the system) Because of the complexity of the subject, CoRE is explicitly chartered = not to attempt work on Reliable Multicast: =BBThe working group will not = develop a reliable multicast solution, [=85]=AB. https://datatracker.ietf.org/wg/core/charter/ Gr=FC=DFe, Carsten From cabo@tzi.org Tue Nov 5 08:27:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E7011E8212 for ; Tue, 5 Nov 2013 08:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWcrHQlyNTSY for ; Tue, 5 Nov 2013 08:27:20 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B791611E81D2 for ; Tue, 5 Nov 2013 08:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA5GR8T4022938; Tue, 5 Nov 2013 17:27:09 +0100 (CET) Received: from dhcp-956b.meeting.ietf.org (dhcp-956b.meeting.ietf.org [31.133.149.107]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BA3F443E; Tue, 5 Nov 2013 17:27:05 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <3B0D81D9-BC1C-4280-BB4B-442FB454D719@tzi.org> Date: Tue, 5 Nov 2013 08:27:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9E6D1E64-AA22-4AFD-9027-641C65380864@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> <00bc875979c9100652c83cc262a26dac@xs4all.nl> <958625B0F6EC4C44B0E146CD46E4ABBD@WeiGengyuPC> <8e1539df1fad55638a5399a3d3ca0b9f@xs4all.nl> <3B0D81D9-BC1C-4280-BB4B-442FB454D719@tzi.org> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.1816) Cc: core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:27:26 -0000 On 05 Nov 2013, at 08:12, Carsten Bormann wrote: > concluded in 2006 Oops, hit send too quickly; make that 2013. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Nov 5 15:57:12 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8662411E8125 for ; Tue, 5 Nov 2013 15:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.369 X-Spam-Level: X-Spam-Status: No, score=-106.369 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn39qci635Cz for ; Tue, 5 Nov 2013 15:57:06 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4C54711E811A for ; Tue, 5 Nov 2013 15:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA5Nv4Sk004298 for ; Wed, 6 Nov 2013 00:57:04 +0100 (CET) Received: from dhcp-9c96.meeting.ietf.org (dhcp-9c96.meeting.ietf.org [31.133.156.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 329285DB; Wed, 6 Nov 2013 00:57:01 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Nov 2013 15:56:57 -0800 To: core Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) X-Mailer: Apple Mail (2.1816) Subject: [core] Meeting summary CoRE IETF88 (part 1) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:57:12 -0000 CoRE met for its first slot on Monday, 2013-11-04. Work is proceeding on the standards-track draft-ietf-core-observe and draft-ietf-core-block, as well as the informational draft-ietf-core-groupcomm and draft-ietf-core-http-mapping, with specific points raised to be handlded by the editors. We expect to submit -observe to the IESG this month, with -block on its heels. Work on draft-ietf-core-resource-directory is resuming, with some charter updating required. The new proposal draft-tcs-coap-no-response-option-04 received favorable reception and further work required before adoption was identified, in particular with respect to exploring the duality with -observe. CoRE will meet again on Thursday, 2013-11-07, 15:20=9617:20. Gr=FC=DFe, Carsten From bergmann@tzi.org Tue Nov 5 17:43:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B31821F9D96 for ; Tue, 5 Nov 2013 17:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJkQEJxHgpUk for ; Tue, 5 Nov 2013 17:43:44 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E8EDD11E81D0 for ; Tue, 5 Nov 2013 17:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA61gaiN000184 for ; Wed, 6 Nov 2013 02:42:36 +0100 (CET) Received: from aung.tzi.org (dhcp-9864.meeting.ietf.org [31.133.152.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3CD0B5F2 for ; Wed, 6 Nov 2013 02:42:36 +0100 (CET) From: Olaf Bergmann To: core@ietf.org Date: Wed, 06 Nov 2013 02:42:33 +0100 Message-ID: <87li128fw6.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [core] Summary of Core AA use-cases meeting Nov 5, 2013 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:43:50 -0000 Today, a group of people who are interested in documenting use-cases for authorization in the Internet of Things have got together and discussed the way forward. The participants agreed that the existing drafts provide a sufficient coverage of relevant use-cases. The next step is to merge these drafts into a single document and identify those use-cases that facilitate understanding of the problem space. Intended status of this document is informational RFC. Nine of the eleven attending people volunteered to contribute. Gruesse Olaf From weigengyu@bupt.edu.cn Tue Nov 5 19:25:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ADC21E80CA for ; Tue, 5 Nov 2013 19:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnk4Kka3Nqvs for ; Tue, 5 Nov 2013 19:25:16 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id BF39621E80C9 for ; Tue, 5 Nov 2013 19:25:14 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id D263119F36A; Wed, 6 Nov 2013 11:25:12 +0800 (HKT) Message-ID: <270AD365740547C1B9F081BD43C30DD3@WeiGengyuPC> From: "weigengyu" To: "Carsten Bormann" , References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> <00bc875979c9100652c83cc262a26dac@xs4all.nl> <958625B0F6EC4C44B0E146CD46E4ABBD@WeiGengyuPC> <8e1539df1fad55638a5399a3d3ca0b9f@xs4all.nl> <3B0D81D9-BC1C-4280-BB4B-442FB454D719@tzi.org> In-Reply-To: <3B0D81D9-BC1C-4280-BB4B-442FB454D719@tzi.org> Date: Wed, 6 Nov 2013 11:25:12 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 03:25:19 -0000 Hi, Carsten, Thank you for the information. > Because of the complexity of the subject, CoRE is explicitly chartered not > to attempt work on Reliable Multicast: > »The working group will not develop a reliable multicast solution, > […]«.https://datatracker.ietf.org/wg/core/charter/ Regards, Gengyu Network Technology Center, School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Wednesday, November 06, 2013 12:12 AM To: consultancy@vanderstok.org Cc: weigengyu ; core Subject: Re: [core] group-comm comments On 05 Nov 2013, at 07:34, peter van der Stok wrote: > As far as I know algorithms exist, but I don't know about standardization. Reliable multicast has a long history in the IETF. It is not an easy problem, so there even was an IRTF research group for it: http://irtf.org/concluded/rmrg The RMT (reliable multicast transport) working group has concluded in 2006: http://tools.ietf.org/wg/rmt/ The main standards document to look at is RFC5401 in conjunction with RFC 5740 (NORM). Another output of the RMRG, RFC 3208 (PGM) has never been advanced to the standards track, but enjoys some deployment. Other approaches such as RFC 6726 (FLUTE, File Delivery over Unidirectional Transport) are more oriented towards content distribution. None of these attempt to achieve group-wide consistency. RFC 1301 did, as did follow-on proposals such as draft-bormann-mtp-so, but there are strong limitations. If you really need this, you are looking for algorithms such as Paxos: http://en.wikipedia.org/wiki/Paxos_(computer_science) More generally speaking, the CAP theorem applies: http://en.wikipedia.org/wiki/CAP_theorem I.e., you only get at most two out of the three: • Consistency (all nodes see the same data at the same time) • Availability (a guarantee that every request receives a response about whether it was successful or failed) • Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system) Because of the complexity of the subject, CoRE is explicitly chartered not to attempt work on Reliable Multicast: »The working group will not develop a reliable multicast solution, […]«. https://datatracker.ietf.org/wg/core/charter/ Grüße, Carsten From weigengyu@bupt.edu.cn Tue Nov 5 19:37:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3967911E81FD for ; Tue, 5 Nov 2013 19:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGIhLcQHj6RR for ; Tue, 5 Nov 2013 19:37:43 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id D426D11E81F8 for ; Tue, 5 Nov 2013 19:37:41 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 4328819F3B7; Wed, 6 Nov 2013 11:37:39 +0800 (HKT) Message-ID: <75D5A26F0BF94F04B9BE8CD017F1E7F4@WeiGengyuPC> From: "weigengyu" To: "Carsten Bormann" , References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> <00bc875979c9100652c83cc262a26dac@xs4all.nl> <958625B0F6EC4C44B0E146CD46E4ABBD@WeiGengyuPC> <8e1539df1fad55638a5399a3d3ca0b9f@xs4all.nl> <3B0D81D9-BC1C-4280-BB4B-442FB454D719@tzi.org> <9E6D1E64-AA22-4AFD-9027-641C65380864@tzi.org> In-Reply-To: <9E6D1E64-AA22-4AFD-9027-641C65380864@tzi.org> Date: Wed, 6 Nov 2013 11:37:39 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 03:37:59 -0000 Hi, Carsten, If you read the RFCs and the charter that concluded in 2006, you would know that are about transport layer reliable multicast. I think that transport layer reliable multicast is not suitable for CoRE. CoAP does reliable unicast itself. CoAP groupcomm is without reliable capability. Many CoRE applications require reliable multicast. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Wednesday, November 06, 2013 12:27 AM To: consultancy@vanderstok.org Cc: weigengyu ; core Subject: Re: [core] group-comm comments On 05 Nov 2013, at 08:12, Carsten Bormann wrote: > concluded in 2006 Oops, hit send too quickly; make that 2013. Grüße, Carsten From weigengyu@bupt.edu.cn Tue Nov 5 19:40:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC5921E8117 for ; Tue, 5 Nov 2013 19:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FujRq+jvA+8k for ; Tue, 5 Nov 2013 19:39:59 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id ABCE521E8104 for ; Tue, 5 Nov 2013 19:39:58 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id DA63A19F3AE for ; Wed, 6 Nov 2013 11:39:57 +0800 (HKT) Message-ID: <8CE01D87EA2A453F83B97570103C1024@WeiGengyuPC> From: "weigengyu" To: Date: Wed, 6 Nov 2013 11:39:56 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Subject: [core] Fw: group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 03:40:03 -0000 Hi, Perter, Comments inlines. > It involved a limited number of receivers which are not too far removed > from the source. In a hospital, it does. But if one healthcare center or clinical monitors many servers across a residence community, the number of servers may be more than ten thausands or one handred thausands. > You would look for a 2-phase commit style of multicast, I expect. > Only when all receivers received the message, can commit take place > otherwise, abort. > Is that correct? The considered usecase includes collecting data request (1-to-N) and responses (N x [1-to-1]). That is something different from two-phase commit which is a typical database consistency algorithm in distributed systems. > This is a very different approach from the MPL one or the video streaming > one. Something like, I think. I think that the proxy-based approach would be an alternative in the environments like CoRE. While the reliable multicast could provide by transport layer or application layer, I do not think the transport layer reliable multicast is suitable for CoRE. Regards, Gengyu > Network Technology Center, > School of Computer > Beijing University of Posts & Telecommunications -----原始邮件----- From: peter van der Stok Sent: Tuesday, November 05, 2013 11:34 PM To: weigengyu Cc: consultancy@vanderstok.org ; core@ietf.org Subject: Re: [core] group-comm comments Hi Gengyu. The medical case is a bit familiar to me. It involved a limited number of receivers which are not too far removed from the source. You would look for a 2-phase commit style of multicast, I expect. Only when all receivers received the message, can commit take place otherwise, abort. Is that correct? This is a very different approach from the MPL one or the video streaming one. As far as I know algorithms exist, but I don't know about standardization. Peter weigengyu schreef op 2013-11-05 05:19: > Hi，Peter, > > Thank you for your reply. > >> Does that partially answer your question for wireless meshes? > Yes. > > "With the choice of the density of MPL forwarders and the number of > repetitions by MPL forwarders", > could help provide the multicast capability near to reliable. > > While Unreliable multicast is requried for many senarios, the current > groupcomm draft can meet these requirements. > > But there are really some senarios, such as mobile healthcare, in-home > switch control etcs, that need the reliable multicast. > I wish that the CoAP groupcomm might evole to cover the CoAP reliable > multicast at next stage. > > regards, > > Gengyu > > Network Technology Center, > School of Computer > Beijing University of Posts & Telecommunications > > > -----原始邮件----- From: peter van der Stok > Sent: Monday, November 04, 2013 12:42 PM > To: weigengyu > Cc: Rahman, Akbar ; Core ; Dijk, Esko ; consultancy@vanderstok.org > Subject: Re: [core] group-comm comments > > Hi Weigenyu, > > With the choice of the density of MPL forwarders and the number of > repetitions by MPL forwarders it is possible to estimate the reliability > of the MPL multicast as function of the single transmission failure rate > under a range of network loads. > > Does that partially answer your question for wireless meshes? > > Peter > > > > weigengyu schreef op 2013-11-04 05:28: >> Hi Akbar, >> >> Thank you for your reply. >> >>> Reliable multicast is not supported. >>> We can perhaps make this more clear by adding a sentence in the Scope >>> (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). >> >> I belive it is required. >> I have misunderstood that it provides unreliable multicast just for >> the use case of Light Switch Control. >> >> And, I also want to ask the List, >> has anyone considered or been interested in CoAP Reliable Groupcomm or >> CoAP reliable multicast? >> >> Regards, >> >> Gengyu >> >> Network Technology Center >> School of Computer >> Beijing University of Posts & Telecommunications >> >> >> -----原始邮件----- From: Rahman, Akbar >> Sent: Sunday, November 03, 2013 10:56 PM >> To: weigengyu >> Cc: Core ; Dijk, Esko ; consultancy@vanderstok.org >> Subject: RE: [core] group-comm comments >> >> Hi Gengyu, >> >> >> Just some quick feedback. The groupcomm draft assumes only unreliable >> (i.e. not guaranteed) IP multicast. This is specified in >> >> http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.4 >> (see 1st paragraph) >> >> and >> >> http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-3.4 >> (see 3rd paragraph) >> >> >> Reliable multicast is not supported. We can perhaps make this more >> clear by adding a sentence in the Scope >> (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2). >> >> >> >> Thanks for your review, >> >> >> Akbar >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf >> Of weigengyu >> Sent: Saturday, November 02, 2013 9:16 AM >> To: Dijk, Esko; consultancy@vanderstok.org >> Cc: Core >> Subject: Re: [core] group-comm comments >> >> Hi, Esko >> >> I would like to give some comments on the GROUP-COMM draft. >> >> There have use cases for reliable and unreliable multicast >> communications. >> If this draft only for providing unreliable multicast over IP multicast, >> it >> is OK; just write it clearly. >> >> If the draft intends to have the reliable or partial multicast facility, >> the dtaft needs to give what mechanisms can gurantte that. >> >> The draft should define mechnisms that the server can register its >> capability of supporting multicast, >> this may be put to RD server; >> and wether to request reliable groupcomm shoule be the client's request. >> >>> To clarify: under the assumption that a server MAY respond to a >>> multicast >>> request, >> A mechanism is required to make the server registers its capability. i.e. >> whether to support multicast; >> >>> and the client doesn't know a priori how many servers will respond to a >>> multicast, >> The client may lookup the information from the RD server (if the rerver's >> registeration processe were possible); >> >>> (since there are no guidelines/rules for that), the safest thing to do >>> is >>> not send the multicast in the first place. >> If not first, when to make available? >> So, whether it is required should be determined by the client request, >> and >> there should have some authority or priority control to client. >> >>> Therefore the advice is to carefully control sending of multicast >>> requests. >> Not only to tell that, the draft should have clear descriptions about how >> the protocol supports multicast requiests and/or reliable multicast when >> required. >> >> regards, >> >> Gengyu >> >> Network Technology Center >> School of Computer >> Beijing University of Posts & Telecommunications >> >> -----原始邮件----- From: Dijk, Esko >> Sent: Thursday, December 20, 2012 6:56 PM >> To: consultancy@vanderstok.org >> Cc: Core >> Subject: Re: [core] group-comm comments >> >> Thanks Peter, >> >> I would agree we need to include guidelines on returning of responses to >> CoAP multicast requests. (Note the CoAP spec ensures that a CoAP server >> will >> never ACK a multicast but that does not help a thing if it still sends a >> response packet...) I'll make a ticket for this. If anyone disagrees >> we'll >> hear it. >> >>> Then I do not understand the text, because "request", "reply" and >>> "response" are overloaded in my mind. >> To clarify: under the assumption that a server MAY respond to a multicast >> request, and the client doesn't know a priori how many servers will >> respond >> to a multicast, (since there are no guidelines/rules for that), the >> safest >> thing to do is not send the multicast in the first place. Therefore the >> advice is to carefully control sending of multicast requests. >> >> Esko >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Thursday 20 December 2012 11:26 >> To: Dijk, Esko >> Cc: consultancy@vanderstok.org; akbar rahman; Core >> Subject: RE: group-comm comments >> >> >> Hi Esko, >> >> thanks for your reactions. I will group my answers, to better explain my >> points on the return of packets to MC senders. >> >> 1) Return of packets to multicast >> >> As I understand the multicast message is preferably sent with no >> confirmation (ack) because the return of all the acks may overwhelm the >> network and the sender of the multicast. >> The acknowledgement is not needed for MPL as the protocol has all the >> machinery to assure that all destinations receive it, (given constraints >> on >> network load and configuration density and size). >> >> Supposing an ack is needed, then it would be advisable to staffle the >> responses and an additional acknowledgement protocol could be added to >> the >> multicast protocol. The same is true if a message is returned (as in the >> case of mDNS). >> >> One can then wonder whether the application protocol (e.g. mDNS) should >> take >> care of the staffled response or that an additional protocol needs to be >> specified. >> I have no opinion on the choice, but see the need for the one or the >> other. >> Coming with a recommendation (explanation) on the subject of returning >> responses (acks) would be my recommendation for the GroupComm document. >> >> Below some reactions on your reactions. Hope this helps to clarify >> misunderstandings. >> >> Peter >> >> Dijk, Esko schreef op 2012-12-19 14:24: >>> Hi Peter, >>> >>> still a fair number of comments! I would agree with most. Below I have >>> selected some which we should discuss further, or ones I don’t agree >>> with: >>> >>> 1. Group communication definition -> >>> Why can't a source node be part of the group that it sends to? E.g. >>> combined sensor+luminaire use case. The IP stack would deliver sent >>> multicast CoAP requests also to the local application if it is >>> subscribed to the multicast IP address. >> source can of course be member of destination group. >> source may be part of the group (remove the "or may be not" part of the >> phrase) >>> >>> 2. I don’t see why we should add “the use of group communication for >>> mDNS is out of scope.” -> mDNS obviously is not CoAP, and the >>> document should define the scope anyway clearly as CoAP group >>> communication. So we don’t have to list any other protocols than CoAP. >> See my answer on return of packets. I wanted a clear statement on (NOT) >> specifying how applications handle the return of MC responses. >> >>> >>> 3. “so setting a multicast address in a source at installation is >>> forbidden?” -> No, that should not be forbidden :) It should also be >>> possible to set a CoAP path and/or port at installation time. That >>> means the two presented measures have to change or be removed. >> No comment >>> >>> 4. “there are 2 ways: (1) the node queries to which group it belongs >>> or (2) an instalation tools instructs the node to which groups” -> >>> Good point. (2) has been chosen because it works without relying on a >>> service to query (e.g. DNS or RD). Is that sufficient argumentation? >>> The mechanism is optional in any case so it does not block others from >>> defining a DNS or RD variant. >> I would point out both variants and mention that the draft focusses on >> (2) >>> >>> 5. “/s requests /s replies” -> >>> multicast replies (if you mean responses) do not exist in CoAP. It’s >>> about requests that should be carefully controlled since they generate >>> unicast responses. >> Then I do not understand the text, because "request", "reply" and >> "response" >> are overloaded in my mind. >>> >>> 6. “/comment what about the reply?” -> based on core-coap “If the >>> request message is Non-confirmable, then the response SHOULD be >>> returned in a Non-confirmable message as well.” >>> . Do you think we should quote this from the core-coap spec? >> As explained above The subject of returning packets to the MC sender >> needs >> careful consideration. >> the response being NOn-confirmable does not solve a lot I am afraid. >>> >>> 7. “/comment invoking as many certificates?” -> >>> core-coap-13 now loosens the concept of authentication to also >>> include other measures, not needing certificates. >> No comment >>> >>> 8. Network configuration: 2 subnets vs 1 -> maybe a one-subnet >>> configuration is worth adding? Here an overview of present/absent use >>> cases: >>> >>> - Link-local CoAP multicast with responses: Present, Appendix A of >>> core-coap >>> - Site-local CoAP multicast, single subnet: >>> - Site-local CoAP multicast, multi subnet, with or without responses >>> (in the new -04 groupcomm): Present >>> - Global CoAP multicast, single or multi subnet, with or without >>> responses: / dependency on IANA IPv6 allocation >>> - any configurations with a central controller on the backbone >>> multicasting: >> >> Again, the draft should go for the most frequent use cases and not try to >> be >> complete. >> Actually explicitly excluding use cases looks ineresting to me. >>> >>> 9. “It might be useful if the practical impossibility of some >>> configurations is high lighted” -> any thoughts, which would be >>> impossible? >> During the coap meeting in Atlanta, Cullen Jennings presented some >> horrifying examples, as far as I remember. >> >>> >>> 10.“the RD discovery will be more complex when there is a router >>> between light-2 and switch” -> yes, there are issues in RD/discovery >>> especially when more than one is present in a network. >> So, adapt the use case and exclude this possibility. >>> >>> 11.“additional reason to remove router from the multicast >>> configuration”-> hmm, I think that we should opt for having a single >>> RD in the system to avoid complexity. Routers are ok. (One of our >>> goals is to define how CoAP groupcomm works even across routers) >> Looking forward to the supporting protocol. >>> >>> 12.“MLD is used to form groups, correct? but that was already done by >>> enabling the MC address in the lights (point 2)” -> Step 1 is putting >>> the MC address in the lights, then step 2 is the Lights use MLD to >>> *ADVERTIZE* this address to any MLD-enabled Routers present >>> link-local. >>> So MLD is not a commissioning-time protocol but runs all the time >>> during operation. >>> Note that in groupcomm -04 we will remove MLD in the basic use case >>> and present it as an option later. >> >> Sounds good. The point is not to add protocols because they exist but >> because they are needed. >>> >>> 13.“WHY are the multicast destinations sending back results?” -> we >>> remove responses in the new -04 groupcomm. They are presented as an >>> optional thing that servers can do. >>> CoAP servers normally MUST respond to a request with a response >>> (core-coap-13) but an exception is now made for multicast where a >>> server MAY choose not to. This choice is completely independent from >>> confirmable/non-confirmable. Non-confirmable only means that an ACK >>> must not be sent. And an ACK is something different from a CoAP >>> response. >>> Agree that a protocol like MPL comes very close to ‘reliable >>> multicast’. >> >> see my worries at the beginning. >>> >>> Esko >>> >>> -----Original Message----- >>> From: peter van der Stok [mailto:stokcons@xs4all.nl] >>> Sent: Tuesday 18 December 2012 12:06 >>> To: akbar rahman; Dijk, Esko; Core >>> Subject: group-comm comments >>> >>> Hi Akbar and Esko, >>> >>> I had promised to review, comment the group comm draft. >>> >>> Below the commented text. >>> >>> I have not gone very detailed with my comments. I hope that it is >>> clear from my comments that a reorganization of the draft and a review >>> of the uses cases are necessary to get a clearer picture of the >>> feasibility of group comm in the context of Coap. >>> >>> Especialy difficult to understand for me were: >>> >>> - the use case network configuration >>> >>> - the forming and enabling of groups >>> >>> - use of responses >>> >>> Hope this helps. >>> >>> Greetings, >>> >>> peter >>> >>> ______________________________________________________________________ >>> _______________________________ >>> >>> >>> Abstract >>> >>> CoAP is a RESTful transfer protocol for constrained devices. 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 document >>> >>> defines how the CoAP protocol should be used in a group communication >>> >>> context. An approach for using CoAP on top of IP multicast is >>> >>> detailed for both constrained and un-constrained networks. Also, >>> >>> various use >>> >>> /s causes /s cases/ >>> >>> and corresponding protocol flows are provided to >>> >>> illustrate important concepts. Finally, guidance is provided for >>> >>> deployment in various network topologies. >>> >>> Status of this Memo >>> >>> This Internet-Draft is submitted in full conformance with the >>> >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> >>> Task Force (IETF). Note that other groups may also distribute >>> >>> working documents as Internet-Drafts. The list of current Internet- >>> >>> Drafts is at http://datatracker.ietf.org/drafts/current/ [1]. >>> >>> Internet-Drafts are draft documents valid for a maximum of six months >>> >>> and may be updated, replaced, or obsoleted by other documents at any >>> >>> time. It is inappropriate to use Internet-Drafts as reference >>> >>> material or to cite them other than as "work in progress." >>> >>> This Internet-Draft will expire on April 22, 2013. >>> >>> Copyright Notice >>> >>> Copyright (c) 2012 IETF Trust and the persons identified as the >>> >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> >>> Provisions Relating to IETF Documents >>> >>> (http://trustee.ietf.org/license-info [2]) in effect on the date of >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 1] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> publication of this document. Please review these documents >>> >>> carefully, as they describe your rights and restrictions with respect >>> >>> to this document. Code Components extracted from this document must >>> >>> include Simplified BSD License text as described in Section 4.e of >>> >>> the Trust Legal Provisions and are provided without warranty as >>> >>> described in the Simplified BSD License. >>> >>> 1. Conventions and Terminology >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>> >>> document are to be interpreted as described in [RFC2119]. >>> >>> This document assumes readers are familiar with the terms and >>> >>> concepts that are used in [I-D.ietf-core-coap]. In addition, this >>> >>> document defines the following terminology: >>> >>> Group Communication >>> >>> A source node sends a single message which is delivered to >>> >>> multiple destination nodes, where all destinations are identified >>> >>> to belong to a specific group. The source node may >>> >>> /remove or may not >>> >>> be >>> >>> part of the group. The underlying mechanism for group >>> >>> communication is assumed to be multicast based. >>> >>> /remove >>> >>> The network where >>> >>> the group communication takes place can be either a constrained >>> >>> or >>> >>> a regular (un-constrained) network/ >>> >>> /comment not sure about the meaning and consequences >>> >>> Multicast >>> >>> Sending a message to multiple destination nodes >>> >>> /s simultaneously./ >>> >>> /s with one network invocation / >>> >>> There are various options to implement multicast including layer >>> >>> 2 >>> >>> (Media Access Control) or layer 3 (IP) mechanisms. >>> >>> IP Multicast >>> >>> A specific multicast solution based on the use of IP multicast >>> >>> addresses as defined in "IANA Guidelines for IPv4 Multicast >>> >>> Address Assignments" [RFC5771] and "IP Version 6 Addressing >>> >>> Architecture" [RFC4291]. >>> >>> Low power and Lossy Network (LLN) >>> >>> Low power and Lossy Network (LLN): A type of constrained network >>> >>> where the devices are interconnected by a variety of low power, >>> >>> lossy links such as IEEE 802.15.4, Bluetooth, >>> >>> WiFi, wired >>> >>> or low >>> >>> power power-line communication links. >>> >>> 2. Introduction >>> >>> 2.1. Background >>> >>> The Constrained Application Protocol (CoAP) is an application >>> >>> protocol (analogous to HTTP) for resource constrained devices >>> >>> operating in an IP network [I-D.ietf-core-coap]. Constrained >>> >>> devices >>> >>> can be large in number, but are often highly correlated to each >>> >>> other >>> >>> (e.g. by type or location). For example, all the light switches in >>> >>> a >>> >>> building may belong to one group and all the thermostats may belong >>> >>> to another group. Groups may be composed by function. For example, >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 3] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> the group "all lights in building one" may consist of the groups >>> >>> "all >>> >>> lights on floor one of building one", "all lights on floor two of >>> >>> building one", etc. Groups may be preconfigured >>> >>> /add before deployment >>> >>> or dynamically >>> >>> formed >>> >>> /add during operation >>> >>> . If information needs to be sent to or received from a group >>> >>> of devices, group communication mechanisms can improve efficiency >>> >>> and >>> >>> latency of communication and reduce bandwidth requirements for a >>> >>> given application. HTTP does not support any equivalent >>> >>> functionality to CoAP group communication. >>> >>> 2.2. Scope >>> >>> In this draft, we address the issues related to CoAP group >>> >>> communication in detail, with use cases, recommended approaches and >>> >>> analysis of the impact to the CoAP protocol and to implementations. >>> >>> /add the use of group communication for mDNS is out of scope. >>> >>> The guiding principle is to apply wherever possible existing IETF >>> >>> protocols to achieve group communication functionality. In many >>> >>> cases the contribution of this document lies in explaining how >>> >>> existing mechanisms may be used to >>> >>> /remove together >>> >>> fulfill CoAP group >>> >>> communication needs for specific use cases. >>> >>> 2.3. Potential Solutions for Group Communication >>> >>> The classic concept of group >>> >>> /s communications /s communication >>> >>> is that of a single >>> >>> source distributing content to multiple destination recipients that >>> >>> are all part of a group. Before content can be distributed, there >>> >>> is >>> >>> a separate process to form the group. The source may be either a >>> >>> member or non-member of the group. >>> >>> Group communication solutions have evolved from "bottom" to "top", >>> >>> i.e., from layer 2 (Media Access Control broadcast/multicast) and >>> >>> layer 3 (IP multicast) to application layer group communication, >>> >>> also >>> >>> referred to as application layer multicast. A study published in >>> >>> 2005 [Lao05] identified new solutions in the "middle" (referred to >>> >>> as >>> >>> overlay multicast) that utilize an infrastructure based on proxies. >>> >>> Each of these classes of solutions may be compared [Lao05] using >>> >>> metrics such as link stress and level of host complexity >>> >>> [Banerjee01]. The results show for a realistic internet topology >>> >>> that IP Multicast is the most resource-efficient, with the downside >>> >>> being that it requires >>> >>> /s the most /s more organizational >>> >>> effort to deploy in the >>> >>> infrastructure. IP Multicast is the solution adopted by this draft >>> >>> for CoAP group communication. >>> >>> 3. CoAP Group Communication Based On IP Multicast >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 4] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> 3.1. IP Multicast Background >>> >>> IP Multicast routing protocols have been evolving for decades, >>> >>> resulting in proposed standards such as Protocol Independent >>> >>> Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various >>> >>> technical and marketing reasons, IP Multicast routing is not widely >>> >>> deployed on the general Internet. However, IP Multicast is very >>> >>> popular in specific deployments such as in enterprise networks (e.g. >>> >>> for video conferencing), smart home networks (e.g. UPnP/mDNS) and >>> >>> carrier IPTV deployments. The packet economy and minimal host >>> >>> complexity of IP multicast make it attractive for group >>> >>> communication >>> >>> in constrained environments. Therefore IP multicast is the >>> >>> recommended underlying mechanism for CoAP group communication, and >>> >>> the approach assumed in this document. >>> >>> To achieve IP multicast beyond a subnet, an IP multicast routing >>> >>> protocol needs to be active on routers. The RPL protocol [RFC6550] >>> >>> for example is able to route multicast traffic in constrained LLNs. >>> >>> While PIM-SM [RFC4601] is often used for multicast routing in un- >>> >>> constrained networks. >>> >>> IP multicast can also be run in a Link-Local (LL) scope. This means >>> >>> that there is no routing involved and an IP multicast message is >>> >>> only >>> >>> received >>> >>> /s on the network /s over the >>> >>> link on which it was sent. >>> >>> 3.2. CoAP Group Definition and Naming >>> >>> A group is defined as a set of CoAP endpoints, where each endpoint >>> >>> is >>> >>> configured to receive a multicast CoAP request that is sent to the >>> >>> group's associated IP multicast address. The group MAY have more >>> >>> than one associated IP multicast address. An endpoint MAY be a >>> >>> member of multiple groups. Group membership of an endpoint MAY >>> >>> dynamically change over time. The group MAY be identified by a >>> >>> Group >>> >>> Name ([I-D.vanderstok-core-dna]) which is defined as a prefix string >>> >>> of a Group FQDN. The Group FQDN can be uniquely mapped to a site- >>> >>> local or global multicast IP address via DNS resolution. >>> >>> A CoAP multicast request that addresses a group includes a Group URI >>> >>> as the request URI. A Group URI has the scheme 'coap' and includes >>> >>> in the authority part either a group IP address >>> >>> /add + optional port >>> >>> or a hostname >>> >>> /add + optional port >>> >>> that >>> >>> can be resolved to the group IP address (e.g., a Group Name or Group >>> >>> FQDN). Group URIs MUST follow the URI syntax [RFC3986]. >>> >>> A CoAP >>> >>> /s node /s end-point >>> >>> becomes a group member by listening for CoAP messages on >>> >>> the group's IP multicast address, assuming the default CoAP UDP >>> >>> port. >>> >>> Note that a non-default UDP port MAY be specified for the group; in >>> >>> which case implementers MUST ensure that all group members are >>> >>> configured to use this same port. >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 5] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Examples of hierarchical group naming (and scoping) for a building >>> >>> control application are shown below. >>> >>> URI authority Targeted group >>> >>> all.bldg6.example.com "all nodes in building 6" >>> >>> all.west.bldg6.example.com "all nodes in west wing, building >>> >>> 6" >>> >>> all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, >>> >>> building 6" >>> >>> all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, >>> >>> west wing, building 6" >>> >>> Reverse mapping (from IP multicast address to group FQDN) is >>> >>> supported using the reverse DNS resolution technique >>> >>> ([I-D.vanderstok-core-dna]). >>> >>> 3.3. Group Discovery and Member Discovery >>> >>> CoAP defines a resource discovery capability, but does not yet >>> >>> specify how to discover groups (e.g. find a group to join or send a >>> >>> multicast message to) or to discover members of a group (e.g. to >>> >>> address selected group members by unicast). These topics are >>> >>> elaborated in more detail in [I-D.vanderstok-core-dna] including >>> >>> examples for using DNS-SD and CoRE Resource Directory. >>> >>> 3.3.1. DNS-SD >>> >>> DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a >>> >>> conventional way to configure DNS PTR, SRV, and TXT records to >>> >>> enable >>> >>> enumeration of services, such as services offered by CoAP nodes, or >>> >>> enumeration of all CoAP nodes, within specified subdomains. A >>> >>> service is specified by a name of the form >>> >>> .., where the service type for CoAP >>> >>> nodes is _coap._udp and the domain is a DNS domain name that >>> >>> identifies a group as in the examples above. For each CoAP >>> >>> end-point >>> >>> in a group, a PTR record with the name _coap._udp and/or a PTR >>> >>> record >>> >>> with the name _coap._udp. is defined and it points to an SRV >>> >>> record having the .. name. >>> >>> All CoAP nodes in a given subdomain may be enumerated by sending a >>> >>> query for PTR records named _coap._udp to the authoritative DNS >>> >>> server for that zone. A list of SRV records is returned. Each SRV >>> >>> record contains the port and host name (AAAA record) of a CoAP node. >>> >>> The IP address of the node is obtained by resolving the host name. >>> >>> DNS-SD also specifies an optional TXT record, having the same name >>> >>> as >>> >>> the SRV record, which can contain "key=value" attributes. This can >>> >>> be used to store information about the device, e.g. schema=DALI, >>> >>> type=switch, group=lighting.bldg6, etc. >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 6] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Another feature of DNS-SD is the ability to specify service subtypes >>> >>> using PTR records. For example, one could represent all the CoAP >>> >>> groups in a subdomain by PTR records with the name >>> >>> _group._sub._coap._udp or alternatively >>> >>> _group._sub._coap._udp.. >>> >>> 3.3.2. CoRE Resource Directory >>> >>> CoRE Resource Directory [I-D.shelby-core-resource-directory] defines >>> >>> the concept of a Resource Directory (RD) server where CoAP servers >>> >>> can register their resources offered and CoAP clients can discover >>> >>> these resources by querying the RD server. RD syntax can be mapped >>> >>> to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], >>> >>> such that the above approach can be reused for group discovery and >>> >>> group member discovery. >>> >>> /remove Specifically, the Domain (d) parameter can be set to the >>> >>> group URI by >>> >>> an end-point registering to the RD. If an end-point wants to join >>> >>> multiple groups, it has to repeat the registration process for each >>> >>> group it wants to join. >>> >>> /end remove >>> >>> /comment d parameter semantics not clear >>> >>> 3.4. Group Resource Manipulation >>> >>> Group communications SHALL only be used for idempotent methods (i.e. >>> >>> CoAP GET, PUT, DELETE). The CoAP messages that are sent via >>> >>> multicast SHALL be Non-Confirmable. >>> >>> A unicast response per server MAY be sent back to answer the group >>> >>> request (e.g. response "2.05 Content" to a group GET request) taking >>> >>> into account the congestion control rules defined in >>> >>> [I-D.ietf-core-coap]. The unicast responses may be a mixture of >>> >>> success (e.g. 2.05 Content) and failure (e.g. 4.04 Not Found) codes >>> >>> depending on the individual server processing result. >>> >>> Group communications SHALL NOT be used for non-idempotent methods >>> >>> (i.e. CoAP POST). This is because not all group members are >>> >>> guaranteed to receive the multicast request, and the sender can not >>> >>> readily find out which group members did not receive it. >>> >>> All nodes in a given group SHOULD receive the same request >>> >>> /remove with high probability. >>> >>> /comment I don't see where probability comes in. >>> >>> This will not be the case if there is diversity in the >>> >>> authority port (i.e. a diversity of dynamic port addresses across >>> >>> the >>> >>> group) or if the targeted resource is located at different paths on >>> >>> different nodes. >>> >>> Therefore, some measures must be present to ensure uniformity in >>> >>> port >>> >>> number and resource names/locations within a group. This document >>> >>> proposes the following measures: >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 7] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> o All CoAP multicast requests MUST be sent either to the default >>> >>> CoAP UDP port (i.e. default Uri-Port as defined in >>> >>> [I-D.ietf-core-coap]), or to a port number obtained via a service >>> >>> discovery lookup operation as a valid CoAP port for the targeted >>> >>> multicast group. >>> >>> o All CoAP multicast requests SHOULD operate only on URIs (links) >>> >>> which were >>> >>> /s retreived /s retrieved >>> >>> either from a "/.well-known/core" lookup on >>> >>> at least one group member node, or from an equivalent service >>> >>> discovery lookup which returns either the resources supported by >>> >>> all group members or resources supported by one particular group >>> >>> member. >>> >>> /comment so setting a multicast address in a source at installation is >>> >>> forbidden? >>> >>> 3.5. Configuring Group Membership In Endpoints >>> >>> In some use cases, the group membership of endpoints needs to be >>> >>> configurable after the network has been deployed. Example use cases >>> >>> can be found in building control: a commissioning tool determines to >>> >>> which groups a light or sensor node belongs, and writes this >>> >>> information to all nodes, which can subsequently join the correct >>> >>> group. >>> >>> To achieve smoother interoperability between nodes/endpoints from >>> >>> different manufacturers, it is proposed here to define an OPTIONAL >>> >>> standardized RESTful means of configuring CoAP endpoints with >>> >>> relevant group information. >>> >>> CoAP endpoints implementing this mechanism MUST support a >>> >>> discoverable "Group Configuration" resource of resource type (rt) >>> >>> [RFC6690] "core.gp". This resource (and perhaps its sub-resources, >>> >>> TBD) are used to manage group membership. Three design options for >>> >>> this mechanism are presented here as a placeholder (TBD). >>> >>> Design 1: use CoRE link format payloads to communicate group >>> >>> membership to endpoints. (TBD Not clear how this should be >>> >>> realized.) >>> >>> /comment, not clear what you mean either. Remove design 1 in this >>> state >>> >>> Design 2: use a JSON type resource. For example, a GET on the >>> >>> "core.gp" resource returns a JSON array of group objects. >>> >>> Req: GET /gp >>> >>> Res: 2.05 Content (Content-Format: application/json) >>> >>> [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", >>> >>> "ip": "ff05::4200:f7fe:ed37:14ca" } >>> >>> ] >>> >>> where "n" defines the Group FQDN and "ip" defines the associated >>> >>> multicast IP address. As a next example, the same endpoint can be >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 8] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> added to another group by a POST on the resource with a JSON group >>> >>> object: >>> >>> Req: POST /gp (Content-Format: application/json) >>> >>> { "n": "floor1.west.bldg6.example.com", >>> >>> "ip": "ff05::4200:f7fe:ed37:14cb" } >>> >>> Res: 2.04 Changed >>> >>> Design 3: define named sub-resources, each sub-resource representing >>> >>> a group membership. The payload of the sub-resource may be JSON or >>> >>> a >>> >>> simple pre-defined format. Or alternatively, information is >>> >>> provided >>> >>> via POST with query parameters. >>> >>> /comment are these mutually exclusive designs? >>> >>> /comment design 2 without JSON is als possible >>> >>> /comment design with SRV and TXt records is also possible >>> >>> /comment there are 2 ways: (1) the node queries to which group it >>> >>> belongs >>> >>> /comment (2) an instalation tools instructs the node to which groups >>> >>> it belongs >>> >>> /comment not clear in text that this choice exists or that a choice >>> was >>> >>> made. >>> >>> 3.6. Congestion Control >>> >>> Multicast CoAP requests may result in a multitude of replies from >>> >>> different nodes, potentially causing congestion. Therefore sending >>> >>> multicast >>> >>> /s requests /s replies >>> >>> should be conservatively controlled. >>> >>> The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific >>> >>> congestion risks through the following measures: >>> >>> o A server MAY choose not to respond to a multicast request if >>> >>> there's nothing useful to respond (e.g. error or empty response). >>> >>> o A server SHOULD limit the support for multicast requests to >>> >>> specific resources where multicast operation is required. >>> >>> o A multicast request MUST be Non-Confirmable. >>> >>> /comment what about the reply? >>> >>> o A server does not respond immediately to a multicast request, but >>> >>> SHOULD first wait for a time that is randomly picked within a >>> >>> predetermined time interval called the Leisure. >>> >>> o A server SHOULD NOT accept multicast requests that can not be >>> >>> authenticated. >>> >>> /comment invoking as many certificates? >>> >>> Additional guidelines to reduce congestion risks are: >>> >>> o A server in an LLN should only support multicast GET for >>> >>> resources >>> >>> that are small, e.g. >>> >>> /remove for an LLN that could mean >>> >>> the payload of the >>> >>> response fits into a single link-layer frame. >>> >>> o A server can minimize the payload length in response to a >>> >>> multicast GET on "/.well-known/core" by using hierarchy in >>> >>> arranging link descriptions for the response. An example of this >>> >>> is given in Section 5 of [RFC6690]. >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 9] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> o Preferably IP multicast with link-local scope should be used, >>> >>> rather than global or site-local. >>> >>> o The Hop Limit field in the IPv6 packet should be chosen as low as >>> >>> possible (if the CoAP/IP stack allows setting of this value. TBD >>> >>> - discuss whether this guideline is relevant/realistic in CoAP >>> >>> context) >>> >>> 3.7. CoAP Multicast and HTTP Unicast Interworking >>> >>> /comment a reference will suffice >>> >>> CoAP supports operation over UDP multicast, while HTTP does not. >>> >>> For >>> >>> use cases where it is required that CoAP group communication is >>> >>> initiated from an HTTP end-point, it would be advantageous if the >>> >>> HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group >>> >>> communication based on IP multicast. >>> >>> /remove One possible way of operation >>> >>> /remove of such HTTP-CoAP Proxy is illustrated in Figure 1. >>> >>> Note that this >>> >>> topic is covered in more detail in >>> >>> [I-D.castellani-core-advanced-http-mapping]. >>> >>> /remove >>> >>> CoAP Mcast CoAP Mcast HTTP-CoAP HTTP >>> >>> Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 >>> >>> | | | | | | >>> >>> |MLD REQUEST | | | | >>> >>> |(Join Group X) | | | | >>> >>> |--LL-->| | | | | >>> >>> | | |MLD REQUEST | | >>> >>> | | |(Join Group X) | | >>> >>> | | |--LL-->| | | >>> >>> | | | | | HTTP REQUEST | >>> >>> | | | | | (URI to | >>> >>> | | | | | unicast addr) | >>> >>> | | | | |< -----------------| >>> >>> | | | | | | >>> >>> | | | Resolve HTTP Request-Line URI | >>> >>> | | | to Group X multicast address | >>> >>> | | | | | | >>> >>> | CoAP REQUEST (to multicast addr)| | >>> >>> |< ------<---------<-------<------| | >>> >>> | | | | | | >>> >>> | | | | >>> >>> | (optional) CoAP RESPONSE(s) | | >>> >>> | |-------------->| | >>> >>> |-----------------|-------------->| Aggregated | >>> >>> | | | HTTP RESPONSE | >>> >>> | | |------------------>| >>> >>> | | | | >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 10] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Figure 1: CoAP Multicast and HTTP Unicast Interworking >>> >>> Note that Figure 1 illustrates the case of IP multicast as the >>> >>> underlying group communications mechanism. MLD denotes the >>> >>> Multicast >>> >>> Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a >>> >>> Link-Local multicast. >>> >>> A key point in Figure 1 is that the incoming HTTP Request (from node >>> >>> 3) will carry a Host request-header field that resolves in the >>> >>> general Internet to the proxy node. At the proxy node, this >>> >>> hostname >>> >>> and/or the Request-Line URI will then possibly be mapped (as >>> >>> detailed >>> >>> in [I-D.castellani-core-http-mapping]) and again resolved (with the >>> >>> CoAP scheme) to an IP multicast address. This may be accomplished, >>> >>> for example, by using DNS or DNS-SD (Section 3.3). The proxy node >>> >>> will then IP multicast the CoAP Request (corresponding to the >>> >>> received HTTP Request) via multicast routers to the appropriate >>> >>> nodes >>> >>> (i.e. nodes 1 and 2). >>> >>> In terms of the HTTP Response, Figure 1 illustrates that it will be >>> >>> generated by the proxy node based on aggregated responses of the >>> >>> CoAP >>> >>> nodes and sent back to the client in the general Internet that sent >>> >>> the HTTP Request (i.e. node 1). In >>> >>> [I-D.castellani-core-advanced-http-mapping] the HTTP Response that >>> >>> the Proxy may use to aggregate multiple CoAP responses is described >>> >>> in more detail. So in terms of overall operation, the CoAP proxy >>> >>> can >>> >>> be considered to be a "non-transparent" proxy according to >>> >>> [RFC2616]. >>> >>> Specifically, [RFC2616] states that a "non-transparent proxy is a >>> >>> proxy that modifies the request or response in order to provide some >>> >>> added service to the user agent, such as group annotation services, >>> >>> media type transformation, protocol reduction or anonymity >>> >>> filtering." >>> >>> An alternative to the above is using a Forward Proxy. In this case, >>> >>> the CoAP request URI is carried in the HTTP Request-Line (as defined >>> >>> in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the >>> >>> IP address of the Proxy. >>> >>> /end remove >>> >>> 4. Use Cases and Corresponding Protocol Flows >>> >>> 4.1. Introduction >>> >>> The use of CoAP group communication is shown in the context of the >>> >>> following use cases and corresponding protocol flows: >>> >>> o Discovery of Resource Directory: discovering the local CoRE RD >>> >>> which contains links (URIs) to resources stored on other servers >>> >>> [RFC6690]. >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 11] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> o Lighting Control: synchronous operation of a group of 6LoWPAN >>> >>> [RFC4944] IPv6-connected lights >>> >>> o Parameter Update: updating parameters/settings simultaneously in >>> >>> a >>> >>> large group of devices in a building/campus control >>> >>> ([I-D.vanderstok-core-bc]) application --- TBD >>> >>> / comment I suggest to remove Firmware Update and Groups status report >>> >>> /comment the ones above are difficult enough, and I doubt that >>> >>> simultaneity >>> >>> /comment (motivation of multicast) is involved here >>> >>> o Firmware Update: efficiently updating firmware simultaneously in >>> >>> a >>> >>> large group of devices in a building/campus control >>> >>> ([I-D.vanderstok-core-bc]) application --- TBD suggests a >>> >>> multicast extension of core-block. >>> >>> o Group Status Report: requesting status information or event >>> >>> reports from a group of devices in a building/campus control >>> >>> application --- TBD, may require reliable group communication to >>> >>> be feasible. >>> >>> 4.2. Network Configuration >>> >>> We assume the following network configuration for all the use cases >>> >>> as shown in Figure 2: >>> >>> /comment the configurations frighten me >>> >>> /comment from completeness considerations I can imagine even more >>> >>> complex ones >>> >>> /comment It might be useful if the practical impossibility of some >>> >>> configurations is high lighted >>> >>> o A large room (Room-A) with three lights (Light-1, Light-2, >>> >>> Light-3) controlled by a Light Switch. The devices are organized >>> >>> into two 6LoWPAN subnets. >>> >>> /comment one subnet is enough for me >>> >>> /remove >>> >>> o Light-1 and the Light Switch are connected to a router (Rtr-1) >>> >>> which is also a CoAP Proxy, a CoAP Resource Directory (RD) and a >>> >>> 6LoWPAN Border Router (6LBR). >>> >>> o Light-2 and the Light-3 are connected to another router (Rtr-2) >>> >>> which is also a CoAP Proxy, a CoAP RD and a 6LBR. >>> >>> o The routers are connected to an IPv6 network backbone which is >>> >>> also multicast enabled. In the general case, this means the >>> >>> network backbone and 6LBRs support a PIM based multicast routing >>> >>> protocol, and MLD for forming groups. In a limited case, if the >>> >>> network backbone is one link, then the routers only have to >>> >>> support MLD-snooping (Appendix A) for the following use cases to >>> >>> work. >>> >>> /end remove >>> >>> /comment I can imagine that an central control is present on the >>> >>> backbone >>> >>> /comment switch or sensor send unicast to central control >>> >>> /comment central control sends multicast to multicast group within >>> >>> single lowpan >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 12] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Network >>> >>> Backbone >>> >>> | >>> >>> ################################################ >>> >>> | >>> >>> # Room-A # >>> >>> | >>> >>> # ********************** # >>> >>> | >>> >>> # ** LoWPAN-1 (subnet-1) ** # >>> >>> | >>> >>> # * * # >>> >>> | >>> >>> # * +----------+ * # >>> >>> | >>> >>> # * | Light |-------+ * # >>> >>> | >>> >>> # * | Switch | | * # >>> >>> | >>> >>> # * +----------+ +---------+ * # >>> >>> | >>> >>> # * | Rtr-1 >>> >>> |-----------------------------| >>> >>> # * +---------+ * # >>> >>> | >>> >>> # * +----------+ | * # >>> >>> | >>> >>> # * | Light-1 |--------+ * # >>> >>> | >>> >>> # * +----------+ * # >>> >>> | >>> >>> # * * # >>> >>> | >>> >>> # ** ** # >>> >>> | >>> >>> # ********************** # >>> >>> | >>> >>> # # >>> >>> | >>> >>> # # >>> >>> | >>> >>> # ********************** # >>> >>> | >>> >>> # ** LoWPAN-2 (subnet-2) ** # >>> >>> | >>> >>> # * * # >>> >>> | >>> >>> # * +----------+ * # >>> >>> | >>> >>> # * | Light-2 |-------+ * # >>> >>> | >>> >>> # * | | | * # >>> >>> | >>> >>> # * +----------+ +---------+ * # >>> >>> | >>> >>> # * | Rtr-2 >>> >>> |-----------------------------| >>> >>> # * +---------+ * # >>> >>> | >>> >>> # * +----------+ | * # >>> >>> | >>> >>> # * | Light-3 |--------+ * # >>> >>> | >>> >>> # * +----------+ * # >>> >>> | >>> >>> # * * # >>> >>> | >>> >>> # ** ** # >>> >>> | >>> >>> # ********************** # >>> >>> | >>> >>> # # >>> >>> | >>> >>> ################################################# >>> >>> | >>> >>> | >>> >>> +--------+ >>> >>> | >>> >>> | DNS >>> >>> |------------------| >>> >>> | Server | >>> >>> +--------+ >>> >>> Figure 2: Network Topology of a Large Room (Room-A) >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 13] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> 4.3. Discovery of Resource Directory >>> >>> The protocol flow for discovery of a RD for the given network (of >>> >>> Figure 2) is shown in Figure 3: >>> >>> o The fixture for Light-2 is installed and powered on for the first >>> >>> time. >>> >>> o Light-2 will then search for the local RD (RD-2) by sending out a >>> >>> GET request (with the "/.well-known/core?rt=core.rd" request URI) >>> >>> to the site-local "All CoAP Nodes" address. In this case, the >>> >>> site is assumed to include all nodes in the subnet. >>> >>> o This multicast message will then go to each node in subnet-2. >>> >>> However, only Rtr-2 (RD-2) will respond because the GET is >>> >>> qualified by the query string "?rt=core.rd". >>> >>> o Note that the flow is shown only for Light-2 for clarity. >>> >>> Similar >>> >>> flows will happen for Light-1, Light-3 and the Light Switch when >>> >>> they are first powered on. >>> >>> The RD may also be discovered by other means such as by assuming a >>> >>> default location (e.g. on a 6LBR), using DHCP, anycast address, etc. >>> >>> However, these approaches do not invoke CoAP group communication so >>> >>> are not further discussed here. >>> >>> For other discovery use cases such as discovering local CoAP >>> >>> servers, >>> >>> services or resources group communication can be used in a similar >>> >>> fashion as in the above use case. Both Link-Local (LL) and site- >>> >>> local discovery are possible this way. >>> >>> /comment the RD discovery will be more complex when there is a router >>> >>> between light-2 and switch >>> >>> /comment Via which RD will light switch discover light-2? >>> >>> /comment additional reason to remove router from the multicast >>> >>> configuration >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 14] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Light Rtr-1 Rtr-2 >>> >>> Network >>> >>> Light-1 Light-2 Light-3 Switch (RD-1) (RD-2) >>> >>> Backbone >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> ********************************** | | | >>> >>> * Light-2 is installed * | | | >>> >>> * and powers on for first time * | | | >>> >>> ********************************** | | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | COAP NON (GET | | >>> >>> | | /.well-known/core?rt=core.rd) | | >>> >>> | |--------->-------------------------------->| | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | COAP NON (2.05 Content | | >>> >>> | | ;rt="core.rd";ins="Primary") | | >>> >>> | |<------------------------------------------| | >>> >>> | | | | | | | >>> >>> Figure 3: Resource Directory Discovery via Multicast Message >>> >>> 4.4. Lighting Control >>> >>> /comment I am confused about the use of protocols >>> >>> /comment MLD is used to form groups, correct? >>> >>> /comment but that was already done by enabling the MC address in the >>> >>> lights (point 2) >>> >>> /comment There are several ways to set up groups, pointing them out >>> and >>> >>> when to use them would be an asset. >>> >>> The protocol flow for a building automation lighting control >>> >>> scenario >>> >>> for the network (Figure 2) is shown in sequence in Figure 4, >>> >>> Figure 5, and Figure 6. We assume the following steps occur before >>> >>> the illustrated flow: >>> >>> o 1) Startup phase: 6LoWPANs are formed. IPv6 addresses assigned >>> >>> to >>> >>> all devices. The CoAP network is formed. >>> >>> o 2) Commissioning phase (by applications): The IP multicast >>> >>> address >>> >>> of the group (Room-A-Lights) has been >>> >>> /s set /s enable >>> >>> in all the Lights. The >>> >>> URI of the group (Room-A-Lights) has been >>> >>> /s set /s resolved >>> >>> in the Light Switch. >>> >>> o 3) The indicated MLD Report messages are link-local multicast. >>> >>> In >>> >>> each LoWPAN, it is assumed that a multicast routing/forwarding >>> >>> protocol in 6LRs will then propagate the Join information >>> >>> contained in the MLD Report over multiple hops to the 6LBR. >>> >>> /comment Don't see the need >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 15] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Light Rtr-1 Rtr-2 >>> >>> Network >>> >>> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >>> >>> Backbone >>> >>> | | | | Proxy) Proxy) | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | MLD Report: Join | | | | | >>> >>> | Group (Room-A-Lights) | | | | >>> >>> |---LL------------------------------------->| | | >>> >>> | | | | |MLD Report: Join | >>> >>> | | | | |Group (Room-A-Lights)| >>> >>> | | | | |---LL--------------->| >>> >>> | | | | | | | >>> >>> | | MLD Report: Join | | | | >>> >>> | | Group (Room-A-Lights) | | | >>> >>> | |---LL------------------------------------->| | >>> >>> | | | | | | | >>> >>> | | | MLD Report: Join | | | >>> >>> | | | Group (Room-A-Lights) | | >>> >>> | | |---LL-------------------------->| | >>> >>> | | | | | | | >>> >>> | | | | |MLD Report: Join | >>> >>> | | | | |Group (Room-A-Lights)| >>> >>> | | | | | |---LL---->| >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> Figure 4: Joining Lighting Groups Using MLD >>> >>> /comment possibly remove from text, or do separate section on use of >>> >>> MLD >>> >>> /comment anyway separating commissioning from operation in separate >>> >>> sections is a good idea. >>> >>> /comment the proxies are a complication in the picture not elaborated >>> >>> in the text. >>> >>> /comment the subject of proxies is another one, to be treated >>> >>> elsewhere. >>> >>> /comment also for proxies the do's and don't's from a simple >>> >>> performance perspective will be interesting >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 16] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Light Rtr-1 Rtr-2 >>> >>> Network >>> >>> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >>> >>> Backbone >>> >>> | | | | Proxy) Proxy) | >>> >>> | | | | | | | >>> >>> | | *********************** | | >>> >>> | | * User flips on * | | >>> >>> | | * light switch to * | | >>> >>> | | * turn on all the * | | >>> >>> | | * lights in Room A * | | >>> >>> | | *********************** | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | COAP NON (PUT | | | >>> >>> | | | Proxy-URI | | | >>> >>> | | | URI for Room-A-Lights | >>> >>> | | | Payload=turn on lights) | >>> >>> | | | |--------->| | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | | Request DNS resolution of | >>> >>> | | | | URI for Room-A-Lights | >>> >>> | | | | |-------------------->| >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | | DNS returns: AAAA | >>> >>> | | | | Group (Room-A-Lights) | >>> >>> | | | | IPv6 multicast address | >>> >>> | | | | |<--------------------| >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | | COAP NON (Put | >>> >>> | | | | URI Path | >>> >>> | | | | Payload=turn on lights)| >>> >>> | | | | Destination IP Address = | >>> >>> | | | | IP multicast address | >>> >>> | | | | for Group (Room-A-Lights)| >>> >>> | | | | Originating IP Address = | >>> >>> | | | | RTR-1 | >>> >>> | | | | |-------------------->| >>> >>> |<------------------------------------------| | | >>> >>> | | | | | | | >>> >>> | | | | | |<---------| >>> >>> | |<---------|<-------------------------------| | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> Figure 5: Sending Lighting Control Multicast Message >>> >>> Rahman & Dijk Expires April 22, 2013 [Page >>> >>> 17] >>> >>> Internet-Draft Group Communication for CoAP October >>> >>> 2012 >>> >>> Light Rtr-1 Rtr-2 >>> >>> Network >>> >>> Light-1 Light-2 Light-3 Switch (CoAP (CoAP >>> >>> Backbone >>> >>> | | | | Proxy) Proxy) | >>> >>> | | | | | | | >>> >>> *********************** | | | | >>> >>> * Lights in Room-A * | | | | >>> >>> * turn on (nearly * | | | | >>> >>> * simultaneously) * | | | | >>> >>> *********************** | | | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | COAP NON (2.04 Changed) | | | | >>> >>> |------------------------------------------>| | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | COAP NON (2.04 Changed) | | | >>> >>> | |------------------------------->| | | >>> >>> | | | | | | | >>> >>> | | | | | | | >>> >>> | | COAP NON (5.00 Internal Server Error) | >>> >>> | | |-------------------->| | | >>> >>> | | | | | | | >>> >>> | | | ****************************** | >>> >>> | | | * Rtr-1 as CoAP Proxy * | >>> >>> | | | * | sends the individual * | >>> >>> | | | * | responses back to * | >>> >>> | | | * v originator * | >>> >>> | | | ****************************** | >>> >>> | | | | | | | >>> >>> | | | COAP NON (2.04 Changed) | | >>> >>> | | | |<---------| | | >>> >>> | | | | | | | >>> >>> | | | COAP NON (2.04 Changed) | | >>> >>> | | | |<---------| | | >>> >>> | | | | | | | >>> >>> | | | COAP NON (5.00 Internal Server Error) | >>> >>> | | | |<---------| | | >>> >>> | | | | | | | >>> >>> Figure 6: Sending Lighting Control Response to Multicast Message >>> >>> NOTE: In the last step of Figure 6, Rtr-1 acting as CoAP proxy, >>> >>> returns multiple individual CoAP responses to the client. Each >>> >>> response echoes the Token of the client's request. The client can >>> >>> identify the original source of each response by ...TBD. >>> >>> /comment WHY are the multicast destinations sending back results? >>> >>> /comment I thought that you wanted MC messages to be non confirmable >>> >>> /comment sending responses seems to contradict this . >>> >>> /comment please remove sending back of responses. >>> >>> /comment one may assume that the MC algorithm within the lowpan is >>> >>> reliable (all destinations receive the message) >>> >>> /comment anyway MPL comes close enough to the reliability requirement >>> >>> given a specifiable range of configurations >>> >>> ______________________________________________________________________ >>> _____________________________________________________ >>> >>> >>> -- >>> >>> Peter van der Stok >>> >>> mailto: consultancy@vanderstok.org >>> >>> www: www.vanderstok.org [3] >>> >>> tel NL: +31(0)492474673 F: +33(0)966015248 >>> >>> ------------------------- >>> The information contained in this message may be confidential and >>> legally protected under applicable law. The message is intended solely >>> for the addressee(s). If you are not the intended recipient, you are >>> hereby notified that any use, forwarding, dissemination, or >>> reproduction of this message is strictly prohibited and may be >>> unlawful. If you are not the intended recipient, please contact the >>> sender by return e-mail and destroy all copies of the original >>> message. >>> >>> >>> Links: >>> ------ >>> [1] http://datatracker.ietf.org/drafts/current/ >>> [2] http://trustee.ietf.org/license-info >>> [3] http://www.vanderstok.org >> >> ________________________________ >> The information contained in this message may be confidential and legally >> protected under applicable law. The message is intended solely for the >> addressee(s). If you are not the intended recipient, you are hereby >> notified >> that any use, forwarding, dissemination, or reproduction of this message >> is >> strictly prohibited and may be unlawful. If you are not the intended >> recipient, please contact the sender by return e-mail and destroy all >> copies >> of the original message. >> _______________________________________________ >> 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 From cabo@tzi.org Thu Nov 7 11:30:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEFB11E8282 for ; Thu, 7 Nov 2013 11:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.31 X-Spam-Level: X-Spam-Status: No, score=-106.31 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9pGL72uZLLQ for ; Thu, 7 Nov 2013 11:30:45 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 74F7D21E80DB for ; Thu, 7 Nov 2013 11:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA7JUJZV019844 for ; Thu, 7 Nov 2013 20:30:19 +0100 (CET) Received: from dhcp-98f2.meeting.ietf.org (dhcp-98f2.meeting.ietf.org [31.133.152.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0C0D0867; Thu, 7 Nov 2013 20:30:17 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Carsten Bormann In-Reply-To: Date: Thu, 7 Nov 2013 11:30:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <12771F6C-A922-4F08-A330-DB58285266EE@tzi.org> References: To: core X-Mailer: Apple Mail (2.1816) Subject: [core] slide set for today posted X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:30:51 -0000 Updated: > http://www.ietf.org/proceedings/88/slides/slides-88-core-0.pdf Please check whether your slides are in and at the right place. Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Thu Nov 7 18:36:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF7C11E81BA for ; Thu, 7 Nov 2013 18:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JnTtYlUqXTN for ; Thu, 7 Nov 2013 18:36:33 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D2A5121E814B for ; Thu, 7 Nov 2013 18:36:17 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Nov 2013 21:36:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CEDC2B.57333473" Date: Thu, 7 Nov 2013 21:36:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG interest in Sleepy Node topic Thread-Index: Ac7cK1YqMzRJhdYORw+JQXBuUFLKkg== From: "Rahman, Akbar" To: "Core" X-OriginalArrivalTime: 08 Nov 2013 02:36:34.0493 (UTC) FILETIME=[57321ED0:01CEDC2B] Subject: [core] WG interest in Sleepy Node topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 02:36:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CEDC2B.57333473 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 =20 =20 Once again we ran out of time on the agenda to discuss the WG interest on the topic of Sleepy Nodes =20 http://www.ietf.org/id/draft-rahman-core-sleepy-nodes-do-we-need-00.txt =20 =20 However, Carsten did suggest that we carry the discussion that we would have had in the meeting forward to the WG list. The key questions that we need WG feedback on are: =20 1. Does the WG want to keep discussing Sleepy Nodes in CORE? The Sleepy Node support could be in: a. CoAP Protocol b. CORE Link Format c. CORE Resource Directory d. Etc. =20 2. Sub-Question: a. Does the WG want to see some immediate development of the Mirror Server concept (which seems to have near unanimous support and is well correlated to Sleepy Node support)? =20 =20 Any and all comments are appreciated! Please write back even if you answered earlier Emails on this topic as we need to gauge WG interest. =20 =20 Thanks, =20 =20 Akbar ------_=_NextPart_001_01CEDC2B.57333473 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

 

 

Once again = we ran out of time on the agenda to discuss the WG interest on the topic = of Sleepy Nodes

 

http://www.ietf.org/id/draft-rahman-core-sleepy-nodes-do-we-need-= 00.txt

 

 

However, = Carsten did suggest that we carry the discussion that we would have had = in the meeting forward to the WG list.  The key questions that we = need WG feedback on are:

 

1.       = Does the WG want to keep discussing Sleepy Nodes = in CORE?  The Sleepy Node support could be in:

a.       = CoAP Protocol

b.      = CORE Link Format

c.       = CORE Resource Directory

d.      = Etc.

 

2.       = Sub-Question:

a.       = Does the WG want to see some immediate = development of the Mirror Server concept (which seems to have near = unanimous support and is well correlated to Sleepy Node = support)?

 

 

Any and all = comments are appreciated!  Please write back even if you answered = earlier Emails on this topic as we need to gauge WG = interest.

 

 

Thanks,

 

 

Akbar

------_=_NextPart_001_01CEDC2B.57333473-- From weigengyu@bupt.edu.cn Fri Nov 8 00:01:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB8421E80B1 for ; Fri, 8 Nov 2013 00:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4NdkMt96sdF for ; Fri, 8 Nov 2013 00:01:51 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2F79621E8064 for ; Fri, 8 Nov 2013 00:01:46 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id A043219F3CC; Fri, 8 Nov 2013 16:01:43 +0800 (HKT) Message-ID: <06E8B6A2EB8F44A9BA8E218CFC9AA8FD@WeiGengyuPC> From: "weigengyu" To: "Rahman, Akbar" References: In-Reply-To: Date: Fri, 8 Nov 2013 16:01:43 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01CEDC9B.D1CF52F0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] WG interest in Sleepy Node topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 08:01:56 -0000 һ MIME ʽĶ෽ʼ ------=_NextPart_000_004D_01CEDC9B.D1CF52F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi=EF=BC=8CAkbar=EF=BC=8C I believe that sleepy node will affects the CoAP performance and = functionalities when CoAP runs in smart phone.=20 Smart phones of IOS=E2=80=99s, Android and WP have sleep mode,=20 and that affects the existing mobile internet applications and mobile = networks. Samrt phones are ever used as SINK in sensor network, as a hub for = merging data and processing,=20 and as a proxy for accessing the Internet through Gprs, 3G or 4G in M2M = networks.=20 Smart phone plays a very important role in the applicatoins, the same as = CoRE applications, that were developed two or three years ago.=20 The typical cenario is that sensors send data to smart phone(s) and then = the smart phone, as a proxy, delivers data to the service center in the = Internet. When the smart phone falls into sleep mode, communications are affected = apparently.=20 Whereas PADs, notebooks are considered to replace the smart phone, as = you know, all these mobile quipements have the sleep mode for sustaining = a longer battery life. =20 So, in CoRE like enviroments, we need to take care of sleep node. =20 regards,=20 Gengyu=20 Network Technology Center School of Computer Beijing University of Posts & Telecommunications From: Rahman, Akbar=20 Sent: Friday, November 08, 2013 10:36 AM To: Core=20 Subject: [core] WG interest in Sleepy Node topic Hi All, =20 =20 =20 Once again we ran out of time on the agenda to discuss the WG interest = on the topic of Sleepy Nodes =20 http://www.ietf.org/id/draft-rahman-core-sleepy-nodes-do-we-need-00.txt =20 =20 However, Carsten did suggest that we carry the discussion that we would = have had in the meeting forward to the WG list. The key questions that = we need WG feedback on are: =20 1. Does the WG want to keep discussing Sleepy Nodes in CORE? The = Sleepy Node support could be in: a. CoAP Protocol b. CORE Link Format c. CORE Resource Directory d. Etc. =20 2. Sub-Question: a. Does the WG want to see some immediate development of the = Mirror Server concept (which seems to have near unanimous support and is = well correlated to Sleepy Node support)? =20 =20 Any and all comments are appreciated! Please write back even if you = answered earlier Emails on this topic as we need to gauge WG interest. =20 =20 Thanks, =20 =20 Akbar -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_004D_01CEDC9B.D1CF52F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=EF=BC=8CAkbar=EF=BC=8C
 
 
I believe that sleepy node will affects the CoAP performance and=20 functionalities when CoAP runs in smart phone.
Smart phones of IOS=E2=80=99s, = Android and WP have sleep=20 mode,
and that affects the existing = mobile=20 internet applications and mobile networks.
 
Samrt phones are ever used as SINK in sensor = network, as a=20 hub for merging data and processing,
and as a proxy=20 for accessing the Internet through Gprs, 3G or 4G in M2M networks. =
 
Smart phone plays a very important = role in the applicatoins, the same as CoRE applications, = that were=20 developed two or three years ago.
The typical cenario is that sensors = send data to=20 smart phone(s) and then the smart = phone, as a=20 proxy, delivers data to the service center in the Internet.
When the smart phone falls into sleep = mode, =20 communications are affected apparently.
Whereas PADs, notebooks are = considered to replace=20 the smart phone, as you know, all these mobile quipements have the sleep = mode=20 for sustaining a longer battery life. 
 
So, in CoRE like enviroments, we need = to take=20 care of sleep node. 
 
 
regards,
 
Gengyu
 
Network Technology = Center
School of Computer
Beijing University of Posts &=20 Telecommunications
 
From: Rahman, Akbar
Sent: Friday, November 08, 2013 10:36 AM
To: Core=20
Subject: [core] WG interest in Sleepy Node = topic
 

Hi All,

 

 

 

Once again we ran out of time on the agenda to = discuss the WG=20 interest on the topic of Sleepy Nodes

 

http://www.ietf.org/id/draft-rahman-core-sleepy-nodes-do-we-need-= 00.txt

 

 

However, Carsten did suggest that we carry the = discussion=20 that we would have had in the meeting forward to the WG list.  The = key=20 questions that we need WG feedback on are:

 

1.      =20 Does the WG want to keep discussing Sleepy Nodes in = CORE? =20 The Sleepy Node support could be in:

a.      =20 CoAP Protocol

b.     =20 CORE Link Format

c.      =20 CORE Resource Directory

d.     =20 Etc.

 

2.      =20 Sub-Question:

a.      =20 Does the WG want to see some immediate development of the = Mirror=20 Server concept (which seems to have near unanimous support and is well=20 correlated to Sleepy Node support)?

 

 

Any and all comments are appreciated!  Please = write back=20 even if you answered earlier Emails on this topic as we need to gauge WG = interest.

 

 

Thanks,

 

 

Akbar

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_004D_01CEDC9B.D1CF52F0-- From tho@koanlogic.com Fri Nov 8 01:48:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A698711E8162 for ; Fri, 8 Nov 2013 01:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrvgVnjHS4Hz for ; Fri, 8 Nov 2013 01:48:15 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 82C4D11E810A for ; Fri, 8 Nov 2013 01:48:15 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id z5so1235806lbh.7 for ; Fri, 08 Nov 2013 01:48:14 -0800 (PST) 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; bh=HCUpQb7GxPYVe9pf35sKS6pjqxAbbktOUcKaiylMFrQ=; b=fh13dbQ/Fx7XPpjy/z2uk0Pj9P77XE4RlJXD3EN03L9CryreJr9aUAexqXuPdyqOuz d25hkrgXSvmfozujejFiK3VnA4YZkYw9ZuD9eHJTn4F9O7PBaZe2xA6NBZ1sApjLX5ET G7H7j5n05k9/G6p0OnIrS56A7NhOM+j8QnEChBgo6l5ZljOc08f1zGbU2OMqZsKxW+va A+Uaormw0DZp5fP74F0HVOTQtijURi4VeHbTpcFzawlDXrVJy2Gel9MOzz2GWZ4ubNe8 32mciBmklcI/VBBV2A85Zp/SBD38XIWt1KufTgJ/vflJoT8uz67cBo/PI6nxcVlmf7Ux +4BA== X-Gm-Message-State: ALoCoQn7u34odMW94vGDBj8cC+RNBRQPSy27G+Q78Pw0PEyCaf6t6QGVLHFQrh+kjjK2aoIjsPTd MIME-Version: 1.0 X-Received: by 10.112.234.168 with SMTP id uf8mr686823lbc.35.1383904094261; Fri, 08 Nov 2013 01:48:14 -0800 (PST) Received: by 10.114.21.4 with HTTP; Fri, 8 Nov 2013 01:48:14 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: References: Date: Fri, 8 Nov 2013 09:48:14 +0000 Message-ID: From: Thomas Fossati To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 Cc: Core Subject: Re: [core] WG interest in Sleepy Node topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 09:48:21 -0000 Hi Akbar, On Fri, Nov 8, 2013 at 2:36 AM, Rahman, Akbar wrote: > Once again we ran out of time on the agenda to discuss the WG interest on > the topic of Sleepy Nodes yes, I'm sorry about that. > However, Carsten did suggest that we carry the discussion that we would have > had in the meeting forward to the WG list. The key questions that we need > WG feedback on are: > > 1. Does the WG want to keep discussing Sleepy Nodes in CORE? The > Sleepy Node support could be in: > > a. CoAP Protocol > > b. CORE Link Format > > c. CORE Resource Directory IMHO if we want to safely stay within the CoRE scope, we should keep sleepy/intermittent handling at the CoAP protocol and Link Format level (with RD used as a backup/complement to base Link Format discovery). So, to me this should be a.+b. with optional c. And this is completely possible -- as documented in the Publish I-D. > 2. Sub-Question: > > a. Does the WG want to see some immediate development of the Mirror > Server concept (which seems to have near unanimous support and is well > correlated to Sleepy Node support)? No, for two reasons: 1) before adopting any solution I think we should look at the different proposals on the table (there are quite a few) and be able to match them against real use cases so to decide what is the best fit for the case (or even better, for a non-trivial subset of cases); 2) I think Mirror belongs to the layer just above CoAP and L-F, and so possibly out of CoRE scope. Cheers (and thanks again for keeping the discussion alive). From esko.dijk@philips.com Fri Nov 8 07:37:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9BD21E818D for ; Fri, 8 Nov 2013 07:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.322 X-Spam-Level: X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=-1.856, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCBgN5V3CrdZ for ; Fri, 8 Nov 2013 07:37:11 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id B9CAB21E8189 for ; Fri, 8 Nov 2013 07:37:04 -0800 (PST) Received: from mail93-db8-R.bigfish.com (10.174.8.232) by DB8EHSOBE034.bigfish.com (10.174.4.97) with Microsoft SMTP Server id 14.1.225.22; Fri, 8 Nov 2013 15:36:56 +0000 Received: from mail93-db8 (localhost [127.0.0.1]) by mail93-db8-R.bigfish.com (Postfix) with ESMTP id 91B03AE0359 for ; Fri, 8 Nov 2013 15:36:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz217bI15d6Oc85fh9251I4015I14ffIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh18c673h1de097h186068hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h1155h) Received: from mail93-db8 (localhost.localdomain [127.0.0.1]) by mail93-db8 (MessageSwitch) id 138392501485708_3499; Fri, 8 Nov 2013 15:36:54 +0000 (UTC) Received: from DB8EHSMHS018.bigfish.com (unknown [10.174.8.245]) by mail93-db8.bigfish.com (Postfix) with ESMTP id 084E1A0004B; Fri, 8 Nov 2013 15:36:54 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS018.bigfish.com (10.174.4.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 8 Nov 2013 15:36:52 +0000 Received: from 011-DB3MMR1-012.MGDPHG.emi.philips.com (10.128.28.96) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.3.146.2; Fri, 8 Nov 2013 15:36:52 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.206]) by 011-DB3MMR1-012.MGDPHG.emi.philips.com ([10.128.28.96]) with mapi id 14.03.0146.002; Fri, 8 Nov 2013 15:36:46 +0000 From: "Dijk, Esko" To: "Rahman, Akbar" , Core Thread-Topic: WG interest in Sleepy Node topic Thread-Index: Ac7cK1YqMzRJhdYORw+JQXBuUFLKkgAa8Nog Date: Fri, 8 Nov 2013 15:36:45 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC27408@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180CC27408011DB3MPN2082MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Subject: Re: [core] WG interest in Sleepy Node topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 15:37:17 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180CC27408011DB3MPN2082MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > 1. Does the WG want to keep discussing Sleepy Nodes in CORE? Yes, let's continue to use the mailing list and CoRE I-Ds for this. > 2. Does the WG want to see some immediate development of the Mirror Serve= r concept First thing to do is check how well it satisfies the requirements, compared= to other methods. For that, we need requirements. For the requirements, we= need use cases! See http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs= -00#section-3 for an initial set of building control use cases. I'm open to receive any other use cases; we could publish these on the mail= ing list and collect them from there. Esko From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rah= man, Akbar Sent: Friday, November 08, 2013 03:37 To: Core Subject: [core] WG interest in Sleepy Node topic Hi All, Once again we ran out of time on the agenda to discuss the WG interest on t= he topic of Sleepy Nodes http://www.ietf.org/id/draft-rahman-core-sleepy-nodes-do-we-need-00.txt However, Carsten did suggest that we carry the discussion that we would hav= e had in the meeting forward to the WG list. The key questions that we nee= d WG feedback on are: 1. Does the WG want to keep discussing Sleepy Nodes in CORE? The Sle= epy Node support could be in: a. CoAP Protocol b. CORE Link Format c. CORE Resource Directory d. Etc. 2. Sub-Question: a. Does the WG want to see some immediate development of the Mirror S= erver concept (which seems to have near unanimous support and is well corre= lated to Sleepy Node support)? Any and all comments are appreciated! Please write back even if you answer= ed earlier Emails on this topic as we need to gauge WG interest. Thanks, Akbar ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED6180CC27408011DB3MPN2082MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> 1. Does th= e WG want to keep discussing Sleepy Nodes in CORE? 
Yes, let’s continue to use the mailing list and CoRE I-Ds for this. <= /p>

 

> 2. Does the WG want to see some immediate devel= opment of the Mirror Server concept
First thing to do is check how well it satisfies the requirements, compared= to other methods. For that, we need requirements. For the requirements, we= need use cases! See http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00#section-3 for an initial set of building control use cases.

 

I’m open to receive any other use cases; we co= uld publish these on the mailing list and collect them from there.

 

Esko

 

From: core-b= ounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar
Sent: Friday, November 08, 2013 03:37
To: Core
Subject: [core] WG interest in Sleepy Node topic

 

Hi All,

 

 

 

Once again we ran out of time on the agenda to discu= ss the WG interest on the topic of Sleepy Nodes

 

http://www.ietf.org/id/draft-rahman-core-sl= eepy-nodes-do-we-need-00.txt

 

 

However, Carsten did suggest that we carry the discu= ssion that we would have had in the meeting forward to the WG list.  T= he key questions that we need WG feedback on are:

 

1.   = ;    Does the WG want to keep discussing Sleepy Nodes in CORE?&nbs= p; The Sleepy Node support could be in:

a.b.c.d. 

2.   = ;    Sub-Question:

a. 

 

Any and all comments are appreciated!  Please w= rite back even if you answered earlier Emails on this topic as we need to g= auge WG interest.

 

 

Thanks,

 

 

Akbar


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED6180CC27408011DB3MPN2082MG_-- From stokcons@xs4all.nl Fri Nov 8 10:45:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9152C21E811B for ; Fri, 8 Nov 2013 10:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.84 X-Spam-Level: X-Spam-Status: No, score=0.84 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUQifGBdxK+l for ; Fri, 8 Nov 2013 10:45:05 -0800 (PST) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 049D511E81C5 for ; Fri, 8 Nov 2013 10:44:12 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube1.xs4all.net [194.109.20.195]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id rA8Ii3F4070982 for ; Fri, 8 Nov 2013 19:44:03 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from hotel-wireless-v6.meeting.ietf.org ([2001:67c:370:144:fda9:2bd2:a6fc:3568]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 08 Nov 2013 19:44:03 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_62d358336509f7d869ee69ff490453ce" Date: Fri, 08 Nov 2013 19:44:03 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <756c6819fa1288ae074577e536999a8b@xs4all.nl> X-Sender: stokcons@xs4all.nl (T/2WxN6KLMJL9L2CqR/iNwlxh8y2sqrU) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] CoMI draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 08 Nov 2013 18:45:11 -0000 --=_62d358336509f7d869ee69ff490453ce Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed > Dear CoRE wg, > > Unfortunately I was unable to present our CoMI draft during the CoRE wg > meeting. > Attached you will find the 3 slides and the draft. > > Question to you: We propose 4 payload formats and want to reduce that > to one. > Do you have a reasoned preference for either CBOR or EXI? > > Our plans are to make a version-02 that incorporates the excellent > comments by Juergen Schoenwalder. > > In the next version-03 we want to address the security aspects and > compare what > CoAP can deliver with the SNMPv3 security provisioning. > > Looking forward to your reaction, > > Peter + Bert > > -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 --=_62d358336509f7d869ee69ff490453ce Content-Transfer-Encoding: base64 Content-Type: application/pdf; name=draft-vanderstok-core-comi-01..pdf Content-Disposition: attachment; filename=draft-vanderstok-core-comi-01..pdf; size=42546 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nJ1WTXPbNhC961fs5NDIM7Zk2W2d5FR/JVXGslWbh8zUPUDkikRMAjQAyva/ 71uQlCU7TSYVR6I+sLtv33sL6J72RxPal6u7p9VgfH1EuR/s0yc888H9YBIXUHdLKzpJsOgdTQ4o WQ7auAkdHNLR4XtKqsEwtY7p/zzmI1opQxk7ugn2bif5OpgcUnIxGE5NYGc47J05tQw/mze1xjdl UCbsvG1zmYwz8kGFxn+gqVlaV6mgrVHld9KcjOiTY16xWVifFpLr/LHWjpHjuHa6pIP9XTwnv34f zp+NemBNCaeFsaXNNXvJ9bNd9Y+rNNgFKJscxeKHyCVCXPxnxlN7XNNMGZVzxSZQJHep0gijI/yb gZmQvweJoJCHQHuiNF4qvbc/QezB7zH2eOGDU2nomkoKbiMhrE+dXrAnqKz7qrRQHmpYI8DmFCxV EVuUDYm04WwLWMYrDbC00opm0xM/amvUztZWMknm3EU9yS7brA86FHRzOZuT46xJ14yHQupkvAdI Gam6LnXaRqIKl7aODKHFuuRHHZ5o8UQqRbzXJo/Vu0QCRomlTKZc1hb17FbsenjqqbQqE0RSFKGA ct+wD6Q9fb65utztUp2eXF2TdfRldkG3w/Mv09udLkcFgFJ36WxFN7OpkIVVuzE8dhBjdQ/K15zq peZs9KzOpQ3c/XymfdqgE3Qrsb7Jc8DBR0+YCNIVKF21HlEY6Q4uZ7vt8sI25bYyC0bPWA1YYo0/ NIflyLp8o/xNHDphISnQ94wru/YJPr8YdHzjm0WlQ4i60rIpS/FFHFgD70RdwecWDIGtfewDdU5O 53T0LkKOb99voMHi7Yo+dvpg3Z3wnNm0kfZ9r1q/mM5NDl+yw6qt0onyd/TROkC7HU7Pk49RO+Ec 8SqQRRZHubNN7SEnzFR6S5mG0fWiWSvzGoB6yU1v+xKxAi9tnFtPs6zqRW7bApMoX4RQfxiPMwUV MKJ3cGev0TjOqB93ecY/Zqkb6jXElSp1Fp2j0NqjrppKgHn9SJU1odjeXkQPIQCeaWoAEls5rkvs CHiHJHbhbckiPGau5W2DDljSPPVDrCsGG9PoF20wJNgKnFZCuqXG82v4HrWWjEbTnnIcAJATBwBK i391lIyrrjTUMxL2RqQRK6JGjq3fj95sEfUtFz9ouJbjUSHb3PZZITwPT2395HReBLGKXmN6/vp2 mN7uxO2dxFWUuMaHyKHYssZ+LG7XGciJAy9QX45Fzx6pJhTWiYGOASwWED7idpWNXrezDmzH8Sun ccQ3BivOxhrXW08XnKtyq/r8eSivucQeC3sjSYw663VFxG8HMWLzjwD9snHwdkfuj07cv+dyhEz+ QcbzZPAXrn8BrPietGVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagoxMDI4CmVuZG9iagoxMiAwIG9i ago8PC9MZW5ndGggMTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydl11v4jgU hu/zK87VTivNAAm0tHsHne6oq9KyDVqttLMXxjkJ3knsjO1A+fd7nA9BAK2SNiqIxH78ntfHx85P GA18GLmr/uaZN3ybQmK8EXyj/8T76fllA6i/eAbzFTW6Az+AVexV/XwIxjCd3sEq866epEUt0X75 qlls4cLfg1o8XboP8MqtWqOGYOSPr1f/euN7WD17V/Tk+9XG2vzX4dDqwljEgUAbD5ROhqngKA1+ ETJW369BSMA4Rm5BSbAbhIhZBBVff/L8cUPLizV1Y1ZQGxVTM2EgUrzIUNoBwDJFZhA0bgXuHIR+ NI8NgRyCM41xkab7z8CMa7OHCA3XYo2wV4UGLZKNNcBkRCBjteBuOAM7YTfuTk4aa5ZVZxIeVIT0 keVKukEB361m3GIEsVZZuzlkZEmNEpKnBXUNRZanIhbUYR5+hefKJLDEcXobqZHzK8RSGkwGtVGl JrJu5byGZ0xYCkuttsKUEbiQKHrI3a2IGC4kVVjYMa2ZtHsaoaa0xnHIy7oG1Dy4LWdnxdapk0HB UyId/PbJFEotraKiUguDnhdA0EoCx3TUFepMSJWqZN+bOKnVBeWUzZZQZn/MOPbVB3BTs8b0Y/E0 h98KWUUaou1HA7itWY7mYgxfFsuhgzLNN8LShBc0gX1ZFa3hQVwLNF3VnbOCOlZaH0V3TRVrehRj 5T+VlZZp3Vl3LV1BFaOQCaWik7dlaYHmgyynLStSK45R3Vj+6ITlcqNaIVrtOsd3mTWhm49aKypV SNbLbvFVLL9mOcaC5TlZBSHZT5WsnIac7VPFol4sR/PPeb+Hry+9dTU0v/HLuAJUojqzxke6ggtx zl/fOrMmLV3Bia4S1Zl1c6RrfK7rr8Vzd9Z9S9f4RJdDdc6JoMmvm3pNR8JwtUXdt6o6VjOPt06P Znn/WnNgBTVrWutinKMxkDHJEiz3z/6sO1cfkBda0G5HO5WhfVCzSmBXVpNf925nm73MPsZps/zR AGb8h1S7FKMqup6OHbEoGR42TCZIW2NP189YtIDeMEaNknetfqeswxryqwX0onRGXm3xGP0BVlAe LeKP0Q6sWZ6jjMQ7zOiuWzoh32DGgMBl3nVhTU9Z83NWWWBNkedK/8+5AILD2p5X+9kxgo4qa0Ej yC4z22Y5u/5kqYhqYp9Mpa7jpk7MCjo1avMJZlFE52HTPy8qVn1wPD0g0hP3RkJPtkzSQVRDaNUP +AW+acQtyrUyj++5oJHJbS1SKmCf3YvH5Oyt5O8lFQoI/iHi48r7g67/AAI18StlbmRzdHJlYW0K ZW5kb2JqCjEzIDAgb2JqCjk2OAplbmRvYmoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicdVZdc9s2EHzXr7in1pmRXX04dtK32FFSdSLblTTT dGw9QCQkIiYBBgBlq7++ewBIWXEaj2WFBPbu9vYW+E6DsyEN+Cf9zareb/NL2rregD7jd9v73huG BZT+ZBVdLbHoHQ1HtNz04r4hjcZ0efmOllXvZKq9tFr6049WbDz95N+1mU1/9pzoNvNmLS2NBsPx m+W33vg9Lb/0TvBmWUjs085bobTMaT5ZLDdNSRO9U9boSmrv6OHk2swnD2/oydhHpbe0taapSajK kfBvfu0Nxy3eTGQFgMib7uvDyWw0w2ZR16XKhFcIR67JChL4WwnrSWppt3sSOgcYw6wbVeYcKTPa W1Oe4fnoog2yqERZElAplzuVSUdaInfEXEuqhBZb/E9p4JFovKkQM6ONcAVCY9VRwgWClsgXPJTC biV9b4T2yiugmk0XwBfCk7CS5HMtM99GS+kqEIiUYtRN4xssTM9ivWeR6Zgbk0q1Nd5kpuQgWWEQ JGFtjKW216QcLW5md3Q//3Q9Ph8OVswZHnrpvNooBFzvX+Sum4rbbDYJa3aIN9UArkI2dCVcaMv0 Cm1J0O9WRA6lAbXtUdZYi63lPqHVzbpUrkDQ+8Xy42AwGK5Q18ygWCuzsLIfkrmZLK9vbz4dauQY F6Pz4SohPaEKMCtLUwPtSfmCeyWfvdQ5HjhUDloq6RzSd9Q4lsLX2Re6xwdzkHBy4QXFuhLD4Ynb ay+emadUURvknw83n2MygxFzqXMSCaqCPDnKxpqK/hH4hgZzyJcoCDLVEeDifAzGFrPpbnSIl7Cg EYvcoxwY64yHE0IWds+woaUheOkM3ny463ecCecaFN5SLq1TznMDMQkaygudYY3IZ1HVUC5I3qk8 KmGx+CPxkOBamLYRaTGkDeTUZiRkpbcK/ehzlI3aQr/8tUY/Oc1cltK3+mxXRCkx36fOQwMuFhne MZEv3lCOGvCsYfW0pbUFB8IDI0+FginEzDhFTZggnQubq39RH+Tqjn0gmtd8cqxzjM5GZDK41mwK haODSidpoVg2MYAfucBRoJi59C54CL/zIMBhIEqFEHhld5iy1lCYoa71vmh4ncGartPwDradtmLw tPgxHIVw8JcEg06z+CGXp0JqdkkYXutFgbFcbTaSx5NNpUHBbDo2YLQW2Hrp/th6jVVbpYXv1C60 wdTabuxe4p0lkMWBBFNVjU5ozK3UmYEctpHdRynr4zWYH8VKTUhMF5uEqEyjQ8BAMLg+GFSsF+yX fICE0eUtEK7a6oRj1t94HHbRpy9K81SLOJvn78/PV3FKLy/frvo0v/uShvbtYBUlzUOXgO6npx/P lPSb0wxixYeoV8c6u26NsN+dLj8ePK6pa4OTzD+Zbtrc7yFMOtYOYmNRQAR/c2e5LAibMuSOw0tk WTSOruaA0CJGe+X9Pw522m9lXUL7/7c/mINikVi4UhiYBGRl3sRzTqJ7OX9wz56V3zO9/Bhtyh65 KXHN4c4Quei/6G8hbGU01O2OpZc8n+O+nuSuoRww3GVUMKfkWZjEUMtaMD+fGh28kBYQLR/ORwxb KXIXMglztRNlE2XCVO+EVWINLXMt3flu4BdDNguNs1+UyL2lWFhRwf5sC4OLAKiw/rSp+9g04qtN 9r1RNlDk2eoylBpcsNVq67ZRfA8nY2yqwJ7HL2nDjsxjmn9rglG+Ctqed9FaO7jXJNZiXxqRv6SQ 5zOPZ9Gfi9sbuudPjMH11e38iLUwCGseQq1PM3xZwSsOx+4ZdZCdnfJBdGROrV9wLrwT70NQA8cs 0JVWqGhqodaK282HarjpsAlJIMpOk+wjnW9DbtqFIePMGXnydUr3+Fi1qkzVc6ZY0iqyVI+SriZz 3CNSyjxB/QNglH3wYb+v5Ws0xEhYgHB8JmSFrHD1UOHqKPzhYH1pY2JtGn8Ik7y+PSkQKdD1dhQa sBOsRuTmzSP9Qp+txLDotXGT51rxIfqhtqrEFb7P1/jzV3f8+zsYE435ijVZ9v7Cz3+5fQNWZW5k c3RyZWFtCmVuZG9iagoxOCAwIG9iagoxNTExCmVuZG9iagoyMiAwIG9iago8PC9MZW5ndGggMjMg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx1Vu9T2zgQ/Z6/YoeZu6MzIUegLZRv FNJebgihEOZ6Q/kgy3Ki1pZcSQ5N//p7K9n5UbhkII4jvX379u3K3+lwMKRDfrefsur9eXtCc987 pI/4m/e+94ZxAbUfsqL3Myw6peERzYpe2jeko2M6OTmlWdXbH5ugnFHh4NKJItALrws7Gb90n2gq g82Uo6PD4fGr2dfe8TuaXfX28cvY0MPo8/igUsI3TlXKhEfSgbQnv7BPhsJCBMIKksJQpgj/rcuB ZYtXf/SGxx1QJeZGhyZX5CtRlliAnbxdkfre6KUoAU2fJ1fkVO2UxzcRtDUDonMZGmxZ9QHIULyH I/rgGvzkEDTPfbxtl8otlMipRoBcBEENooIL8+I9agngFufLvja5liKotDmsasVL+bqwZWmftJlH SqqMmX95RU86LEiQ1z9VTL2FylWtDDjYlJFpqixKsIkZ0T21qZFOC71cqEqAXN4C6eCpcFBEGbli ACtl4xy+qUGqxt930+sDkHqhDJWqrFu1SMCki5t7aryYcz6OEDjnjBiBgGhzlaNYKcPua/ZVSXAo +dp0UFCVQYJF6m8OfyNIg/SQim2cVFshGHrATjM+5hBQNeRjKxIt1mZT0KX+GWtMtdUmVmmp1VPU LLJ/P70FaVVFqZyeLzq55cLqKEhcklsIa2wgo8BatKL2KWuSM1lOjbhIKLJc1wwpQ4/nfJEI78t1 USjH1WrLBBk86HqqGh9g9hYIPs5Zr2xF6zWsc9ylBlh19LZrgxn7HbnNrSg54diTqCKkrZ1davSH NiBQJWHUDwn0eTJ2lOHCnt/sNFZwwvjausAAwUpbsrmi8RkHjWcM70XtaqwQcpEM3pRlyx8rUD82 OO4ayYFFqQOygbtqJXWhkZ3u3PAwPrgcIMtGHUiIgfjaqPygmlfhcSvZ4WAIZWfKVdrY0s47X7IC 39SKnjAmPO1N7u9me/30SdfTeH07+nQ/vh1d8vXdX+dXV+uLtGInf/wwvb9q1/LVBuViOpmMri8T 0OT8370+22pvejMbT6/Pr/ZSF2rfGcLKJqogXPR6xrXAUEXPBjaWh2W8dDqLatDD7YeLo+Hw3eNu hW8xfqBOGiR6raBMBWXo1o95G6MQFTpBuHa2xLJslZcHE0T0sSUguFQ1+jPXXjbeb5gcvx4ePva7 y7e43AyVyPTNyekvTC8syEw2xY8nSCHQm1/22ZcYd13504CEfQpdxhn5oTXKDtc7BWZPCw2LCSmV 9zQZv/cpr7i/cbX1cX/0HDdJnNqY1kmeeGjEDt84C6ov0e0+2RonHJzz7XlXbSZ2qdGduSqw2W/p 17Rqxap0tT5r4006PiMTYP0znDrovnjdztaoU5ohmA8Va5furQkOdsTA6x8k3g762OeFE5Vi9v14 b61BG0fw4IXLRNfkLYwsdexNhGWY3dQnLYfLyOE5b+SaKQ7Skh0ktXap/0p8lwlmsOPx8zIBdNvo jMYxkvAequYpcngWJg46vmtRoK0K74RP5LdpbklU8SHATRP1l6IWWan6hCNQpQGJCOt+TkcC+1A4 Xa5iaCn8CxP5F++AWgCxRFZkmQP76M//MRED8lMYAJd4zuCnn7tgv9Hv9NEpPv0z60c/6ngGndfg ggetPj9svX72JPZww0fp60cgjma9T3j/B6FUKmJlbmRzdHJlYW0KZW5kb2JqCjIzIDAgb2JqCjEy NTAKZW5kb2JqCjI3IDAgb2JqCjw8L0xlbmd0aCAyOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nM1WTXPbNhC961fsqbUnkmzZbZ16pgd/yBlmYju1eMhMnAMEgiIcEmAAULY7/vF9 C5L6cNVbDqZGww8sdt8uHt7iBx2OJ3TIv+4uq8HB3Qkt/OCQPuC/GPwYTKIBdTdZ0XkKo/c0OaI0 H7TzJnR0TCcn7ymtBnuJCcoZFUaXTuSBdlwX9jrZ9Z3oVgY7V46ODifH++nD4PhPSj8N9ngkuTwl OpvdAOrt+cfpRTpKLqc3aXKVTO+G9FhoWZD21HiVUbDUGP2jUeUz6UyZoPNnuk7O938dTI57j7js /EHJ4EkbCoWiShixwPRMLbVUMD76IxofjRnz2WeKqeUijrGLxOD73ZQELZxtarI5ldp89ySFIWmN Dzo0QWH8qjEyaGtopsKYUgTLratEwJQtUAyjdYFcfK2kzjUQAeDXZHQ51irkI2mdGukeiv8GdGkB c2NDD6yf6RH6OmZVoQqvUMRlUCYb1RbePGIDj67qMhp3nhhQNKzWbmpng5W2JN/UtXWBMK9UwiMb oyjTXtqlcmJe9nA25jrlbeOk4lqtnsNzreh+z4X7/VPi9MbVAmuqQ0G1CMUpHeC98/VYKIelWsQC FYg+KoTJuJwbYWJJotUqRiF8hOeb+ahztRoTEnX0GoDboJx0DLzmALOFmENrWIzqoNJz4vhY8C/X n5DE9Etyvz+kj7PbGwKmi/PbO6ZCaEu6Rb+WAuOtIBE2fK6wodhLcNh3IJnbDA9IPIjqpdPzSJAt 5zPVrvPx+Gi8w6dmygdns0ZirmCWoCwb62FRup4AlmrlKo0lFqAciSzT7DsiaZmxrvJ2LlwQrk2s hZeFqsQac8zCB9fI0LhIhz4tIE5ARL+VkXoCpQPvbWbpQi9Vu2dBtLn1Ojyzh82Aww4cagZSeCxb WfZ0tD5AGSAVhNXqV6krFOqd63IFaIO6eb97vAorNjIZkqu/OtKOUeZhx8xH0+tK4K1Ac1XaxyEW vcRdmwUPdV4WDVYY2x4wEfb/d/o2H4nejV5f73Y+7nhtv71i5AsZUalNQX5pmd4+3qVbI5ciCEp5 666+dfn8HGQ9pg0B675g4/WPXeH7V3MgXrWUlw1Pr6+XnY+7bbc9sRBs2/disMY07l5FXZdaCqbO wYMHf94YJjnHDnhjmJ6qkt4aJvWktzz9DI6vDzisPUtRNivlYWlSkDl05kIs+RCR6TxH88M+qJQw LCGZqtHA+Ys1nZ6s9zMahq1qYZ7ZspVfYmmD0M06MRZQXs/Tu67SnnzQz7sktYHWi1L/I1rha2TR HRNCPOPUTtXso22YzkdZY7XzbUeKMLKlMHIddVNSoZR8XGi8bw85fd86gfWNjfH6E007l485SmWq bfhRtmHAJ0/kjDjIwNEs2O/0C31wiuuH9jB9qjVaFJ3VTpc4XA75gPnbf0jy9TNw0e/f4HGaDv7G 71/qAgeMZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iagoxMDgxCmVuZG9iagozMiAwIG9iago8PC9M ZW5ndGggMzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVk134kYQvOtX9Cmx 38NeA17byc3fj7zgJYY9rfcwSC0zsb48MwL871M9GhkQ5JDAM8hoprqquqfgnc5O+3Qmz/Ae59GX 50t6tdEZPeLvNXqP+n4Bhbc4p5sZFl1Rf0CzNGr29WkwpMvLK5rl0dGocGwKdid3RqWODjxuy/Ho 0OdE32JXztnQ4Kw/PJ79HQ1/o9mf0dHwlGg8uqGHuoidLguasjv+NRpc+LvYN1vw3gKqTLnUCVtS qHg9IS3EUhUzuZIqXJYmJ36v9VJlXAhgf9gCpgHIyloH9LIAUEBMaP5B06fxBLSm3BQcwkJeV5nS smfBQBMc60wdu9oAIPVbaHL3HYyKRBZpQ86owlalcacbQcASZKz+IqKUiRfasYcJsKJ3+2NBF5at 9zR1KKFMQrkq1Cvn0EepUTmvSvO2ozSGSG2dBcTvO56WRNeUKKco4VQX2svMVPFaAxDVlCNtyXDK xsAS+KQs6m707pTBY7yhMirEfOUhX46m49HL8Y/nh9vB18urn6ddFr65h/feKMsAgEsvx7Ra6Hgh etxWE3YY6K2t4DvnYE/iGwI1Xin+xTJiBTRbcaxTHQfftyajAyD0h+f9A/SvZWxcGZfZtpFd33Re ZUxP7KRBW3K7EiYtFmzDgEB2qHyxXxmzWRvtPrw6leSojXkM8qV/nyfET2bO1kpr5zA16da1LZbf 6xdp245dbdmc+G2bdXmZcNaSO++Qm3KlAhFdyNI6A4sVjMhLh/PomjMm2CttF2KSYRyTIgnncYce L8us9mDg0x6B02ZwPr1HQbcxTRzpzHZocVjXjJTCIOsi4YrxgtkDvh+LEhRMqGA3WhYQwIWaZ94/ QXMNhVewt3qJa9V4nJoy964v+7TUqrkciDh/NfTYMpCSoQEr4yUbbJbRxq2tut4eZI9EGwr6bn4K X2m3CBEYgJpOtQs6wdNGzyYCtzJnF9nWlSSXUFkyWHxU7EdCxTHktrebVkprVfGx07fPWb6TTnxH G2A88hHGe6y9PHpEsj0jsdm6XpOcuXaS7xkGWyp/u/nj/nZ2Mrq7f5qNHkb3zzYc00ppsz/U3hqk PwD3Dg9qPfH6f9XzQdStlfFaxxgEVeEuvPEelcb6GTOMzGyDx8kASTm026rsELObOnv7z8zCl06X WK7WOq9zKupcvnplxNdIPelb49q/OfTsT6TlXqAvFQihBgmiYiHJvEej16ChxQJuu2TSsPMA/RDF 4IPIgAe9tkW91pHeJqWnch9YzZdFa5XX8HXg6y1BNoHeqSvf6Bd6NCxDPC/t/bqCakvXldEZfon0 5NfI+d5PlR8TOccXP4F4P4v+wvMfHy/VvmVuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTAwOQpl bmRvYmoKMzcgMCBvYmoKPDwvTGVuZ3RoIDM4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3Ry ZWFtCniczVbfb9pIEH73XzHqw10iGcqPNqSR+kDAqXy6QIpdKVWTh2W9hu3Zu87umgRV/d87uzZg B046nXTSGSHDeOabb76ZHXiCXrcPPfuq7zT33i5GsNJeDz7he+U9eX3nAPWN5nAdo9Ml9AcQp14V 14fBEEajS4hz7ywUhinBTGeqSGrgxDWRt+EpO8CcGrlkCga9/vA8/u4NP0D8p3eGTyRAxAws2FPJ tPHBKCJ0zo0GAhnXBmQKD2fz6z+CSdwJp8EsDm/CYKF92JCsZA/nUBCu9PnvXn+4w8TLSFgy0IjM BZg1fiwY5SlnCdyG1yCX3xk1XYwaXDSYxIoUPkaJBNMLKAWVIuUqx6icaU1WDJ65WZ+i9prA31O1 3AgIaZAOJYZLAaqqnosVYO5OIbk4JheKVKr8oFRNE/43HGOUeclFYl0wrVW9heAwE4dRGbiGhGta ao3kuWjRi7A/1ueikWPY7XcHXXAd1EaV1JSK4WPrP3bWXCZlxiwwlXkhLS4yOXRc19H1N1iTDQPS SowEqeKFkQpHILFjwBMmbBlMXcHRIFp1w+nDedfVX5M5RPiQyiyTz1YTK8g8CmGNdqLoeutbophA qoQppLprmJCiUyMJtkKtkKQoczxAGr4tbiaD96PLR0yIiau2IYpiOK4cW4T2gNB1HVDJapFsdpcA cyqWMmUzEjtAulx2DowtrmBNGShSXO5KUywjBiOxmZptsJDM0tDtSRg3RLb5Sl2SLNvaXJRkRO3O 3yvPnGxPdcSQZWmD3Pi72VbyWbvuUJmVubBdjUqs2Wq5T9qcAFKz13aIBWXWZkH8Co9ZwfB7O6bl bbYFS2qUSnPLHodDJOylshzarp3aFrDePlhCxtoahQKi29DHNO5hxVhUY73rTBR8/hLMJgHMb8Cu RIRX3GW+kaqlEXsheZEx32ULi3GSqNjBpkrmbmjeDT4MH1HeitthKhOWcsHtWbtCxMNi5sXmwq38 lFBWYdXDH3+9C16tkujrLB7fn979zSLCJmiA1WxrSfFYju8748kkiKJjCFwjHUIprjeOPPYhUTyO v5xwtxctccCF2ftOg2iyCO/icD7b2wDexLvmWPENQSVQkoKpDt+xhPBuc9Gpfz5oI5a7few2WfdN bb+6+gg/UDoY9uBnq938qPJ/Ked/IuE/VAvnnTnqDbFa8jRFsecVZ3iF20u0ZKu570XDmmbT4N4J 16gtTEN3tn6+0vZoLPvO5f3A6bfBHYDbFCIj/4Lf4JNiuKXEUurgpeAKT+a4UDzDPyK+/TPy7kin b3f2F3T0iIhB7H3G1y+Eo7DbZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago5ODMKZW5kb2JqCjQy IDAgb2JqCjw8L0xlbmd0aCA0MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1W TVPjRhC961d0+ZBAlWNje7MQqnLwgiCqDQtri8oh5DCWRvbsSjNiZuQPUvnv6R6NbPmDSjDGLqn7 db/Xrwe9wkVvABf08p9JEfQnlzA3wQXc43sevAYDFwD+IyngU4xBVzAYQpwFdd4AhiO4vLyCuAjO Imm5ltz+dKtZZuHEz416iE5dB3hMrJpxDcOLweg8/haMfoH49+AM70Tl8qNDzljCQ2n1Bq6vf4Vp +PU5/HITwt/nPwaDURMNINrxURbJlK+bKrvrdLWLmSdyJpyZ4oGtp+KN471nacRc8nQ0fCc+Srm0 IhPYPfh+x2mquTFYfXsvvnknPZRslvOpZbYylP4lDu/Dyfu9JQuKj0XB/0dvE241k6YQ1iX8Z/yd 0iumUyHnNZe6GR/7D37+PGyUjhccJENQlYHF7w/RJ7DUGggDleEpZEq7O+0o54Al04Iie3uj+02t +JLrLsVphyIV8HWZi0RYKEhIJRscwjS+r444skgHmEyhc+ydTo9cYCxnqSuEveQVdeex6FLBhNxv FBKFyhlrqDyTwLRmmy7QMIDnnHqjO6uFSBYeCDMs4hi43Icy16Ak32aRRp1Tlu00E6Lo46i2SWuy RmEoVKhSflKX3Wg7pPvwo9N91Bv2/F7eVTJxEk+59QjxSoHdlNzxFg2SQf4cTFWWSluc82zjAK59 ksESeSMsYKNUs/+HFpZsRXTIKo0eXTAlT2hFUqzg9H+eRAc7DSthF1Ay/NMv5v1CzPopN4kWpUVl 8Pf4/mN026KJEEWVW1E2jZltZ7DynbmhGkLbhrYbNd3Dpo4aL9kmVyzdrzt2KGr2jScWFgzFg1bv NDk0FHaLCMyCaA4MA2j6SorXiuebvcrE1RdM+VIkHAe4K+GHYxGYpv1Wz4eCozC+I3azTeMsWjTQ aMUlQytOfY6BW9zDXJUkyqOeMyneGBnDwMvZ9Pbx5XyfIB0EfM0KFMzUSuDqGl57CQ8CJOyFqcdE DiCRFfaJZLVwi7zjV6szo+q1qEJj4Z1m3XqCL+ddgnk5Q+22l3p1O2aDy7duaGbt4Rg6WPYmN/Wt fjhYiwGCTWsv1z4g23jMMcqGkzEWrMKvSK19liDjtnNcRVp2R5/tkcVjIhO6cGE3avwE92GMZ50x bM4bMu0eWogNB9/SbnnqRXDF6Ap5C4Vqmc5UWSbWjcDNxngcl0zHa++ApuEWidUc9xkdsfBQT8+H XCbclGgkB1CK+XwzY8l3HAPC1/8dUIHxzecma3uWau0S631tiE3q3mhs9ASCgqKPkadGK6vv8APc a45OljNlwnUpEALGpRY5PmR06UHjw9FTyJ9PWBSu/kLEMA6+4utfqpnUX2VuZHN0cmVhbQplbmRv YmoKNDMgMCBvYmoKMTAxNgplbmRvYmoKNDcgMCBvYmoKPDwvTGVuZ3RoIDQ4IDAgUi9GaWx0ZXIg L0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVZNc+I4EL37V3Rx2IUqYrD5SPBtZpakqNrMziTOachB tmWiiSU5kkzw/PptyXaAIZvKzi6GspFaT92vW6/9BGM/gLG92nvKvdHNOWy0N4Yr/G28Jy9wBtDe Ug4fYzS6gCCEOPeadQGEEzg/v4CYe/2VMFQJas7+UCQ38Mrnk7xevTYO8FdqZEIVhONgMoi/e5MF xH96fZy500xsIJcK6I7wsqBgHihowilcrz5CriSHbzeXn4IwmNwD0VBpmgETbnAyDeb3QyCD371g 0iEq+lRRbYBp0FQYMBKHjGJ022BvSVFRkDnoWt+VMePUB4hxggj9jD4aiXAWyBp3YIhQKaGBwLqf UZ0qVhqphg3YegAlYaqF0bUwZGc3QIAWqiR1IUnmfCppynLWBHFLU8OkgKmPhntSbpZfI7haxh0n fir5iG9GnCWjF69xRTjfr7iNIPTHM0wC5gnDXvfbp7NLqTgxEZCyLFhK7IajHX7WgyPe1v0X6CH0 gnAync17zmbvmIvvJQCZfEf/ISUCEqQPDEmKjsyGMDTah360G0ZUSptK5IkURUO2fEaGtZYpIwan npl5cBMd8JKkD9aqAWuS3W5DbG40NRZv3U9lUXEBgthYDnOkEeXyp2IjLZYlvMkasPIzNbG8phkj sd182NRSUrtpTgTZ2LrFMWbqIbqhq8JoTOlB7eSyKOSzNTsh4wQM5xqs6N2FcOLj/10Q4Ipi3T/c aJWvREZ3MITAWe/tDq2+PNT6Q5YhKxote+NxhN8owFsQhZNoOuu9sRif2rW2DMe+vWbBWyviuqR2 H20wlvQny8G6/48L/2M0s2k0CfHh3dEs/NCf+NP3xJLVWLy/GEz4K8EsLqLzOYb0b1MTvJnM03Be URQn6a1sokLaZpBRLoU2yhUnlJWyYqFBiqLGE3zjhELRo3KlIiUlHsNOOlBeE0XSR2rQW804K4gV 9+Z8i4xtWVaRwskJLSjHg6H9No4TGX+fgO9P38q1H/RZs8SpDDFNX2M/aAf5ikKiexLQzQ1tutA+ uJwZux1KHOoJInLMAaqG3zbdDdsiO85RtycrUEpssCg02UEfShsF0J0PjYJb3ULLLVXIR67IxpHR yC9BfdoxXnHn+yFBPf2jBwUTj2e50xMgBrtsUhnqevN8vhjfd73BZdi647irDzyiOxyyGTvcpnMP Zc5Kq6xUanNmayuzMons73vvS4tt1P2o+WTEELi+u40B3104E1gbXVi2ARUU/x+BItgsdKRv0fMM XwdujXyE3+BKUSRIJFIvdyVDp+BDqViBbzRD+1YzPXnl+fYF8wOLe0Rcxt5XvP4Ge0rewWVuZHN0 cmVhbQplbmRvYmoKNDggMCBvYmoKOTk5CmVuZG9iago1MiAwIG9iago8PC9MZW5ndGggNTMgMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy9Vm1v2zYQ/u5fcfCHLQEc2bKTpTVQDO6a BQaaNk1VYMOyD7R0crhKpEJStvXvd0dRfomNDNiASQkkS3fH55577qhnGEUxjPgM17TsDR+uYWl7 I7il/2XvuRd7AwiXtIT3CRm9gXgMSd5r/WIYT+D6+g0kZe9srhwahe7igxG5gxPHL/pufuo5wOfU 6QUaGI/iyXnyV2/yFpKPvTN6sxJFjY/nUAlpIoDkCcHic40FpELBAkHY75jBoqHHKpNqCY5NRIlg 2M46WNTu/MdePOlCrqV7AgG1kRdkYBqQ5JgK1znrPLfo6OJ/5dLY7Q+FG47FUUJ0WpuhWY9N2s6Z 7ui9KMBp7ygKgyJryCtFuSInVZeUcIhF0XdBcA/Zk7AtCG1K6Ov8XR8ezxi/rp1/8Vxrh/bxPATK dVHodcvHXioUhciSVKAlkSwVOMrDBxUuItfxT56bSTSmE6CsCyfhbv6+Zd+G4LMto5QUp9MaVgUG WyPFokDLyWdaIYPATWXQ2kDtQRl8xpQO+2ZoUyMrp82AmCkKKjijpAwq0RSalgoFuL1JOhQBVUnh xRKjF/g47X+EF0IcgnwV2FaPR/BCLH54/20LcgvvkOUJV5rRgNHr4MmVL4USS8aByknXwN3sd9Y4 V860YtOqYMFCisYJBuGjkLmRaKMDgj9TjmvReDYqTGXekOppPSZg75l01j9tFdkl9u1h7htlL60+ WfX3xCkcLUrNhV1f+oC+k7TigpH9u5iYcLVRnYh4pTjoqiuqrD6hS/QdZlK0rAQQuBEl1W9KvruJ 8HDzZep1EN5GqS6H5XJYysXwKNLPHsOOfO//dQrjaHRF84h4VY5KHe4ufvUtMQVRVUVIZLihwzfY jlk+Hs/2F5vnc5XhBgYQb5vx2Or+qbGzLGOxkWV/NJrS3zSmSzwdT6aXV/1XnOku+JJrPIr4vIpf 80iaCnkd6yiTtLXc8ThTNJV4ZNPLFUlPZzwvqHEKTH0FSSY8VluZdM3hKxcKd8DJ/NOHm99YE0EU fpjptTAZjzCehyob+BAvRZ762ZQWdYZ7auMGkoYUH7R9YiCwcvukhP5u1HctfQr1Tm++VGKH9EAf pIFOWgPuE73wjSb2Wq2B3OjyWLdtfiQ5e0CNMNvmCFvVIbqXeKZwQlohMaEyOK2K6PQISXVdZLSR rHjjJLGLEIg7yO+E7f7C+wZ7BXr/Q8sddcq/apUDtb/1I/OyVfD/3MlXY2+7IpFmNB6/Ov0dfoBb g7hCtdD2ZlORTC3MKiML+oAZ8EfM5csPnD/uaROgj6k/KeJN0vtC59/MJe85ZW5kc3RyZWFtCmVu ZG9iago1MyAwIG9iago5ODQKZW5kb2JqCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nHVV21IiSRB95ysyeNjBDUAaUGeI2AdUdNkY0NHeW6gP RXc2lHZXtVXVXP5+M6ubm+NyESjzcs6pk1Xv0GkH0OFn9RlltdOHC5jbWgdu6T2vvdcCHwDVR5TB ZUhBXyHoQpjUyrwAuj24uPgKYVZrjJVDo9C1ro1IHHzyuNKT8WfrAHeR0zM00O0EvZPwtdb7BuH3 WqP673ND5lN0oZ5gLMX9YmOHcWzQWmhCvdMZ0GsQdAZn/UGvS1/qzycnX2pB7/9L0LeqAhX41u62 e+1+mfV5fLjJkXvFGyUyGZWhe4xXWllnhFQYQ4xLGaGFyfBfsEWea+PALaSFN6li0AkkMiWdpJq3 AX7XK1yiaYJMjhC7BW4g1uqL29WQrlkuT/58DEHOlTbIC5CLTapFDFL5n7ejsKJh8L1A60BQ3wX9 Scv4jFiLOYKw1PWowoqWMMvdpk0VuudbMGNqbkHES2mJn9PwhpjDZHxpIdEGogPyqJx0kthTJSuz POU2R8xyba2cpdj0sKi7wYSZSAcrXaQxzJBehJr6iKWWVHPtUFm5JPSCEu0BuB7tXJ9kHBlDQAy6 wihbsf97gQoELIWRnAYr6Raerc0xkokktLSXCJFQSjtumxtNG0ccm7Shw/sj2GWHSMcIZ+1OwIKU 7TCm/mPqFMfEXCvixdJsu0SAZaZQFS5qtM3cblmlPxUKVxocec2yUXDfk9IPEwdVLVxHmHNXoEAf 3rJOuKLUf8eT2gzzHFUs1zAkgFGkTUwGJI2rQozCFGnZ9+nh5qrXD85fCNANF14Lv5MrVpS51bei 1smjlEP67QBJ6wZH7nkY/RiwKbdl2pHOTrP5aSZnp9s6VfbD6HFQyjulHRlzdEaOIgbPDRoxsoFr EaBMuAGIPE9lJJj86Xq9/jDxz42dNE2CZ4tooWevGLnDwWXnTKgOK/FIBxM5zh9Q1XYcsQhJII6x G+XEmrc/o8xyHP6ZfCfHXN49lJ7+4/FuWsVRb2RLCbPhUfk44kBjo6yfbpKdlY2FE1tXsAd31tiD 6beDn3Fzz0pELiNV4mViZ1TWsY6mzFvB43MLo4v5gszqf5biHOGjsXY01NxEgEUPcUoD0/pLpAV7 Vho6PFc8wIAiWvgVOmcsg6+wJDpN9YpLlHocO4OrwQB8vSqhzmt1f9wQYuM9uhAOUPJJscXkW+wn O0YbGZkTQUiMzn5SmTWKMSEupR8ojpfvxtfMib8Ka3UkBTttW7Wc6j2VVDjHCIRFfw5voVYoK94H jIeX05udDbxMVaUVHXCaZnUFVpMAPm4Pz3oO8DRuXbcluqT1arVqmSTqn3cvZtK+HGt4wP03eC+0 85veyoR5Azo8WzkdrzT1Ujn49blRqBiNjfx5q9wnt+TucVyK4s7PfNyS3EQ14NHpN/gFbg3S/aVm 2o7WuaT7lA4aI1O6xpt8lfc/ln2655snCF6o4iis/aDnf6h3liplbmRzdHJlYW0KZW5kb2JqCjU4 IDAgb2JqCjEwOTgKZW5kb2JqCjYyIDAgb2JqCjw8L0xlbmd0aCA2MyAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nM1XXU/bMBR9z6+4qrQBWtuRtnxOe4C2VEFby6jZC0KT6zipR2IH JylU4sfvOgmF0FQMrRM4alLZ18fH187xyQ1sN23YNlfxZKH1+XwP/NjahgH+fOvGsrMAKB4shGOC Qftgt4B4Vt7PhlYb9vb2gYTWpiMTriVPGj1NvQQqSld9d6rqAUYsUROuobVtt7fIb6t9AOSbtYkt SriNSHNP3MFX+HC365nbgbl1IJUu1zFTmlejfoEN7P5rY2vDau0+AD7pZAB3vOq+qwAztEd6jgSV TJH5rdJuXIfbKZdQG9KQ14ApmVAhY6ASRk6vDiIBEYPmOJ+YY7ZcoNiIeHb7Ae90PBpCnGghfRAS 4QSbAg4ArkpiUF72H8GAIn9ECihDmMn8ybTiOiIaLCrdRTiOm2cxj66ZvNSapcQQDK39pEGK1D3B A/dxAgZlRrWgk8D8wZA6pLHhaFoyzi5NyjNJ5hE38xPSFYyayeJ8SIZglwf+1KguS/WrAk1Taex7 GONOyxiUyn3O9bEBAyPOhGcYCiVLsUUW18Uu5zU6Pu13ScPp9YfEOXH65wUNqjWdm/V94LWy3C+w VrRjnhPu42ZYB9ZLFVVYTj5+u1XN61VYa+U1JP1BkfH3xGvUJX3SGJNzZzh42vWYxhxVjkumXHx9 /olXISmv4rUK66WKKqxjh4yrsJb2vVGhxQZmqJxKBvO/47W07xN6zQvtQsmK8cAykmg3/9f+io5c F/U3Lrcv5/7y/KTbaR3YV6ux1smrq1JzNL+793FAU58/Y/UeeBERciLY9fN1fGtexTqiJLwvXhcy Fr7kbnkp355XbjaWu+aa86RizFl2+neaNhriCqx1eYBHz1MuhS06xCWWM1QwQwY18cHEoAFTmXMp 6JwoDfyOhlGAPszom0xD456xy0XvLLNivqahsZqMixmeHUZIJxzUxPg57paN2lSr1M9dZupGjuwt +i88H/q4ODdKuY/LFMy221dNtMBJQYupFE3jlM5y0fVUEKhbo3wqTZgK+SHG7bSyYWfIB/0qjBN1 DR9hoDmfcTlRcf8uEiihcBRpEeDnQN18EnSe5+vyjPqYr9YVIvaJ9QOvP3ZSq1xlbmRzdHJlYW0K ZW5kb2JqCjYzIDAgb2JqCjgyOAplbmRvYmoKNjcgMCBvYmoKPDwvTGVuZ3RoIDY4IDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic3ZVdU6MwFIbv+RVnerGrM+gSaEvLXb90cNS6ljt1 OimkbVyaYEhbnR3/+56krcquVa+XDISP5yTveXOAB/COCXimbft04fy4DmFWOh6c4j5zHhxiAdh2 6QK6CUItID4kU2cTR8APIAxbkCycg1hopgTTR31Fpxre2XryIn7vPsAw1XLCFPgeCQ6TeydoQ3Lu HOCT34ffHRLsrgBqy6yIRZ9qOlN0UdYggpZPwjpiBnjG/jW4kxtJVPMVy59cWM+ZAD1noFhZSFEy WJasBCpgGPeBi1IzmoGcWmZFFaeTnFXm5xkTmk85U66F5FKncsFgLZd5BhMGtISpzHO5LiMM9Jt7 05A8G5NxMG7i0cc9HJNPchESZ1TAHumiyJmRSeFsNLwEJlKZcTGzytcSbg+mPNVcCprfHsJF3H3J payoqNEu1yOtMLSGJmR4Qwwn9yzVcb+GbnE9B/1UoEPdOBlZYtg9G/SSo7g/uEzik3hw7W618vLr qb+dNoIb8FwgrjluTgjc7UaFiiQLIxC40NyQHtz961X9mGADSGzGuKzWpYqk2HhnjJF2bKsetOFd 4PZSsQKLBBebZSYxLBGqFH0yFivM0K3kZCqB5WyBeGmI9Zync0il0BRn18vC6FAsp2Y0LTcliKMc V0SdyJfFdc2EWOgDkRWSC21TeS0yu+AbYW8c//idqQxlrXzxeBOwO6/i5zKleSfL0IwywVowkb77 JdygNd/zSNQPuq0oqpOwU/sk9EoqbeIazVawH71mC6nZ11VV+FdZjV7Qj6JGu0c+kLWJ3elqeZ63 n43xC0JFauWQethq+6Sxn75SMt3qaZJG6NfbwRv22f0f16fh26pcYXln+C0bafkLvsGpYmzFxESW g8eCYxB0CsVz/Bu45o9Qh7+2mys6Y0AC8/IPEucntj8ZodOqZW5kc3RyZWFtCmVuZG9iago2OCAw IG9iago2OTUKZW5kb2JqCjcyIDAgb2JqCjw8L0xlbmd0aCA3MyAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1WTXPiOBC9+1d0cZiP2sBiIEOS2/CRlKc2IQO+Tc1B2G2jHVvySDIZ qrL/fVu2IBA8S3Y3VXtZKMqm1f38+nVbre/Q7fjQtV93jXLv1/kQUu114YZ+qffd8ysHcJcoh1FI Thfg9yBMvDrOh14fhsMLCHPvXSAMKoGmPVEsMdDwGcvboMkOMIuMXKKCXtfvvw9/9/qXEP7mvdut t8q4mIq4kFyYOebS4Mc4Vqh1C66gNeh3/avzfv/i6mpyPfZbZ+/fen7/FMK9VMaGf+h2uzai2TcQ 2jARofX0BxeXvaE/+Ln3vZKRY+WfDweX/p7nH7v7r+7OWlymg06vA3DLioKLFBakk5EwHs3m5NL7 sE3FGuBL0J50llLlTIh2RDdfgWtgsOSCqQ0kdsVAjJqnghmMrQXMCg9EMYoJnXOtuRQgE9BGlZEp FblzUUPQClEKVwSuMbJ/IeY6KrVGDSv54JKoOEVMwBKh1BRPxPFHtGIiRbgNRhAzwzoHaYSremXN FGfLjOCYQlBYUEVRmIoDJVQh56yw/LiIMeGCG4QMRWpWnYN0FmW0ogjrXGmRcW1sWMG4TclSgIRj FutO/fiEK/J4spOzywcZQdk4iKQwjAsNyEk+RbCkki2PW7C3tACC5WgfZuq0HM42uTMg+UkephTb 1KkYTFHp5zD7irzVMAsmHQdlCVMJpKgzqQnv2NnYvbg1y0p8prddgh6kfG21poKvUa05PmxZExZZ ql5IlMz3+4/0CpKj9qnlwwxzqpdFYbVkVDeLZ+uw40fPo1zOgBvbHzVfTZLt949rWtepz+CZhqr4 dV/YdVMlVP9xMK3Z6NN0HLaDyfQuDK6D6bwFSj4cCvFLu/lzZP+Zo106EOKx1mpT4OGG9ljn9bRA jgVGPOFR9WYd+LoUXotdzetID0dj14dbXtcHYjfwemzes8leCrvJUF22hkgqeocL6lRtG6jqBUno L8DavRZbQ4Y0RUSZ27ng6m7fiZdgnTI05RjUz+/3TuX4AqwTOdod4V9jCUypk9a4M7wCr9fAOmVo wgruwumN69D90P+1/3tYpwxNWLNxOA3bi3Ae3N3shy43NGvdwPsveI2CcNGEdbR/2en4NFPtdBPZ 5mW8jvrLsG/oBipNUU1HXEZD1+/8k/3rL3M871UTZE10Yyr+wshv8AZuFOIaxVLq6Y+CTi4aPhaK Z3QsPrNH48FzpC/3jA5Z/sAeKKeh95m+fwJun8pnZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iago5 MjgKZW5kb2JqCjc3IDAgb2JqCjw8L0xlbmd0aCA3OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nN1WbU/bMBD+nl9x6qQNtJLljabwjb6hSkPdIPsEfHATN/VInGC7pZX243dOU0pC KoTEpKmO4jj23ePnzne2H8EybbD0U37D1Ph27UMsDQsu8Y2NR8MuBKD8hCn0AhTqgu1AMDM2ejY4 Lvh+F4LUOBpzRQWn6mQgyExBQ+lnV+OmfoBJqLIpFeBYtnsc/DbcMwi+G0c48qdZ4XX/PkE9dPzF sN0d4ji/iCJBpawBKLpSIJVgPN503F6P+p5zZt83IX4kuw1WP1toH7pOTXXBJYs5jd6DtY8Xwxli 9PRHYL3V0YR1SRYxrVl4aDYGLKUBCx/q8XVINpax2vFqqodk46/Slmq4HpaNAZkmtAGLCEHWANkM UpJL7LihoWIZB8908NRowPp60lxe9e8T1EOI5XS2O3W1bJg65xh6fEmF1GSQ3g2eKWqdUwkqg35v cl3SGWUC6IqkeULboOYUlkSwAqK1iPIxHxBFYkFS2XqJAq3nTbhVOTUIjxAhWaBE17F9rwVMgqCz BN2CkcB4MTcQCbMsSbIneV4xpTfavxhN5ZN2O9wdMR7RGeNM0bvjCh8snSH4p4AZ6Fvgnelfz4OO DX5Rd3zwnaIxAN9FwLrZpZ+w2Bdg4XFug2fBaPgmM9c5mTKlIxcKV2wd/m4TKfp0E2AIsTvyJwJI ou8SRLElTdZtWEh9JOtFnIwHWqVuy793drerHWS5YHWKhlPUvq6bAG3TNTumrXPF9E37//R1kcpm mVlyG8MVV445hERSIHA17u1SCGOfgNLNNmh6OhVyvFFR/jIZnpiaA6l4cudiSCiP9Xix0ZT7jFmZ PMAF3wyHmUD0PONRkeY6EgTmmJ5JtzW3ko3OU6Yk0ISmyEZWZg8z3Lmlet7VdrBFfG2At5paipJw rmcyCzKl8ykPs0IBBbRCATXHzNc/kqRYrbkiKyi7UoI0UUgbd+oUXJaEQ4S7/o3KHuAzXApKl5RP Mzlc5QwpwUUuWILX4ba+Env15bz9QWIK9uk9Ig4D4yc+fwHtoHc1ZW5kc3RyZWFtCmVuZG9iago3 OCAwIG9iago3NzIKZW5kb2JqCjgyIDAgb2JqCjw8L0xlbmd0aCA4MyAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nL1WXW+bMBR951dctdKWSl1nY/OVN0JCValTu5a3dQ8ETMYWcAq0 af/9rmnSNbHTNpM2Q4QJh3t9zj22uQVyQoGoY3XNKuvzlQez1iJwir+ZdWvRHgCrS1bBKEGQD9SG pLCe3qNgM/A8H5LKGpzVnWhq0X0aN2nRgaFF8suZ6X+Ai6yTU9GATSg7Sn5aLIDk3Brgk1g2IB7S ajEXx9D9EHBwly8mdb6QZd0l6XQuDqBoZAXXIutKWQM7oSc2LOXdPIepOPpoUbaOJepM5iKHsoZo dHEFaQuFnM/lsh0iznbXuFFsHuXLdghVinGqdAE3g7LORVHWZSdujjYyYvMIeA64XHU4diarvhuD G+At4tdIDg4Hl4JrgxuB6+g5dfJ/Xg/eGvUhpE2TPurjHTxDXmd+2NMtsCJF2bQdNHK58bbigAYZ GQlvI9f8FW0e9besJx9tIzlVEVQQW4niMXWiUl6gZScG1UzancssnYd53oi2TR4XL2V8asR+RQUM IGbKrVp+b0etC409Uhdr6sUzdeSqITXq7+Ck8cEczAZG+pMCC4FzYAy4xoH56qk6eY/0lP7P+WxC 6HDMRv5wyKkXanmQ0Q63mxSYGBRwTE5B+og01UJT4FI2nTYsGgB1FV9TCMf1mcnH0d4+dvoqueN+ yFxDOrusrGUPdlp5k/GVqGQn/trIuoGRtv+faL9ORndwvO1ghoEZFlVbL/jawQ7gRqIw2w52IjYe Dp0gorqDnb0dvMkf+9tIh+w0sUmCnRaOgRNjIX1CtAoplfedik8d1rOgG5vTCsneucCe1W2X1pnu RxoCITChEIbgxFsRKPf8wKaafkq5fWtCerPFqyF7+gw3LQYmKpeNzEyGVEwYhCPwHfDHWwFc6ng2 Dzazxm/srqLOQRY7Ntf3bs2tyCTG+Xd7M7pdfd3cpzXkuAled/IXfIDTRoh7UU9lO3lYlDiDIVw0 5Ry/6I7VV53m+2+X6UzgovwdI04S6ysevwHBhgrYZW5kc3RyZWFtCmVuZG9iago4MyAwIG9iago3 NTQKZW5kb2JqCjg3IDAgb2JqCjw8L0xlbmd0aCA4OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nL1W33ObOBB+56/YaWfukhlfCwiQ7TfHPzqZSae51G9tH2SQHV2xRCQ5rv/7W8nE jS3cNr2ZA2wE7H673+6HxAPEbxKI3d6ey3X09o7CykQxvMPfKnqIEm8A7alcw9UcjfqQpDBfRnu/ BFIClPZhvo4urqXlWnL710SzpYWObazeX3fdB/hQWrXgGtI4IZfzfyIygPlNdPHcJEugyNxBUyhy oMQdOV4OLv+MEhLY09iZdW6v4dWmaqayapSQ9kaVrB5VlebGzHcNf4V4R0hx2g3jkRCAr1zmp16U As19vjFkOJi242J2alkM3FOaQTbGp1AQKJDrGBkHlkEBfoFTwAdjkBRI7I8EyAiyDAiBLOBA+u6p OzJvSV0XDvHSOE6GE3LVHw6zhI6COMjoP1YgjztyR/po2dWLoAK3StsgrWQASeH4dkHkRZ8EPFD0 404qHdkdqOS+S8XEp5wFlvk5QQfRB2elfMz4jq+V5b8t5FDASLv/P9H+MZlOBXvJHhRMcn8Z9O6g YJR4VkBGnP2hehlBBeeEoIIns3ESKjh/sYKP+eP41DKPz4q4qwRnJUxdIl2NLOI46JCr8ktfxf2A eBbYs2lgSX5xgr2WxjJZhnpMRhDHMMWeTGE0OkFIsv4gpUn4PqQv70nsxTZrU6bhG941GXRRudWq 7BLkngm+XwU9nVmQSU6zwfFcPpudDehduKxALcHwUuFIq+137x+7PvdmWrNd6/hTr+eOayYk/jXo +30hnl9NhrDleH8HmJURFa56pqmFtUKuYNOAvecwvvpwBxVfCimsUBKXR7BbBQ3T1vSOFmpnvRTa WP/QQVoM66AYWM2kqZlHsGxRc9gKew+fL56W215Lq+Km1KKxSr9VooLPlwiGmD2P3laPGWAL9chh sbGwMS6CQEVy5rmiYTeWQ2ijmT0jXnk6eD/I7w3W516YFmmrNrWzLTVnhiO1ygXly6UoBZflrudT 0fxhI3B6A6PWHPg3BEVP/bUF4abhpWB1vQO1j1rW6G2xCmsm2cpDSivsDlm7brQ5gNmsVty43I7S qR1hq/Z1V3Wttg5h3y9m2RCN0+KpOf3zK8UzubjO8pqvXVZPYsP5z2E8MglOIB+t+gp/wDvN+SOX C2Wm3xpPetRoUeP3Xs998wUz4adbtuI4x31BxOk8+hv3fwH7X0txZW5kc3RyZWFtCmVuZG9iago4 OCAwIG9iago4ODYKZW5kb2JqCjkyIDAgb2JqCjw8L0xlbmd0aCA5MyAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nL2W32/aMBDH3/NXnIq0UWk/7NiJA1IfgEJVqdO6Lm/rHlJwUDZI qOPR9b/fOdAOYicjL3OCMMnd+fuxD58fgXygQMy1/56vvY93ApalR+AKP0vv0aOVAey/5msYx2gU AfUhTr2dHwWfgRARxGuvf51rqXKp31+qJNXgaJPi07XrOcDnuS4epAKfUHYe//DYAOIbr797OZ65 nV5bD7RK8nKV6KzIYZ1s4L6f5QuZZnmm5f35+VuPsoOA2AhpD0iG6NQ/fCYIiABCbjocO9N9P5zV LcOBeSs4BBxCCqEP4QTCYBf47NdiM80XmyLLdZw8rOTZkTuh7bqorQuXZOyUZuma/ZXGJ9VPVgmc 1C05NRFMEN8IF8zcSCMGjlnZkbnEHrLeFPNkNVoslCzL+HlTx/bbsX0bWzQsR+paDvnCnL4yI6Rl aTGfAFMDYdDSesBsEN45r2oggWulkQItXRIskNtC6RqFy/MgBHdm4aRzFgbVVIeXlWBuWQZNiWiN PmhMxGPeO7kutGxOw4ZUfgkVOLmj/8TdTlMjCdtJQpsk6L6/HWFgv24ZkMZUdJE4ElG0Ywgbg3X/ O+06rGLAiZ9aluzETe46L3WSz+tZFbVDRDaE330tSJUrs71YwRwT0yzhEOJWFfPjfJodDHtCMd4m KjOVrXSX4g5F+OIf1XLQKqYHiVLJc5uCdqBeBZAWCtJMlRpU8VT3huaSjcX64vQKuI/VUAd7gAHk 0pyQOnn5jQpco2NRYT4wUt0U2Ag4B2ZlEjaOZpExMDevjIXZtDCTfELo8JKNo+GQUzEy4+A+YQ5f 2ySHBSJ81cVPeANXSsqtzB+Kcvp7k6EmGG1UtsIz4DtzDrR2jG+3yVLibvsdI05j7wtefwBqKQbG ZW5kc3RyZWFtCmVuZG9iago5MyAwIG9iago2NjcKZW5kb2JqCjk3IDAgb2JqCjw8L0xlbmd0aCA5 OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1WTW/bOBC961cMEqDbAmlWFKkP G+jBie0iQIJmWx8WWOyBlsa2dmXSIak0+fcdyg5i11SwGyC3SjZkifPem+GIz7yD+JxB7M/dtVxH v3/NYWmjGD7TdxndRawLgN2lXMPFjIIKYAnMFtEWxyDhkOcFzNbR+yvl0Ch0H8dGLhwEjkt9cxV6 DvCldHqOBpKY8Q+zfyI+gNl19P6nqJiH0afAP5201Waiqo2ulbvWpWxutXEnH36LGA9RsQGwDPgR 4SmkWcEJdqQt+rTFgfZXXGuHo6oyaO3scYMnIbKkjywJRad90Wm/dEg2mwJPgMfdhwEfAU9BhKql iRGiC+hiqB2Ce8gpnCRxzIbpJR8Ph+ngkgXLy/oSzgIJPzUq1KIpiPiYpYjjOCSb98nmB7JXyjqp ymBn2AjiGCYMRiNIp/scTOTFIGFpSLjoEy4OhG+NLnta43U5jC6gSKEY71NkLM0TMTjq0nQKfccp oKpAL2BRG+vA6O8/gy9eAq/lBhbagMVSE08A7mtmfXB2vBZfvRyIAJfeF/7fIurN4L+tCv/qh1aF oLDiaVWILjgH8bwqxvyiGA4Fy0fBKl/jXr98C7Yd8i058K1gh3zMU4eoiyJ79i3BvW9xTh0aT9/a t3LIA76VvblvUbETb117HEyQbeVMvJ1vxf69yPKDt5J001wM2Gtcq8d3XoDuo6Ux8vEZ+DJqH7iW tfLeR9jn7ceX+X2tW9s8glvVFhqUlQWn6Ye1MH902N05I5Vd1+4M5q2D2oFC7OIO9h8VLmqFIBXg AyG2qEa6Witwct7gOcBshVS/uSfPKymwVmXTVkjiSGb+gNWuMEpzU6slSAuSbkqjz8Bqr1xpSknp bQo+NzKTsiUV9KPe1lGWqx2NwbsWrSPdK7UtEB/ketNsBffz8/8JNOzxfuj7Sje4I7HOtKVrzVP6 PtTnPkfip8G6dNtMPBAVPfCTtpKOWoXQWqzOiSnJumkS55xobnblfaP9IgH/vLmmiAHrIu6JuqLp +eb0v/AOPhvEe1RzbScPm5oEYbQxdUM7yTO/mzxyv79u5RJpjf5NjJNZ9AedPwCYflf0ZW5kc3Ry ZWFtCmVuZG9iago5OCAwIG9iago4MTQKZW5kb2JqCjEwMiAwIG9iago8PC9MZW5ndGggMTAzIDAg Ui9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniczVZdb9pKEH33rxjloR9q+TBwk9TKjRSI g1wlJA2udKWqD8t6MHtjdt3dBYKUH39njUkwoWqvRNPaQjYzs2fPzux6zjdo1n1ourt88qnXuD2C 1HhN6NMv9b55fhEA5YNPoRtT0DH4LYjH3mqcD602HB0dQzz13kTSopZoa+eajS3suHrqKtplB7jm Vo1QQ6vpt9/G/3rtDxBfem/IE08Q7DJHAyZHLsYCExgtYUhInEkYIWjMNRqk2QsPg3+uLsEspWX3 b197fnuNxDhXOhEyBavAEmwJyJkVSoKQZBQ0DXL3v76a+gkLhCE4B2TZHUpQc+I71moKE2vzoNFY LBb1RZvXlU4brWbTb9DYIZ/glNUSZlmxiDpBtA7XjADe1XZdu607HO8qCwR4KPLiZtpM7kOxim3r KrySgodygXvhtWZ03f0Y9uJadB4O4ugiCm8DZ2VasyWoMaXdVhhtMdwA2nXttv4AyG3UFHW7FWzG V4m8MKNBHPaLzPwpjK57cRjXhvFtNOgHj/FdZvCwAyi5Sui0GavdcXoZRt0oHgbP4kfCmp1AZ3mO MhH3cPbLGEU3Z0lCnx5T2UfrpDwD+nJ70eu0PvhfnwHtjVFPzdxHeGtnSyUHmNIRn2O59X8ItDdG fTZLscLndzOKxRRjwe+qVbNk/Z9Ae2NUVu2wU2E0k0akEpNMVXbTizD6XM69WbgnRlH1u/QyVWOj 7Hn7uoq6ux3fO/176Gub7btyrZi0A6qnJG1gXEelBrfuyMbJDmrEjkun3q779XKIcdKjdBBMJEnY GCQdQ6uDOdOiwCVlwkh50Ot7ENb93dQ9KwRYCDsBJiuqQMgEx0IKi5ChTClgGH76HA56oWNXqALC 0EuiEzI+AcxwSgbnLOwwYWvhw0AyOiZMJvTKJ0pwdGFrdWFKzcSMUVwwx8sU+sexNRO1cCKrhHoq UB0ulAa8Z9Oclul02SzJQ5ncKOp/q5wu1CxLIFPqDjJxh0GlCifrTXC6JYacQyS0Bica9enjHnCu BA3XIrdKnx6spssfpzs4aWy4H4edNL6Dd6LVooq+ypvL1d+b6JeKs6xsGTHl64Cqm80opnXQ2AT4 mfFPY0lpBuft7nEQdPyjsxXSX60iDXMSyAl9W4eWMvcK+hpxjnKkTHifC0KhKmiRkeh+74R3Z3tD f7lhKZLnKyGGsfeJ7v8AmXi18GVuZHN0cmVhbQplbmRvYmoKMTAzIDAgb2JqCjkwMAplbmRvYmoK MTA3IDAgb2JqCjw8L0xlbmd0aCAxMDggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0K eJytVdtum0AQfecrRn5oEykBFnyXE8mJk8hSorgpVR+qPmBY2xvDLtld2/Hfd7jYhsq5uC4IATsz Z2fOnIEXsE0CdnoW9yA2rKcWTJVhwx1eU+PFIJkDFLcghisPndpAHPAmRh5HwHGh1WqDFxsnQ66p 5FSfD6Q/0bDnuBYPw33rAI+BFmMqwbGJe+o9G24HvHvjpLD2KNdyDdyP6UVtESY3PEwE4/peBH40 ElLXYOlHCzQ2mm23Zl2efjWIu0F4K/qJxkLTfhhKqpS3TugWxckhPtq+ArALtm3SbVy7g2630bkm h0BVSmnbtv254CFX2ufBLn9Sb7U7Dml8LnwkRVAuoEkaLafeccvRPUuKVem18vZBg45guBxfJXjg XrW73Tpp9Q9AekMqB/X5/wml7qZCcV2sY3B7hFCaxwqlRer/phQUSr1D3tRJz3oYXnn+OKLpym6k f84oBz2jgGYW4l5swnD2mQKfw+NwkNnUmmv/FSZCpm4gxs800JW5JqZrNk1iOnjhM0RCzBVEbE67 6Oc0t/OP8Y9ZePW7kFt2CZQZgJ5gYWUBlzLXS9Kz8oe9Vvdda/Nd6/vIzhGxh+fcsyoEZK3cR1VK YaaGjSZcpySmLGzHfSGBhglZT0OmArGkcl1p167bqAdJt140zHoLOENiIVGHsGJ6lmsFVR36MsQf TH9U6fHGebcX7j2iEmUVMz4FH+5uPBAcapa5olF0Pudixa1ASBySFL8oROqLdM2Mp2bMxgirF5Jj flGUV0JVIFmihUw1HGbrKGRMccaCWVpGgeMvfRalE5HuqWco+ZAuWUAxq1tUus5NRfVYGtaPPlzA ZCHT1wImEUqxMYuYXoMW2+IyMnAAy/kUyPTVj5OInkEguMJGbpDyPVKe9UpUuM/YLRdWU2v1I/FY jNRgkQjQcDKelzi2iAjftZjDF7iTlC4pHwt185ow7AD0E8ki/Lefpf/3Ovx1/Br5UwoO+Y2IN57x Dc8/UbB2JGVuZHN0cmVhbQplbmRvYmoKMTA4IDAgb2JqCjc0OAplbmRvYmoKMTEyIDAgb2JqCjw8 L0xlbmd0aCAxMTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVt9T2zgQfs9f sZOHA2awQwyFHr3eDb9KM1MKBfNw0/Ig2+tEYEtGkgn897crOSEOzNxdEo8de7X77fftrvwIO/EY dvjbnfN6MLo+gKkd7MA5HdPB42DsDaA75TUcp2T0EcYJpOUgrBtDsgsHBx8hrQebE+XQKHTRqRGl g3c+J/pi8t59gMvc6QwNJDvj3a30frD7O6TfBpv0ZCib7+hSfYGFFKnIKhyCsFbnUjgsYC7dDC4n pzCOd+P9eBwndNA1CFVsbQzGuws/q8/34iShh8n+4uH12Y9DOD9LAZ9F3VQY57oexXOsquhB6bka 5drgX8Z95nNcT+NaZuQgLL05hCTe+UDZEQHKwa/N7ir6ok0t3CGIpqlkLpzUauTw2f3a6kH7Y1RP R+RxZF/sbZPKGv/8RLGGK8GGn7QsPg/Xkhx2GJYO3nD1XxwxG+zplfN0hlBJ9QClTwCEc0ZmrUPY oNUbIC20lsh3+lUKcLRIiRpBl3zdy/BicgwGrW5NjkEy6SzLFodgLCA5nRvpiDhyCgIsxVRTkIpt u0RzrZ6IWOJRVB5c3JPxu3YyZySM2Qd9EkYyD6A4k6p64TDr5SOgQJsb2ThterCphuh4i7NV8rHF bZjP0CCB5dRfXUAtXiieW8G2z+uNaKBsVc7wFwkdgePbOUXJECw68mV0O515nyf66AouM4vmCeHn JDqNJboyYjkjHW7f9QAv3FO4I0uMT9tKmK5Hgv22d1wLJabMLpPpXsC2GaPPkHLRHTS2W9KXkQ2q gpcI3ygGiQHrOgIVDDv/Q9CNR9ATZqK8OwIkSVbfCAsP7wO6OPqblM+rtkAQvRSH12gbIhCjVEe3 RkZftXVDL1WI7FV+Y3WljVtg6xIk4QospaIyoCLz9GaYP6AJBOdaNJGtbTRtjL2LuyRI/VzYQGPn Jyjhk7Jw8/Xy9ttpEJNmAXUIpyeKgsrfepQNIaGABQ8EH/qVb4sdQuvrzcfyhUHdVrYV15t6l665 UM6uQPLPyXmBT74htFfPL/X1JlXobNaBmxjqtqLWESRoB3VFv4M4NLDIc84h+K4pchfsBp1jLG0D jTA0AWgboMqpSF2fMIlMNSTtjI0MVh1TGbo5ouqJG/CSLq3vfZrCtbSWzPkfzRWxzIz2mbk2D9yN CrGgO5TRCgPpNbXOSjuEPWmthyTvWKWgiHdd//oOWDrJZCh5ikz0RY2Wnma9+s9Xcq0dLsAvpKPf fWsXJAlwvpH8bKIx5oRUy8FB9AUtOvIJRBiivRnmNQlDg9h0bKKze8ydXYBnrIUsS5pKVHvCNv4h 2fWIXM7SujHS4mGvUzXAcZd1ACyW3lf65F0Kt8HmM6z77UqfhlIiPGH5UdPwHHmGY9p51iPz/C67 jRLCbsHTmgimlEzYcBjC9ZeT3b3x/jLia4j12P8akcrVM1RKInghjM+e2A/eveLUhPjMfGLxf/NM OOqHxFs+UT8X1B43Tj/Ab3BuEGlDy7Q9e24krad1Rlb0GrTNr0J7669JP6+o+CFJeOqfpYMf9P0H 4msH22VuZHN0cmVhbQplbmRvYmoKMTEzIDAgb2JqCjExNTYKZW5kb2JqCjExNyAwIG9iago8PC9M ZW5ndGggMTE4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicfVVRb9s4DH73ryD8 sHa4JIvbw9oNuIekybYMl6ZrcriHYQ+yTNtKLMmV5Db590fJ6tINucYIjEjkR/L7SOYBxqMMxv6J by6Td/dXUNlkDJ/pWyUPSRYMIL64hOmGjK4hu4BNmfR+GVxcwtXVNWxkcr5QDo1CN5wZVjo48bnR y8Wpc4AVdzpHAxfj7PLtZptcfoDN38k53WxqBJ1vkTt4Eq4Gd2gR0lyoQqgKHMsbTIFr5ZhQFhhY fOhQcXIqIVrZ0duzJLt8iegdUDn70uqI4shCoqt1YQfQaM6c0GoQjoUv8pE1hOixbItclKK3IGOm imBmHbZAZh0Cs2C7qkI6Ksg9On5fDGcjga4ccm1wGGBLxtH+GPUZ9vEhVdqJ8pBCTTg5ogJWFATk dATy0Z7ZiDlD2uqmSQeQ6tymIae07WxNJ04D5UpEl9p41wjyDEBshHixILC6M0QlefkwBjmKRzSe zov3JwQi916eNa9RsmEpGrT/q44NRhCMfhGoQMuNyIO+BF4wR47OdNx1hpIxTNlWmyA9Edp3lURr GZH8IrdrYnKNvDPCHchIWVGg6YWKZW9Ws9VHoqJp9JMlk8kdJRgdWqMfhSVjSsODnn8guMXkdnIa 6sy4v1Iv5UhWIyny9AwUImlhsBKUfM9n6GAPMopuN30fBtqs5znH6IEGi4/RSgOwtm2iKu+4luKP vWxeucW9eOV2a7V65Zrn2vjrbEwlT/hO6acGiwqln5jot8Saug3mxvoWpw6bonHwr9gqalHctw0J jv0skN46dBfz09LP3N3sn181/6kqOXWK2IX17fKO4t8wQ2QomGojmVJhDirqQgUl8ZszvgMi9tjK nQ3NdTNd3cdJKsI66udHYSl8iNJoSX0pQ0mQH2CGSF8vBqIZRKy53WmYie2uH+yl4DXDhuZawRdm nN0x2b5ouCzz+dZMVdjo6lnh8Nv2EWl4fEvBeOy1/vkrO4rxSfPO+oqWiym9msPxivar0UXHKX1f 3QC+rle3A2oXqR/pbDq/P9oWVKfnX5K4YbeF8GsaFIq7358Edf1e5NiGSaY9Y/xQ+SnrZ83QlJCn X/dUrWch6OT0Dt7AZ4NIquTazvetIE+YtEY0tNEHfqv/+fvG/35H40p/Hz8Icb5JvtHzH5aoCKVl bmRzdHJlYW0KZW5kb2JqCjExOCAwIG9iago4NjgKZW5kb2JqCjEyMiAwIG9iago8PC9MZW5ndGgg MTIzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicjVZdV+JIEH3nV9TJw66ek2RI YET2TVBnUCMsibsPow9NUkA0dMfuDo7/fqsTRD6SmYUjkaS76t66Vbd5hbbrQdu8N9d41foy7cFC tdrwjf4WrdeWVy6AzSVewSCiRefg+RDNW9U+D/wO9HrnEK1aJyOuUXLUzqVkcw01r6EIRnX3Acax FjOU4Le9zmn03Or0IbprnXi+CzDFOUrkMarTP1v+2ccDjx7dC7liOl3j/qITivhjej30Pa//BDCQ LOEobQhdG6xbfIc3IRMFcyGhUAgpB1qsQAsY8SSNmUYK4nXKTPs4p/hapBJXyDXc4RozZdkwGE7A 69omCJiUNgRMxkvw+v2e+4nZgBo5l+7MgObciemfp6ZEg2qRDUMXGE9g4sJ3MZ/TPaIwFDxOCfgg 5Uy+w3j2jLHe8N4Dm0tUBJVKJDg8ngwH4+njKSFOjELOLhCn3acFVJcXKsdxqFyKBcVSj6dURcw1 rj7UqiOI8QtKJxYS6YPljlopZ5FL1cy23EF1I4HuUhtu6ToRqFW8tCGiL6YEty7cFhlLUp7qZWof g7QiybjKhdQg5tRsFxMQa4IZBuEn5zpsx6EMWqfd/SzJXgUuikWhdBP9FPW8SiBmCuUaG2l/Z1K/ YEXXGpeLU74g3ZQoJLWyyWtobNGXoY/R7iZzaGDrUf9WtzL6sxLckfO4e+b3ZukvJJPsvdLGipYI N+H4Hi6ZZlDaQLxkfIFwXc7n7+AfpHTaZw0Mdl3C3TMD4xMjPv+1HXi+1yE7COJhJhZLmZaVL1sr cGEqFH23AsbZoprvbTyanQFTjZ5gbOQedQl4Zzu1YDScfBlNnBltTohLZY/qr2A0cEYjq6aDw+gS vF7lJAbtjpN4B4IZe/vaOz/iY8NVYqYH5UvKlQ2XH3cMzxu3iUQYLwXyN4ZZYgax3GGFWhaxLiQa MvWVOebwD0plSuaTiGEwWvul4xhmX883Hkm4aYhymWaGWf+YWafrtYnZkBlNbghKUPCE2m1qmNHQ sJRXzAypgQuhxje6bTexs6gppUiIjEFmNl3keUZOP0uzVL/TfvJ8Q606FLYnWY1CmnYzmeyW41qy FRr5rYqfQU/wMP6YtrZfS7FrzqasMDGWLLPhwf3g82/6zNE4/QPN9KZ/QowLacAGIsGsienjyUMY PJ6WNNYbJTpGPk1DGqarPMOaZj3mOZFCi1hkRsT7YLLubFU887csu/+H5dmTiYaqWPJKQOuzQza4 tsnGOcqyrSod6FljvzZROUR+iPuYqsFYQ8T8qqG0a8YhMYeIFi/wB3yTSMc+nwl19TOnXwJq08c+ KU621IWD148J4QK/a3z0Kmr9Te//ADh6jFdlbmRzdHJlYW0KZW5kb2JqCjEyMyAwIG9iagoxMDE1 CmVuZG9iagoxMjcgMCBvYmoKPDwvTGVuZ3RoIDEyOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nJWVX3PiNhTF3/kUd/LQJjOOiw2YsG/8zXoLDsVOd9pNHoQtQIstsZIMSz99r2wg NODJ1AzjwdjS75x7z/UPqNsO1M3ncI6z2m+zNixVrQ6P+F3WftSc4gY4nOIMehHe9ACOC9GiVj7n gNuAdvsBoqx263NNJaf6fiDJQsOVoy8m/rXrAE+xFnMqwa07jbvoe63RgWhcu8V/vs1G/UbTeXgF mEqq8hW3YGZbcDMhnCxpRrkGny+EzIhmgkOPKAovtxO/93IHeBn0it79WnMaxwXPjpBlm5RCQPVO yDWcrTiVQotYpLhSGEymL3c3FoTRADwXdx/1ccF3SxlECwY0plmpo+7aeJfr/UdH58FDHT1jk1T3 Y0otiFDLiNE0YXxZKiM8gbGNNIoZR1HqM2dGYJWMGVUilzEFP0F2tmAI8HL7PPNf7j7BI8W9WAzh nmvy8yjDq5KBhBZ8ITwncm9UtC5VNB2ngSpGlHND17ML4i82jFIWrz+oDP6skoGFgmeF7AOiyVKS 7LwKz4OyCLg/GACEzDmtInQ7DhJ+ZhwNMaYWhKGN9UEvjM83/hT+xBoYLg+6SYKthXYvq9i6Ml4x TWOdS3qkwE2wdHQuj155V0mMVzOR6xUzboUfte4HLXsM2bk3/pk1uJ8F3Y1kaRVRp9lEoonAhThd SmHBIzL9nqsVSRGLIGSAFz7nDD0+tOPAhn6epiigiusmkoSrjKnCUrEAf7r1YEriNdUKxBbL6g+H Q3jAXDgtu3nZeocUqqMS5ES76EafEtW+VOPV3bpJ1Hd8Ms15YsHEGPxXN3iEe+gWrYRaE5picWFM +DJH5z8y+TgQ+oIv2DKXZXnOHA+GUf8pGJ1sNxjWpaSzqVa/wu42TZcOOVdl8N+pCOOVoHxHcDaY zjnWomtXYfewwzKCDX/zfwVcohu4U8Yc5wp9o9l+LWZPLGRKLBiWKQts4zdJ8mWOIKcoF+2xEVJj Efa0cgaENM4l0/tTOB3bPXqMG56PJufKgPW8ponbFefK/kxLI7A9Qy3zIs3mx1seq2P3FtMjmmte DhN/6+KLBl83RnaeUgVagOm/S08PNxz1IKtxOK0W0zK9PSLp2mgo3J3YmNR4RSXZ7VFUX9KSyfyH s9OIGWaEpVU6RpQmcwwl1s0UQ32CLsdxscHJTeYsNc6HmuhyNh1SAt15ruilnHIJk6tR4Q3a0Z2d ZQLx3zroqr6O0ReuaDpHMX+bKmHDKi0J4zSB2TCMFnmKAdkyKbhBUrhHX8yG6PiY8XWlyoLnxNFB ji72o9JVJO126x1Jf0XWkswJCiyHdiBkkhG5No1eBrFvQ89sxHn1VAwoW67m6OOAYU5wCu7haaNZ xv4p62YsLiZlMSHHYnc/FbsiHu9W+sokxd5RMMXuE5yk+Eqi5DQ00RdvLL5Ou4F6KwCqujKUAtzq MFFLL7xWQb4lHDAuWH+xhl/gUVK6pXwu1PDnBjdXp7eKZZ5swrvj29QMVrf1iisOo9of+PkXNKfA B2VuZHN0cmVhbQplbmRvYmoKMTI4IDAgb2JqCjExMzMKZW5kb2JqCjEzMiAwIG9iago8PC9MZW5n dGggMTMzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicnVZdd9o4EH3nV8zJw25y jm0MbEPatyTQLDQQFmjTsyUPwh5AiSU5kgykv35H5qMEzGmy5oDBlmbuvXNnzDOEQQVC91qfI1Eq 9+swNaUQbug9LT2XKvkCWJ8iAVdDWnQBlSoMJ6XVvgpUa1CvX8BQlE5b0qKWaP2GZhMLBce16rSK rgPcRVaNUUM1rNTOho+l2kcY3pZO6c6Plt8IONqJHymN9MHSh7M/S5XaZsHOMZhhMn7x4N/Ag7+Z tk/owRf6zmQM1wFcKS2YlB6cXCtprGZcYkyx9qJcpmnCI2a5ktDTyqpIJTA6vVaXvdHZiQexo+e/ huRXLg4DjU4XSj8Bl5BqNdVozOjMg3YmMecZ0I7q+RGeU62yNFJCHCXbZzNi48FlkPNrBtDgj09E 7sZtJa2FyOSGx0RpcAROvEOY+3y2qf3K+REO63IdxvotL+5MMmERmjdUMSfWCeAbZ0letX4TWtsA r0txiGUvnx+G/6MiqE3mSrz1iy+mwh7F3nTLPcLsQV8JZiImMw8aaw+2AxhEM4VywTCJURcU46TD JJuiQGlBTaCL1iE2sOB2Bju2hQbOObH65Cw6TlAchhpYZvNAHnw1CNfMoMlh9PE54zq/9UvEFdEi FV9T98PaERk/41hnTL8USTkYNsIwrDwAUB3vJhMeUUlhMzG2bWYcaBkzHROuexwfk3lmbfqpXF4s FoGeRD7G3CodKD0t08/lMgyDmRVkmT0Uze+th1UAQtHMUTidv3duV1CiGZNTfHPqRS1PuRRJGZf8 IBuF3cm2tCgNp0pBh+knatBbypVRqUlNWplPlvemPUjZHtx1HzYp22zOBpHmqYW78SNGFrrKrsbB 6NStfEfOR6Oky1okqZ9qLlAf7YkeUhNKcjv1Qe6/QUDXNI0m498gamvQzWSKBKtIW1S/1WDYd8qv AZCTMUKxeoyEHwuACmQmWxn/KNr7GbfUwTfUsl+oQmwwY/qRerhNF+55knAmjEcUVh1NjK50Zn+6 SVzQzEc9Bp1fUIyrC76LNPGrl+8bviO/Q8r47kZYr34oANPOEteaYb3AM77z6jFFupk2SA0296BL tHssS8gN6yGHL1IlMSnS3z5nD1O35M9M05Rm+RAXKdOcIrj55pLn25w+DWbZrkiHgT67J7iloXeZ jzOaFln88gblIhMIJWm0sADjrMzXcMppNjblyA233DFpPCkQbmOmD9VcnDmTZDRNudUT/AE3GnGO cqxMc5nSVDX0/0HzhHZ5bhD+BXvHj57r+eq5k7s5LP1Dr/8AgKaOHGVuZHN0cmVhbQplbmRvYmoK MTMzIDAgb2JqCjk2OQplbmRvYmoKMTM3IDAgb2JqCjw8L0xlbmd0aCAxMzggMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy1Vl1P20AQfPevWPHQglQgH9BQ1CIFCCgSadrGRZWqPpzP G/tovGfuziHpr++eHReCEDhSsRM5Oc/Mzs75bN9Ca68NLb+vjjIL9r/1ILFBCy75mwS3QbsEwOog MzgNGXQE7Q6E06DitaHThV7vCMIs2B6SQ0Pods+NmDp4YjvTo+FT4wBj6XSEBjqtdncnvAm6HyC8 Crb7eY4UqwX09wB+jK5gIlPMBEy1gdHwdOdt0HlfAlkiTJUFURNitNKoCC24FEuqraguFY7PThWt zuViOdMiZq12t9aSmnshZ+tCYPC2QMsDcyVKVtnKRUHSKU0wQccGhw68BWuLDL2eVyrLeYW5MEpE My4qDLLeFI3BGKLlymruuBR/eGA8PN9bb218Pj7mBrFughBjdq8hQijyWDhW4n9VWxAJqyS4Ze6L 0XpnpJ2aKim8bcue+1KitZCJpdfKNHuzOuconQd52VTQvzRjSNHgurmPCxsfW5XlMwy5JJDI8NNW pJzdOlkrXWMNB2lUFRxbZXCpwGOUlJTt+qoo4UgcpykNc4izohJvbe3fQ5/BtRviOg1x3Ya4gwp3 H9OzaKrQ61ntPwqrrluduE/8pMF04EJi7kVebU5ITwqZjqMblO5hRi9ShmSdIIkNSby8x9ORiq4V 3q1R/m9exmizy8Zc8XqXMemBL/NS4zXcaX2qkqboKtzP3E1TRiTia/+rKd6giMc0WzbFJ0jcb3P/ 1a2pKf7OaEr8DG5EuEJKXLoRZUBSx36ONyFtFCzpM862XK0NGYo9keWbNj+0NpxDqwsj8TuJuVAz /4BqSpU6y5S7YBbGTTkFxXozhihcqo36U44+WC6HnXI9zsuHk4GJ07/hDVwaxDlSpO1gkStuDvq5 UTN+rXjnXy0O4NH284tIEDq9X6w4CIOvvP8FDw+8BGVuZHN0cmVhbQplbmRvYmoKMTM4IDAgb2Jq CjY5NAplbmRvYmoKMTQyIDAgb2JqCjw8L0xlbmd0aCAxNDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJzVVVFv0zAQfvevOPkBNglokgItaEFibJoqMQojEg+IB9e5FkNip7bTdf8e O03UZnPVguCBRE1S331333dnnZcQPYsh8nf75iUZ3IxgYUgEV+63IEsSNw7QvngJ55lzGkOcQDYn G1wMyRBGozFkJTmZSItaon16odncQuB6p64noXWAKbdqhhqSKB6eZj/I8BVk78lJZz5bm/w1yrpE zaxQEmDFihpTKpX9ooVlswLp4M3pYxIPjwMKyZU0wliU9gMrW3SLOxt4mEZjteAe1tk2BiPKqsDs rkK/nrzsMjbJuPLGtbeCdIFTej05N5wVTNMHBBsEsy7NrLadv39SsC5ASpt0ziwXfYJNpu9KcNxZ DYdrBB+IdyRSuA4vUAdq1efSrm0rcWydNhnDZfrP5G53cFAupFSJfI9Ug8saZUAsFli6DdsSFrn7 DhHegUEp5JTzWpuUxhRKtu7+1XKmapljHtB3n8CfNBSajjYcxVzgvt2/p619pTkarkVllT7U2RB6 OrnoYL7m/6KdKdXq9je6GaLpvvRdR3Q7NHZR/X5Gf7efByU6TlkzacM6+2qc8+4g62+FB7MsWKNQ 2BtX5jakr7hzf5E0RFZMQu5OkM9W/YRHcKURV+hKYi7XlXCjHN5WWhTugHniD5nncO/6+pEtEJLx NxfxMiOf3P0LQs8LvmVuZHN0cmVhbQplbmRvYmoKMTQzIDAgb2JqCjUxNAplbmRvYmoKMTQ3IDAg b2JqCjw8L0xlbmd0aCAxNDggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJylVW1v mzAQ/s6vOPFha6W8kWzri9pJzdpVkZolW5g0qeoHYw5wBza1TZb++xlDGkjTqOuCIrDvec53j8/n Bxj0PBiUT/2mmdP/cQSxcgZwbf6x8+B4FgD1i2Yw9g3oGLwh+JFT8TwYjuDo6Bj8zDmYcI2So+5e ShJp2PH7IqaTXfMAM6pFgBKGA2906N87oxPwb5yDBiJjfEZpIdW567mQkdV6VPBAFDzE0O1/Pnzv eKMG86y/UuGpwocCOcXSfPA0S0WWp7jyH3NrGH5a8862rMBJhufudDKeBfdItftsmYqCKWbI9QZe frigjQs7ZKGxsoihrCLdQ16StGhSq3F/bwK1ZBd5jjxkKxj3AH5Nb2BBE8wIREJW+qsiz4XUrZT9 hCkga2aIikoWoAKdoPWhKh86IdpYI8ZrW04eU0HClh5UmDrgWtkVZSm9MoMlI5ZhQ/hacKqZ4LBA DVpsDMIKrOo0SwdZkWpGidIQS1HkHQiYiZHHoEmQYgcID2HxbToHLkptKSn9KpP6V0M2fmtXzyF2 0XHtbIo6EWHlE1SO9AkHIqpd3E66lz2GOupSIbHLymqPCEV1B5AQBQEiB1yZ3E0twh+mE3Dtio9u byP2uOeZ4Fp7cjFfJ1WvNG6maPUkzASscImSpKBYue9rlOpAWQhCmUVFBJpllaPNhuREmqIy0Sqr 1pP4isWc6EJib7v8d1R/GWZmVdpd/qfSbLNkleeAKEMxk+UUj91mtddw5EVmsrFwW93n7vWV3z4Y L0PnP18PnS22sOXpaYbbPFV7u8IOWeqNm/6/Mi+En4s0bYb/AkwE6hWovFDJK2B11b5ZtE3z3i0a 40tRna5nitmIWq0wEUo3G+lGu+1EWrSc6OQNtMmchKFJU/0jr10HNbc9uZffOF41uTHT3yf2x6FV b0m46cwSFlr8hndwLdF0C3MzqqtVzkxCcJFLlpr7tVPesR+279/bOYkRhid3xuOV73w3z1/dynDG ZW5kc3RyZWFtCmVuZG9iagoxNDggMCBvYmoKNzQ3CmVuZG9iagoxNTIgMCBvYmoKPDwvTGVuZ3Ro IDE1MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJ1U207bQBB991eM8lCISowv ITdBBeEaiZaUuH0pfdisB3uLvRt21yT06ztOjIghoqVrWSvPzJnLGc/cg+f64JVPdfPc2b3uQmIc D87pTZx7x18aQHXxHIYRGfXADyC6dVY4H4IQut0eRLmzPZIWtUTbOtHs1sKGc6w+jzbJAa64VVPU EHh+2Ix+OWEfoktnmzT7CzPgKp9luIgeZwiS5XjQMKKUDIWMhUwan5pbjh8+IZanhGGGOUpbQXK0 qYobYMnLQUPIB8WZFUo2dkv4W0Ahx6jFM5YsBNWaoP47li3+G8tTJhOcWJy9Bd7frRNUyoPO2+xN V7xBxKYZvmKvxBi8L1ByrKW4Icd6H6o068Kah/IQn1ecF9ocNLwGEENPX4WcqkLGGK9Ts6zvZTqb it4LliUM3cAF+M4yEcOEp5gzU2PkTGQrGgwwjWCs0hiDkJXxU4CNvK1MWrfkwryg7T2krdysNdVY vYGp9/D0zyxVg3VU0DBoswVHcazRGKyTNEYaZXhgEmK6J1bd1YrlSpois0zaOipVEgfwMfRb7X7Q 7rY73RButr/Q4KHOmIzNTXOH1GGr3+l4/l7Q7pH6TDPK+aZZi3CaM5ENngPxx0PKhpKhft25SidV id+uRwO65vO5+0r/vEOGqC2ca8QHJOoMT2uxLgo2RwER8lSqTCWCfo1j5e7ApY3dKk5lM5JxUTaL ZTBkBivlkIgQTBJAySShoYUTUVpxWxlMUpS/6QXY83t+0K/EY/faheNUSFajsaqd1qF1k7WkD9Nl Ei51lOzLpUv26z2CD2tFni5mgjoLRzMtMtqrO+Vubb/cuz/GLEEIvZ/k8TRyvtLzBwrpvkhlbmRz dHJlYW0KZW5kb2JqCjE1MyAwIG9iago2NDIKZW5kb2JqCjQgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDkgMCBSCi9Gb250IDEwIDAgUgo+PgovQ29u dGVudHMgNSAwIFIKPj4KZW5kb2JqCjExIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvVGV4dF0KL0V4dEdTdGF0ZSAxNCAwIFIKL0ZvbnQgMTUgMCBSCj4+Ci9Db250ZW50cyAxMiAw IFIKPj4KZW5kb2JqCjE2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAxOSAwIFIKL0ZvbnQgMjAgMCBSCj4+Ci9Db250ZW50cyAxNyAwIFIKPj4KZW5k b2JqCjIxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAyNCAwIFIKL0ZvbnQgMjUgMCBSCj4+Ci9Db250ZW50cyAyMiAwIFIKPj4KZW5kb2JqCjI2IDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyOSAwIFIK L0ZvbnQgMzAgMCBSCj4+Ci9Db250ZW50cyAyNyAwIFIKPj4KZW5kb2JqCjMxIDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzNCAwIFIKL0ZvbnQgMzUg MCBSCj4+Ci9Db250ZW50cyAzMiAwIFIKPj4KZW5kb2JqCjM2IDAgb2JqCjw8L1R5cGUvUGFnZS9N ZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzOSAwIFIKL0ZvbnQgNDAgMCBSCj4+Ci9D b250ZW50cyAzNyAwIFIKPj4KZW5kb2JqCjQxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA0NCAwIFIKL0ZvbnQgNDUgMCBSCj4+Ci9Db250ZW50cyA0 MiAwIFIKPj4KZW5kb2JqCjQ2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4 dF0KL0V4dEdTdGF0ZSA0OSAwIFIKL0ZvbnQgNTAgMCBSCj4+Ci9Db250ZW50cyA0NyAwIFIKPj4K ZW5kb2JqCjUxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3Rh dGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdT dGF0ZSA1NCAwIFIKL0ZvbnQgNTUgMCBSCj4+Ci9Db250ZW50cyA1MiAwIFIKPj4KZW5kb2JqCjU2 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA1OSAw IFIKL0ZvbnQgNjAgMCBSCj4+Ci9Db250ZW50cyA1NyAwIFIKPj4KZW5kb2JqCjYxIDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA2NCAwIFIKL0ZvbnQg NjUgMCBSCj4+Ci9Db250ZW50cyA2MiAwIFIKPj4KZW5kb2JqCjY2IDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA2OSAwIFIKL0ZvbnQgNzAgMCBSCj4+ Ci9Db250ZW50cyA2NyAwIFIKPj4KZW5kb2JqCjcxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA3NCAwIFIKL0ZvbnQgNzUgMCBSCj4+Ci9Db250ZW50 cyA3MiAwIFIKPj4KZW5kb2JqCjc2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5 NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0V4dEdTdGF0ZSA3OSAwIFIKL0ZvbnQgODAgMCBSCj4+Ci9Db250ZW50cyA3NyAwIFIK Pj4KZW5kb2JqCjgxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9S b3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4 dEdTdGF0ZSA4NCAwIFIKL0ZvbnQgODUgMCBSCj4+Ci9Db250ZW50cyA4MiAwIFIKPj4KZW5kb2Jq Cjg2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA4 OSAwIFIKL0ZvbnQgOTAgMCBSCj4+Ci9Db250ZW50cyA4NyAwIFIKPj4KZW5kb2JqCjkxIDAgb2Jq Cjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAw IFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA5NCAwIFIKL0Zv bnQgOTUgMCBSCj4+Ci9Db250ZW50cyA5MiAwIFIKPj4KZW5kb2JqCjk2IDAgb2JqCjw8L1R5cGUv UGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA5OSAwIFIKL0ZvbnQgMTAwIDAg Ugo+PgovQ29udGVudHMgOTcgMCBSCj4+CmVuZG9iagoxMDEgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEwNCAwIFIKL0ZvbnQgMTA1IDAgUgo+Pgov Q29udGVudHMgMTAyIDAgUgo+PgplbmRvYmoKMTA2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMDkgMCBSCi9Gb250IDExMCAwIFIKPj4KL0NvbnRl bnRzIDEwNyAwIFIKPj4KZW5kb2JqCjExMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAg MCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMTE0IDAgUgovRm9udCAxMTUgMCBSCj4+Ci9Db250ZW50cyAx MTIgMCBSCj4+CmVuZG9iagoxMTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRXh0R1N0YXRlIDExOSAwIFIKL0ZvbnQgMTIwIDAgUgo+PgovQ29udGVudHMgMTE3IDAg Ugo+PgplbmRvYmoKMTIxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAxMjQgMCBSCi9Gb250IDEyNSAwIFIKPj4KL0NvbnRlbnRzIDEyMiAwIFIKPj4K ZW5kb2JqCjEyNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90 YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRH U3RhdGUgMTI5IDAgUgovRm9udCAxMzAgMCBSCj4+Ci9Db250ZW50cyAxMjcgMCBSCj4+CmVuZG9i agoxMzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDEzNCAwIFIKL0ZvbnQgMTM1IDAgUgo+PgovQ29udGVudHMgMTMyIDAgUgo+PgplbmRvYmoKMTM2 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMzkg MCBSCi9Gb250IDE0MCAwIFIKPj4KL0NvbnRlbnRzIDEzNyAwIFIKPj4KZW5kb2JqCjE0MSAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTQ0IDAgUgov Rm9udCAxNDUgMCBSCj4+Ci9Db250ZW50cyAxNDIgMCBSCj4+CmVuZG9iagoxNDYgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE0OSAwIFIKL0ZvbnQg MTUwIDAgUgo+PgovQ29udGVudHMgMTQ3IDAgUgo+PgplbmRvYmoKMTUxIDAgb2JqCjw8L1R5cGUv UGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNTQgMCBSCi9Gb250IDE1NSAw IFIKPj4KL0NvbnRlbnRzIDE1MiAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2Vz IC9LaWRzIFsKNCAwIFIKMTEgMCBSCjE2IDAgUgoyMSAwIFIKMjYgMCBSCjMxIDAgUgozNiAwIFIK NDEgMCBSCjQ2IDAgUgo1MSAwIFIKNTYgMCBSCjYxIDAgUgo2NiAwIFIKNzEgMCBSCjc2IDAgUgo4 MSAwIFIKODYgMCBSCjkxIDAgUgo5NiAwIFIKMTAxIDAgUgoxMDYgMCBSCjExMSAwIFIKMTE2IDAg UgoxMjEgMCBSCjEyNiAwIFIKMTMxIDAgUgoxMzYgMCBSCjE0MSAwIFIKMTQ2IDAgUgoxNTEgMCBS Cl0gL0NvdW50IDMwCj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMg MCBSCi9NZXRhZGF0YSAxNTYgMCBSCj4+CmVuZG9iago3IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRl Ci9PUE0gMT4+ZW5kb2JqCjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTAgMCBvYmoKPDwv UjgKOCAwIFI+PgplbmRvYmoKMTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTUgMCBvYmoK PDwvUjgKOCAwIFI+PgplbmRvYmoKMTkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjAgMCBv YmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMjQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjUg MCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoK MzAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMzQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRv YmoKMzUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMzkgMCBvYmoKPDwvUjcKNyAwIFI+Pgpl bmRvYmoKNDAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNDQgMCBvYmoKPDwvUjcKNyAwIFI+ PgplbmRvYmoKNDUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNDkgMCBvYmoKPDwvUjcKNyAw IFI+PgplbmRvYmoKNTAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNTQgMCBvYmoKPDwvUjcK NyAwIFI+PgplbmRvYmoKNTUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNTkgMCBvYmoKPDwv UjcKNyAwIFI+PgplbmRvYmoKNjAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNjQgMCBvYmoK PDwvUjcKNyAwIFI+PgplbmRvYmoKNjUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNjkgMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNzAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNzQg MCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNzUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoK NzkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKODAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRv YmoKODQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKODUgMCBvYmoKPDwvUjgKOCAwIFI+Pgpl bmRvYmoKODkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKOTAgMCBvYmoKPDwvUjgKOCAwIFI+ PgplbmRvYmoKOTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKOTUgMCBvYmoKPDwvUjgKOCAw IFI+PgplbmRvYmoKOTkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTAwIDAgb2JqCjw8L1I4 CjggMCBSPj4KZW5kb2JqCjEwNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMDUgMCBvYmoK PDwvUjgKOCAwIFI+PgplbmRvYmoKMTA5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjExMCAw IG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoK MTE1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjExOSAwIG9iago8PC9SNwo3IDAgUj4+CmVu ZG9iagoxMjAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTI0IDAgb2JqCjw8L1I3CjcgMCBS Pj4KZW5kb2JqCjEyNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMjkgMCBvYmoKPDwvUjcK NyAwIFI+PgplbmRvYmoKMTMwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjEzNCAwIG9iago8 PC9SNwo3IDAgUj4+CmVuZG9iagoxMzUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTM5IDAg b2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE0MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagox NDQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTQ1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5k b2JqCjE0OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNTAgMCBvYmoKPDwvUjgKOCAwIFI+ PgplbmRvYmoKMTU0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE1NSAwIG9iago8PC9SOAo4 IDAgUj4+CmVuZG9iago4IDAgb2JqCjw8L0Jhc2VGb250L0NvdXJpZXIvVHlwZS9Gb250Ci9TdWJ0 eXBlL1R5cGUxPj4KZW5kb2JqCjE1NiAwIG9iago8PC9UeXBlL01ldGFkYXRhCi9TdWJ0eXBlL1hN TC9MZW5ndGggMTM1ND4+c3RyZWFtCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2Vo aUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+Cjx4Onht cG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIuOS4x LTEzLCBmcmFtZXdvcmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9y Zy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNv bS9pWC8xLjAvJz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzcyNjk2Y2ZiLTZmMmMtMTFl ZS0wMDAwLTExZmM3ZGNkN2RjJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEu My8nIHBkZjpQcm9kdWNlcj0nR1BMIEdob3N0c2NyaXB0IDkuMDQnLz4KPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9JzcyNjk2Y2ZiLTZmMmMtMTFlZS0wMDAwLTExZmM3ZGNkN2RjJyB4bWxuczp4 bXA9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nPjx4bXA6TW9kaWZ5RGF0ZT4yMDEzLTEw LTE3VDExOjM4OjM3KzAyOjAwPC94bXA6TW9kaWZ5RGF0ZT4KPHhtcDpDcmVhdGVEYXRlPjIwMTMt MTAtMTdUMTE6Mzg6MzcrMDI6MDA8L3htcDpDcmVhdGVEYXRlPgo8eG1wOkNyZWF0b3JUb29sPkdO VSBFbnNjcmlwdCAxLjYuNS45MDwveG1wOkNyZWF0b3JUb29sPjwvcmRmOkRlc2NyaXB0aW9uPgo8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nNzI2OTZjZmItNmYyYy0xMWVlLTAwMDAtMTFmYzdk Y2Q3ZGMnIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBN TTpEb2N1bWVudElEPSd1dWlkOjcyNjk2Y2ZiLTZmMmMtMTFlZS0wMDAwLTExZmM3ZGNkN2RjMjAx My0xMC0xN1QxMTozODozNyswMjowMCcvPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nNzI2 OTZjZmItNmYyYy0xMWVlLTAwMDAtMTFmYzdkY2Q3ZGMnIHhtbG5zOmRjPSdodHRwOi8vcHVybC5v cmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Zm9ybWF0PSdhcHBsaWNhdGlvbi9wZGYnPjxkYzp0aXRs ZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPkVuc2NyaXB0IE91dHB1dDwv cmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjwvcmRmOkRlc2NyaXB0aW9uPgo8L3JkZjpSREY+ CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBl bmQ9J3cnPz4KZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBHaG9zdHNj cmlwdCA5LjA0KQovQ3JlYXRpb25EYXRlKEQ6MjAxMzEwMTcxMTM4MzcrMDInMDAnKQovTW9kRGF0 ZShEOjIwMTMxMDE3MTEzODM3KzAyJzAwJykKL1RpdGxlKEVuc2NyaXB0IE91dHB1dCkKL0NyZWF0 b3IoR05VIEVuc2NyaXB0IDEuNi41LjkwKT4+ZW5kb2JqCnhyZWYKMCAxNTcKMDAwMDAwMDAwMCA2 NTUzNSBmIAowMDAwMDM1NjQ4IDAwMDAwIG4gCjAwMDAwMzkwNzEgMDAwMDAgbiAKMDAwMDAzNTM3 NCAwMDAwMCBuIAowMDAwMDMwNDcyIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAw MTExMyAwMDAwMCBuIAowMDAwMDM1NzE0IDAwMDAwIG4gCjAwMDAwMzc1NzcgMDAwMDAgbiAKMDAw MDAzNTc1NSAwMDAwMCBuIAowMDAwMDM1Nzg0IDAwMDAwIG4gCjAwMDAwMzA2MzEgMDAwMDAgbiAK MDAwMDAwMTEzMyAwMDAwMCBuIAowMDAwMDAyMTczIDAwMDAwIG4gCjAwMDAwMzU4MTQgMDAwMDAg biAKMDAwMDAzNTg0NCAwMDAwMCBuIAowMDAwMDMwNzkzIDAwMDAwIG4gCjAwMDAwMDIxOTMgMDAw MDAgbiAKMDAwMDAwMzc3NiAwMDAwMCBuIAowMDAwMDM1ODc0IDAwMDAwIG4gCjAwMDAwMzU5MDQg MDAwMDAgbiAKMDAwMDAzMDk1NSAwMDAwMCBuIAowMDAwMDAzNzk3IDAwMDAwIG4gCjAwMDAwMDUx MTkgMDAwMDAgbiAKMDAwMDAzNTkzNCAwMDAwMCBuIAowMDAwMDM1OTY0IDAwMDAwIG4gCjAwMDAw MzExMTcgMDAwMDAgbiAKMDAwMDAwNTE0MCAwMDAwMCBuIAowMDAwMDA2MjkzIDAwMDAwIG4gCjAw MDAwMzU5OTQgMDAwMDAgbiAKMDAwMDAzNjAyNCAwMDAwMCBuIAowMDAwMDMxMjc5IDAwMDAwIG4g CjAwMDAwMDYzMTQgMDAwMDAgbiAKMDAwMDAwNzM5NSAwMDAwMCBuIAowMDAwMDM2MDU0IDAwMDAw IG4gCjAwMDAwMzYwODQgMDAwMDAgbiAKMDAwMDAzMTQ0MSAwMDAwMCBuIAowMDAwMDA3NDE2IDAw MDAwIG4gCjAwMDAwMDg0NzEgMDAwMDAgbiAKMDAwMDAzNjExNCAwMDAwMCBuIAowMDAwMDM2MTQ0 IDAwMDAwIG4gCjAwMDAwMzE2MDMgMDAwMDAgbiAKMDAwMDAwODQ5MSAwMDAwMCBuIAowMDAwMDA5 NTc5IDAwMDAwIG4gCjAwMDAwMzYxNzQgMDAwMDAgbiAKMDAwMDAzNjIwNCAwMDAwMCBuIAowMDAw MDMxNzY1IDAwMDAwIG4gCjAwMDAwMDk2MDAgMDAwMDAgbiAKMDAwMDAxMDY3MSAwMDAwMCBuIAow MDAwMDM2MjM0IDAwMDAwIG4gCjAwMDAwMzYyNjQgMDAwMDAgbiAKMDAwMDAzMTkyNyAwMDAwMCBu IAowMDAwMDEwNjkxIDAwMDAwIG4gCjAwMDAwMTE3NDcgMDAwMDAgbiAKMDAwMDAzNjI5NCAwMDAw MCBuIAowMDAwMDM2MzI0IDAwMDAwIG4gCjAwMDAwMzIwODkgMDAwMDAgbiAKMDAwMDAxMTc2NyAw MDAwMCBuIAowMDAwMDEyOTM3IDAwMDAwIG4gCjAwMDAwMzYzNTQgMDAwMDAgbiAKMDAwMDAzNjM4 NCAwMDAwMCBuIAowMDAwMDMyMjUxIDAwMDAwIG4gCjAwMDAwMTI5NTggMDAwMDAgbiAKMDAwMDAx Mzg1OCAwMDAwMCBuIAowMDAwMDM2NDE0IDAwMDAwIG4gCjAwMDAwMzY0NDQgMDAwMDAgbiAKMDAw MDAzMjQxMyAwMDAwMCBuIAowMDAwMDEzODc4IDAwMDAwIG4gCjAwMDAwMTQ2NDUgMDAwMDAgbiAK MDAwMDAzNjQ3NCAwMDAwMCBuIAowMDAwMDM2NTA0IDAwMDAwIG4gCjAwMDAwMzI1NzUgMDAwMDAg biAKMDAwMDAxNDY2NSAwMDAwMCBuIAowMDAwMDE1NjY1IDAwMDAwIG4gCjAwMDAwMzY1MzQgMDAw MDAgbiAKMDAwMDAzNjU2NCAwMDAwMCBuIAowMDAwMDMyNzM3IDAwMDAwIG4gCjAwMDAwMTU2ODUg MDAwMDAgbiAKMDAwMDAxNjUyOSAwMDAwMCBuIAowMDAwMDM2NTk0IDAwMDAwIG4gCjAwMDAwMzY2 MjQgMDAwMDAgbiAKMDAwMDAzMjg5OSAwMDAwMCBuIAowMDAwMDE2NTQ5IDAwMDAwIG4gCjAwMDAw MTczNzUgMDAwMDAgbiAKMDAwMDAzNjY1NCAwMDAwMCBuIAowMDAwMDM2Njg0IDAwMDAwIG4gCjAw MDAwMzMwNjEgMDAwMDAgbiAKMDAwMDAxNzM5NSAwMDAwMCBuIAowMDAwMDE4MzUzIDAwMDAwIG4g CjAwMDAwMzY3MTQgMDAwMDAgbiAKMDAwMDAzNjc0NCAwMDAwMCBuIAowMDAwMDMzMjIzIDAwMDAw IG4gCjAwMDAwMTgzNzMgMDAwMDAgbiAKMDAwMDAxOTExMiAwMDAwMCBuIAowMDAwMDM2Nzc0IDAw MDAwIG4gCjAwMDAwMzY4MDQgMDAwMDAgbiAKMDAwMDAzMzM4NSAwMDAwMCBuIAowMDAwMDE5MTMy IDAwMDAwIG4gCjAwMDAwMjAwMTggMDAwMDAgbiAKMDAwMDAzNjgzNCAwMDAwMCBuIAowMDAwMDM2 ODY0IDAwMDAwIG4gCjAwMDAwMzM1NDggMDAwMDAgbiAKMDAwMDAyMDAzOCAwMDAwMCBuIAowMDAw MDIxMDEyIDAwMDAwIG4gCjAwMDAwMzY4OTUgMDAwMDAgbiAKMDAwMDAzNjkyNiAwMDAwMCBuIAow MDAwMDMzNzE0IDAwMDAwIG4gCjAwMDAwMjEwMzMgMDAwMDAgbiAKMDAwMDAyMTg1NSAwMDAwMCBu IAowMDAwMDM2OTU3IDAwMDAwIG4gCjAwMDAwMzY5ODggMDAwMDAgbiAKMDAwMDAzMzg4MCAwMDAw MCBuIAowMDAwMDIxODc2IDAwMDAwIG4gCjAwMDAwMjMxMDYgMDAwMDAgbiAKMDAwMDAzNzAxOSAw MDAwMCBuIAowMDAwMDM3MDUwIDAwMDAwIG4gCjAwMDAwMzQwNDYgMDAwMDAgbiAKMDAwMDAyMzEy OCAwMDAwMCBuIAowMDAwMDI0MDcwIDAwMDAwIG4gCjAwMDAwMzcwODEgMDAwMDAgbiAKMDAwMDAz NzExMiAwMDAwMCBuIAowMDAwMDM0MjEyIDAwMDAwIG4gCjAwMDAwMjQwOTEgMDAwMDAgbiAKMDAw MDAyNTE4MCAwMDAwMCBuIAowMDAwMDM3MTQzIDAwMDAwIG4gCjAwMDAwMzcxNzQgMDAwMDAgbiAK MDAwMDAzNDM3OCAwMDAwMCBuIAowMDAwMDI1MjAyIDAwMDAwIG4gCjAwMDAwMjY0MDkgMDAwMDAg biAKMDAwMDAzNzIwNSAwMDAwMCBuIAowMDAwMDM3MjM2IDAwMDAwIG4gCjAwMDAwMzQ1NDQgMDAw MDAgbiAKMDAwMDAyNjQzMSAwMDAwMCBuIAowMDAwMDI3NDc0IDAwMDAwIG4gCjAwMDAwMzcyNjcg MDAwMDAgbiAKMDAwMDAzNzI5OCAwMDAwMCBuIAowMDAwMDM0NzEwIDAwMDAwIG4gCjAwMDAwMjc0 OTUgMDAwMDAgbiAKMDAwMDAyODI2MyAwMDAwMCBuIAowMDAwMDM3MzI5IDAwMDAwIG4gCjAwMDAw MzczNjAgMDAwMDAgbiAKMDAwMDAzNDg3NiAwMDAwMCBuIAowMDAwMDI4Mjg0IDAwMDAwIG4gCjAw MDAwMjg4NzIgMDAwMDAgbiAKMDAwMDAzNzM5MSAwMDAwMCBuIAowMDAwMDM3NDIyIDAwMDAwIG4g CjAwMDAwMzUwNDIgMDAwMDAgbiAKMDAwMDAyODg5MyAwMDAwMCBuIAowMDAwMDI5NzE0IDAwMDAw IG4gCjAwMDAwMzc0NTMgMDAwMDAgbiAKMDAwMDAzNzQ4NCAwMDAwMCBuIAowMDAwMDM1MjA4IDAw MDAwIG4gCjAwMDAwMjk3MzUgMDAwMDAgbiAKMDAwMDAzMDQ1MSAwMDAwMCBuIAowMDAwMDM3NTE1 IDAwMDAwIG4gCjAwMDAwMzc1NDYgMDAwMDAgbiAKMDAwMDAzNzYzOSAwMDAwMCBuIAp0cmFpbGVy Cjw8IC9TaXplIDE1NyAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzxFMTAwNjBEMzY1QkEz OTkyRDMyMkVGNjg1RTExQkVGOT48RTEwMDYwRDM2NUJBMzk5MkQzMjJFRjY4NUUxMUJFRjk+XQo+ PgpzdGFydHhyZWYKMzkyNTAKJSVFT0YK --=_62d358336509f7d869ee69ff490453ce Content-Transfer-Encoding: base64 Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="IETF core management.pptx" Content-Disposition: attachment; filename="IETF core management.pptx"; size=55643 UEsDBBQABgAIAAAAIQA6XofOcwIAAM0ZAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE WduOmzAUfK/Uf0B+rYJD2m63VZJ96OWpl5V2+wEunBBasC3bSTd/XwMhIbtkgWB6XlCMfWbGNpoB Z37zkKXeFpROBF+QwJ8SD3goooTHC/Lz/svkmnjaMB6xVHBYkB1ocrN8+WJ+v5OgPVvN9YKsjZEf KNXhGjKmfSGB256VUBkztqliKln4h8VAZ9PpFQ0FN8DNxOQYZDn/BCu2SY33+cHeLpVIHhPvYzku p1qQJMvr8/u0seK3hOaSoqO5RkGqH9UwKdMkZMb20y2PHs1lsp+HbyuLMXqdSP3KDjjDkPecJ9jX /bAboJIIvFumzHeW2VFUSkOlAm3rirH+80gNUsVqlYQQiXCT2RK/DpalJ00/YwmvJnFOjE7tzW9M G/uw1BuBa2U17E6a9mrG0dFHwQxdwWt0BW9QFHBhQFfPZq3h/JmoYbdpWlvTFBtTqTppOtd1gt6m zLBY5xfnKnLgNvK85FYJqccwtAK4TcE2gb+jKDgAt26AjUkor8P3oIBp3/JfKdyZXQrOZ12D7mQU X9nOPql7uygb41h3iX2ppnHMfJimcey9m6bKNJyvSxfTqMidL0AfcufR1of8LSb5FSb5O0zya0zy 95jkwRSF/ZiMw42mWzIeGYe7S1/Gaoijt4AKrvMeo7wBHthRoyRAzZIANUwC1DQJUOKk+HK7K79U j7/H+UAsoC+wAUeW19sGUCM2QM3YACdkn+69o/Dpu/cznJiv2HEC6OnqD7fjy1YfNQJn/z0CbV1x QEJDoaA/eXX4nldPpAUCZZLnjx0OjBZ68GwhP9ePIOrLHW60Edlg+hKmgZwWf8Ys/wEAAP//AwBQ SwMEFAAGAAgAAAAhAEe/GtARAQAAdQMAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsk9tKxDAQhu8F 3yHkfpvuekBk070RYe9E6gOMybSNNgeSqey+vaHgoVCr4F5m5p+PbxKy3R1sz94wJuOd5Oui5Ayd 8tq4VvKn+n51w1kicBp671DyIya+q87Pto/YA+Wh1JmQWKa4JHlHFG6FSKpDC6nwAV3uND5aoHyM rQigXqFFsSnLaxG/M3g1YbK9ljzu9QVn9THg/9jCIoEGAqF8xFWIeTqSybuwGmKLJLn26iGX05go MpmLeaHNaYWoG+yzA9PPqHz2ipeA7U9C678L+aYxCu+8Giw6mvOaJr6cQiARIqZcHNNLN3R1SiE1 JPL2lycbM0tKl6dUwgOh06iXpSCEDyMx+SzVOwAAAP//AwBQSwMEFAAGAAgAAAAhAD0Ap9wcAQAA fQUAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc7zUzUrEMBAA4LvgO4S527Td 3brKpnsRYUEQdH2A0E5/sE1KJiv27U0v2sASPJReAp1JZj7SJIfjd9+xLzTUaiUgiWJgqApdtqoW 8HF+vtsDIytVKTutUMCIBMf89ubwhp20bhE17UDMVVEkoLF2eOScigZ7SZEeULlMpU0vrfs0NR9k 8Slr5GkcZ9zMa0Du1WSnUoA5la7/eRzwP7V1VbUFPuni0qOyV1pw6toSX+SoL9aVlaZGKyCK5nFv UhK5FsCvyzZLyqysySNNgWlI0pDhfh1DFjKk6xiC/yJZ1ODW4qu7FMYdBB8zZfx8kJWtszW7kGG3 jmEbMmzXMWxChoclDUpbpPfpofAkf+H5lN8jwr1HM/8BAAD//wMAUEsDBBQABgAIAAAAIQBBaXni 9wAAAFoDAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHO8k89qAyEQh++FvoPM vbq76Z+kxM0lFAKFQkkfQHTWle6qqCndt68pFCKEpYeQi+D8nG8+GFxvvseBfGGIxlkONa2AoJVO Gas5fOxf7pZAYhJWicFZ5DBhhE17e7N+x0Gk3BR74yPJFBs59Cn5Z8ai7HEUkTqPNiedC6NI+Ro0 80J+Co2sqapHFk4Z0BZMslMcwk4tgOwnj/9hu64zErdOHka06cwIloSOmSeCxsSB0t/C8aiXNMOA nXdoruPwNOdQX9Qh9+JbXnswCkuZY1LmzZzWwyW14pDHvYrJHVIhdVIvHs2a3V9naas/B1b8iPYH AAD//wMAUEsDBBQABgAIAAAAIQBHPSyv8AAAANYCAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlk ZTMueG1sLnJlbHO8ksFKAzEQhu+C7xDmbrK7FRFpthcRCoIg9QFCMpsN3U1CJhX37U0FoYFSPBQv gcyf+eaDyXrzNU/sExO54CW0vAGGXgfjvJXwsXu5ewRGWXmjpuBRwoIEm/72Zv2Ok8qliUYXiRWK JwljzvFJCNIjzop4iOhLMoQ0q1yuyYqo9F5ZFF3TPIh0yoC+YrKtkZC2ZgVst0T8CzsMg9P4HPRh Rp/PjBBZWSo8lSxmCZz/FI5H1/ICA3Heofsfh+aSQ3tVh9KLb2XtyRmsZY5Jna8uad1fU4umMu5V LeGQK6mTevWo+zUT1W/svwEAAP//AwBQSwMEFAAGAAgAAAAhAI1OqrjwAAAA1gIAACAAAABwcHQv c2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc7ySwWoDIRCG74W+g8y9utmEUkrcXEogUCiU9AFE Z13propjQvfta3ooEULoIfQiOL/zzYe63nxNIztiIhe8hAVvgKHXwThvJXzstw9PwCgrb9QYPEqY kWDT3d+t33FUuTTR4CKxQvEkYcg5PgtBesBJEQ8RfUn6kCaVyzZZEZX+VBZF2zSPIp0zoKuYbGck pJ1ZAtvPEf/CDn3vNL4EfZjQ5wsjRFaWCk8li1kC5z+F09IueYGBuOzQ/o9De81hcVOH0otv5dmT M1jLnJI6X13TWt1Si8Yy7lXN4ZArqbN6dej3wkT1G7tvAAAA//8DAFBLAwQUAAYACAAAACEAwxyM v0sBAAAWBwAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHMgogQBKKAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8lctOwzAQRfdI/EPkPXX6oDxUtxuE1AUSgvIBJpk8RGJb nmkhf49bIE2iymJhdTk39p2jexNlsfqqq2gHFkutBBuPYhaBSnRaqlywt83j1S2LkKRKZaUVCNYA stXy8mLxApUkdwmL0mDkXBQKVhCZe84xKaCWONIGlHuSaVtLcqPNuZHJh8yBT+J4zm3Xgy17ntE6 FcyuU7d/0xj4j7fOsjKBB51sa1B0YgUnmaPzkzYHEmw/7aXxyBkxfnr/NOR+rMoUjgCH8Ved+CBu QkIUrk29pSeJBPYI05MHp7wJjSdhK3qv4JWaCnpNtaKPJCiIpyt/HMEhhk11xN4JL9Y8JJbSBDjE 6oi9E/60gsZF7m6ns8P4I3ohrs/03sy8ScQhKXYlfD5bbTofUSv5KGZnimLqg7gLCWEs4CCJVvqD 4L2/2fIbAAD//wMAUEsDBBQABgAIAAAAIQDeUavVhQMAAJ8RAAAUAAAAcHB0L3ByZXNlbnRhdGlv bi54bWzsmG1r2zoUx98P7ncwfntx/SQ/hTrDaZYx6IWwdB9AteXETLaMpHRtx/3u90hWZrstZWUX xiB5E0nn6K+jn6RIJ5fv71tq3REuGtbltn/h2RbpSlY13T63v9xsnNS2hMRdhSnrSG4/EGG/X/71 7rJf9JwI0kksoasFMp1Y4Nw+SNkvXFeUB9JiccF60oGtZrzFEqp871YcfwP5lrqB58Vui5vONv35 z/Rndd2UZM3KYwvDDyKcUB2HODS9OKn1P6M2ncU8JIHvyO54K4jcsE4KoGMvYdqCVv9gIQn/VF0L +aTFaqrcDnyUoDSMEbDjC9UCFt92l5fuS907Jol4rW0UiY3IS10OsEjsKF9vHaUSI/VyN4hyXh4m FsWTGQVKYWoOvak5fG5OJmb03DzFFY24poHsHq3yPrczHyHPg71aPuR2nEaprsiHHnaoKDkhHbo3 42tUplucZCg6dcsyL1bdtFd5FHKNJTYjSbwXYyypieWJU0VqfKTyhtzLnXygZHmJVdt2y03p85Zb FKuDRDrny06rTF3oHfV78MF0D2ePwuwlzW0Ir4b9VujGWyyIrXxFX65IbUrbUlp3WPsOmjNrUctX /IzVhCceYVU1vK+Eqx8AqAzjMdpUm4ZSXeH72yvKjZb+nASnbuoIdnoValzCShS8wTCr8oA5HCIT BV4QPPH5u+0cggdDKZ4YSjEy+6yYuT+gGX6B4tdifp3bKEpU8Geab6SpEBqa4UhzOGFnmm+lqRAa mmik6YeJH59xvh2nYmhwRhOcaZCmZ5xvx6kYGpzxiDMIUn0Tjjih1w2+3T2OvwMnwARfdyv+VT2G LB21qYIJXhJ7eNdtj10ph8fSnw1LETKwkgmsBIXze+YMyxAysNIRliI1v0bOsAwhAyubwIqjZH5J nGEZQvr5/fy93S+gbF7jULKOvMnt7x82xWYVhKHjxeHGQcEqclK4gJ1svQk3kb8qfK/4V6VyfqRS io/HpiIgckoa/ehZ2tg2JWeC1fKiZK3JP92efSO8Z41OQf1gSBoH1b2S1EkNLA/jDeSXoMn4o231 TKgEMVbclWtJ9U6YMS9QERY6P3J/uOiS1n06RHAShSvxF0R1eYJDIweoc7bBWp3oCDnIuyocVMSB k22uQmf9ISuQn8TF1So7sdWZ12+gG8K2/v/p+uiX6c6AjHyH71PT9P+I5X8AAAD//wMAUEsDBBQA BgAIAAAAIQAZu3QUXAUAALQTAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTEueG1s5Fjbbts4EH1fYP+B 0HNdWzdbDuoWjp1kC6SpkaQfQEuULYQitSTtOC3233eGEu0oTpyk28vDJoA0GpFzPcMZ+d2HTcnJ mildSDHy/Lc9jzCRyqwQi5H35fq0k3hEGyoyyqVgI++Oae/D+z//eFcdaZ4R2C30ER15S2Oqo25X p0tWUv1WVkzAu1yqkhp4VItupugtSC15N+j1+t2SFsJr9quX7Jd5XqRsKtNVyYSphSjGqQHL9bKo tJNWvURapZgGMXZ3y6T34Fl6xTO86+paMYaUWJ+p6qqaKfv6Yj1TpMggXh4RtISweN3mRbPMPoq1 JboPti8cSY82uSrxDr6RzciD4N/htYs8tjEkrZnpjpsuPz+yNl2ePLK66xR07ylFr2rj9t0Z+P2h 8+ga9R/LDelvfcMNxGyAiZ6jXl2dy/RGEyEnSyoWbKyUvF0ymmlcUfvebHQBsbJW2kypoefa4KOh C03UEVqgPmah23d/kY0hbrbEzhMwaH77SWZgMF0ZaY16ENQwCOMgsdGKg2AImW7HNwqDXpQ0cRvA 66QdPHpUKW3OmCwJEmAjS41VRNdgW73ULUG2kKcF51YHF+QWk/GAXRaGKcKLcuQlPfyrLcLAnYjM 0oYWvKa7KMY6ju7aeEEKsjtcNYc7hIB/FNqm3jhCOWLeELU52lyZO87sQ4UXi0KFIigWvOCdi3Mo +K+QviGYBYmdKSlzi3RdmglnVGzFmfczho6sqSAZ3K+MvHlDjpky5AzqZs3EXEIJogeYwkYbE9mM Knq5VcpE58vVE0qb6Fr3nds2Es8BeYBy2kCOfjGQrb4fCeR44Cc1kPuBH/f6tlJ2QA4CP4r7QQ3k EDH9/wXyIUw9BuQLuWblHHwZvAl6fvh7ILvtJpeQGNDDGQlamG0jFVpK3YFeh9lqScxdBVpSo64L w1mj4hCU49dB+cnWloT9gW992sF26EcRIsfC1vejsIHR/e71FGCeAANWE+ULYX2EgYaei2N1Y4OF kYIpZLYSqWnCtAeejHWmJx7JCmVsK30MMBN5eUJupboBYWSh5KpqYeY7ERA4BFzxImPkYmUxOeM0 ZUvJ8Yy1mTgMiOczD5MbiK7x+/eKKihiD0zA09Am53Bmt/X/+sTkMDKiq9+SSTI9GY6nnXEQ9TpR kkw7x6fRoDPshafj8dQ/iSbjf7ytuRAMAQa7NO3lo564MP7+Lg05DnEHirct5DszFu3XbHtg+lnd xWr5gd0l6g/iKLJVGuBA1Lfta1emie/7Ya9fl2kQxxH8/+D2MoyD+Gd3mFtFoUg0op41nX8METkt GgPrZa/tMQH22sMHBnz+5KYDoxJUsYZBqZNKxeBSFp3ePdBuz47mcqj1PKO1JWff9rPjWgqevs8e duMZedATXyywkfGJCrpg+OlGPgrIaQ5nmn5Fn92X+qI4/Y4NrztEWl9cOKcmz8+p33dkDP5zFwfA +ZgG/JZKgmH48FsKjpDQgvJXjaBNxYMFeQ6iGhkH6n8NXycjbynVV699Frxk9iTK8InkOyvw6Mhf cnRsG0F6zPKGmhkNn05WWi2g9XacmwPr7FuMVS13D5ubjpCC3ZtQD4DT3twPHQcB5IaDhwByv5ek XH2i1ee1tQkmaqWgcU8ss8I5ab7wRx43MIaZDVDZDVDzRYC8AHkB8oCiaQrnBKxoCMcJHGe7JnSc 0HEix4kcJ3ac2HH6jgPtbMkLAaOhvXkkl/yvmuEo5/LONYhKUYI7lhJNoCpa19+1cD8MZSs18go4 7vNCQBMD8DBtKKJPwKexwrk9Y9d2wDHlpZSm0WQlYZZq0Ug16jBREOh/AQAA//8DAFBLAwQUAAYA CAAAACEAviCLblUIAADcNgAAFQAAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbOxb/W7bOBL/ew+4dxD0 1x5wivUt2Vh3Yct2z4c2DRL3AWiJtnmVSB1FJ06LAvcs+2j7JDekRH8nTbLJ3SZwilrUiBwOZ+Y3 Q9qjX35dFblxjXlFGO2azpltGpimLCN03jU/T0ZWbBqVQDRDOaO4a97iyvz13V//8kvZqfLMgNG0 6qCuuRCi7LRaVbrABarOWIkpPJsxXiABt3zeyji6Aa5F3nJtO2wViFCzGc8fMp7NZiTFA5YuC0xF zYTjHAmQvFqQstLcyodwKzmugI0avSPSO1hZepVn8lqVE46xbNHr97y8Ki+4enx+fcENkoG+TIOi AtRitpoHTTd1S69Vo7U3fK6bqLOa8UJeYW3GqmuC8m/lZ0vS8EoYaU1MN9R08elI33QxPNK7pSdo bU0qV1ULd2Q56/Vc5STDxvmymGJuXOQoxQuWZ9B2FGc1SC+iKj+w9EtlUAaLlDqp17zuUStCXsuF IW5LYA+uA7zBs752zX8vEReYmyAByF/zVyqTY1RjI3ijWLHqs+xWzj2FqyKiTl6JK3GbY3VTqo9a vgzPLmtDrEkzcF254G9eGPp2GIZW7A5ty09ix2oPo77l2NGo5ztJHA397+ZaalAKBbklCw46y5FE SYatwRDWUogkx4iujXL39OKdJ++Eos2kr4G5aXaBOLrcY9uMU5rQy25pG95jSddt29qYlzgFBM9z bPg/Nh60kgX0xj3O2c0Co6x6mE0FETlu+C8rMUACfaiEMheaVwbvSLn4OPM0r+1Odxv8CEy8dhB4 ofJ/xwlDz90FTOwF7SgKaiC0Hd+3d9EArkKNmw3OZjPQD0hRi1XPeehjxg1HoKBKuis2jXxMK4U2 oRtcN6a6gWi6YBDbRD3RUQc1UD4Hl0kFV15VlWkfz5rWhaiMa5Rv0LzztDcT9/RTTzceV3+sfQtT 6/OVaWSECxUsDMy5Mv6BE4t3Cfs43njrg7gd4WKgsuQMpQvjZ+dve+wOXL9hKKMDBGZgSJRwd05w N0LmYLQFSUccgKDj+IayjxpPI2aCpoAW5VdNVN8dhHYY3xX+DqfSoAFXbbAhnXbJYX3fBr7bc6NB 3+oPPMfy+3FixV7PsUbhcJiMXN/3XOe7TE+O3ylYNtbJF+4PEl5BUs4qNhNnKSuazNkq2Q3mJSMq eTp2k4GV4zhxGAd27IdaehBLX4/g83Bh+wgNAaJ1hnJCN45rBG4gGnpeGNl+DVHXjR03UspubTg1 Ct5qymBR6+rRmw0h7akAJqZ5cwGbzwivxCW7Ud41hU1O01Y95BCF13H27luQuG7g+z0rGg5Dy/d8 1+rbfmzFQX+QtEcDJ/F635Vbbw9TBDlTM+V7TlSsn8M1YbkMQk4Q+04U1urZpjuBHTpNZNume55v +yqG7tBdN4ziqI6tO3MJbiy6pu9GNqhYEZROH5hCD5H+vv8DpEsEPQDgO3w2GN6WTKQ6bzYyv7Dk JRKL1yn55eR1yq0gLbcPLyG+vNTIUxDwIghw9v8EAgWiaI7lMeV1mqVVzF+n4Anj+Oy1Ck9b6G3B 4OO4/2r9v/XDLe8ul3s20AWZ/gnUIM8aBeIflLTQuFQNQuFEK+rTijqI5CAFnsH+9+rr+vBkcKEO FwZGH2iff1ELnTEqemoIWgoGByIkCG0eQ1d5hIQN2MWSpkJvqXJ6VSqR5ZklFc3W05Z/zYq3ezzj OQhUs0xyPlkpdUyXV1/XzREsY31zzmitMdjF1QfCo8f3ZwpMfwJH75VlTlL1JdgzOvy/KkZPkewE 4bcF4f97UrjjW4+Te50yxGvLEOmU8VOGOEH4lCFOGeLkXm8nQ6yK/BTWT7g7hfVTWD+512njf8gV r8gLJoj6l0913frNePu+qYXaLQq4u4zGXxcE4JXos5WhfmBd18EYUh5ZtFRTt+u9HlPC0g6jYK+G xQVS5Ln1D+QANKepi9owKnkl3mNWGLLRNTlOhUISum5KWTZdJJmyEcnzB5W4UHB1BeyEKcDUEOoB lEek4Vz3fzZfG1OB+Qyl2KhKnJIZwZmBqs7TPeVRtVLBvpF3q6T+gJFtz/ZrI/uO37bjvSoIiKBe FDUVe47tBGGof8B/i1a+xKhiVFXWEGpU5CvuGEei3kFS8ny3rYqAmoRkNYRNlFY/IUv/6Zo9ThAk qhJRVsGt7dp9O7R9uOp/gOmSiHQxQgXJbyV7MMAC8QqrZNfE+wQoitw1f//Pb9q1HhbkH/fFxxM0 afw8XYq/G6rWRPluJZVDpHdAuN4tr3orSj2mhpfMS083S12WpIuqq4dUuz1HGIv2w5gqKnqWMOa3 A0eFscCDpOQ01UrrYq7ACZzYacKY53q+137DYQyOhFtp6oaIxW6iesOAG+Aq5aQUjCtX6xg//WTA 3zPAUFlHHhO2lJCwJSeYG+f4ZkcVEaTVtlJCIBVxoAq/faiKtHoRxnLJuqS7uq0+lxPy+OK3N6KI zTrfNAZ6V+dnjvGp/89hMrHGg+H5ZDwaDy87jwfCPabe9y3nzDsLz5wzF/5D+8kZ5elRb39tfySL qYt+s+bedwV0UfBep2Pl0/1+O3STuG/1HX9k+YN2ZPVGYWCNAs/3k37cS7yhLp9OOVYH2+etoQ5t z41DV8t8pIRav1eU5vwjKj9dK00y2ChwkuFEEUtC58Z07nTNXECMFCtoZV9kefLclTRX0lxJgxZK U8AR9GgamuJqyrqPpymepvia4mtKoCmBpoSaAoeYRU7oF1CSvMivePJ/1ATd0pbaLA2MSQpYjmrR xmAlqrctE6pfoMqWgEwZEWaEEiGTOa4E4gBhiq/le0GUZXhSv2JSXDKm3qZoNZykc9WsZauZTvoX KPq/AAAA//8DAFBLAwQUAAYACAAAACEAhFg20JIHAABoNgAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0 LnhtbOxb7U/jOBP/ftLzP1j5tI9Ead6bVNdd0W7ZQ1p2OehK99UkbhutE+dst5TndP/7M3ZiSl+g pRSOA5ZV40ycsWfmN+OxHf/6aZZTNCVcZKzoWM6hbSFSJCzNilHH+jE4bkQWEhIXKaasIB3rmgjr 08f//PJr2RY0RfB2Idq4Y42lLNvNpkjGJMfikJWkgGdDxnMs4ZaPminHV8A1p03XtsNmjrPCqt/n 27zPhsMsIZ9ZMslJISsmnFAsoedinJXCcCu34VZyIoCNfnuhSx9BsuSCpuoqygEnRJWK6RdeXpRn XD/+Nj3jKEtBXxYqcA5qsZr1g7qavi2mutBcen1kirg9G/JcXUE2NOtYoPxr9dtUNDKTKKmIyZya jL+vqZuM+2tqN00DzVuNKqmqzq0R50aeC5qlBH2b5JeEozOKEzJmNIWyoznrl4wQovzKkp8CFQyE VDqpZL6pUSlCXcsxktclsAfoAG9A1v861p8TzCXhFvQA+l/x1ypT7+jCvOO1YuWsy9Jr1fYlXDUR t6mQF/KaEn1T6p+qfykZnleGuCENAbpK4L+8MPTtMAwbkdu3G34vchpxv9VtOHbr+Mh3elGr7/9t 3fQalFJAvxULDjqjWHlJShqf+yBLLnuU4OLGKHc3Lz/66k5q2lBhDcxdpGeY4/MltvV7WhNG7Kax 4T2WdN3YNsY8Jwl48IgS5G82HpR6Y6hNjjhnV2OCU7GdTWUmKan5T4T8jCX+KqQ2Fx4JxNuqX/wk 9Qyv25XuNvgaN/HiIPBCjX/HCUPPXXSYyAviViuoHCF2fN9e9AaASoGu5n42HIJ+oBdVt6o2VzGG rjgGBQkFV2IhelII7W3SFLgpXJoCLpIxg9gmq4bWAhRhOgLIJJJrVIky6ZJhXTqTAk0xnXvzwtOj obynnn46R1z1c4MtUjR+XFgozbjUwQIRzrXxV0AsP/bY6ckcrVtxW8MF4bLkDCdj9MH97xK7FejX DFV0gMAMDDPduTsb2MVDfOMdA8BNl82QxuUNxJFipeJRRb0dyh+CTsf3PM14Dk/wTN91ogqegE2n DnlzRiUX8gthOVIF8BmApwYHntYonVdR5IIdZ5Ruhd4CxnBAqqQ9puFSAehoIoFFzbmqvx6vq3b/ 0t1g94tMB57Tky7CSUKE2ML2C0x3NG+wbN7F0Pco80ZBZV43CJ2gtRR93Dj0W677Rsw7wJeUHCBR WRkGjOe1srs6xNUWre38UOv6fhR4rcp5fdf1Aw2buXVDP4w9lSYp60aeHcetx1h36/FmL5ZU8dQJ VTy90bt+HZLgQg/iQ8jzOlaPTXgGCVnVDDcpy3n/9zb60h+gjYPBYluXi7FbS8Igk1Ko1jcqSSc9 yqsxTOGnkG7Vs0l+ytKKHthqJKjHN/NKdXeb25bCkBnOS0oOE5Y381HzcSKZ0fNliJZnl6/BQq/K JuJa/CgHWU62jIsv0zbz3ppovT7cDHnj+Pzx4eaijdxDO0A9VkgQCn24HxF3t7o2u31AV+oONI71 +kEbMlmaJXrlYOce7diTDU7xdCqYwb9d235AM4szg/swtpchbQOi7m7jdnR5ZAh4CrkOkOW4ng9p 6jZTrTva2zElC1dTsmBfKZkbe25kL6VkrcBzW45XpWROEMZh+KiM+z0ne8/J3nOy15+TZeU3Igfs lKQZ1tPYTzB9fQ1W6jhbj6JPlaktZUxq8c+kTI9OYd6zlmfMWm47ycnwpEjJBoXuRUJ0gJw3otSz 8bU4SlO+umb2RIq1bLsN/9sOXJy267X9YClLfLW6htLzqVrl4Pah+guct6LgAVR+JhQLtXWf/APz m3h5YyHa08aCH7YC39fzHD8MPMcLlzYW/NBXxLexsXA6oTIr/4mdo9bqBFZbYvcJbBTbjqsNG9hR qLamF/cU4tDz7HpD0PFg4u7FL3ECq9BNp2ab+UVPaFeWuV7p7PYFyrk61X3wIvfLkerOFe+H+sLL x+dDc4Z/DyJ3XXl9+TY7QMWE0nuSy3eY/ntgurIe9Sbg+mr2QDe42vue6Pue6B6E3T3W778vHzCl G/L0p1P+kFHK1HmC57YAKnHGxcYg9hh/X40xD5vBRstLFPobtX0sUdyayTqREy192RpBfI3NRPY1 rFCsWZeAeLfd3PTe1Y3bp0/a6AxfU4ZTBJAoBZmkDFUnVYAgJIEHbIj6f5wcoF73+/nB4eEeF0L0 xRxyufezff2Z6/Jn+6Wy/byEAMUd669uNw7dXtRtdB3/uOF/jluNo+MwaBwHnu/3utFRz+v/rQ7a OH474URr4cScJQLiyvmdPEs4E2wo9ey5OgjULNkV4SXL9Fkgx64PFOmR3vNbcRhFrluto+i+mas5 bmDO+CSUn+Ly+1Srkk0hLGWpSgyAWEJ4QZcjp2NRCZFKzqCU/oTS5chVNFfRXEWDUpV1OCb9cAzF nSckNcUzFM9QfEPxDSUwlMBQQkMJLTSmWfETtKQuFoCF/lYRTMmYai4aWDPLQRxdKmqLlbgKHIPC HGZKJxCUsyIlw6zIpHIoIiTm4KoFmaozOgVLiVrl7VgyP2dMn2xo1pwUuirWqlQ3pwAGiv4/AAAA //8DAFBLAwQUAAYACAAAACEAeXDp2YwFAAAWFAAAFQAAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbORY 727bNhD/PmDvQOjr5liWZcU26hSOm3QB2tSIXewzLVEWEYpkScqxOwzYs+zR9iQ7UqIdJ86fpgM6 tEggno7k8f78eHfyq9frkqEVUZoKPgo6R2GACE9FRvlyFHycn7f6AdIG8wwzwcko2BAdvD75+adX cqhZhmA310M8Cgpj5LDd1mlBSqyPhCQc5nKhSmzgVS3bmcI3ILVk7SgMk3aJKQ+a/eo5+0We05S8 EWlVEm5qIYowbEBzXVCpvTT5HGlSEQ1i3O49lU7AsnTGMjtqOVeEWIqv3io5k1Plpi9XU4VoBv4K EMcluCVoNxPNMvfKV45o39m+9CQernNV2hFsQ+tRAM7f2Gfb8sjaoLRmpjtuWnw4sDYtzg6sbvsD 2rcOtVbVyh0wZ2vPjNGMoMuqXBCFpgynpBAsA7rjJLtN3ggt34n0WiMuwEjrk9rm7YraEXaUBTIb CeIBOiAbkPV5FHyqsDJEBaAB6F/Ldy6zexyxU7xxrFmfimxjz17A6Jh4yLSZmQ0j7kW6R61fRvKr OhBbVg7QtQb/0U2SOEySpNWPzsJWPOl3WoOz49NWJzw+H8edSf/4LP4z2GoNTuGgtxWhwGcM21uS kdabM7ClNBNGMN8G5eHjzUlk34zj5RZrEG6eTbHCV3fENvucJ7zZbR/DRyIZRYPQB/OKpHCDl4yg +OngATUpYDUZKyVuCoIz/byYGmoYaeRX2rzBBr/TxoULLzVSQ6uXusi6XtbtRQ8H/MA16Q56vW7i 8N/pJEk32r8w/W5vcHzcqy/CoBPH4f5tAKhwdLO7Z3kO/gEtarXqM+9jDN0oDA7SFq4kQOyCa3fb jCeUJxaewDwtBOQ2Ux90EKAIsyVAJjXKoUrL9JTkDTU1Gq0w293mvdlxbh5Z52Z3iKsfW2wR3vo4 C1BGlXHJ4j54zcl7YejK5ccdVp2Ye0htpNnLDHkUpFEHpAelvwTQiQfzHMJ8KtaotwdlZEXZ9FFz PTgfBaK7DF8FxE4vGvTiGohhF/7vIjGOev1BUiOxF3aS417/DhSl0uYtESWyBKgFUHRAwKsGkbsl ls3FOWXsWUjlUK8BlYZNhINGDZZxZUBEI7lefxibD0X5iaj+J7tfgtaLU7hvGZpdvp+iO4B9ShxR ygH2gNjV0foLhR0QgiBjoFJog6SQFcMKlZjjJbF9DDJCMA3PDG/2Tvq27pwXBHSmGmHYpJYEWf9S Dp0gYyRDC6zJw9q+4Lwx3yBObm47BkupBE4LpAtRQb1mBNpUmESmAL0oXxFtQBWrGKRwocxXuO+b w9fBFuxdQYehrRc2CGsJyUAjkaOJGE8fts6mvxKrd1AYY6j6Nv9y6FMgm7QahssN1bmwcINanUM7 NwrGimIWIIm50PAaRuFpmIQxjP4PMpukJi3OcUnZxoqHTFZgpYnZqr6ooFtQjj0K/vnrb++MF5ed K/Kpgsgi6M8lNPb7MHtBKL8v70wVyeEWLNjmVwT5HfRLr4l1lnOadinQe07/KJCZkbRS1DySP//H 9n4xoF/goN+pLhBZU0DI8IfJI2ezeV4xsAE+Lq2mUGNdsYBBkawCBlQYRlPX4qIMqgsT0lWep8rJ 9+WoC3DQUmFD6t7pF1dtbnkpFZl9lJIBgszGpRjoA9JrpOnnQ13A/cbeDf6nlEd7ctdAH+jJ/S8y KVPvsfywcnYKaAgUFMyJY0rKl2ix7IwCZqCZM2ugsmugFsvI8iLLiywPKJymEDBY0RCeE3nOdk3X c7qeE3tO7Dk9z+l5TuI50PwXjPLrUeCGAOWC/VYzPOVN3pkGXqElmOMo3jhK4vqTZs79T09ZBRCw 0Mspp8Y2+1ADsAKscNsr2U/5jMzrj/PySgj3HdpuJNko1aIt1RxnAwWO/hcAAP//AwBQSwMEFAAG AAgAAAAhAG/Rr/4mAQAAjQYAACwAAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVy MS54bWwucmVsc8SV32rDIBTG7wd7h+D9NEnbtBs1vRmDwq5G9wCSnBhZ/IPasbz9XMugQie7COmN 4NHznR/fOeJ29yWH7BOsE1pRVOAcZaAa3QrFKXo/vDxsUOY8Uy0btAKKRnBoV9/fbd9gYD4kuV4Y lwUV5SjqvTdPhLimB8kc1gZUOOm0lcyHreXEsOaDcSBlnlfEXmqgOtLM9i1Fdt+G+ofRwH+0ddeJ Bp51c5Sg/JUSxDPugh6zHDxFGJ8CP8sKBy1EriMspkRwg2jhlY366COSi3h0aZEiW89izjKFUN7S nDJFVtySrEiRVbO0LTk5xaTuCBnedAQhoRXsHC+wUfwvjtUsVqTnJJ+FYZ1iWE6KEHLjbpwi5zU5 mI+zOFH9IpDoE6m/AQAA//8DAFBLAwQUAAYACAAAACEASq91OdIAAAC/AQAAKgAAAHBwdC9ub3Rl c1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlMS54bWwucmVsc6yQsWoDMQyG90LfwWiPfZchlBJfllLI kKWkD2Bs3Z3JnWwsJSRvX0NLyUGGDh31S/r0oe3uOk/qgoVjIgutbkAh+RQiDRY+j++rF1AsjoKb EqGFGzLsuuen7QdOTuoSjzGzqhRiC6NIfjWG/YizY50yUu30qcxOalkGk50/uQHNumk2ptwzoFsw 1T5YKPuwBnW8ZfwLO/V99PiW/HlGkgcnDE8xYAW6MqBY0Po7+Wm0ugLBPPZo/9ODkiAfHAuWhc1d vhj6NTOLt3dfAAAA//8DAFBLAwQUAAYACAAAACEAoFLbelQIAACVPAAAIQAAAHBwdC9zbGlkZU1h c3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxbXXLbyBF+T1XugEIeYy4JgCBIlaktiRK9rpK9KlNbeUwN gQGBCBwggyFFKZUq3yE3yC2S4/gk6Z4fEvwVrbW0zgp+EJuDQffM93X3dAP02x8X08yaU16mOevb zg8t26IszKOUTfr2LzfDRte2SkFYRLKc0b59T0v7x9M//uFtcVJm0QdSCsot0MHKE9K3EyGKk2az DBM6JeUPeUEZXItzPiUCvvJJM+LkDnRPs6bbanWaU5IyW9/Pj7k/j+M0pBd5OJtSJpQSTjMiYP1l khal0VYco63gtAQ18u61JZ3C/sJRFuHneKL+XvPTt+SkzLM0GqZZJr/wyXiQcWtOsr49lP/s5unb 5sY0Gsc0FFelwGtGlRRQc1nccEpRYvN3vBgVeBXMf5xfcyuNgBXbYmQK4KNueUFPk1/ZXArNjdsn RiQni5hP8ROwsxZ9Gyi+x79NubSFsEI1GK5Gw+TnHXPD5HLH7KYx0KwYLU6KNNSrS8OtDbXcjtkT XBYzTi3Ht62IliF4weinq/N37uCvg5+XG9ZKCKq9ysPb0mL5ICFsQs84z+8SSqISgVJArG5Q8Egl s1JcEEGABfwqyKS0+Amuhr+PfHNjdZJEVDNV2cY4SwtDLMqghU7HVClygKsQ4kXAzgqeMqGQK3n4 CTxAyYJTESYoxqBGj6PLmAvoGUsj6B8A2/juQx6BUjITuX0sqT2n3W61NFltPwD/XmMM4OSleEfz qYUC7AAWI7WTufbW1RQcZjkuStrImHWHBjeGpykmhCyd9u1uC/+pFSFBlyySsiBppuQmqpH7xT1K QbtNWSjudgRDyw2M7yB24AMZtdylpxinLwvjJxAUKoYOe4wxZRymSCxxX4AVkYqMav2HnKjzuBMZ G0dR6vVcx/Ekr37Hd/wNcrue3wsCX5GrmP6uyQW4Fud5dC/jBj4BATh3YF1Jzh9s644ToKn8+4xw alvZe1ZKpxZG4EYYG4HNpoM8k9QSFoIWoMqIA8FVlsqnBRFXbFSEONGgcrP4C+GFxkUAoh/zUUIK ugseNVd+VcuWAJViJO4zKvdcyD+wn2yeLWNQTuM4SPAopazxywiO0qkYZJSw5TRxOsjS8NYSuUWj VFj6RJU+BwcvmEDD6EhSJa5JYmqwlPA+FjEeorURMdJbnylioDL4OJvCbh/6NhIKO7JhKeC07SPi KPjGcdT1g27XVwmyA3LH+K2JJM8JfJMlHd/9TgNpq4z4HYeVlOeZg/SSbALhwqWOiMafYAj9ypEH G8uveZ7Hxi2Xdym5os3E6EqLXooairNIxso/hkGn5wati4Z3fuE22p3Aa/R6vW7j8uL8vD3s+kO/ 6/zTXvp5GlHAS66NS5WHjIjTL5//86cvn/+7CukYS0xglkXXhBPcm0oXEW1cXOotPSHg3d52wDsS omeKeKRQh7gxcyjEu893VDqB08Zo3n9Wtr2uo2fUh+X3fFhGKReyqD3+2ETC5alZ7jg2N41LT32S 8RENcxZZGZ3T7AhDsjp9kqGbJOXH2/GebGeYz7hIjjYkj/GnGUrjA3a+urBZtpE3yPx5vrCc9VbA Qn0yK60nvKPTnDUrKb/g5A4fj6jnAocyW+8bZzZIVK2OymxQu7juZhfQ6ThOzwt08eJ6XVf1sv+3 xcsxycxksLEm9QzAG6Z6M4/lHVVPhKJaUawd03sq9we53bWSY5eDf8zn+DiAW8Ebt+V4b6z3lzfD N9Yg/3S55vB7D/2dlp5cCbR3lP4ORE2SRlC6rE7r5ygKIqE2k5As1sWBCc5DIeSoo/kbNgCtloN4 YiMd4NG/EUOBDyWBaQC8VhvlugH4XhqAzbq/txEaT3so2zRKf03X8PVlu/xQj3vRwfUT5jDjH0hh jSdO384E4C4WIEW3II0nLo65OObiGEgkDCkTMEMLZsQ1I8s5nhnxzEjbjLTNiG9GfDPSMSOYJ7KU 3YIv4YdtxXn2kxowkopnaPivyH0+E+8jHdKVEZmJXKcdtLtex4e1rSJ96+71uV5lrs4ce+e2K3Nl HYRQby0ria0kUi4ca1eOhM7eSJZkvpQyPoHZ04xmYEvI6tWi5Iqd81ulMWfiTE4YkxKCDZNmyibX MxZKGyq7huc01tJ1KJSXmnyzdvUsFgfm6auVyPAwjRyOBplqlkqq0/ANCpN5OyYh5NI/T//WyPTT a0o2LlCiXwiUGxfCUuveFVtSdF8Vimc8JbDNMCG8pMbPtuBBTDQ8Xg3PFjyIiYanXcOzBQ9iouHx a3i24EFMNDwdhGdK+NXyZdgBsJzHwDId5e8JLERIgxWswNIvl2qw1sFChDRY3RVYjhc4+IahRmsd LYRIo9WroNV1u7L1qtFaQwshUv1DpQwtZKO0VZMqJF1fvepPGfT1oLdhBn71eZBhl7cJmNMyfbTs TlczdpDgVrH5aiLGs9FDxeyqWR7PBgCiRLJvf/n8bzVa4Q3tfsOCmO0riNm+gpgdWxArCgPHkYfS q6XwXy9F4aMluM5OTqcrT746qBRYz87DZq2veei4vjxT68hYPQdDQF6Akc32Qp82LTi4a0Z+E0Z2 dzQK/69j5MjSqmbkEUZ2t01ur6eazJqRF2dkd2/mtX3VydaMvDgju/s/r+eobrlm5MUZWfaYla6y OMlFQvmyx4Q7rtdewW2/51pNWW9IqxzCnBsyHj2sniXtYlWufVUs7CK1CpOsP24px7fYmGe3IcP/ +EGXoImFeY/+Wzd6W08fXy0+u/uurQeOrxafPf3Q1jPGVwvQ7vZk+7HiqwVoT7fg4s/ga4D2F+9B 26tz9KFaGpZbJ+lDpW3HD+okvV5pVotL+eMo83sb9WMd9Svu0/8BAAD//wMAUEsDBBQABgAIAAAA IQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1s LnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJi F7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJ F9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPW IOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAHBwdC9z bGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOI NHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0Fsfg ScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJ akgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQ SwMEFAAGAAgAAAAhAGARFf3iAAAAwQIAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0MS54bWwucmVsc7ySzUoDMRCA74LvEOZusltFamm2Fyn04EXqAwzJbDa4m4RMKvbtjYLQ hVI8SC8D8/fNd5j15nMaxQdl9jFoaGUDgoKJ1gen4W2/vVuC4ILB4hgDaTgSw6a7vVm/0oilLvHg E4tKCaxhKCWtlGIz0IQsY6JQO33ME5aaZqcSmnd0pBZN86jyKQO6GVPsrIa8s/cg9sdEf2HHvveG nqM5TBTKmROqoOPKw+yoaJDyp/Ad2kZWGKjzDourODxdUmivorC8pPDwnwo8eksvyIXyzOSkPhtq f83U7PG6LwAAAP//AwBQSwMEFAAGAAgAAAAhAFtpUOrOAgAAGAcAAB8AAABwcHQvbm90ZXNTbGlk ZXMvbm90ZXNTbGlkZTEueG1stFVtb5swEP4+af8B+TslNM4balKFJEyTujZq2h/ggRNQje3ZTpps 6n/f2UDSNtXKl33B5nx3fp57juPqel8yb0eVLgQfo/CigzzKU5EVfDNGjw+JP0SeNoRnhAlOx+hA NbqefP1yJSMuDNUexHMdkTHKjZFREOg0pyXRF0JSDmdroUpi4FVtgkyRZ8hbsuCy0+kHJSk4quNV m3ixXhcpnYt0W1JuqiSKMmIAu84LqZtssk02qaiGNC76DaQJcEtXLLOrlg+KUrvju29KruRSuePb 3VJ5RQYVQx4nJRQGBfVB7eZe+c5tgnfhm2ZLov1alXYFbt5+jKD8B/sMrI3ujZdWxvRkTfO7D3zT fPGBd9BcELy61LKqwJ3TGYajbsPonqYg/IZRb3Ak18DW8kakT9rjAmhVVRCzHLzpVCnxnFOSaWuu yB8Dq4rYVeaeOUi4RbPsdltCk/0eo19bogxVCKAAkV4dXYW4zYlABYOLpGCscqtsMjL7WGQHe/oT Vld/EjFtVubAqHuR9rFmmWP8ZzBNOvEc9/0Y97s+TvrYH3XDnj+fjXASTofzzgC/oCPaIqMc8NoU CorGiP1QKPcfV8ChNDNGCT+qUvUBicwktFoYp8jathaoy7MlUeT+kySBwxuceDmqn6qIz1W8bKXi vTBv9dQSMvxDYjA/QKcussJ5tVL8e7n5XFzGXwvbjnbvnHb3Pzav7bC6Wxv3Nt36nlvrpgVvj5Ib Hqsnh9uChom63PJKompsvG+sjPrzRevGcksz9UDYG23qnbdVBXwwcTzqX86GsR+HOPHxfDTwp0m/ 5ye9LsazeDiddRcvdoqGOEoVdQP2e9aM5hCfDeeySJXQYm0uUlHWUz6Q4pkqKQo36MNO/bfYETZG OMRD3Ot1hhUPh61ZHVqrWj3AU6Z+EHm3cwLAZTBeZs4koW61wCcXK5v9q03+AgAA//8DAFBLAwQU AAYACAAAACEAMf5vRj0EAADjDgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnht bMRX247bNhB9L9B/INRnR/JNviB2sKvdDQJ4N0bsoM+0SFtCKJIl6VuKAvmt9nPyJR2Sku3dtbfO FnX9YI2omTO3M6T09t2mYGhFlc4FHwT1N1GAKE8FyfliEHye3tW6AdIGc4KZ4HQQbKkO3g1//umt 7GtGRngrlgYBBtd9PAgyY2Q/DHWa0QLrN0JSDs/mQhXYwK1ahEThNWAXLGxEURwWOOdBaa/OsRfz eZ7SG5EuC8qNB1GUYQPx6yyXukKT56BJRTXAOOvHIelMrO+xNlRNAAmqYrYS0je5YTRAzk6tYKEe DKEU6YQRxHEBC9PcUPDBcuqeaDlVlFqJr94rOZFj5QweVmOFcmIBSsMgLB+Uau6Wr5wQPjFfVCLu b+aqsFcoDNq4SLf2P7RrdGNQ6hfT/WqafTyim2a3R7TDykF44NRm5YN7nk6n3omqjD7RFJizYBQ1 dslVYWs5EukXjbiAtHwVRJKBNr1SSqwziom2yz75naGviL3KrGxJatTUdaWqk33uhH20R0vVjaJ6 5GvQjHtRr9l9XLVOu9XsWgVbjXo3Bp1nNfHQsm8214JsrfUMrq5nuM+0mZgto05esXoZBqHzT1At /RX8tnaQOwUrHxhK++fsFBgxbOeS8trnCXC0MAmjmO96aIYJy9MvyAhESW6QJzBypIUpBkSLbpwP B0k5GWOFbTiHyD4i6TKsMnPJ/lPvu43nva+3ApTlhFC7v/yHPNDLmeeBq+xvS6wg9wAC2+ztX0WO VidutH2fTpCjGbWs/C+5gQqsRm78cg7VMlb0JUqv6byUxqlBK8z247l/esCruqUqVHKshJj7TQo0 YVMidzlj7kYtZglTHuvO/SrAvVpYgb6WoQcRnM1W6OMPEJbQ2s3tI0evJG/rCHPbl2Hu3KijpHV1 AtOlNjfY4JE2jk54oZHq25jVB7LDP1Q6zXQ0W98LAj7x0gjHiie8b0RNOAU98eN2pxs/JX47Aqrv dsV2Y7+DVUhSafOeigJZAYKEejpPeAXBld0pVRz7OVpXVC9yywCWF24ArRvn29bylhPPGpwzL1sa 8hcnzb7YQASZUF8DtFYY2qRtjWGPYB+49ud6JahKmFUCXxaJYK61mKeAMghmlZgY5U9KUUhsRnwi 02rObHLTza9YybICBmr3ICYZlvad4FkhvK679WGf2h8wW3B33jmUg3F3G9Elp/3RSVZm4pdODOgr h7J9ZCjjywwlMUdnsnL50ky6t53zZ9IB/vgLxBmvDZdqU3ykTZ0LnfqMPCyLo62qXjpfalXzIq36 H+dxDh8mNtffrxqtbv0uSmrXzat2rdVJ4lrvppHUOq2o144b9d5V0vyj+szREASF7c/tJKpM8bQT M/z+7c9fvn/7a39ag9/X8cxd/DeT7cvE4sCVqXssP66cu8K9KCRuScLHZNnCvYrFqD5Oh38DAAD/ /wMAUEsDBBQABgAIAAAAIQBXHni71gIAAKAIAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDIueG1srFbtbtowFP0/ae9geb9pgCLKUKFaKUyT+qVCH8CNbxqvju3ZTgadJvW1tsfpk8x2 EqAdSLDuT2zfXJ97z7nXcY5P5hlHBWjDpBjg1kETIxCxpEzcD/DtbNLoYWQsEZRwKWCAF2DwyfD9 u2PVN5yek4XMLXIYwvTJAKfWqn4UmTiFjJgDqUC4d4nUGbFuqe8jqsl3h53xqN1sdqOMMIGr/XqX /TJJWAxnMs4zELYE0cCJdfmblClTo6ld0JQG42DC7pcp2YVybOXdV4yCky7csoWHjnc85RQJkjnD jFngKBcUfREp4Ta8N2qmAfxMFJ+1mqprHbZdFtcaMephqu04ql5UbmEpijCJXm2/r6ekP0905ken BZoPsCvZwj8jb4O5RXFpjFfWOL3a4Bun4w3eUR0gWgvqWZXJ/U2nXdMp1WgtWdX5GnUu4weDhHR8 PP2S3tKj5OxHlVbCW2Y5VH7lyzBZJVOJZeenki58kDs3BiPpc2OndsEhLJR/hDS0y5cT39cgGrdT jCjTNrBGJrMjDkQspbHDEWfxA7ISAWUWXRBjQaOQljsPDtzrZINaARwEvSaa3GyNUSqrApE666iW dbu4h7W4ZYMZ5Vr90c9cNu23Kc3ofOXyH0RWnnvBlxpuFn1nqX0nB6XNC6lLEV+HDDT2CDmFWLpT y6EAvgN8UHoP+FnK9O7oh3uiT2SubbozfGdfeJZsRN/a5P/Y2p26tSeSMxAizzLQYr3BgzBv/ZS4 a+oyzxzTxwH+lhPtgHHV++WpfEPzh3nBW1V2FJKb8uO9ZvbzNfe6Nq/9K1Pi7hYvzo/DbrfT7Ha7 jV573Gx0Rr1W4+P46LTRah5NPnVao97RuPOzvqcMZxScgPhljSk0zsZlWbdHtMPnp18fnp9+r4rt kthY7iXetnKHobz9fFWmHseNXF8QdVWEcFk43qNgUu5PoCrgysVj1H8Wwz8AAAD//wMAUEsDBBQA BgAIAAAAIQBKvPjSJgIAAF4EAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1s jFRLbtswEN0X6B0Edq3QUgPZNSIH8a8bNzHi9ACMRFlC+CtJq1aKArlWe5ycpENKit06BbLRDB9n 3nypi8s9Z0FNtamkSFF0NkABFZnMK7FN0de7ZThCgbFE5IRJQVPUUIMuJ+/fXaixYfmKNHJnA+AQ ZkxSVFqrxhibrKScmDOpqIC7QmpOLBz1FueafAduznA8GCSYk0qgzl+/xV8WRZXRucx2nArbkmjK iIX8TVkp07Opt7ApTQ3QeO+/U7KNgmrvGREPKPBmugYgQhOoPNuwPBCEA7CiVHvMqDtNqdNE/Vmr jVprb3pdr3VQ5c61c0G4u+jM/FHUXsH/uG97lYz3heZOQgeCfYpgUI37YofRvQ2yFswOaFbevGKb lYtXrHEfAB8FdVW1yZ2WE/flLCWrqBA7zqkWCibxWBJmqQ6il0L7EoxayezBBEJCia4jbcUvFm0b nFRlNwFYsusdhx18TNG3HdFAjCA+ZB+1efc+Xjmk3bXV7qcyb1zse5AeJGNm7MY2jHq9ZlGXXU6L 23YIR7DTj8yV/5zad1ABe+Ga82O4HF7F06vzcJjEH8PzeLYMP82iWTiKR8l8MU0WSZT87LfMsCqn 0EDkKDT0F7YOXl9Ow/mindn/I9rJ89OvD89Pvx1m/Q0k4XdC5Guiye0pn/P2Deu7g9tBe9FusZvK xvGAZPoLUTe1DwfvCCYw85CCd9wN8GDiOPr/wuQPAAAA//8DAFBLAwQUAAYACAAAACEAdvkk41sE AABdEwAAJQAAAHBwdC9oYW5kb3V0TWFzdGVycy9oYW5kb3V0TWFzdGVyMS54bWzsWN1u2zYUvh+w dyC4a1c/lhzbiFzEjt0VSLIgTrFrWqIsIRSpkfRPWhToa22P0yfZISXGTuJ1QbsAQ5BciIeHh4fn 7yOdc/x2WzG0plKVgic4eONjRHkqspIvE/zhetbpY6Q04RlhgtME31KF345+/um4HhbAFSt9TpSm EoEeroYkwYXW9dDzVFrQiqg3oqYc1nIhK6JhKpdeJskG9FfMC32/51Wk5LjdL5+yX+R5mdJTka4q ynWjRFJGNPigirJWTlv9FG21pArU2N33TBqBj+mcZWZcLJvvpRwdk6ESrMxmJWN2YlTTCZNoTViC F8sAe6Nj74EUzXOa6jOlzZrTZAmjWNXXklJD8fU7Wc9rswqnX6wvJSozSAxGnFQQf6PbLrRidsrX lvAebF86kgy3uazMCKFD2wRDlm/N17OmbTVKG2a646bFbwdk02J6QNpzB3h7hxqvGuMeuxP5g77z 6AriQviSURTeOefMVvWZSG8U4gLcaqIgJlB3S3oipdgUlGTKsBvn7zY2ETFjXSB9W8MpRSahkD8m +I8VkVCv7ZZGzhI7q8HIxeZcZLCNrLTATw1gOIiiftBtAhMN4q5/PzpkWEul31FRIUMkWILrVjtZ t5WxEzFsLkz52DMYR5sED+Iwthv2VqrSwI+VVYL7vvlrjDKxmfLM0pqUrKE9o+lAPRqnjfN6OxbZ rRFYwAiBgKsBDC2E/IjRRhJIgjIRpBix9xxiPwiiCIKh7SSKj0KYyP2Vxf4KX1UTwWwiCU9Ba4K1 IydaNlUlqproMz6vUyPowna9/Z3Iug2chpBfiHlBanoofo2snTZu2AgqPde3jFp6zYK2xDKaX4Gf pjQCwL5V9y186+1BfJvbh9tay0kKhXNdVlShC7pBV6IicL/VpU6LGalKBsURQPWnBZGK6h2EGkua HDn7DL1nd20/+4a3TjcsyrNLIonxhxFzgVPe+TBv1Zt47BJsc/6vIB08Bmn3GUGa6fsYBTO2u53f i9VuH1DpvyL2JSAWEbaE3ynS6niF7j9C19b7Q+hGzwjdXD94Xxvs2if9h9/ZAVxFQWBvnlfs/hB2 F6+v7f8Xsnc/8neQjZ8RsoplF6vqEGot0v6jF/cVuy8Buy/23c1ZZuH3aRyc9IPxrN+JZ9GsEx3N Tjsnpz2/M5sexX7cncbTbvgZ30GnzCikyLouH18A3zpRj75++fOXr1/+MjxtV3LTZPieC8UOrnUA mYbcthRaydJ4NR70wkl/3BkHxqvTwVHnZNaLO7O4G0WTcf9k0p1+Np2OIBqmktomyPvMtU+C6FED pSpTKZTI9RuovrYT49ViQ2UtStuMCfy2o2NzH/SjuNs/Cnx3p4BtbrTWmkuqbbKkTJ6TGi2WQYKZ hsqHwoF/Cm6AWixDwwsNLzQ8oEiaUq5BoiUcJ3ScO5mu43QdJ3KcyHFix4kdp+c4PYwKVvIbCIYZ MMoF+7VhOKp17l5LbPQ3AAAA//8DAFBLAwQUAAYACAAAACEAo5j4kzgBAADtAgAAHAAAAHBwdC90 aGVtZS90aGVtZU92ZXJyaWRlMy54bWyE0t1OwyAUB/B7E9+BcL/RDzvdsnZZv+KFiRfTBzi2rCWj dAEy9e1ltM42XSY3HMKP/4GE9ear4ehEpWKtCLE7dzCiomhLJqoQv7/lsyeMlAZRAm8FDfE3VXgT 3d+tYaVr2tBXc1aykiKTI9QKQlxrfVwRogqzDWreHqkwe/tWNqDNUlaklPBp8htOPMdZkAaYwJEJ LLjcnU9RJKAxvV5AMqVgllLFKoFci8qDe56UrD4SLtEJeIgdOzCJ1uQCuJ663I7e9aA8eP/lWcD1 1C2zrRt7lzwLoCiouNI7cTM/i3s7QF05zV4sEz/djvwg37/9tgHqyofbbxygrgwmPk2zPPdH3qKu XEx8kMVOEoy8RTVn4nDl9nEcPPb6QvYtf77KnTjI0l/+p8jgD9nV6ItGPwAAAP//AwBQSwMEFAAG AAgAAAAhAPevJGkrAQAA3QIAABwAAABwcHQvdGhlbWUvdGhlbWVPdmVycmlkZTEueG1shNLdboMg GAbg8yW7B8P5ij/TrUZt6l92toN1F8CEqhGwAdJtdz+KrtNoOk74gIcXSIh2X4xaZyJk2/MYOBsb WIRXPW55HYP3Q/nwDCypEMeI9pzE4JtIsEvu7yIUqoYw8qr3ihYTS+dwGaIYNEqdQghlpZeR3PQn wvXasRcMKT0UNcQCfep8RqFr2wFkqOUg0YEVFW+XXcTiiOmzzCTunEsnRf2RUWGdEY2BbRqASQSv gKqlK00b3Qhw5/6XZwBVS7ct9k7qXvMMQFVF+MrZmVN4RTraCRrKZXawzbx8P/OTfO/22yZoKB9v v3GChtJf+DwvytKbeYOGMlh4v0jtzJ95gxra8m7l9mnqP436So49fVnlduoX+S//U3DyZ8xo9iWT HwAAAP//AwBQSwMEFAAGAAgAAAAhAI2sJ3xqBgAAkCYAACEAAABwcHQvbm90ZXNNYXN0ZXJzL25v dGVzTWFzdGVyMS54bWzsWt1u2zYUvh+wdyC0y8G1JVGWbcQpYifpiqVZkKQbsDtaoiwhFKlR9E86 FOhrbdjd3qRPskNS8m+apkmTFa1zYR1Rh+Q53znfISll7/k8Z2hKZZkJ3nfcZy0HUR6JOOPjvvP6 8rjRcVCpCI8JE5z2nWtaOs/3v/9ur+hxoWj5ipSKSgSj8LJH+k6qVNFrNssopTkpn4mCcniWCJkT Bbdy3IwlmcHoOWt6rVa7mZOMO1V/eZf+IkmyiB6KaJJTruwgkjKiwIMyzYqyHq24y2iFpCUMY3qv mbQPHkYXLNbX0dj+nsn9PdIrBcvi44wxc6OHpkMm0ZSwvjMau05zf6+5oUWThEbqpFT6WT2SEfTA ZXEpKdUSn76QxUWhn8Lsp9MzibIYwuIgTnJAX49tHlRq5pZPjdDc6D6uRdKbJzLXV4AOzfsOxPha /zaNaXOFItsYLVuj9JcbdKP06AbtZj1Bc2VS7ZU1btudwPW82qNzwIXwMaPIWzhXm10WJyK6KhEX 4JZFQQxT0KYHUopZSklc6mbr/KKjRURfixSp6wJmSWMJafym7/wxIRLytepi9YywtBqMHM1eiRi6 kYkSzl0B9LoYd1zfAoO7gd9aR4f0ClmqF1TkSAt9R4LrZnQyrTJjqaKbudDpY+ZgHM36TjfwAtNh 5UmeafqxLO87nZb+s0ZpbI54bGRFMmblph7phnzUTmvn1Xwg4mutMIIrAAGFAQxNhXzjoJkkEIRS I0gdxF5ywL7rYgxgKHODg9CDG7n6ZLT6hE/yoWAmkIRHMGrfUbU4VNJmlcgLok74RRFpxRq2y/lv RBYVcAogPxUXKSnoTfhZXXNr3TAIlupCXTNq5ClzqxSLaXIOfurUcIH7Zrjb+K3mN/JbVx9uci0h ESTOZZbTEp3SGToXOYH6VmQqSo9JnjFIDhdqapQSWVK1pJC1xMaotk/LK3YX5mfV8Mpp20R5fEYk 0f4woss35Y3XF9XwGo9lgE3MP0pSf5uk/iOSNIZkyOL5Uvm+9PQ7QMTWjqRfA0kRYWPYmEgzxo6t t7AVb7MV34mt50Kt87YsYIRbqAzNlxDdozgzWh9ndsnil/m4YrdZ5x/A7q7XCgNL7hB73WCD4ZbU 1f7ED12slR+J4uu5J8ejReYZltfzrqndpxYs2H+3TAi2MyF4xLqt+bu+u7KBNmvFAwLdDru4CjQO W4G/GekA+0G7jjSG8hXuivkXWMwNInUxRFAtF4uyUZMbBRDS8EwKkRjbylwNGSV80UXt68qTm0On PcZRFE9klKKfWRZdUY5GlMgRhRhxbY4yRtnibG1YM8Sk9z0N+X2mZ0FHI8rpHaYyZe+eUx3KTH3C VIZ495zq1wwS8O5TmRXmnlMd//sPT26Z65NXwPZ23Ws/Yt1L1Mah0pY9A8mDD5dd3Oq6bhXJ3e71 AQVvtDtifrmb1nCbsuEjUhY2oqeT/CbWmg3SZzpz7rj7NXD3qz15Jiw29Puzgw8DPHS7jYF3MGjg wWHQGIStdiPw2wM38PCwPfTfOgvqZDGFEBnXN5d6u8f74Ixq//27v354/+7v5Sqf6Dfr9yko5lK/ L4dIQ2wrCU1kBl4NBt22N+wMGgMXHzfwYTdsHBy3g8Zx4GM8HHQOhv7RW/1638W9SFLz5v9lXH8z cPHWV4M8i6QoRaKeQfZVnx+ahZhRWYjMfIFwW9VnDBN7v4W7Lc1vs/loGtvqq7FWF6nqy0LE5CtS oNHY7TtMQeZD4vSd+Aqk0djTbZ5u83QbSCSKKFegUQl1i1e3LHT8usWvW3DdguuWoG4J6pZ23QJb qZRl/ArA0BcHJYL9ZBtqyZZp8xHoA9RhwHZltvuIkhM+kFdGTgRXB0ZhREqoFbqSZ3x8NuH6rUPF rSIa0KSSziJVI7tyqF7VOEjUpu6KXvV0k8Poikr9zet/5DMQgKx0/zHnDUqqby3lxoOovKUCGNHT 0OdEnlQlFVzcBeLJAqHRrwLhLwNhFrpdIJ4yEBr9KhB4GQjXD13ztmgXiSeLhIa/ikSwEomO1+ns IvGkkdDwV5FoLyPheZ22eVe+iAT0uiSjizfLwrUVG9h0GIeWoVoPjd2VPwGM2l2mPhNAGpUKoHAF oBD76+voNwuQRqUCqLMESKOzvr59swBpVCqAuisAtYNwfdn5ZgHSqNhXKytnhvrW/h/Z/n8AAAD/ /wMAUEsDBBQABgAIAAAAIQCjmPiTOAEAAO0CAAAcAAAAcHB0L3RoZW1lL3RoZW1lT3ZlcnJpZGUy LnhtbITS3U7DIBQH8HsT34Fwv9EPO92ydlm/4oWJF9MHOLasJaN0ATL17WW0zjZdJjccwo//gYT1 5qvh6ESlYq0IsTt3MKKiaEsmqhC/v+WzJ4yUBlECbwUN8TdVeBPd361hpWva0FdzVrKSIpMj1ApC XGt9XBGiCrMNat4eqTB7+1Y2oM1SVqSU8GnyG048x1mQBpjAkQksuNydT1EkoDG9XkAypWCWUsUq gVyLyoN7npSsPhIu0Ql4iB07MInW5AK4nrrcjt71oDx4/+VZwPXULbOtG3uXPAugKKi40jtxMz+L eztAXTnNXiwTP92O/CDfv/22AerKh9tvHKCuDCY+TbM890feoq5cTHyQxU4SjLxFNWficOX2cRw8 9vpC9i1/vsqdOMjSX/6nyOAP2dXoi0Y/AAAA//8DAFBLAwQKAAAAAAAAACEAnpwrrnAgAABwIAAA FwAAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMC AgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIU FRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQUFBQUFBQUFBT/wAARCADAAQADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAEC AwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0Kx wRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ 2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QA tREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaH iImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq 8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoorwXRvGHxX+ Jlvrninwhf8Ahmw0XT9XvtM07w9qmnzPLqS2dzJbStNdrMPIMkkMuzbE+wbSwfJUAHvVFeR6h+0Z p2n+LJ9Obwzrsvh+11iDw9d+Ko1t/sEGoTNGiQlTKJyvmTRRmRYigd8E4DEeC6L+1N4x1DULFbHx hpeveJbvxHPpsXgKHwndCWa1i1FreUrerLsUxwDzWlKlFxhhRuB9rUV8paX8cvFfiD4neJNHfxpc aPDY+JptHttPtfh1qOpQmJJFVd9/F+5UnPLEgJ1OK92+Inxe0P4XzwrrqXccEum6hqa3UUatHts4 1lki5YHzGjZ2RQMERSZIwMrpcOtjt6K8Tb9q3w5eWej/ANjaDr+uaprFnp1xYaVawwJPLNeR3MiW zGSZUjljjs7iSXcwVFT7xJANnS/2lLHWtW0DRLHwf4km8R6ldXtrd6SVtUk0prOS3W5Nw7ThCqrd QupiZ96sNuSQCwPY6K+bfht+1Zb+PPgtpPiINcTX0EWhwaxrGnWcctimoXk1tHJZorTKS6/aF34y Iw/VnUx10Vr+1h4f/tFm1Lw7r+h+GzPq1pD4kv0t/sk0+m/aDdoFSZpQAlrOys0YDCM98AoZ7hRX l3w2+OyfEDxdJ4bvPBniTwjqn9lJrcC62ltsns3k2IwaGeTa+esbYZccgZGc++/aU06z8ZQ6QvhP xFdaNNry+GE8TW8dsbH+0SdrRlTMJgiNuUyeXt3Iygk4zXl/XYR7DRXhumftSx+IrLSJNE+HfizV bzW/tEuk2KNYRS3lrblFuLrL3QWKNJJI0/eMrM0ibQwORp2f7UHhLUPDeva3DaaubbRPC58V3kTW 6JKsCvdRyW+0uP36PZTqynC5Aw55wgPX6K8buP2mtMt/FF1p7eFPEf8AYljq9noV94lMdsLG2u7p LdrdSPO81lJuoELrGQrOM4GSPZKYBRRRSAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvGte /ZnsdWutetrTxp4o0Pwp4guZbvV/C2mzWy2d1JKc3G2RoGuIVmJYyLFKgJdyMFiT7LRQB5Defs26 RdeKZb5PEWu23hyfV7fX7jwlC9uNOmv4WjeOUkwmdR5kMUhjWUIXTJXkg27r9nnQrj4e6d4Xj1DU bWXS9Xl1zTNahaMXtjdvdSXJeNim3GZpIypUho2ZWzk16nRQB49a/ATW9F17W77QPit4o0Cw1bVJ tWm0q2sdKmgWaUgyBWms3k2nHQucdq6n4r/CLRvjBpui2esy3MMelapDqkTWrKrOUDo8L5BzHJHJ JG46lXOCDg13FFHkB4ta/sr+HdJ0rU4dI1vW9H1S48TzeK7PWLaWFrnTruRGi8uESRtGYRFJLGI3 Rhtkbuc1ueB/gLpHgfxBpeupq2q6trVqmpfar/UXiMl/NfSWrzTShEVQw+xwqixhVVRjb0x6bRQB 4jo37JnhXw74ds9E0zUdTstPjs9JtrqKFogt7Jp1zFPb3Mg8vHnHyvLd1xvRsHlEK6Gsfs36DqHh Ky0YyT6hDp9/rWpxW17IBFcyalHerNFMUXd5Q+3ygbcMAq8nnPr1FK2lh3sfOP7Ofwj8feG/iDqH inxxe6hKItBt9AsbfVNUtr6UKkrSMVa3toFEY+QBnDSuSxfGAKyNU+A3jrUfjdaSW8t1pvgK38WJ 4qaFNWgexkkClmKwfZhcCV5TlkMxhBZpB8xCj6loqr6p/wBb3/Mm2lv67HkUn7OdlZ+H/CVloPir XvDOq+GILm0sdc0/7M9y1vcMrTwyJNDJE6M0cTfcyDEhBGDnA1/9jvw9qmhHSNN8V+J/D1ldeH5P Deqixnt5H1W1d5pWM7ywuwkMlzO5eMoT5rDpgD3yipsM+f8Aw/8As33t5448XX+v+I9Yj8M3Pii0 1q08OW81ubK9+y2liIJZj5RmUrPbFiiyKreWhZSM5+gKKKq4gooopDCiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA+R7H9oPxxrGraTqljq3hqWbXdL0l7bR0SaRNJa+1SG2K3cYmBkmiWRhuBi3MjLtTbk1 Pib+054y+x/EHRdJ1DR7WWDQfEL6fqlrZlZLe5035JXCvdeY5LCQcwokbBcPOB831fF4X0aC4mni 0ixjnmlE8si2yBnkDBg7HHLblU5POVB7Ux/CGgyXV3cvomnNc3gIuZmtIy8wKlSHOMtlSV57HFC2 swe7aPF/hX4s8a6Rpvi7w9fX3/CW65a6zc6Zpd9Bps/2Wy8u2gMX2tnuZJNhZwdxfcRvOSea53Wv 2rda1Dwpb63oNtpmmxXjtHbR6pB5rlre0Wa+B33NvEBFNJ9nJeVCjQSnEnQfTFvp1paXNzcQWsMN xdMrTyxxhXlIAUFyBliAABnsKq3XhnR762it7jSbG4t4ZzdRxS2yMiTFixkAIwHLMx3dcknvS6B1 PnbQf2mvF+rRr4i/sfSZvDRubS0Gk2sczahK8+gQ6oCk2/ZxJJ5QXy/mDA5Ur83OP+0d4003xBcS Qan4f8TXGtWugQWjaPh9P0xrmPVbl3eOW7jDuVtoo+Z4/MzEwCkhD9YWug6ZZJGlvp1pAkbrIixQ KoVlQRqwwOCEAUHsoA6VW/4Q3QPsd3af2Hpv2S8/4+YPskeyf5i3zrjDfMzNz3YnvT7h2Pni4/aN 8fXmg6hq1lpvhyzWy0rR5mtZpo7lprm9vJrctHOLuOAqqw70jMgMjSKnmIRk5OlftIeLdR8QNfpr Ogx6fe6VplnHb3lhNDb2V9Lq15ZTXUhaYMVU24UxZwXaJVmx+8k+ppdB0ya3nt5NOtJLeeFbeWJo FKyRKCFRhjBUZOAeBk1C/hXRZIUhbR7BoUtmslja1QqsBxmIDHCHauV6cDjijrcOlj5t0L9ojxJf fFLQrS4+xtpt+P7Ju9Wt2ZtJili1O6thcIm/eGuTCkMY3FUeQBnfaok7jxd8dtUtdetLOwh07wlB FYTancN44jktjeRxyxxmGDY/yH95ky4k25QeW27I9fHh7Slt1gGmWYgWJIFj+zptEanKIBj7oPIH QGpL/R7DVZLWS9sba8e1lE1u1xErmGQdHQkfK3uOaOwPqfNs37THit4Ynsl8M3Vxq6s9jYqsxl0g rq1np5ivcS/O5F2zfKItrwumHxurV8OftCeLZvifdaBqOiWd5pdpeXWlTCxEEN481tbNM08UTXjS uJWT5YBDlUkRzK4zXvCeHdJjnu510uzWa7kSW5kW3QNM6EFGc4+YqQCCemOKkXRdPj1aTVFsLZdT kjEL3ghUTNGDkIXxkrntnFAHhXiv9ozV9F1LxHewWml2enaBApbw1rAkg1vVHeza4U221iF5HlhD G28xy/OmzBoWvx28bal4i0jwppmoeDdV1TUr+0iXxBYW882nRRXGnajd+X5Qn3PLGbBMnzVDJcI2 1M4r6Fl0ewm1OHUpLG2k1GBGjiu2hUyxqeqq+MgHuAaisfDek6XHGlnpdlaJHM1yiwW6IFlYFWkA A4YhmBbqQx9aAPnXwf8AtEeKvEF/4R/tvTNPZdXstF16GDRhcLJFBf2eqSfZjmTE8iNYDDEKrebj YCoYyeOPiZqV148nu49W1bw3d2b+HRpHh27cW7Xa3epSW90ZYMnzd6LsGc+WEDrtJJr6Ih0HTLd4 Hi060jeBI44mSBQY1QMEVeOAodwAOm9sdTUlxpNjeX1rez2VvNe2u77PcSRK0kO4YbYxGVyODjrQ B558N7zXv+FpfErT9Z1yTV7e3lsZbKHyVhitI5I5D5SKCT0C5ZiSzZPAwq+nVFHawxTyzJDGk0uP MkVQGfHAye+KlpgFFFFIAooooAKKKKACiiigAooooAKKKKACiiigAor5x0Hx58XvjvJr2v8Aw91f wr4P8Hadqd1pmlHXNIn1K41p7aVoZZnZLiIW8LSo6rtDvhSxxkCuqk/aGTwL4H8J3HxI0G/0Tx1r YliTwnoNtJrF3PLCT5rwJbq7NFtCybjjasiBsMcUAeyUV5PrH7SPhKP4E+Ifiho102qaVpNvcZtX hkguPtkZKCzkidQ8cxl2x7GAOWHqK5b4dfHjxXq3wH+IOqeKdP0zT/ib4Fj1C31fTrVH+xi4hgNx buily/lSQvC33ucsAeKTdk2+g1rbzPoGivkDUvjl8b/h/wDA7QfjB4kv/AOueGrm003ULzQdO0i8 sr0w3bRDy4Jnu5UaVfOGAUwxGOM16/8AtWfE7xX8Jfg7ca54JttMvPFEup6bpllDrEbvbF7q8it/ nCOjf8tezD8ab0EtT2Civmb4uftV6poH7Jei/EvwhYWNz4q12xjnsdO1FHeCKVLd7m9SRVZW/cw2 11kbh80YGa6q6/as8MeGtJ0GHV7bWtX8R3Wh2mtajY+FtBvNS+wwzR5Esvko/lIWV9oY7iFPXGaf fyDse30V47rn7WXw50iPw/8AZr7U/EN14h0lNc0mx8P6Nd6hc3tmxx5qRxRkgDvuxt744qW+/ao+ Htv4P8LeIrG91LX4PFAmOjafomk3V5f3nk8TgW0cZkXyiMPuACng4JApAeu0V5D/AMNV/Dxvh/b+ LkvtSltrjU30SLSo9JuTqj6iud9mLPy/O85drErt4A3ZxzUWk/tbfDPWPC3iLXk1e+tbfw/dQ6fq Vne6TdwXsN5NgR2otmjEjzMSFCIpOTQB7HRXkNj+1X8PJvCPiXxDqF/qHh238MmD+2bPXtKubG9s FmYLDJJBIgfy3J4cArw3PynGI37a3w486/tFh8Vvq9pGl1/Yo8K6j9vmtG3YvI4DDva3+Rsy42g4 BILKCAe80V5Jr37UngHR9L8NXtndap4nbxFpy6vp1n4a0i61K6ksTt/0loYY2aOMbgMuF5yOoIDN a/as+G+j6T4Tv4tWvNaHiy1uLrQrXRdLub251BYDGJkjhijLiRDKu5GAZcPkDY2AD16ivnHxl+2n 4Y0yz+GOo+H7bUtY03xb4hn0W626LevcWHkRTGeN4Ui3pOsqIvlOAxUyOAVRiO//AGiviZqvwl+H cGvaPDaT3kmuaTppS9Rnj8u6v4LeQ4VlO4JKxBzgEDII4piuen0V4r40/bA+GvgPXNf0rUb3WJpv DtwsGuz6foV5dW+k7o0kWS5ljiKRxlZFwxODhv7rYqWf7VGiL8dPHfgnU0l03RPDOhWmstrk1jcr bbXFw87yXBTyliWOKIo27DkyBSxRgsjPdaK8k8G/tReBPG15d2kEmtaRcw6fLq8MWvaHd6c17ZRg F7i2E0a+cgDLnbkjcMjkV4/8YP28bC18LeFZ/htZ6pdXHiTWILC01rVvB+rXGntbNFJI88CxRo1y f3e1Y0cE/MwyqE0/ID67orw68/a88BeHdSfTNWu9WuBp94mkar4isPD962i2t/uWNoXugjRxkSMF ILkIThmyDWl48/as+Hnw58Uahoer3upvLpXk/wBsX1jpF1dWOj+aAY/tlxHGY4NwIb5m4BBOAc0A ev0V4/4w/at+HngfxJf6RqN7qkyaW8ceratYaPdXWm6U0iqyC6uo4zFCSrqx3N8oYFsA5pfHn7VX w/8Ahz4hvtJ1a51aUaYkMmralp2jXV5YaSsqhozd3EUbRw7lIb5jwpDHAINAHr9FNR1kVWVgysMh lOQR606gAooooAKKKKAPl/wHeeP/ANmWz1zwRB8Ldc8f6B/a99f+G9W8OXVkqeTdXElz9nu1uJ42 haOSV18wBlZcHqCKrnR/i34G8YeBfin4n8MN4/1ldC1LRte0Xws9us+mC4u4rm3NuJnjScRrEIXO 4MSA4yM19UUUAfFg/Z9+IPxPmj07xBpV94K8N+MPHN14211dN1G3+16ZDb2sEWn2pZSwM0k8Mdw5 jDqvlkbs4zr69+zZ4u+HHjPxnL4Ru/EHjrRvH/g7UNK1qfXtUhluLbUYYGGnybn2FldZJYeAdp2E kKOPryik1dW/raw763/rufO3wJ/Y3+G/gnwb4B1DVfAGnJ400vTLKS4kvHa6NvfpCnmOoZ2jDrIG wy9Dyp6V1/7TngfW/iB8O9M0zQLE6hfQ+JtD1B4hKkeILfUreaZ8uQPljjdsZycYAJwK9aoqr3dy baWPjbXP2dfHV1c/GLQ00lJ/Cdno/iF/A6LdRA3V5rMIeaPaW/deTL9ojUvtXbdnHAOKXijwT8Wf +EisND1HRPHt/wCHI/Del2Wi2vgfX7TSbRLqOArdrqdyJUuFAk27WiLLsztUtnP2tRS6W/rr/mPr c+Tf2WPgl41+HniX4ZXXiPQjp0WifDI+HL2Q3MMnl3wvo5PKGxySCiFtw+XGATniuSl+Hvxb8FeD fA+jNo/jFfDCap4kuNXsvh/f2MOr+bcapLNYMZZZFAt2hkdmEbqwLLuxjFfb9FD1d3/V9QPgbwN8 NPHHwbm8LeItQ8OyPr9r8QdXvtO8Kav4nguNR1ezvdNSMtFdzS7ZbuMKzFXddwSbBxtJxtT8D+NP 2hNc+L2vWfh2+0jVdE+IOh6nJoOi69HbX00dtpSwywJfQuI0uljuFfh9quoTdxmvvHx18PfDHxO0 CTQ/F3h/TfEukO4kNlqlsk8W8Zw4DA4YZOGHIzUvgvwL4d+HPh+DQvC2h6f4d0aAkx2OmWyQQqT1 baoAye56nvR/X5f5AfFN/wDs++I/G3w9+J91pHgPx1aapq2n6ZplhJ8Q/Fq6jqV9HFfrPKnlPNKk MSAMylpssWfC88/SUPgPW1/ay1Txk1h/xTs3ge20eO+8xObpb6eVotm7f9x0OcbeeuRXsFFAH52+ G/2avHXw4034d6xrfhz4g30Ufgax8Pajp3w58ULp+oafe2888gEoW5iSeFxcfeV22MhOMNmvZfg9 8C/EHhHxp8FtTPhS60LTtI07xRJqtvfa6uqz2Vzf3FrLEJJ2IaWSTZKzFAyq24bjwW+raKd9b/1q B8cah8L/AB14Naw15fB+oa2unfGXUvFLafpc1u9zLplxbXUKTxq0qqfmnQlCwYDJI4r2n9qbwLrn xE+FttpPh6xOo6gniHRL1oRKkeIYNSt5pny7AfLHG7Yzk4wATgV69RSWiS7f8D/IVtW+/wDwf8z5 m134P+K7z4fftV6dDo2+/wDG0962gx+fEDfK+i21snJbCZmjkX5yuMZ6HNcL8TvgZ458W3nxF8K2 +g3sSeMvh3oumWeuJPELO2v7B7uSS2uGEnmJ5hmjUMisMM3PFfadFK39fK36lf1+N/0PiPwR8Hde 8SeKl1CfwD8TrG90rQ9TgF98QfHf9oww3k9sYfJs4fPmEyvvOZW8oAKp5PFekv8ACPxUvwq/Zg0Z NIxf+DdU0a41u3E8Q+xxwaTcQSnO7D7ZZEXCFic5GRk19J0U+t/T8Bf8H8T89vjJ8KvjR8T9H8d6 JqPhzx9rXiaTVprixMHiKzsPChsFu99uIoY5keaQwqo2Tof3h3OwxXsckfxH+D/iD4q6JoXwvuPH Z8aa5Lrei6x9ptV0yNp7aCJ4dREkqyokTQn7iPvQgLg8V9TUUAfAHi79njxdoviD4l6Pe+EPiN4x j8W6td6lp7+E/Gx0vw/PHdIpkgvYWuFMIQl0JEUm9AuATxWz8Yfg34y0XxVqjeBfA/jbQ/FEml2d ponibwT4ltzpl9JDaJEiazBduqssTLt3+SxeMDkN8o+5qKPIPMp6Kl9Ho9impyRTaksEYupIFIja XaN5UHopbOParlFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXk178f7TQ9Y1dNX0trTRrC4ktBqEUkj5mE 0cKI+6JIk8x5flxK3CkttAYj1ms298NaRqWnXGn3el2V1YXEnnTWs1ujxSSbg+9lIwW3ANk85Get AHma/tQeDI5rpbt7y0WEeaheDLSwGCOZZggO4BhJtwRuBViwUDNdfr3xS0PwvDbvq7XGnvPateRx TxYYosckknfGUSMlueNy/wB4VZk+GPg6ZgZPCmhuQu0FtOhOF8tY8fd6eXGif7qKOgFauqeHdK1x dupaZZ6gvkyW+26t0kHlSACRPmB+Vgq5HQ4GelHQDkfCHxu8M+ONRtLPS5LqU3LPEk5h/c+chlDR eYCVLD7PMcqSpCZDcrnJsf2kPCl1rFtp832q0a+mjTTmkiIN3E6W7LMq9dh+1QDuRvyQAr7e80nw Z4f0FYhpuh6bp4hkaaMWtpHFsdt4LDaBgnzJMn/bb1NU4fhn4Qtpo5YvCuiRSxz/AGpHTToQyzfL +8B28P8AInzdfkX0FD8gXmc3rnxog07R/DOsWmk3E+lazbNfG5ud8X2a3HlkPIEjfZuWTcDKY412 kO6EgHF1L9qHwxo/hj+2r+2vbCCO5gtrj7RH8sLSSwqylk3AusU6TbRnKnAO7IHpN74K8PalBp8N 3oOmXUOnKEso5rON1tlAUBYwR8g+ReBj7o9BVeP4deFIbo3MfhnR0uCQTMthEHyJBKDnbniRVf8A 3lB6ih+QLzM7x98QJvBui6PeW2kyahcandLbR2zecWTMMkpJEEUznAiIwqNyc5ABNc9oP7R3hbxD 9jgs0vLnUrmKFlsreMSMHeJZDHuB2gqGGSSAedpO1sdtL4D8OXGlx6bPoWn3GmxSLLFZzWySQxMq bFKIQVXC/KNoGAT6mix8BeGdNvkvrPw7pNreoFVbiCyiSRQqBFAYLkAIAo9AAOlAHH3nxrWPw7pu s22j/wCjTaLBr14t7dCFra3lxtUbUcPJw2clUXblnUEGmXn7SPgnTb6e1vLy4tZIYZrhvNgI/dxt Ou7Gc4ZracA4x8gzjem7s7zwD4Y1Cx0+yuvDmk3Nnp8fk2dvNYxPHbR4UbI1K4RcKowMD5R6U26+ H3he+mE1x4b0i4lEUkAklsYmby3370yV+63myZHQ+Y2fvGm/IDk7j9ojwZaaSl/NeTRq4BWJ4wrM DMkAYEnbtMziMPu2EgkNtBaom/aE8P3F3YW+n2Wqai17Jth8u0ZTKvkLMzIGwSVEsOQduPM/2WA7 NvAPhhrE2TeHNJNmY1hNubGLy9iyGVV27cYEhLgf3jnrzUV18N/CV9aRWtz4X0a4togRHDLp8TIg IRSApXA4jjH0RfQUgOW/4aI8GNbW92t3cmwuZVit71rcpBKC8iNIHbACq8Tod2CW2gAl03Sx/HLR ptc0WzWy1AWWqx74NQe3Kx4aW2igbHXZK11GFbqM8gAMR0c3w08IXTzPN4V0WV5pFmlZ9PhJd1DB WbK8kB3AJ6b29TU9p4D8Nae7Pa+HtKtnaXzy0NlEpMm9H38L97fFE2euY0PVRT6oDdooopAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV4344+DXiLV/Fmq6/4d1+DRrzUJk3mVWkU JHaGOCQLjAljmJYdmSRw2SF2+yUUAeN3nw1+IVxpLwW3ixtNLxuwtV1CadomErbIhdOnmMrwyyK0 hXejJCyg7eY9N+E/jqGa1uLvxjdTyxSwsY21Kd4/LRrHMbAIqyfLFfLuKgv56lueV9oopNX0BaO5 866T8FPijpfh/StOtvGYsEsrT7PFDBqc7pbsLeKPdueEmZXdJG2tt8oSYQnaMeoa18OLfUNc8K6n LZWupyeHYJpYHvD5l091sCQ/vnBbbhpicn75jbkrx3VFUB8/eKPgNrviy58R3b6f4d06fUrtmjWG 4kZDH5F5HHPIPIBNyj3XnbssCVVQU2hz0PiT4L3uoS62bJdOkbUPEUet29zeyyNLZMtvap5q7kfc we3f92CvyOFWSMcV7BRSAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA//ZUEsDBBQABgAIAAAAIQC0z1gZuQAAACQBAAAsAAAAcHB0L25vdGVzTWFzdGVycy9f cmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHOMz8EKwjAMBuC74DuU3G23HURk7S4i7CrzAUqXdcWt LW0V9/YWdnHgwUsgCf8XUjfveSIvDNE4y6GkBRC0yvXGag737no4AYlJ2l5OziKHBSM0Yr+rbzjJ lENxND6SrNjIYUzJnxmLasRZRuo82rwZXJhlym3QzEv1kBpZVRRHFr4NEBuTtD2H0PYlkG7x+I/t hsEovDj1nNGmHydYylnMoAwaEwdK18laK5o9YKJmm9/EBwAA//8DAFBLAwQUAAYACAAAACEAcocj rcIFAAA2GwAAFAAAAHBwdC90aGVtZS90aGVtZTIueG1s7FlPb9s2FL8P2HcgdG/9r8nioE6R2E67 NemCJM3QIy3REmtKFEg6qW9DexwwYFg37DJgtx2GbQFaYJfu02TrsHVAv8IeKVkWLbpxmxYr0NqA RVI/vv/v6VG+eu1ezNAxEZLypOM1Ltc9RBKfBzQJO97tw+1Lax6SCicBZjwhHW9CpHdt48MPruJ1 FZGYINifyHXc8SKl0vVaTfqwjOVlnpIE7g25iLGCqQhrgcAnQDdmtWa9vlqLMU08lOAYyO5gQaXE l3pE0jDxNqbk+wx+EiX1gs/EgSZO8j0GFYwa+iJFOOgygY4x63h18/FqG1drBYCpKm7bfHJcDghG zfPoGQBTVdxaXX8LegaAfR/kr/Le2urX+60cWwJlwyrtFnzabQtfot96sW4lUDa88mIdS6BsuFLB 9zb7vb5N34Cy4WoF3+w1e2ubFt6AIkaTkUOadrvQtoAMObvhhLfb3W4h/AxVK8VMtj9RVgTlUWcC KcZ3udgGhPEuVjRBapKSIfYB2MWMDgTVHPA6waU72ZIvK0uaGZK+oKnqeJ+kGEJ9Bnn+5OfnTx6h 509Oz+4/Prv/29mDB2f3f3VsvIGTsLzx2Y9f/fv95+ifRz88e/iNGy/L+D9/+eKP3792A1UZ+PTb 078enz797su/f3rogG8KPCjDD2lMJLpFTtA+j0E3BwMyEC+34zDCtLxjMwklTrDe40D3VWShb00w ww7cFrEteCQoFDMH8Pr4riXwQSTGKne5BbwZxRZwl3O2xYVTp5uaV9kK4yR0MxfjMm4f42MX7+6c f/vjFOKZukh2I2KJucfA5TgkCVFI3+MjQhzb7lBq2XWX+oJLPlToDkVbmDpNckgHVjTNNt2gMfhl 4hIQ/G3ZZvcIbXHmIt8jxzYSsgIzF0nCLDNex2OFY6fEOGZl5A5WkUvIg4nwLYNLBZ4OCeOoHxBd PKp7PhUTS9ybUD3cbt9lk9hGCkVHLuQO5ryM7PFRN8Jx6pSZJlEZ+7EcQYhitMeVUwhuZ4iegx9w stDdR5RY7j4/t2/T0BJpFiD6zljktdsqwjFN3lfkpSvypqDOlJivw4tw89W3y0VA3/7i28PjZI9A vL+vve9r77tYexfl87IVd1ZkTe887ZANvXhxuzykjB2oCSM70tRnCVIH27BoJmZX0Z6nEQxzfhYu FNiMkeDqM6qigwinwKdhOIQyJx1KlHIJhwKz7KRtzosUtDdrK9OjDKCx2uVBfoQqH3EKMmYWmgPm lFFLE1iWWeujizFrZMAluTWMaFVuhcpObuaSWxPSAWF9uG+sNjPWEDKYkUDbPSMwdctrd5GMcEBy H2m9q4o0jN2WMNva+VYrcWtrshfgtoyTyuyuLGA39d5FvDQlMPOSTty5dGSJPUMnINVKc8VDPk47 3hDaKRjGKdCTugJhFiYdz1e5Kucm87zC7rBs1BcqbLFIhVQ9LKNsl7k1fYuSzORvrlzRdng9Cjiq 0XJStNYa/6MU5lJ2LRkOia8WrMym+T0+VkQcRMEJGrCx2Mcgtw5V0CegEh4aJtb0RECGmjswszM/ zwLHuyPz+oelEc5rkk7RqYYZ3IwLGcysJF4xm5P9FVUxKf+aVCmH8Tumio5c6FtbgTlVQR8gMNIx 2vG4UBGHKpRG1N8W0DkYXiAXgrTQIiGm3ylrWcnxrG5lNLIiF0Zqn4ZIUKh0KhKE7Klcz3OINfKq mGdGTiivM4W4Ms2uA3JM2KHO3lWtv4eiaTXJDWFw806z57kxBqFO1Le188nC5mXbgxmjbP+yzEpF v/QoaF9MhJd81GYVq8KuubL0ozaF0wfSP1C4qfAZKfrbQ74P3kdFR4kgEC9ljQfSqZiNBiBztphx 06TebBs1c0HB9w02nyVjF+3SnLFfzO7VjZ2PLFuX48hh6lo1RXV7ND3JmFnlnyU+uAu8e3BSGjMl s1dK9+Cs2Z3+ewB0Mo5m68Z/AAAA//8DAFBLAwQUAAYACAAAACEAo5j4kzgBAADtAgAAHAAAAHBw dC90aGVtZS90aGVtZU92ZXJyaWRlNC54bWyE0t1OwyAUB/B7E9+BcL/RDzvdsnZZv+KFiRfTBzi2 rCWjdAEy9e1ltM42XSY3HMKP/4GE9ear4ehEpWKtCLE7dzCiomhLJqoQv7/lsyeMlAZRAm8FDfE3 VXgT3d+tYaVr2tBXc1aykiKTI9QKQlxrfVwRogqzDWreHqkwe/tWNqDNUlaklPBp8htOPMdZkAaY wJEJLLjcnU9RJKAxvV5AMqVgllLFKoFci8qDe56UrD4SLtEJeIgdOzCJ1uQCuJ663I7e9aA8eP/l WcD11C2zrRt7lzwLoCiouNI7cTM/i3s7QF05zV4sEz/djvwg37/9tgHqyofbbxygrgwmPk2zPPdH 3qKuXEx8kMVOEoy8RTVn4nDl9nEcPPb6QvYtf77KnTjI0l/+p8jgD9nV6ItGPwAAAP//AwBQSwME FAAGAAgAAAAhAHKHI63CBQAANhsAABQAAABwcHQvdGhlbWUvdGhlbWUzLnhtbOxZT2/bNhS/D9h3 IHRv/a/J4qBOkdhOuzXpgiTN0CMt0RJrShRIOqlvQ3scMGBYN+wyYLcdhm0BWmCX7tNk67B1QL/C HilZFi26cZsWK9DagEVSP77/7+lRvnrtXszQMRGS8qTjNS7XPUQSnwc0CTve7cPtS2sekgonAWY8 IR1vQqR3bePDD67idRWRmCDYn8h13PEipdL1Wk36sIzlZZ6SBO4NuYixgqkIa4HAJ0A3ZrVmvb5a izFNPJTgGMjuYEGlxJd6RNIw8Tam5PsMfhIl9YLPxIEmTvI9BhWMGvoiRTjoMoGOMet4dfPxahtX awWAqSpu23xyXA4IRs3z6BkAU1XcWl1/C3oGgH0f5K/y3trq1/utHFsCZcMq7RZ82m0LX6LferFu JVA2vPJiHUugbLhSwfc2+72+Td+AsuFqBd/sNXtrmxbegCJGk5FDmna70LaADDm74YS3291uIfwM VSvFTLY/UVYE5VFnAinGd7nYBoTxLlY0QWqSkiH2AdjFjA4E1RzwOsGlO9mSLytLmhmSvqCp6nif pBhCfQZ5/uTn508eoedPTs/uPz67/9vZgwdn9391bLyBk7C88dmPX/37/efon0c/PHv4jRsvy/g/ f/nij9+/dgNVGfj029O/Hp8+/e7Lv3966IBvCjwoww9pTCS6RU7QPo9BNwcDMhAvt+MwwrS8YzMJ JU6w3uNA91VkoW9NMMMO3BaxLXgkKBQzB/D6+K4l8EEkxip3uQW8GcUWcJdztsWFU6ebmlfZCuMk dDMX4zJuH+NjF+/unH/74xTimbpIdiNiibnHwOU4JAlRSN/jI0Ic2+5Qatl1l/qCSz5U6A5FW5g6 TXJIB1Y0zTbdoDH4ZeISEPxt2Wb3CG1x5iLfI8c2ErICMxdJwiwzXsdjhWOnxDhmZeQOVpFLyIOJ 8C2DSwWeDgnjqB8QXTyqez4VE0vcm1A93G7fZZPYRgpFRy7kDua8jOzxUTfCceqUmSZRGfuxHEGI YrTHlVMIbmeInoMfcLLQ3UeUWO4+P7dv09ASaRYg+s5Y5LXbKsIxTd5X5KUr8qagzpSYr8OLcPPV t8tFQN/+4tvD42SPQLy/r73va++7WHsX5fOyFXdWZE3vPO2QDb14cbs8pIwdqAkjO9LUZwlSB9uw aCZmV9GepxEMc34WLhTYjJHg6jOqooMIp8CnYTiEMicdSpRyCYcCs+ykbc6LFLQ3ayvTowygsdrl QX6EKh9xCjJmFpoD5pRRSxNYllnro4sxa2TAJbk1jGhVboXKTm7mklsT0gFhfbhvrDYz1hAymJFA 2z0jMHXLa3eRjHBAch9pvauKNIzdljDb2vlWK3Fra7IX4LaMk8rsrixgN/XeRbw0JTDzkk7cuXRk iT1DJyDVSnPFQz5OO94Q2ikYxinQk7oCYRYmHc9XuSrnJvO8wu6wbNQXKmyxSIVUPSyjbJe5NX2L kszkb65c0XZ4PQo4qtFyUrTWGv+jFOZSdi0ZDomvFqzMpvk9PlZEHETBCRqwsdjHILcOVdAnoBIe GibW9ERAhpo7MLMzP88Cx7sj8/qHpRHOa5JO0amGGdyMCxnMrCReMZuT/RVVMSn/mlQph/E7poqO XOhbW4E5VUEfIDDSMdrxuFARhyqURtTfFtA5GF4gF4K00CIhpt8pa1nJ8axuZTSyIhdGap+GSFCo dCoShOypXM9ziDXyqphnRk4orzOFuDLNrgNyTNihzt5Vrb+Homk1yQ1hcPNOs+e5MQahTtS3tfPJ wuZl24MZo2z/ssxKRb/0KGhfTISXfNRmFavCrrmy9KM2hdMH0j9QuKnwGSn620O+D95HRUeJIBAv ZY0H0qmYjQYgc7aYcdOk3mwbNXNBwfcNNp8lYxft0pyxX8zu1Y2djyxbl+PIYepaNUV1ezQ9yZhZ 5Z8lPrgLvHtwUhozJbNXSvfgrNmd/nsAdDKOZuvGfwAAAP//AwBQSwMECgAAAAAAAAAhAA4V6ROV AwAAlQMAABQAAABwcHQvbWVkaWEvaW1hZ2UxLnBuZ4lQTkcNChoKAAAADUlIRFIAAAAFAAAABQgD AAAAurHW1wAAAwBQTFRFAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8AAAD//wD/ AP//////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzAABmAACZAADMAAD/ADMAADMzADNmADOZADPMADP/ AGYAAGYzAGZmAGaZAGbMAGb/AJkAAJkzAJlmAJmZAJnMAJn/AMwAAMwzAMxmAMyZAMzMAMz/AP8A AP8zAP9mAP+ZAP/MAP//MwAAMwAzMwBmMwCZMwDMMwD/MzMAMzMzMzNmMzOZMzPMMzP/M2YAM2Yz M2ZmM2aZM2bMM2b/M5kAM5kzM5lmM5mZM5nMM5n/M8wAM8wzM8xmM8yZM8zMM8z/M/8AM/8zM/9m M/+ZM//MM///ZgAAZgAzZgBmZgCZZgDMZgD/ZjMAZjMzZjNmZjOZZjPMZjP/ZmYAZmYzZmZmZmaZ ZmbMZmb/ZpkAZpkzZplmZpmZZpnMZpn/ZswAZswzZsxmZsyZZszMZsz/Zv8AZv8zZv9mZv+ZZv/M Zv//mQAAmQAzmQBmmQCZmQDMmQD/mTMAmTMzmTNmmTOZmTPMmTP/mWYAmWYzmWZmmWaZmWbMmWb/ mZkAmZkzmZlmmZmZmZnMmZn/mcwAmcwzmcxmmcyZmczMmcz/mf8Amf8zmf9mmf+Zmf/Mmf//zAAA zAAzzABmzACZzADMzAD/zDMAzDMzzDNmzDOZzDPMzDP/zGYAzGYzzGZmzGaZzGbMzGb/zJkAzJkz zJlmzJmZzJnMzJn/zMwAzMwzzMxmzMyZzMzMzMz/zP8AzP8zzP9mzP+ZzP/MzP///wAA/wAz/wBm /wCZ/wDM/wD//zMA/zMz/zNm/zOZ/zPM/zP//2YA/2Yz/2Zm/2aZ/2bM/2b//5kA/5kz/5lm/5mZ /5nM/5n//8wA/8wz/8xm/8yZ/8zM/8z///8A//8z//9m//+Z///M////RGKwUAAAABF0Uk5T//// /////////////////wAlrZliAAAAAWJLR0QAiAUdSAAAAAxjbVBQSkNtcDA3MTIAAAADSABzvAAA AA5JREFUGFdj+A8CDDhIAHW2GOiD2w0MAAAAAElFTkSuQmCCUEsDBBQABgAIAAAAIQCTqn2YuQAA ACQBAAAwAAAAcHB0L2hhbmRvdXRNYXN0ZXJzL19yZWxzL2hhbmRvdXRNYXN0ZXIxLnhtbC5yZWxz jM/BCsIwDAbgu+A7lNxtNwURWbeLCLvKfIDSZl1xa0tbxb29hV0cePASSML/hVTNexrJC0M0znIo aQEErXTKWM3h3l13JyAxCavE6CxymDFCU2831Q1HkXIoDsZHkhUbOQwp+TNjUQ44iUidR5s3vQuT SLkNmnkhH0Ij2xfFkYVvA+qVSVrFIbSqBNLNHv+xXd8biRcnnxPa9OMESzmLGRRBY+JA6TJZ6oFm D1hdsdVv9QcAAP//AwBQSwMEFAAGAAgAAAAhAF75POVdBgAA9x4AABQAAABwcHQvdGhlbWUvdGhl bWUxLnhtbOwZ2W7bOPB9gf0HQu+pb+dAnSJ27O0CadeIXfSxoCXqaChKS9KJk6/f4ZCU5SOJ26TY BTZ+sIej4QznHsrvP6xyTm6ZVFkhBkHrXTMgTIRFlIlkEHyZT45OAqI0FRHlhWCD4J6p4MP577+9 p2c6ZTkjsF+oMzoIUq3Ls0ZDhYCm6l1RMgHP4kLmVMNSJo1I0jvgm/NGu9nsN3KaiYAImgPb6XT+ TbO85FSzb3/FcRayb0B0HJx7QWMOX0Irgwi5nBkxzO2+ojJTih5dMpUlgrRwV3TTMj9KJosRl+SW 8kHQxE/QOH/fqAi43qWb4MfROYLopv0cPyTgepfudHzRGrYrfkhAwxD02ZU9ao0746GjrRFZcJd3 /3TUubzYoK/x7zytW43Igt2ndawRWbC3Q395OZ5MOhv0SGTB/g59bzxsjnob9EiU8kzc7Dn9cNg7 dtQVSVzwj3vJm83eRaXsmqpRiyG7X+gnIgrjKaffCzkBQnQy1Zkg+r5kMQ2B/kJmlBsx9IzRGt6i QrWFamyxyzPxqrzX7FBtrxyqmu/VFFWMM85n+p6zK4UnUQXPogkgcYG7KsuWKYBO3gZdIinCRBb6 a6bTWUpLkGOTMlGOdaJIWShwEKL38sbUz4R2YeKjEKip/lREFt2pR2fFBlcJ1govqGMYHCqsc/wy YS1LeKC0Fh5tV1ql8l5p+OOsCVFNqKnYrX7biiYqpJxFxu6WgXfLq7tIpTRizkdG711FWmi3A8x2 8rzVatJODdsXSDvESXVx3UfEee+9xEuewdpLJnG30pGLzRW5g1P12r2AhLQcBDEUDgDzEvgpkQSE 8gR6eqidKs8m87bC+8Oy1XxU4Q0RpVT6kqrU7sJHvgGK9fnbva6xw+sosKcaHXaKzknrXzwF/tRd y+KYhfoRzHrpnhVLzeQsje7Igi/lNYVzm1AFfaJMaTCxX0jIUHwCq83Md1mwp+1j5+ZlSl1NMinq NbTkCFdnwFXteNVq6+w/qQqm/CupUg/j/5kqJnKZYJ0IJwiYAyQlJkYHQSF1WkAVKtMsnEiYHFAW nItAWpgjEW4uCuas7HZdtywPW+SSVF9nCZEZVDqdSsam2un5DLOWq4ouMxwjV2eq46rS/i7YLeNz k719o39AUl9NnCGQbttpm2tnjEViEvW/OvnYsPnR8WAtyO4/VFit6NdawenLjvCDrdZWrB1x7d7B rbakOiXmCwp3JkPOqvl2XlyD90k1URIIxCM7eBCTihZawJkt0kozrH7tGLV2QSX3Fw6fNWNX49KW sZ8W9/PGdtCGretxtMfUjd0UNeORv8ngauclQbH4DrIv4Wa05BajSlhZYCrJ4g50BXfRpS7wwKtY 5rgxjskKq9K9K3BQM1aahCvjWxLer4dqvyVcKv0HKxCmt3BA3JREHqKph8KV8KB0prFmsSax5nBC jSUssamwNRFPVSf3xmBffXrNiVGv9op4ZNAxRX8pIoRSRqOxiPDWOghEIVhgjpWzCNoBExZCSk0z fghlNcxVHc53gKnE8l5E9+DwWybBzmkhH4CNNPqrv5dUAlP+p4C8OW11u8YXuOj2jtvGJfUni/oT scxHhRmHwWoiBK6mvTlwpK0rwyIHH16JWRn6smAMNF99pbJ0DVdDaH0usHTYtu7Cx2RCRWtTANVA R6r10BGxeArK5VReoUwArhHIRASBgKB1K4cuzOI5XcwenEpGQW0jkNErMZQ3qI95YXCBWxZUGfOY FxLusemzcIfJRDJdilB7tbjR0aZWOA39vXajndcohj4N17Trrl17ehHbZryfzj1dLCEo5yuMmMVy 9lCB5gVItfgM0eOCauETEKxxDaa7WeZZXnzP7ECCFzQmjr7M4Hb2YOugS0piSZY+FpWW2Q1G5gwh l1X2oTAvPnn2wD7arAZLwv0Ppzqicj3ijOLoY61nvkVhsqgez5sJ+OhLuQ2yeg489i6JhCmVimFw uHeXaAoPTh24jjO0uKueXLyV0bcy+lZG38roWxn98TLqqqe5ne8MqBDDko78HxP+1c8G8u3vr7e/ v1797y9YfKIlWSQtKG/Q9Ai0pUEAAQIJl7QNrm1wbYMDyHll3SQdpu0xFU3HYzoe0/WYrsf0PKbn MX2P6UOVNCeGdmN+TEm1KkDPdZDTbTtJdlD+0ojXxPN/AAAA//8DAFBLAwQUAAYACAAAACEAIs2M 3MIBAAD5BAAAEQAAAHBwdC92aWV3UHJvcHMueG1spFRNb9swDL0X2H8QdE/9sdRxjDjFgGGnHgYk 612QGEeDLQmikib99aPtJM2HD2l3E6nHx/co2rPnXVOzLXjU1pQ8eYw5AyOt0qYq+Z/lr1HOGQZh lKitgZLvAfnz/NvDzBVbDW+/PSMCg4Uo+ToEV0QRyjU0Ah+tA0N3K+sbESj0VaS8eCPipo7SOM6i RmjDD/X+nnq7WmkJP63cNGBCT+KhFoHE41o7PLK5e9icBySarvpC0pzMmRZYv3YW25iwwXpQL7AK DN9pVE9ZMuVMbIL9of5uMJQ85tE5dGldh5yOs3QygIxuu2CtFXyEclGrs6g/sq3wCylqeoykk4pt MJ+JAneM3jBPOFN0F3dNKLu/zUanKldYrytt2I4ux1N67X3Js/QAOrRsYdWGpL1gOJ0ZFdL4aNLW v3PmLJY8TbLDEHpIn8zzY9MPkpb8zF0r6NK7sQFwCbtwM4ABz62tAdNX6WHXcWf5CDj16F7nRgJa H8DfIynLhhRdZj8r6Lp7J/A/1+VpUOdldljnKMnb+ZLW0eSrC/M9SQcWJhnfszBX7iuv1cIJST8Y JknehD5oWme5Px57xv6vNf8HAAD//wMAUEsDBBQABgAIAAAAIQA/hbhxIgIAACgLAAATAAAAcHB0 L3RhYmxlU3R5bGVzLnhtbORW32/aMBB+n7T/wfJ76iSEliFCBbRok7Y9dKzvTuyAVf+IYq9QTfvf 5zgBAkurdSUS0l6ITe7u++7z3Tmj643g4JEWmikZw+DCh4DKVBEmlzH8vph7Awi0wZJgriSN4RPV 8Hr8/t0ID03Cv5knTj9rA2wUqYc4hitj8iFCOl1RgfWFyqm07zJVCGzstlgiUuC1jS44Cn3/EgnM JASEZjH82Z+FYT+KJt7V7e2lF/Wi0Jv60cAb9Kc3sw/zm2DWm/yC4wa25WZ/P5G/dq4cvmJhc/lC CfshQBUoBB6YpCmVBgQOYr1SnC4S7uDSxcaZlZtMSXNHM8DIJoaCSVU4+7zQZsYL8Ih5DBOO0weI xiO0sy9tnCx0Z0UegtrmAMCkjeWUFOWC08y4pwRre07hlW9PKhW5zVzLpSOgFWdkzrhjfITEzRap YYXKcNWjjl6w5apDmF14o/LuUOrgiTJGie5g9vGZ1IzQj91BNQCq5X3XWPd1VdbVl21DvRAXu+ap escw20buX9vjll6Nt3VoQa8QHGZd/OiwBRM7gwInwXF7oLcxjN7CcM+qXIXP8WvxqmydvzvNs8vK sXJMn+PXllVVmdiOQnU4OUESQyUdy9MN0H0tvzhAX61lW3+0KtXINGMl//8i62aqpQJ3an02Wf9x vfQGwemvl38djq8qrFpWp/a5SXx8u55a5W38zoXeq1u+qD8rDzb2+3b8GwAA//8DAFBLAwQUAAYA CAAAACEAtj80JO8BAABtBAAAEQAAAHBwdC9wcmVzUHJvcHMueG1srJRdi5wwFIbvC/0PkvusMWpG ZZwlmSgUWljaLb1ONc6EqpEks7ul9L83M+Nuu1sHllIFo7w55zznI66vH4Y+uJPGKj2WILpCIJBj o1s17krw+baGGQisE2Mrej3KEnyXFlxv3r5ZT8VkpJWjE86b3pjAOxptIUqwd24qwtA2ezkIe6Un OXqt02YQzn+aXdgace8DDH2IESLhINQIZnvzGnvddaqRXDeHwQOcnRjZn0jsXk320dv0Gm9/5vEM aXNK8pibf37ZC+e9+Urog7MYBJ0Rg/zUq1ZaXzgQHnc3vflgDpu1KKzZfd32JrgTfQnoFqE8O255 IdQ18teiQMiikHJGFwWEMn8vCJxljKdLMSqeL1Ixwjmpl2LkF3B95FkIfxdhKuSDe2/d/BYcjCrB j2pFtlWeUEhQvIVJlGDI8opBwqN4hVCEKF79PJY+SopW2UaY9t0gdrJqlePCicfORslfvR1UY7TV nbtq9DAPSTjpe2kmrU5zEqF52M7UM7CHe87I44gigilc5RmFSYxzSBnnkDGapYRglEboiVF24tC7 EyOf1H/Ew/giYM3TqqaUQ1RtK5ikcQXzLI5gQhiOWeWXODkDpkWzF8bdGtF880fuo+yYsLJ9wkz/ BRNfrOJ5PTU9fPmH2PwCAAD//wMAUEsDBBQABgAIAAAAIQB1dLiARQEAAOwCAAARAAAAcHB0L3Rh Z3MvdGFnNS54bWyMkl1rwjAUhu8H+w8l95rqxRjOKs5VJ1RbbL3YZWiPbSBfJNG5f79Y7cCqQ8hN cvI85z0hw/GBM28P2lApAtTr+sgDkcuCijJAm2zWeUWesUQUhEkBAfoBg8aj56ehGlhSRsZ6TiDM gASoslYNMDZ5BZyYrlQgXG0rNSfWbXWJC02+nZgz3Pf9F8wJFejM60d4ud3SHD5kvuMg7EmigRHr wpuKKtPY1CM2pcE4TU1fRBqdhvME4W7iaRzF6zTMptEkTVeTZYi8PWHuXDKpU7A9hC+BZbQ4X7kq pZ+TJHSu+TreJG1hWhEFTjjXcqf699AritEC2pebzDf7NMHrPhEtK9vGZ/Equ0fPpLD/h2wTEdEl ZHCw7/JwH0jWcRZOs4Vr/ZU0qH97sHO103/7W/UzHJsc89UTutMjjZuPOvoFAAD//wMAUEsDBBQA BgAIAAAAIQBh4tD7kgEAAAIDAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB8klFr2zAUhd8H+w9C744km4wgEhfa0acVAvXY6Jsm3aaitiSk m6TZr5/kxm5Dy8BgrHvOx9G5Xl+9DD05QEzWuw0VC04JOO2NdbsN/dndVitKEipnVO8dbOgJEr1q v35Z6yC1j7CNPkBEC4lkkktShw19QgySsaSfYFBpkRUuDx99HBTmz7hjQelntQNWc/6NDYDKKFSs AKswE+kZafSMDPvYjwCjGfQwgMPExEKwNy1CHNKnhnHyTjlYPAX4VDoNZ/VLsrPweDwujs0ozfkF +3334368amVd6UoDbddGS7TYQ6u9CmSPtrd/FeaWSe6B/NnbvnRMtHcYfb9ms744dQSFPrZbyJnJ QTli8vse/fMonMZlCb1KeJf39WjBXJ/acOFIo+OjqhgjHGzZeitW9aiZDybsNlqHYNqaC14JUfGm 47UUXDbLh5k6idbn5l/DgSG5Mfna7zT51dx8725p4RVYVS87LqTID38o97rwvwGHc+7/E5sx4bKr a1mvZC3eESdAO4a+/GvbfwAAAP//AwBQSwMEFAAGAAgAAAAhAEzWDGJcAQAASwMAABIAAABwcHQv dGFncy90YWcyMy54bWyMk1FvgjAUhd+X7D+Qvivow7I40RiGzgSFWHzYYwNXaFLapq3O/ftVBJMp JCa8QM937rmnYTo/V8w5gdJUcB+Nhh5ygGcip7zw0T5dDt6Row3hOWGCg49+QaP57PVlKieGFJE2 jjXgekJ8VBojJ66rsxIqoodCArdnB6EqYuyrKtxckR9rXDF37HlvbkUoRw2vnuHF4UAz+BTZsQJu riYKGDE2vC6p1K2bfMZNKtDWpqb/RZpdl3M4qezGy3ibIudEmI8wozmk1DBYCm6Q+yjEYRpEC4y3 i03YQBcpBjO6lwdxFO869IFgQnUBm2jdSB6O8NciCa3Xahfvk3tDXBIJ1nClxFGO+2J0om2WGo1o UfYt3Uk3m3fPrSPfE3W3Ma977geSXZyGQbq2o7+TFvX6OnmYsU6jMLBsaO+1s4xGOBh/3J7rzcPZ XHaqW7FfL7Tb/gezPwAAAP//AwBQSwMEFAAGAAgAAAAhAI9d6eZZAQAARAQAABMACAFkb2NQcm9w cy9jdXN0b20ueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtJNRa4MwFIXf B/sPIc+1RjvXWtTSaguDPpTq9i4aNUwTSa5uZey/L2WzpW9jw6cQbjjfOeQeb/Xe1KinUjHBfWxN CUaUZyJnvPTxc7IzFhgpSHme1oJTH5+owqvg/s47SNFSCYwqpCW48nEF0C5NU2UVbVI11WOuJ4WQ TQr6KktTFAXLaCSyrqEcTJuQRzPrFIjGaC9y+Ftv2cNfJXORnd2pl+TUar3A+xE/oaIBlvv4I3LC KHKIY9hbNzQsYm0Md+bODbIgxN7Y4c5dbz8xas+PbYx42ujo6w4qIcM40Yo9LOv2TYEMDhSoRH3K Ua7PGMSrZ16nnjmw/+liNriIaQZC3lgYBfgwAKMU6A1u3ZX6z9BsYhPLHoXtDOwjKysYP+vjhUcL KvX+3wZ+2ia7CTqK/X4U+nygh4IXLNdrzNJ6/NCLCzZOhv6cC/Mrsnmtf/AFAAD//wMAUEsDBBQA BgAIAAAAIQArrlGXSQEAAAsDAAARAAAAcHB0L3RhZ3MvdGFnMi54bWyMkl1rwjAUhu8H+w8l7Faj DsZwVnFdq0K0xdaLXYY2bQP5Iolu+/cLagdWO4TchHOe57wnZDL75sw7EG2oFD4Y9gfAIyKXBRWV D3ZZ1HsFnrFYFJhJQXzwQwyYTR8fJmpscYWM9ZxAmDH2QW2tGkNo8ppwbPpSEeFqpdQcW3fVFSw0 /nJizuBoMHiBHFMBzry+h5dlSXPyIfM9J8KeJJowbF14U1NlGpu6x6Y0MU5zpC8iTU/LeQJzt3EQ o3ibAu+AmQ96o7fLA+Ct7jAL0DxNN/N1eAYDyaROiR22gTVanVuuSulynoTOtdjGu6QtTGusiBMu tNyrqxgNekUxWpCuzDfnNMGPcxCtatvGo3iTddGRFPb/kG0ik4pRQXR3c7RCf+ss0ftiFDwF/YqW 3USyjbMwyFYu6GfSsM/H94bNP57+AgAA//8DAFBLAwQUAAYACAAAACEAd5Eyl4kCAAD0CAAAEQAA AHBwdC90YWdzL3RhZzEueG1spFZhb6IwGP5+yf0HwucpKuqWZW5hUlyzQg0tu9t9uTRQlRwCgbrd /v31JizdGMq2xCimz/O8z/u0fcPF1d9toj3wooyzdKYP+wNd42mYRXG6nukBdXpnulYKlkYsyVI+ 0594qV9dfv92kZ8Ltkal0KRAWp6zmb4RIj83jDLc8C0r+1nOU7m2yootE/JvsTaigj1K4W1ijAaD qbFlcapX/KILP1ut4pDbWbjb8lTsRQqeMCHNl5s4L2u1vItaXvBSyjyzX1m63DenpWwrO3YR1LUH lsh0dOP1ErLucUCR5S0CawFq1MA03wLnzqK/B1cgm6/YLhHv4eYBodgF/h3wCcReRWhKYs+Bi+Ny r2UaLbjW0rPc2rvL8maTcA48Am7BfQWahtPxdHS66oWTaNwbj8ywd3Y2GPemfDo1zckpO13xRhn0 e1jRlzfw7aoDAbJJH3qQQgvBX8Bus/uM7FsBvcF+f47daww9G/ys4L3R+3gb3sH/IXyAYVHQHS33 ggKP4h8e+IArSLAXuNfdKBRSBFyLUODvv5Vdo7FIOEniqBG7wiI31hIQQBc+DpZzZBGiKJANyznh YlFku/xQ7TlG2G9TmWdJVtQqKF5vGgdSUXJkZm1CTpaKLm4IvUftPYmn5KWnxkFS88Q2lDvSeuYI gnZb9O+mrhC+kLqi8sXUFaVPp6729PnU1SiPpF7ddNuGnoPrG1aBD2PvLBTUdo6pvrl3jSnbmB/H bbyAO/io55iquuSCF/Ix1SL5S0T25yBZrdKVqk4etTQE1DnR/AyhYzy1ajtLTv3AIfi2AkZ8yCfy Y/LJiE/GByevasvarXfyRcM8GQ2Gh+a1aqrBMeoXlst/AAAA//8DAFBLAwQUAAYACAAAACEAR5T1 12MCAADrBQAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACkVFFP2zAQfp+0/2DlCR4gbQesVK4RKkNMohDRlD0iL7k2Fo7Psk0L+/W7JG3WbgWN rS/97u7Ll/Pn3PGz51KzBTiv0Ayj7mEnYmAyzJWZD6NpennQj5gP0uRSo4Fh9AI+OhMfP/DEoQUX FHhGEsYPoyIEO4hjnxVQSn9IZUOVGbpSBgrdPMbZTGVwgdlTCSbEvU7nJIbnACaH/MC2glGjOFiE fxXNMav68/fpiyU9wVMorZYBRJKkD2EVPNzWjz7QI5953FJ4ikHqVJUgTo/7Paq0Mf+GLveid3LE 4wbyc2u1ymQg/8RYZQ49zgJrlFmCS3AJKhN4vEkk98BTt3V0WR9G3JoDnzkAwyYFLtne0eDTPo93 EHkinZw7aQsv+l2i/Ar5RKscvKD2VojfYKA/ojWAX6k8B7Oqdni8FfPxeKSVrQtryCeZ1DAiO8VM ag8k3Sb4FcjqU0mkcsRchMECsoCOefWDPpaTiH2XHqpLGEYL6ZQ0IWpoTVBjbX1w4hJN8GzqIedx m6zhJncTq6PqnA14k9hopfQFwTu0u+/Qru1jqQoa/P+3Xwe1j4S3HW5ecTujOw87DD/dNLzuobG7 aeec9PVmey0a4ZNT4N6qsRtY7qxXg+GrKrvDUpqdnNenbucL776wJbpHOjabO3yyO2ljDGpRz8Ur KuOvTFraKjIr2F53/29YvS3W1j385vwISyvNi0gKVU0Jj9cJfq3Mo5/aFC+qZbIame0knxTSQU47 qx2pNsGv6PKcrvijQpo55GvOn4Vq+dw3u1t0jw879Kv3zDpXrY/1UhU/AQAA//8DAFBLAwQUAAYA CAAAACEAN99MKYABAACjAwAAEgAAAHBwdC90YWdzL3RhZzIwLnhtbIyTXWvCMBiF7wf7DyH3sypj bGKV0qYaSD9o44W7kaDRFtqkJNFt/35B2zGVgpch5znvOW/IdP5dV+DElS6lcOFoMISAi63cleLg whUNX94h0IaJHauk4C784RrOZ89P02Zi2IFoA6yB0BPmwsKYZuI4elvwmumBbLiwd3upambsUR2c nWJf1riunPFw+ObUrBSw5dUjvNzvyy0P5PZYc2EuJopXzNjwuigb3bk1j7g1imtrc6avIs0u5YBg tW0ckc0IghOrXJguMXSub0OMSJAPcIwp9gj+REGrHd0q86WXohzRRZasUp94eR57EWrVecEannOz UPLYjPvQW4piSpCfxBTF9JbxE5JkfeN8WUnVjSPloTB9eB95Vy+0MfrGhVKY/nJ0Tfr3Yn6qv73c zYy89J82YvcKP1wMiLdOVrQVBXzPjtVd3Yjgvndr9wtS4vlomZAAZeBjc36Sc9o0SyjyKbayddpl Gd66ZFbixQuCwOtDrNP9r9kvAAAA//8DAFBLAwQUAAYACAAAACEATNYMYlwBAABLAwAAEgAAAHBw dC90YWdzL3RhZzIxLnhtbIyTUW+CMBSF35fsP5C+K+jDsjjRGIbOBIVYfNhjA1doUtqmrc79+1UE kykkJrxAz3fuuadhOj9XzDmB0lRwH42GHnKAZyKnvPDRPl0O3pGjDeE5YYKDj35Bo/ns9WUqJ4YU kTaONeB6QnxUGiMnrquzEiqih0ICt2cHoSpi7Ksq3FyRH2tcMXfseW9uRShHDa+e4cXhQDP4FNmx Am6uJgoYMTa8LqnUrZt8xk0q0Nampv9Fml2Xczip7MbLeJsi50SYjzCjOaTUMFgKbpD7KMRhGkQL jLeLTdhAFykGM7qXB3EU7zr0gWBCdQGbaN1IHo7w1yIJrddqF++Te0NcEgnWcKXEUY77YnSibZYa jWhR9i3dSTebd8+tI98Tdbcxr3vuB5JdnIZBurajv5MW9fo6eZixTqMwsGxo77WzjEY4GH/cnuvN w9lcdqpbsV8vtNv+B7M/AAAA//8DAFBLAwQUAAYACAAAACEAy/uB1mQBAACAAwAAEgAAAHBwdC90 YWdzL3RhZzEyLnhtbIyTTW+CMACG70v2H0jvipplW1Q0BEFJUAithx0brEACbdNWt/37VQUT+VhM uEDf5/1Iw3z5UxbGmQiZM2qB8XAEDEITdshpaoE98gafwJAK0wMuGCUW+CUSLBevL3M+VTgNpDK0 AZVTbIFMKT41TZlkpMRyyDih+uzIRImVfhWpeRD4WxuXhTkZjd7NEucUVLx4hmfHY56QFUtOJaHq ZiJIgZUuL7Ocy9qNP+PGBZHa5ko/VFrcxhkUl3qxF+4QMM64sADKVUFWRCYeowqYbR10kRPYEO7s rVsxFykkatyUO2EQxrASDSaz+/MQ4rCCCf21m26nXfVdcdCJ/aje0Tr1fDdY1WXsPdqE8ayp2QZ+ Hw43duTqNus43EfNSjDDnOhKa8FOvDWkRpsU8lHg9q3uzKmnX3OCPM36bqiTrq7pn5JNwj6pjIl+ aRSHyHWQr0O/ohp6+7gAZv3zLP4AAAD//wMAUEsDBBQABgAIAAAAIQDpF7e3igEAAEUEAAASAAAA cHB0L3RhZ3MvdGFnMTEueG1spJTba8IwGMXfB/sfQt5nneyGeKGrqQtEW2wE3csINbWFNilJ3OW/ X+ZlbHZhjj2W7/zO+c4XaG/4WpXgmStdSNGHl602BFykclWIdR/OaXhxB4E2TKxYKQXvwzeu4XBw ftaru4atiTbAGgjdZX2YG1N3PU+nOa+YbsmaCzvLpKqYsZ9q7a0Ue7HGVel12u0br2KFgHtencLL LCtSPpLppuLC7EwUL5mxy+u8qPXBrT7FrVZcW5st/W2lwa4cEKyyjUOMyChp4Smm2Cf4EY0geGal PRb0visn5OlyP4sf8PE0efBjlCA6nkXzOCB+kkz9Cdrrk5zVPOFmrOSm7rjQY4piStCxOIhINHPl BLKU6pBDinVuXLiLbLQOoyl1xYVSGHcruiTug5i38vMgzUv78RfthDUVQThuEX8ZzeleNOIZ25SN uhOCXc9J0YKC+2gBrp62D7BdMZ5FFAUU29LL+LDA1a2Tvf4He/N3dmY1/nRMEOj8Brd/yv2IvTst 1jv8AQbvAAAA//8DAFBLAwQUAAYACAAAACEAzso3DVoBAABLAwAAEgAAAHBwdC90YWdzL3RhZzEw LnhtbIyTXW+CMBiF75fsP5DeK+qSZXGiMQw/EhQieLHLDl6hSb/SVrf9+3UIWwa6mHDT9DznnPdt mMw+GHVOoDQR3EPD/gA5wDORE154aJ8uek/I0QbzHFPBwUOfoNFsen83kWODi1AbxxpwPcYeKo2R Y9fVWQkM676QwO3dQSiGjT2qws0VfrfGjLqjweDRZZhwVPPqFl4cDiSDF5EdGXBzNlFAsbHldUmk btzkLW5SgbY2Ff2n0vQ8nMMxsxMvom2KnBOmHkooySHGBWyP7A3UQnCD3K46CVI/nCfJdr4JavJb moAZtuV+FEa7pBb1Rs8/XxXlCyqUPV2muimV/lLMJlzXks5VsprHgfVa7qJ93DZMSizBGi6VOMpO jQZtUykxFKoBrhW/GNa0r8JCUpTXlnuRrjf8T9M2sSJ5Dvz3Oa9D8S5KAz9d2/jXuMEfqlW6zX8w /QIAAP//AwBQSwMEFAAGAAgAAAAhAMvSQ4VXAQAAPwMAABEAAABwcHQvdGFncy90YWc5LnhtbIyS X2vCMBTF3wf7DiXvWnUwhrOK1L9QbTH1YY+hvbaBNAlJdNu3X1bbjbV1CHkJOb9zzr1kMvsomHMB pangHhr2B8gBnoiU8sxDx3jVe0GONoSnhAkOHvoEjWbTx4eJHBuSBdo41oDrMfFQbowcu65OciiI 7gsJ3L6dhCqIsVeVuaki79a4YO5oMHh2C0I5qnh1Dy9OJ5rAQiTnAri5mihgxNjyOqdS127yHjep QFubkv5TaXodzuGksBOvwn2MnAthHoqpYbAAnawEN8ht6/Ay9oM5xvv5blkx31IMZtiU+2EQHnAl 6o1efw5mNAVfMKHsrZtqp5T6rphdsK0krSe8mUdL67U+hMeoaYhzIsEarpU4y1aNGm1S5YLKAW4V 7wyr25dhAc3yW8vtpKsN/9O0SWxomgJfENOq+SuPDmG89OOtDX6LavCpXKJb//3pFwAAAP//AwBQ SwMEFAAGAAgAAAAhAMj6Kb9WAQAAQwMAABEAAABwcHQvdGFncy90YWc4LnhtbIySX2uDMBTF3wf7 DpL31raDMbraUpz9A7ZKYx/2GPRWAzEJSdpt336Z1cHUjoIvIed3zrk3zhafJXMuoDQV3EPj4Qg5 wFORUZ576JisBi/I0YbwjDDBwUNfoNFi/vgwk1ND8lAbxxpwPSUeKoyRU9fVaQEl0UMhgdu7k1Al MfaocjdT5MMal8ydjEbPbkkoRzWv7uHF6URTeBPpuQRuriYKGDG2vC6o1I2bvMdNKtDWpqL/VJpf h3M4Ke3Eq2ifIOdCmIcwoxmshDCgVoIb5HaVOEj8cInxfrkLaupHisGM23I/CqMDrkWDyevvV8X4 ggllT/1UN6XS98Xswm0t6VzhzTIOrNf6EB3jtiEuiARruFbiLDs1GrRNJdQwqAa4Vbw3rGlfhYU0 L24tt5euN/xP0zaxoVkG/PqUt4H4ECWBn2xt9HvcoE/VGt3m/59/AwAA//8DAFBLAwQUAAYACAAA ACEArAEhsFUBAAA6AwAAEQAAAHBwdC90YWdzL3RhZzcueG1sjJJfa8IwFMXfB/sOJe9adTCGs4rU +geqLaY+7DG01zaQJiGJbvv2i127MVuHkJeQ8zvn3Esms4+SOWdQmgruoWF/gBzgqcgozz10SJa9 F+RoQ3hGmODgoU/QaDZ9fJjIsSF5qI1jDbgeEw8Vxsix6+q0gJLovpDA7dtRqJIYe1W5mynybo1L 5o4Gg2e3JJSjmlf38OJ4pCksRHoqgZtvEwWMGFteF1Tqxk3e4yYVaGtT0X8qTb+Hczgp7cTLaJcg 50yYhxJqGCxAp0vBDXLbOhwkfjjHeDffBjVzkWIww2u5H4XRHtei3uj152BGM/AFE8reuql2SqXv itmGm1rSesLreRxYr9U+OsTXhrggEqzhSomTbNVo0BZ16X6rc2dOU7zKCWle3NprJ10v95+S18Sa ZhnwBTGtmr/yeB8lgZ9sbPBb3IBP1f7c5ttPvwAAAP//AwBQSwMEFAAGAAgAAAAhAFrMX8l9AQAA ogMAABEAAABwcHQvdGFncy90YWc2LnhtbIyTX2uDMBTF3wf7DpL31raMbdTa4qx2glUxdmOPQVMV NJEk7bZvv9jqYP4ZBV9izu/cc+8lq81XWShnzHhOiQ7m0xlQMIlpkpNUB4fInjwDhQtEElRQgnXw jTnYrO/vVtVSoNTlQpEGhC+RDjIhqqWq8jjDJeJTWmEi746UlUjII0vVhKFPaVwW6mI2e1RLlBPQ 8OwWnh6PeYy3ND6VmIirCcMFEjI8z/KKt27VLW4Vw1zaXOg/kdbX5hSCStmx7XsRUM6o0AEs8gTb lArMbEoEUPtKaEWma0DoGXuroWopxGLelZu+64ewEU0W2u/XKWPSgjL5f5jv17vohwpCM3SCtpfe re1Y7raNs3XeHOj4nmbKniwv8t89K9S2RmRpDvS9w/5FHrsOe9cZM4evRmDJrLvQPwTdwDBDFZaB d4yeql6bLdqj6imNzWSwTjuYSx03T7OxDQ7SzRr/Cdkn6hWOS4PQjywzkmOOPoIWeniqAbV9Xusf AAAA//8DAFBLAwQUAAYACAAAACEA9A73B2EBAAB8AwAAEgAAAHBwdC90YWdzL3RhZzEzLnhtbIyT 226CMACG75fsHUjvFTXLtqhoCAdHgkJovdhlgxVIoG3a6ra3X1VYIofFhBvo//2HNCzX31VpnImQ BaMWmI4nwCA0ZYeCZhbYI3/0DgypMD3gklFigR8iwXr1/LTkc4WzUCpDG1A5xxbIleJz05RpTios x4wTqs+OTFRY6VeRmQeBv7RxVZqzyeTVrHBBQc2LR3h2PBYpcVl6qghVNxNBSqx0eZkXXDZu/BE3 LojUNlf6rtLqNs6guNKL/WiHgHHGpQVQoUriEpn6jCpgdnXQQ05oQ7izt17NXKSQqGlb7kRhlMBa NJot/p67EIeVTOiv/XQ37arvi4NOEsTNjs6pH3ih25RxbeQt2optGAzB8MOOPd1lk0T7uF0I5pgT XWgj2Il3ZjRom0IBCr2hzb05zfBrTlhk+dD99NL1Jf1Tsk24WJFhYZxEyHNQoCM/4wZ5ebsAZvPj rH4BAAD//wMAUEsDBBQABgAIAAAAIQDqxLh3WQEAAE4DAAASAAAAcHB0L3RhZ3MvdGFnMTQueG1s jJNRb4IwFIXfl+w/kL4r6MOyuKExDJ0JCpH6sMcGrtCktE1bnfv3KwpbprCY8AC95zv33N7wOjtV zDmC0lRwH42GHnKAZyKnvPDRDi8Gz8jRhvCcMMHBR1+g0Wz6+PAqJ4YUkTaONeB6QnxUGiMnrquz Eiqih0ICt7W9UBUx9lMVbq7IpzWumDv2vCe3IpSjhlf38GK/pxm8iexQATcXEwWMGBtel1Tq1k3e 4yYVaGtzpv9Eml6Gczip7MSLeIORcyTMR5gaBimjOZzfFoIb5N6q0xAH0TxNN/N12JC1NAUzupYH cRRvO/SBYEJ1Aeto1UhuSun7PAmt13Ib75Jrw7QkEqzhUomDHPeh1xRe4Sjsy9zZpw1+7hPRouy7 oU66uaZ/Qt4krBcR89/N9FPJNsZhgFe2/0fS8l73dE11MH75eS57h5OpQ57HtKc17ba/wvQbAAD/ /wMAUEsDBBQABgAIAAAAIQALUoXe7AAAAJABAAASAAAAcHB0L3RhZ3MvdGFnMTUueG1sjJDNasMw DIDvg72D8b112sMYWZNSuvaUrbBkDyASJTHYsrG1rnv7ef0ZFHoo6KKf70PSYnmwRuwxRO2okLNp JgVS6zpNQyE/m+3kWYrIQB0YR1jIH4xyWT4+LHzOMFSRRRJQzKGQI7PPlYrtiBbi1Hmk1OtdsMAp DYPqAnwnsTVqnmVPyoImeebDPbzre93iq2u/LBKfJAENcFo+jtrHi83fY/MBY9Ic6auVytNxgsCm i9e7avdRb5p1tarr99XbRoo9mFR3xoUaeSbVLeA8NZm//EdtdIcNHnjriI94qv7R6vLM8hcAAP// AwBQSwMEFAAGAAgAAAAhAPygfnBZAQAASgMAABEAAABwcHQvdGFncy90YWc0LnhtbIyTW2+CMBiG 75fsP5Dea9Uly+JEYxg4ExQieLHLDj6BhB7SVrf9+1UOOygkJtxA3+fp97ZhtvikpXUCqQrObDQe jpAFLOFpwTIb7WNv8IQspQlLSckZ2OgLFFrM7+9mYqpJ5ittGQFTU2KjXGsxxVglOVCihlwAM2sH LinR5lVmOJXkw4hpiSej0SOmpGCo4eUtPD8cigReeHKkwHQtkVASbYZXeSFUaxO32IQEZTQV/W+k eV3OYoSaxl6wjZF1IqWNorJIISQZbI/0HaTHmUb4Oh25seMvo2i73LgNeY5GoMeXcSfwg11H3uEl l13Axl83kaul6HUZusa12gX78FIY5USAEa4kP4pJ3xidaDtLhfpFlveV7qSb5t37ViNXRLgLYteJ 18b0FrbsQ2/Hq3rnm+m3/0n+Xl/3ITSxweT556nkHue6vvLqPMz3M4/b32D+DQAA//8DAFBLAwQU AAYACAAAACEAxXooBuQAAACAAQAAEgAAAHBwdC90YWdzL3RhZzE5LnhtbIyQ20oDQQyG74W+w5D7 drYtiKzdLaXWq9WCWx8g7GYPMJMZJmPVt3e0LSJ4UQiBHP6PP1mtP6xRRwoyOi5gPstAETeuHbkv 4PXwOL0DJRG5ReOYCvgkgXU5uVn5PGJfSVQJwJJjAUOMPtdamoEsysx54jTrXLAYUxl63QZ8T2Br 9CLLbrXFkeGsD9foXdeNDT245s0SxxMkkMGYzMswernQ/DU0H0gS5kf9x1J5Ok4x2nTxdl/tX+rd YVtt6vp587QDdUST+s64UFOcg/5PcN6aLu5/Y5ny97a+PK/8AgAA//8DAFBLAwQUAAYACAAAACEA TNYMYlwBAABLAwAAEgAAAHBwdC90YWdzL3RhZzE4LnhtbIyTUW+CMBSF35fsP5C+K+jDsjjRGIbO BIVYfNhjA1doUtqmrc79+1UEkykkJrxAz3fuuadhOj9XzDmB0lRwH42GHnKAZyKnvPDRPl0O3pGj DeE5YYKDj35Bo/ns9WUqJ4YUkTaONeB6QnxUGiMnrquzEiqih0ICt2cHoSpi7Ksq3FyRH2tcMXfs eW9uRShHDa+e4cXhQDP4FNmxAm6uJgoYMTa8LqnUrZt8xk0q0Nampv9Fml2Xczip7MbLeJsi50SY jzCjOaTUMFgKbpD7KMRhGkQLjLeLTdhAFykGM7qXB3EU7zr0gWBCdQGbaN1IHo7w1yIJrddqF++T e0NcEgnWcKXEUY77YnSibZYajWhR9i3dSTebd8+tI98Tdbcxr3vuB5JdnIZBurajv5MW9fo6eZix TqMwsGxo77WzjEY4GH/cnuvNw9lcdqpbsV8vtNv+B7M/AAAA//8DAFBLAwQUAAYACAAAACEAN99M KYABAACjAwAAEgAAAHBwdC90YWdzL3RhZzE3LnhtbIyTXWvCMBiF7wf7DyH3sypjbGKV0qYaSD9o 44W7kaDRFtqkJNFt/35B2zGVgpch5znvOW/IdP5dV+DElS6lcOFoMISAi63cleLgwhUNX94h0IaJ Hauk4C784RrOZ89P02Zi2IFoA6yB0BPmwsKYZuI4elvwmumBbLiwd3upambsUR2cnWJf1riunPFw +ObUrBSw5dUjvNzvyy0P5PZYc2EuJopXzNjwuigb3bk1j7g1imtrc6avIs0u5YBgtW0ckc0IghOr XJguMXSub0OMSJAPcIwp9gj+REGrHd0q86WXohzRRZasUp94eR57EWrVecEannOzUPLYjPvQW4pi SpCfxBTF9JbxE5JkfeN8WUnVjSPloTB9eB95Vy+0MfrGhVKY/nJ0Tfr3Yn6qv73czYy89J82YvcK P1wMiLdOVrQVBXzPjtVd3Yjgvndr9wtS4vlomZAAZeBjc36Sc9o0SyjyKbayddplGd66ZFbixQuC wOtDrNP9r9kvAAAA//8DAFBLAwQUAAYACAAAACEARbBjz1ABAABFAwAAEQAAAHBwdC90YWdzL3Rh ZzMueG1sjJNdb4IwGIXvl+w/kN5r0YtlcaIxDJ0JCrF4scsGKjTpV9rqtn+/iuCi4mLCDbznOe85 bRhPvznzDkQbKkUABn0feETksqCiDMA2m/degWcsFgVmUpAA/BADppPnp7EaWVzGxnrOQJgRDkBl rRpBaPKKcGz6UhHhZjupObbuVZew0PjLGXMGh77/AjmmAjS8foSXux3NybvM95wIezLRhGHrwpuK KtO6qUfclCbG2dT0RaTJqZwnMHeN58k6A94BswAgRguSUcvIXAoL4K0QRVkYzxBaz1ZRAx2liNjB tTxM4mTToQ8lk7oLWMXLRnIzQh+zNHJei02yTa8NUYUVcYYLLfdqeA+9oY5d72Xu3NMGr/fEtKzu nVAn3RzTPyGvifoiEtEZ9A9IN0kWhdnSrf5MW9TvLtZMe8O383N55XVF9/mIw/YPmPwCAAD//wMA UEsDBBQABgAIAAAAIQAqEMRIagEAAIQDAAASAAAAcHB0L3RhZ3MvdGFnMTYueG1sjJNda8IwGIXv B/sPJfdalbENtYr0wxU6W0wc7DLU2AbaJCTRbf9+UduB/RhCbpqc57znNGS+/C4L60Skopw5YDwc AYuwlO8pyxywQ8HgFVhKY7bHBWfEAT9EgeXi8WEuphpnkdKWMWBqih2Qay2mtq3SnJRYDbkgzJwd uCyxNp8ys/cSfxnjsrAno9GzXWLKQMXLe3h+ONCUeDw9loTpq4kkBdYmvMqpULWbuMdNSKKMzYW+ ibS4lrMYLk3jIN4gYJ1w4QBEdUE8otKAMw3stg76yI1WEG5W737FnKWQ6HFT7sZRvIWVaDCZ/a2b IS4vuDS73XR72kXfNQ662zCpe7ROg9CPvDqMF36EMIw3s6bqPQr7DODbKvFNnvU23iXNUDDHgphQ a8mPolWlRpsUClHk9/XunFOXv8yJaJb33VEnXV3UPyGbhEdP9Pxu+sXJNka+i8zPRJ9JjT29nAG7 fkCLXwAAAP//AwBQSwMEFAAGAAgAAAAhADffTCmAAQAAowMAABIAAABwcHQvdGFncy90YWcyMi54 bWyMk11rwjAYhe8H+w8h97MqY2xildKmGkg/aOOFu5Gg0RbapCTRbf9+QdsxlYKXIec57zlvyHT+ XVfgxJUupXDhaDCEgIut3JXi4MIVDV/eIdCGiR2rpOAu/OEazmfPT9NmYtiBaAOsgdAT5sLCmGbi OHpb8JrpgWy4sHd7qWpm7FEdnJ1iX9a4rpzxcPjm1KwUsOXVI7zc78stD+T2WHNhLiaKV8zY8Loo G925NY+4NYpra3OmryLNLuWAYLVtHJHNCIITq1yYLjF0rm9DjEiQD3CMKfYI/kRBqx3dKvOll6Ic 0UWWrFKfeHkeexFq1XnBGp5zs1Dy2Iz70FuKYkqQn8QUxfSW8ROSZH3jfFlJ1Y0j5aEwfXgfeVcv tDH6xoVSmP5ydE3692J+qr+93M2MvPSfNmL3Cj9cDIi3Tla0FQV8z47VXd2I4L53a/cLUuL5aJmQ AGXgY3N+knPaNEso8im2snXaZRneumRW4sULgsDrQ6zT/a/ZLwAAAP//AwBQSwECLQAUAAYACAAA ACEAOl6HznMCAADNGQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt ABQABgAIAAAAIQBHvxrQEQEAAHUDAAALAAAAAAAAAAAAAAAAAKwEAABfcmVscy8ucmVsc1BLAQIt ABQABgAIAAAAIQA9AKfcHAEAAH0FAAAgAAAAAAAAAAAAAAAAAO4HAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBBaXni9wAAAFoDAAAgAAAAAAAAAAAAAAAA AEgJAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc1BLAQItABQABgAIAAAAIQBHPSyv 8AAAANYCAAAgAAAAAAAAAAAAAAAAAH0KAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwucmVs c1BLAQItABQABgAIAAAAIQCNTqq48AAAANYCAAAgAAAAAAAAAAAAAAAAAKsLAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlNC54bWwucmVsc1BLAQItABQABgAIAAAAIQDDHIy/SwEAABYHAAAfAAAAAAAA AAAAAAAAANkMAABwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh AN5Rq9WFAwAAnxEAABQAAAAAAAAAAAAAAAAAaQ8AAHBwdC9wcmVzZW50YXRpb24ueG1sUEsBAi0A FAAGAAgAAAAhABm7dBRcBQAAtBMAABUAAAAAAAAAAAAAAAAAIBMAAHBwdC9zbGlkZXMvc2xpZGUx LnhtbFBLAQItABQABgAIAAAAIQC+IItuVQgAANw2AAAVAAAAAAAAAAAAAAAAAK8YAABwcHQvc2xp ZGVzL3NsaWRlMy54bWxQSwECLQAUAAYACAAAACEAhFg20JIHAABoNgAAFQAAAAAAAAAAAAAAAAA3 IQAAcHB0L3NsaWRlcy9zbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAhAHlw6dmMBQAAFhQAABUAAAAA AAAAAAAAAAAA/CgAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbFBLAQItABQABgAIAAAAIQBv0a/+JgEA AI0GAAAsAAAAAAAAAAAAAAAAALsuAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVy MS54bWwucmVsc1BLAQItABQABgAIAAAAIQBKr3U50gAAAL8BAAAqAAAAAAAAAAAAAAAAACswAABw cHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA oFLbelQIAACVPAAAIQAAAAAAAAAAAAAAAABFMQAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3Rl cjEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAAAAAAAAAAAAAAAA2DkAAHBwdC9z bGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXR kvG8AAAANwEAACwAAAAAAAAAAAAAAAAA3joAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVM YXlvdXQzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGARFf3iAAAAwQIAACwAAAAAAAAAAAAAAAAA 5DsAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAFtpUOrOAgAAGAcAAB8AAAAAAAAAAAAAAAAAED0AAHBwdC9ub3Rlc1NsaWRlcy9ub3Rl c1NsaWRlMS54bWxQSwECLQAUAAYACAAAACEAMf5vRj0EAADjDgAAIQAAAAAAAAAAAAAAAAAbQAAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0AFAAGAAgAAAAhAFceeLvWAgAA oAgAACEAAAAAAAAAAAAAAAAAl0QAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbFBL AQItABQABgAIAAAAIQBKvPjSJgIAAF4EAAAhAAAAAAAAAAAAAAAAAKxHAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0My54bWxQSwECLQAUAAYACAAAACEAdvkk41sEAABdEwAAJQAAAAAAAAAA AAAAAAARSgAAcHB0L2hhbmRvdXRNYXN0ZXJzL2hhbmRvdXRNYXN0ZXIxLnhtbFBLAQItABQABgAI AAAAIQCjmPiTOAEAAO0CAAAcAAAAAAAAAAAAAAAAAK9OAABwcHQvdGhlbWUvdGhlbWVPdmVycmlk ZTMueG1sUEsBAi0AFAAGAAgAAAAhAPevJGkrAQAA3QIAABwAAAAAAAAAAAAAAAAAIVAAAHBwdC90 aGVtZS90aGVtZU92ZXJyaWRlMS54bWxQSwECLQAUAAYACAAAACEAjawnfGoGAACQJgAAIQAAAAAA AAAAAAAAAACGUQAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1sUEsBAi0AFAAGAAgA AAAhAKOY+JM4AQAA7QIAABwAAAAAAAAAAAAAAAAAL1gAAHBwdC90aGVtZS90aGVtZU92ZXJyaWRl Mi54bWxQSwECLQAKAAAAAAAAACEAnpwrrnAgAABwIAAAFwAAAAAAAAAAAAAAAAChWQAAZG9jUHJv cHMvdGh1bWJuYWlsLmpwZWdQSwECLQAUAAYACAAAACEAtM9YGbkAAAAkAQAALAAAAAAAAAAAAAAA AABGegAAcHB0L25vdGVzTWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHNQSwECLQAU AAYACAAAACEAcocjrcIFAAA2GwAAFAAAAAAAAAAAAAAAAABJewAAcHB0L3RoZW1lL3RoZW1lMi54 bWxQSwECLQAUAAYACAAAACEAo5j4kzgBAADtAgAAHAAAAAAAAAAAAAAAAAA9gQAAcHB0L3RoZW1l L3RoZW1lT3ZlcnJpZGU0LnhtbFBLAQItABQABgAIAAAAIQByhyOtwgUAADYbAAAUAAAAAAAAAAAA AAAAAK+CAABwcHQvdGhlbWUvdGhlbWUzLnhtbFBLAQItAAoAAAAAAAAAIQAOFekTlQMAAJUDAAAU AAAAAAAAAAAAAAAAAKOIAABwcHQvbWVkaWEvaW1hZ2UxLnBuZ1BLAQItABQABgAIAAAAIQCTqn2Y uQAAACQBAAAwAAAAAAAAAAAAAAAAAGqMAABwcHQvaGFuZG91dE1hc3RlcnMvX3JlbHMvaGFuZG91 dE1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAXvk85V0GAAD3HgAAFAAAAAAAAAAAAAAA AABxjQAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAIs2M3MIBAAD5BAAAEQAA AAAAAAAAAAAAAAAAlAAAcHB0L3ZpZXdQcm9wcy54bWxQSwECLQAUAAYACAAAACEAP4W4cSICAAAo CwAAEwAAAAAAAAAAAAAAAADxlQAAcHB0L3RhYmxlU3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQC2 PzQk7wEAAG0EAAARAAAAAAAAAAAAAAAAAESYAABwcHQvcHJlc1Byb3BzLnhtbFBLAQItABQABgAI AAAAIQB1dLiARQEAAOwCAAARAAAAAAAAAAAAAAAAAGKaAABwcHQvdGFncy90YWc1LnhtbFBLAQIt ABQABgAIAAAAIQBh4tD7kgEAAAIDAAARAAAAAAAAAAAAAAAAANabAABkb2NQcm9wcy9jb3JlLnht bFBLAQItABQABgAIAAAAIQBM1gxiXAEAAEsDAAASAAAAAAAAAAAAAAAAAJ+eAABwcHQvdGFncy90 YWcyMy54bWxQSwECLQAUAAYACAAAACEAj13p5lkBAABEBAAAEwAAAAAAAAAAAAAAAAAroAAAZG9j UHJvcHMvY3VzdG9tLnhtbFBLAQItABQABgAIAAAAIQArrlGXSQEAAAsDAAARAAAAAAAAAAAAAAAA AL2iAABwcHQvdGFncy90YWcyLnhtbFBLAQItABQABgAIAAAAIQB3kTKXiQIAAPQIAAARAAAAAAAA AAAAAAAAADWkAABwcHQvdGFncy90YWcxLnhtbFBLAQItABQABgAIAAAAIQBHlPXXYwIAAOsFAAAQ AAAAAAAAAAAAAAAAAO2mAABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhADffTCmAAQAA owMAABIAAAAAAAAAAAAAAAAAhqoAAHBwdC90YWdzL3RhZzIwLnhtbFBLAQItABQABgAIAAAAIQBM 1gxiXAEAAEsDAAASAAAAAAAAAAAAAAAAADasAABwcHQvdGFncy90YWcyMS54bWxQSwECLQAUAAYA CAAAACEAy/uB1mQBAACAAwAAEgAAAAAAAAAAAAAAAADCrQAAcHB0L3RhZ3MvdGFnMTIueG1sUEsB Ai0AFAAGAAgAAAAhAOkXt7eKAQAARQQAABIAAAAAAAAAAAAAAAAAVq8AAHBwdC90YWdzL3RhZzEx LnhtbFBLAQItABQABgAIAAAAIQDOyjcNWgEAAEsDAAASAAAAAAAAAAAAAAAAABCxAABwcHQvdGFn cy90YWcxMC54bWxQSwECLQAUAAYACAAAACEAy9JDhVcBAAA/AwAAEQAAAAAAAAAAAAAAAACasgAA cHB0L3RhZ3MvdGFnOS54bWxQSwECLQAUAAYACAAAACEAyPopv1YBAABDAwAAEQAAAAAAAAAAAAAA AAAgtAAAcHB0L3RhZ3MvdGFnOC54bWxQSwECLQAUAAYACAAAACEArAEhsFUBAAA6AwAAEQAAAAAA AAAAAAAAAACltQAAcHB0L3RhZ3MvdGFnNy54bWxQSwECLQAUAAYACAAAACEAWsxfyX0BAACiAwAA EQAAAAAAAAAAAAAAAAAptwAAcHB0L3RhZ3MvdGFnNi54bWxQSwECLQAUAAYACAAAACEA9A73B2EB AAB8AwAAEgAAAAAAAAAAAAAAAADVuAAAcHB0L3RhZ3MvdGFnMTMueG1sUEsBAi0AFAAGAAgAAAAh AOrEuHdZAQAATgMAABIAAAAAAAAAAAAAAAAAZroAAHBwdC90YWdzL3RhZzE0LnhtbFBLAQItABQA BgAIAAAAIQALUoXe7AAAAJABAAASAAAAAAAAAAAAAAAAAO+7AABwcHQvdGFncy90YWcxNS54bWxQ SwECLQAUAAYACAAAACEA/KB+cFkBAABKAwAAEQAAAAAAAAAAAAAAAAALvQAAcHB0L3RhZ3MvdGFn NC54bWxQSwECLQAUAAYACAAAACEAxXooBuQAAACAAQAAEgAAAAAAAAAAAAAAAACTvgAAcHB0L3Rh Z3MvdGFnMTkueG1sUEsBAi0AFAAGAAgAAAAhAEzWDGJcAQAASwMAABIAAAAAAAAAAAAAAAAAp78A AHBwdC90YWdzL3RhZzE4LnhtbFBLAQItABQABgAIAAAAIQA330wpgAEAAKMDAAASAAAAAAAAAAAA AAAAADPBAABwcHQvdGFncy90YWcxNy54bWxQSwECLQAUAAYACAAAACEARbBjz1ABAABFAwAAEQAA AAAAAAAAAAAAAADjwgAAcHB0L3RhZ3MvdGFnMy54bWxQSwECLQAUAAYACAAAACEAKhDESGoBAACE AwAAEgAAAAAAAAAAAAAAAABixAAAcHB0L3RhZ3MvdGFnMTYueG1sUEsBAi0AFAAGAAgAAAAhADff TCmAAQAAowMAABIAAAAAAAAAAAAAAAAA/MUAAHBwdC90YWdzL3RhZzIyLnhtbFBLBQYAAAAAQABA AJkRAACsxwAAAAA= --=_62d358336509f7d869ee69ff490453ce-- From cabo@tzi.org Fri Nov 8 12:28:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1E621F9D46 for ; Fri, 8 Nov 2013 12:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.304 X-Spam-Level: X-Spam-Status: No, score=-106.304 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecu12wOnR+fQ for ; Fri, 8 Nov 2013 12:28:01 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4211E81C1 for ; Fri, 8 Nov 2013 12:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA8KRusC020786 for ; Fri, 8 Nov 2013 21:27:56 +0100 (CET) Received: from dhcp-9cfc.meeting.ietf.org (dhcp-9cfc.meeting.ietf.org [31.133.156.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1531FB38; Fri, 8 Nov 2013 21:27:54 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Carsten Bormann In-Reply-To: Date: Fri, 8 Nov 2013 12:27:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: core X-Mailer: Apple Mail (2.1822) Subject: [core] Meeting summary CoRE IETF88 (part 2) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:28:07 -0000 > CoRE met for its first slot on Monday, 2013-11-04. > Work is proceeding on the standards-track draft-ietf-core-observe and > draft-ietf-core-block, as well as the informational > draft-ietf-core-groupcomm and draft-ietf-core-http-mapping, with > specific points raised to be handlded by the editors. We expect to > submit -observe to the IESG this month, with -block on its heels. > Work on draft-ietf-core-resource-directory is resuming, with some > charter updating required. The new proposal > draft-tcs-coap-no-response-option-04 received favorable reception and > further work required before adoption was identified, in particular > with respect to exploring the duality with -observe. The second meeting of CoRE on Thursday, 2013-11-07, mostly focused on the subject of authorization. Based on reports given from a number of ad-hoc meetings that started on Sunday, as well as some impromptu input, a set of five areas of desirable deliverables was identified. CoRE is currently chartered at most for one of those, so charter updates will be required (these can be combined with the outstanding update for resource-directory); details need to be worked out after the meeting, and work on understanding the technical approaches needs to continue. One area that may not fit into the CoRE WG is the authenticated multi-party transfer of authorization information; a home for this (most likely in the security area) may need to be found once it is better understood. We quickly looked at OMA (LWM2M) and ETSI plugtest activities based on CoAP, and continued the discussion on the format of the URIs to be used for alternative transports. We ran out of time before coming to sleepy nodes and the transfer of management information. Gr=FC=DFe, Carsten From prvs=017b77d3c=abhijan.bhattacharyya@tcs.com Fri Nov 8 13:01:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C4111E80E9 for ; Fri, 8 Nov 2013 13:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF3lDO8kOgK6 for ; Fri, 8 Nov 2013 13:01:10 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id E5DEB11E80DC for ; Fri, 8 Nov 2013 13:00:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,662,1378837800"; d="scan'208";a="469471073" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id B75D9DAC12; Sat, 9 Nov 2013 02:30:38 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 78283DAC02; Sat, 9 Nov 2013 02:30:38 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , From: Abhijan Bhattacharyya To: "Rahman Akbar" , "core@ietf.org WG" Message-ID: Date: Sat, 9 Nov 2013 02:30:32 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 11/09/2013 02:30:32, Serialize complete at 11/09/2013 02:30:33, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 11/09/2013 02:30:33, Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 11/09/2013 02:30:34, Serialize complete at 11/09/2013 02:30:34, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 11/09/2013 02:30:37, Serialize complete at 11/09/2013 02:30:37 Content-Type: multipart/alternative; boundary="=_alternative 007367F665257C1D_=" Subject: Re: [core] WG interest in Sleepy Node topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 21:01:14 -0000 --=_alternative 007367F665257C1D_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Akbar, Its a yes from my side in favour of supporting sleepy nodes in CoRE. One of the many reasons why we have started advocating for CoAP to our cust= omers, compared to any other competing technologies, is the assumption that= support for sleepy nodes is very much there in CoAP's road map. If we devi= ate then probably CoAP will lose an edge as there are competing solutions w= hich already incorporate support for sleepy-node-state-machine at the appli= cation layer. Another point I would like to make is: The probable intention behind confin= ing the sleep-management considerations within the Layer-2, etc. =A0is prob= ably to make the application more agnostic about the lower-part of the stac= k. In an ideal world we would like to do that. But when we are in the const= rained world of IoT/M2M (or whatever you call it) probably we cannot have t= hat much liberty. =A0=A0 The mirror server may not always be a practicable solution. We need other p= roposals. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: Rahman, Akbar Date: Fri, Nov 8, 2013 at 8:06 AM Subject: [core] WG interest in Sleepy Node topic To: Core Hi All, =A0 =A0 =A0 Once again we ran out of time on the agenda to discuss the WG interest on t= he topic of Sleepy Nodes =A0 http://www.ietf.org/id/draft-rahman-core-sleepy-nodes-do-we-need-00.txt =A0 =A0 However, Carsten did suggest that we carry the discussion that we would hav= e had in the meeting forward to the WG list.=A0 The key questions that we n= eed WG feedback on are: =A0 1.=A0=A0=A0=A0=A0=A0 Does the WG want to keep discussing Sleepy Nodes in CO= RE?=A0 The Sleepy Node support could be in: a.=A0=A0=A0=A0=A0=A0 CoAP Protocol b.=A0=A0=A0=A0=A0 CORE Link Format c.=A0=A0=A0=A0=A0=A0 CORE Resource Directory d.=A0=A0=A0=A0=A0 Etc. =A0 2.=A0=A0=A0=A0=A0=A0 Sub-Question: a.=A0=A0=A0=A0=A0=A0 Does the WG want to see some immediate development of = the Mirror Server concept (which seems to have near unanimous support and i= s well correlated to Sleepy Node support)? =A0 =A0 Any and all comments are appreciated!=A0 Please write back even if you answ= ered earlier Emails on this topic as we need to gauge WG interest. =A0 =A0 Thanks, =A0 =A0 Akbar _______________________________________________ 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 = 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 007367F665257C1D_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Akbar,
Its a yes from my side in favour of support= ing sleepy nodes in CoRE.
One of the many reasons why we have sta= rted advocating for CoAP to our customers, compared to any other competing = technologies, is the assumption that support for sleepy nodes is very much = there in CoAP's road map. If we deviate then probably CoAP will lose an edg= e as there are competing solutions which already incorporate support for sl= eepy-node-state-machine at the application layer.
Another point I= would like to make is: The probable intention behind confining the sleep-m= anagement considerations within the Layer-2, etc.  is probably to make= the application more agnostic about the lower-part of the stack. In an ide= al world we would like to do that. But when we are in the constrained world= of IoT/M2M (or whatever you call it) probably we cannot have that much lib= erty.   

The mirror server may not always be a practicable= solution. We need other proposals.

Regards
Abhijan Bhattacharyya=
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Ta= ta Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
______________________________= ______________
Experience certainty. IT Services
Business Solution= s
Consulting
____________________________________________

From: Rah= man, Akbar <Akbar.Rahman@interdigital.com>
Date: Fri, Nov 8, 2013 at 8:06 AM
Subject: [core] WG interest in Sleepy = Node topic
To: Core <core@ietf.org>


<= p class=3D"MsoNormal"> Hi All,

 

 

&= nbsp;

Once again we ran out of time on the= agenda to discuss the WG interest on the topic of Sleepy Nodes

 

http://www.ietf.org/id/draft-rahman-core-sleepy-nodes= -do-we-need-00.txt

 

 

However, Carsten did suggest that= we carry the discussion that we would have had in the meeting forward to t= he WG list.  The key questions that we need WG feedback on are:=

 

1.     =   Does the WG want to keep discussing Sleepy Node= s in CORE?  The Sleepy Node support could be in:

a.       CoAP Protocol

<= /u>b. &nb= sp;    CORE Link Format

c.       CORE Resource Directory

d.      Etc.

 

2.   &nbs= p;   Sub-Question:

a.       Does the WG want to see some immediate development of the Mirror Server co= ncept (which seems to have near unanimous support and is well correlated to= Sleepy Node support)?

 

 

Any and all comments are apprecia= ted!  Please write back even if you answered earlier Emails on this to= pic as we need to gauge WG interest.

 

 

Thanks,

 

 

Akbar


___= ____________________________________________
core mailing list
core@ietf.org
ht= tps://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
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 007367F665257C1D_=-- From cabo@tzi.org Fri Nov 8 17:26:04 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D53F21E808D for ; Fri, 8 Nov 2013 17:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCUdO8dwJUCp for ; Fri, 8 Nov 2013 17:25:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7A811E80E2 for ; Fri, 8 Nov 2013 17:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA91PrmM015741; Sat, 9 Nov 2013 02:25:53 +0100 (CET) Received: from [10.199.5.35] (209-82-80-116.dedicated.allstream.net [209.82.80.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 58388A99; Sat, 9 Nov 2013 02:25:50 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 8 Nov 2013 17:25:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Thomas Fossati X-Mailer: Apple Mail (2.1822) Cc: Core Subject: Re: [core] WG interest in Sleepy Node topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 01:26:04 -0000 On 08 Nov 2013, at 01:48, Thomas Fossati wrote: > out of CoRE scope At this stage of the discussion, I would be less concerned with the WG = scope than with finding out what the industry actually needs to be = standardized to foster interoperability. If there are items within this = set that are outside CoRE scope, we can always try to find a home for = them, either by rechartering or by finding another WG. But it is = important to have a clear understanding of the items that we think need = to be speced. At a level a bit more specific than we have been = discussing so far. Gr=FC=DFe, Carsten From esko.dijk@philips.com Mon Nov 11 01:30:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D358E21E812C for ; Mon, 11 Nov 2013 01:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.858 X-Spam-Level: X-Spam-Status: No, score=-2.858 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cr+KtFkX7ki for ; Mon, 11 Nov 2013 01:30:22 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7991611E8142 for ; Mon, 11 Nov 2013 01:22:12 -0800 (PST) Received: from mail121-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE009.bigfish.com (10.236.130.72) with Microsoft SMTP Server id 14.1.225.22; Mon, 11 Nov 2013 09:22:00 +0000 Received: from mail121-co9 (localhost [127.0.0.1]) by mail121-co9-R.bigfish.com (Postfix) with ESMTP id 059B4C80248; Mon, 11 Nov 2013 09:22:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz217bI98dI15d6O9371Ic89bh936eI542I1432I9251I4015I168aJ1521Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068h1954cbhz2dh109h2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1155h) Received: from mail121-co9 (localhost.localdomain [127.0.0.1]) by mail121-co9 (MessageSwitch) id 1384161718810480_13618; Mon, 11 Nov 2013 09:21:58 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.225]) by mail121-co9.bigfish.com (Postfix) with ESMTP id C06ED3C003E; Mon, 11 Nov 2013 09:21:58 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 11 Nov 2013 09:21:58 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.206]) by 011-DB3MMR1-011.MGDPHG.emi.philips.com ([10.128.28.50]) with mapi id 14.03.0158.002; Mon, 11 Nov 2013 09:21:56 +0000 From: "Dijk, Esko" To: Zach Shelby , "core@ietf.org" Thread-Topic: Sleepy devices: OMA lightweight queue mode for CoAP Thread-Index: Ac7eupK1vkBEFzF3SDuPgMOcHEH12w== Date: Mon, 11 Nov 2013 09:21:55 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC2895D@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Subject: [core] Sleepy devices: OMA lightweight queue mode for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 09:30:27 -0000 SGVsbG8gWmFjaCwgYWxsLA0KDQo+IEluIHRoZSBPTUEgTGlnaHR3ZWlnaHQgc3RhbmRhcmQsIHRo ZSBtZWNoYW5pc20gdGhhdCB1c2VzIENvQVAgdG8gc29sdmUgdGhpcyBwcm9ibGVtIHdhcyBqdXN0 IGNhbGxlZCBhICJxdWV1ZSBtb2RlIi4gVGhpcyBpcyBpbiBwcmFjdGljZSByZWFsaXNlZCB3aXRo IGEgUHJveHkgYW5kDQo+IGFuIFJEIGluIHRoZSBzYW1lIGJveC4gQW4gUkQgcmVnaXN0cmF0aW9u IHBhcmFtZXRlciBpcyB1c2VkIHRvIGluZGljYXRlIHRoYXQgYSBub2RlIGlzIGluIHF1ZXVlIG1v ZGUuIEZyb20gdGhlcmUgb24gdGhlIHByb3h5IHF1ZXVlcyBhbGwgaW5jb21pbmcgcmVxdWVzdHMg dG8gdGhlDQo+IG5vZGUsIHdoaWNoIGFyZSByZWxlYXNlZCB1cG9uIHJlY2VwdGlvbiBvZiBhIHJl Z2lzdHJhdGlvbiB1cGRhdGUgcmVxdWVzdCBmcm9tIHRoZSBub2RlLiBJZiB0aGUgV0cgd2FudHMs IHRoaXMgY291bGQgZmFpcmx5IGVhc2lseSBiZSBkb2N1bWVudGVkIGluIHRoZSBSZXNvdXJjZQ0K PiBEaXJlY3RvcnkgZHJhZnQgbWFpbnRhaW5pbmcgY29tcGF0aWJpbGl0eSB3aXRoIE9NQSBMaWdo dHdlaWdodC4NCg0KSW4gdGhpcyBzb2x1dGlvbiwgZG9lcyB0aGUgUHJveHkgcXVldWUgYSBDb0FQ IHJlcXVlc3QgZm9yIGFuIGFyYml0cmFyeSB0aW1lIHBlcmlvZD8gSSBhc3N1bWUgaXQgd29ya3Mg YXMgZm9sbG93cw0KDQoxLSB0aGUgQ29BUCBjbGllbnQgdGhhdCBuZWVkcyB0byByZWFjaCB0aGUg c2xlZXB5L2ludGVybWl0dGVudC1jb25uZWN0aXZpdHkgZW5kcG9pbnQgKFNJQ0VQKSBzZW5kcyBh IENPTiByZXF1ZXN0IHRvIFByb3h5LCBjb250YWluaW5nIHRoZSBQcm94eS1Vcmkgb3IgUHJveHkt U2NoZW1lIG9wdGlvbg0KMi0gUHJveHkgQUNLcyB0aGUgQ09OIG1lc3NhZ2UgYW5kIHB1dHMgdGhl IHJlcXVlc3QgaW4gcXVldWUNCjMtIFNJQ0VQIHdha2VzIHVwLCB1cGRhdGVzIGl0cyByZWdpc3Ry YXRpb24gb24gUHJveHkNCjQtIFByb3h5IHNlbmRzIHF1ZXVlZCByZXF1ZXN0IChDT04pIHRvIFNJ Q0VQDQooLSBvcHRpb25hbDogaWYgcmVxdWVzdCBmYWlscyB0byBiZSBkZWxpdmVyZWQgdG8gU0lD RVAgaXQgaXMgcmUtcXVldWVkIGZvciBuZXh0IHRpbWU7IHRoZW4gbW92ZSBiYWNrIHRvIHN0ZXAg MykNCjUtIFByb3h5IHJlY2VpdmVzIENvQVAgcmVzcG9uc2UgZnJvbSBTSUNFUA0KNi0gUHJveHkg ZGVsaXZlcnMgcmVzcG9uc2UgdG8gdGhlIENvQVAgY2xpZW50ICh1c2luZyBDT04pDQoNCkZyb20g Y29yZS1jb2FwIEkgdW5kZXJzdGFuZCB0aGVyZSBpcyBubyBpbmhlcmVudCBsaW1pdCB0byB0aGUg dGltZSBiZXR3ZWVuIGEgQ29BUCByZXF1ZXN0IGFuZCBpdHMgcmVzcG9uc2UuIEUuZy4gaXQgbWF5 IGJlIDI0IGhvdXJzIGluIGFib3ZlIGV4YW1wbGUuDQpJIHdvbmRlciBpZiBjdXJyZW50IGltcGxl bWVudGF0aW9ucyBvZiBjb3JlLWNvYXAgYWxsb3cgdGhpcywgb3IgYXJlIHRlc3RlZCBvbiB0aGlz IGFzcGVjdC4NCg0KT25lIGJlbmVmaXQgb2YgdGhpcyBzb2x1dGlvbiAoaWYgSSBzZWUgaXQgcmln aHQpIGlzIHRoYXQgdGhlcmUgaXMgbm8gcmVzb3VyY2UgZGVsZWdhdGlvbi9idWZmZXJpbmcgbmVl ZGVkIGF0IGFsbC4gQSBkcmF3YmFjayBpcyB0aGF0IHRoZSBTSUNFUCBuZWVkcyB0byBhY3RzIGFz IENvQVAgc2VydmVyIGFzIHdlbGwgYXMgQ29BUCBjbGllbnQsIHdoaWxlIHNvbWUgb3RoZXIgc29s dXRpb25zIHJlcXVpcmUgb25seSBDb0FQLWNsaWVudCBmdW5jdGlvbmFsaXR5IGluIHRoZSBTSUNF UC4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg WmFjaCBTaGVsYnkNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxNCwgMjAxMyAxODoxNA0KVG86IFJh aG1hbiwgQWtiYXINCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3JkcmFmdC1yYWhtYW4tY29yZS1zbGVlcHktbm9kZXMtZG8t d2UtbmVlZC0wMC50eHQNCg0KSGksDQoNCkkgdGhpbmsgIlNsZWVweSBOb2RlcyIgcmVhbGx5IG1p c3NlcyB0aGUgYnJvYWRlciBwb2ludC4gV2hhdCB3ZSBhcmUgcmVhbGx5IGRlYWxpbmcgd2l0aCBp cyBhIG5vZGUgd2l0aCBpbnRlcm1pdHRlbnQgcmVhY2hhYmlsaXR5LCAiSSdsbCBjYWxsIHlvdSwg ZG9uJ3QgY2FsbCBtZSIuIFNsZWVwaW5nIG1pZ2h0IGp1c3QgYmUgb25lIHJlYXNvbiB3aHkgdGhp cyBoYXBwZW5zLCBhIE5BVCBpcyBhbm90aGVyIGV2ZW4gbW9yZSBjb21tb24gb25lLiBBbmQgb24g Y2VsbHVsYXIgbmV0d29ya3Mgbm9kZXMgdHlwaWNhbGx5IGNvbWUgb24gdGhlIG5ldHdvcmsganVz dCBsb25nIGVub3VnaCB0byBnZXQgdGhlaXIgYnVzaW5lc3MgZG9uZS4NCg0KSW4gdGhlIE9NQSBM aWdodHdlaWdodCBzdGFuZGFyZCwgdGhlIG1lY2hhbmlzbSB0aGF0IHVzZXMgQ29BUCB0byBzb2x2 ZSB0aGlzIHByb2JsZW0gd2FzIGp1c3QgY2FsbGVkIGEgInF1ZXVlIG1vZGUiLiBUaGlzIGlzIGlu IHByYWN0aWNlIHJlYWxpc2VkIHdpdGggYSBQcm94eSBhbmQgYW4gUkQgaW4gdGhlIHNhbWUgYm94 LiBBbiBSRCByZWdpc3RyYXRpb24gcGFyYW1ldGVyIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCBh IG5vZGUgaXMgaW4gcXVldWUgbW9kZS4gRnJvbSB0aGVyZSBvbiB0aGUgcHJveHkgcXVldWVzIGFs bCBpbmNvbWluZyByZXF1ZXN0cyB0byB0aGUgbm9kZSwgd2hpY2ggYXJlIHJlbGVhc2VkIHVwb24g cmVjZXB0aW9uIG9mIGEgcmVnaXN0cmF0aW9uIHVwZGF0ZSByZXF1ZXN0IGZyb20gdGhlIG5vZGUu IElmIHRoZSBXRyB3YW50cywgdGhpcyBjb3VsZCBmYWlybHkgZWFzaWx5IGJlIGRvY3VtZW50ZWQg aW4gdGhlIFJlc291cmNlIERpcmVjdG9yeSBkcmFmdCBtYWludGFpbmluZyBjb21wYXRpYmlsaXR5 IHdpdGggT01BIExpZ2h0d2VpZ2h0Lg0KDQpBbHRob3VnaCBNaXJyb3IgU2VydmVyIGlzIGEgdXNl ZnVsIHBhcmFkaWdtIGZvciBzb21lIHVzZSBjYXNlcyAoYW5kIHdlIHNob3VsZCBldmVudHVhbGx5 IGRvY3VtZW50IGl0KSwgSSBmaW5kIGl0IGxlc3MgdXNlZnVsIGFzIGl0IGxpbWl0cyB0aGUgUkVT VCBvcGVyYXRpb25zIHRoYXQgY2FuIGJlIHBlcmZvcm1lZC4NCg0KWmFjaA0KDQpPbiBPY3QgMTEs IDIwMTMsIGF0IDk6MzggUE0sICJSYWhtYW4sIEFrYmFyIiA8QWtiYXIuUmFobWFuQEludGVyRGln aXRhbC5jb20+IHdyb3RlOg0KDQo+IFRoYW5rcywgR2VuZ3l1LCBmb3IgeW91ciBzdXBwb3J0IGZv ciB0aGUgdG9waWMgb2YgU2xlZXB5IE5vZGVzLg0KPg0KPiBJIGFncmVlIHRoYXQgd2UgY2FuIGhh dmUgZGlmZmVyZW50IGRlZmluaXRpb25zIG9mIHdoYXQgd2UgbWVhbiBmcm9tIGEgQ09SRSBwZXJz cGVjdGl2ZSBmb3IgYSBTbGVlcHkgTm9kZS4gIEF0IHRoaXMgcG9pbnQgKHVudGlsIHdlIGFkb3B0 IGEgV0cgZGVsaXZlcmFibGUgZm9yIHRoaXMgdG9waWMpIG9uZSBkZWZpbml0aW9uIGlzIGp1c3Qg YXMgdmFsaWQgYXMgYW5vdGhlci4gIEhvd2V2ZXIsIGl0IGlzIGFsc28gaW50ZXJlc3RpbmcgdG8g c2VlIHdoYXQgb3RoZXIgV0dzIGFyZSBkb2luZy4gIFNvIGZvciBleGFtcGxlLCBpbiBST0xMLCB0 aGUgZGVmaW5pdGlvbiBpczoNCj4NCj4NCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1yb2xsLXRlcm1pbm9sb2d5LTEzDQo+DQo+DQo+ICAgU2xlZXB5IE5vZGU6IEEgc2xl ZXB5IG5vZGUgaXMgYSBub2RlIHRoYXQgbWF5IHNvbWV0aW1lcyBnbyBpbnRvIGENCj4gICBzbGVl cCBtb2RlIChpLmUuICBnbyBpbnRvIGEgbG93IHBvd2VyIHN0YXRlIHRvIGNvbnNlcnZlIHBvd2Vy KSBhbmQNCj4gICB0ZW1wb3JhcmlseSBzdXNwZW5kIHByb3RvY29sIGNvbW11bmljYXRpb24uICBX aGVuIG5vIGluIGEgc2xlZXAgbW9kZSwNCj4gICB0aGUgc2xlZXB5IG5vZGUgaXMgaW4gYSBmdWxs eSBwb3dlcmVkIG9uIHN0YXRlIHdoZXJlIGl0IGhhcyB0aGUNCj4gICBjYXBhYmlsaXR5IHRvIHBl cmZvcm0gY29tbXVuaWNhdGlvbi4NCj4NCj4NCj4gQW5kIHRoaXMgUk9MTCBkZWZpbml0aW9uLCBh dCBsZWFzdCwgaXMgc2ltaWxhciB0byB0aGUgb25lIGZyb20NCj4gZHJhZnQtZGlqay1jb3JlLXNs ZWVweS1yZXFzLTAwDQo+DQo+DQo+DQo+IEJlc3QgUmVnYXJkcywNCj4NCj4NCj4gQWtiYXINCj4N Cj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogd2VpZ2VuZ3l1IFtt YWlsdG86d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuXQ0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTEs IDIwMTMgMjoyNyBBTQ0KPiBUbzogUmFobWFuLCBBa2Jhcg0KPiBDYzogY29yZUBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW2NvcmVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24NCj4gZm9y ZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LW5vZGVzLWRvLXdlLW5lZWQtMDAudHh0DQo+DQo+IEhp LCBSYWhtYW4sDQo+DQo+IE15IGFuc3dlciB0aGUgcXVlc3Rpb24gIlNob3VsZCB3ZSBoYXZlIGEg Q09SRSBkZWxpdmVyYWJsZSBmb3IgQ29BUCBzdXBwb3J0IG9mIFNsZWVweSBOb2Rlcz8iIGlzIFlF Uy4NCj4NCj4gQnV0IEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNlIGNhc2VzLg0K PiBBY2NvcmRpbmcgdG8gIlNsZWVweSBEZXZpY2VzIHVzaW5nIENvQVAgLSBSZXF1aXJlbWVudHMg ZHJhZnQtZGlqay1jb3JlLXNsZWVweS1yZXFzLTAwIg0KPiB0aGUgZGVmaW5pdGluIG9mIFNsZWVw aW5nL0FzbGVlcCBhcyBmb2xsb3dpbmc6DQo+ICAgU2xlZXBpbmcvQXNsZWVwICA6IEEgU0VQIGJl aW5nIGluIGEgInNsZWVwaW5nIHN0YXRlIiBpLmUuIGl0cyBuZXR3b3JrIGludGVyZmFjZSBpcyBk aXNjb25uZWN0ZWQgYW5kIGEgU0VQIGlzIG5vdCBhYmxlIHRvIHNlbmQgb3IgcmVjZWl2ZSBtZXNz YWdlcy4NCj4gU28sIGEgc2xlZXB5IG5vZGUgc2hvdWxkIG5vdCBzdGFydCB0byBjb21tdW5pY2F0 ZSB3aXRoIG90aGVyIG5vZGVzLiAgVGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBzbGVlcHkgbm9k ZXMgaXMgbm90IHBvc3NpYmxlLCB0aGF0IGlzIGdpdmVuIGluICJQcm9ibGVtIHN0YXRlbWVudCBh bmQgVXNlIGNhc2VzIG9mIFNsZWVweSBub2RlIGluIENvbnN0cmFpbmVkIG5vZGUgbmV0d29ya3Mg ZHJhZnQtaG9uZy1sd2lnLXNsZWVweW5vZGUtcHJvYmxlbS1zdGF0ZW1lbnQtMDAiDQo+DQo+IFdo ZW4gYSBub2RlIGlzIGluIHNsZWVwaW5nIHN0YXRlLCBpdCBjYW4gcmVjZWl2ZSwgYnV0IGl0IGNh bm5vdCBzZW5kLg0KPiBUaGUgc2xlZXBpbmcgbm9kZSBjYW4gYmUgd2FrZW4tdXAgYnkgYSByZWNl aXZlZCBtZXNzYWdlIG9yIHRpbWVyIGV4cGlyZWQgZXZlbnQ7IHRoZXJlZm9yZSB0aGUgbm9kZSB0 dXJucyB0byBiZSBhd2FrZS4NCj4gQW4gYWxhcm1pbmcgbWVzc2FnZSBtYXkgY2F1c2UgdGhlIHNs ZWVweSBub2RlIGF3YWtlIGFuZCB0aGVuIHRvIGdpdmUgcmVzcG9uc2UuDQo+IFRoZSB0aW1lciBl eHBpcmVkIGV2ZW50IG1heSBjYXVzZSAgdGhlIHNsZWVweSBub2RlIGF3YWtlIGFuZCB0aGVuIHRv IHNlbmQgaGVhcnRiZWF0Lg0KPiBBIG5vZGUgY2FuIHNlbmQgYSBtZXNzYWdlIG91dCBvbmx5IHdo ZW4gaXQgaXMgYXdha2UuDQo+DQo+IEFmdGVyYWxsLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBu b24tc2xlZXAgbm9kZSAgaW5pdGlhdGVzIGNvbW11bmljYXRpb24gd2l0aCBhIHNsZWVweSBub2Rl LiBUaGUgc2xlZXAgbm9kZSBpcyBwYXNzaXZlLg0KPiBJZiB0aGUgbm9kZSBpbiBzbGVlcHkgc3Rh dGUgd2FudHMgdG8gcmVzcG9uZCB0aGUgbWVzc2FnZSwgaXQgZmlyc3RseSB0dXJucyB0byBhd2Fr ZSBzdGF0ZS4NCj4NCj4gcmVnYXJkcywNCj4NCj4gR2VuZ3l1DQo+DQo+DQo+IC0tLS0t5Y6f5aeL 6YKu5Lu2LS0tLS0NCj4gRnJvbTogUmFobWFuLCBBa2Jhcg0KPiBTZW50OiBGcmlkYXksIE9jdG9i ZXIgMTEsIDIwMTMgMTE6MzkgQU0NCj4gVG86IENhcnN0ZW4gQm9ybWFubiA7IGNvcmVAaWV0Zi5v cmcNCj4gU3ViamVjdDogW2NvcmVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24NCj4gZm9y ZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LW5vZGVzLWRvLXdlLW5lZWQtMDAudHh0DQo+DQo+IEhp IENhcnN0ZW4gKGFuZCBXRyksDQo+DQo+DQo+IEkgd3JvdGUgYSBzaG9ydCBkcmFmdCBiYXNlZCBv biB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uIGZyb20gSUVURi04NyAoQmVybGluKToNCj4NCj4gIlNo b3VsZCB3ZSBoYXZlIGEgQ09SRSBkZWxpdmVyYWJsZSBmb3IgQ29BUCBzdXBwb3J0IG9mIFNsZWVw eSBOb2Rlcz8iDQo+DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jb3Jl L2N1cnJlbnQvbXNnMDQ3NTAuaHRtbA0KPg0KPg0KPg0KPiBBbnkgYW5kIGFsbCBjb21tZW50cyB3 aWxsIGJlIG11Y2ggYXBwcmVjaWF0ZWQuDQo+DQo+DQo+DQo+IEFrYmFyDQo+DQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIg MTAsIDIwMTMgMTE6MzQgUE0NCj4gVG86IFJhaG1hbiwgQWtiYXI7IFJhaG1hbiwgQWtiYXINCj4g U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uDQo+IGZvcmRyYWZ0LXJhaG1hbi1jb3Jl LXNsZWVweS1ub2Rlcy1kby13ZS1uZWVkLTAwLnR4dA0KPg0KPg0KPiBBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LW5vZGVzLWRvLXdlLW5lZWQtMDAudHh0DQo+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWtiYXIgUmFobWFuIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9yeS4NCj4NCj4gRmlsZW5hbWU6IGRyYWZ0LXJhaG1h bi1jb3JlLXNsZWVweS1ub2Rlcy1kby13ZS1uZWVkDQo+IFJldmlzaW9uOiAwMA0KPiBUaXRsZTog U2xlZXB5IERldmljZXM6IERvIHdlIG5lZWQgdG8gU3VwcG9ydCB0aGVtIGluIENPUkU/DQo+IENy ZWF0aW9uIGRhdGU6IDIwMTMtMTAtMTENCj4gR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0K PiBOdW1iZXIgb2YgcGFnZXM6IDYNCj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1yYWhtYW4tY29yZS1zbGVlcHktbm9kZXMtZG8tDQo+IHdlLW5lZWQt MDAudHh0DQo+IFN0YXR1czoNCj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1yYWhtYW4tY29yZS1zbGVlcHktbm9kZXMtZG8td2Utbg0KPiBlZWQNCj4gSHRtbGl6ZWQ6DQo+ IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhaG1hbi1jb3JlLXNsZWVweS1ub2Rl cy1kby13ZS1uZWVkLTANCj4gMA0KPg0KPg0KPiBBYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50 IHN1bW1hcml6ZXMgdGhlIGRpc2N1c3Npb24gaW4gdGhlIENPUkUgV0cgcmVsYXRlZCB0byB0aGUN Cj4gICBxdWVzdGlvbiBvZiB3aGV0aGVyIHN1cHBvcnQgb2Ygc2xlZXB5IGRldmljZXMgaXMgcmVx dWlyZWQgZm9yIHRoZQ0KPiAgIENvQVAgcHJvdG9jb2wsIENPUkUgTGluayBGb3JtYXQsIENPUkUg UmVzb3VyY2UgRGlyZWN0b3J5LCBldGMuICBUaGUNCj4gICBvbmx5IGdvYWwgb2YgdGhpcyBkb2N1 bWVudCBpcyB0byB0cmlnZ2VyIGRpc2N1c3Npb25zIGluIHRoZSBDT1JFIFdHDQo+ICAgc28gdGhh dCBhbGwgcmVsZXZhbnQgY29uc2lkZXJhdGlvbnMgZm9yIHNsZWVwaW5nIGRldmljZXMgYXJlIHRh a2VuDQo+ICAgaW50byBhY2NvdW50Lg0KPg0KPg0KPg0KPg0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQo+DQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBs aXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCi0tDQpaYWNoIFNoZWxieSwgQ2hp ZWYgTmVyZCwgU2Vuc2lub2RlIEx0ZC4NCmh0dHA6Ly93d3cuc2Vuc2lub2RlLmNvbSBAU2Vuc2lu b2RlSW9UDQpNb2JpbGU6ICszNTggNDAgNzc5NjI5Nw0KVHdpdHRlcjogQHphY2hfc2hlbGJ5DQpM aW5rZWRJbjogaHR0cDovL2ZpLmxpbmtlZGluLmNvbS9pbi96YWNoc2hlbGJ5DQo2TG9XUEFOIEJv b2s6IGh0dHA6Ly82bG93cGFuLm5ldA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIg YXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFk ZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9u LCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQg YW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95 IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From Akbar.Rahman@InterDigital.com Tue Nov 12 07:10:04 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0969F11E816D for ; Tue, 12 Nov 2013 07:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auC6VziOU15u for ; Tue, 12 Nov 2013 07:09:59 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7632411E8178 for ; Tue, 12 Nov 2013 07:09:46 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Nov 2013 10:10:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 12 Nov 2013 10:10:04 -0500 Message-ID: In-Reply-To: <756c6819fa1288ae074577e536999a8b@xs4all.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoMI draft Thread-Index: Ac7csukQxKtkn6zXTC6pOSQZD5O7cgDBX8yA References: <756c6819fa1288ae074577e536999a8b@xs4all.nl> From: "Rahman, Akbar" To: , "Core" X-OriginalArrivalTime: 12 Nov 2013 15:10:04.0983 (UTC) FILETIME=[44666C70:01CEDFB9] Subject: Re: [core] CoMI draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:10:04 -0000 SGkgUGV0ZXIgKyBCZXJ0LA0KDQoNClRoYW5rcyBmb3IgdGhlIGdvb2QgZHJhZnQuICBPbmUgcXVl c3Rpb24uICBJbiB5b3VyIHNsaWRlcywgaXQgc2FpZDoNCg0KDQo+IEludGVncmF0ZSBTTk1QICsg Q29BUCB0byByZWR1Y2UgY29kZSBjb21wbGV4aXR5IGFuZCBzdGFjayBzaXplDQoNCg0KRG8geW91 IHNlZSB0aGF0IHRoaXMgaW50ZWdyYXRpb24gYXMgYWJzb2x1dGVseSBuZWNlc3NhcnkuICBPciBj YW4gc29tZXRpbWVzIENvQVAgaXRzZWxmIChpLmUuIHdpdGhvdXQgU05NUCkgcHJvdmlkZSBhbiBh ZGVxdWF0ZSBpbnRlcmZhY2U/ICBBcyB5b3Uga25vdywgZm9yIGV4YW1wbGUsIHdlIHByb3ZpZGUg YW4gZXhhbXBsZSBvZiBhIENvQVAgbWV0aG9kIHRvIGNvbmZpZ3VyZSBFbmRwb2ludCBncm91cCBh ZGRyZXNzZXMgaW4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LWdyb3VwY29tbS0xNiNzZWN0aW9uLTIuNi4yDQoNCg0KSSBhbSBqdXN0IHRyeWluZyB0byB1bmRl cnN0YW5kIHRoZSBpbXBsaWNhdGlvbnMgb2YgIkludGVncmF0ZSBTTk1QICsgQ29BUCIuDQoNCg0K VGhhbmtzLA0KDQoNCkFrYmFyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIHBldGVyIHZhbiBkZXIgU3Rvaw0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAwOCwg MjAxMyAxOjQ0IFBNDQpUbzogQ29yZQ0KU3ViamVjdDogW2NvcmVdIENvTUkgZHJhZnQNCg0KPiBE ZWFyIENvUkUgd2csDQo+IA0KPiBVbmZvcnR1bmF0ZWx5IEkgd2FzIHVuYWJsZSB0byBwcmVzZW50 IG91ciBDb01JIGRyYWZ0IGR1cmluZyB0aGUgQ29SRSANCj4gd2cgbWVldGluZy4NCj4gQXR0YWNo ZWQgeW91IHdpbGwgZmluZCB0aGUgMyBzbGlkZXMgYW5kIHRoZSBkcmFmdC4NCj4gDQo+IFF1ZXN0 aW9uIHRvIHlvdTogV2UgcHJvcG9zZSA0IHBheWxvYWQgZm9ybWF0cyBhbmQgd2FudCB0byByZWR1 Y2UgdGhhdCANCj4gdG8gb25lLg0KPiBEbyB5b3UgaGF2ZSBhIHJlYXNvbmVkIHByZWZlcmVuY2Ug Zm9yIGVpdGhlciBDQk9SIG9yIEVYST8NCj4gDQo+IE91ciBwbGFucyBhcmUgdG8gbWFrZSBhIHZl cnNpb24tMDIgdGhhdCBpbmNvcnBvcmF0ZXMgdGhlIGV4Y2VsbGVudCANCj4gY29tbWVudHMgYnkg SnVlcmdlbiBTY2hvZW53YWxkZXIuDQo+IA0KPiBJbiB0aGUgbmV4dCB2ZXJzaW9uLTAzIHdlIHdh bnQgdG8gYWRkcmVzcyB0aGUgc2VjdXJpdHkgYXNwZWN0cyBhbmQgDQo+IGNvbXBhcmUgd2hhdCBD b0FQIGNhbiBkZWxpdmVyIHdpdGggdGhlIFNOTVB2MyBzZWN1cml0eSBwcm92aXNpb25pbmcuDQo+ IA0KPiBMb29raW5nIGZvcndhcmQgdG8geW91ciByZWFjdGlvbiwNCj4gDQo+IFBldGVyICsgQmVy dA0KPiANCj4gDQoNCg0KLS0NClBldGVyIHZhbiBkZXIgU3Rvaw0KdmFuZGVyc3RvayBjb25zdWx0 YW5jeQ0KbWFpbHRvOiBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZw0Kd3d3OiB3d3cudmFuZGVy c3Rvay5vcmcNCnRlbCBOTDogKzMxKDApNDkyNDc0NjczICAgICBGOiArMzMoMCk5NjYwMTUyNDgN Cg== From stokcons@xs4all.nl Tue Nov 12 07:23:28 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BBB21E811E for ; Tue, 12 Nov 2013 07:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3V60FMIHA0u for ; Tue, 12 Nov 2013 07:23:23 -0800 (PST) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0B411E80FA for ; Tue, 12 Nov 2013 07:23:23 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube3.xs4all.net [194.109.20.199]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id rACFNLju079540; Tue, 12 Nov 2013 16:23:21 +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, 12 Nov 2013 16:23:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Nov 2013 16:23:20 +0100 From: peter van der Stok To: "Rahman, Akbar" Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <756c6819fa1288ae074577e536999a8b@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (1b8AHQA/5vG1q1vU45iDfTE2hg8xl6C4) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Core Subject: Re: [core] CoMI draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2013 15:23:28 -0000 Hi Akbar thanks for the question. Actually I meant integrating the functionality of CoAP and SNMP, and use the CoAP protocol to attain this integration. Hope this is clearer. Peter Rahman, Akbar schreef op 2013-11-12 16:10: > Hi Peter + Bert, > > > Thanks for the good draft. One question. In your slides, it said: > > >> Integrate SNMP + CoAP to reduce code complexity and stack size > > > Do you see that this integration as absolutely necessary. Or can > sometimes CoAP itself (i.e. without SNMP) provide an adequate > interface? As you know, for example, we provide an example of a CoAP > method to configure Endpoint group addresses in > > http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.6.2 > > > I am just trying to understand the implications of "Integrate SNMP + > CoAP". > > > Thanks, > > > Akbar > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of peter van der Stok > Sent: Friday, November 08, 2013 1:44 PM > To: Core > Subject: [core] CoMI draft > >> Dear CoRE wg, >> >> Unfortunately I was unable to present our CoMI draft during the CoRE >> wg meeting. >> Attached you will find the 3 slides and the draft. >> >> Question to you: We propose 4 payload formats and want to reduce that >> to one. >> Do you have a reasoned preference for either CBOR or EXI? >> >> Our plans are to make a version-02 that incorporates the excellent >> comments by Juergen Schoenwalder. >> >> In the next version-03 we want to address the security aspects and >> compare what CoAP can deliver with the SNMPv3 security provisioning. >> >> Looking forward to your reaction, >> >> Peter + Bert >> >> > > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 From Akbar.Rahman@InterDigital.com Tue Nov 12 07:41:05 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF9E11E8270 for ; Tue, 12 Nov 2013 07:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPqAA36kGa1i for ; Tue, 12 Nov 2013 07:41:01 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1624711E8282 for ; Tue, 12 Nov 2013 07:39:02 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Nov 2013 10:39:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 12 Nov 2013 10:39:18 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoMI draft Thread-Index: Ac7fuzwPB8bsRcOMQAKoJkApR5efigAAfXhA References: <756c6819fa1288ae074577e536999a8b@xs4all.nl> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 12 Nov 2013 15:39:19.0606 (UTC) FILETIME=[5A3CA560:01CEDFBD] Cc: Core Subject: Re: [core] CoMI draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:41:05 -0000 U3RhdGVkIGFub3RoZXIgd2F5LCBkbyB5b3UgbWVhbiB1c2UgQ29BUCB0byByZWFkL3dyaXRlIE1J QnM/DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGV0ZXIgdmFuIGRl ciBTdG9rIFttYWlsdG86c3Rva2NvbnNAeHM0YWxsLm5sXSANClNlbnQ6IFR1ZXNkYXksIE5vdmVt YmVyIDEyLCAyMDEzIDEwOjIzIEFNDQpUbzogUmFobWFuLCBBa2Jhcg0KQ2M6IGNvbnN1bHRhbmN5 QHZhbmRlcnN0b2sub3JnOyBDb3JlDQpTdWJqZWN0OiBSRTogW2NvcmVdIENvTUkgZHJhZnQNCg0K DQpIaSBBa2Jhcg0KDQp0aGFua3MgZm9yIHRoZSBxdWVzdGlvbi4NCkFjdHVhbGx5IEkgbWVhbnQg aW50ZWdyYXRpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgQ29BUCBhbmQgU05NUCwgYW5kIHVzZSB0 aGUgQ29BUCBwcm90b2NvbCB0byBhdHRhaW4gdGhpcyBpbnRlZ3JhdGlvbi4NCg0KSG9wZSB0aGlz IGlzIGNsZWFyZXIuDQoNClBldGVyDQoNCg0KUmFobWFuLCBBa2JhciBzY2hyZWVmIG9wIDIwMTMt MTEtMTIgMTY6MTA6DQo+IEhpIFBldGVyICsgQmVydCwNCj4gDQo+IA0KPiBUaGFua3MgZm9yIHRo ZSBnb29kIGRyYWZ0LiAgT25lIHF1ZXN0aW9uLiAgSW4geW91ciBzbGlkZXMsIGl0IHNhaWQ6DQo+ IA0KPiANCj4+IEludGVncmF0ZSBTTk1QICsgQ29BUCB0byByZWR1Y2UgY29kZSBjb21wbGV4aXR5 IGFuZCBzdGFjayBzaXplDQo+IA0KPiANCj4gRG8geW91IHNlZSB0aGF0IHRoaXMgaW50ZWdyYXRp b24gYXMgYWJzb2x1dGVseSBuZWNlc3NhcnkuICBPciBjYW4gDQo+IHNvbWV0aW1lcyBDb0FQIGl0 c2VsZiAoaS5lLiB3aXRob3V0IFNOTVApIHByb3ZpZGUgYW4gYWRlcXVhdGUgDQo+IGludGVyZmFj ZT8gIEFzIHlvdSBrbm93LCBmb3IgZXhhbXBsZSwgd2UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIGEg Q29BUCANCj4gbWV0aG9kIHRvIGNvbmZpZ3VyZSBFbmRwb2ludCBncm91cCBhZGRyZXNzZXMgaW4N Cj4gDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1ncm91cGNv bW0tMTYjc2VjdGlvbi0yLjYuMg0KPiANCj4gDQo+IEkgYW0ganVzdCB0cnlpbmcgdG8gdW5kZXJz dGFuZCB0aGUgaW1wbGljYXRpb25zIG9mICJJbnRlZ3JhdGUgU05NUCArIA0KPiBDb0FQIi4NCj4g DQo+IA0KPiBUaGFua3MsDQo+IA0KPiANCj4gQWtiYXINCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3Jl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCj4gT2YgcGV0ZXIgdmFuIGRlciBTdG9rDQo+ IFNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMDgsIDIwMTMgMTo0NCBQTQ0KPiBUbzogQ29yZQ0KPiBT dWJqZWN0OiBbY29yZV0gQ29NSSBkcmFmdA0KPiANCj4+IERlYXIgQ29SRSB3ZywNCj4+IA0KPj4g VW5mb3J0dW5hdGVseSBJIHdhcyB1bmFibGUgdG8gcHJlc2VudCBvdXIgQ29NSSBkcmFmdCBkdXJp bmcgdGhlIENvUkUgDQo+PiB3ZyBtZWV0aW5nLg0KPj4gQXR0YWNoZWQgeW91IHdpbGwgZmluZCB0 aGUgMyBzbGlkZXMgYW5kIHRoZSBkcmFmdC4NCj4+IA0KPj4gUXVlc3Rpb24gdG8geW91OiBXZSBw cm9wb3NlIDQgcGF5bG9hZCBmb3JtYXRzIGFuZCB3YW50IHRvIHJlZHVjZSB0aGF0IA0KPj4gdG8g b25lLg0KPj4gRG8geW91IGhhdmUgYSByZWFzb25lZCBwcmVmZXJlbmNlIGZvciBlaXRoZXIgQ0JP UiBvciBFWEk/DQo+PiANCj4+IE91ciBwbGFucyBhcmUgdG8gbWFrZSBhIHZlcnNpb24tMDIgdGhh dCBpbmNvcnBvcmF0ZXMgdGhlIGV4Y2VsbGVudCANCj4+IGNvbW1lbnRzIGJ5IEp1ZXJnZW4gU2No b2Vud2FsZGVyLg0KPj4gDQo+PiBJbiB0aGUgbmV4dCB2ZXJzaW9uLTAzIHdlIHdhbnQgdG8gYWRk cmVzcyB0aGUgc2VjdXJpdHkgYXNwZWN0cyBhbmQgDQo+PiBjb21wYXJlIHdoYXQgQ29BUCBjYW4g ZGVsaXZlciB3aXRoIHRoZSBTTk1QdjMgc2VjdXJpdHkgcHJvdmlzaW9uaW5nLg0KPj4gDQo+PiBM b29raW5nIGZvcndhcmQgdG8geW91ciByZWFjdGlvbiwNCj4+IA0KPj4gUGV0ZXIgKyBCZXJ0DQo+ PiANCj4+IA0KPiANCj4gDQo+IC0tDQo+IFBldGVyIHZhbiBkZXIgU3Rvaw0KPiB2YW5kZXJzdG9r IGNvbnN1bHRhbmN5DQo+IG1haWx0bzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmcNCj4gd3d3 OiB3d3cudmFuZGVyc3Rvay5vcmcNCj4gdGVsIE5MOiArMzEoMCk0OTI0NzQ2NzMgICAgIEY6ICsz MygwKTk2NjAxNTI0OA0K From zach.shelby@arm.com Tue Nov 12 10:34:54 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795F011E8121 for ; Tue, 12 Nov 2013 10:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sb08WW5B8TT for ; Tue, 12 Nov 2013 10:34:50 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0B65611E810B for ; Tue, 12 Nov 2013 10:34:49 -0800 (PST) Received: from usa-sjc-gw2.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Tue, 12 Nov 2013 18:34:47 +0000 Received: from Spock.usa.Arm.com ([fe80::f144:5416:1a75:7083]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Tue, 12 Nov 2013 10:34:44 -0800 From: Zach Shelby To: "Rahman, Akbar" Date: Tue, 12 Nov 2013 10:34:35 -0800 Thread-Topic: [core] CoMI draft Thread-Index: Ac7f1drJqttH7VvGT5Gy+voXjfh/pg== Message-ID: <3F25B7AC-2891-47A4-803A-8361363B0A96@arm.com> References: <756c6819fa1288ae074577e536999a8b@xs4all.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 113111218344800202 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: Core Subject: Re: [core] CoMI draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:34:54 -0000 Akbar, I think the point of Peter's draft is to enable access to MiBs purely using= CoAP in a restful way. I think the CoMI draft is a good step in that direc= tion as it allows access to MiBs as they are written now. Of course in para= llel to that, if a device (like a border router or gateway e.g.) did suppor= t SNMP, the same MiBs could be accessible also via that. Zach On Nov 12, 2013, at 7:39 AM, "Rahman, Akbar" wrote: > Stated another way, do you mean use CoAP to read/write MIBs? > > > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Tuesday, November 12, 2013 10:23 AM > To: Rahman, Akbar > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] CoMI draft > > > Hi Akbar > > thanks for the question. > Actually I meant integrating the functionality of CoAP and SNMP, and use = the CoAP protocol to attain this integration. > > Hope this is clearer. > > Peter > > > Rahman, Akbar schreef op 2013-11-12 16:10: >> Hi Peter + Bert, >> >> >> Thanks for the good draft. One question. In your slides, it said: >> >> >>> Integrate SNMP + CoAP to reduce code complexity and stack size >> >> >> Do you see that this integration as absolutely necessary. Or can >> sometimes CoAP itself (i.e. without SNMP) provide an adequate >> interface? As you know, for example, we provide an example of a CoAP >> method to configure Endpoint group addresses in >> >> http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.6.2 >> >> >> I am just trying to understand the implications of "Integrate SNMP + >> CoAP". >> >> >> Thanks, >> >> >> Akbar >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf >> Of peter van der Stok >> Sent: Friday, November 08, 2013 1:44 PM >> To: Core >> Subject: [core] CoMI draft >> >>> Dear CoRE wg, >>> >>> Unfortunately I was unable to present our CoMI draft during the CoRE >>> wg meeting. >>> Attached you will find the 3 slides and the draft. >>> >>> Question to you: We propose 4 payload formats and want to reduce that >>> to one. >>> Do you have a reasoned preference for either CBOR or EXI? >>> >>> Our plans are to make a version-02 that incorporates the excellent >>> comments by Juergen Schoenwalder. >>> >>> In the next version-03 we want to address the security aspects and >>> compare what CoAP can deliver with the SNMPv3 security provisioning. >>> >>> Looking forward to your reaction, >>> >>> Peter + Bert >>> >>> >> >> >> -- >> Peter van der Stok >> vanderstok consultancy >> mailto: consultancy@vanderstok.org >> www: www.vanderstok.org >> tel NL: +31(0)492474673 F: +33(0)966015248 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 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 Akbar.Rahman@InterDigital.com Tue Nov 12 12:34:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C214F11E80E6 for ; Tue, 12 Nov 2013 12:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4XmV6lKCMhD for ; Tue, 12 Nov 2013 12:34:40 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id F176121F9FBC for ; Tue, 12 Nov 2013 12:34:39 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Nov 2013 15:34:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Nov 2013 15:34:56 -0500 Message-ID: In-Reply-To: <3F25B7AC-2891-47A4-803A-8361363B0A96@arm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoMI draft Thread-Index: Ac7f1drJqttH7VvGT5Gy+voXjfh/pgAEL1TQ References: <756c6819fa1288ae074577e536999a8b@xs4all.nl> <3F25B7AC-2891-47A4-803A-8361363B0A96@arm.com> From: "Rahman, Akbar" To: "Zach Shelby" X-OriginalArrivalTime: 12 Nov 2013 20:34:59.0437 (UTC) FILETIME=[A80009D0:01CEDFE6] Cc: Core Subject: Re: [core] CoMI draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:34:43 -0000 Thanks, Zach. Got it and +1. -----Original Message----- From: Zach Shelby [mailto:Zach.Shelby@arm.com]=20 Sent: Tuesday, November 12, 2013 1:35 PM To: Rahman, Akbar Cc: consultancy@vanderstok.org; Core Subject: Re: [core] CoMI draft Akbar, I think the point of Peter's draft is to enable access to MiBs purely using CoAP in a restful way. I think the CoMI draft is a good step in that direction as it allows access to MiBs as they are written now. Of course in parallel to that, if a device (like a border router or gateway e.g.) did support SNMP, the same MiBs could be accessible also via that. Zach On Nov 12, 2013, at 7:39 AM, "Rahman, Akbar" wrote: > Stated another way, do you mean use CoAP to read/write MIBs? > > > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Tuesday, November 12, 2013 10:23 AM > To: Rahman, Akbar > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] CoMI draft > > > Hi Akbar > > thanks for the question. > Actually I meant integrating the functionality of CoAP and SNMP, and use the CoAP protocol to attain this integration. > > Hope this is clearer. > > Peter > > > Rahman, Akbar schreef op 2013-11-12 16:10: >> Hi Peter + Bert, >> >> >> Thanks for the good draft. One question. In your slides, it said: >> >> >>> Integrate SNMP + CoAP to reduce code complexity and stack size >> >> >> Do you see that this integration as absolutely necessary. Or can=20 >> sometimes CoAP itself (i.e. without SNMP) provide an adequate=20 >> interface? As you know, for example, we provide an example of a CoAP >> method to configure Endpoint group addresses in >> >> http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.6.2 >> >> >> I am just trying to understand the implications of "Integrate SNMP +=20 >> CoAP". >> >> >> Thanks, >> >> >> Akbar >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf=20 >> Of peter van der Stok >> Sent: Friday, November 08, 2013 1:44 PM >> To: Core >> Subject: [core] CoMI draft >> >>> Dear CoRE wg, >>> >>> Unfortunately I was unable to present our CoMI draft during the CoRE >>> wg meeting. >>> Attached you will find the 3 slides and the draft. >>> >>> Question to you: We propose 4 payload formats and want to reduce=20 >>> that to one. >>> Do you have a reasoned preference for either CBOR or EXI? >>> >>> Our plans are to make a version-02 that incorporates the excellent=20 >>> comments by Juergen Schoenwalder. >>> >>> In the next version-03 we want to address the security aspects and=20 >>> compare what CoAP can deliver with the SNMPv3 security provisioning. >>> >>> Looking forward to your reaction, >>> >>> Peter + Bert >>> >>> >> >> >> -- >> Peter van der Stok >> vanderstok consultancy >> mailto: consultancy@vanderstok.org >> www: www.vanderstok.org >> tel NL: +31(0)492474673 F: +33(0)966015248 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- 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. 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 From trac+core@trac.tools.ietf.org Wed Nov 13 00:05:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F49F11E8114 for ; Wed, 13 Nov 2013 00:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbGoNBvfMGQm for ; Wed, 13 Nov 2013 00:05:27 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDE421F9E43 for ; Wed, 13 Nov 2013 00:05:26 -0800 (PST) Received: from localhost ([127.0.0.1]:33840 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VgVRr-0004dx-LV; Wed, 13 Nov 2013 09:05:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 13 Nov 2013 08:05:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/355 Message-ID: <060.178361dc4332d6174c594b7781e4603f@trac.tools.ietf.org> X-Trac-Ticket-ID: 355 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20131113080527.0CDE421F9E43@ietfa.amsl.com> Resent-Date: Wed, 13 Nov 2013 00:05:26 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #355: Clarify assumptions on reliable/unreliable multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 08:05:38 -0000 #355: Clarify assumptions on reliable/unreliable multicast Based on IETF88 discussion, we propose to add some text to describe that we assume an unreliable IP multicast mechanism. Also mention that ROLL MPL (Trickle) is a way to achieve higher reliability without requiring new mechanisms on the CoAP level. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From stokcons@xs4all.nl Wed Nov 13 01:15:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8DD21E80CD for ; Wed, 13 Nov 2013 01:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f70Z7cjT2zyA for ; Wed, 13 Nov 2013 01:15:16 -0800 (PST) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by ietfa.amsl.com (Postfix) with ESMTP id B845621F9F96 for ; Wed, 13 Nov 2013 01:15:13 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube11.xs4all.net [194.109.20.209]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id rAD9F6ge073604; Wed, 13 Nov 2013 10:15:07 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from ineo-y1c.hightechcampus.nl ([80.255.245.239]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 13 Nov 2013 10:15:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Nov 2013 10:15:06 +0100 From: peter van der Stok To: "Rahman, Akbar" Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <756c6819fa1288ae074577e536999a8b@xs4all.nl> <3F25B7AC-2891-47A4-803A-8361363B0A96@arm.com> Message-ID: X-Sender: stokcons@xs4all.nl (qKuNlxvRbTqWsrIQBbpcZ75KMQDNZkVW) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Core Subject: Re: [core] CoMI draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 13 Nov 2013 09:15:20 -0000 Let me confirm the correctness of Zach's description Peter Rahman, Akbar schreef op 2013-11-12 21:34: > Thanks, Zach. Got it and +1. > > > > -----Original Message----- > From: Zach Shelby [mailto:Zach.Shelby@arm.com] > Sent: Tuesday, November 12, 2013 1:35 PM > To: Rahman, Akbar > Cc: consultancy@vanderstok.org; Core > Subject: Re: [core] CoMI draft > > Akbar, > > I think the point of Peter's draft is to enable access to MiBs purely > using CoAP in a restful way. I think the CoMI draft is a good step in > that direction as it allows access to MiBs as they are written now. Of > course in parallel to that, if a device (like a border router or > gateway > e.g.) did support SNMP, the same MiBs could be accessible also via > that. > > Zach > > On Nov 12, 2013, at 7:39 AM, "Rahman, Akbar" > wrote: > >> Stated another way, do you mean use CoAP to read/write MIBs? >> >> >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Tuesday, November 12, 2013 10:23 AM >> To: Rahman, Akbar >> Cc: consultancy@vanderstok.org; Core >> Subject: RE: [core] CoMI draft >> >> >> Hi Akbar >> >> thanks for the question. >> Actually I meant integrating the functionality of CoAP and SNMP, and > use the CoAP protocol to attain this integration. >> >> Hope this is clearer. >> >> Peter >> >> >> Rahman, Akbar schreef op 2013-11-12 16:10: >>> Hi Peter + Bert, >>> >>> >>> Thanks for the good draft. One question. In your slides, it said: >>> >>> >>>> Integrate SNMP + CoAP to reduce code complexity and stack size >>> >>> >>> Do you see that this integration as absolutely necessary. Or can >>> sometimes CoAP itself (i.e. without SNMP) provide an adequate >>> interface? As you know, for example, we provide an example of a CoAP > >>> method to configure Endpoint group addresses in >>> >>> http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.6.2 >>> >>> >>> I am just trying to understand the implications of "Integrate SNMP + >>> CoAP". >>> >>> >>> Thanks, >>> >>> >>> Akbar >>> >>> >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf >>> Of peter van der Stok >>> Sent: Friday, November 08, 2013 1:44 PM >>> To: Core >>> Subject: [core] CoMI draft >>> >>>> Dear CoRE wg, >>>> >>>> Unfortunately I was unable to present our CoMI draft during the CoRE > >>>> wg meeting. >>>> Attached you will find the 3 slides and the draft. >>>> >>>> Question to you: We propose 4 payload formats and want to reduce >>>> that to one. >>>> Do you have a reasoned preference for either CBOR or EXI? >>>> >>>> Our plans are to make a version-02 that incorporates the excellent >>>> comments by Juergen Schoenwalder. >>>> >>>> In the next version-03 we want to address the security aspects and >>>> compare what CoAP can deliver with the SNMPv3 security provisioning. >>>> >>>> Looking forward to your reaction, >>>> >>>> Peter + Bert >>>> >>>> >>> >>> >>> -- >>> Peter van der Stok >>> vanderstok consultancy >>> mailto: consultancy@vanderstok.org >>> www: www.vanderstok.org >>> tel NL: +31(0)492474673 F: +33(0)966015248 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > Zach Shelby > Director of Technology > ARM Internet of Things BU > www.arm.com > mobile: +1 (408) 203-9434 > Skype: zdshelby > LinkedIn: fi.linkedin.com/in/zachshelby/ > > > -- 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. > > 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 From zach.shelby@arm.com Wed Nov 13 09:47:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9357521E8096 for ; Wed, 13 Nov 2013 09:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+C+m8OXVnei for ; Wed, 13 Nov 2013 09:47:47 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id DC78511E80EA for ; Wed, 13 Nov 2013 09:47:46 -0800 (PST) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Wed, 13 Nov 2013 17:47:44 +0000 Received: from Spock.usa.Arm.com ([fe80::f144:5416:1a75:7083]) by usa-sjc-gw1.usa.Arm.com ([::1]) with mapi; Wed, 13 Nov 2013 09:47:40 -0800 From: Zach Shelby To: "Dijk, Esko" Date: Wed, 13 Nov 2013 09:47:36 -0800 Thread-Topic: Sleepy devices: OMA lightweight queue mode for CoAP Thread-Index: Ac7gmHKXK7+FWjp6TgWG9EmjQcWG7A== Message-ID: <8AD83A72-6EE4-4C77-A084-BAD5C5C87989@arm.com> References: <031DD135F9160444ABBE3B0C36CED6180CC2895D@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC2895D@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 113111317474500902 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org" Subject: Re: [core] Sleepy devices: OMA lightweight queue mode for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 17:47:51 -0000 Esko, Only the what you might call the SICEP-PROXY interface is within scope of t= he OMA specification. How the client interacts with the proxy is out of sco= pe. In the device management space the proxy often times is the application= , in other cases it might be an HTTP reverse proxy. The only timings discussed in the OMA spec are the CoAP timeouts used to ti= me how long the SICEP can be assumed to be awake after sending a registrati= on update. I would prefer to document only the SICEP-PROXY interface, really that is t= he only part in scope of the resource directory specification anyways. Zach On Nov 11, 2013, at 1:21 AM, "Dijk, Esko" wrote: >> In the OMA Lightweight standard, the mechanism that uses CoAP to solve t= his problem was just called a "queue mode". This is in practice realised wi= th a Proxy and >> an RD in the same box. An RD registration parameter is used to indicate = that a node is in queue mode. From there on the proxy queues all incoming r= equests to the >> node, which are released upon reception of a registration update request= from the node. If the WG wants, this could fairly easily be documented in = the Resource >> Directory draft maintaining compatibility with OMA Lightweight. > > In this solution, does the Proxy queue a CoAP request for an arbitrary ti= me period? I assume it works as follows > > 1- the CoAP client that needs to reach the sleepy/intermittent-connectivi= ty endpoint (SICEP) sends a CON request to Proxy, containing the Proxy-Uri = or Proxy-Scheme option > 2- Proxy ACKs the CON message and puts the request in queue > 3- SICEP wakes up, updates its registration on Proxy > 4- Proxy sends queued request (CON) to SICEP > (- optional: if request fails to be delivered to SICEP it is re-queued fo= r next time; then move back to step 3) > 5- Proxy receives CoAP response from SICEP > 6- Proxy delivers response to the CoAP client (using CON) > > From core-coap I understand there is no inherent limit to the time betwee= n a CoAP request and its response. E.g. it may be 24 hours in above example= . > I wonder if current implementations of core-coap allow this, or are teste= d on this aspect. > > One benefit of this solution (if I see it right) is that there is no reso= urce delegation/buffering needed at all. A drawback is that the SICEP needs= to acts as CoAP server as well as CoAP client, while some other solutions = require only CoAP-client functionality in the SICEP. Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 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 weigengyu@bupt.edu.cn Wed Nov 13 20:46:47 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09B21E81A4 for ; Wed, 13 Nov 2013 20:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDLtqgFnST2f for ; Wed, 13 Nov 2013 20:46:41 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9F21E81A2 for ; Wed, 13 Nov 2013 20:46:36 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 72B5119F39C; Thu, 14 Nov 2013 12:46:30 +0800 (HKT) Message-ID: <7DBB3220CDD245D1BF9C230E3C0EACC6@WeiGengyuPC> From: "weigengyu" To: , , References: <060.178361dc4332d6174c594b7781e4603f@trac.tools.ietf.org> In-Reply-To: <060.178361dc4332d6174c594b7781e4603f@trac.tools.ietf.org> Date: Thu, 14 Nov 2013 12:46:30 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] #355: Clarify assumptions on reliable/unreliable multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 04:46:47 -0000 Hi, all, I would like to remind all that there is no words "reliability" mentioned in " Multicast Protocol for Low power and Lossy Networks (MPL) draft-ietf-roll-trickle-mcast-05. " While in another draft, Applicability Statement: The use of the RPL protocol set in Home Automation and Building Control draft-ietf-roll-applicability-home-building-01, give some descriptions as following: {/begin 2.2. Traffic Characteristics For reliability purposes, it is therefore essential that alternative n-hop communication routes exist for quick error recovery. 2.2.7. RPL applicability per communication paradigm N-cast over the wireless network will be done using multicast with MPL [I-D.ietf-roll-trickle-mcast]. Configuration constraints that are necessary to meet reliability and timeliness with MPL are discussed in Section 4.1.7. 3. Using RPL to meet Functional Requirements When reliability is required, multiple independent paths are used with RPL-P2P. For 1-hop destinations this means that one 1-hop communication and a second 2-hop communication take place via a neigboring node. The same reliability can be achieved by using MPL where the seed is a repeater and a second repeater is 1 hop removed from the seed and the destination node. 4. RPL Profile RPL-P2P MUST be used in home and building networks. Non-storing mode allows for constrained memory in repeaters when source routing is used. 4.1.7. Multicast Commercial light deployments may have a need for multicast. Several mechanisms exist for achieving such functionality; [I-D.ietf-roll-trickle-mcast] is RECOMMENDED for home and building deployments. Guaranteeing timeliness is intimately related to the density of the MPL routers. ...... There are no rules about selecting repeaters for MPL. In buildings with central managment tools, the repeaters can be selected, but in the home is not possible to automatically configure the repeater topology at this moment. /end} NOTE: no reliability mentioned in 4.1.7. At least until now, " ROLL MPL (Trickle) " of " Multicast Protocol for Low power and Lossy Networks (MPL) draft-ietf-roll-trickle-mcast-05. " does not guarante reliability. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: core issue tracker Sent: Wednesday, November 13, 2013 4:05 PM To: draft-ietf-core-groupcomm@tools.ietf.org ; esko.dijk@philips.com Cc: core@ietf.org Subject: [core] #355: Clarify assumptions on reliable/unreliable multicast #355: Clarify assumptions on reliable/unreliable multicast Based on IETF88 discussion, we propose to add some text to describe that we assume an unreliable IP multicast mechanism. Also mention that ROLL MPL (Trickle) is a way to achieve higher reliability without requiring new mechanisms on the CoAP level. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Wed Nov 13 23:45:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF721E819A for ; Wed, 13 Nov 2013 23:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9cVDy2Nm59K for ; Wed, 13 Nov 2013 23:44:57 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3073D21E816B for ; Wed, 13 Nov 2013 23:44:55 -0800 (PST) Received: from mail224-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 07:44:55 +0000 Received: from mail224-tx2 (localhost [127.0.0.1]) by mail224-tx2-R.bigfish.com (Postfix) with ESMTP id 1567DB804E9; Thu, 14 Nov 2013 07:44:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(z579ehz217bI15d6O9371Ic89bh542I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzd9hz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh109h2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h1155h) Received: from mail224-tx2 (localhost.localdomain [127.0.0.1]) by mail224-tx2 (MessageSwitch) id 1384415092386537_16350; Thu, 14 Nov 2013 07:44:52 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.241]) by mail224-tx2.bigfish.com (Postfix) with ESMTP id 599E7540086; Thu, 14 Nov 2013 07:44:52 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 07:44:52 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.3.158.2; Thu, 14 Nov 2013 07:44:17 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.03.0158.002; Thu, 14 Nov 2013 07:44:17 +0000 From: "Dijk, Esko" To: weigengyu , "trac+core@trac.tools.ietf.org" , "draft-ietf-core-groupcomm@tools.ietf.org" Thread-Topic: [core] #355: Clarify assumptions on reliable/unreliable multicast Thread-Index: AQHO4EcZbNCW3wTCIU6CpcO5syJNqJokKGoAgAAwBTA= Date: Thu, 14 Nov 2013 07:44:17 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC38DEF@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <060.178361dc4332d6174c594b7781e4603f@trac.tools.ietf.org> <7DBB3220CDD245D1BF9C230E3C0EACC6@WeiGengyuPC> In-Reply-To: <7DBB3220CDD245D1BF9C230E3C0EACC6@WeiGengyuPC> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.69.203.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org" Subject: Re: [core] #355: Clarify assumptions on reliable/unreliable multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 07:45:02 -0000 SGkgR2VuZ3l1LA0KDQppbmRlZWQgdGhlIGd1YXJhbnRlZWQtcmVsaWFiaWxpdHkgYXNwZWN0IGlz IG5vdCBjb25zaWRlcmVkIGluIE1QTCBub3IgUlBMLiBIb3dldmVyIE1QTCBoYXMgdGhlIGluaGVy ZW50IHByb3BlcnR5IG9mIG11bHRpcGxlIChwb3NzaWJseSBtYW55LCBkZXBlbmRpbmcgb24gcGFy YW1ldGVyIHNldHRpbmdzKSB0cmFuc21pc3Npb24gJ3JldHJpZXMnIGF0IGVhY2ggaG9wIChpLmUu IE1QTCBGb3J3YXJkZXIpLiBBbHNvIHRoZSBmbG9vZGluZyBuYXR1cmUgb2YgTVBMIG1lYW5zIHRo YXQgbWFueS9hbGwgcm91dGluZyBwYXRocyB0aHJvdWdoIGEgbmV0d29yayBhcmUgc2ltdWx0YW5l b3VzbHkgYXR0ZW1wdGVkIHRvIHJlYWNoIGEgZGVzdGluYXRpb24gb3IgZ3JvdXAgb2YgZGVzdGlu YXRpb25zLiBBbHNvIHRoaXMgYXBwcm9hY2ggaXMgaGlnaGx5IHJvYnVzdCBhZ2FpbnN0IGNoYW5n ZXMgaW4gbmV0d29yayB0b3BvbG9neSBhbmQgbmV0d29yayBkZW5zaXR5LiBTbyBNUEwgKHByb3Zp ZGVkIHBhcmFtZXRlcnMgYXJlIHNldCB0byBlbmFibGUgdGhpcykgZG9lcyBwcm92aWRlIHRoZSBo aWdoZXN0IGxldmVsIG9mIHJlbGlhYmlsaXR5IG9uZSBjYW4gZ2V0IHdpdGhvdXQgZ29pbmcgdG8g dGhlIGd1YXJhbnRlZWQtcmVsaWFibGUgbXVsdGljYXN0IHRlY2huaXF1ZXMgdGhhdCBDYXJzdGVu IGFscmVhZHkgbGlzdGVkIGluIGFuIGVhcmxpZXIgZW1haWwgb24gdGhlIHJlbGlhYmlsaXR5IHRv cGljLg0KDQpJZiB0aGUgTVBMIHNwZWMgYW5kIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGZhaWwg dG8gbWVudGlvbiB0aGlzIGFzcGVjdCwgaXQncyBhIGdvb2QgcmVhc29uIHBlcmhhcHMgdG8gc2F5 IHRoaXMgaW4gY29yZS1ncm91cGNvbW0uDQoNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHdlaWdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbl0NClNl bnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNCwgMjAxMyAwNTo0Nw0KVG86IHRyYWMrY29yZUB0cmFj LnRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tQHRvb2xzLmlldGYub3Jn OyBEaWprLCBFc2tvDQpDYzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSAjMzU1 OiBDbGFyaWZ5IGFzc3VtcHRpb25zIG9uIHJlbGlhYmxlL3VucmVsaWFibGUgbXVsdGljYXN0DQoN CkhpLCBhbGwsDQoNCkkgd291bGQgbGlrZSB0byByZW1pbmQgYWxsIHRoYXQgdGhlcmUgaXMgbm8g d29yZHMgInJlbGlhYmlsaXR5IiBtZW50aW9uZWQgaW4gIiBNdWx0aWNhc3QgUHJvdG9jb2wgZm9y IExvdyBwb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgKE1QTCkgZHJhZnQtaWV0Zi1yb2xsLXRyaWNr bGUtbWNhc3QtMDUuICINCg0KV2hpbGUgaW4gYW5vdGhlciBkcmFmdCwgIEFwcGxpY2FiaWxpdHkg U3RhdGVtZW50OiBUaGUgdXNlIG9mIHRoZSBSUEwgcHJvdG9jb2wgc2V0IGluIEhvbWUgQXV0b21h dGlvbiBhbmQgQnVpbGRpbmcgQ29udHJvbCBkcmFmdC1pZXRmLXJvbGwtYXBwbGljYWJpbGl0eS1o b21lLWJ1aWxkaW5nLTAxLCBnaXZlIHNvbWUgZGVzY3JpcHRpb25zIGFzDQpmb2xsb3dpbmc6DQp7 L2JlZ2luDQoyLjIuIFRyYWZmaWMgQ2hhcmFjdGVyaXN0aWNzDQogICAgRm9yIHJlbGlhYmlsaXR5 IHB1cnBvc2VzLCBpdCBpcyB0aGVyZWZvcmUgZXNzZW50aWFsIHRoYXQgYWx0ZXJuYXRpdmUgbi1o b3AgY29tbXVuaWNhdGlvbiByb3V0ZXMgZXhpc3QgZm9yIHF1aWNrIGVycm9yIHJlY292ZXJ5Lg0K Mi4yLjcuIFJQTCBhcHBsaWNhYmlsaXR5IHBlciBjb21tdW5pY2F0aW9uIHBhcmFkaWdtDQogICAg Ti1jYXN0IG92ZXIgdGhlIHdpcmVsZXNzIG5ldHdvcmsgd2lsbCBiZSBkb25lIHVzaW5nIG11bHRp Y2FzdCB3aXRoIE1QTCBbSS1ELmlldGYtcm9sbC10cmlja2xlLW1jYXN0XS4gQ29uZmlndXJhdGlv biBjb25zdHJhaW50cyB0aGF0IGFyZSBuZWNlc3NhcnkgdG8gbWVldCByZWxpYWJpbGl0eSBhbmQg dGltZWxpbmVzcyB3aXRoIE1QTCBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNC4xLjcuDQozLiBV c2luZyBSUEwgdG8gbWVldCBGdW5jdGlvbmFsIFJlcXVpcmVtZW50cw0KICAgIFdoZW4gcmVsaWFi aWxpdHkgaXMgcmVxdWlyZWQsIG11bHRpcGxlIGluZGVwZW5kZW50IHBhdGhzIGFyZSB1c2VkIHdp dGggUlBMLVAyUC4gRm9yIDEtaG9wIGRlc3RpbmF0aW9ucyB0aGlzIG1lYW5zIHRoYXQgb25lIDEt aG9wIGNvbW11bmljYXRpb24gYW5kIGEgc2Vjb25kIDItaG9wIGNvbW11bmljYXRpb24gdGFrZSBw bGFjZSB2aWEgYSBuZWlnYm9yaW5nIG5vZGUuIFRoZSBzYW1lIHJlbGlhYmlsaXR5IGNhbiBiZSBh Y2hpZXZlZCBieSB1c2luZyBNUEwgd2hlcmUgdGhlIHNlZWQgaXMgYSByZXBlYXRlciBhbmQgYSBz ZWNvbmQgcmVwZWF0ZXIgaXMgMSBob3AgcmVtb3ZlZCBmcm9tIHRoZSBzZWVkIGFuZCB0aGUgZGVz dGluYXRpb24gbm9kZS4NCjQuIFJQTCBQcm9maWxlDQogICAgUlBMLVAyUCBNVVNUIGJlIHVzZWQg aW4gaG9tZSBhbmQgYnVpbGRpbmcgbmV0d29ya3MuIE5vbi1zdG9yaW5nIG1vZGUgYWxsb3dzIGZv ciBjb25zdHJhaW5lZCBtZW1vcnkgaW4gcmVwZWF0ZXJzIHdoZW4gc291cmNlIHJvdXRpbmcgaXMg dXNlZC4NCjQuMS43LiBNdWx0aWNhc3QNCiAgICBDb21tZXJjaWFsIGxpZ2h0IGRlcGxveW1lbnRz IG1heSBoYXZlIGEgbmVlZCBmb3IgbXVsdGljYXN0LiBTZXZlcmFsIG1lY2hhbmlzbXMgZXhpc3Qg Zm9yIGFjaGlldmluZyBzdWNoIGZ1bmN0aW9uYWxpdHk7IFtJLUQuaWV0Zi1yb2xsLXRyaWNrbGUt bWNhc3RdIGlzIFJFQ09NTUVOREVEIGZvciBob21lIGFuZCBidWlsZGluZyBkZXBsb3ltZW50cy4N CiAgICBHdWFyYW50ZWVpbmcgdGltZWxpbmVzcyBpcyBpbnRpbWF0ZWx5IHJlbGF0ZWQgdG8gdGhl IGRlbnNpdHkgb2YgdGhlIE1QTCByb3V0ZXJzLiAuLi4uLi4NCiAgICBUaGVyZSBhcmUgbm8gcnVs ZXMgYWJvdXQgc2VsZWN0aW5nIHJlcGVhdGVycyBmb3IgTVBMLiBJbiBidWlsZGluZ3Mgd2l0aCBj ZW50cmFsIG1hbmFnbWVudCB0b29scywgdGhlIHJlcGVhdGVycyBjYW4gYmUgc2VsZWN0ZWQsIGJ1 dCBpbiB0aGUgaG9tZSBpcyBub3QgcG9zc2libGUgdG8gYXV0b21hdGljYWxseSBjb25maWd1cmUg dGhlIHJlcGVhdGVyIHRvcG9sb2d5IGF0IHRoaXMgbW9tZW50Lg0KL2VuZH0NCk5PVEU6IG5vIHJl bGlhYmlsaXR5IG1lbnRpb25lZCBpbiA0LjEuNy4NCg0KQXQgbGVhc3QgdW50aWwgbm93LCAiIFJP TEwgTVBMIChUcmlja2xlKSAiIG9mICIgTXVsdGljYXN0IFByb3RvY29sIGZvciBMb3cgcG93ZXIg YW5kIExvc3N5IE5ldHdvcmtzIChNUEwpIGRyYWZ0LWlldGYtcm9sbC10cmlja2xlLW1jYXN0LTA1 LiAiDQpkb2VzIG5vdCBndWFyYW50ZSByZWxpYWJpbGl0eS4NCg0KUmVnYXJkcywNCg0KR2VuZ3l1 DQoNCk5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINClNjaG9vbCBvZiBDb21wdXRlcg0KQmVpamlu ZyBVbml2ZXJzaXR5IG9mIFBvc3RzICYgVGVsZWNvbW11bmljYXRpb25zDQoNCi0tLS0t5Y6f5aeL 6YKu5Lu2LS0tLS0NCkZyb206IGNvcmUgaXNzdWUgdHJhY2tlcg0KU2VudDogV2VkbmVzZGF5LCBO b3ZlbWJlciAxMywgMjAxMyA0OjA1IFBNDQpUbzogZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbUB0 b29scy5pZXRmLm9yZyA7IGVza28uZGlqa0BwaGlsaXBzLmNvbQ0KQ2M6IGNvcmVAaWV0Zi5vcmcN ClN1YmplY3Q6IFtjb3JlXSAjMzU1OiBDbGFyaWZ5IGFzc3VtcHRpb25zIG9uIHJlbGlhYmxlL3Vu cmVsaWFibGUgbXVsdGljYXN0DQoNCiMzNTU6IENsYXJpZnkgYXNzdW1wdGlvbnMgb24gcmVsaWFi bGUvdW5yZWxpYWJsZSBtdWx0aWNhc3QNCg0KQmFzZWQgb24gSUVURjg4IGRpc2N1c3Npb24sIHdl IHByb3Bvc2UgdG8gYWRkIHNvbWUgdGV4dCB0byBkZXNjcmliZSB0aGF0IHdlIGFzc3VtZSBhbiB1 bnJlbGlhYmxlIElQIG11bHRpY2FzdCBtZWNoYW5pc20uIEFsc28gbWVudGlvbiB0aGF0IFJPTEwg TVBMDQooVHJpY2tsZSkgaXMgYSB3YXkgdG8gYWNoaWV2ZSBoaWdoZXIgcmVsaWFiaWxpdHkgd2l0 aG91dCByZXF1aXJpbmcgbmV3IG1lY2hhbmlzbXMgb24gdGhlIENvQVAgbGV2ZWwuDQoNCi0tDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tDQpSZXBvcnRlcjog ICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBkcmFmdC1pZXRmLWNvcmUtDQogIGVza28uZGlq a0BwaGlsaXBzLmNvbSAgfCAgZ3JvdXBjb21tQHRvb2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBl ZGl0b3JpYWwgICAgfCAgICAgU3RhdHVzOiAgbmV3DQpQcmlvcml0eTogIG1pbm9yICAgICAgICB8 ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBncm91cGNvbW0gICAgfCAgICBWZXJzaW9uOg0KU2V2 ZXJpdHk6ICAtICAgICAgICAgICAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvd2cvY29yZS90cmFjL3RpY2tldC8zNTU+DQpjb3JlIDxodHRwOi8vdG9vbHMu aWV0Zi5vcmcvY29yZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1h eSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUg bGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocyku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9k dWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVz IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K From cabo@tzi.org Fri Nov 22 12:13:24 2013 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 307191AE19E for ; Fri, 22 Nov 2013 12:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Dn1ktE2mBs4D for ; Fri, 22 Nov 2013 12:13:22 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1F44A1AE1E8 for ; Fri, 22 Nov 2013 12:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAMKD6F4027208; Fri, 22 Nov 2013 21:13:06 +0100 (CET) Received: from tzi-v4.plugtests.net (wsip-24-234-25-210.lv.lv.cox.net [24.234.25.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5453B4CB; Fri, 22 Nov 2013 21:13:04 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Carsten Bormann Date: Fri, 22 Nov 2013 12:13:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: To: core X-Mailer: Apple Mail (2.1822) Cc: IOT_PLUGTESTS@LIST.ETSI.ORG Subject: [core] Preliminary Summary from CoAP#3 plug test in Las Vegas 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, 22 Nov 2013 20:13:24 -0000 While a couple of final tests are still ongoing, here is an impression = from the CoAP#3 plugtest that is ending today: Overall interoperability was 94.1 % at the time of writing, with 809 = interoperable out of 860 tests completed. Note that this figure includes a number of completely new = implementations as well as a number of newer specifications, including = OMA LWM2M. The core-coap tests were interoperable at 95.9 %, link-format was even = better at 98.4 %. Remaining hotspots (~ 80 %) are ETags/Validation and separate responses = in a lossy context. Block and Observe are at 84.9 and 84.8 percent, respectively, reflecting = that some of the implementations are rather new and some recent changes = may not be fully implemented. OMA LWM2M was at a stunning 97.4 % given that the 1.0 spec draft is not = even a month old, but that result reflects a smaller sample size and an = early test spec with limited coverage. We found a number of issues where clarifications are desirable in the = LWM2M spec draft. Finally, we only completed very few DTLS tests, at 66.7 % = interoperability. The problems observed were generally with the retransmission mechanism. We will certainly expand this segment in the next events. Thanks go to ETSI for running and to OMA for hosting the event, as well = as to all the participants for bringing lots of implementations to the = event. If you missed this one: The next CoAP/DTLS/LWM2M interop is not far = away. Discussions on the details are ongoing, but we might even have one in = London colocated with IETF89. Gr=FC=DFe, Carsten From cabo@tzi.org Fri Nov 22 14:07:23 2013 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 B65961AE2D1 for ; Fri, 22 Nov 2013 14:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, 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 xzh5hf0br5JH for ; Fri, 22 Nov 2013 14:07:22 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 03B001AE2C9 for ; Fri, 22 Nov 2013 14:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAMM77Xv011389; Fri, 22 Nov 2013 23:07:07 +0100 (CET) Received: from tzi-v4.plugtests.net (wsip-24-234-25-210.lv.lv.cox.net [24.234.25.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0DDDA4EF; Fri, 22 Nov 2013 23:07:05 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Fri, 22 Nov 2013 14:07:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: core X-Mailer: Apple Mail (2.1822) Cc: IOT_PLUGTESTS@LIST.ETSI.ORG Subject: Re: [core] Preliminary Summary from CoAP#3 plug test in Las Vegas 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, 22 Nov 2013 22:07:23 -0000 For those who just can=92t stop testing (or have missed the event): I have deployed the updates for CoAP#3 to http://coap.me, so you can use = coap://coap.me as a test CoAP server and use the web interface of = coap.me as a test CoAP client against your server. The test descriptions for CoAP and DTLS can be found at = https://github.com/cabo/td-coap3 =97 these are not the official ETSI = document (which will be available soon) but the =93source code=94 for = that. If you want to arrange some unofficial remote testing before CoAP#4, = please don=92t hesitate to ask me. Gr=FC=DFe, Carsten From weigengyu@bupt.edu.cn Sun Nov 24 23:12:50 2013 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 DB69F1AC7F0 for ; Sun, 24 Nov 2013 23:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 Jk4WF3YCQhoe for ; Sun, 24 Nov 2013 23:12:48 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0161AC4C1 for ; Sun, 24 Nov 2013 23:12:47 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 2D36119F3A1 for ; Mon, 25 Nov 2013 15:12:41 +0800 (HKT) Message-ID: <64044205845E4B18B2DD96EB25311267@WeiGengyuPC> From: "weigengyu" To: Date: Mon, 25 Nov 2013 15:12:41 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01CEE9F0.C952E940" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Subject: Re: [core] about CoAP and OMA requirements 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, 25 Nov 2013 07:12:51 -0000 һ MIME ʽĶ෽ʼ ------=_NextPart_000_0050_01CEE9F0.C952E940 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, all, OMA LWM2M docs were mentioned in some emails,=20 but OMA LWM2M docs were not used as references in the drafts of this WG. = In the OMA LWM2M =A1=B0Lightweight Machine to Machine Requirements = Candidate Version 1.0 =A8C 02 Oct 2012=A1=B1, there are 40 items in =A1=B0 6.1 High-Level Functional = Requirements=A1=B1.=20 Which ones are as this WG=A1=AFs requirements? =20 Gengyu=20 Network Technology Center School of Computer Beijing University of Posts & Telecommunications ------=_NextPart_000_0050_01CEE9F0.C952E940 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi, all,
 
OMA LWM2M docs were mentioned in some emails,
but OMA LWM2M docs were not used as references in the drafts of = this WG.=20
 
In the OMA LWM2M =A1=B0Lightweight Machine to Machine Requirements = Candidate=20 Version 1.0 =A8C 02 Oct 2012=A1=B1,
there are 40 items in =A1=B0 6.1 High-Level Functional = Requirements=A1=B1.
 
Which ones are as this WG=A1=AFs requirements? 

Gengyu
 
Network Technology Center
School of Computer
Beijing University of Posts & Telecommunications
 
<= /HTML> ------=_NextPart_000_0050_01CEE9F0.C952E940-- From ludwig@sics.se Mon Nov 25 03:28:51 2013 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 EB3031AD7BE for ; Mon, 25 Nov 2013 03:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-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 ierdfVOBpYAS for ; Mon, 25 Nov 2013 03:28:50 -0800 (PST) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1951ACCFC for ; Mon, 25 Nov 2013 03:28:49 -0800 (PST) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id rAPBPi9Z027821 for ; Mon, 25 Nov 2013 12:28:48 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1g7as9xd1n-1 for ; Mon, 25 Nov 2013 12:28:48 +0100 Received: from [192.168.0.103] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 949D7400E2 for ; Mon, 25 Nov 2013 12:28:48 +0100 (CET) Message-ID: <52933469.40600@sics.se> Date: Mon, 25 Nov 2013 12:28:41 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: core@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070709070908010309030106" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-25_01:2013-11-25,2013-11-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311250043 Subject: [core] Security use cases for CoRE 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, 25 Nov 2013 11:28:52 -0000 This is a cryptographically signed message in MIME format. --------------ms070709070908010309030106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, as those of you who attended IETF88 might remember, I am working on a=20 draft on CoRE security use cases [1] with a group of interested people=20 from this WG. The current structure of the draft contains usecases for general=20 communication security, DoS prevention, authentication as well as=20 authorization. In an offline discussion it has been suggested that the use cases for=20 commSec and authentication are well understood by CoRE and mostly=20 covered by the work of DICE. It was therefore suggested to focus on=20 authorization use cases. I'd like to solicit the opinion of the WG on this matter, especially=20 since we aim to get this draft accepted as (informational) working group = document at some point. tl;dr : Should [1] be about authorization use cases only? Regards, Ludwig Seitz [1] draft-seitz-core-sec-usecases-00 --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms070709070908010309030106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwW1izANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDExNTAyMDUwNloXDTE0MDExNTE0Mzc0OFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqm5Fq+vazAJCxhLsrE6yZ4Fcjf22HECMhhoH QAVWMuk61UnFAxiiKnsGb2iRrw9fFD2ZZP+VVKiojuMaNzlnyrULh84UwJhmkm6Ab2olLQ4x XZqNDvFe7djMtMMgqD8Erf35WuK8mrRjqHPX/imDEw4Ub6XvL5+rnhBKQozCm5FoIHOcol5H EbAO+F4XZA3pgQFyUWpWGlyIMZ3na9fkCBspupWZ68ytytxgB0poqbqJMSZtge6bkP/gZo6e dnbAydjkSkqHHGbpKzMJVI12TyJlJTN70Zg/OF4EMgcwN0tmJvrNqhH3oXlkKkTWk94ojP8M J3eQv6del7mB1tJcuwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAO/qDJzu5Icr9AFUhmI3z qGMpbjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBADhtqCPIvc8t6La1swQso5U7FF3Is5txWrQWPzcttJMyPo1LzdNT/jHEKF93 nOqiKm50NISmDFkBSxKOTTYPFJ4thgFcTZf+K57ucvxL/c+MLj3PlmCMNmtciCa8gxpldYz4 aob7CT02KQZvX+yGUmOTdHkoLd9FaxRq0ei43EAxjGIsU7vliaAoKCSO0pRsdtSrOYNV3fSd ZB6xd8KBjAJsC8P/Q2BfeMT5+fJPvX5pfj8h+qyGkJCPx2RHhkf5tSIrnOAoYkvrUZFk1JJx H+v1KrX2QRCu3fx7L9D3S1QNSCD3d3nDcM2sXdtGg6/KynBtw31O4YqQWgU9XQp+NoYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwW1izAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzExMjUxMTI4NDFaMCMGCSqGSIb3DQEJBDEW BBT0wzBR2E6JrkD5QuRL4EqCqoR3BTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFtYswDQYJKoZIhvcNAQEBBQAE ggEAYLA7ES565/7zyyICso4zK27TsQ5dtwNFLRlVQVusrDlk94qlM7/XKCqts9WBkXekf8cM qY6MPfLBkbllFzhy2MwggA126XCoC/IIk7G8yi1sT398BVObPNuY/Uc/cSduxbc8BSVa7hL6 3n+TANoYGQxuXB5DAL7Dvqd30VdWr86so+FxLhbJ5mebH8QhAgpVPfQoOa/Yuu9/421ctqqy /hHdysg7rhgKun2dTqhtOv2VvPm1hluWMQJK/malgxaiPZtkmJd3Bu7I6LFy5ydFZtbTf4hx mE3+we428TSjXPbcoTyd8eBq+1tXit34V0TPGHI1wOF2MPvMd96C0Eon0wAAAAAAAA== --------------ms070709070908010309030106-- From ietf@sandeep.de Mon Nov 25 04:37:34 2013 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 4A3621AD8EF for ; Mon, 25 Nov 2013 04:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] 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 lt5Bb-QsUGCa for ; Mon, 25 Nov 2013 04:37:31 -0800 (PST) Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D86E1AD687 for ; Mon, 25 Nov 2013 04:37:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1385383049; l=5952; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version:X-RZG-CLASS-ID:X-RZG-AUTH; bh=97zfsigGitL7PRqTCHQgBvYvsms=; b=BEv1F9s3W7G1MbnHQP2klOXT6ISc1dbbv6IwGJoED/GXuRr8tDMLKfPjZOmAp5l2/hA CZbnulSNtDawppfaYs7pRF1lXAXFkn5Fh2mLVELFBtFgpVFvZTtcwTVYe6DZJcQud5Ck5 /D+8Aylo41bdak1fEsquBISf+5ORBZKedxM= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQSEYQcnho= X-RZG-CLASS-ID: mo00 Received: from mail-bk0-f43.google.com ([209.85.214.43]) by smtp.strato.de (RZmta 32.16 AUTH) with (TLSv1.0:DHE-RSA-AES256-SHA encrypted) ESMTPSA id u0562fpAPCbQfvt for ; Mon, 25 Nov 2013 13:37:26 +0100 (CET) Received: by mail-bk0-f43.google.com with SMTP id mz12so1936963bkb.2 for ; Mon, 25 Nov 2013 04:37:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VoM8kBbQqeiDBiosBvZycxm03wucwB4CJxX84kjnqtk=; b=GWPYuT21jJCUu+sQLE1yRVIfXR2XWgVdEgqjKBO87euHqHE/R1uiIuon6Lvqij5Cik o//cPaSehGu2aBD65aachQCUdh7rJUEVttLJ/JJG2iDYgFL5LFEBKMdyeLIcMvpd7GAL MFOFZCiBYdfbQbmNEVr+jD0QJHB9Oh68Hnt6xF69Azl2WFGiXYzo8icy+NNcJlX+1LKm Ym4IG9sHzjYJzm+SoPj0K3kF/jlzEk2J11lImnkSAkj/H4MO0r2A97+xFWYSpZx6RtaC 8Di8gb/4fi1DviYojz/AhCHHZqlGJ+DOIQFQHQBrIYycR66rk3Quw2P5HWmWif1p3b1p t/RA== MIME-Version: 1.0 X-Received: by 10.205.12.133 with SMTP id pi5mr1260799bkb.54.1385383045964; Mon, 25 Nov 2013 04:37:25 -0800 (PST) Received: by 10.205.38.11 with HTTP; Mon, 25 Nov 2013 04:37:25 -0800 (PST) In-Reply-To: <52933469.40600@sics.se> References: <52933469.40600@sics.se> Date: Mon, 25 Nov 2013 13:37:25 +0100 Message-ID: From: Sandeep Kumar To: Ludwig Seitz Content-Type: multipart/alternative; boundary=20cf301cbe0e557ad504ebffa0ba Cc: core@ietf.org Subject: Re: [core] Security use cases for CoRE 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, 25 Nov 2013 12:37:34 -0000 --20cf301cbe0e557ad504ebffa0ba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ludwig Maybe the goals you want to achieve with this document can help the decision. If the goal is to identify the missing pieces of the IoT security puzzle, then capturing all different possible security use cases from the IoT makes sense. Authorization being only one of the missing pieces. CommSec and authentication are not the missing pieces, the lifecycle management of these protocols yes. So usecases that only provides a reaffirmation for Section 9 of draft-ietf-core-coap or the DICE wg charter are not really worthwhile. However if the goal is to identify why authorization is indeed something that needs to be solved and additionally why it needs to be solved in core/ietf, then I would say focus on authorization usecases. From the Berlin meeting, I remember that this was indeed the start of the "writing down the usecases" discussion. Even though I like the first goal, the focus in the second goal will help get something done more useful with the authorization drafts in the short term. That's my two cents Sandeep On Mon, Nov 25, 2013 at 12:28 PM, Ludwig Seitz wrote: > Hello, > > > as those of you who attended IETF88 might remember, I am working on a > draft on CoRE security use cases [1] with a group of interested people fr= om > this WG. > > The current structure of the draft contains usecases for general > communication security, DoS prevention, authentication as well as > authorization. > > In an offline discussion it has been suggested that the use cases for > commSec and authentication are well understood by CoRE and mostly covered > by the work of DICE. It was therefore suggested to focus on authorization > use cases. > > I'd like to solicit the opinion of the WG on this matter, especially sinc= e > we aim to get this draft accepted as (informational) working group docume= nt > at some point. > > > tl;dr : Should [1] be about authorization use cases only? > > > Regards, > > Ludwig Seitz > > [1] draft-seitz-core-sec-usecases-00 > > -- > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=E4gen 17 > SE-223 70 Lund > > Phone +46(0)70-349 92 51 > http://www.sics.se > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --20cf301cbe0e557ad504ebffa0ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ludwig

Maybe= the goals you want to achieve with this document can help the decision.
If the goal is to identify the missing pieces of the IoT securit= y puzzle, then capturing all different possible security use cases from the= IoT makes sense. Authorization being only one of the missing pieces.=A0 Co= mmSec and authentication are not the missing pieces, the lifecycle manageme= nt of these protocols yes. So usecases that only provides a reaffirmation f= or Section 9 of draft-ietf-core-coap or the DICE wg charter are not really = worthwhile.

However if the goal is to identify why authorization is indeed so= mething that needs to be solved and additionally why it needs to be solved = in core/ietf, then I would say focus on authorization usecases. From the Be= rlin meeting, I remember that this was indeed the start of the "writin= g down the usecases" discussion.

Even though I like the first goal, the focus in the second goal w= ill help get something done more useful with the authorization drafts in th= e short term.=A0

That's my two cents
Sandeep


On Mon,= Nov 25, 2013 at 12:28 PM, Ludwig Seitz <ludwig@sics.se> wrote:=
Hello,


as those of you who attended IETF88 might remember, I am working on a draft= on CoRE security use cases [1] with a group of interested people from this= WG.

The current structure of the draft contains usecases for general communicat= ion security, DoS prevention, authentication as well as authorization.

In an offline discussion it has been suggested that the use cases for commS= ec and authentication are well understood by CoRE and mostly covered by the= work of DICE. It was therefore suggested to focus on authorization use cas= es.

I'd like to solicit the opinion of the WG on this matter, especially si= nce we aim to get this draft accepted as (informational) working group docu= ment at some point.


tl;dr : Should [1] be about authorization use cases only?


Regards,

Ludwig Seitz

[1] draft-seitz-core-sec-usecases-00

--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelev=E4gen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se


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


--20cf301cbe0e557ad504ebffa0ba-- From rstruik.ext@gmail.com Mon Nov 25 05:20:01 2013 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 C68F01AD945 for ; Mon, 25 Nov 2013 05:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_22=0.6, 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 38c49OPynEOg for ; Mon, 25 Nov 2013 05:20:00 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9AD1AD6C1 for ; Mon, 25 Nov 2013 05:20:00 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so6739754iec.41 for ; Mon, 25 Nov 2013 05:20:00 -0800 (PST) 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=QSu2sX5d6zxhkzhGshYBgtI3WyyNHm0gySy5MNtims8=; b=ae1ts37D+RCEUrX8azJvRRQPYuVuXjeapk+mF3jeE7k8QKX1rqA+N9lXyIeIl+F3Lq HfDsetLHR8R7MrfpCeP/wZc56ziQBTQhIAXOUlsNBx0EC4l4TIMSfizVN8JHTKLdLuVp yauIii20tXYMC87AOGhMRlLary0Zra/0VxktbKlEUdLOFcj22TeFwCGVRswxft26Gx+s Y+1Wh1yfaR+aZs+uK2QHOe0m5pyVW5U/1nEjDq2MZuhIn9Uxc3GXX7fKDlFxwG/c5aZp Tv1g55wtZFKZHLrmVUQV8R1aYvJX3ohUFNwTqsl4PUq1jvf8W7dgVeqHevYksnX0aneo raWw== X-Received: by 10.42.224.10 with SMTP id im10mr1375189icb.46.1385385600243; Mon, 25 Nov 2013 05:20:00 -0800 (PST) Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id x5sm26237646iga.6.2013.11.25.05.19.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 05:19:59 -0800 (PST) Message-ID: <52934E73.7020004@gmail.com> Date: Mon, 25 Nov 2013 08:19:47 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ludwig Seitz , core@ietf.org References: <52933469.40600@sics.se> In-Reply-To: <52933469.40600@sics.se> Content-Type: multipart/alternative; boundary="------------020802070702090907090001" Subject: Re: [core] Security use cases for CoRE 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, 25 Nov 2013 13:20:02 -0000 This is a multi-part message in MIME format. --------------020802070702090907090001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ludwig: Authorization can only be enforced via proper authentication mechanisms, so I do expect any description of the former to refer to the latter. Rene On 11/25/2013 6:28 AM, Ludwig Seitz wrote: > Hello, > > > as those of you who attended IETF88 might remember, I am working on a > draft on CoRE security use cases [1] with a group of interested people > from this WG. > > The current structure of the draft contains usecases for general > communication security, DoS prevention, authentication as well as > authorization. > > In an offline discussion it has been suggested that the use cases for > commSec and authentication are well understood by CoRE and mostly > covered by the work of DICE. It was therefore suggested to focus on > authorization use cases. > > I'd like to solicit the opinion of the WG on this matter, especially > since we aim to get this draft accepted as (informational) working > group document at some point. > > > tl;dr : Should [1] be about authorization use cases only? > > > Regards, > > Ludwig Seitz > > [1] draft-seitz-core-sec-usecases-00 > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------020802070702090907090001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ludwig:

Authorization can only be enforced via proper authentication mechanisms, so I do expect any description of the former to refer to the latter.

Rene

On 11/25/2013 6:28 AM, Ludwig Seitz wrote:
Hello,


as those of you who attended IETF88 might remember, I am working on a draft on CoRE security use cases [1] with a group of interested people from this WG.

The current structure of the draft contains usecases for general communication security, DoS prevention, authentication as well as authorization.

In an offline discussion it has been suggested that the use cases for commSec and authentication are well understood by CoRE and mostly covered by the work of DICE. It was therefore suggested to focus on authorization use cases.

I'd like to solicit the opinion of the WG on this matter, especially since we aim to get this draft accepted as (informational) working group document at some point.


tl;dr : Should [1] be about authorization use cases only?


Regards,

Ludwig Seitz

[1] draft-seitz-core-sec-usecases-00 



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------020802070702090907090001-- From gerdes@tzi.de Mon Nov 25 06:08:35 2013 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 5A6A91ADBD4 for ; Mon, 25 Nov 2013 06:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 lIlLhgBTYXGW for ; Mon, 25 Nov 2013 06:08:33 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCDF1ADBD3 for ; Mon, 25 Nov 2013 06:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAPE8SBq001825 for ; Mon, 25 Nov 2013 15:08:28 +0100 (CET) Received: from [134.102.218.232] (dynamic-218-2.informatik.uni-bremen.de [134.102.218.232]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3A38ED76 for ; Mon, 25 Nov 2013 15:08:28 +0100 (CET) Message-ID: <529359DC.4070506@tzi.de> Date: Mon, 25 Nov 2013 15:08:28 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: core@ietf.org References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> In-Reply-To: <52934E73.7020004@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [core] Security use cases for CoRE 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, 25 Nov 2013 14:08:35 -0000 On 11/25/2013 02:19 PM, Rene Struik wrote: > Hi Ludwig: > > Authorization can only be enforced via proper authentication mechanisms, > so I do expect any description of the former to refer to the latter. +1 Best regards, Steffi From goran.selander@ericsson.com Mon Nov 25 06:25:43 2013 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 0A52D1ADDAC for ; Mon, 25 Nov 2013 06:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 b1ZKdoSefnJa for ; Mon, 25 Nov 2013 06:25:41 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 846001ADD9D for ; Mon, 25 Nov 2013 06:25:40 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-0c-52935de40b53 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 58.A7.23787.4ED53925; Mon, 25 Nov 2013 15:25:40 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.136]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 15:25:39 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Rene Struik , Ludwig Seitz , "core@ietf.org" Thread-Topic: [core] Security use cases for CoRE Thread-Index: AQHO6dGHGhSQrpQtSEqGdxDPcPvg6Jo13Z+AgAAjNgA= Date: Mon, 25 Nov 2013 14:25:39 +0000 Message-ID: In-Reply-To: <52934E73.7020004@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_F3AD00FA8C16C24298F85A1A14F03E433CB9AF69ESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvre6T2MlBBm+PC1jse7ue2eJV6x1m i9U3nrM4MHvsnHWX3WPJkp9MHr3HfrMFMEdx2aSk5mSWpRbp2yVwZfz6sJm94I1MxdozV9ka GH9KdDFyckgImEg8+3GBDcIWk7hwbz2QzcUhJHCIUaL3zR5mCGcJo8TSr1NZQarYBFwlDjx4 xwRiiwhkSsz8/xMsLiygL3FzXisLRNxAYv6Lt4wQtpXEs3+TwOIsAqoSHx7/AqvnFfCVWHzt GthmTgFNiUUzXoHVMwJd8f3UGrD5zALiEreezGeCuE5AYsme88wQtqjEy8f/wOaICuhJ3DzT wgoRV5T4+GofI0RvvsT07XuYIXYJSpyc+YRlAqPILCRjZyEpm4WkDCKuJ3Fj6hQ2CFtbYtnC 18wQtq7EjH+HoGqsJaZf3YaiZgEjxypG9tzEzJz0csNNjMBIO7jlt+4OxlPnRA4xSnOwKInz fnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0d48t/Tj3yN6lUtOqHLVSgs6sPlkuzrf tRNMaJjxwebY2wWLbFXKi0ViTW1251k97DW2l2DZ021WfPL+V7OkNm213AiGJGMxMZ3rwTK/ V6gfcF03r+Oq+aOsmrdO0y42KLiGKH7YtaG+7KqwV+Vejz/srql2GhbxIq/tb17uKQuL42Bg MVJiKc5INNRiLipOBAAAooNbggIAAA== Subject: Re: [core] Security use cases for CoRE 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, 25 Nov 2013 14:25:43 -0000 --_000_F3AD00FA8C16C24298F85A1A14F03E433CB9AF69ESESSMB303erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, From: Rene Struik > Date: Monday, November 25, 2013 2:19 PM To: Ludwig Seitz >, "core@ietf.org" > Subject: Re: [core] Security use cases for CoRE Hi Ludwig: Authorization can only be enforced via proper authentication mechanisms, so= I do expect any description of the former to refer to the latter. [G=F6ran] Agree, and it may not restrict access appropriately to only authe= nticate and authorize, if you transport the response in plain text. So comm= unication security may also be a derived requirement to support authorizati= on. This is not claiming that there would be any new authentication or comm= unication security requirements, but the fact that authentication and commu= nication security is required implies e.g. the need for certain key managem= ent, which we have seen is not fully covered in CoAP and DICE. Best regards, G=F6ran --_000_F3AD00FA8C16C24298F85A1A14F03E433CB9AF69ESESSMB303erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <01F1190C3E770F4F814341738DEACE85@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi all,

From: Rene Struik <rstruik.ext@gmail.com>
Date: Monday, November 25, 2013 2:1= 9 PM
To: Ludwig Seitz <ludwig@sics.se>, "core@ietf.org" <core@i= etf.org>
Subject: Re: [core] Security use ca= ses for CoRE

Hi Ludwig:

Authorization can only be enforced via proper authentication mechanisms, so= I do expect any description of the former to refer to the latter.

[G=F6ran] Agree, and it may not restrict access appropriately to only authe= nticate and authorize, if you transport the response in plain text. So comm= unication security may also be a derived requirement to support authorizati= on. This is not claiming that there would be any new authentication or communication security requirements, bu= t the fact that authentication and communication security is required impli= es e.g. the need for certain key management, which we have seen is not full= y covered in CoAP and DICE.

Best regards,
G=F6ran


--_000_F3AD00FA8C16C24298F85A1A14F03E433CB9AF69ESESSMB303erics_-- From schmitt@ifi.uzh.ch Mon Nov 25 07:50:50 2013 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 474911ADF72 for ; Mon, 25 Nov 2013 07:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 duA7M6DFinIS for ; Mon, 25 Nov 2013 07:50:45 -0800 (PST) Received: from bohuslav.ifi.uzh.ch (bohuslav.ifi.uzh.ch [130.60.155.10]) by ietfa.amsl.com (Postfix) with ESMTP id 457E81ADF71 for ; Mon, 25 Nov 2013 07:50:43 -0800 (PST) Received: from authenticated sender schmitt by bohuslav.ifi.uzh.ch (postfix) with ESMTPSA id SA for ; core@ietf.org Message-ID: <529371D1.6020400@ifi.uzh.ch> Date: Mon, 25 Nov 2013 16:50:41 +0100 From: Corinna Schmitt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: core@ietf.org References: <52937166.2060208@ifi.uzh.ch> In-Reply-To: <52937166.2060208@ifi.uzh.ch> X-Forwarded-Message-Id: <52937166.2060208@ifi.uzh.ch> Content-Type: multipart/alternative; boundary="------------020303060501090505000105" X-Virus-Scanned: clamav-milter 0.97.8 at bohuslav X-Virus-Status: Clean Subject: [core] CfP NOMS "Special Track on Privacy, Trust, Regulation, and Legal Issues" 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, 25 Nov 2013 15:50:50 -0000 This is a multi-part message in MIME format. --------------020303060501090505000105 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Dear Core Members, please, find below our call for paper for special track on "Privacy, Trust, Regulation, and Legal Issues" will be held at the IEEE/IFIP Network Operations and Management Symposium (NOMS 2014). Online version is available under: http://noms2014.ieee-noms.org/content/special-track-privacy-trust-regulation-and-legal-issues We are looking forward for your submission and further forwarding and announcement of the call. Regards, Corinna Special Track on Privacy, Trust, Regulation, and Legal Issues A special track on "Privacy, Trust, Regulation, and Legal Issues" will be held at the IEEE/IFIP Network Operations and Management Symposium (NOMS 2014) in Krakow, Poland, May 5--9, 2014. This special track is sponsored by the IEEE Communications Society and is supported by the EU FP7 Flamingo Network of Excellence research project and EU FP7 SmartenIT STREP project. Following the success of previous editions of NOMS and the rising research in security issues, the main goal of this special track is to present the state-of-the-art research results and experience reports in the area of security, addressing amongst others currently important topics such as privacy, trust, regulation, and legal issues (correlating to economics and their effects) for the Future Internet, especially when data containing private and sensitive information is published in the Internet. This special track should answer among others the following questions: * What regulations and legal issues exists that limit access to published data * How much trust is required between communication partners? * What privacy concerns exist when data is published? * Which solutions exist to bring trust into the Future Internet? * What requirements and challenges must be faced for security developments in the Future Internet? * What implications does Internet technology have for the concept of "nonpublic" information? NOMS 2014 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion. Furthermore, the session attendees will be stimulated to participate in interesting discussions amongst the attendees, such that all participants can take home lots of ideas for consideration in their ongoing research projects or start new research projects to address the challenging topics. To this end, short papers describing late-breaking advances and work-in-progress reports from ongoing research are also welcome. TOPICS OF INTEREST Authors are invited to submit papers that fall into or are related to one or multiple topic areas listed below: * State-of-the-art analysis * Privacy and anonymity issues in the Future Internet * Descriptions and models of new threats to privacy * Experience reports from Future Internet experimental facilities set--up and results * Legal, regulative, and cost implications of data in transit * Legal and regulative impact of user's profile cloning, and leakage of sensitive information about the user * Understanding how trust emerges and evolves, and developing trustworthy services for Future Internet * Requirements, challenges, and associated costs for securing communications * Impact of new Internet architectures on privacy-- enhancing technologies and vice versa * Privacy and security issues and restrictions in monitoring network traffic * Regulations for data access in the Future Internet * Trusted computing technology * Security issues for constraint devices * Cyber security PAPER SUBMISSION Paper submissions must present original, unpublished research or experiences. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 words abstract that clearly outlines the scope and contributions of the paper. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular papers and 4 pages for short papers describing work in progress. Submissions must be in IEEE 2-column style. Self-plagiarized papers will be rejected without further review. Authors should submit their papers via JEMS: https://submissoes.sbc.org.br/home.cgi?c=1812. PROCEEDINGS Papers accepted for special track on "Privacy, Trust, Regulation and Legal Issues" will be included in the conference proceedings, IEEE Xplore, IFIP database, and EI Index. IFIP and IEEE reserve the right to remove any paper from the IFIP database and IEEE Xplore, if the paper is not presented at the conference. SPECIAL TRACK CO-CHAIRS * Corinna Schmitt, University of Zrich, Switzerland * Sofie Verbrugge, iMinds, Belgium IMPORTANT DATES * Paper submission: January 15, 2014 * Notification of acceptance: February 15, 2014 * Final version of papers due: March 1, 2014 * Workshop date: May 5, 2014 -- -- --------------020303060501090505000105 Content-Type: multipart/related; boundary="------------020602050700010405040505" --------------020602050700010405040505 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Dear Core Members,

please, find below our call for paper for special track on “Privacy, Trust, Regulation, and Legal Issues" will be held at the IEEE/IFIP Network Operations and Management Symposium (NOMS 2014). Online version is available under: http://noms2014.ieee-noms.org/content/special-track-privacy-trust-regulation-and-legal-issues

We are looking forward for your submission and further forwarding and announcement of the call.

Regards,
Corinna


Special Track on Privacy, Trust, Regulation, and Legal Issues

A special track on “Privacy, Trust, Regulation, and Legal Issues" will be held at the IEEE/IFIP Network Operations and Management Symposium (NOMS 2014) in Krakow, Poland, May 5-‐9, 2014. This special track is sponsored by the IEEE Communications Society and is supported by the EU FP7 Flamingo Network of Excellence research project and EU FP7 SmartenIT STREP project.
Following the success of previous editions of NOMS and the rising research in security issues, the main goal of this special track is to present the state-of-the-art research results and experience reports in the area of security, addressing amongst others currently important topics such as privacy, trust, regulation, and legal issues (correlating to economics and their effects) for the Future Internet, especially when data containing private and sensitive information is published in the Internet.
This special track should answer among others the following questions:
  • What regulations and legal issues exists that limit access to published data
  • How much trust is required between communication partners?
  • What privacy concerns exist when data is published?
  • Which solutions exist to bring trust into the Future Internet?
  • What requirements and challenges must be faced for security developments in the Future Internet?
  • What implications does Internet technology have for the concept of “nonpublic” information?
NOMS 2014 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion. Furthermore, the session attendees will be stimulated to participate in interesting discussions amongst the attendees, such that all participants can take home lots of ideas for consideration in their ongoing research projects or start new research projects to address the challenging topics. To this end, short papers describing late‐breaking advances and work‐in‐progress reports from ongoing research are also welcome.

TOPICS OF INTEREST

Authors are invited to submit papers that fall into or are related to one or multiple topic areas listed below:
  • State-of‐the‐art analysis
  • Privacy and anonymity issues in the Future Internet
  • Descriptions and models of new threats to privacy
  • Experience reports from Future Internet experimental facilities set-‐up and results
  • Legal, regulative, and cost implications of data in transit
  • Legal and regulative impact of user’s profile cloning, and leakage of sensitive information about the user
  • Understanding how trust emerges and evolves, and developing trustworthy services for Future Internet
  • Requirements, challenges, and associated costs for securing communications
  • Impact of new Internet architectures on privacy-‐ enhancing technologies and vice versa
  • Privacy and security issues and restrictions in monitoring network traffic
  • Regulations for data access in the Future Internet
  • Trusted computing technology
  • Security issues for constraint devices
  • Cyber security

PAPER SUBMISSION

Paper submissions must present original, unpublished research or experiences. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 words abstract that clearly outlines the scope and contributions of the paper. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular papers and 4 pages for short papers describing work in progress. Submissions must be in IEEE 2‐column style. Self‐plagiarized papers will be rejected without further review. Authors should submit their papers via JEMS: https://submissoes.sbc.org.br/home.cgi?c=1812.

PROCEEDINGS

Papers accepted for special track on "Privacy, Trust, Regulation and Legal Issues" will be included in the conference proceedings, IEEE Xplore, IFIP database, and EI Index. IFIP and IEEE reserve the right to remove any paper from the IFIP database and IEEE Xplore, if the paper is not presented at the conference.

SPECIAL TRACK CO-CHAIRS

  • Corinna Schmitt, University of Zrich, Switzerland
  • Sofie Verbrugge, iMinds, Belgium

IMPORTANT DATES

  • Paper submission: January 15, 2014
  • Notification of acceptance: February 15, 2014
  • Final version of papers due: March 1, 2014
  • Workshop date: May 5, 2014



--



--


--------------020602050700010405040505 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm 5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9 +/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3 ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1 no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0 qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8 zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi 5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57 du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69 e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK 5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8 /kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q 379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs 3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8 LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7 jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb 1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg 48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37 9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9 nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL 3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379 XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+ 8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N 2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl 5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61// OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154 ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9 e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx 9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN /PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2 baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj 8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc 861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73 se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn 7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+ 0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf// 9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7 7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778 mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy 5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+ 1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/ S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/ +x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19 /n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8 rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0 +R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3 LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr 165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40 GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/ cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw /kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr 1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1 RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT 4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh 2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb 6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4 W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM 1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u 3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5 oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga 61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo 115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx /vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5 ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3 3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ 4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy 87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR 9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn 1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197 zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw 7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg 9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1 y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77 8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y 5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2 SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1 a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2 6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5 eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5 i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55 htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx 413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN 0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9 Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8 RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2 7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8 Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3 atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE 7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf 17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F 7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at 7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+ JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4 EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8 PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L 9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9 AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2 jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa 4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW /iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ /Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+ KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0 5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9 Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo 9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1 eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7 jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz 5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU 0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1 53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY 1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3 vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5 40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9 JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um 7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk 1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4 bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU 4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf /6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3 hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+ bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4 wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5 tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061 BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB +EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw /jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB 4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly 5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+ Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4 qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I /qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO 0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1 68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8 pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn +RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18 0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd /sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo 8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1 bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3 ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8 Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS 73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2 mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv 3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR 52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ 1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz 4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV 2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2 NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54 NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k /JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR 4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0 WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i 5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1 dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6 YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3 S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa +n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p 9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2 pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO RK5CYII= --------------020602050700010405040505 Content-Type: image/png; x-mac-type="0"; x-mac-creator="0"; name="visitenkarte.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="visitenkarte.png" iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm 5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9 +/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3 ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1 no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0 qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8 zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi 5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57 du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69 e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK 5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8 /kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q 379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs 3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8 LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7 jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb 1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg 48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37 9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9 nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL 3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379 XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+ 8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N 2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl 5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61// OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154 ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9 e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx 9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN /PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2 baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj 8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc 861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73 se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn 7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+ 0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf// 9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7 7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778 mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy 5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+ 1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/ S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/ +x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19 /n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8 rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0 +R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3 LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr 165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40 GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/ cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw /kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr 1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1 RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT 4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh 2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb 6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4 W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM 1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u 3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5 oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga 61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo 115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx /vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5 ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3 3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ 4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy 87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR 9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn 1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197 zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw 7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg 9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1 y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77 8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y 5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2 SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1 a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2 6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5 eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5 i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55 htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx 413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN 0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9 Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8 RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2 7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8 Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3 atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE 7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf 17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F 7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at 7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+ JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4 EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8 PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L 9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9 AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2 jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa 4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW /iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ /Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+ KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0 5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9 Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo 9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1 eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7 jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz 5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU 0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1 53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY 1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3 vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5 40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9 JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um 7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk 1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4 bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU 4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf /6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3 hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+ bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4 wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5 tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061 BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB +EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw /jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB 4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly 5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+ Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4 qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I /qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO 0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1 68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8 pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn +RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18 0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd /sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo 8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1 bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3 ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8 Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS 73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2 mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv 3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR 52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ 1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz 4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV 2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2 NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54 NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k /JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR 4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0 WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i 5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1 dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6 YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3 S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa +n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p 9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2 pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO RK5CYII= --------------020602050700010405040505-- --------------020303060501090505000105-- From Bert.Greevenbosch@huawei.com Mon Nov 25 16:30:56 2013 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 9627F1AE0E5 for ; Mon, 25 Nov 2013 16:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 l2zXrxAoSbTb for ; Mon, 25 Nov 2013 16:30:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ADBB81AE0E2 for ; Mon, 25 Nov 2013 16:30:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAR88663; Tue, 26 Nov 2013 00:30:53 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 00:30:27 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 00:30:50 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.229]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 08:30:44 +0800 From: Bert Greevenbosch To: Rene Struik , Ludwig Seitz , "core@ietf.org" Thread-Topic: [core] Security use cases for CoRE Thread-Index: AQHO6dGMCH3tigSLZ0a30t1BC5CbApo1aEaAgAFAfvA= Date: Tue, 26 Nov 2013 00:30:43 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> In-Reply-To: <52934E73.7020004@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63E3A3683SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 00:30:56 -0000 --_000_46A1DF3F04371240B504290A071B4DB63E3A3683SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1, authentication is essential for authorisation. From: core [mailto:core-bounces@ietf.org] On Behalf Of Rene Struik Sent: 25 November 2013 21:20 To: Ludwig Seitz; core@ietf.org Subject: Re: [core] Security use cases for CoRE Hi Ludwig: Authorization can only be enforced via proper authentication mechanisms, so= I do expect any description of the former to refer to the latter. Rene On 11/25/2013 6:28 AM, Ludwig Seitz wrote: Hello, as those of you who attended IETF88 might remember, I am working on a draft= on CoRE security use cases [1] with a group of interested people from this= WG. The current structure of the draft contains usecases for general communicat= ion security, DoS prevention, authentication as well as authorization. In an offline discussion it has been suggested that the use cases for commS= ec and authentication are well understood by CoRE and mostly covered by the= work of DICE. It was therefore suggested to focus on authorization use cas= es. I'd like to solicit the opinion of the WG on this matter, especially since = we aim to get this draft accepted as (informational) working group document= at some point. tl;dr : Should [1] be about authorization use cases only? Regards, Ludwig Seitz [1] draft-seitz-core-sec-usecases-00 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --_000_46A1DF3F04371240B504290A071B4DB63E3A3683SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1, authentication= is essential for authorisation.

 

From: core [mailto:core-bounces@ietf.org] On Behalf Of Rene Struik
Sent: 25 November 2013 21:20
To: Ludwig Seitz; core@ietf.org
Subject: Re: [core] Security use cases for CoRE

 

Hi Ludwig:

Authorization can only be enforced via proper authentication mechanisms, so= I do expect any description of the former to refer to the latter.

Rene

On 11/25/2013 6:28 AM, Ludwig Seitz wrote:

Hello,


as those of you who attended IETF88 might remember, I am working on a draft= on CoRE security use cases [1] with a group of interested people from this= WG.

The current structure of the draft contains usecases for general communicat= ion security, DoS prevention, authentication as well as authorization.

In an offline discussion it has been suggested that the use cases for commS= ec and authentication are well understood by CoRE and mostly covered by the= work of DICE. It was therefore suggested to focus on authorization use cas= es.

I'd like to solicit the opinion of the WG on this matter, especially since = we aim to get this draft accepted as (informational) working group document= at some point.


tl;dr : Should [1] be about authorization use cases only?


Regards,

Ludwig Seitz

[1] draft-seitz-core-sec-usecases-00 




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




-- 
email: rstruik.ext@gmail.com<=
/a> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--_000_46A1DF3F04371240B504290A071B4DB63E3A3683SZXEMA510MBXchi_-- From likepeng@huawei.com Mon Nov 25 17:19:15 2013 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 175CD1AE0E7 for ; Mon, 25 Nov 2013 17:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 WhYWvpzNzEJC for ; Mon, 25 Nov 2013 17:19:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 86F4F1AE0E1 for ; Mon, 25 Nov 2013 17:19:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYH73667; Tue, 26 Nov 2013 01:19:11 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 01:18:46 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 01:19:10 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.45]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 09:18:58 +0800 From: Likepeng To: Bert Greevenbosch , Rene Struik , Ludwig Seitz , "core@ietf.org" Thread-Topic: [core] Security use cases for CoRE Thread-Index: AQHO6dGMUB/zXgy3rEKCMumaSTEiaZo1aEaAgAC7dYCAAJJRkA== Date: Tue, 26 Nov 2013 01:18:58 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.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_34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07FSZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 01:19:15 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07FSZXEMA501MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 PmF1dGhlbnRpY2F0aW9uIGlzIGVzc2VudGlhbCBmb3IgYXV0aG9yaXphdGlvbg0KDQorMS4NCg0K PndlIGFpbSB0byBnZXQgdGhpcyBkcmFmdCBhY2NlcHRlZCBhcyAoaW5mb3JtYXRpb25hbCkgd29y a2luZyBncm91cCBkb2N1bWVudCBhdCBzb21lIHBvaW50Lg0KDQpJIGJlbGlldmUgYSBzZXBhcmF0 ZSBXRyBpcyBtb3JlIGFwcHJvcHJpYXRlIGZvciB0aGlzIGl0ZW0sIHNpbmNlIHdlIGhhdmUgYSBs b3Qgb2Ygc2VjdXJpdHkgaXNzdWVzIGFuZCB3ZSByZWFsbHkgbmVlZCB0aGUgaGVscCBmcm9tIHNl Y3VyaXR5IGFyZWEgZXhwZXJ0cyBhbmQgd2UgbmVlZCBtb3JlIG5ldyBlbmVyZ2llcyBmb3IgdGhp cyBhcmVhLg0KDQpUaGFua3MsDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQq3orz+yMs6IGNvcmUg W21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQmVydCBHcmVldmVuYm9zY2gNCrei y83KsbzkOiAyMDEzxOoxMdTCMjbI1SA4OjMxDQrK1bz+yMs6IFJlbmUgU3RydWlrOyBMdWR3aWcg U2VpdHo7IGNvcmVAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbY29yZV0gU2VjdXJpdHkgdXNlIGNhc2Vz IGZvciBDb1JFDQoNCisxLCBhdXRoZW50aWNhdGlvbiBpcyBlc3NlbnRpYWwgZm9yIGF1dGhvcmlz YXRpb24uDQoNCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBSZW5lIFN0cnVpaw0KU2VudDogMjUgTm92ZW1iZXIgMjAxMyAyMToyMA0KVG86IEx1 ZHdpZyBTZWl0ejsgY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbY29yZV0gU2VjdXJpdHkgdXNlIGNhc2VzIGZvciBDb1JFDQoNCkhpIEx1ZHdpZzoNCg0K QXV0aG9yaXphdGlvbiBjYW4gb25seSBiZSBlbmZvcmNlZCB2aWEgcHJvcGVyIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbXMsIHNvIEkgZG8gZXhwZWN0IGFueSBkZXNjcmlwdGlvbiBvZiB0aGUgZm9y bWVyIHRvIHJlZmVyIHRvIHRoZSBsYXR0ZXIuDQoNClJlbmUNCg0KT24gMTEvMjUvMjAxMyA2OjI4 IEFNLCBMdWR3aWcgU2VpdHogd3JvdGU6DQpIZWxsbywNCg0KDQphcyB0aG9zZSBvZiB5b3Ugd2hv IGF0dGVuZGVkIElFVEY4OCBtaWdodCByZW1lbWJlciwgSSBhbSB3b3JraW5nIG9uIGEgZHJhZnQg b24gQ29SRSBzZWN1cml0eSB1c2UgY2FzZXMgWzFdIHdpdGggYSBncm91cCBvZiBpbnRlcmVzdGVk IHBlb3BsZSBmcm9tIHRoaXMgV0cuDQoNClRoZSBjdXJyZW50IHN0cnVjdHVyZSBvZiB0aGUgZHJh ZnQgY29udGFpbnMgdXNlY2FzZXMgZm9yIGdlbmVyYWwgY29tbXVuaWNhdGlvbiBzZWN1cml0eSwg RG9TIHByZXZlbnRpb24sIGF1dGhlbnRpY2F0aW9uIGFzIHdlbGwgYXMgYXV0aG9yaXphdGlvbi4N Cg0KSW4gYW4gb2ZmbGluZSBkaXNjdXNzaW9uIGl0IGhhcyBiZWVuIHN1Z2dlc3RlZCB0aGF0IHRo ZSB1c2UgY2FzZXMgZm9yIGNvbW1TZWMgYW5kIGF1dGhlbnRpY2F0aW9uIGFyZSB3ZWxsIHVuZGVy c3Rvb2QgYnkgQ29SRSBhbmQgbW9zdGx5IGNvdmVyZWQgYnkgdGhlIHdvcmsgb2YgRElDRS4gSXQg d2FzIHRoZXJlZm9yZSBzdWdnZXN0ZWQgdG8gZm9jdXMgb24gYXV0aG9yaXphdGlvbiB1c2UgY2Fz ZXMuDQoNCkknZCBsaWtlIHRvIHNvbGljaXQgdGhlIG9waW5pb24gb2YgdGhlIFdHIG9uIHRoaXMg bWF0dGVyLCBlc3BlY2lhbGx5IHNpbmNlIHdlIGFpbSB0byBnZXQgdGhpcyBkcmFmdCBhY2NlcHRl ZCBhcyAoaW5mb3JtYXRpb25hbCkgd29ya2luZyBncm91cCBkb2N1bWVudCBhdCBzb21lIHBvaW50 Lg0KDQoNCnRsO2RyIDogU2hvdWxkIFsxXSBiZSBhYm91dCBhdXRob3JpemF0aW9uIHVzZSBjYXNl cyBvbmx5Pw0KDQoNClJlZ2FyZHMsDQoNCkx1ZHdpZyBTZWl0eg0KDQpbMV0gZHJhZnQtc2VpdHot Y29yZS1zZWMtdXNlY2FzZXMtMDANCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KY29yZSBtYWlsaW5nIGxpc3QNCg0KY29yZUBpZXRmLm9y ZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlDQoNCg0KDQotLQ0KDQplbWFpbDogcnN0cnVpay5leHRAZ21haWwuY29tPG1h aWx0bzpyc3RydWlrLmV4dEBnbWFpbC5jb20+IHwgU2t5cGU6IHJzdHJ1aWsNCg0KY2VsbDogKzEg KDY0NykgODY3LTU2NTggfCBVUzogKzEgKDQxNSkgNjkwLTczNjMNCg== --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07FSZXEMA501MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

>aut= hentication is essential for authorization

&n= bsp;

+1.=

&n= bsp;

>we = aim to get this draft accepted as (informational) working group document at= some point.

&n= bsp;

I belie= ve a separate WG is more appropriate for this item, since we have a lot of = security issues and we really need the help from security area experts and we need more new energies for this area.

&n= bsp;

Thanks,=

Kind Re= gards

Kepeng

 = ;

=B7=A2=BC=FE=C8=CB:<= /b> core [mailto:core-bounces@ietf.org] =B4=FA=B1=ED Bert Greevenbosch
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C226=C8=D5 8:31
=CA=D5=BC=FE=C8=CB: Rene Struik; Ludwig Seitz; core@ietf.org
=D6=F7=CC=E2: Re: [core] Security use cases for CoRE

 

+1,= authentication is essential for authorisation.

&n= bsp;

From:= core [mailto:core-bounces@ietf.org] On Behalf Of Rene Struik
Sent: 25 November 2013 21:20
To: Ludwig Seitz; core@ietf.org=
Subject: Re: [core] Security use cases for CoRE

 

Hi Ludwig:

Authorization can only be enforced via proper authentication mechanisms, so= I do expect any description of the former to refer to the latter.

Rene

On 11/25/2013 6:28 AM, Ludwig Seitz wrote:

= Hello,


as those of you who attended IETF88 might remember, I am working on a draft= on CoRE security use cases [1] with a group of interested people from this= WG.

The current structure of the draft contains usecases for general communicat= ion security, DoS prevention, authentication as well as authorization.

In an offline discussion it has been suggested that the use cases for commS= ec and authentication are well understood by CoRE and mostly covered by the= work of DICE. It was therefore suggested to focus on authorization use cas= es.

I'd like to solicit the opinion of the WG on this matter, especially since = we aim to get this draft accepted as (informational) working group document= at some point.


tl;dr : Should [1] be about authorization use cases only?


Regards,

Ludwig Seitz

[1] draft-seitz-core-sec-usecases-00 



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

= 

-- 
email: r=
struik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 69=
0-7363
--_000_34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07FSZXEMA501MBSchi_-- From barryleiba.mailing.lists@gmail.com Mon Nov 25 19:03:48 2013 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 67D3F1AE103 for ; Mon, 25 Nov 2013 19:03:48 -0800 (PST) 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 RpcGTG-1t0vB for ; Mon, 25 Nov 2013 19:03:47 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0A05F1AE146 for ; Mon, 25 Nov 2013 19:03:46 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id ia6so3408805vcb.18 for ; Mon, 25 Nov 2013 19:03:46 -0800 (PST) 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=ORNC0fPTpTC9Bthhjji+WZYA9FJhGLnKZwqlagHysu0=; b=kUXp3PTswBYPxtotoDGkQCWyz2cu7ekW1C2TwlOF3rTREZ4SVJLjM9hgG/wDblRVIj slXxN7kaZ5747d8Z7hAtMh47zveJQ/XTOmCFlmYLN4yR666XhLYuMvcprPwqy8lCa6f1 TY0dyKGBldwNvHZ/hBR7pV1Vvgj7lCCkJdz6Q6ewFivgT89HYD7whd3WRQFwzxUBHL6M iL5QstIc29uprQD/JYmUSKC6U144McIcMbeVmeExEaw/2N3i9DLeOBEHB4x/1henxo3F J3AQ9r7c7S+YGfcqLTHxhEhrV0eU1MX/IgFCWdxQtVdGAglr2iarmj+HOlWoTRX8GoAh nX0w== MIME-Version: 1.0 X-Received: by 10.52.0.9 with SMTP id 9mr340984vda.47.1385435026652; Mon, 25 Nov 2013 19:03:46 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.170.71 with HTTP; Mon, 25 Nov 2013 19:03:46 -0800 (PST) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> Date: Mon, 25 Nov 2013 22:03:46 -0500 X-Google-Sender-Auth: emUanuvn-ozD4TPcyXbicSRn_sk Message-ID: From: Barry Leiba To: "core@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 03:03:48 -0000 > I believe a separate WG is more appropriate for this item, since we have a > lot of security issues and we really need the help from security area > experts and we need more new energies for this area. For what it's worth, your responsible AD thinks so, too. I would much rather see a working group chartered to do this in the Security Area (though I could accept it in the Applications Area is I were assured there'd be enough Sec Area participation). The reason I want it to be separate is to focus the security work and to provide a place for the Sec Area participants to engage without their having to sift through the other CORE protocol discussions. Barry, Applications AD From weigengyu@bupt.edu.cn Mon Nov 25 19:46:43 2013 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 7F79A1A1F52 for ; Mon, 25 Nov 2013 19:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.063 X-Spam-Level: X-Spam-Status: No, score=-0.063 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 GtIEc7C8jPLh for ; Mon, 25 Nov 2013 19:46:41 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id DE1DF1AE08A for ; Mon, 25 Nov 2013 19:46:38 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 3161119F397; Tue, 26 Nov 2013 11:46:35 +0800 (HKT) Message-ID: <02640F35739941CF856BF49DD4BDADDB@WeiGengyuPC> From: "weigengyu" To: "Barry Leiba" , References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> In-Reply-To: Date: Tue, 26 Nov 2013 11:46:34 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 03:46:43 -0000 I agree to discuss in a separate WG too. It is easy to see that the security requirements as OMA LWMAN docs are far more than that defined in CoAP Charter. Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Barry Leiba Sent: Tuesday, November 26, 2013 11:03 AM To: core@ietf.org Subject: Re: [core] Security use cases for CoRE > I believe a separate WG is more appropriate for this item, since we have a > lot of security issues and we really need the help from security area > experts and we need more new energies for this area. For what it's worth, your responsible AD thinks so, too. I would much rather see a working group chartered to do this in the Security Area (though I could accept it in the Applications Area is I were assured there'd be enough Sec Area participation). The reason I want it to be separate is to focus the security work and to provide a place for the Sec Area participants to engage without their having to sift through the other CORE protocol discussions. Barry, Applications AD _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Mon Nov 25 23:27:50 2013 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 4B50C1AE190 for ; Mon, 25 Nov 2013 23:27:50 -0800 (PST) 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 6nKix1xuzw67 for ; Mon, 25 Nov 2013 23:27:49 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C123A1AE183 for ; Mon, 25 Nov 2013 23:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAQ7RjY5017040 for ; Tue, 26 Nov 2013 08:27:46 +0100 (CET) Received: from [192.168.217.105] (p548922B6.dip0.t-ipconnect.de [84.137.34.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7E09816A; Tue, 26 Nov 2013 08:27:45 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Carsten Bormann In-Reply-To: Date: Tue, 26 Nov 2013 08:27:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <980D5994-B0D4-4E63-8778-89F3939869ED@tzi.org> References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> To: "core@ietf.org" X-Mailer: Apple Mail (2.1822) Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 07:27:50 -0000 On 26 Nov 2013, at 04:03, Barry Leiba wrote: >> I believe a separate WG is more appropriate for this item, since we = have a >> lot of security issues and we really need the help from security area >> experts and we need more new energies for this area. >=20 > For what it's worth, your responsible AD thinks so, too. I would much > rather see a working group chartered to do this in the Security Area > (though I could accept it in the Applications Area is I were assured > there'd be enough Sec Area participation). Maybe this is a hint that this document is creeping away from being a = =93use cases=94 document. But indeed, solution work would benefit from being in its own WG with = considerable Security Area attention. If we want a BOF in London, we have to start now preparing. Gr=FC=DFe, Carsten From likepeng@huawei.com Tue Nov 26 00:59:30 2013 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 4E62B1AD6BF for ; Tue, 26 Nov 2013 00:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 zjBcp_31iPUI for ; Tue, 26 Nov 2013 00:59:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 264E61AC863 for ; Tue, 26 Nov 2013 00:59:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI08613; Tue, 26 Nov 2013 08:59:27 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 08:58:42 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 08:59:06 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.45]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 16:59:03 +0800 From: Likepeng To: Carsten Bormann , "core@ietf.org" Thread-Topic: [core] Security use cases for CoRE Thread-Index: AQHO6dGMUB/zXgy3rEKCMumaSTEiaZo1aEaAgAC7dYCAAJJRkP//mHIAgABJv4CAAJ3QIA== Date: Tue, 26 Nov 2013 08:59:02 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF321@SZXEMA501-MBS.china.huawei.com> References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> <980D5994-B0D4-4E63-8778-89F3939869ED@tzi.org> In-Reply-To: <980D5994-B0D4-4E63-8778-89F3939869ED@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 Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 08:59:30 -0000 Pk1heWJlIHRoaXMgaXMgYSBoaW50IHRoYXQgdGhpcyBkb2N1bWVudCBpcyBjcmVlcGluZyBhd2F5 IGZyb20gYmVpbmcgYSDigJx1c2UgY2FzZXPigJ0gZG9jdW1lbnQuDQoNCkkgbWVhbiwgYXV0aGVu dGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gYXMgYSB3aG9sZSwgbm90IGp1c3QgdGhlIHVzZSBj YXNlIGRvY3VtZW50Lg0KDQo+QnV0IGluZGVlZCwgc29sdXRpb24gd29yayB3b3VsZCBiZW5lZml0 IGZyb20gYmVpbmcgaW4gaXRzIG93biBXRyB3aXRoIGNvbnNpZGVyYWJsZSBTZWN1cml0eSBBcmVh IGF0dGVudGlvbi4NCj5JZiB3ZSB3YW50IGEgQk9GIGluIExvbmRvbiwgd2UgaGF2ZSB0byBzdGFy dCBub3cgcHJlcGFyaW5nLg0KDQpZZXMsIHN1cmUuIEkgd291bGQgYmUgcXVpdGUgaGFwcHkgdG8g d29yayB0b2dldGhlciB3aXRoIGludGVyZXN0ZWQgcGFydGllcyB0b3dhcmRzIHRoaXMgZGlyZWN0 aW9uLg0KDQpUaGFua3MsDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCi0tLS0t6YKu5Lu25Y6f 5Lu2LS0tLS0NCuWPkeS7tuS6ujogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10g 5Luj6KGoIENhcnN0ZW4gQm9ybWFubg0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTHmnIgyNuaXpSAx NToyOA0K5pS25Lu25Lq6OiBjb3JlQGlldGYub3JnDQrkuLvpopg6IFJlOiBbY29yZV0gU2VjdXJp dHkgdXNlIGNhc2VzIGZvciBDb1JFDQoNCk9uIDI2IE5vdiAyMDEzLCBhdCAwNDowMywgQmFycnkg TGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPiB3cm90ZToNCg0KPj4gSSBiZWxpZXZlIGEg c2VwYXJhdGUgV0cgaXMgbW9yZSBhcHByb3ByaWF0ZSBmb3IgdGhpcyBpdGVtLCBzaW5jZSB3ZSAN Cj4+IGhhdmUgYSBsb3Qgb2Ygc2VjdXJpdHkgaXNzdWVzIGFuZCB3ZSByZWFsbHkgbmVlZCB0aGUg aGVscCBmcm9tIA0KPj4gc2VjdXJpdHkgYXJlYSBleHBlcnRzIGFuZCB3ZSBuZWVkIG1vcmUgbmV3 IGVuZXJnaWVzIGZvciB0aGlzIGFyZWEuDQo+IA0KPiBGb3Igd2hhdCBpdCdzIHdvcnRoLCB5b3Vy IHJlc3BvbnNpYmxlIEFEIHRoaW5rcyBzbywgdG9vLiAgSSB3b3VsZCBtdWNoIA0KPiByYXRoZXIg c2VlIGEgd29ya2luZyBncm91cCBjaGFydGVyZWQgdG8gZG8gdGhpcyBpbiB0aGUgU2VjdXJpdHkg QXJlYSANCj4gKHRob3VnaCBJIGNvdWxkIGFjY2VwdCBpdCBpbiB0aGUgQXBwbGljYXRpb25zIEFy ZWEgaXMgSSB3ZXJlIGFzc3VyZWQgDQo+IHRoZXJlJ2QgYmUgZW5vdWdoIFNlYyBBcmVhIHBhcnRp Y2lwYXRpb24pLg0KDQpNYXliZSB0aGlzIGlzIGEgaGludCB0aGF0IHRoaXMgZG9jdW1lbnQgaXMg Y3JlZXBpbmcgYXdheSBmcm9tIGJlaW5nIGEg4oCcdXNlIGNhc2Vz4oCdIGRvY3VtZW50Lg0KDQpC dXQgaW5kZWVkLCBzb2x1dGlvbiB3b3JrIHdvdWxkIGJlbmVmaXQgZnJvbSBiZWluZyBpbiBpdHMg b3duIFdHIHdpdGggY29uc2lkZXJhYmxlIFNlY3VyaXR5IEFyZWEgYXR0ZW50aW9uLg0KSWYgd2Ug d2FudCBhIEJPRiBpbiBMb25kb24sIHdlIGhhdmUgdG8gc3RhcnQgbm93IHByZXBhcmluZy4NCg0K R3LDvMOfZSwgQ2Fyc3Rlbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From ndamour@sierrawireless.com Tue Nov 26 01:50:41 2013 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 2CD091ADFDA for ; Tue, 26 Nov 2013 01:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 piQOGoSA68P1 for ; Tue, 26 Nov 2013 01:50:38 -0800 (PST) Received: from carmd-sa01.sierrawireless.com (carmd-sa01.sierrawireless.com [208.81.121.45]) by ietfa.amsl.com (Postfix) with ESMTP id 972F41A1F55 for ; Tue, 26 Nov 2013 01:50:38 -0800 (PST) X-ASG-Debug-ID: 1385459435-0252477cbd23bd0001-aa7cYp Received: from CARMD-EXCHHUB01.sierrawireless.local (carmd-exchhub01.sierrawireless.local [10.0.6.2]) by carmd-sa01.sierrawireless.com with ESMTP id prjPMaGtdAYWP2G2 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Nov 2013 01:50:35 -0800 (PST) X-Barracuda-Envelope-From: ndamour@sierrawireless.com X-ASG-Whitelist: Client Received: from carmd-exchmb01.sierrawireless.local ([10.0.6.3]) by CARMD-EXCHHUB01.sierrawireless.local ([::1]) with mapi; Tue, 26 Nov 2013 01:50:35 -0800 From: Nicolas Damour To: "core@ietf.org" Date: Tue, 26 Nov 2013 01:50:31 -0800 Thread-Topic: [core] Security use cases for CoRE X-ASG-Orig-Subj: RE: [core] Security use cases for CoRE Thread-Index: AQHO6dGMUB/zXgy3rEKCMumaSTEiaZo1aEaAgAC7dYCAAJJRkIAAjatA Message-ID: <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_9287D1909D3EEA4E92505D48604887E9EA273A6069carmdexchmb01_" MIME-Version: 1.0 X-Barracuda-Connect: carmd-exchhub01.sierrawireless.local[10.0.6.2] X-Barracuda-Start-Time: 1385459435 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://carmd-sa01.sierrawireless.com:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sierrawireless.com X-Barracuda-BRTS-Status: 1 Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 09:50:41 -0000 --_000_9287D1909D3EEA4E92505D48604887E9EA273A6069carmdexchmb01_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8uDQoNCkkgbWF5IGJlIHN3aW1taW5nIGFnYWluc3QgdGhlIGN1cnJlbnQgaGVyZSwgc28g SeKAmW0gc29ycnkgdG8gYmUgYSBsaXR0bGUgaWNvbm9jbGFzdCBoZXJlIChhbmQgaWYgSSBhbSB3 cm9uZywgcGxlYXNlIGFjY2VwdCBteSBhcG9sb2dpZXMgaW4gYWR2YW5jZSkuDQpJIHdvdWxkIHNh eSB0aGF0IGZyb20gYSBzdHJpY3QgdGhlb3JldGljYWwgcG9pbnQgb2YgdmlldywgYXV0aG9yaXph dGlvbiBkb2VzIGFic29sdXRlbHkgbm90IHJlcXVpcmUgYXV0aGVudGljYXRpb24uDQoNCkEgdmVy eSBzaW1wbGUgZXhhbXBsZSBpbiB0aGUgcGh5c2ljYWwgd29ybGQgaXMgYWNjZXNzIHRvIGEgc2Fm ZSBpbiBzb21lIChwb3NzaWJseSBTd2lzcykgYmFua3MuDQpBcyBsb25nIGFzIHlvdSBoYXZlIHRo ZSBrZXkgKG9yIHBhc3Njb2RlKSwgeW91IGNhbiBnZXQgYWNjZXNzIHRvIHRoZSBzYWZlLg0KQW5k IG5vIG9uZSB3aWxsIGV2ZXIgYXNrIHlvdSBmb3IgeW91ciBpZGVudGl0eS4NCkFzIGEgbWF0dGVy IG9mIGZhY3QsIGluIHNvbWUgb2YgdGhlc2UgY2FzZXMgaXQgaXMgYWJzb2x1dGVseSBlc3NlbnRp YWwgdGhhdCBhdXRob3JpemF0aW9uIGhhcHBlbnMgd2l0aCBubyBmb3JtIG9mIGF1dGhlbnRpY2F0 aW9uIHdoYXRzb2V2ZXIuDQoNCkluIHRoZSBJVCB3b3JsZCwgaXTigJlzIHF1aXRlIHRoZSBzYW1l Lg0KQW4gYXBwbGljYXRpb24gY291bGQgYWNjZXNzIGEgc2VydmljZSBieSBkaXNwbGF5aW5nIHNv bWUgc29ydCBvZiBjcmVkZW50aWFsLCB3aGlsZSBuZXZlciBhdXRoZW50aWNhdGluZyBpdHNlbGYu DQpJIGJlbGlldmUgdGhhdCBPQXV0aCwgZm9yIGV4YW1wbGUsIGRvZXMgcHJvdmlkZSB0aGF0IHNv cnQgb2YgbWVjaGFuaXNtLg0KDQpOb3csIG9mIGNvdXJzZSB0aGVyZSBpcyB2YWx1ZSBpbiBhdXRo ZW50aWNhdGlvbiBhcyB3ZWxsLg0KDQpCdXQgSSB3b3VsZCB0aGluayB0aGF0IHRvIHNheSB0aGF0 IGF1dGhvcml6YXRpb24gcmVxdWlyZXMgYXV0aGVudGljYXRpb24gaXMgcGxhaW5seSB3cm9uZy4N Cg0KSnVzdCBteSB0d28gY2VudHMsDQoNCk5pY29sYXMuDQoNCg0KDQpOaWNvbGFzIERBTU9VUiA6 OiBTZW5pb3IgTWFuYWdlciwgQnVzaW5lc3MgYW5kIElubm92YXRpb24gRGV2ZWxvcG1lbnQNClNJ RVJSQSBXSVJFTEVTUyA6OiBDVE8gT2ZmaWNlDQpQaG9uZSArMzMgKDApIDY3MCA3MDYgMDAzDQpM YWtlIFBhcmsgLSBaQUMgZGUgbCdIZXJzIC0gQWxsw6llIGR1IExhYyAtIEJQIDg3MjE2IDo6IDMx NjcyIExhYsOoZ2UgQ2VkZXggOjogRnJhbmNlDQpuZGFtb3VyQHNpZXJyYXdpcmVsZXNzLmNvbTxt YWlsdG86bmRhbW91ckBzaWVycmF3aXJlbGVzcy5jb20+IDo6IHd3dy5zaWVycmF3aXJlbGVzcy5j b208aHR0cDovL3d3dy5zaWVycmF3aXJlbGVzcy5jb20vPg0KDQpEZSA6IGNvcmUgW21haWx0bzpj b3JlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTGlrZXBlbmcNCkVudm95w6kgOiBt YXJkaSAyNiBub3ZlbWJyZSAyMDEzIDAyOjE5DQrDgCA6IEJlcnQgR3JlZXZlbmJvc2NoOyBSZW5l IFN0cnVpazsgTHVkd2lnIFNlaXR6OyBjb3JlQGlldGYub3JnDQpPYmpldCA6IFJlOiBbY29yZV0g U2VjdXJpdHkgdXNlIGNhc2VzIGZvciBDb1JFDQoNCj5hdXRoZW50aWNhdGlvbiBpcyBlc3NlbnRp YWwgZm9yIGF1dGhvcml6YXRpb24NCg0KKzEuDQoNCj53ZSBhaW0gdG8gZ2V0IHRoaXMgZHJhZnQg YWNjZXB0ZWQgYXMgKGluZm9ybWF0aW9uYWwpIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgYXQgc29t ZSBwb2ludC4NCg0KSSBiZWxpZXZlIGEgc2VwYXJhdGUgV0cgaXMgbW9yZSBhcHByb3ByaWF0ZSBm b3IgdGhpcyBpdGVtLCBzaW5jZSB3ZSBoYXZlIGEgbG90IG9mIHNlY3VyaXR5IGlzc3VlcyBhbmQg d2UgcmVhbGx5IG5lZWQgdGhlIGhlbHAgZnJvbSBzZWN1cml0eSBhcmVhIGV4cGVydHMgYW5kIHdl IG5lZWQgbW9yZSBuZXcgZW5lcmdpZXMgZm9yIHRoaXMgYXJlYS4NCg0KVGhhbmtzLA0KS2luZCBS ZWdhcmRzDQpLZXBlbmcNCg0K5Y+R5Lu25Lq6OiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnXSDku6PooaggQmVydCBHcmVldmVuYm9zY2gNCuWPkemAgeaXtumXtDogMjAxM+W5tDEx 5pyIMjbml6UgODozMQ0K5pS25Lu25Lq6OiBSZW5lIFN0cnVpazsgTHVkd2lnIFNlaXR6OyBjb3Jl QGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0K5Li76aKYOiBSZTogW2NvcmVdIFNlY3Vy aXR5IHVzZSBjYXNlcyBmb3IgQ29SRQ0KDQorMSwgYXV0aGVudGljYXRpb24gaXMgZXNzZW50aWFs IGZvciBhdXRob3Jpc2F0aW9uLg0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUmVuZSBTdHJ1aWsNClNlbnQ6IDI1IE5vdmVtYmVyIDIwMTMg MjE6MjANClRvOiBMdWR3aWcgU2VpdHo7IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIFNlY3VyaXR5IHVzZSBjYXNlcyBmb3IgQ29SRQ0KDQpI aSBMdWR3aWc6DQoNCkF1dGhvcml6YXRpb24gY2FuIG9ubHkgYmUgZW5mb3JjZWQgdmlhIHByb3Bl ciBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zLCBzbyBJIGRvIGV4cGVjdCBhbnkgZGVzY3JpcHRp b24gb2YgdGhlIGZvcm1lciB0byByZWZlciB0byB0aGUgbGF0dGVyLg0KDQpSZW5lDQoNCk9uIDEx LzI1LzIwMTMgNjoyOCBBTSwgTHVkd2lnIFNlaXR6IHdyb3RlOg0KSGVsbG8sDQoNCg0KYXMgdGhv c2Ugb2YgeW91IHdobyBhdHRlbmRlZCBJRVRGODggbWlnaHQgcmVtZW1iZXIsIEkgYW0gd29ya2lu ZyBvbiBhIGRyYWZ0IG9uIENvUkUgc2VjdXJpdHkgdXNlIGNhc2VzIFsxXSB3aXRoIGEgZ3JvdXAg b2YgaW50ZXJlc3RlZCBwZW9wbGUgZnJvbSB0aGlzIFdHLg0KDQpUaGUgY3VycmVudCBzdHJ1Y3R1 cmUgb2YgdGhlIGRyYWZ0IGNvbnRhaW5zIHVzZWNhc2VzIGZvciBnZW5lcmFsIGNvbW11bmljYXRp b24gc2VjdXJpdHksIERvUyBwcmV2ZW50aW9uLCBhdXRoZW50aWNhdGlvbiBhcyB3ZWxsIGFzIGF1 dGhvcml6YXRpb24uDQoNCkluIGFuIG9mZmxpbmUgZGlzY3Vzc2lvbiBpdCBoYXMgYmVlbiBzdWdn ZXN0ZWQgdGhhdCB0aGUgdXNlIGNhc2VzIGZvciBjb21tU2VjIGFuZCBhdXRoZW50aWNhdGlvbiBh cmUgd2VsbCB1bmRlcnN0b29kIGJ5IENvUkUgYW5kIG1vc3RseSBjb3ZlcmVkIGJ5IHRoZSB3b3Jr IG9mIERJQ0UuIEl0IHdhcyB0aGVyZWZvcmUgc3VnZ2VzdGVkIHRvIGZvY3VzIG9uIGF1dGhvcml6 YXRpb24gdXNlIGNhc2VzLg0KDQpJJ2QgbGlrZSB0byBzb2xpY2l0IHRoZSBvcGluaW9uIG9mIHRo ZSBXRyBvbiB0aGlzIG1hdHRlciwgZXNwZWNpYWxseSBzaW5jZSB3ZSBhaW0gdG8gZ2V0IHRoaXMg ZHJhZnQgYWNjZXB0ZWQgYXMgKGluZm9ybWF0aW9uYWwpIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQg YXQgc29tZSBwb2ludC4NCg0KDQp0bDtkciA6IFNob3VsZCBbMV0gYmUgYWJvdXQgYXV0aG9yaXph dGlvbiB1c2UgY2FzZXMgb25seT8NCg0KDQpSZWdhcmRzLA0KDQpMdWR3aWcgU2VpdHoNCg0KWzFd IGRyYWZ0LXNlaXR6LWNvcmUtc2VjLXVzZWNhc2VzLTAwDQoNCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KY29yZSBtYWlsaW5nIGxpc3QN Cg0KY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg0KDQoNCi0tDQoNCmVtYWlsOiByc3RydWlr LmV4dEBnbWFpbC5jb208bWFpbHRvOnJzdHJ1aWsuZXh0QGdtYWlsLmNvbT4gfCBTa3lwZTogcnN0 cnVpaw0KDQpjZWxsOiArMSAoNjQ3KSA4NjctNTY1OCB8IFVTOiArMSAoNDE1KSA2OTAtNzM2Mw0K --_000_9287D1909D3EEA4E92505D48604887E9EA273A6069carmdexchmb01_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpT aW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg NCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xh czsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ047fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZv cm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ047fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9y bWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs YWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nh cg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czsNCgljb2xvcjpibGFjazt9DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0 ZWQsIGRpdi5IVE1MUHJlZm9ybWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTjt9DQpwLkhUTUwsIGxpLkhUTUwsIGRpdi5IVE1MDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg 6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjsNCgljb2xvcjpibGFjazsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTjt9DQpzcGFu LkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byP IjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h aWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUy Ng0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC5hLCBsaS5hLCBkaXYuYQ0KCXttc28tc3R5 bGUtbmFtZTrmibnms6jmoYbmlofmnKw7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+ac rCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ047fQ0Kc3Bhbi5DaGFyDQoJe21z by1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTpTaW1T dW47DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29s b3I9d2hpdGUgbGFuZz1GUiBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+SGVsbG8uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBtYXkg YmUgc3dpbW1pbmcgYWdhaW5zdCB0aGUgY3VycmVudCBoZXJlLCBzbyBJ4oCZbSBzb3JyeSB0byBi ZSBhIGxpdHRsZSBpY29ub2NsYXN0IGhlcmUgKGFuZCBpZiBJIGFtIHdyb25nLCBwbGVhc2UgYWNj ZXB0IG15IGFwb2xvZ2llcyBpbiBhZHZhbmNlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIHdvdWxkIHNh eSB0aGF0IGZyb20gYSBzdHJpY3QgdGhlb3JldGljYWwgcG9pbnQgb2YgdmlldywgYXV0aG9yaXph dGlvbiBkb2VzIDx1PmFic29sdXRlbHkgbm90PC91PiByZXF1aXJlIGF1dGhlbnRpY2F0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkEgdmVyeSBzaW1wbGUgZXhh bXBsZSBpbiB0aGUgcGh5c2ljYWwgd29ybGQgaXMgYWNjZXNzIHRvIGEgc2FmZSBpbiBzb21lIChw b3NzaWJseSBTd2lzcykgYmFua3MuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXMgbG9uZyBhcyB5b3UgaGF2 ZSB0aGUga2V5IChvciBwYXNzY29kZSksIHlvdSBjYW4gZ2V0IGFjY2VzcyB0byB0aGUgc2FmZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5BbmQgbm8gb25lIHdpbGwgZXZlciBhc2sgeW91IGZvciB5b3VyIGlk ZW50aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFzIGEgbWF0dGVyIG9mIGZhY3QsIGluIHNvbWUgb2Yg dGhlc2UgY2FzZXMgaXQgaXMgYWJzb2x1dGVseSBlc3NlbnRpYWwgdGhhdCBhdXRob3JpemF0aW9u IGhhcHBlbnMgd2l0aCBubyBmb3JtIG9mIGF1dGhlbnRpY2F0aW9uIHdoYXRzb2V2ZXIuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW4gdGhlIElUIHdvcmxkLCBpdOKA mXMgcXVpdGUgdGhlIHNhbWUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QW4gYXBwbGljYXRpb24gY291bGQg YWNjZXNzIGEgc2VydmljZSBieSBkaXNwbGF5aW5nIHNvbWUgc29ydCBvZiBjcmVkZW50aWFsLCB3 aGlsZSBuZXZlciBhdXRoZW50aWNhdGluZyBpdHNlbGYuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBiZWxp ZXZlIHRoYXQgT0F1dGgsIGZvciBleGFtcGxlLCBkb2VzIHByb3ZpZGUgdGhhdCBzb3J0IG9mIG1l Y2hhbmlzbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ob3csIG9m IGNvdXJzZSB0aGVyZSBpcyB2YWx1ZSBpbiBhdXRoZW50aWNhdGlvbiBhcyB3ZWxsLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJ1dCBJIHdvdWxkIHRoaW5rIHRoYXQg dG8gc2F5IHRoYXQgYXV0aG9yaXphdGlvbiByZXF1aXJlcyBhdXRoZW50aWNhdGlvbiBpcyBwbGFp bmx5IHdyb25nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkp1c3Qg bXkgdHdvIGNlbnRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk5p Y29sYXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48Yj48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzY1NjU2NTttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+Tmljb2xhcyBEQU1PVVImbmJz cDs6OiZuYnNwO1NlbmlvciBNYW5hZ2VyLCBCdXNpbmVzcyBhbmQgSW5ub3ZhdGlvbiBEZXZlbG9w bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0 ZXh0LWF1dG9zcGFjZTpub25lJz48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0UzM0EyRjttc28t ZmFyZWFzdC1sYW5ndWFnZTpGUic+U0lFUlJBIFdJUkVMRVNTJm5ic3A7OjombmJzcDtDVE8gT2Zm aWNlPG86cD48L286cD48L3NwYW4+PC9iPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3Rl eHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojRTMzQTJGO21zby1mYXJl YXN0LWxhbmd1YWdlOkZSJz5QaG9uZSA8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NTY1 NjU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPiszMyAoMCkgNjcwIDcwNiAwMDM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25l Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiM2NTY1NjU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPkxha2UgUGFyayAt IFpBQyBkZSBsJ0hlcnMgLSBBbGzDqWUgZHUgTGFjIC0gQlAgODcyMTYgOjogMzE2NzIgTGFiw6hn ZSBDZWRleCA6OiBGcmFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0U0M0Iz MDttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+PGEgaHJlZj0ibWFpbHRvOm5kYW1vdXJAc2llcnJh d2lyZWxlc3MuY29tIj48c3BhbiBsYW5nPUZSPm5kYW1vdXJAc2llcnJhd2lyZWxlc3MuY29tPC9z cGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojRTQzQjMwO21zby1mYXJlYXN0LWxhbmd1YWdlOkZS Jz4gOjogPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojRTQzQjMwO21zby1mYXJlYXN0LWxh bmd1YWdlOkZSJz48YSBocmVmPSJodHRwOi8vd3d3LnNpZXJyYXdpcmVsZXNzLmNvbS8iPjxzcGFu IGxhbmc9RlI+d3d3LnNpZXJyYXdpcmVsZXNzLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0U0M0IzMDttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFz cz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkRlJm5ic3A7Ojwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnXSA8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBMaWtlcGVuZzxicj48Yj5FbnZvecOpJm5ic3A7 OjwvYj4gbWFyZGkgMjYgbm92ZW1icmUgMjAxMyAwMjoxOTxicj48Yj7DgCZuYnNwOzo8L2I+IEJl cnQgR3JlZXZlbmJvc2NoOyBSZW5lIFN0cnVpazsgTHVkd2lnIFNlaXR6OyBjb3JlQGlldGYub3Jn PGJyPjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtjb3JlXSBTZWN1cml0eSB1c2UgY2FzZXMgZm9y IENvUkU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6d2luZG93dGV4dCc+Jmd0O2F1dGhlbnRpY2F0aW9uIGlzIGVzc2VudGlhbCBmb3Ig YXV0aG9yaXphdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3Rl eHQnPisxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiZn dDt3ZSBhaW0gdG8gZ2V0IHRoaXMgZHJhZnQgYWNjZXB0ZWQgYXMgKGluZm9ybWF0aW9uYWwpIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQgYXQgc29tZSBwb2ludC48L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5JIGJlbGlldmUgYSBzZXBhcmF0ZSBXRyBpcyBtb3Jl IGFwcHJvcHJpYXRlIGZvciB0aGlzIGl0ZW0sIHNpbmNlIHdlIGhhdmUgYSBsb3Qgb2Ygc2VjdXJp dHkgaXNzdWVzIGFuZCB3ZSByZWFsbHkgbmVlZCB0aGUgaGVscCBmcm9tIHNlY3VyaXR5IGFyZWEg ZXhwZXJ0cyBhbmQgd2UgbmVlZCBtb3JlIG5ldyBlbmVyZ2llcyBmb3IgdGhpcyBhcmVhLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOndpbmRvd3RleHQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPlRoYW5rcyw8L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjp3aW5kb3d0ZXh0Jz5LaW5kIFJlZ2FyZHM8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5LZXBlbmcgPC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPVpILUNOIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjp3aW5kb3d0ZXh0 Jz7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQnPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOndpbmRvd3RleHQnPiBjb3JlIFs8YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gPC9zcGFuPjxiPjxz cGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu O2NvbG9yOndpbmRvd3RleHQnPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQn PkJlcnQgR3JlZXZlbmJvc2NoPGJyPjwvc3Bhbj48Yj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjp3aW5kb3d0ZXh0Jz7lj5Hp gIHml7bpl7Q8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQnPjo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu O2NvbG9yOndpbmRvd3RleHQnPiAyMDEzPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQnPuW5tDwv c3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlNpbVN1bjtjb2xvcjp3aW5kb3d0ZXh0Jz4xMTwvc3Bhbj48c3BhbiBsYW5nPVpILUNOIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjp3aW5kb3d0ZXh0Jz7m nIg8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTaW1TdW47Y29sb3I6d2luZG93dGV4dCc+MjY8L3NwYW4+PHNwYW4gbGFuZz1aSC1DTiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6d2luZG93dGV4 dCc+5pelPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQnPiA4OjMxPGJyPjwvc3Bhbj48Yj48c3Bh biBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtj b2xvcjp3aW5kb3d0ZXh0Jz7mlLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3Rl eHQnPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQnPiBSZW5lIFN0cnVpazsgTHVkd2ln IFNlaXR6OyA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT48 YnI+PC9zcGFuPjxiPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQnPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47 Y29sb3I6d2luZG93dGV4dCc+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6d2luZG93dGV4dCc+IFJlOiBb Y29yZV0gU2VjdXJpdHkgdXNlIGNhc2VzIGZvciBDb1JFPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6d2luZG93dGV4dCc+KzEsIGF1dGhlbnRpY2F0aW9uIGlzIGVzc2VudGlhbCBmb3Ig YXV0aG9yaXNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2lu ZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3Rl eHQnPiBjb3JlIFs8YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5SZW5lIFN0cnVp azxicj48Yj5TZW50OjwvYj4gMjUgTm92ZW1iZXIgMjAxMyAyMToyMDxicj48Yj5Ubzo8L2I+IEx1 ZHdpZyBTZWl0ejsgPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8 L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIFNlY3VyaXR5IHVzZSBjYXNlcyBmb3Ig Q29SRTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5IaSBMdWR3aWc6PGJyPjxicj5BdXRob3JpemF0 aW9uIGNhbiBvbmx5IGJlIGVuZm9yY2VkIHZpYSBwcm9wZXIgYXV0aGVudGljYXRpb24gbWVjaGFu aXNtcywgc28gSSBkbyBleHBlY3QgYW55IGRlc2NyaXB0aW9uIG9mIHRoZSBmb3JtZXIgdG8gcmVm ZXIgdG8gdGhlIGxhdHRlci48YnI+PGJyPlJlbmU8YnI+PGJyPk9uIDExLzI1LzIwMTMgNjoyOCBB TSwgTHVkd2lnIFNlaXR6IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2tx dW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLVVT PkhlbGxvLCA8YnI+PGJyPjxicj5hcyB0aG9zZSBvZiB5b3Ugd2hvIGF0dGVuZGVkIElFVEY4OCBt aWdodCByZW1lbWJlciwgSSBhbSB3b3JraW5nIG9uIGEgZHJhZnQgb24gQ29SRSBzZWN1cml0eSB1 c2UgY2FzZXMgWzFdIHdpdGggYSBncm91cCBvZiBpbnRlcmVzdGVkIHBlb3BsZSBmcm9tIHRoaXMg V0cuIDxicj48YnI+VGhlIGN1cnJlbnQgc3RydWN0dXJlIG9mIHRoZSBkcmFmdCBjb250YWlucyB1 c2VjYXNlcyBmb3IgZ2VuZXJhbCBjb21tdW5pY2F0aW9uIHNlY3VyaXR5LCBEb1MgcHJldmVudGlv biwgYXV0aGVudGljYXRpb24gYXMgd2VsbCBhcyBhdXRob3JpemF0aW9uLiA8YnI+PGJyPkluIGFu IG9mZmxpbmUgZGlzY3Vzc2lvbiBpdCBoYXMgYmVlbiBzdWdnZXN0ZWQgdGhhdCB0aGUgdXNlIGNh c2VzIGZvciBjb21tU2VjIGFuZCBhdXRoZW50aWNhdGlvbiBhcmUgd2VsbCB1bmRlcnN0b29kIGJ5 IENvUkUgYW5kIG1vc3RseSBjb3ZlcmVkIGJ5IHRoZSB3b3JrIG9mIERJQ0UuIEl0IHdhcyB0aGVy ZWZvcmUgc3VnZ2VzdGVkIHRvIGZvY3VzIG9uIGF1dGhvcml6YXRpb24gdXNlIGNhc2VzLiA8YnI+ PGJyPkknZCBsaWtlIHRvIHNvbGljaXQgdGhlIG9waW5pb24gb2YgdGhlIFdHIG9uIHRoaXMgbWF0 dGVyLCBlc3BlY2lhbGx5IHNpbmNlIHdlIGFpbSB0byBnZXQgdGhpcyBkcmFmdCBhY2NlcHRlZCBh cyAoaW5mb3JtYXRpb25hbCkgd29ya2luZyBncm91cCBkb2N1bWVudCBhdCBzb21lIHBvaW50LiA8 YnI+PGJyPjxicj50bDtkciA6IFNob3VsZCBbMV0gYmUgYWJvdXQgYXV0aG9yaXphdGlvbiB1c2Ug Y2FzZXMgb25seT8gPGJyPjxicj48YnI+UmVnYXJkcywgPGJyPjxicj5MdWR3aWcgU2VpdHogPGJy Pjxicj5bMV0gZHJhZnQtc2VpdHotY29yZS1zZWMtdXNlY2FzZXMtMDAgPGJyPjxicj48YnI+PGJy Pjxicj48L3NwYW4+PG86cD48L286cD48L3A+PHByZT48c3BhbiBsYW5nPUVOLVVTPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLVVTPmNvcmUgbWFpbGluZyBsaXN0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLVVTPjxhIGhyZWY9Im1haWx0bzpjb3JlQGll dGYub3JnIj5jb3JlQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PHNw YW4gbGFuZz1FTi1VUz48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvYT48 L3NwYW4+PG86cD48L286cD48L3ByZT48L2Jsb2NrcXVvdGU+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1VUz48YnI+PGJyPjxicj48 L3NwYW4+PG86cD48L286cD48L3A+PHByZT48c3BhbiBsYW5nPUVOLVVTPi0tIDwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1VUz5lbWFpbDogPGEgaHJlZj0ibWFpbHRv OnJzdHJ1aWsuZXh0QGdtYWlsLmNvbSI+cnN0cnVpay5leHRAZ21haWwuY29tPC9hPiB8IFNreXBl OiByc3RydWlrPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLVVTPmNl bGw6ICsxICg2NDcpIDg2Ny01NjU4IHwgVVM6ICsxICg0MTUpIDY5MC03MzYzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_9287D1909D3EEA4E92505D48604887E9EA273A6069carmdexchmb01_-- From ludwig@sics.se Tue Nov 26 02:26:46 2013 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 3374E1ADFDA for ; Tue, 26 Nov 2013 02:26:46 -0800 (PST) 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_SE=0.35, RP_MATCHES_RCVD=-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 LDntpH6TYysy for ; Tue, 26 Nov 2013 02:26:44 -0800 (PST) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id B925E1AD67B for ; Tue, 26 Nov 2013 02:26:43 -0800 (PST) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id rAQA0nNV016007 for ; Tue, 26 Nov 2013 11:26:42 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1g7as9y23a-1 for ; Tue, 26 Nov 2013 11:26:42 +0100 Received: from [192.168.0.103] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 5E420400E2 for ; Tue, 26 Nov 2013 11:26:42 +0100 (CET) Message-ID: <52947762.7040604@sics.se> Date: Tue, 26 Nov 2013 11:26:42 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: core@ietf.org References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> In-Reply-To: <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090809010800080306080706" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-26_04:2013-11-26,2013-11-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311260023 Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 10:26:46 -0000 This is a cryptographically signed message in MIME format. --------------ms090809010800080306080706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/26/2013 10:50 AM, Nicolas Damour wrote: > Hello. > > I may be swimming against the current here, so I=92m sorry to be a litt= le > iconoclast here (and if I am wrong, please accept my apologies in advan= ce). > > I would say that from a strict theoretical point of view, authorization= > does _absolutely not_ require authentication. > > A very simple example in the physical world is access to a safe in some= > (possibly Swiss) banks. > > As long as you have the key (or passcode), you can get access to the sa= fe. > > And no one will ever ask you for your identity. > > As a matter of fact, in some of these cases it is absolutely essential > that authorization happens with no form of authentication whatsoever. > > In the IT world, it=92s quite the same. > > An application could access a service by displaying some sort of > credential, while never authenticating itself. > > I believe that OAuth, for example, does provide that sort of mechanism.= > > Now, of course there is value in authentication as well. > > But I would think that to say that authorization requires authenticatio= n > is plainly wrong. > > Just my two cents, > > Nicolas. > > You are not really swimming against the current, I recall making a very=20 similar remark to Rene during IETF88. However even for anonymous authorization there needs to be some binding=20 between the authorization and the subject exercising it. It might be=20 something as simple as possession of an authZ token (with all the=20 negative security implications) or something as complicated as a=20 pseudonym with linked public key and a trusted third party as an=20 identity escrow agent to prevent abuses. My stance is that there is a relevant number of use cases where=20 authentication is required in order to perform meaningful authorization=20 and some use cases where anonymous authorization is needed. tl;dr: Sometimes we need authN for authZ. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms090809010800080306080706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwW1izANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDExNTAyMDUwNloXDTE0MDExNTE0Mzc0OFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqm5Fq+vazAJCxhLsrE6yZ4Fcjf22HECMhhoH QAVWMuk61UnFAxiiKnsGb2iRrw9fFD2ZZP+VVKiojuMaNzlnyrULh84UwJhmkm6Ab2olLQ4x XZqNDvFe7djMtMMgqD8Erf35WuK8mrRjqHPX/imDEw4Ub6XvL5+rnhBKQozCm5FoIHOcol5H EbAO+F4XZA3pgQFyUWpWGlyIMZ3na9fkCBspupWZ68ytytxgB0poqbqJMSZtge6bkP/gZo6e dnbAydjkSkqHHGbpKzMJVI12TyJlJTN70Zg/OF4EMgcwN0tmJvrNqhH3oXlkKkTWk94ojP8M J3eQv6del7mB1tJcuwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAO/qDJzu5Icr9AFUhmI3z qGMpbjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBADhtqCPIvc8t6La1swQso5U7FF3Is5txWrQWPzcttJMyPo1LzdNT/jHEKF93 nOqiKm50NISmDFkBSxKOTTYPFJ4thgFcTZf+K57ucvxL/c+MLj3PlmCMNmtciCa8gxpldYz4 aob7CT02KQZvX+yGUmOTdHkoLd9FaxRq0ei43EAxjGIsU7vliaAoKCSO0pRsdtSrOYNV3fSd ZB6xd8KBjAJsC8P/Q2BfeMT5+fJPvX5pfj8h+qyGkJCPx2RHhkf5tSIrnOAoYkvrUZFk1JJx H+v1KrX2QRCu3fx7L9D3S1QNSCD3d3nDcM2sXdtGg6/KynBtw31O4YqQWgU9XQp+NoYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwW1izAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzExMjYxMDI2NDJaMCMGCSqGSIb3DQEJBDEW BBST0vxTGp6n1HjRUxt9wvPd1ytt9jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFtYswDQYJKoZIhvcNAQEBBQAE ggEAl5PME5BvV6S1dlXod4TC0uftIaKCZxzrc828fvi/6t4dyvqsQUJUh8kb+1hqhFVOC76d yrPsuOca/kYnKBtYsM3tN56PL2EJgRBzmiRDLZm2wMPaNUH0qLpIXzYeIVBBzH1c11EPhzm0 Hl7Vl1oKBYQmD3VTwOOPI0LY6u4N3pH30wjssUIWetlUNnLHeFzRuv6TWP9aoPX7nywhFk2M 7Lnx9p4x5NB1Ew+uZKYKXGTOLT0EuhMK7X9bTjeGtBkaTde83XpkX2FfNlTtiaXWOIaCnNiK 4akqHOTZXLaH9+ExLWrivn1bUKE42fNXYUe7VwgqIqAr0ODLUuZdQKCv6gAAAAAAAA== --------------ms090809010800080306080706-- From ietf@sandeep.de Tue Nov 26 03:06:43 2013 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 263C31A1F64 for ; Tue, 26 Nov 2013 03:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] 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 j_y_nLUuzAig for ; Tue, 26 Nov 2013 03:06:40 -0800 (PST) Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBB21AD7C1 for ; Tue, 26 Nov 2013 03:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1385463999; l=23392; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version:X-RZG-CLASS-ID:X-RZG-AUTH; bh=OcNk+Kj0UxQXujSJQU8HebEnYac=; b=XdIdNX/u7fLXf84QhOvAqiThTYPkv4rWvwJl/Wz9eWtzfu7AuDdQBPLDrAQJ+TLFuxr CDj7mOl2eEiPjJTeODTeOi2Tm7KfXPn9hpbvKtFwDlLja2iVOFd+a/N6xF8PwDrZqa+9X NU01z30+p6CX7Br+LPd6eIgyTYU/rSLWrXQ= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQSEYQdmVg= X-RZG-CLASS-ID: mo00 Received: from mail-bk0-f54.google.com ([209.85.214.54]) by smtp.strato.de (RZmta 32.16 AUTH) with (TLSv1.0:DHE-RSA-AES256-SHA encrypted) ESMTPSA id m05004pAQB6ayVE for ; Tue, 26 Nov 2013 12:06:36 +0100 (CET) Received: by mail-bk0-f54.google.com with SMTP id v16so2476791bkz.41 for ; Tue, 26 Nov 2013 03:06:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OYmIhTmUmiBIaOIGAbV3muhbB30mE6fzVX7wbv9ByKI=; b=CK9hZsZ9XUQzY1urWHKa5LZhOvkE8mA1euKsLdCKlTh/g+DsP7JOh/VxRYwFpDnSmp mgsdXKNOoEXzhFKhd3+Z3ADchaFzUKwqPQNzRSGQW33zCurZPKCCRBDJwjLuBNnN6jhX UuIrNqKnv2CuUycl+Y+hcRTK14cxtKzG2Pba/9l0ORXITR/vUvTzQARXalrD9dyqBQsJ Egirm0UuAXGrYqBuhtt2gSjlgV+FRsSQ+xq9S3uD4aDtKn9xznfgbZdpeKopmOP92FSi Zp9W2pjlen5sL70juONy0bo43u62pmAO0vno20zH82EGi1BcWgWbiV30dz+IhYf7ZoQF 9xmA== MIME-Version: 1.0 X-Received: by 10.205.76.133 with SMTP id ze5mr5013483bkb.37.1385463996292; Tue, 26 Nov 2013 03:06:36 -0800 (PST) Received: by 10.205.38.11 with HTTP; Tue, 26 Nov 2013 03:06:36 -0800 (PST) In-Reply-To: <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> Date: Tue, 26 Nov 2013 12:06:36 +0100 Message-ID: From: Sandeep Kumar To: Nicolas Damour Content-Type: multipart/alternative; boundary=f46d041555ec59760804ec1279d5 Cc: "core@ietf.org" Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 11:06:43 -0000 --f46d041555ec59760804ec1279d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 However the question is if we know of any IoT scenario that requires anonymous credentials? regards Sandeep On Tue, Nov 26, 2013 at 10:50 AM, Nicolas Damour wrote: > Hello. > > > > I may be swimming against the current here, so I=E2=80=99m sorry to be a = little > iconoclast here (and if I am wrong, please accept my apologies in advance= ). > > I would say that from a strict theoretical point of view, authorization > does *absolutely not* require authentication. > > > > A very simple example in the physical world is access to a safe in some > (possibly Swiss) banks. > > As long as you have the key (or passcode), you can get access to the safe= . > > And no one will ever ask you for your identity. > > As a matter of fact, in some of these cases it is absolutely essential > that authorization happens with no form of authentication whatsoever. > > > > In the IT world, it=E2=80=99s quite the same. > > An application could access a service by displaying some sort of > credential, while never authenticating itself. > > I believe that OAuth, for example, does provide that sort of mechanism. > > > > Now, of course there is value in authentication as well. > > > > But I would think that to say that authorization requires authentication > is plainly wrong. > > > > Just my two cents, > > > > Nicolas. > > > > > > > > *Nicolas DAMOUR :: Senior Manager, Business and Innovation Development* > > *SIERRA WIRELESS :: CTO Office* > > Phone +33 (0) 670 706 003 > > Lake Park - ZAC de l'Hers - All=C3=A9e du Lac - BP 87216 :: 31672 Lab=C3= =A8ge Cedex > :: France > > ndamour@sierrawireless.com :: www.sierrawireless.com > > > > *De :* core [mailto:core-bounces@ietf.org] *De la part de* Likepeng > *Envoy=C3=A9 :* mardi 26 novembre 2013 02:19 > *=C3=80 :* Bert Greevenbosch; Rene Struik; Ludwig Seitz; core@ietf.org > *Objet :* Re: [core] Security use cases for CoRE > > > > >authentication is essential for authorization > > > > +1. > > > > >we aim to get this draft accepted as (informational) working group > document at some point. > > > > I believe a separate WG is more appropriate for this item, since we have = a > lot of security issues and we really need the help from security area > experts and we need more new energies for this area. > > > > Thanks, > > Kind Regards > > Kepeng > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* core [mailto:core-bounces@ietf.org ] *=E4=BB=A3=E8=A1=A8 *Bert > Greevenbosch > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4**:* 2013=E5=B9=B411=E6=9C=8826=E6= =97=A5 8:31 > *=E6=94=B6=E4=BB=B6=E4=BA=BA**:* Rene Struik; Ludwig Seitz; core@ietf.org > *=E4=B8=BB=E9=A2=98**:* Re: [core] Security use cases for CoRE > > > > +1, authentication is essential for authorisation. > > > > *From:* core [mailto:core-bounces@ietf.org ] *On > Behalf Of *Rene Struik > *Sent:* 25 November 2013 21:20 > *To:* Ludwig Seitz; core@ietf.org > *Subject:* Re: [core] Security use cases for CoRE > > > > Hi Ludwig: > > Authorization can only be enforced via proper authentication mechanisms, > so I do expect any description of the former to refer to the latter. > > Rene > > On 11/25/2013 6:28 AM, Ludwig Seitz wrote: > > Hello, > > > as those of you who attended IETF88 might remember, I am working on a > draft on CoRE security use cases [1] with a group of interested people fr= om > this WG. > > The current structure of the draft contains usecases for general > communication security, DoS prevention, authentication as well as > authorization. > > In an offline discussion it has been suggested that the use cases for > commSec and authentication are well understood by CoRE and mostly covered > by the work of DICE. It was therefore suggested to focus on authorization > use cases. > > I'd like to solicit the opinion of the WG on this matter, especially sinc= e > we aim to get this draft accepted as (informational) working group docume= nt > at some point. > > > tl;dr : Should [1] be about authorization use cases only? > > > Regards, > > Ludwig Seitz > > [1] draft-seitz-core-sec-usecases-00 > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > > -- > > email: rstruik.ext@gmail.com | Skype: rstruik > > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --f46d041555ec59760804ec1279d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

However the question is if we kn= ow of any IoT scenario that requires anonymous credentials?

re= gards
Sandeep
 --f46d041555ec59760804ec1279d5-- From esko.dijk@philips.com Tue Nov 26 05:37:42 2013 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 9DA2C1AE1CA for ; Tue, 26 Nov 2013 05:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNRESOLVED_TEMPLATE=1.252] 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 V7ruDq7rmb99 for ; Tue, 26 Nov 2013 05:37:40 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id D86FB1AD79D for ; Tue, 26 Nov 2013 05:37:38 -0800 (PST) Received: from mail217-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Tue, 26 Nov 2013 13:37:38 +0000 Received: from mail217-ch1 (localhost [127.0.0.1]) by mail217-ch1-R.bigfish.com (Postfix) with ESMTP id 3CBAE1A03D2; Tue, 26 Nov 2013 13:37:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -46 X-BigFish: VPS-46(zz217bI98dI15d6O9371IfcbW1521I542I1432I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh1de097h18602ehz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h1155h) Received: from mail217-ch1 (localhost.localdomain [127.0.0.1]) by mail217-ch1 (MessageSwitch) id 1385473056103162_8275; Tue, 26 Nov 2013 13:37:36 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail217-ch1.bigfish.com (Postfix) with ESMTP id 11B7C1E005C; Tue, 26 Nov 2013 13:37:36 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 26 Nov 2013 13:37:35 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.03.0158.002; Tue, 26 Nov 2013 13:37:33 +0000 From: "Dijk, Esko" To: Zach Shelby Thread-Topic: Sleepy devices: OMA lightweight queue mode for CoAP Thread-Index: Ac7eupK1vkBEFzF3SDuPgMOcHEH12wB3d1YAAoTV/kA= Date: Tue, 26 Nov 2013 13:37:33 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC40DF1@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180CC2895D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <8AD83A72-6EE4-4C77-A084-BAD5C5C87989@arm.com> In-Reply-To: <8AD83A72-6EE4-4C77-A084-BAD5C5C87989@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org" Subject: Re: [core] Sleepy devices: OMA lightweight queue mode for 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: Tue, 26 Nov 2013 13:37:42 -0000 > in other cases it might be an HTTP reverse proxy. Considering this case, wouldn't the HTTP request usually time out? The 'SICEP' may typically wake up once a day and the HTTP connection would = be dropped long before that. (A few minutes typically?) I'm therefore wondering whether this request caching is suitable for the ge= neral case (where the requesting client is not integrated into the proxy no= de itself) Esko -----Original Message----- From: Zach Shelby [mailto:Zach.Shelby@arm.com] Sent: Wednesday, November 13, 2013 18:48 To: Dijk, Esko Cc: core@ietf.org; Rahman, Akbar Subject: Re: Sleepy devices: OMA lightweight queue mode for CoAP Esko, Only the what you might call the SICEP-PROXY interface is within scope of t= he OMA specification. How the client interacts with the proxy is out of sco= pe. In the device management space the proxy often times is the application= , in other cases it might be an HTTP reverse proxy. The only timings discussed in the OMA spec are the CoAP timeouts used to ti= me how long the SICEP can be assumed to be awake after sending a registrati= on update. I would prefer to document only the SICEP-PROXY interface, really that is t= he only part in scope of the resource directory specification anyways. Zach On Nov 11, 2013, at 1:21 AM, "Dijk, Esko" wrote: >> In the OMA Lightweight standard, the mechanism that uses CoAP to >> solve this problem was just called a "queue mode". This is in >> practice realised with a Proxy and an RD in the same box. An RD >> registration parameter is used to indicate that a node is in queue mode.= From there on the proxy queues all incoming requests to the node, which ar= e released upon reception of a registration update request from the node. I= f the WG wants, this could fairly easily be documented in the Resource Dire= ctory draft maintaining compatibility with OMA Lightweight. > > In this solution, does the Proxy queue a CoAP request for an arbitrary > time period? I assume it works as follows > > 1- the CoAP client that needs to reach the > sleepy/intermittent-connectivity endpoint (SICEP) sends a CON request > to Proxy, containing the Proxy-Uri or Proxy-Scheme option > 2- Proxy ACKs the CON message and puts the request in queue > 3- SICEP wakes up, updates its registration on Proxy > 4- Proxy sends queued request (CON) to SICEP > (- optional: if request fails to be delivered to SICEP it is re-queued > for next time; then move back to step 3) > 5- Proxy receives CoAP response from SICEP > 6- Proxy delivers response to the CoAP client (using CON) > > From core-coap I understand there is no inherent limit to the time betwee= n a CoAP request and its response. E.g. it may be 24 hours in above example= . > I wonder if current implementations of core-coap allow this, or are teste= d on this aspect. > > One benefit of this solution (if I see it right) is that there is no reso= urce delegation/buffering needed at all. A drawback is that the SICEP needs= to acts as CoAP server as well as CoAP client, while some other solutions = require only CoAP-client functionality in the SICEP. Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 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, Registered in England & Wales,= Company No: 2548782 ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From gerdes@tzi.de Tue Nov 26 06:01:46 2013 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 AA3031AE206 for ; Tue, 26 Nov 2013 06:01:46 -0800 (PST) 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 Kl9Vx6Gef4Qs for ; Tue, 26 Nov 2013 06:01:45 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4EE1AE20B for ; Tue, 26 Nov 2013 06:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAQE1hcx005652 for ; Tue, 26 Nov 2013 15:01:43 +0100 (CET) Received: from [134.102.117.21] (unknown [134.102.117.21]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3BC4C593 for ; Tue, 26 Nov 2013 15:01:43 +0100 (CET) Message-ID: <5294A9C6.4090201@tzi.de> Date: Tue, 26 Nov 2013 15:01:42 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: core@ietf.org References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> In-Reply-To: <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 14:01:46 -0000 Hi, On 11/26/2013 10:50 AM, Nicolas Damour wrote: > Hello. > > I may be swimming against the current here, so I’m sorry to be a little iconoclast here (and if I am wrong, please accept my apologies in advance). > I would say that from a strict theoretical point of view, authorization does absolutely not require authentication. > > A very simple example in the physical world is access to a safe in some (possibly Swiss) banks. > As long as you have the key (or passcode), you can get access to the safe. > And no one will ever ask you for your identity. > As a matter of fact, in some of these cases it is absolutely essential that authorization happens with no form of authentication whatsoever. I think your bank example is still authentication. The definition in RFC 4949 states that authentication is "The process of verifying a claim that a system entity or system resource has a certain attribute value." This means that you are not necessarily verifying the identity of a subject but verify a certain attribute of the subject, e.g. if it has a certain key. If we want to distinguish entities and give different access rights to different entities we will always need authentication. Without authentication we can only grant the same access rights to every entity. Best regards, Steffi From esko.dijk@philips.com Tue Nov 26 06:14:11 2013 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 63AE31AE205 for ; Tue, 26 Nov 2013 06:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 2ZgrGemHm2P8 for ; Tue, 26 Nov 2013 06:14:09 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id E8D581ADAEA for ; Tue, 26 Nov 2013 06:14:08 -0800 (PST) Received: from mail200-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.22; Tue, 26 Nov 2013 14:14:08 +0000 Received: from mail200-co1 (localhost [127.0.0.1]) by mail200-co1-R.bigfish.com (Postfix) with ESMTP id 69EECE0CC0 for ; Tue, 26 Nov 2013 14:14:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -11 X-BigFish: VPS-11(zz217bI15d6Oc85fh3166M9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275bh18c673h1de097h186068hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h1155h) Received: from mail200-co1 (localhost.localdomain [127.0.0.1]) by mail200-co1 (MessageSwitch) id 1385475246429765_12555; Tue, 26 Nov 2013 14:14:06 +0000 (UTC) Received: from CO1EHSMHS006.bigfish.com (unknown [10.243.78.247]) by mail200-co1.bigfish.com (Postfix) with ESMTP id 5BD5D800059 for ; Tue, 26 Nov 2013 14:14:06 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS006.bigfish.com (10.243.66.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 26 Nov 2013 14:14:06 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-003.MGDPHG.emi.philips.com ([10.128.28.53]) with mapi id 14.03.0158.002; Tue, 26 Nov 2013 14:13:58 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: CoAP 'infinite timeout' use case Thread-Index: Ac7qsAOxXW3ZPYkKRdGb4l5oB/zS2w== Date: Tue, 26 Nov 2013 14:13:58 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.109] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180CC40E34011DB3MPN2082MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [core] CoAP 'infinite timeout' use case 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, 26 Nov 2013 14:14:11 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180CC40E34011DB3MPN2082MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, This is triggered by my previous message on sleepy nodes. Does anyone know what could (should) be expected from a CoAP client impleme= ntation in the following use case: - Client C sends a CON request to server S; - S sends empty ACK to C - S starts processing to produce the request; - C receives ACK - S 'dies' (e.g. power failure, reset, crash...) before finalizing= the response creation - C waits for a long time (and keeps waiting, the response never a= rrives - there is no CoAP standard timeout mechanism activated in this case= ) Is there some sort of timeout behaviour expected of C? Or any interoperabil= ity guidelines on that? (I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 only a= ddress timeouts of "a couple of seconds") Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED6180CC40E34011DB3MPN2082MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

This is triggered by my previous message on sleepy n= odes.

Does anyone know what could (should) be expected fro= m a CoAP client implementation in the following use case:

 

-   =        Client C sends a CON request to server S;

-   =        S sends empty ACK to C

-   =        S starts processing to produce the request;

-   =        C receives ACK

-   =        S ‘dies’ (e.g. power failure, reset, crash...) be= fore finalizing the response creation

-   =        C waits for a long time (and keeps waiting, the response neve= r arrives – there is no CoAP standard timeout mechanism activated in = this case)

 

Is there some sort of timeout behaviour expected of = C? Or any interoperability guidelines on that?

(I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 only address timeouts of “a coup= le of seconds”)

 

Esko

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED6180CC40E34011DB3MPN2082MG_-- From cabo@tzi.org Tue Nov 26 07:44:37 2013 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 179471AC4C1 for ; Tue, 26 Nov 2013 07:44:37 -0800 (PST) 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 XWvQUer5mmSG for ; Tue, 26 Nov 2013 07:44:36 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CF5E51AD72A for ; Tue, 26 Nov 2013 07:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAQFiXnC001680; Tue, 26 Nov 2013 16:44:33 +0100 (CET) Received: from [134.102.116.75] (unknown [134.102.116.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5981D68D; Tue, 26 Nov 2013 16:44:33 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Tue, 26 Nov 2013 16:44:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> References: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1822) Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP 'infinite timeout' use case 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, 26 Nov 2013 15:44:37 -0000 One general rule in CoAP is that timeouts are on the message layer, not = on the request/response layer. Most likely, there will still be a limit to the time in which the = response is useful to the client. E.g., in the HTTP world, many clients give up after ~ 60 seconds (even = if the TCP connection below HTTP has longer timeouts). But there is nothing in the HTTP spec that describes these timeouts. I find it quite logical that CoAP hasn=92t anything here either. But maybe the analogy is not quite right, I=92d like to hear about that. (Klaus has a draft that would allow a client to even cancel an = outstanding request, draft-hartke-core-coap-liveliness.) Gr=FC=DFe, Carsten PS.: > (I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 = only address timeouts of =93a couple of seconds=94) What specific test are are you referring here? We didn=92t test any client timeout for separate responses. From esko.dijk@philips.com Tue Nov 26 08:03:53 2013 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 A1F621AC85E for ; Tue, 26 Nov 2013 08:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 hrsQgBX2jMlj for ; Tue, 26 Nov 2013 08:03:51 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id A902F1AD8F2 for ; Tue, 26 Nov 2013 08:03:51 -0800 (PST) Received: from mail135-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.22; Tue, 26 Nov 2013 16:03:51 +0000 Received: from mail135-va3 (localhost [127.0.0.1]) by mail135-va3-R.bigfish.com (Postfix) with ESMTP id 3D1DB3A01EE; Tue, 26 Nov 2013 16:03:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zz217bI15d6Oc89bh542I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh109h2a8h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h1155h) Received: from mail135-va3 (localhost.localdomain [127.0.0.1]) by mail135-va3 (MessageSwitch) id 1385481830177411_27416; Tue, 26 Nov 2013 16:03:50 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.235]) by mail135-va3.bigfish.com (Postfix) with ESMTP id 1C3C9480065; Tue, 26 Nov 2013 16:03:50 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 26 Nov 2013 16:03:44 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.03.0158.002; Tue, 26 Nov 2013 16:03:17 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] CoAP 'infinite timeout' use case Thread-Index: Ac7qsAOxXW3ZPYkKRdGb4l5oB/zS2wADmKEAAAAOGCA= Date: Tue, 26 Nov 2013 16:03:17 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> In-Reply-To: <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP 'infinite timeout' use case 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, 26 Nov 2013 16:03:53 -0000 Agree, I was somewhat expecting that CoAP would follow HTTP in this respect= . I did notice that for HTTP it is explicitly stated that no timeouts are nee= ded but that they may (MAY?) be present; http://tools.ietf.org/html/draft-i= etf-httpbis-p1-messaging-25#section-6.5 I think the CoAP spec could at least makes a similar remark; currently it's= not mentioned. For implementers it's perhaps useful at some point to know what methods / b= est practices to use to detect the 'server dead' case; similar to the case = for TCP of half-open connections and detection thereof where some approache= s are documented. I assume for now it is timer-based with a custom timeout = value, where the value must not be lower than MAX_LATENCY. > What specific test are are you referring here? > We didn't test any client timeout for separate responses. Oops, I didn't mean to say timeout here but time taken by the server for pr= ocessing the request. It mentions " Some time (a couple of seconds) elapses= ." in the base.html test specs. A similar case occurs when this "some time" is higher than the client's exp= ectation of "some time" so that's even an aspect that could be tested. (E.g= . use MAX_LATENCY instead of "couple of seconds"?) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday, November 26, 2013 16:45 To: Dijk, Esko Cc: core (core@ietf.org) Subject: Re: [core] CoAP 'infinite timeout' use case One general rule in CoAP is that timeouts are on the message layer, not on = the request/response layer. Most likely, there will still be a limit to the time in which the response = is useful to the client. E.g., in the HTTP world, many clients give up after ~ 60 seconds (even if t= he TCP connection below HTTP has longer timeouts). But there is nothing in the HTTP spec that describes these timeouts. I find it quite logical that CoAP hasn't anything here either. But maybe the analogy is not quite right, I'd like to hear about that. (Klaus has a draft that would allow a client to even cancel an outstanding = request, draft-hartke-core-coap-liveliness.) Gr=FC=DFe, Carsten PS.: > (I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 only= address timeouts of "a couple of seconds") What specific test are are you referring here? We didn't test any client timeout for separate responses. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From zach.shelby@arm.com Tue Nov 26 09:29:57 2013 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 3C2371ADF6C for ; Tue, 26 Nov 2013 09:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WrzEUjFqtIZ2 for ; Tue, 26 Nov 2013 09:29:56 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 822561ADF59 for ; Tue, 26 Nov 2013 09:29:55 -0800 (PST) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Tue, 26 Nov 2013 17:29:53 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw1.usa.Arm.com ([::1]) with mapi; Tue, 26 Nov 2013 09:29:49 -0800 From: Zach Shelby To: "Dijk, Esko" Date: Tue, 26 Nov 2013 09:29:49 -0800 Thread-Topic: Sleepy devices: OMA lightweight queue mode for CoAP Thread-Index: Ac7qzRuUMuN/RUP/QImOtWXvIMWOmQ== Message-ID: <2E04C2C9-4860-499E-9CF6-C419CBFD8B0A@arm.com> References: <031DD135F9160444ABBE3B0C36CED6180CC2895D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <8AD83A72-6EE4-4C77-A084-BAD5C5C87989@arm.com> <031DD135F9160444ABBE3B0C36CED6180CC40DF1@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC40DF1@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 113112617295318602 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org" Subject: Re: [core] Sleepy devices: OMA lightweight queue mode for 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: Tue, 26 Nov 2013 17:29:57 -0000 On Nov 26, 2013, at 5:37 AM, "Dijk, Esko" wrote: > The 'SICEP' may typically wake up once a day and the HTTP connection woul= d be dropped long before that. (A few minutes typically?) You would need to long-poll or use a callback of course. Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 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 barryleiba.mailing.lists@gmail.com Tue Nov 26 09:33:33 2013 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 2BE351ADF7C for ; Tue, 26 Nov 2013 09:33:33 -0800 (PST) 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 E5tPd8k1kpYV for ; Tue, 26 Nov 2013 09:33:32 -0800 (PST) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 200881ADF78 for ; Tue, 26 Nov 2013 09:33:32 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id x11so4110609vbb.34 for ; Tue, 26 Nov 2013 09:33:31 -0800 (PST) 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=ansPuv0xOclDMxhxA2qb+GX+pq4Ym5VtJ//O70m/JGg=; b=L5dcFI3kmrlz9HmZCR3qWh/VlH/0PHQeqhwMkajPiVCHaY1zCwbOKZ4t89kwH9TgpF gNGJ79HHhlgaoBR1nDHWOlP+Ov0daVls2W4SMayRcR+YK2QcV0APFzo9lmUuDp1nalFt L5j7/cq0i3nJgRzpCLt/Czp5f5cDG5YVrE8i4WNoSBX3hDiq5T3gkwYi/GBLJWFfnm5G /5BXRoQBP/5Z4DARHlXorMkSB533IwOUwi0zrR9NXjDjMw659RmenZFYwr6bSTH+9dZQ h/yYSz1RiJC+NR+IXmt2fTozS+PjTXCfP7jv1uA5lpE7kyYgUQsWf9bw5WvvVwnzmZpS IN5A== MIME-Version: 1.0 X-Received: by 10.52.118.98 with SMTP id kl2mr5401859vdb.30.1385487211858; Tue, 26 Nov 2013 09:33:31 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.170.71 with HTTP; Tue, 26 Nov 2013 09:33:31 -0800 (PST) In-Reply-To: <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> Date: Tue, 26 Nov 2013 12:33:31 -0500 X-Google-Sender-Auth: u0AUH-WftN2sW7V21oD_RzEqJkQ Message-ID: From: Barry Leiba To: Nicolas Damour Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org" Subject: Re: [core] Security use cases for CoRE 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, 26 Nov 2013 17:33:33 -0000 > I would say that from a strict theoretical point of view, authorization does > absolutely not require authentication. > > A very simple example in the physical world is access to a safe in some > (possibly Swiss) banks. > > As long as you have the key (or passcode), you can get access to the safe. > > And no one will ever ask you for your identity. > > As a matter of fact, in some of these cases it is absolutely essential that > authorization happens with no form of authentication whatsoever. As Stephanie says, this is still authentication: the key or passcode is the authentication credential/token. If you need this sort of use case, then you need to make sure the authentication options allow it. But you *are* authenticating. Barry From hartke@tzi.org Tue Nov 26 09:43:25 2013 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 BE55E1ADEBE for ; Tue, 26 Nov 2013 09:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 tzU4K-_RI2Ur for ; Tue, 26 Nov 2013 09:43:24 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4871AD694 for ; Tue, 26 Nov 2013 09:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAQHhFke029132 for ; Tue, 26 Nov 2013 18:43:15 +0100 (CET) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 51C0175C for ; Tue, 26 Nov 2013 18:43:15 +0100 (CET) Received: by mail-vb0-f48.google.com with SMTP id x16so4129515vbf.35 for ; Tue, 26 Nov 2013 09:43:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VB9xZEJbcqswlqD0Oae+QUTk2k36SARFD1nJOU4m4nk=; b=MuvqdmHCU90MdcqOD9U6OXyTXstJK8Au1rGYFzOIvWkh5PCthKGACEtlFkgQDF+kN6 rlp8c3kb6oRvxrA/K8RDeDngrAhrLRDBPAK1DJD5fiNdZg2CvwQ8mojyfRYHnNv0xcWJ LuXDFWIwpRVoM/TSh38Rvtm03HnpoVDMvADzd9lux4T04Rt+T3JA1h9h3GNTjpnEU1Iz +ajidZ6B2M91PxMo/DLnV89hUSUJBO/Xfb8eTx45yDGSjUVTgeWUaPQmbJMUKHg/r8Dh 4T8el6ND42Krh2uNUJNwv02Gq2fRx69t2TxFOGEEv+c8ge088MENGYjCZDZ+F65r/SHD 2hdg== X-Received: by 10.220.253.66 with SMTP id mz2mr32090856vcb.10.1385487793986; Tue, 26 Nov 2013 09:43:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.233.132 with HTTP; Tue, 26 Nov 2013 09:42:33 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> From: Klaus Hartke Date: Tue, 26 Nov 2013 19:42:33 +0200 Message-ID: To: "Dijk, Esko" Content-Type: text/plain; charset=ISO-8859-1 Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP 'infinite timeout' use case 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, 26 Nov 2013 17:43:25 -0000 Carsten Bormann wrote: > Most likely, there will still be a limit to the time in which the response is useful to the client. > E.g., in the HTTP world, many clients give up after ~ 60 seconds (even if the TCP connection below HTTP has longer timeouts). It's worth keeping in mind that there might also be intermediaries between the client and the origin server that may return a 5.04 (Gateway Timeout) response if they don't receive a response after some timeout determined by their local configuration. Esko Dijk wrote: > For implementers it's perhaps useful at some point to know what methods / best practices to use to detect the 'server dead' case; Currently there's only the "CoAP ping" that a client can send to determine if a server is running at a given IP address/port number. But that doesn't tell the client if it's the same server that the client sent its request to, or if the server still plans to send a response. For that you'd need something like . Best regards, Klaus From hartke@tzi.org Tue Nov 26 09:50:33 2013 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 3D8E31AE222 for ; Tue, 26 Nov 2013 09:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 A5P5ncegpqeC for ; Tue, 26 Nov 2013 09:50:32 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 03AEE1AE221 for ; Tue, 26 Nov 2013 09:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAQHoOY9014219 for ; Tue, 26 Nov 2013 18:50:24 +0100 (CET) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6020776B for ; Tue, 26 Nov 2013 18:50:24 +0100 (CET) Received: by mail-vb0-f45.google.com with SMTP id p14so4208632vbm.32 for ; Tue, 26 Nov 2013 09:50:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=g1Yy5ozRNi/I2TLoqy8kUOmR1OkxQd27pv33yFRXANQ=; b=h5Q6RPsW71JY/tPg6xTliPvUj60/4U5cn98G54g7otBzixTL/uHHbUsI29dLt7qVTU TvwyIm0RDRlhbibBvzmri9rP1XiI9pis8GG/G9QfCt95q+6y75C7qd2wLBV5a+8sysMi NeqjNS73W0D2L1q76kP6eUMvBvPOw9xkkTcqxaWHiq/AU+Wstpe4ai1FyjcGflhMRTf6 slPyfGYbsKz6fYYoqcRKNWQfknphw2wpfQ/UqpJx180tgU5j3M5gxgADVoXBrVfKx/op P90OytEbrBFmRxh9LRWFCmQqYrQZ8hNTVaYq9XYRSiaP8L06s6M0fFNBT2LA7wWyIV9V wbyQ== X-Received: by 10.52.233.100 with SMTP id tv4mr16903vdc.86.1385488223280; Tue, 26 Nov 2013 09:50:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.233.132 with HTTP; Tue, 26 Nov 2013 09:49:43 -0800 (PST) In-Reply-To: <2E04C2C9-4860-499E-9CF6-C419CBFD8B0A@arm.com> References: <031DD135F9160444ABBE3B0C36CED6180CC2895D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <8AD83A72-6EE4-4C77-A084-BAD5C5C87989@arm.com> <031DD135F9160444ABBE3B0C36CED6180CC40DF1@011-DB3MPN2-082.MGDPHG.emi.philips.com> <2E04C2C9-4860-499E-9CF6-C419CBFD8B0A@arm.com> From: Klaus Hartke Date: Tue, 26 Nov 2013 19:49:43 +0200 Message-ID: To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org" Subject: Re: [core] Sleepy devices: OMA lightweight queue mode for 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: Tue, 26 Nov 2013 17:50:33 -0000 Zach Shelby wrote: > Esko Dijk wrote: >> The 'SICEP' may typically wake up once a day and the HTTP connection would be dropped long before that. (A few minutes typically?) > > You would need to long-poll or use a callback of course. I'd expect a 2.xx (Accepted)* response here with Location options indicating a resource that the client can poll or observe to track the progress of the request. (*like HTTP 202 Accepted ; currently not defined in CoAP) Best regards, Klaus From likepeng@huawei.com Tue Nov 26 18:50:02 2013 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 4DA401AE094 for ; Tue, 26 Nov 2013 18:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 70ygfqHUwIAF for ; Tue, 26 Nov 2013 18:50:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E29AD1ABD2A for ; Tue, 26 Nov 2013 18:49:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAT03012; Wed, 27 Nov 2013 02:49:59 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 02:49:31 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 02:49:58 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.45]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 10:49:50 +0800 From: Likepeng To: "core@ietf.org" Thread-Topic: [core] How to correlate request and responses in group communication Thread-Index: Ac7rG1cGT4fNhozCS7KwdPTKZ1kSxw== Date: Wed, 27 Nov 2013 02:49:50 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@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_34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [core] How to correlate request and responses in group communication 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, 27 Nov 2013 02:50:02 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5SZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, When I read the group communication draft, I come up with one question, how= to correlate a multicast request with the multiple responses from differen= t nodes? For example, a client sends a multicast GET request to a group URI: all.bld= g6.example.com, and after some time, it will receive multiple responses fro= m different nodes. In the request, it contains one token. In the responses,= I assume that all the responses should use the same token according to the= base coap spec. Then how can the client differentiate the different respon= ses from different nodes, corresponding to the same request? I searched the whole group communication draft, token is not mentioned. So = I hope to get opinion from the group. Thanks, Kind Regards Kepeng --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5SZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

When I read the group communica= tion draft, I come up with one question, how to correlate a multicast reque= st with the multiple responses from different nodes?

 

For example, a client sends a m= ulticast GET request to a group URI: all.bldg6.example.com, and after some = time, it will receive multiple responses from different nodes. In the reque= st, it contains one token. In the responses, I assume that all the responses should use the same token according to the= base coap spec. Then how can the client differentiate the different respon= ses from different nodes, corresponding to the same request?

 

I searched the whole group comm= unication draft, token is not mentioned. So I hope to get opinion from the = group.

 

Thanks,

Kind Regards<= /p>

Kepeng

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5SZXEMA501MBSchi_-- From weigengyu@bupt.edu.cn Tue Nov 26 20:19:11 2013 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 DA0C21AC3DD for ; Tue, 26 Nov 2013 20:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 3CZSKjAKTFEg for ; Tue, 26 Nov 2013 20:19:08 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 447E91A1DFA for ; Tue, 26 Nov 2013 20:19:06 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 49F0519F344; Wed, 27 Nov 2013 12:19:04 +0800 (HKT) Message-ID: From: "weigengyu" To: "Dijk, Esko" , "Carsten Bormann" References: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Wed, 27 Nov 2013 12:19:04 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] CoAP 'infinite timeout' use case 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, 27 Nov 2013 04:19:12 -0000 Hi, Esko and Carsten, I do not agree. The original intention of HTTP is to download WEB page for personal reading. But CoAP is for M2M control. Request for control may require immediate or time-limited responses. The message layer timesout is not enough for this. CoAP should includes timeout at transaction sub-layer. This may be the one of what CoAP is different from HTTP. regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Dijk, Esko Sent: Wednesday, November 27, 2013 12:03 AM To: Carsten Bormann Cc: core (core@ietf.org) Subject: Re: [core] CoAP 'infinite timeout' use case Agree, I was somewhat expecting that CoAP would follow HTTP in this respect. I did notice that for HTTP it is explicitly stated that no timeouts are needed but that they may (MAY?) be present; http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#section-6.5 I think the CoAP spec could at least makes a similar remark; currently it's not mentioned. For implementers it's perhaps useful at some point to know what methods / best practices to use to detect the 'server dead' case; similar to the case for TCP of half-open connections and detection thereof where some approaches are documented. I assume for now it is timer-based with a custom timeout value, where the value must not be lower than MAX_LATENCY. > What specific test are are you referring here? > We didn't test any client timeout for separate responses. Oops, I didn't mean to say timeout here but time taken by the server for processing the request. It mentions " Some time (a couple of seconds) elapses" in the base.html test specs. A similar case occurs when this "some time" is higher than the client's expectation of "some time" so that's even an aspect that could be tested. (E.g use MAX_LATENCY instead of "couple of seconds"?) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday, November 26, 2013 16:45 To: Dijk, Esko Cc: core (core@ietf.org) Subject: Re: [core] CoAP 'infinite timeout' use case One general rule in CoAP is that timeouts are on the message layer, not on the request/response layer. Most likely, there will still be a limit to the time in which the response is useful to the client. E.g., in the HTTP world, many clients give up after ~ 60 seconds (even if the TCP connection below HTTP has longer timeouts). But there is nothing in the HTTP spec that describes these timeouts. I find it quite logical that CoAP hasn't anything here either. But maybe the analogy is not quite right, I'd like to hear about that. (Klaus has a draft that would allow a client to even cancel an outstanding request, draft-hartke-core-coap-liveliness.) Grüße, Carsten PS.: > (I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 only > address timeouts of "a couple of seconds") What specific test are are you referring here? We didn't test any client timeout for separate responses. ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Tue Nov 26 22:03:06 2013 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 909331AE155 for ; Tue, 26 Nov 2013 22:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 bXDiFO-ieQJL for ; Tue, 26 Nov 2013 22:03:04 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 2D85F1AE128 for ; Tue, 26 Nov 2013 22:03:03 -0800 (PST) Received: from mail91-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.22; Wed, 27 Nov 2013 06:03:02 +0000 Received: from mail91-co1 (localhost [127.0.0.1]) by mail91-co1-R.bigfish.com (Postfix) with ESMTP id 847F24C0425; Wed, 27 Nov 2013 06:03:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz217bI15d6O9371Ic89bh542I9251Id799hdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzd9hz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh109h2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h1155h) Received: from mail91-co1 (localhost.localdomain [127.0.0.1]) by mail91-co1 (MessageSwitch) id 1385532180138264_4556; Wed, 27 Nov 2013 06:03:00 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.250]) by mail91-co1.bigfish.com (Postfix) with ESMTP id 1D18050005D; Wed, 27 Nov 2013 06:03:00 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 27 Nov 2013 06:02:59 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-001.MGDPHG.emi.philips.com ([10.128.28.51]) with mapi id 14.03.0158.002; Wed, 27 Nov 2013 06:02:10 +0000 From: "Dijk, Esko" To: weigengyu , Carsten Bormann Thread-Topic: [core] CoAP 'infinite timeout' use case Thread-Index: Ac7qsAOxXW3ZPYkKRdGb4l5oB/zS2wADmKEAAAAOGCAAGkv2AAADHniA Date: Wed, 27 Nov 2013 06:02:09 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC40FD0@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.85.136.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org" Subject: Re: [core] CoAP 'infinite timeout' use case 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, 27 Nov 2013 06:03:06 -0000 DQpJIGRvbid0IHNlZSBhIHByb2JsZW0gZm9yIHRoZSBpbW1lZGlhdGUgcmVzcG9uc2VzIHJlcXVp cmVkIGZvciBjb250cm9sIGFwcGxpY2F0aW9ucy4gVGhlIHNlcnZlciBjb3VsZC9zaG91bGQgdGhl biBqdXN0IHJlc3BvbmQgaW1tZWRpYXRlbHkgd2l0aCB0aGUgUGlnZ3ktYmFja2VkIHJlc3BvbnNl IGFzIGhpbnRlZCBpbiBzZWN0aW9uIDUuMi4xLCBhbmQgZG9pbmcgdGhpcyB0aGUgcHJvYmxlbSBk b2Vzbid0IG9jY3VyLg0KDQpIb3dldmVyLCBmb3Igc2VwYXJhdGUgcmVzcG9uc2VzIChpZiB0aGUg cmVzcG9uc2UgZ2VuZXJhdGlvbiB0YWtlcyBsb25nZXIgdGhhbiBhIGZldyBzZWNvbmRzKSB0aGVy ZSBhcmUgY3VycmVudGx5IG5vIHN0YW5kYXJkIG1lY2hhbmlzbXMgc28gdGhlIGNsaWVudCB3b3Vs ZCBoYXZlIHRvIGtub3cgYmVmb3JlaGFuZCBhcHByb3hpbWF0ZWx5IGhvdyBsb25nIHRoZSBzZXJ2 ZXIgd2lsbCB0YWtlIGF0IG1vc3QgdG8gcHJvY2VzcyB0aGUgcmVxdWVzdCB0byBhIHNwZWNpZmlj IHJlc291cmNlLiBJIGhhdmVuJ3QgZW5jb3VudGVyZWQgYW55IHByYWN0aWNhbCBwcm9ibGVtcyB3 aXRoIHRoaXMgeWV0IGV4Y2VwdCBmb3IgdXNlIGNhc2VzIG9mIHJlcXVlc3QgcXVldWluZyBieSBh IENvQVAgcHJveHkuDQoNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHdlaWdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbl0gDQpTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDI3LCAyMDEzIDA1OjE5DQpUbzogRGlqaywgRXNrbzsgQ2Fyc3RlbiBCb3Jt YW5uDQpDYzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBDb0FQICdpbmZpbml0 ZSB0aW1lb3V0JyB1c2UgY2FzZQ0KDQpIaSwgRXNrbyBhbmQgQ2Fyc3RlbiwNCg0KSSBkbyBub3Qg YWdyZWUuDQpUaGUgb3JpZ2luYWwgaW50ZW50aW9uIG9mIEhUVFAgaXMgdG8gZG93bmxvYWQgV0VC IHBhZ2UgZm9yIHBlcnNvbmFsIHJlYWRpbmcuDQpCdXQgQ29BUCBpcyBmb3IgTTJNIGNvbnRyb2wu DQoNClJlcXVlc3QgZm9yIGNvbnRyb2wgbWF5IHJlcXVpcmUgaW1tZWRpYXRlIG9yIHRpbWUtbGlt aXRlZCByZXNwb25zZXMuDQpUaGUgbWVzc2FnZSBsYXllciB0aW1lc291dCBpcyBub3QgZW5vdWdo IGZvciB0aGlzLg0KQ29BUCBzaG91bGQgaW5jbHVkZXMgdGltZW91dCBhdCB0cmFuc2FjdGlvbiBz dWItbGF5ZXIuDQoNClRoaXMgbWF5IGJlIHRoZSBvbmUgb2Ygd2hhdCBDb0FQIGlzIGRpZmZlcmVu dCBmcm9tIEhUVFAuDQoNCnJlZ2FyZHMsDQoNCkdlbmd5dQ0KDQpOZXR3b3JrIFRlY2hub2xvZ3kg Q2VudGVyDQpTY2hvb2wgb2YgQ29tcHV0ZXINCkJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyAm IFRlbGVjb21tdW5pY2F0aW9ucw0KDQotLS0tLeWOn+Wni+mCruS7ti0tLS0tDQpGcm9tOiBEaWpr LCBFc2tvDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI3LCAyMDEzIDEyOjAzIEFNDQpUbzog Q2Fyc3RlbiBCb3JtYW5uDQpDYzogY29yZSAoY29yZUBpZXRmLm9yZykNClN1YmplY3Q6IFJlOiBb Y29yZV0gQ29BUCAnaW5maW5pdGUgdGltZW91dCcgdXNlIGNhc2UNCg0KQWdyZWUsIEkgd2FzIHNv bWV3aGF0IGV4cGVjdGluZyB0aGF0IENvQVAgd291bGQgZm9sbG93IEhUVFAgaW4gdGhpcyByZXNw ZWN0Lg0KSSBkaWQgbm90aWNlIHRoYXQgZm9yIEhUVFAgaXQgaXMgZXhwbGljaXRseSBzdGF0ZWQg dGhhdCBubyB0aW1lb3V0cyBhcmUgbmVlZGVkIGJ1dCB0aGF0IHRoZXkgbWF5IChNQVk/KSBiZSBw cmVzZW50Ow0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1odHRwYmlzLXAx LW1lc3NhZ2luZy0yNSNzZWN0aW9uLTYuNQ0KDQpJIHRoaW5rIHRoZSBDb0FQIHNwZWMgY291bGQg YXQgbGVhc3QgbWFrZXMgYSBzaW1pbGFyIHJlbWFyazsgY3VycmVudGx5IGl0J3Mgbm90IG1lbnRp b25lZC4NCg0KRm9yIGltcGxlbWVudGVycyBpdCdzIHBlcmhhcHMgdXNlZnVsIGF0IHNvbWUgcG9p bnQgdG8ga25vdyB3aGF0IG1ldGhvZHMgLyBiZXN0IHByYWN0aWNlcyB0byB1c2UgdG8gZGV0ZWN0 IHRoZSAnc2VydmVyIGRlYWQnIGNhc2U7IHNpbWlsYXIgdG8gdGhlIGNhc2UgZm9yIFRDUCBvZiBo YWxmLW9wZW4gY29ubmVjdGlvbnMgYW5kIGRldGVjdGlvbiB0aGVyZW9mIHdoZXJlIHNvbWUgYXBw cm9hY2hlcyBhcmUgZG9jdW1lbnRlZC4gSSBhc3N1bWUgZm9yIG5vdyBpdCBpcyB0aW1lci1iYXNl ZCB3aXRoIGEgY3VzdG9tIHRpbWVvdXQgdmFsdWUsIHdoZXJlIHRoZSB2YWx1ZSBtdXN0IG5vdCBi ZSBsb3dlciB0aGFuIE1BWF9MQVRFTkNZLg0KDQo+IFdoYXQgc3BlY2lmaWMgdGVzdCBhcmUgYXJl IHlvdSByZWZlcnJpbmcgaGVyZT8NCj4gV2UgZGlkbid0IHRlc3QgYW55IGNsaWVudCB0aW1lb3V0 IGZvciBzZXBhcmF0ZSByZXNwb25zZXMuDQpPb3BzLCBJIGRpZG4ndCBtZWFuIHRvIHNheSB0aW1l b3V0IGhlcmUgYnV0IHRpbWUgdGFrZW4gYnkgdGhlIHNlcnZlciBmb3IgcHJvY2Vzc2luZyB0aGUg cmVxdWVzdC4gSXQgbWVudGlvbnMgIiBTb21lIHRpbWUgKGEgY291cGxlIG9mIHNlY29uZHMpIGVs YXBzZXMiIGluIHRoZSBiYXNlLmh0bWwgdGVzdCBzcGVjcy4NCkEgc2ltaWxhciBjYXNlIG9jY3Vy cyB3aGVuIHRoaXMgInNvbWUgdGltZSIgaXMgaGlnaGVyIHRoYW4gdGhlIGNsaWVudCdzIGV4cGVj dGF0aW9uIG9mICJzb21lIHRpbWUiIHNvIHRoYXQncyBldmVuIGFuIGFzcGVjdCB0aGF0IGNvdWxk IGJlIHRlc3RlZC4gDQooRS5nIHVzZSBNQVhfTEFURU5DWSBpbnN0ZWFkIG9mICJjb3VwbGUgb2Yg c2Vjb25kcyI/KQ0KDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBD YXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQpTZW50OiBUdWVzZGF5LCBOb3Zl bWJlciAyNiwgMjAxMyAxNjo0NQ0KVG86IERpamssIEVza28NCkNjOiBjb3JlIChjb3JlQGlldGYu b3JnKQ0KU3ViamVjdDogUmU6IFtjb3JlXSBDb0FQICdpbmZpbml0ZSB0aW1lb3V0JyB1c2UgY2Fz ZQ0KDQpPbmUgZ2VuZXJhbCBydWxlIGluIENvQVAgaXMgdGhhdCB0aW1lb3V0cyBhcmUgb24gdGhl IG1lc3NhZ2UgbGF5ZXIsIG5vdCBvbiB0aGUgcmVxdWVzdC9yZXNwb25zZSBsYXllci4NCg0KTW9z dCBsaWtlbHksIHRoZXJlIHdpbGwgc3RpbGwgYmUgYSBsaW1pdCB0byB0aGUgdGltZSBpbiB3aGlj aCB0aGUgcmVzcG9uc2UgaXMgdXNlZnVsIHRvIHRoZSBjbGllbnQuDQpFLmcuLCBpbiB0aGUgSFRU UCB3b3JsZCwgbWFueSBjbGllbnRzIGdpdmUgdXAgYWZ0ZXIgfiA2MCBzZWNvbmRzIChldmVuIGlm IHRoZSBUQ1AgY29ubmVjdGlvbiBiZWxvdyBIVFRQIGhhcyBsb25nZXIgdGltZW91dHMpLg0KQnV0 IHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIEhUVFAgc3BlYyB0aGF0IGRlc2NyaWJlcyB0aGVzZSB0 aW1lb3V0cy4NCkkgZmluZCBpdCBxdWl0ZSBsb2dpY2FsIHRoYXQgQ29BUCBoYXNuJ3QgYW55dGhp bmcgaGVyZSBlaXRoZXIuDQpCdXQgbWF5YmUgdGhlIGFuYWxvZ3kgaXMgbm90IHF1aXRlIHJpZ2h0 LCBJJ2QgbGlrZSB0byBoZWFyIGFib3V0IHRoYXQuDQooS2xhdXMgaGFzIGEgZHJhZnQgdGhhdCB3 b3VsZCBhbGxvdyBhIGNsaWVudCB0byBldmVuIGNhbmNlbCBhbiBvdXRzdGFuZGluZyByZXF1ZXN0 LCBkcmFmdC1oYXJ0a2UtY29yZS1jb2FwLWxpdmVsaW5lc3MuKQ0KDQpHcsO8w59lLCBDYXJzdGVu DQoNClBTLjoNCg0KPiAoSSBzZWUgdGhlIENvQVAgcGx1Z3Rlc3QgdGVzdCBzcGVjcyBodHRwczov L2dpdGh1Yi5jb20vY2Fiby90ZC1jb2FwMyANCj4gb25seSBhZGRyZXNzIHRpbWVvdXRzIG9mICJh IGNvdXBsZSBvZiBzZWNvbmRzIikNCg0KV2hhdCBzcGVjaWZpYyB0ZXN0IGFyZSBhcmUgeW91IHJl ZmVycmluZyBoZXJlPw0KV2UgZGlkbid0IHRlc3QgYW55IGNsaWVudCB0aW1lb3V0IGZvciBzZXBh cmF0ZSByZXNwb25zZXMuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRp YWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMg bWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k ZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5h bCBtZXNzYWdlLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29yZSANCg0K From esko.dijk@philips.com Tue Nov 26 22:44:23 2013 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 5B9081AE222 for ; Tue, 26 Nov 2013 22:44:23 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3] 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 yQv4p6ITT1T3 for ; Tue, 26 Nov 2013 22:44:19 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA571AE213 for ; Tue, 26 Nov 2013 22:44:19 -0800 (PST) Received: from mail148-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE030.bigfish.com (10.236.130.93) with Microsoft SMTP Server id 14.1.225.22; Wed, 27 Nov 2013 06:44:19 +0000 Received: from mail148-co9 (localhost [127.0.0.1]) by mail148-co9-R.bigfish.com (Postfix) with ESMTP id E0220700135; Wed, 27 Nov 2013 06:44:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz217bI98dI15d6O542I1432I9251I4015Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h1155h) Received: from mail148-co9 (localhost.localdomain [127.0.0.1]) by mail148-co9 (MessageSwitch) id 1385534656784912_2971; Wed, 27 Nov 2013 06:44:16 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.227]) by mail148-co9.bigfish.com (Postfix) with ESMTP id B105B200077; Wed, 27 Nov 2013 06:44:16 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 27 Nov 2013 06:44:16 +0000 Received: from 011-DB3MMR1-016.MGDPHG.emi.philips.com (10.128.28.100) by 011-DB3MMR1-003.MGDPHG.emi.philips.com (10.128.28.53) with Microsoft SMTP Server (TLS) id 14.3.158.2; Wed, 27 Nov 2013 06:44:11 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-016.MGDPHG.emi.philips.com ([10.128.28.100]) with mapi id 14.03.0158.002; Wed, 27 Nov 2013 06:44:11 +0000 From: "Dijk, Esko" To: Klaus Hartke , Zach Shelby Thread-Topic: [core] Sleepy devices: OMA lightweight queue mode for CoAP Thread-Index: Ac7eupK1vkBEFzF3SDuPgMOcHEH12wB3d1YAAoTV/kAACFTbgAAAseuAABp5gHA= Date: Wed, 27 Nov 2013 06:44:10 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC40FFC@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180CC2895D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <8AD83A72-6EE4-4C77-A084-BAD5C5C87989@arm.com> <031DD135F9160444ABBE3B0C36CED6180CC40DF1@011-DB3MPN2-082.MGDPHG.emi.philips.com> <2E04C2C9-4860-499E-9CF6-C419CBFD8B0A@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.69.193.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org" Subject: Re: [core] Sleepy devices: OMA lightweight queue mode for 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, 27 Nov 2013 06:44:23 -0000 Thanks, > I'd expect a 2.xx (Accepted)* response here with Location options indicat= ing > a resource that the client can poll or observe to track the progress of t= he request. For the HTTP-to-CoAP proxy case, status 202 seems to fit the use case very = well. In the CoAP Proxy case, a 2.xx (Accepted) is then the most intuitive soluti= on. With the solution of HTTP long polling: this assumes different knowledge on= the HTTP client side, in the sense that the client already knows it may ta= ke very long and is prepared to long-poll for that amount of time and repea= t its request. The "status 202" solution does not assume such pre-knowledge= on the client side. (Btw in the typical sleepy/SICEP use cases I consider, the HTTP client or C= oAP client initiating a request via Proxy does not have this pre-knowledge= .) Esko -----Original Message----- From: Klaus Hartke [mailto:hartke@tzi.org] Sent: Tuesday, November 26, 2013 18:50 To: Zach Shelby Cc: Dijk, Esko; core@ietf.org Subject: Re: [core] Sleepy devices: OMA lightweight queue mode for CoAP Zach Shelby wrote: > Esko Dijk wrote: >> The 'SICEP' may typically wake up once a day and the HTTP connection >> would be dropped long before that. (A few minutes typically?) > > You would need to long-poll or use a callback of course. I'd expect a 2.xx (Accepted)* response here with Location options indicatin= g a resource that the client can poll or observe to track the progress of t= he request. (*like HTTP 202 Accepted ; currently not defined in CoAP) Best regards, Klaus ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Tue Nov 26 23:00:45 2013 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 49AF91AE22C for ; Tue, 26 Nov 2013 23:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 K9NtDPDPU_BR for ; Tue, 26 Nov 2013 23:00:43 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id E531D1AE180 for ; Tue, 26 Nov 2013 23:00:42 -0800 (PST) Received: from mail184-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.22; Wed, 27 Nov 2013 07:00:42 +0000 Received: from mail184-co1 (localhost [127.0.0.1]) by mail184-co1-R.bigfish.com (Postfix) with ESMTP id 4855A4801A2; Wed, 27 Nov 2013 07:00:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(z579ehz217bI15d6Oc85fh1be0I9251I4015I14ffIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh18c673h1de097hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h1155h) Received: from mail184-co1 (localhost.localdomain [127.0.0.1]) by mail184-co1 (MessageSwitch) id 13855356417791_2565; Wed, 27 Nov 2013 07:00:41 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.252]) by mail184-co1.bigfish.com (Postfix) with ESMTP id F25A1100064; Wed, 27 Nov 2013 07:00:40 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 27 Nov 2013 07:00:40 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-001.MGDPHG.emi.philips.com (10.128.28.51) with Microsoft SMTP Server (TLS) id 14.3.158.2; Wed, 27 Nov 2013 07:00:38 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.03.0158.002; Wed, 27 Nov 2013 07:00:38 +0000 From: "Dijk, Esko" To: Likepeng , "core@ietf.org" Thread-Topic: [core] How to correlate request and responses in group communication Thread-Index: Ac7rG1cGT4fNhozCS7KwdPTKZ1kSxwAIgb/g Date: Wed, 27 Nov 2013 07:00:37 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.69.193.72] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180CC4102C011DB3MPN2082MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [core] How to correlate request and responses in group communication 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, 27 Nov 2013 07:00:45 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180CC4102C011DB3MPN2082MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Kepeng, The identification of the individual response is by the (unicast) IP source= address of the responding CoAP endpoint. Indeed this would be good to mention somewhere in groupcomm. Correlation of a single request with a set of responses is via Token; in ca= se there are multiple outstanding multicast requests from a single endpoint= . Also core-coap has some information on use of IP address of the responding = endpoint, section 8.2: For the purposes of interpreting the Location-* options and any links embedded in the representation and, the request URI (base URI) relative to which the response is interpreted, is formed by replacing the multicast address in the Host component of the original request URI by the literal IP address of the endpoint actually responding. Esko From: core [mailto:core-bounces@ietf.org] On Behalf Of Likepeng Sent: Wednesday, November 27, 2013 03:50 To: core@ietf.org Subject: [core] How to correlate request and responses in group communicati= on Hi all, When I read the group communication draft, I come up with one question, how= to correlate a multicast request with the multiple responses from differen= t nodes? For example, a client sends a multicast GET request to a group URI: all.bld= g6.example.com, and after some time, it will receive multiple responses fro= m different nodes. In the request, it contains one token. In the responses,= I assume that all the responses should use the same token according to the= base coap spec. Then how can the client differentiate the different respon= ses from different nodes, corresponding to the same request? I searched the whole group communication draft, token is not mentioned. So = I hope to get opinion from the group. Thanks, Kind Regards Kepeng ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED6180CC4102C011DB3MPN2082MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hell= o Kepeng,

&nbs= p;

The = identification of the individual response is by the (unicast) IP source add= ress of the responding CoAP endpoint.

Inde= ed this would be good to mention somewhere in groupcomm.

Corr= elation of a single request with a set of responses is via Token; in case t= here are multiple outstanding multicast requests from a single endpoint.

&nbs= p;

Also= core-coap has some information on use of IP address of the responding endp= oint, section 8.2:

&nbs= p;

For = the purposes of interpreting the Location-* options and any links

&nbs= p;  embedded in the representation and, the request URI (base URI)

&nbs= p;  relative to which the response is interpreted, is formed by replac= ing

&nbs= p;  the multicast address in the Host component of the original reques= t

&nbs= p;  URI by the literal IP address of the endpoint actually responding.=

&nbs= p;

Esko=

&nbs= p;

From: core [mailto:core-bounces@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: core@ietf.org
Subject: [core] How to correlate request and responses in group comm= unication

 

Hi all,

 

When I read the group communication= draft, I come up with one question, how to correlate a multicast request w= ith the multiple responses from different nodes?

 

For example, a client sends a multi= cast GET request to a group URI: all.bldg6.example.com, and after some time= , it will receive multiple responses from different nodes. In the request, = it contains one token. In the responses, I assume that all the responses should use the same token according to the= base coap spec. Then how can the client differentiate the different respon= ses from different nodes, corresponding to the same request?

 

I searched the whole group communic= ation draft, token is not mentioned. So I hope to get opinion from the grou= p.

 

Thanks,

Kind Regards

Kepeng


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED6180CC4102C011DB3MPN2082MG_-- From weigengyu@bupt.edu.cn Wed Nov 27 00:29:32 2013 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 7D30F1AC448 for ; Wed, 27 Nov 2013 00:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 SZhYG8C3wCrm for ; Wed, 27 Nov 2013 00:29:23 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 213E81A1F02 for ; Wed, 27 Nov 2013 00:29:18 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 9E83719F390; Wed, 27 Nov 2013 16:29:14 +0800 (HKT) Message-ID: From: "weigengyu" To: "Dijk, Esko" , "Carsten Bormann" References: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED6180CC40FD0@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC40FD0@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Wed, 27 Nov 2013 16:28:42 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] CoAP 'infinite timeout' use case 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, 27 Nov 2013 08:29:34 -0000 Hi, Esko, When a client sends a request to turn off 10 lights by multicast, immediate responses are expected. When messages are send by unreliable multicast, it is undeterminded how long the client may wait. Regards, Gengyu Network Technology Center School of computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Dijk, Esko Sent: Wednesday, November 27, 2013 2:02 PM To: weigengyu ; Carsten Bormann Cc: core@ietf.org Subject: RE: [core] CoAP 'infinite timeout' use case I don't see a problem for the immediate responses required for control applications. The server could/should then just respond immediately with the Piggy-backed response as hinted in section 5.2.1, and doing this the problem doesn't occur. However, for separate responses (if the response generation takes longer than a few seconds) there are currently no standard mechanisms so the client would have to know beforehand approximately how long the server will take at most to process the request to a specific resource. I haven't encountered any practical problems with this yet except for use cases of request queuing by a CoAP proxy. Esko -----Original Message----- From: weigengyu [mailto:weigengyu@bupt.edu.cn] Sent: Wednesday, November 27, 2013 05:19 To: Dijk, Esko; Carsten Bormann Cc: core@ietf.org Subject: Re: [core] CoAP 'infinite timeout' use case Hi, Esko and Carsten, I do not agree. The original intention of HTTP is to download WEB page for personal reading. But CoAP is for M2M control. Request for control may require immediate or time-limited responses. The message layer timesout is not enough for this. CoAP should includes timeout at transaction sub-layer. This may be the one of what CoAP is different from HTTP. regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Dijk, Esko Sent: Wednesday, November 27, 2013 12:03 AM To: Carsten Bormann Cc: core (core@ietf.org) Subject: Re: [core] CoAP 'infinite timeout' use case Agree, I was somewhat expecting that CoAP would follow HTTP in this respect. I did notice that for HTTP it is explicitly stated that no timeouts are needed but that they may (MAY?) be present; http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#section-6.5 I think the CoAP spec could at least makes a similar remark; currently it's not mentioned. For implementers it's perhaps useful at some point to know what methods / best practices to use to detect the 'server dead' case; similar to the case for TCP of half-open connections and detection thereof where some approaches are documented. I assume for now it is timer-based with a custom timeout value, where the value must not be lower than MAX_LATENCY. > What specific test are are you referring here? > We didn't test any client timeout for separate responses. Oops, I didn't mean to say timeout here but time taken by the server for processing the request. It mentions " Some time (a couple of seconds) elapses" in the base.html test specs. A similar case occurs when this "some time" is higher than the client's expectation of "some time" so that's even an aspect that could be tested. (E.g use MAX_LATENCY instead of "couple of seconds"?) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday, November 26, 2013 16:45 To: Dijk, Esko Cc: core (core@ietf.org) Subject: Re: [core] CoAP 'infinite timeout' use case One general rule in CoAP is that timeouts are on the message layer, not on the request/response layer. Most likely, there will still be a limit to the time in which the response is useful to the client. E.g., in the HTTP world, many clients give up after ~ 60 seconds (even if the TCP connection below HTTP has longer timeouts). But there is nothing in the HTTP spec that describes these timeouts. I find it quite logical that CoAP hasn't anything here either. But maybe the analogy is not quite right, I'd like to hear about that. (Klaus has a draft that would allow a client to even cancel an outstanding request, draft-hartke-core-coap-liveliness.) Grüße, Carsten PS.: > (I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 > only address timeouts of "a couple of seconds") What specific test are are you referring here? We didn't test any client timeout for separate responses. ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From likepeng@huawei.com Wed Nov 27 00:32:11 2013 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 43E0F1AC7F1 for ; Wed, 27 Nov 2013 00:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 b6QTCgKp3XGN for ; Wed, 27 Nov 2013 00:32:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5141AC448 for ; Wed, 27 Nov 2013 00:32:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAT30292; Wed, 27 Nov 2013 08:32:06 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 08:31:30 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 08:32:00 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.45]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 16:31:54 +0800 From: Likepeng To: "Dijk, Esko" , "core@ietf.org" Thread-Topic: [core] How to correlate request and responses in group communication Thread-Index: Ac7rG1cGT4fNhozCS7KwdPTKZ1kSxwAIgb/gAAIa26A= Date: Wed, 27 Nov 2013 08:31:53 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.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_34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] How to correlate request and responses in group communication 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, 27 Nov 2013 08:32:11 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4SZXEMA501MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRXNrbywNCg0KPlRoZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgaW5kaXZpZHVhbCByZXNwb25z ZSBpcyBieSB0aGUgKHVuaWNhc3QpIElQIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSByZXNwb25kaW5n IENvQVAgZW5kcG9pbnQuDQoNCkluIHRoZSByZXNwb25zZSwgdGhlIG9ubHkgcGxhY2UgdG8gcHV0 IHRoZSAodW5pY2FzdCkgSVAgc291cmNlIGFkZHJlc3MgaXMgdGhlIFVEUCBsYXllciwgcmlnaHQ/ IEJlY2F1c2UgSFJJLUhvc3QgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGUgdGFyZ2V0IG5vZGUsIG5v dCB0aGUgc291cmNlIG5vZGUuDQoNCihDb0FQIHNlY3Rpb24gNS4xMC4xKSBUaGUgVXJpLUhvc3Qs IFVyaS1Qb3J0LCBVcmktUGF0aCBhbmQgVXJpLVF1ZXJ5IE9wdGlvbnMgYXJlIHVzZWQgdG8gc3Bl Y2lmeSB0aGUgdGFyZ2V0IHJlc291cmNlIG9mIGEgcmVxdWVzdCB0byBhIENvQVAgb3JpZ2luIHNl cnZlci4NCg0KVGhhdCBtZWFucywgdGhlIHJlcXVlc3RvciBoYXMgdG8gcmVseSBvbiBVRFAgbGF5 ZXIgdG8gZ2V0IHRoZSAodW5pY2FzdCkgSVAgc291cmNlIGFkZHJlc3MgZnJvbSB0aGUgcmVzcG9u c2UsIHRoZW4gY29ycmVsYXRlIHRoZSBtdWx0aWNhc3QgcmVxdWVzdCBhbmQgdGhlIHVuaWNhc3Qg cmVzcG9uc2UuIEJ1dCBpbiBteSBvcGluaW9uLCB0aGUgY29ycmVsYXRpb24gc2hvdWxkIGJlIGRv bmUgaW4gdGhlIENvQVAgbGF5ZXIuIENvQVAgbGF5ZXIgc2hvdWxkIHByb3ZpZGUgc29tZSBpbmZv cm1hdGlvbiB0byBiZSB1c2VkIGZvciB0aGlzIHB1cnBvc2UuDQoNCkluIENvQVAgc3BlYywgaXQg bWVudGlvbnMgdGhhdCBUb2tlbiBNVVNUIGJlIHVzZWQgdG8gbWF0Y2ggdGhlIHJlc3BvbnNlcyB3 aXRoIHRoZSBtdWx0aWNhc3QgcmVxdWVzdC4gSWYgdGhlcmUgYXJlIG11bHRpcGxlIHJlc3BvbnNl cywgd2UgaGF2ZSB0byB1c2Ugc291cmNlIGVuZHBvaW50IHRvIGRpZmZlcmVudGlhdGUuIEJ1dCB0 aGlzIGluZm9ybWF0aW9uIGNhbiBiZSBvbmx5IGdvdCBmcm9tIFVEUCBsYXllci4gVGhhdCBpcyBh biBpc3N1ZSwgaW4gbXkgb3Bpbmlvbi4NCg0KQ29BUCBTZWN0aW9uIDguMg0KICAgV2hlbiBtYXRj aGluZyBhIHJlc3BvbnNlIHRvIGEgbXVsdGljYXN0IHJlcXVlc3QsIG9ubHkgdGhlIHRva2VuIE1V U1QNCiAgIG1hdGNoOyB0aGUgc291cmNlIGVuZHBvaW50IG9mIHRoZSByZXNwb25zZSBkb2VzIG5v dCBuZWVkIHRvIChhbmQgd2lsbA0KICAgbm90KSBiZSB0aGUgc2FtZSBhcyB0aGUgZGVzdGluYXRp b24gZW5kcG9pbnQgb2YgdGhlIG9yaWdpbmFsIHJlcXVlc3QuDQoNCkFueSB0aG91Z2h0cz8NCg0K VGhhbmtzLA0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0Kt6K8/sjLOiBEaWprLCBFc2tvIFttYWls dG86ZXNrby5kaWprQHBoaWxpcHMuY29tXQ0Kt6LLzcqxvOQ6IDIwMTPE6jEx1MIyN8jVIDE1OjAx DQrK1bz+yMs6IExpa2VwZW5nOyBjb3JlQGlldGYub3JnDQrW98ziOiBSRTogW2NvcmVdIEhvdyB0 byBjb3JyZWxhdGUgcmVxdWVzdCBhbmQgcmVzcG9uc2VzIGluIGdyb3VwIGNvbW11bmljYXRpb24N Cg0KSGVsbG8gS2VwZW5nLA0KDQpUaGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIGluZGl2aWR1YWwg cmVzcG9uc2UgaXMgYnkgdGhlICh1bmljYXN0KSBJUCBzb3VyY2UgYWRkcmVzcyBvZiB0aGUgcmVz cG9uZGluZyBDb0FQIGVuZHBvaW50Lg0KSW5kZWVkIHRoaXMgd291bGQgYmUgZ29vZCB0byBtZW50 aW9uIHNvbWV3aGVyZSBpbiBncm91cGNvbW0uDQpDb3JyZWxhdGlvbiBvZiBhIHNpbmdsZSByZXF1 ZXN0IHdpdGggYSBzZXQgb2YgcmVzcG9uc2VzIGlzIHZpYSBUb2tlbjsgaW4gY2FzZSB0aGVyZSBh cmUgbXVsdGlwbGUgb3V0c3RhbmRpbmcgbXVsdGljYXN0IHJlcXVlc3RzIGZyb20gYSBzaW5nbGUg ZW5kcG9pbnQuDQoNCkFsc28gY29yZS1jb2FwIGhhcyBzb21lIGluZm9ybWF0aW9uIG9uIHVzZSBv ZiBJUCBhZGRyZXNzIG9mIHRoZSByZXNwb25kaW5nIGVuZHBvaW50LCBzZWN0aW9uIDguMjoNCg0K Rm9yIHRoZSBwdXJwb3NlcyBvZiBpbnRlcnByZXRpbmcgdGhlIExvY2F0aW9uLSogb3B0aW9ucyBh bmQgYW55IGxpbmtzDQogICBlbWJlZGRlZCBpbiB0aGUgcmVwcmVzZW50YXRpb24gYW5kLCB0aGUg cmVxdWVzdCBVUkkgKGJhc2UgVVJJKQ0KICAgcmVsYXRpdmUgdG8gd2hpY2ggdGhlIHJlc3BvbnNl IGlzIGludGVycHJldGVkLCBpcyBmb3JtZWQgYnkgcmVwbGFjaW5nDQogICB0aGUgbXVsdGljYXN0 IGFkZHJlc3MgaW4gdGhlIEhvc3QgY29tcG9uZW50IG9mIHRoZSBvcmlnaW5hbCByZXF1ZXN0DQog ICBVUkkgYnkgdGhlIGxpdGVyYWwgSVAgYWRkcmVzcyBvZiB0aGUgZW5kcG9pbnQgYWN0dWFsbHkg cmVzcG9uZGluZy4NCg0KRXNrbw0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTGlrZXBlbmcNClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIg MjcsIDIwMTMgMDM6NTANClRvOiBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0K U3ViamVjdDogW2NvcmVdIEhvdyB0byBjb3JyZWxhdGUgcmVxdWVzdCBhbmQgcmVzcG9uc2VzIGlu IGdyb3VwIGNvbW11bmljYXRpb24NCg0KSGkgYWxsLA0KDQpXaGVuIEkgcmVhZCB0aGUgZ3JvdXAg Y29tbXVuaWNhdGlvbiBkcmFmdCwgSSBjb21lIHVwIHdpdGggb25lIHF1ZXN0aW9uLCBob3cgdG8g Y29ycmVsYXRlIGEgbXVsdGljYXN0IHJlcXVlc3Qgd2l0aCB0aGUgbXVsdGlwbGUgcmVzcG9uc2Vz IGZyb20gZGlmZmVyZW50IG5vZGVzPw0KDQpGb3IgZXhhbXBsZSwgYSBjbGllbnQgc2VuZHMgYSBt dWx0aWNhc3QgR0VUIHJlcXVlc3QgdG8gYSBncm91cCBVUkk6IGFsbC5ibGRnNi5leGFtcGxlLmNv bSwgYW5kIGFmdGVyIHNvbWUgdGltZSwgaXQgd2lsbCByZWNlaXZlIG11bHRpcGxlIHJlc3BvbnNl cyBmcm9tIGRpZmZlcmVudCBub2Rlcy4gSW4gdGhlIHJlcXVlc3QsIGl0IGNvbnRhaW5zIG9uZSB0 b2tlbi4gSW4gdGhlIHJlc3BvbnNlcywgSSBhc3N1bWUgdGhhdCBhbGwgdGhlIHJlc3BvbnNlcyBz aG91bGQgdXNlIHRoZSBzYW1lIHRva2VuIGFjY29yZGluZyB0byB0aGUgYmFzZSBjb2FwIHNwZWMu IFRoZW4gaG93IGNhbiB0aGUgY2xpZW50IGRpZmZlcmVudGlhdGUgdGhlIGRpZmZlcmVudCByZXNw b25zZXMgZnJvbSBkaWZmZXJlbnQgbm9kZXMsIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHNhbWUgcmVx dWVzdD8NCg0KSSBzZWFyY2hlZCB0aGUgd2hvbGUgZ3JvdXAgY29tbXVuaWNhdGlvbiBkcmFmdCwg dG9rZW4gaXMgbm90IG1lbnRpb25lZC4gU28gSSBob3BlIHRvIGdldCBvcGluaW9uIGZyb20gdGhl IGdyb3VwLg0KDQpUaGFua3MsDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1l c3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBw bGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJl c3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBv ciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFs bCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4SZXEMA501MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Esko= ,

&n= bsp;

>The identification of the individual response is by the (unic= ast) IP source address of the responding CoAP endpoint.

&n= bsp;

In the = response, the only place to put the (unicast) IP source address is the UDP = layer, right? Because HRI-Host is used to indicate the target node, not the= source node.

&n= bsp;

(CoAP section 5.10.1)= The Uri-Host, Uri-Port, Uri-Path and Uri-Query Options are used to specify= the target resource of a request to a CoAP origin server.

&n= bsp;

That me= ans, the requestor has to rely on UDP layer to get the (unicast) IP source = address from the response, then correlate the multicast request and the uni= cast response. But in my opinion, the correlation should be done in the CoAP layer. CoAP layer should provide so= me information to be used for this purpose.

&n= bsp;

In CoAP= spec, it mentions that Token MUST be used to match the responses with the = multicast request. If there are multiple responses, we have to use source e= ndpoint to differentiate. But this information can be only got from UDP layer. That is an issue, in my opinion.

&n= bsp;

CoAP Se= ction 8.2

   When mat= ching a response to a multicast request, only the token MUST

   match; t= he source endpoint of the response does not need to (and will

 &= nbsp; not) be the same as the destination endpoint of the original request.=

&n= bsp;

Any tho= ughts?

&n= bsp;

Thanks,=

Kind Re= gards

Kepeng<= o:p>

&n= bsp;

=B7=A2=BC=FE=C8=CB: Dijk, Esko [mailto:esko.dijk@philips.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C227=C8=D5 15:01
=CA=D5=BC=FE=C8=CB: Likepeng; core@ietf.org
=D6=F7=CC=E2: RE: [core] How to correlate request and responses in group communication<= o:p>

 

Hello Kepeng,

 

The identification of the individual response is by the (unicast)= IP source address of the responding CoAP endpoint.

Indeed this would be good to mention somewhere in groupcomm.

Correlation of a single request with a set of responses is via To= ken; in case there are multiple outstanding multicast requests from a singl= e endpoint.

 

Also core-coap has some information on use of IP address of the r= esponding endpoint, section 8.2:

 

For the purposes of interpreting the Location-* options and any l= inks

   embedded in the representation and, the request URI = (base URI)

   relative to which the response is interpreted, is fo= rmed by replacing

   the multicast address in the Host component of the o= riginal request

   URI by the literal IP address of the endpoint actual= ly responding.

 

Esko

 

From: core [mailto:core-bounces@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: core@ietf.org
Subject: [core] How to correlate request and responses in group comm= unication

 

Hi all,

 

When I read the group communica= tion draft, I come up with one question, how to correlate a multicast reque= st with the multiple responses from different nodes?

 

For example, a client sends a m= ulticast GET request to a group URI: all.bldg6.example.com, and after some = time, it will receive multiple responses from different nodes. In the reque= st, it contains one token. In the responses, I assume that all the responses should use the same token according to the= base coap spec. Then how can the client differentiate the different respon= ses from different nodes, corresponding to the same request?

 

I searched the whole group comm= unication draft, token is not mentioned. So I hope to get opinion from the = group.

 

Thanks,

Kind Regards<= /p>

Kepeng

 

The information contained in this message may be = confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recip= ient, you are hereby notified that any use, forwarding, dissemination, or r= eproduction of this message is strictly prohibited and may be unlawful. If = you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the o= riginal message.

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4SZXEMA501MBSchi_-- From likepeng@huawei.com Wed Nov 27 01:00:40 2013 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 DB4BB1AE260 for ; Wed, 27 Nov 2013 01:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 1d_-c1kyba2G for ; Wed, 27 Nov 2013 01:00:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3973F1AE25F for ; Wed, 27 Nov 2013 01:00:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAT33533; Wed, 27 Nov 2013 09:00:34 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 09:00:03 +0000 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 09:00:33 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.45]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 17:00:30 +0800 From: Likepeng To: "Dijk, Esko" , weigengyu , Carsten Bormann Thread-Topic: [core] CoAP 'infinite timeout' use case Thread-Index: Ac7qsAOxXW3ZPYkKRdGb4l5oB/zS2///lqgAgAAFPYCAAM2UAIAAHM2A//9Jc8A= Date: Wed, 27 Nov 2013 09:00:29 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC0013@SZXEMA501-MBS.china.huawei.com> References: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED6180CC40FD0@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC40FD0@011-DB3MPN2-082.MGDPHG.emi.philips.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 Cc: "core@ietf.org" Subject: Re: [core] CoAP 'infinite timeout' use case 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, 27 Nov 2013 09:00:41 -0000 SGVsbG8gRXNrbywNCg0KPkhvd2V2ZXIsIGZvciBzZXBhcmF0ZSByZXNwb25zZXMgKGlmIHRoZSBy ZXNwb25zZSBnZW5lcmF0aW9uIHRha2VzIGxvbmdlciB0aGFuIGEgZmV3IHNlY29uZHMpIHRoZXJl IGFyZSBjdXJyZW50bHkgbm8gc3RhbmRhcmQgbWVjaGFuaXNtcyBzbyB0aGUgY2xpZW50IHdvdWxk IGhhdmUgdG8ga25vdyBiZWZvcmVoYW5kIGFwcHJveGltYXRlbHkgaG93IGxvbmcgdGhlIHNlcnZl ciB3aWxsIHRha2UgYXQgbW9zdCB0byBwcm9jZXNzIHRoZSByZXF1ZXN0IHRvIGEgc3BlY2lmaWMg cmVzb3VyY2UuDQoNClNvbWUgdGltZSBhZ28sIHdlIHN1Ym1pdHRlZCBhIGRyYWZ0IHRvIHByb3Bv c2UgYSBuZXcgUGF0aWVuY2Ugb3B0aW9uIGZvciB0aGlzOg0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbGktY29yZS1jb2FwLXBhdGllbmNlLW9wdGlvbi0wMg0KDQpJIHRoaW5rIGl0 IGNhbiBzb2x2ZSB0aGUgcHJvYmxlbSB5b3UgbWVudGlvbmVkLg0KDQpLaW5kIFJlZ2FyZHMNCktl cGVuZw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGNvcmUgW21haWx0bzpj b3JlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBEaWprLCBFc2tvDQrlj5HpgIHml7bpl7Q6IDIw MTPlubQxMeaciDI35pelIDE0OjAyDQrmlLbku7bkuro6IHdlaWdlbmd5dTsgQ2Fyc3RlbiBCb3Jt YW5uDQrmioTpgIE6IGNvcmVAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtjb3JlXSBDb0FQICdpbmZp bml0ZSB0aW1lb3V0JyB1c2UgY2FzZQ0KDQoNCkkgZG9uJ3Qgc2VlIGEgcHJvYmxlbSBmb3IgdGhl IGltbWVkaWF0ZSByZXNwb25zZXMgcmVxdWlyZWQgZm9yIGNvbnRyb2wgYXBwbGljYXRpb25zLiBU aGUgc2VydmVyIGNvdWxkL3Nob3VsZCB0aGVuIGp1c3QgcmVzcG9uZCBpbW1lZGlhdGVseSB3aXRo IHRoZSBQaWdneS1iYWNrZWQgcmVzcG9uc2UgYXMgaGludGVkIGluIHNlY3Rpb24gNS4yLjEsIGFu ZCBkb2luZyB0aGlzIHRoZSBwcm9ibGVtIGRvZXNuJ3Qgb2NjdXIuDQoNCkhvd2V2ZXIsIGZvciBz ZXBhcmF0ZSByZXNwb25zZXMgKGlmIHRoZSByZXNwb25zZSBnZW5lcmF0aW9uIHRha2VzIGxvbmdl ciB0aGFuIGEgZmV3IHNlY29uZHMpIHRoZXJlIGFyZSBjdXJyZW50bHkgbm8gc3RhbmRhcmQgbWVj aGFuaXNtcyBzbyB0aGUgY2xpZW50IHdvdWxkIGhhdmUgdG8ga25vdyBiZWZvcmVoYW5kIGFwcHJv eGltYXRlbHkgaG93IGxvbmcgdGhlIHNlcnZlciB3aWxsIHRha2UgYXQgbW9zdCB0byBwcm9jZXNz IHRoZSByZXF1ZXN0IHRvIGEgc3BlY2lmaWMgcmVzb3VyY2UuIEkgaGF2ZW4ndCBlbmNvdW50ZXJl ZCBhbnkgcHJhY3RpY2FsIHByb2JsZW1zIHdpdGggdGhpcyB5ZXQgZXhjZXB0IGZvciB1c2UgY2Fz ZXMgb2YgcmVxdWVzdCBxdWV1aW5nIGJ5IGEgQ29BUCBwcm94eS4NCg0KRXNrbw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogd2VpZ2VuZ3l1IFttYWlsdG86d2VpZ2VuZ3l1QGJ1 cHQuZWR1LmNuXQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMyAwNToxOQ0KVG86 IERpamssIEVza287IENhcnN0ZW4gQm9ybWFubg0KQ2M6IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbY29yZV0gQ29BUCAnaW5maW5pdGUgdGltZW91dCcgdXNlIGNhc2UNCg0KSGksIEVza28g YW5kIENhcnN0ZW4sDQoNCkkgZG8gbm90IGFncmVlLg0KVGhlIG9yaWdpbmFsIGludGVudGlvbiBv ZiBIVFRQIGlzIHRvIGRvd25sb2FkIFdFQiBwYWdlIGZvciBwZXJzb25hbCByZWFkaW5nLg0KQnV0 IENvQVAgaXMgZm9yIE0yTSBjb250cm9sLg0KDQpSZXF1ZXN0IGZvciBjb250cm9sIG1heSByZXF1 aXJlIGltbWVkaWF0ZSBvciB0aW1lLWxpbWl0ZWQgcmVzcG9uc2VzLg0KVGhlIG1lc3NhZ2UgbGF5 ZXIgdGltZXNvdXQgaXMgbm90IGVub3VnaCBmb3IgdGhpcy4NCkNvQVAgc2hvdWxkIGluY2x1ZGVz IHRpbWVvdXQgYXQgdHJhbnNhY3Rpb24gc3ViLWxheWVyLg0KDQpUaGlzIG1heSBiZSB0aGUgb25l IG9mIHdoYXQgQ29BUCBpcyBkaWZmZXJlbnQgZnJvbSBIVFRQLg0KDQpyZWdhcmRzLA0KDQpHZW5n eXUNCg0KTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0KU2Nob29sIG9mIENvbXB1dGVyDQpCZWlq aW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgJiBUZWxlY29tbXVuaWNhdGlvbnMNCg0KLS0tLS3ljp/l p4vpgq7ku7YtLS0tLQ0KRnJvbTogRGlqaywgRXNrbw0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJl ciAyNywgMjAxMyAxMjowMyBBTQ0KVG86IENhcnN0ZW4gQm9ybWFubg0KQ2M6IGNvcmUgKGNvcmVA aWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW2NvcmVdIENvQVAgJ2luZmluaXRlIHRpbWVvdXQnIHVz ZSBjYXNlDQoNCkFncmVlLCBJIHdhcyBzb21ld2hhdCBleHBlY3RpbmcgdGhhdCBDb0FQIHdvdWxk IGZvbGxvdyBIVFRQIGluIHRoaXMgcmVzcGVjdC4NCkkgZGlkIG5vdGljZSB0aGF0IGZvciBIVFRQ IGl0IGlzIGV4cGxpY2l0bHkgc3RhdGVkIHRoYXQgbm8gdGltZW91dHMgYXJlIG5lZWRlZCBidXQg dGhhdCB0aGV5IG1heSAoTUFZPykgYmUgcHJlc2VudDsNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtaHR0cGJpcy1wMS1tZXNzYWdpbmctMjUjc2VjdGlvbi02LjUNCg0KSSB0 aGluayB0aGUgQ29BUCBzcGVjIGNvdWxkIGF0IGxlYXN0IG1ha2VzIGEgc2ltaWxhciByZW1hcms7 IGN1cnJlbnRseSBpdCdzIG5vdCBtZW50aW9uZWQuDQoNCkZvciBpbXBsZW1lbnRlcnMgaXQncyBw ZXJoYXBzIHVzZWZ1bCBhdCBzb21lIHBvaW50IHRvIGtub3cgd2hhdCBtZXRob2RzIC8gYmVzdCBw cmFjdGljZXMgdG8gdXNlIHRvIGRldGVjdCB0aGUgJ3NlcnZlciBkZWFkJyBjYXNlOyBzaW1pbGFy IHRvIHRoZSBjYXNlIGZvciBUQ1Agb2YgaGFsZi1vcGVuIGNvbm5lY3Rpb25zIGFuZCBkZXRlY3Rp b24gdGhlcmVvZiB3aGVyZSBzb21lIGFwcHJvYWNoZXMgYXJlIGRvY3VtZW50ZWQuIEkgYXNzdW1l IGZvciBub3cgaXQgaXMgdGltZXItYmFzZWQgd2l0aCBhIGN1c3RvbSB0aW1lb3V0IHZhbHVlLCB3 aGVyZSB0aGUgdmFsdWUgbXVzdCBub3QgYmUgbG93ZXIgdGhhbiBNQVhfTEFURU5DWS4NCg0KPiBX aGF0IHNwZWNpZmljIHRlc3QgYXJlIGFyZSB5b3UgcmVmZXJyaW5nIGhlcmU/DQo+IFdlIGRpZG4n dCB0ZXN0IGFueSBjbGllbnQgdGltZW91dCBmb3Igc2VwYXJhdGUgcmVzcG9uc2VzLg0KT29wcywg SSBkaWRuJ3QgbWVhbiB0byBzYXkgdGltZW91dCBoZXJlIGJ1dCB0aW1lIHRha2VuIGJ5IHRoZSBz ZXJ2ZXIgZm9yIHByb2Nlc3NpbmcgdGhlIHJlcXVlc3QuIEl0IG1lbnRpb25zICIgU29tZSB0aW1l IChhIGNvdXBsZSBvZiBzZWNvbmRzKSBlbGFwc2VzIiBpbiB0aGUgYmFzZS5odG1sIHRlc3Qgc3Bl Y3MuDQpBIHNpbWlsYXIgY2FzZSBvY2N1cnMgd2hlbiB0aGlzICJzb21lIHRpbWUiIGlzIGhpZ2hl ciB0aGFuIHRoZSBjbGllbnQncyBleHBlY3RhdGlvbiBvZiAic29tZSB0aW1lIiBzbyB0aGF0J3Mg ZXZlbiBhbiBhc3BlY3QgdGhhdCBjb3VsZCBiZSB0ZXN0ZWQuIA0KKEUuZyB1c2UgTUFYX0xBVEVO Q1kgaW5zdGVhZCBvZiAiY291cGxlIG9mIHNlY29uZHMiPykNCg0KRXNrbw0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emku b3JnXQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjYsIDIwMTMgMTY6NDUNClRvOiBEaWprLCBF c2tvDQpDYzogY29yZSAoY29yZUBpZXRmLm9yZykNClN1YmplY3Q6IFJlOiBbY29yZV0gQ29BUCAn aW5maW5pdGUgdGltZW91dCcgdXNlIGNhc2UNCg0KT25lIGdlbmVyYWwgcnVsZSBpbiBDb0FQIGlz IHRoYXQgdGltZW91dHMgYXJlIG9uIHRoZSBtZXNzYWdlIGxheWVyLCBub3Qgb24gdGhlIHJlcXVl c3QvcmVzcG9uc2UgbGF5ZXIuDQoNCk1vc3QgbGlrZWx5LCB0aGVyZSB3aWxsIHN0aWxsIGJlIGEg bGltaXQgdG8gdGhlIHRpbWUgaW4gd2hpY2ggdGhlIHJlc3BvbnNlIGlzIHVzZWZ1bCB0byB0aGUg Y2xpZW50Lg0KRS5nLiwgaW4gdGhlIEhUVFAgd29ybGQsIG1hbnkgY2xpZW50cyBnaXZlIHVwIGFm dGVyIH4gNjAgc2Vjb25kcyAoZXZlbiBpZiB0aGUgVENQIGNvbm5lY3Rpb24gYmVsb3cgSFRUUCBo YXMgbG9uZ2VyIHRpbWVvdXRzKS4NCkJ1dCB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBIVFRQIHNw ZWMgdGhhdCBkZXNjcmliZXMgdGhlc2UgdGltZW91dHMuDQpJIGZpbmQgaXQgcXVpdGUgbG9naWNh bCB0aGF0IENvQVAgaGFzbid0IGFueXRoaW5nIGhlcmUgZWl0aGVyLg0KQnV0IG1heWJlIHRoZSBh bmFsb2d5IGlzIG5vdCBxdWl0ZSByaWdodCwgSSdkIGxpa2UgdG8gaGVhciBhYm91dCB0aGF0Lg0K KEtsYXVzIGhhcyBhIGRyYWZ0IHRoYXQgd291bGQgYWxsb3cgYSBjbGllbnQgdG8gZXZlbiBjYW5j ZWwgYW4gb3V0c3RhbmRpbmcgcmVxdWVzdCwgZHJhZnQtaGFydGtlLWNvcmUtY29hcC1saXZlbGlu ZXNzLikNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpQUy46DQoNCj4gKEkgc2VlIHRoZSBDb0FQIHBs dWd0ZXN0IHRlc3Qgc3BlY3MgaHR0cHM6Ly9naXRodWIuY29tL2NhYm8vdGQtY29hcDMgDQo+IG9u bHkgYWRkcmVzcyB0aW1lb3V0cyBvZiAiYSBjb3VwbGUgb2Ygc2Vjb25kcyIpDQoNCldoYXQgc3Bl Y2lmaWMgdGVzdCBhcmUgYXJlIHlvdSByZWZlcnJpbmcgaGVyZT8NCldlIGRpZG4ndCB0ZXN0IGFu eSBjbGllbnQgdGltZW91dCBmb3Igc2VwYXJhdGUgcmVzcG9uc2VzLg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBh cHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRk cmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJl IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24s IG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBh bmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kg YWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUgDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxp bmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlDQo= From ndamour@sierrawireless.com Wed Nov 27 02:17:17 2013 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 AF4141ADEB5 for ; Wed, 27 Nov 2013 02:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 t1w336nva8Gu for ; Wed, 27 Nov 2013 02:17:15 -0800 (PST) Received: from carmd-sa01.sierrawireless.com (carmd-sa01.sierrawireless.com [208.81.121.45]) by ietfa.amsl.com (Postfix) with ESMTP id 434DD1A1F61 for ; Wed, 27 Nov 2013 02:17:15 -0800 (PST) X-ASG-Debug-ID: 1385547422-0252477cbd56ce0001-aa7cYp Received: from carmd-exchhub02.sierrawireless.local (carmd-exchhub02.sierrawireless.local [10.0.6.5]) by carmd-sa01.sierrawireless.com with ESMTP id i9QBZA4XdSCVkoOs (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Nov 2013 02:17:02 -0800 (PST) X-Barracuda-Envelope-From: ndamour@sierrawireless.com X-ASG-Whitelist: Client Received: from carmd-exchmb01.sierrawireless.local ([10.0.6.3]) by carmd-exchhub02.sierrawireless.local ([::1]) with mapi; Wed, 27 Nov 2013 02:17:02 -0800 From: Nicolas Damour To: "core@ietf.org" Date: Wed, 27 Nov 2013 02:17:00 -0800 Thread-Topic: [core] Security use cases for CoRE X-ASG-Orig-Subj: RE: [core] Security use cases for CoRE Thread-Index: Ac7qsBCMQ8MmWiHCS8quoKyqKQMipwAXN0wA Message-ID: <9287D1909D3EEA4E92505D48604887E9EA273A61C1@carmd-exchmb01.sierrawireless.local> References: <52933469.40600@sics.se> <52934E73.7020004@gmail.com> <46A1DF3F04371240B504290A071B4DB63E3A3683@SZXEMA510-MBX.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABF07F@SZXEMA501-MBS.china.huawei.com> <9287D1909D3EEA4E92505D48604887E9EA273A6069@carmd-exchmb01.sierrawireless.local> <5294A9C6.4090201@tzi.de> In-Reply-To: <5294A9C6.4090201@tzi.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Barracuda-Connect: carmd-exchhub02.sierrawireless.local[10.0.6.5] X-Barracuda-Start-Time: 1385547422 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://carmd-sa01.sierrawireless.com:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sierrawireless.com X-Barracuda-BRTS-Status: 1 Subject: Re: [core] Security use cases for CoRE 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, 27 Nov 2013 10:17:18 -0000 VGhhbmtzIFN0ZWZhbmllIGZvciB5b3VyIGV4cGxhbmF0aW9uLg0KDQpJIHNlZSB0aGF0IG15IHVu ZGVyc3RhbmRpbmcgb2YgYXV0aGVudGljYXRpb24gd2FzIHRvbyByZXN0cmljdGVkIChyZXN0cmlj dGVkIHRvIHRoZSBpZGVudGl0eSksIGFuZCBJIGNhbiBvbmx5IGFncmVlIHdpdGggeW91IDopDQoN Ck5pY29sYXMuDQoNCk5pY29sYXMgREFNT1VSwqA6OsKgU2VuaW9yIE1hbmFnZXIsIEJ1c2luZXNz IGFuZCBJbm5vdmF0aW9uIERldmVsb3BtZW50DQpTSUVSUkEgV0lSRUxFU1PCoDo6wqBDVE8gT2Zm aWNlDQpQaG9uZSArMzMgKDApIDY3MCA3MDYgMDAzDQpMYWtlIFBhcmsgLSBaQUMgZGUgbCdIZXJz IC0gQWxsw6llIGR1IExhYyAtIEJQIDg3MjE2IDo6IDMxNjcyIExhYsOoZ2UgQ2VkZXggOjogRnJh bmNlDQpuZGFtb3VyQHNpZXJyYXdpcmVsZXNzLmNvbSA6OiB3d3cuc2llcnJhd2lyZWxlc3MuY29t DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogY29yZSBbbWFpbHRvOmNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdGVmYW5pZSBHZXJkZXMNCkVudm95w6nC oDogbWFyZGkgMjYgbm92ZW1icmUgMjAxMyAxNTowMg0Kw4DCoDogY29yZUBpZXRmLm9yZw0KT2Jq ZXTCoDogUmU6IFtjb3JlXSBTZWN1cml0eSB1c2UgY2FzZXMgZm9yIENvUkUNCg0KSGksDQoNCk9u IDExLzI2LzIwMTMgMTA6NTAgQU0sIE5pY29sYXMgRGFtb3VyIHdyb3RlOg0KPiBIZWxsby4NCj4g DQo+IEkgbWF5IGJlIHN3aW1taW5nIGFnYWluc3QgdGhlIGN1cnJlbnQgaGVyZSwgc28gSeKAmW0g c29ycnkgdG8gYmUgYSBsaXR0bGUgaWNvbm9jbGFzdCBoZXJlIChhbmQgaWYgSSBhbSB3cm9uZywg cGxlYXNlIGFjY2VwdCBteSBhcG9sb2dpZXMgaW4gYWR2YW5jZSkuDQo+IEkgd291bGQgc2F5IHRo YXQgZnJvbSBhIHN0cmljdCB0aGVvcmV0aWNhbCBwb2ludCBvZiB2aWV3LCBhdXRob3JpemF0aW9u IGRvZXMgYWJzb2x1dGVseSBub3QgcmVxdWlyZSBhdXRoZW50aWNhdGlvbi4NCj4gDQo+IEEgdmVy eSBzaW1wbGUgZXhhbXBsZSBpbiB0aGUgcGh5c2ljYWwgd29ybGQgaXMgYWNjZXNzIHRvIGEgc2Fm ZSBpbiBzb21lIChwb3NzaWJseSBTd2lzcykgYmFua3MuDQo+IEFzIGxvbmcgYXMgeW91IGhhdmUg dGhlIGtleSAob3IgcGFzc2NvZGUpLCB5b3UgY2FuIGdldCBhY2Nlc3MgdG8gdGhlIHNhZmUuDQo+ IEFuZCBubyBvbmUgd2lsbCBldmVyIGFzayB5b3UgZm9yIHlvdXIgaWRlbnRpdHkuDQo+IEFzIGEg bWF0dGVyIG9mIGZhY3QsIGluIHNvbWUgb2YgdGhlc2UgY2FzZXMgaXQgaXMgYWJzb2x1dGVseSBl c3NlbnRpYWwgdGhhdCBhdXRob3JpemF0aW9uIGhhcHBlbnMgd2l0aCBubyBmb3JtIG9mIGF1dGhl bnRpY2F0aW9uIHdoYXRzb2V2ZXIuDQoNCkkgdGhpbmsgeW91ciBiYW5rIGV4YW1wbGUgaXMgc3Rp bGwgYXV0aGVudGljYXRpb24uIFRoZSBkZWZpbml0aW9uIGluIFJGQw0KNDk0OSBzdGF0ZXMgdGhh dCBhdXRoZW50aWNhdGlvbiBpcyAiVGhlIHByb2Nlc3Mgb2YgdmVyaWZ5aW5nIGEgY2xhaW0gdGhh dCBhIHN5c3RlbSBlbnRpdHkgb3Igc3lzdGVtIHJlc291cmNlIGhhcyBhIGNlcnRhaW4gYXR0cmli dXRlIHZhbHVlLiINCg0KVGhpcyBtZWFucyB0aGF0IHlvdSBhcmUgbm90IG5lY2Vzc2FyaWx5IHZl cmlmeWluZyB0aGUgaWRlbnRpdHkgb2YgYSBzdWJqZWN0IGJ1dCB2ZXJpZnkgYSBjZXJ0YWluIGF0 dHJpYnV0ZSBvZiB0aGUgc3ViamVjdCwgZS5nLiBpZiBpdCBoYXMgYSBjZXJ0YWluIGtleS4NCg0K SWYgd2Ugd2FudCB0byBkaXN0aW5ndWlzaCBlbnRpdGllcyBhbmQgZ2l2ZSBkaWZmZXJlbnQgYWNj ZXNzIHJpZ2h0cyB0byBkaWZmZXJlbnQgZW50aXRpZXMgd2Ugd2lsbCBhbHdheXMgbmVlZCBhdXRo ZW50aWNhdGlvbi4gV2l0aG91dCBhdXRoZW50aWNhdGlvbiB3ZSBjYW4gb25seSBncmFudCB0aGUg c2FtZSBhY2Nlc3MgcmlnaHRzIHRvIGV2ZXJ5IGVudGl0eS4NCg0KQmVzdCByZWdhcmRzLA0KU3Rl ZmZpDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From esko.dijk@philips.com Wed Nov 27 05:17:35 2013 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 602D11A1F19 for ; Wed, 27 Nov 2013 05:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNRESOLVED_TEMPLATE=1.252] 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 lLTO6VXnGklC for ; Wed, 27 Nov 2013 05:17:32 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 199F91A1F00 for ; Wed, 27 Nov 2013 05:17:32 -0800 (PST) Received: from mail36-co9-R.bigfish.com (10.236.132.249) by CO9EHSOBE035.bigfish.com (10.236.130.98) with Microsoft SMTP Server id 14.1.225.22; Wed, 27 Nov 2013 13:17:31 +0000 Received: from mail36-co9 (localhost [127.0.0.1]) by mail36-co9-R.bigfish.com (Postfix) with ESMTP id 61C7AD002B4 for ; Wed, 27 Nov 2013 13:17:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(zz217bI15d6Oc85fh9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h1155h) Received: from mail36-co9 (localhost.localdomain [127.0.0.1]) by mail36-co9 (MessageSwitch) id 1385558249688711_5203; Wed, 27 Nov 2013 13:17:29 +0000 (UTC) Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.248]) by mail36-co9.bigfish.com (Postfix) with ESMTP id A3BAC1C006B; Wed, 27 Nov 2013 13:17:29 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 27 Nov 2013 13:17:28 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.03.0158.002; Wed, 27 Nov 2013 13:17:26 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: Which IPv6 multicast scopes for the "All CoAP Nodes" address? Thread-Index: Ac7rcvvkVU2ar6eHR+2s01dMYO1xPw== Date: Wed, 27 Nov 2013 13:17:25 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC421C2@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180CC421C2011DB3MPN2082MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Subject: [core] Which IPv6 multicast scopes for the "All CoAP Nodes" address? 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, 27 Nov 2013 13:17:35 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180CC421C2011DB3MPN2082MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, in coap-18 it mentions for the IPv6 "All CoAP Nodes" address: Note that there is a distinct multicast address for each scope that interested CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local scopes only. which could raise some interoperability concerns: - CoAP nodes are not obliged to join any of these addresses; so mu= lticast discovery may not work in practice. A client may be tempted to instead use the "All Nodes" link-local IPv6 mult= icast address to send out a CoAP request, since IPv6 / 6LoWPAN-ND requires = joining this address. - CoAP nodes only join the link-local and/or site-local scoped add= ress, not others (admin-local, or the new "realm-local" defined in draft-dr= oms-6man-multicast-scopes-02) So a discovering client using e.g. admin-local may not find any CoAP nodes. My goal was to write some guidelines in groupcomm what IPv6 / IPv4 multicas= t addresses a CoAP server should join, and which addresses a discovering cl= ient should use. For now I will base on the information that core-coap provides; adding that= a server SHOULD join both the link-local and site-local "All CoAP nodes" I= Pv6 multicast addresses. regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED6180CC421C2011DB3MPN2082MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

in coap-18 it mentions for the IPv6 “All CoAP = Nodes” address:

 

Note that there is a distinct multicast address

      for each scope that i= nterested CoAP nodes should listen to; CoAP

      needs the Link-Local = and Site-Local scopes only.

 

which could raise some interoperability concerns:

-   =        CoAP nodes are not obliged to join any of these addresses; so= multicast discovery may not work in practice.
A client may be tempted to instead use the “All Nodes” link-loc= al IPv6 multicast address to send out a CoAP request, since IPv6 / 6LoWPAN-= ND requires joining this address.

-   =        CoAP nodes only join the link-local and/or site-local scoped = address, not others (admin-local, or the new “realm-local” defi= ned in draft-droms-6man-multicast-scopes-02)
So a discovering client using e.g. admin-local may not find any CoAP nodes.=

 

My goal was to write some guidelines in groupcomm wh= at IPv6 / IPv4 multicast addresses a CoAP server should join, and which add= resses a discovering client should use.

For now I will base on the information that core-coa= p provides; adding that a server SHOULD join both the link-local and site-l= ocal “All CoAP nodes” IPv6 multicast addresses.

 

regards,

Esko


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED6180CC421C2011DB3MPN2082MG_-- From trac+core@trac.tools.ietf.org Wed Nov 27 05:19:20 2013 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 64E0E1A1F4C for ; Wed, 27 Nov 2013 05:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 J6gZw7Ppj0W7 for ; Wed, 27 Nov 2013 05:19:18 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB8A1A1F5D for ; Wed, 27 Nov 2013 05:19:18 -0800 (PST) Received: from localhost ([127.0.0.1]:34053 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vlf1L-0001JA-AK; Wed, 27 Nov 2013 14:19:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 27 Nov 2013 13:19:11 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/356 Message-ID: <060.91cbb7f0396300e887521dbfdfaad3bc@trac.tools.ietf.org> X-Trac-Ticket-ID: 356 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Cc: core@ietf.org Subject: [core] #356: Which IPv6 multicast scopes for the "All CoAP Nodes" address? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 13:19:20 -0000 #356: Which IPv6 multicast scopes for the "All CoAP Nodes" address? in coap-18 it mentions for the IPv6 “All CoAP Nodes” address: Note that there is a distinct multicast address for each scope that interested CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local scopes only. which could raise some interoperability concerns: - CoAP nodes are not obliged to join any of these addresses; so multicast discovery may not work in practice. A client may be tempted to instead use the “All Nodes” link-local IPv6 multicast address to send out a CoAP request, since IPv6 / 6LoWPAN-ND requires joining this address. - CoAP nodes only join the link-local and/or site-local scoped address, not others (admin-local, or the new “realm-local” defined in draft-droms-6man-multicast-scopes-02) So a discovering client using e.g. admin-local may not find any CoAP nodes. My goal was to write some guidelines in groupcomm what IPv6 / IPv4 multicast addresses a CoAP server should join, and which addresses a discovering client should use. For now I will base on the information that core-coap provides; adding that a server SHOULD join both the link-local and site-local “All CoAP nodes” IPv6 multicast addresses. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new defect | Milestone: Priority: major | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Wed Nov 27 07:02:37 2013 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 60FCA1ADBE8 for ; Wed, 27 Nov 2013 07:02:37 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 7JiUxvmu05-o for ; Wed, 27 Nov 2013 07:02:33 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2357D1ADBC9 for ; Wed, 27 Nov 2013 07:02:33 -0800 (PST) Received: from mail32-db8-R.bigfish.com (10.174.8.235) by DB8EHSOBE031.bigfish.com (10.174.4.94) with Microsoft SMTP Server id 14.1.225.22; Wed, 27 Nov 2013 15:02:32 +0000 Received: from mail32-db8 (localhost [127.0.0.1]) by mail32-db8-R.bigfish.com (Postfix) with ESMTP id 226C66C043F; Wed, 27 Nov 2013 15:02:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz217bI15d6O9371Ic89bh542I9251Id799hdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzd9hz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh109h2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h1155h) Received: from mail32-db8 (localhost.localdomain [127.0.0.1]) by mail32-db8 (MessageSwitch) id 1385564549662309_24869; Wed, 27 Nov 2013 15:02:29 +0000 (UTC) Received: from DB8EHSMHS004.bigfish.com (unknown [10.174.8.231]) by mail32-db8.bigfish.com (Postfix) with ESMTP id 94122580040; Wed, 27 Nov 2013 15:02:29 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS004.bigfish.com (10.174.4.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 27 Nov 2013 15:02:29 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.03.0158.002; Wed, 27 Nov 2013 15:02:29 +0000 From: "Dijk, Esko" To: weigengyu , Carsten Bormann Thread-Topic: [core] CoAP 'infinite timeout' use case Thread-Index: Ac7qsAOxXW3ZPYkKRdGb4l5oB/zS2wADmKEAAAAOGCAAGkv2AAADHniAAAWZbgAADZOloA== Date: Wed, 27 Nov 2013 15:02:29 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC4228E@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED6180CC40FD0@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org" Subject: Re: [core] CoAP 'infinite timeout' use case 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, 27 Nov 2013 15:02:37 -0000 SGVsbG8gR2VuZ3l1LA0KDQp0aGVyZSBhcmUgYWxzbyBjYXNlcyB3aGVyZSBubyByZXNwb25zZSBp cyBleHBlY3RlZCwgZS5nLiBtZW50aW9uZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS0xNiNzZWN0aW9uLTIuNyAsIGFueSBzdWNjZXNzIHJl c3BvbnNlcyBhcmUgc3VwcHJlc3NlZCAtIG5vIHJlcG9ydGluZyBiYWNrIHRvIHRoZSBjbGllbnQg YXQgYWxsLiBUaGlzIHdvcmtzIGlmIHRoZSB1bmRlcmx5aW5nIElQIG11bHRpY2FzdCBjYW4gYmUg bWFkZSAicmVsaWFibGUgZW5vdWdoIiwgaS5lLiBzdGF0aXN0aWNhbGx5IHJlbGlhYmxlLCB3aGlj aCBpcyBhY2hpZXZlZCB0aHJvdWdoIE1QTC4gQW5kIHRoZSBjbGllbnQgZG9lc24ndCBuZWVkIHRv IHdhaXQuDQpGb3IgdGhlIG5leHQgZ3JvdXBjb21tIHVwZGF0ZSBJIGRlZmluZSByZWxpYWJsZSBt dWx0aWNhc3QgYXMgbW9yZSBzdHJpbmdlbnQgdGhhbiB0aGF0LCBuYW1lbHkgdGhlIGNsaWVudCB3 b3VsZCBnZXQgY29uZmlybWF0aW9uIG9mIHRvIHdoaWNoIG5vZGVzIHRoZSByZXF1ZXN0IGNvdWxk IGJlIGRlbGl2ZXJlZCBhbmQgdG8gd2hpY2ggbm90Lg0KDQpGb3IgdGhlIGNhc2VzIHdoZXJlIHRo ZSBjbGllbnQgd2FudHMgdG8gZ2V0IHJlc3BvbnNlcyBiYWNrLCBpdCBjYW4ganVzdCB3YWl0IHVz aW5nIGFuIGFwcGxpY2F0aW9uLXNwZWNpZmljIGNvbmZpZ3VyZWQgdGltZW91dCAod2hpY2ggbWF5 IGJlIGJhc2VkIG9uIGtub3dsZWRnZSBhYm91dCBleHBlY3RlZCBwcm9wYWdhdGlvbiB0aW1lIG9m IGEgbWVzc2FnZSB0aHJvdWdoIHRoZSBuZXR3b3JrLCBldGMuKS4NCg0KRXNrbw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogd2VpZ2VuZ3l1IFttYWlsdG86d2VpZ2VuZ3l1QGJ1 cHQuZWR1LmNuXQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMyAwOToyOQ0KVG86 IERpamssIEVza287IENhcnN0ZW4gQm9ybWFubg0KQ2M6IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbY29yZV0gQ29BUCAnaW5maW5pdGUgdGltZW91dCcgdXNlIGNhc2UNCg0KSGksIEVza28s DQoNCldoZW4gYSBjbGllbnQgc2VuZHMgYSByZXF1ZXN0IHRvIHR1cm4gb2ZmIDEwIGxpZ2h0cyBi eSBtdWx0aWNhc3QsICBpbW1lZGlhdGUgcmVzcG9uc2VzIGFyZSBleHBlY3RlZC4NCldoZW4gbWVz c2FnZXMgYXJlIHNlbmQgYnkgdW5yZWxpYWJsZSBtdWx0aWNhc3QsIGl0IGlzIHVuZGV0ZXJtaW5k ZWQgaG93IGxvbmcgdGhlIGNsaWVudCBtYXkgd2FpdC4NCg0KUmVnYXJkcywNCg0KR2VuZ3l1DQoN Ck5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINClNjaG9vbCBvZiBjb21wdXRlcg0KQmVpamluZyBV bml2ZXJzaXR5IG9mIFBvc3RzICYgVGVsZWNvbW11bmljYXRpb25zDQoNCi0tLS0t5Y6f5aeL6YKu 5Lu2LS0tLS0NCkZyb206IERpamssIEVza28NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjcs IDIwMTMgMjowMiBQTQ0KVG86IHdlaWdlbmd5dSA7IENhcnN0ZW4gQm9ybWFubg0KQ2M6IGNvcmVA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbY29yZV0gQ29BUCAnaW5maW5pdGUgdGltZW91dCcgdXNl IGNhc2UNCg0KDQpJIGRvbid0IHNlZSBhIHByb2JsZW0gZm9yIHRoZSBpbW1lZGlhdGUgcmVzcG9u c2VzIHJlcXVpcmVkIGZvciBjb250cm9sDQphcHBsaWNhdGlvbnMuIFRoZSBzZXJ2ZXIgY291bGQv c2hvdWxkIHRoZW4ganVzdCByZXNwb25kIGltbWVkaWF0ZWx5IHdpdGggdGhlDQpQaWdneS1iYWNr ZWQgcmVzcG9uc2UgYXMgaGludGVkIGluIHNlY3Rpb24gNS4yLjEsIGFuZCBkb2luZyB0aGlzIHRo ZSBwcm9ibGVtDQpkb2Vzbid0IG9jY3VyLg0KDQpIb3dldmVyLCBmb3Igc2VwYXJhdGUgcmVzcG9u c2VzIChpZiB0aGUgcmVzcG9uc2UgZ2VuZXJhdGlvbiB0YWtlcyBsb25nZXINCnRoYW4gYSBmZXcg c2Vjb25kcykgdGhlcmUgYXJlIGN1cnJlbnRseSBubyBzdGFuZGFyZCBtZWNoYW5pc21zIHNvIHRo ZSBjbGllbnQNCndvdWxkIGhhdmUgdG8ga25vdyBiZWZvcmVoYW5kIGFwcHJveGltYXRlbHkgaG93 IGxvbmcgdGhlIHNlcnZlciB3aWxsIHRha2UgYXQNCm1vc3QgdG8gcHJvY2VzcyB0aGUgcmVxdWVz dCB0byBhIHNwZWNpZmljIHJlc291cmNlLiBJIGhhdmVuJ3QgZW5jb3VudGVyZWQNCmFueSBwcmFj dGljYWwgcHJvYmxlbXMgd2l0aCB0aGlzIHlldCBleGNlcHQgZm9yIHVzZSBjYXNlcyBvZiByZXF1 ZXN0IHF1ZXVpbmcNCmJ5IGEgQ29BUCBwcm94eS4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogd2VpZ2VuZ3l1IFttYWlsdG86d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNu XQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMyAwNToxOQ0KVG86IERpamssIEVz a287IENhcnN0ZW4gQm9ybWFubg0KQ2M6IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29y ZV0gQ29BUCAnaW5maW5pdGUgdGltZW91dCcgdXNlIGNhc2UNCg0KSGksIEVza28gYW5kIENhcnN0 ZW4sDQoNCkkgZG8gbm90IGFncmVlLg0KVGhlIG9yaWdpbmFsIGludGVudGlvbiBvZiBIVFRQIGlz IHRvIGRvd25sb2FkIFdFQiBwYWdlIGZvciBwZXJzb25hbCByZWFkaW5nLg0KQnV0IENvQVAgaXMg Zm9yIE0yTSBjb250cm9sLg0KDQpSZXF1ZXN0IGZvciBjb250cm9sIG1heSByZXF1aXJlIGltbWVk aWF0ZSBvciB0aW1lLWxpbWl0ZWQgcmVzcG9uc2VzLg0KVGhlIG1lc3NhZ2UgbGF5ZXIgdGltZXNv dXQgaXMgbm90IGVub3VnaCBmb3IgdGhpcy4NCkNvQVAgc2hvdWxkIGluY2x1ZGVzIHRpbWVvdXQg YXQgdHJhbnNhY3Rpb24gc3ViLWxheWVyLg0KDQpUaGlzIG1heSBiZSB0aGUgb25lIG9mIHdoYXQg Q29BUCBpcyBkaWZmZXJlbnQgZnJvbSBIVFRQLg0KDQpyZWdhcmRzLA0KDQpHZW5neXUNCg0KTmV0 d29yayBUZWNobm9sb2d5IENlbnRlcg0KU2Nob29sIG9mIENvbXB1dGVyDQpCZWlqaW5nIFVuaXZl cnNpdHkgb2YgUG9zdHMgJiBUZWxlY29tbXVuaWNhdGlvbnMNCg0KLS0tLS3ljp/lp4vpgq7ku7Yt LS0tLQ0KRnJvbTogRGlqaywgRXNrbw0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyNywgMjAx MyAxMjowMyBBTQ0KVG86IENhcnN0ZW4gQm9ybWFubg0KQ2M6IGNvcmUgKGNvcmVAaWV0Zi5vcmcp DQpTdWJqZWN0OiBSZTogW2NvcmVdIENvQVAgJ2luZmluaXRlIHRpbWVvdXQnIHVzZSBjYXNlDQoN CkFncmVlLCBJIHdhcyBzb21ld2hhdCBleHBlY3RpbmcgdGhhdCBDb0FQIHdvdWxkIGZvbGxvdyBI VFRQIGluIHRoaXMgcmVzcGVjdC4NCkkgZGlkIG5vdGljZSB0aGF0IGZvciBIVFRQIGl0IGlzIGV4 cGxpY2l0bHkgc3RhdGVkIHRoYXQgbm8gdGltZW91dHMgYXJlDQpuZWVkZWQgYnV0IHRoYXQgdGhl eSBtYXkgKE1BWT8pIGJlIHByZXNlbnQ7DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWh0dHBiaXMtcDEtbWVzc2FnaW5nLTI1I3NlY3Rpb24tNi41DQoNCkkgdGhpbmsgdGhl IENvQVAgc3BlYyBjb3VsZCBhdCBsZWFzdCBtYWtlcyBhIHNpbWlsYXIgcmVtYXJrOyBjdXJyZW50 bHkgaXQncw0Kbm90IG1lbnRpb25lZC4NCg0KRm9yIGltcGxlbWVudGVycyBpdCdzIHBlcmhhcHMg dXNlZnVsIGF0IHNvbWUgcG9pbnQgdG8ga25vdyB3aGF0IG1ldGhvZHMgLw0KYmVzdCBwcmFjdGlj ZXMgdG8gdXNlIHRvIGRldGVjdCB0aGUgJ3NlcnZlciBkZWFkJyBjYXNlOyBzaW1pbGFyIHRvIHRo ZSBjYXNlDQpmb3IgVENQIG9mIGhhbGYtb3BlbiBjb25uZWN0aW9ucyBhbmQgZGV0ZWN0aW9uIHRo ZXJlb2Ygd2hlcmUgc29tZSBhcHByb2FjaGVzDQphcmUgZG9jdW1lbnRlZC4gSSBhc3N1bWUgZm9y IG5vdyBpdCBpcyB0aW1lci1iYXNlZCB3aXRoIGEgY3VzdG9tIHRpbWVvdXQNCnZhbHVlLCB3aGVy ZSB0aGUgdmFsdWUgbXVzdCBub3QgYmUgbG93ZXIgdGhhbiBNQVhfTEFURU5DWS4NCg0KPiBXaGF0 IHNwZWNpZmljIHRlc3QgYXJlIGFyZSB5b3UgcmVmZXJyaW5nIGhlcmU/DQo+IFdlIGRpZG4ndCB0 ZXN0IGFueSBjbGllbnQgdGltZW91dCBmb3Igc2VwYXJhdGUgcmVzcG9uc2VzLg0KT29wcywgSSBk aWRuJ3QgbWVhbiB0byBzYXkgdGltZW91dCBoZXJlIGJ1dCB0aW1lIHRha2VuIGJ5IHRoZSBzZXJ2 ZXIgZm9yDQpwcm9jZXNzaW5nIHRoZSByZXF1ZXN0LiBJdCBtZW50aW9ucyAiIFNvbWUgdGltZSAo YSBjb3VwbGUgb2Ygc2Vjb25kcykNCmVsYXBzZXMiIGluIHRoZSBiYXNlLmh0bWwgdGVzdCBzcGVj cy4NCkEgc2ltaWxhciBjYXNlIG9jY3VycyB3aGVuIHRoaXMgInNvbWUgdGltZSIgaXMgaGlnaGVy IHRoYW4gdGhlIGNsaWVudCdzDQpleHBlY3RhdGlvbiBvZiAic29tZSB0aW1lIiBzbyB0aGF0J3Mg ZXZlbiBhbiBhc3BlY3QgdGhhdCBjb3VsZCBiZSB0ZXN0ZWQuDQooRS5nIHVzZSBNQVhfTEFURU5D WSBpbnN0ZWFkIG9mICJjb3VwbGUgb2Ygc2Vjb25kcyI/KQ0KDQpFc2tvDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5v cmddDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNiwgMjAxMyAxNjo0NQ0KVG86IERpamssIEVz a28NCkNjOiBjb3JlIChjb3JlQGlldGYub3JnKQ0KU3ViamVjdDogUmU6IFtjb3JlXSBDb0FQICdp bmZpbml0ZSB0aW1lb3V0JyB1c2UgY2FzZQ0KDQpPbmUgZ2VuZXJhbCBydWxlIGluIENvQVAgaXMg dGhhdCB0aW1lb3V0cyBhcmUgb24gdGhlIG1lc3NhZ2UgbGF5ZXIsIG5vdCBvbg0KdGhlIHJlcXVl c3QvcmVzcG9uc2UgbGF5ZXIuDQoNCk1vc3QgbGlrZWx5LCB0aGVyZSB3aWxsIHN0aWxsIGJlIGEg bGltaXQgdG8gdGhlIHRpbWUgaW4gd2hpY2ggdGhlIHJlc3BvbnNlDQppcyB1c2VmdWwgdG8gdGhl IGNsaWVudC4NCkUuZy4sIGluIHRoZSBIVFRQIHdvcmxkLCBtYW55IGNsaWVudHMgZ2l2ZSB1cCBh ZnRlciB+IDYwIHNlY29uZHMgKGV2ZW4gaWYNCnRoZSBUQ1AgY29ubmVjdGlvbiBiZWxvdyBIVFRQ IGhhcyBsb25nZXIgdGltZW91dHMpLg0KQnV0IHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIEhUVFAg c3BlYyB0aGF0IGRlc2NyaWJlcyB0aGVzZSB0aW1lb3V0cy4NCkkgZmluZCBpdCBxdWl0ZSBsb2dp Y2FsIHRoYXQgQ29BUCBoYXNuJ3QgYW55dGhpbmcgaGVyZSBlaXRoZXIuDQpCdXQgbWF5YmUgdGhl IGFuYWxvZ3kgaXMgbm90IHF1aXRlIHJpZ2h0LCBJJ2QgbGlrZSB0byBoZWFyIGFib3V0IHRoYXQu DQooS2xhdXMgaGFzIGEgZHJhZnQgdGhhdCB3b3VsZCBhbGxvdyBhIGNsaWVudCB0byBldmVuIGNh bmNlbCBhbiBvdXRzdGFuZGluZw0KcmVxdWVzdCwgZHJhZnQtaGFydGtlLWNvcmUtY29hcC1saXZl bGluZXNzLikNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpQUy46DQoNCj4gKEkgc2VlIHRoZSBDb0FQ IHBsdWd0ZXN0IHRlc3Qgc3BlY3MgaHR0cHM6Ly9naXRodWIuY29tL2NhYm8vdGQtY29hcDMNCj4g b25seSBhZGRyZXNzIHRpbWVvdXRzIG9mICJhIGNvdXBsZSBvZiBzZWNvbmRzIikNCg0KV2hhdCBz cGVjaWZpYyB0ZXN0IGFyZSBhcmUgeW91IHJlZmVycmluZyBoZXJlPw0KV2UgZGlkbid0IHRlc3Qg YW55IGNsaWVudCB0aW1lb3V0IGZvciBzZXBhcmF0ZSByZXNwb25zZXMuDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkNCnByb3RlY3RlZCB1bmRl ciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUN CmFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQNCnRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5h dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcw0Kc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJl Y2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBk ZXN0cm95IGFsbCBjb3BpZXMNCm9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QN CmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29y ZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5 IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRp bmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBl LW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From esko.dijk@philips.com Wed Nov 27 07:13:51 2013 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 7C3B61ADEA3 for ; Wed, 27 Nov 2013 07:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.551 X-Spam-Level: X-Spam-Status: No, score=0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001] 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 PWja-BImxvkj for ; Wed, 27 Nov 2013 07:13:42 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id E30811ADBC9 for ; Wed, 27 Nov 2013 07:13:41 -0800 (PST) Received: from mail124-db9-R.bigfish.com (10.174.16.250) by DB9EHSOBE027.bigfish.com (10.174.14.90) with Microsoft SMTP Server id 14.1.225.22; Wed, 27 Nov 2013 15:13:40 +0000 Received: from mail124-db9 (localhost [127.0.0.1]) by mail124-db9-R.bigfish.com (Postfix) with ESMTP id 95BAA4E056D; Wed, 27 Nov 2013 15:13:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(z579ehz217bI15d6Oc89bh1be0Ic85bh1432I9251I4015I14ffIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL18c58eh17326ah8275bh8275dh18c673h1de097h186068hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h1155h) Received: from mail124-db9 (localhost.localdomain [127.0.0.1]) by mail124-db9 (MessageSwitch) id 1385565218691338_7370; Wed, 27 Nov 2013 15:13:38 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.239]) by mail124-db9.bigfish.com (Postfix) with ESMTP id A45C0360071; Wed, 27 Nov 2013 15:13:38 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 27 Nov 2013 15:13:37 +0000 Received: from 011-DB3MMR1-017.MGDPHG.emi.philips.com (10.128.28.102) by 011-DB3MMR1-007.MGDPHG.emi.philips.com (10.128.28.57) with Microsoft SMTP Server (TLS) id 14.3.158.2; Wed, 27 Nov 2013 15:13:37 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-017.MGDPHG.emi.philips.com ([10.128.28.102]) with mapi id 14.03.0158.002; Wed, 27 Nov 2013 15:13:37 +0000 From: "Dijk, Esko" To: Likepeng , "core@ietf.org" Thread-Topic: [core] How to correlate request and responses in group communication Thread-Index: Ac7rG1cGT4fNhozCS7KwdPTKZ1kSxwAIgb/gAAIa26AADwLsQA== Date: Wed, 27 Nov 2013 15:13:37 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180CC422AA011DB3MPN2082MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [core] How to correlate request and responses in group communication 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, 27 Nov 2013 15:13:51 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180CC422AA011DB3MPN2082MG_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WWVzLCBpdKGvcyBjdXJyZW50bHkgZGVmaW5lZCB0byB1c2UgdGhlIFVEUCBsYXllciBmb3IgdGhh dCBpbmZvcm1hdGlvbi4gQXQgbGVhc3QgaXShr3MgZWZmaWNpZW50IDopDQoNCklmIGluZm9ybWF0 aW9uIG90aGVyIHRoYW4gSVAgYWRkcmVzcyBpcyBuZWVkZWQsIHN1Y2ggYXMgYSBub24tdm9sYXRp bGUgR1VJRCwgdGhlIENvQVAgc2VydmVyIGNvdWxkIGluY2x1ZGUgdGhpcyBhcyBwYXJ0IG9mIGl0 cyByZXNwb25zZSBwYXlsb2FkIChpbiBjYXNlIG9mIEdFVCBvciBQVVQpLg0KQnV0IHRoYXShr3Mg bm90IHRoZSBtb3N0IGJlYXV0aWZ1bCBzb2x1dGlvbiBJIGFncmVlLg0KDQpFc2tvDQoNCkZyb206 IExpa2VwZW5nIFttYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwg Tm92ZW1iZXIgMjcsIDIwMTMgMDk6MzINClRvOiBEaWprLCBFc2tvOyBjb3JlQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW2NvcmVdIEhvdyB0byBjb3JyZWxhdGUgcmVxdWVzdCBhbmQgcmVzcG9uc2Vz IGluIGdyb3VwIGNvbW11bmljYXRpb24NCg0KSGkgRXNrbywNCg0KPlRoZSBpZGVudGlmaWNhdGlv biBvZiB0aGUgaW5kaXZpZHVhbCByZXNwb25zZSBpcyBieSB0aGUgKHVuaWNhc3QpIElQIHNvdXJj ZSBhZGRyZXNzIG9mIHRoZSByZXNwb25kaW5nIENvQVAgZW5kcG9pbnQuDQoNCkluIHRoZSByZXNw b25zZSwgdGhlIG9ubHkgcGxhY2UgdG8gcHV0IHRoZSAodW5pY2FzdCkgSVAgc291cmNlIGFkZHJl c3MgaXMgdGhlIFVEUCBsYXllciwgcmlnaHQ/IEJlY2F1c2UgSFJJLUhvc3QgaXMgdXNlZCB0byBp bmRpY2F0ZSB0aGUgdGFyZ2V0IG5vZGUsIG5vdCB0aGUgc291cmNlIG5vZGUuDQoNCihDb0FQIHNl Y3Rpb24gNS4xMC4xKSBUaGUgVXJpLUhvc3QsIFVyaS1Qb3J0LCBVcmktUGF0aCBhbmQgVXJpLVF1 ZXJ5IE9wdGlvbnMgYXJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgdGFyZ2V0IHJlc291cmNlIG9mIGEg cmVxdWVzdCB0byBhIENvQVAgb3JpZ2luIHNlcnZlci4NCg0KVGhhdCBtZWFucywgdGhlIHJlcXVl c3RvciBoYXMgdG8gcmVseSBvbiBVRFAgbGF5ZXIgdG8gZ2V0IHRoZSAodW5pY2FzdCkgSVAgc291 cmNlIGFkZHJlc3MgZnJvbSB0aGUgcmVzcG9uc2UsIHRoZW4gY29ycmVsYXRlIHRoZSBtdWx0aWNh c3QgcmVxdWVzdCBhbmQgdGhlIHVuaWNhc3QgcmVzcG9uc2UuIEJ1dCBpbiBteSBvcGluaW9uLCB0 aGUgY29ycmVsYXRpb24gc2hvdWxkIGJlIGRvbmUgaW4gdGhlIENvQVAgbGF5ZXIuIENvQVAgbGF5 ZXIgc2hvdWxkIHByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiB0byBiZSB1c2VkIGZvciB0aGlzIHB1 cnBvc2UuDQoNCkluIENvQVAgc3BlYywgaXQgbWVudGlvbnMgdGhhdCBUb2tlbiBNVVNUIGJlIHVz ZWQgdG8gbWF0Y2ggdGhlIHJlc3BvbnNlcyB3aXRoIHRoZSBtdWx0aWNhc3QgcmVxdWVzdC4gSWYg dGhlcmUgYXJlIG11bHRpcGxlIHJlc3BvbnNlcywgd2UgaGF2ZSB0byB1c2Ugc291cmNlIGVuZHBv aW50IHRvIGRpZmZlcmVudGlhdGUuIEJ1dCB0aGlzIGluZm9ybWF0aW9uIGNhbiBiZSBvbmx5IGdv dCBmcm9tIFVEUCBsYXllci4gVGhhdCBpcyBhbiBpc3N1ZSwgaW4gbXkgb3Bpbmlvbi4NCg0KQ29B UCBTZWN0aW9uIDguMg0KICAgV2hlbiBtYXRjaGluZyBhIHJlc3BvbnNlIHRvIGEgbXVsdGljYXN0 IHJlcXVlc3QsIG9ubHkgdGhlIHRva2VuIE1VU1QNCiAgIG1hdGNoOyB0aGUgc291cmNlIGVuZHBv aW50IG9mIHRoZSByZXNwb25zZSBkb2VzIG5vdCBuZWVkIHRvIChhbmQgd2lsbA0KICAgbm90KSBi ZSB0aGUgc2FtZSBhcyB0aGUgZGVzdGluYXRpb24gZW5kcG9pbnQgb2YgdGhlIG9yaWdpbmFsIHJl cXVlc3QuDQoNCkFueSB0aG91Z2h0cz8NCg0KVGhhbmtzLA0KS2luZCBSZWdhcmRzDQpLZXBlbmcN Cg0Kt6K8/sjLOiBEaWprLCBFc2tvIFttYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tXQ0Kt6LL zcqxvOQ6IDIwMTPE6jEx1MIyN8jVIDE1OjAxDQrK1bz+yMs6IExpa2VwZW5nOyBjb3JlQGlldGYu b3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0K1vfM4jogUkU6IFtjb3JlXSBIb3cgdG8gY29ycmVs YXRlIHJlcXVlc3QgYW5kIHJlc3BvbnNlcyBpbiBncm91cCBjb21tdW5pY2F0aW9uDQoNCkhlbGxv IEtlcGVuZywNCg0KVGhlIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBpbmRpdmlkdWFsIHJlc3BvbnNl IGlzIGJ5IHRoZSAodW5pY2FzdCkgSVAgc291cmNlIGFkZHJlc3Mgb2YgdGhlIHJlc3BvbmRpbmcg Q29BUCBlbmRwb2ludC4NCkluZGVlZCB0aGlzIHdvdWxkIGJlIGdvb2QgdG8gbWVudGlvbiBzb21l d2hlcmUgaW4gZ3JvdXBjb21tLg0KQ29ycmVsYXRpb24gb2YgYSBzaW5nbGUgcmVxdWVzdCB3aXRo IGEgc2V0IG9mIHJlc3BvbnNlcyBpcyB2aWEgVG9rZW47IGluIGNhc2UgdGhlcmUgYXJlIG11bHRp cGxlIG91dHN0YW5kaW5nIG11bHRpY2FzdCByZXF1ZXN0cyBmcm9tIGEgc2luZ2xlIGVuZHBvaW50 Lg0KDQpBbHNvIGNvcmUtY29hcCBoYXMgc29tZSBpbmZvcm1hdGlvbiBvbiB1c2Ugb2YgSVAgYWRk cmVzcyBvZiB0aGUgcmVzcG9uZGluZyBlbmRwb2ludCwgc2VjdGlvbiA4LjI6DQoNCkZvciB0aGUg cHVycG9zZXMgb2YgaW50ZXJwcmV0aW5nIHRoZSBMb2NhdGlvbi0qIG9wdGlvbnMgYW5kIGFueSBs aW5rcw0KICAgZW1iZWRkZWQgaW4gdGhlIHJlcHJlc2VudGF0aW9uIGFuZCwgdGhlIHJlcXVlc3Qg VVJJIChiYXNlIFVSSSkNCiAgIHJlbGF0aXZlIHRvIHdoaWNoIHRoZSByZXNwb25zZSBpcyBpbnRl cnByZXRlZCwgaXMgZm9ybWVkIGJ5IHJlcGxhY2luZw0KICAgdGhlIG11bHRpY2FzdCBhZGRyZXNz IGluIHRoZSBIb3N0IGNvbXBvbmVudCBvZiB0aGUgb3JpZ2luYWwgcmVxdWVzdA0KICAgVVJJIGJ5 IHRoZSBsaXRlcmFsIElQIGFkZHJlc3Mgb2YgdGhlIGVuZHBvaW50IGFjdHVhbGx5IHJlc3BvbmRp bmcuDQoNCkVza28NCg0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIExpa2VwZW5nDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI3LCAyMDEz IDAzOjUwDQpUbzogY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFtjb3JlXSBIb3cgdG8gY29ycmVsYXRlIHJlcXVlc3QgYW5kIHJlc3BvbnNlcyBpbiBncm91cCBj b21tdW5pY2F0aW9uDQoNCkhpIGFsbCwNCg0KV2hlbiBJIHJlYWQgdGhlIGdyb3VwIGNvbW11bmlj YXRpb24gZHJhZnQsIEkgY29tZSB1cCB3aXRoIG9uZSBxdWVzdGlvbiwgaG93IHRvIGNvcnJlbGF0 ZSBhIG11bHRpY2FzdCByZXF1ZXN0IHdpdGggdGhlIG11bHRpcGxlIHJlc3BvbnNlcyBmcm9tIGRp ZmZlcmVudCBub2Rlcz8NCg0KRm9yIGV4YW1wbGUsIGEgY2xpZW50IHNlbmRzIGEgbXVsdGljYXN0 IEdFVCByZXF1ZXN0IHRvIGEgZ3JvdXAgVVJJOiBhbGwuYmxkZzYuZXhhbXBsZS5jb20sIGFuZCBh ZnRlciBzb21lIHRpbWUsIGl0IHdpbGwgcmVjZWl2ZSBtdWx0aXBsZSByZXNwb25zZXMgZnJvbSBk aWZmZXJlbnQgbm9kZXMuIEluIHRoZSByZXF1ZXN0LCBpdCBjb250YWlucyBvbmUgdG9rZW4uIElu IHRoZSByZXNwb25zZXMsIEkgYXNzdW1lIHRoYXQgYWxsIHRoZSByZXNwb25zZXMgc2hvdWxkIHVz ZSB0aGUgc2FtZSB0b2tlbiBhY2NvcmRpbmcgdG8gdGhlIGJhc2UgY29hcCBzcGVjLiBUaGVuIGhv dyBjYW4gdGhlIGNsaWVudCBkaWZmZXJlbnRpYXRlIHRoZSBkaWZmZXJlbnQgcmVzcG9uc2VzIGZy b20gZGlmZmVyZW50IG5vZGVzLCBjb3JyZXNwb25kaW5nIHRvIHRoZSBzYW1lIHJlcXVlc3Q/DQoN Ckkgc2VhcmNoZWQgdGhlIHdob2xlIGdyb3VwIGNvbW11bmljYXRpb24gZHJhZnQsIHRva2VuIGlz IG5vdCBtZW50aW9uZWQuIFNvIEkgaG9wZSB0byBnZXQgb3BpbmlvbiBmcm9tIHRoZSBncm91cC4N Cg0KVGhhbmtzLA0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1h eSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUg bGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocyku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9k dWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVz IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K --_000_031DD135F9160444ABBE3B0C36CED6180CC422AA011DB3MPN2082MG_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Yes, = it=A1=AFs currently defined to use the UDP layer for that information. At l= east it=A1=AFs efficient :)

=  

If in= formation other than IP address is needed, such as a non-volatile GUID, the= CoAP server could include this as part of its response payload (in case of= GET or PUT).

But t= hat=A1=AFs not the most beautiful solution I agree.

=  

Esko<= o:p>

=  

From: Likepeng [mailto:likepeng@huawei.com]
Sent: Wednesday, November 27, 2013 09:32
To: Dijk, Esko; core@ietf.org
Subject: Re: [core] How to correlate request and responses in group = communication

 =

Hi Esko,

 

>T= he identification of the individual response is by the (unicast) IP source = address of the responding CoAP endpoint.

 

In the response, the o= nly place to put the (unicast) IP source address is the UDP layer, right? B= ecause HRI-Host is used to indicate the target node, not the source node.

 

(CoAP section 5.10.1) The Uri-Host, = Uri-Port, Uri-Path and Uri-Query Options are used to specify the target res= ource of a request to a CoAP origin server.

 

That means, the reques= tor has to rely on UDP layer to get the (unicast) IP source address from th= e response, then correlate the multicast request and the unicast response. = But in my opinion, the correlation should be done in the CoAP layer. CoAP layer should provide some information to b= e used for this purpose.

 

In CoAP spec, it menti= ons that Token MUST be used to match the responses with the multicast reque= st. If there are multiple responses, we have to use source endpoint to diff= erentiate. But this information can be only got from UDP layer. That is an issue, in my opinion.

 

CoAP Section 8.2<= /o:p>

   When matching a respons= e to a multicast request, only the token MUST

   match; the source endpo= int of the response does not need to (and will

   not) be t= he same as the destination endpoint of the original request.

 

Any thoughts?

 

Thanks,

Kind Regards

Kepeng

 

=B7=A2=BC=FE=C8= =CB: Dijk, Esko [mailto:esko.dijk@philips.co= m]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C227=C8=D5 15:01
=CA=D5=BC=FE=C8=CB: Likepeng; core@ietf.org
=D6=F7=CC=E2: RE: [core] How to correlat= e request and responses in group communication

 =

Hello= Kepeng,

 = ;

The i= dentification of the individual response is by the (unicast) IP source addr= ess of the responding CoAP endpoint.

Indee= d this would be good to mention somewhere in groupcomm.

Corre= lation of a single request with a set of responses is via Token; in case th= ere are multiple outstanding multicast requests from a single endpoint.

 = ;

Also = core-coap has some information on use of IP address of the responding endpo= int, section 8.2:

 = ;

For t= he purposes of interpreting the Location-* options and any links

 = ;  embedded in the representation and, the request URI (base URI)

 = ;  relative to which the response is interpreted, is formed by replaci= ng

 = ;  the multicast address in the Host component of the original request=

 = ;  URI by the literal IP address of the endpoint actually responding.<= /span>

 = ;

Esko<= /span>

 = ;

From: core [mailto:core-bounces@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: core@ietf.org
Subject: [core] How to correlate request and responses in group comm= unication

 =

Hi all,

 

When I read the group communication draft, I come up= with one question, how to correlate a multicast request with the multiple = responses from different nodes?

 

For example, a client sends a multicast GET request = to a group URI: all.bldg6.example.com, and after some time, it will receive= multiple responses from different nodes. In the request, it contains one t= oken. In the responses, I assume that all the responses should use the same token according to the base coap spe= c. Then how can the client differentiate the different responses from diffe= rent nodes, corresponding to the same request?

 

I searched the whole group communication draft, toke= n is not mentioned. So I hope to get opinion from the group.

 

Thanks,

Kind Regards

Kepeng

 

The information contained in this message may be confidential and= legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you ar= e hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are not = the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message= .

--_000_031DD135F9160444ABBE3B0C36CED6180CC422AA011DB3MPN2082MG_-- From weigengyu@bupt.edu.cn Wed Nov 27 08:13:45 2013 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 AB5901AE14B for ; Wed, 27 Nov 2013 08:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 QSHCgMvcPqkU for ; Wed, 27 Nov 2013 08:13:36 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id F01F31AE07F for ; Wed, 27 Nov 2013 08:13:32 -0800 (PST) Received: from WeiGengyuPC (unknown [221.218.46.96]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id F1C2D19F39C; Thu, 28 Nov 2013 00:13:27 +0800 (HKT) Message-ID: From: "weigengyu" To: "Dijk, Esko" , "Carsten Bormann" References: <031DD135F9160444ABBE3B0C36CED6180CC40E34@011-DB3MPN2-082.MGDPHG.emi.philips.com> <07CB6FA7-EA67-40D9-95BE-DFA1EC0E508F@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC40EBC@011-DB3MPN2-082.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED6180CC40FD0@011-DB3MPN2-082.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED6180CC4228E@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC4228E@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Thu, 28 Nov 2013 00:12:41 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] CoAP 'infinite timeout' use case 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, 27 Nov 2013 16:13:45 -0000 Hi Esko, I agree that wether to have responses is determined by the application, the question is what CoAP chooses to support. In the Internet area, as far as I know, IP layer protocols, including IP multicast, just do best effort. The "reliable enough", i.e. statistically reliable, is actually unreliable. The result of "And the client doesn't need to wait" is that "the alarming lights" are still on. I am happy to see "For the next groupcomm update I define reliable multicast as more stringent than that." In the Internet world, two alternatives are transport layer relialbe multicast or application reliable multicast. I prefer the application layer reliable mulitcast. And there may have some approaches to design the architecture. We will also "put" our ideas after the CoAP charter appeals for reliable multicast. The response delay is application requirements. The transaction sub-layer timesout is configured as applicaton-specific. The message sub-layer reliability is essential for message delivery, but not enough for transactions. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Dijk, Esko Sent: Wednesday, November 27, 2013 11:02 PM To: weigengyu ; Carsten Bormann Cc: core@ietf.org Subject: RE: [core] CoAP 'infinite timeout' use case Hello Gengyu, there are also cases where no response is expected, e.g. mentioned in http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.7 , any success responses are suppressed - no reporting back to the client at all. This works if the underlying IP multicast can be made "reliable enough", i.e. statistically reliable, which is achieved through MPL. And the client doesn't need to wait. For the next groupcomm update I define reliable multicast as more stringent than that, namely the client would get confirmation of to which nodes the request could be delivered and to which not. For the cases where the client wants to get responses back, it can just wait using an application-specific configured timeout (which may be based on knowledge about expected propagation time of a message through the network, etc.). Esko -----Original Message----- From: weigengyu [mailto:weigengyu@bupt.edu.cn] Sent: Wednesday, November 27, 2013 09:29 To: Dijk, Esko; Carsten Bormann Cc: core@ietf.org Subject: Re: [core] CoAP 'infinite timeout' use case Hi, Esko, When a client sends a request to turn off 10 lights by multicast, immediate responses are expected. When messages are send by unreliable multicast, it is undeterminded how long the client may wait. Regards, Gengyu Network Technology Center School of computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Dijk, Esko Sent: Wednesday, November 27, 2013 2:02 PM To: weigengyu ; Carsten Bormann Cc: core@ietf.org Subject: RE: [core] CoAP 'infinite timeout' use case I don't see a problem for the immediate responses required for control applications. The server could/should then just respond immediately with the Piggy-backed response as hinted in section 5.2.1, and doing this the problem doesn't occur. However, for separate responses (if the response generation takes longer than a few seconds) there are currently no standard mechanisms so the client would have to know beforehand approximately how long the server will take at most to process the request to a specific resource. I haven't encountered any practical problems with this yet except for use cases of request queuing by a CoAP proxy. Esko -----Original Message----- From: weigengyu [mailto:weigengyu@bupt.edu.cn] Sent: Wednesday, November 27, 2013 05:19 To: Dijk, Esko; Carsten Bormann Cc: core@ietf.org Subject: Re: [core] CoAP 'infinite timeout' use case Hi, Esko and Carsten, I do not agree. The original intention of HTTP is to download WEB page for personal reading. But CoAP is for M2M control. Request for control may require immediate or time-limited responses. The message layer timesout is not enough for this. CoAP should includes timeout at transaction sub-layer. This may be the one of what CoAP is different from HTTP. regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Dijk, Esko Sent: Wednesday, November 27, 2013 12:03 AM To: Carsten Bormann Cc: core (core@ietf.org) Subject: Re: [core] CoAP 'infinite timeout' use case Agree, I was somewhat expecting that CoAP would follow HTTP in this respect. I did notice that for HTTP it is explicitly stated that no timeouts are needed but that they may (MAY?) be present; http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#section-6.5 I think the CoAP spec could at least makes a similar remark; currently it's not mentioned. For implementers it's perhaps useful at some point to know what methods / best practices to use to detect the 'server dead' case; similar to the case for TCP of half-open connections and detection thereof where some approaches are documented. I assume for now it is timer-based with a custom timeout value, where the value must not be lower than MAX_LATENCY. > What specific test are are you referring here? > We didn't test any client timeout for separate responses. Oops, I didn't mean to say timeout here but time taken by the server for processing the request. It mentions " Some time (a couple of seconds) elapses" in the base.html test specs. A similar case occurs when this "some time" is higher than the client's expectation of "some time" so that's even an aspect that could be tested. (E.g use MAX_LATENCY instead of "couple of seconds"?) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday, November 26, 2013 16:45 To: Dijk, Esko Cc: core (core@ietf.org) Subject: Re: [core] CoAP 'infinite timeout' use case One general rule in CoAP is that timeouts are on the message layer, not on the request/response layer. Most likely, there will still be a limit to the time in which the response is useful to the client. E.g., in the HTTP world, many clients give up after ~ 60 seconds (even if the TCP connection below HTTP has longer timeouts). But there is nothing in the HTTP spec that describes these timeouts. I find it quite logical that CoAP hasn't anything here either. But maybe the analogy is not quite right, I'd like to hear about that. (Klaus has a draft that would allow a client to even cancel an outstanding request, draft-hartke-core-coap-liveliness.) Grüße, Carsten PS.: > (I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 > only address timeouts of "a couple of seconds") What specific test are are you referring here? We didn't test any client timeout for separate responses. ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From weigengyu@bupt.edu.cn Thu Nov 28 01:16:20 2013 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 6A6A31ADF46 for ; Thu, 28 Nov 2013 01:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.549 X-Spam-Level: X-Spam-Status: No, score=0.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-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 MQf2g2J7QHv4 for ; Thu, 28 Nov 2013 01:16:14 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A01E1ADBD2 for ; Thu, 28 Nov 2013 01:16:10 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 620E219F3B1; Thu, 28 Nov 2013 17:16:07 +0800 (HKT) Message-ID: <72478E14D297435C8430474E749919F7@WeiGengyuPC> From: "weigengyu" To: "Dijk, Esko" References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Thu, 28 Nov 2013 17:13:48 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CEEC5D.33C427D0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] How to correlate request and responses in group communication 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, 28 Nov 2013 09:16:20 -0000 һ MIME ʽĶ෽ʼ ------=_NextPart_000_000B_01CEEC5D.33C427D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Esko,=20 In OMA LWM2M Requirements,=20 6. Requirements (Normative) 6.1 High-Level Functional Requirements LightweightM2MHLF-001 The Lightweight M2M enabler SHALL support a = unique ID to identify the LWM2M Device.=20 It is understood that each device needs a unique ID.=20 And within a decvice there may have a few of physical resources that can = be remotely accessed individually.=20 Based on CoAP =A8C18 terminology, it seems that Endpoint is = correspondant to the OMA Device.=20 Whether or not? If it is, attentions need to pay for that. =20 I think that giving the description how to define and how to access the = device or the physical resources is better than leaving that to the = application.=20 By the way, Location option is defined in CoAP =A8C18.=20 The current version describes the location-query and location-path used = as the response to POST request.=20 And In CoAP =A8C18, =A1=B0 5.10.6.1. ETag as a Response Option The ETag Option in a response provides the current value (i.e., after = the request was processed) of the entity-tag for the "tagged representation". If no Location-* options are present, the tagged = representation is the selected representation (Section 5.5.3) of the target resource. If one or more Location-* options are present and thus = a location URI is indicated (Section 5.10.7), the tagged representation is the representation that would be retrieved by a GET = request to the location URI.=20 5.10.7. Location-Path and Location-Query The Location-Path and Location-Query Options together indicate a = relative URI that consists either of an absolute path, a query string or both. A combination of these options is included in a 2.01 (Created) = response to indicate the location of the resource created as the result of a POST request (see Section 5.8.2). The location is = resolved relative to the request URI. =A1=B0 Based on the above text, by the URI the target resource can be accessed. = I got a little confused wether the target resource is a Device or a = phiscal resource? =20 If the URI indicates a Device, the means to access phiscal resources is = required.=20 If the URI indicates a physical resource, CoAP =A8C18 has the means to = tell the differences.=20 Regards,=20 Gengyu=20 Network Technology Center=20 School of Computer Beijng University of Posts & Telecommunications From: Dijk, Esko=20 Sent: Wednesday, November 27, 2013 11:13 PM To: Likepeng ; core@ietf.org=20 Subject: Re: [core] How to correlate request and responses in group = communication Yes, it=A1=AFs currently defined to use the UDP layer for that = information. At least it=A1=AFs efficient :) =20 If information other than IP address is needed, such as a non-volatile = GUID, the CoAP server could include this as part of its response payload = (in case of GET or PUT). But that=A1=AFs not the most beautiful solution I agree. =20 Esko =20 From: Likepeng [mailto:likepeng@huawei.com]=20 Sent: Wednesday, November 27, 2013 09:32 To: Dijk, Esko; core@ietf.org Subject: Re: [core] How to correlate request and responses in group = communication =20 Hi Esko, =20 >The identification of the individual response is by the (unicast) IP = source address of the responding CoAP endpoint. =20 In the response, the only place to put the (unicast) IP source address = is the UDP layer, right? Because HRI-Host is used to indicate the target = node, not the source node. =20 (CoAP section 5.10.1) The Uri-Host, Uri-Port, Uri-Path and Uri-Query = Options are used to specify the target resource of a request to a CoAP = origin server. =20 That means, the requestor has to rely on UDP layer to get the (unicast) = IP source address from the response, then correlate the multicast = request and the unicast response. But in my opinion, the correlation = should be done in the CoAP layer. CoAP layer should provide some = information to be used for this purpose. =20 In CoAP spec, it mentions that Token MUST be used to match the responses = with the multicast request. If there are multiple responses, we have to = use source endpoint to differentiate. But this information can be only = got from UDP layer. That is an issue, in my opinion. =20 CoAP Section 8.2 When matching a response to a multicast request, only the token MUST match; the source endpoint of the response does not need to (and will not) be the same as the destination endpoint of the original request. =20 Any thoughts? =20 Thanks, Kind Regards Kepeng =20 =B7=A2=BC=FE=C8=CB: Dijk, Esko [mailto:esko.dijk@philips.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C227=C8=D5 15:01 =CA=D5=BC=FE=C8=CB: Likepeng; core@ietf.org =D6=F7=CC=E2: RE: [core] How to correlate request and responses in group = communication =20 Hello Kepeng, =20 The identification of the individual response is by the (unicast) IP = source address of the responding CoAP endpoint. Indeed this would be good to mention somewhere in groupcomm. Correlation of a single request with a set of responses is via Token; in = case there are multiple outstanding multicast requests from a single = endpoint. =20 Also core-coap has some information on use of IP address of the = responding endpoint, section 8.2: =20 For the purposes of interpreting the Location-* options and any links embedded in the representation and, the request URI (base URI) relative to which the response is interpreted, is formed by replacing the multicast address in the Host component of the original request URI by the literal IP address of the endpoint actually responding. =20 Esko =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Likepeng Sent: Wednesday, November 27, 2013 03:50 To: core@ietf.org Subject: [core] How to correlate request and responses in group = communication =20 Hi all, =20 When I read the group communication draft, I come up with one question, = how to correlate a multicast request with the multiple responses from = different nodes? =20 For example, a client sends a multicast GET request to a group URI: = all.bldg6.example.com, and after some time, it will receive multiple = responses from different nodes. In the request, it contains one token. = In the responses, I assume that all the responses should use the same = token according to the base coap spec. Then how can the client = differentiate the different responses from different nodes, = corresponding to the same request? =20 I searched the whole group communication draft, token is not mentioned. = So I hope to get opinion from the group. =20 Thanks, Kind Regards Kepeng =20 -------------------------------------------------------------------------= ------- The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_000B_01CEEC5D.33C427D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Esko,
 
In OMA LWM2M Requirements,
    6. Requirements (Normative)
    6.1 High-Level Functional Requirements
    LightweightM2MHLF-001 The Lightweight M2M = enabler SHALL=20 support a unique ID to identify the LWM2M Device.
 
It is understood that each device needs a unique ID.
And within a decvice there may have a few of physical resources = that can be=20 remotely accessed individually.
 
Based on CoAP =A8C18 terminology, it seems that Endpoint is = correspondant to=20 the OMA Device.
Whether or not?   If it is, attentions need to pay for=20 that. 
 
I think that giving the description how to define and how to access = the=20 device or the physical resources is better than leaving that to the = application.=20
 
By the way, Location option is = defined in CoAP=20 =A8C18.
The current version describes the = location-query=20 and location-path used as the response to POST request.
And In CoAP =A8C18,    =A1=B0
     5.10.6.1. ETag as a Response Option
The ETag Option in a response provides the current value (i.e., = after the=20 request was processed) of the entity-tag for the "tagged
representation". If no Location-* options are present, the tagged=20 representation is the selected representation (Section 5.5.3) of = the
target resource. If one or more Location-* options are present and = thus a=20 location URI is indicated (Section 5.10.7), the tagged
representation is the representation that would be retrieved by a = GET=20 request to the location URI.
    5.10.7. Location-Path and Location-Query
The Location-Path and Location-Query Options together indicate a = relative=20 URI that consists either of an absolute path, a query string
or both. A combination of these options is included in a 2.01 = (Created)=20 response to indicate the location of the resource created
as the result of a POST request (see Section 5.8.2). The location = is=20 resolved relative to the request URI. =A1=B0
 
Based on the above text, by the URI = the target=20 resource can be accessed.
I got a = little confused=20 wether the target resource is a Device or a phiscal = resource? =20
 
If the URI indicates a Device, the = means to=20 access phiscal resources is required.
If the URI indicates a physical = resource, CoAP=20 =A8C18 has the means to tell the differences.
 
 
Regards,
 
Gengyu
 
Network Technology Center =
School of Computer
Beijng University of Posts &=20 Telecommunications
 
 
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 11:13 PM
Subject: Re: [core] How to correlate request and responses = in group=20 communication
 

Yes, it=A1=AFs=20 currently defined to use the UDP layer for that information. At least = it=A1=AFs=20 efficient :)

 

If = information=20 other than IP address is needed, such as a non-volatile GUID, the CoAP = server=20 could include this as part of its response payload (in case of GET or=20 PUT).

But = that=A1=AFs not=20 the most beautiful solution I agree.

 

Esko

 

From: Likepeng=20 [mailto:likepeng@huawei.com]
Sent: Wednesday, November 27, = 2013=20 09:32
To: Dijk, Esko; core@ietf.org
Subject: Re: = [core] How=20 to correlate request and responses in group=20 communication

 

Hi = Esko,

 

>The=20 identification of the individual response is by the (unicast) IP source = address=20 of the responding CoAP endpoint.

 

In the response, the = only place=20 to put the (unicast) IP source address is the UDP layer, right? Because = HRI-Host=20 is used to indicate the target node, not the source = node.

 

(CoAP section 5.10.1) The Uri-Host, Uri-Port, = Uri-Path=20 and Uri-Query Options are used to specify the target resource of a = request to a=20 CoAP origin server.

 

That means, the = requestor has to=20 rely on UDP layer to get the (unicast) IP source address from the = response, then=20 correlate the multicast request and the unicast response. But in my = opinion, the=20 correlation should be done in the CoAP layer. CoAP layer should provide = some=20 information to be used for this purpose.

 

In CoAP spec, it = mentions that=20 Token MUST be used to match the responses with the multicast request. If = there=20 are multiple responses, we have to use source endpoint to differentiate. = But=20 this information can be only got from UDP layer. That is an issue, in my = opinion.

 

CoAP Section=20 8.2

   When matching a response to a = multicast=20 request, only the token MUST

   match; the source endpoint of the = response=20 does not need to (and will

   not) be = the same as=20 the destination endpoint of the original request.

 

Any=20 thoughts?

 

Thanks,

Kind=20 Regards

Kepeng

 

=B7=A2=BC=FE=C8=CB: Dijk, Esko [mailto:esko.dijk@philips.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C227=C8=D5 = 15:01
=CA=D5=BC=FE=C8=CB: Likepeng; core@ietf.org
=D6=F7=CC=E2: RE: [core] How to correlate = request and responses in=20 group communication

 

Hello=20 Kepeng,

 

The = identification of the individual response is by the (unicast) IP source = address=20 of the responding CoAP endpoint.

Indeed this=20 would be good to mention somewhere in groupcomm.

Correlation of=20 a single request with a set of responses is via Token; in case there are = multiple outstanding multicast requests from a single=20 endpoint.

 

Also core-coap=20 has some information on use of IP address of the responding endpoint, = section=20 8.2:

 

For = the=20 purposes of interpreting the Location-* options and any=20 links

  =20 embedded in the representation and, the request URI (base=20 URI)

  =20 relative to which the response is interpreted, is formed by=20 replacing

  =20 the multicast address in the Host component of the original=20 request

  =20 URI by the literal IP address of the endpoint actually=20 responding.

 

Esko

 

From: core [mailto:core-bounces@ietf.org] = On=20 Behalf Of Likepeng
Sent: Wednesday, November 27, 2013=20 03:50
To: core@ietf.org
Subject: = [core] How to=20 correlate request and responses in group=20 communication

 

Hi all,

 

When I read the group communication draft, I come = up with one=20 question, how to correlate a multicast request with the multiple = responses from=20 different nodes?

 

For example, a client sends a multicast GET request = to a=20 group URI: all.bldg6.example.com, and after some time, it will receive = multiple=20 responses from different nodes. In the request, it contains one token. = In the=20 responses, I assume that all the responses should use the same token = according=20 to the base coap spec. Then how can the client differentiate the = different=20 responses from different nodes, corresponding to the same=20 request?

 

I searched the whole group communication draft, = token is not=20 mentioned. So I hope to get opinion from the group.

 

Thanks,

Kind Regards

Kepeng

 

The=20 information contained in this message may be confidential and legally = protected=20 under applicable law. The message is intended solely for the = addressee(s). If=20 you are not the intended recipient, you are hereby notified that any = use,=20 forwarding, dissemination, or reproduction of this message is strictly=20 prohibited and may be unlawful. If you are not the intended recipient, = please=20 contact the sender by return e-mail and destroy all copies of the = original=20 message

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_000B_01CEEC5D.33C427D0-- From esko.dijk@philips.com Thu Nov 28 01:30:53 2013 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 2DA651ADF4E for ; Thu, 28 Nov 2013 01:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7] 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 gaHfmAEnoy1V for ; Thu, 28 Nov 2013 01:30:49 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id C7DE61ADF44 for ; Thu, 28 Nov 2013 01:30:48 -0800 (PST) Received: from mail24-co1-R.bigfish.com (10.243.78.233) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 28 Nov 2013 09:30:47 +0000 Received: from mail24-co1 (localhost [127.0.0.1]) by mail24-co1-R.bigfish.com (Postfix) with ESMTP id A685D7001D3; Thu, 28 Nov 2013 09:30:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VPS-33(z579ehz217bI15d6O9371Ic89bh1be0Ic85bh1432I1418I1453I9251I4015I14ffIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzd9hz1d7338h1de098h1033IL18c58eh17326ah8275bh8275dh18c673h1de097h186068hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h1155h) Received: from mail24-co1 (localhost.localdomain [127.0.0.1]) by mail24-co1 (MessageSwitch) id 1385631044999638_16673; Thu, 28 Nov 2013 09:30:44 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.239]) by mail24-co1.bigfish.com (Postfix) with ESMTP id EFA3060006F; Thu, 28 Nov 2013 09:30:44 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 28 Nov 2013 09:30:44 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.03.0158.002; Thu, 28 Nov 2013 09:30:42 +0000 From: "Dijk, Esko" To: weigengyu Thread-Topic: [core] How to correlate request and responses in group communication Thread-Index: Ac7rG1cGT4fNhozCS7KwdPTKZ1kSxwAIgb/gAAIa26AADwLsQAAmFA0AAABYPeA= Date: Thu, 28 Nov 2013 09:30:41 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <72478E14D297435C8430474E749919F7@WeiGengyuPC> In-Reply-To: <72478E14D297435C8430474E749919F7@WeiGengyuPC> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180CC43638011DB3MPN2082MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org" Subject: Re: [core] How to correlate request and responses in group communication 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, 28 Nov 2013 09:30:53 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180CC43638011DB3MPN2082MG_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBkb26hr3Qga25vdyB0aGUgT01BIExXTTJNIGRldGFpbHMsIGJ1dCB0aGUgQ29BUCBlbmRwb2lu dCBpcyBsaWtlbHkgdG8gYmUgZGlmZmVyZW50IKhDIG9uZSBEZXZpY2UgKD1ub2RlPykgdXN1YWxs eSBzdXBwb3J0cyBtYW55IGVuZHBvaW50cyB3aGljaCBjb3VsZCBjb3JyZXNwb25kIGUuZy4gdG8g ZGlmZmVyZW50IGFwcGxpY2F0aW9ucyBvbiB0aGUgRGV2aWNlLiBBbmQgdGhlIENvQVAgZW5kcG9p bnQgaXMgaWRlbnRpZmllZCBieSBJUCBhZGRyZXNzIChwbHVzIHBvcnQsIHBsdXMgc2VjdXJpdHkg Y29udGV4dCkgc28gdGhpcyBpcyBub3QgYSBzdWl0YWJsZSBVSUQgc2luY2UgdGhlIElQIGFkZHJl c3MgbWF5IGNoYW5nZSBvdmVyIHRpbWUuDQoNCkNvQVAgZG9lc26hr3Qgc3VwcG9ydCBzcGVjaWZp YyBvcHRpb25zIHRvIGNvbW11bmljYXRlIGEgbm9kZS9EZXZpY2UgdW5pcXVlIElEIGJhY2sgYW5k IGZvcnRoIEFGQUlLLiBUaGF0IGNvdWxkIGJlIGFjY29tcGxpc2hlZCBhdCBsb3dlciBsYXllciB0 aHJvdWdoIHNlY3VyaXR5IChEVExTIGF1dGhlbnRpY2F0aW9uKSBvciBhdCBoaWdoZXIgbGF5ZXIg aW4gdGhlIGFwcGxpY2F0aW9uLWxldmVsIHBheWxvYWRzIChlLmcuIGEgcmVzb3VyY2UgL3VpZCB0 aGF0IHRlbGxzIHRoZSB1bmlxdWUgSUQgb2YgYSBkZXZpY2UsIG9yIGEgVUlEIHRoYXQgaXMgaW5j bHVkZWQgaW4gdGhlIHBheWxvYWQgb2YgYSBDb0FQIHJlc3BvbnNlLikNCg0KRXNrbw0KDQpGcm9t OiB3ZWlnZW5neXUgW21haWx0bzp3ZWlnZW5neXVAYnVwdC5lZHUuY25dDQpTZW50OiBUaHVyc2Rh eSwgTm92ZW1iZXIgMjgsIDIwMTMgMTA6MTQNClRvOiBEaWprLCBFc2tvDQpDYzogY29yZUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBIb3cgdG8gY29ycmVsYXRlIHJlcXVlc3QgYW5kIHJl c3BvbnNlcyBpbiBncm91cCBjb21tdW5pY2F0aW9uDQoNCkhpIEVza28sDQoNCkluIE9NQSBMV00y TSBSZXF1aXJlbWVudHMsDQogICAgNi4gUmVxdWlyZW1lbnRzIChOb3JtYXRpdmUpDQogICAgNi4x IEhpZ2gtTGV2ZWwgRnVuY3Rpb25hbCBSZXF1aXJlbWVudHMNCiAgICBMaWdodHdlaWdodE0yTUhM Ri0wMDEgVGhlIExpZ2h0d2VpZ2h0IE0yTSBlbmFibGVyIFNIQUxMIHN1cHBvcnQgYSB1bmlxdWUg SUQgdG8gaWRlbnRpZnkgdGhlIExXTTJNIERldmljZS4NCg0KSXQgaXMgdW5kZXJzdG9vZCB0aGF0 IGVhY2ggZGV2aWNlIG5lZWRzIGEgdW5pcXVlIElELg0KQW5kIHdpdGhpbiBhIGRlY3ZpY2UgdGhl cmUgbWF5IGhhdmUgYSBmZXcgb2YgcGh5c2ljYWwgcmVzb3VyY2VzIHRoYXQgY2FuIGJlIHJlbW90 ZWx5IGFjY2Vzc2VkIGluZGl2aWR1YWxseS4NCg0KQmFzZWQgb24gQ29BUCCoQzE4IHRlcm1pbm9s b2d5LCBpdCBzZWVtcyB0aGF0IEVuZHBvaW50IGlzIGNvcnJlc3BvbmRhbnQgdG8gdGhlIE9NQSBE ZXZpY2UuDQpXaGV0aGVyIG9yIG5vdD8gICBJZiBpdCBpcywgYXR0ZW50aW9ucyBuZWVkIHRvIHBh eSBmb3IgdGhhdC4NCg0KSSB0aGluayB0aGF0IGdpdmluZyB0aGUgZGVzY3JpcHRpb24gaG93IHRv IGRlZmluZSBhbmQgaG93IHRvIGFjY2VzcyB0aGUgZGV2aWNlIG9yIHRoZSBwaHlzaWNhbCByZXNv dXJjZXMgaXMgYmV0dGVyIHRoYW4gbGVhdmluZyB0aGF0IHRvIHRoZSBhcHBsaWNhdGlvbi4NCg0K QnkgdGhlIHdheSwgTG9jYXRpb24gb3B0aW9uIGlzIGRlZmluZWQgaW4gQ29BUCCoQzE4Lg0KVGhl IGN1cnJlbnQgdmVyc2lvbiBkZXNjcmliZXMgdGhlIGxvY2F0aW9uLXF1ZXJ5IGFuZCBsb2NhdGlv bi1wYXRoIHVzZWQgYXMgdGhlIHJlc3BvbnNlIHRvIFBPU1QgcmVxdWVzdC4NCkFuZCBJbiBDb0FQ IKhDMTgsICAgIKGwDQogICAgIDUuMTAuNi4xLiBFVGFnIGFzIGEgUmVzcG9uc2UgT3B0aW9uDQpU aGUgRVRhZyBPcHRpb24gaW4gYSByZXNwb25zZSBwcm92aWRlcyB0aGUgY3VycmVudCB2YWx1ZSAo aS5lLiwgYWZ0ZXIgdGhlIHJlcXVlc3Qgd2FzIHByb2Nlc3NlZCkgb2YgdGhlIGVudGl0eS10YWcg Zm9yIHRoZSAidGFnZ2VkDQpyZXByZXNlbnRhdGlvbiIuIElmIG5vIExvY2F0aW9uLSogb3B0aW9u cyBhcmUgcHJlc2VudCwgdGhlIHRhZ2dlZCByZXByZXNlbnRhdGlvbiBpcyB0aGUgc2VsZWN0ZWQg cmVwcmVzZW50YXRpb24gKFNlY3Rpb24gNS41LjMpIG9mIHRoZQ0KdGFyZ2V0IHJlc291cmNlLiBJ ZiBvbmUgb3IgbW9yZSBMb2NhdGlvbi0qIG9wdGlvbnMgYXJlIHByZXNlbnQgYW5kIHRodXMgYSBs b2NhdGlvbiBVUkkgaXMgaW5kaWNhdGVkIChTZWN0aW9uIDUuMTAuNyksIHRoZSB0YWdnZWQNCnJl cHJlc2VudGF0aW9uIGlzIHRoZSByZXByZXNlbnRhdGlvbiB0aGF0IHdvdWxkIGJlIHJldHJpZXZl ZCBieSBhIEdFVCByZXF1ZXN0IHRvIHRoZSBsb2NhdGlvbiBVUkkuDQogICAgNS4xMC43LiBMb2Nh dGlvbi1QYXRoIGFuZCBMb2NhdGlvbi1RdWVyeQ0KVGhlIExvY2F0aW9uLVBhdGggYW5kIExvY2F0 aW9uLVF1ZXJ5IE9wdGlvbnMgdG9nZXRoZXIgaW5kaWNhdGUgYSByZWxhdGl2ZSBVUkkgdGhhdCBj b25zaXN0cyBlaXRoZXIgb2YgYW4gYWJzb2x1dGUgcGF0aCwgYSBxdWVyeSBzdHJpbmcNCm9yIGJv dGguIEEgY29tYmluYXRpb24gb2YgdGhlc2Ugb3B0aW9ucyBpcyBpbmNsdWRlZCBpbiBhIDIuMDEg KENyZWF0ZWQpIHJlc3BvbnNlIHRvIGluZGljYXRlIHRoZSBsb2NhdGlvbiBvZiB0aGUgcmVzb3Vy Y2UgY3JlYXRlZA0KYXMgdGhlIHJlc3VsdCBvZiBhIFBPU1QgcmVxdWVzdCAoc2VlIFNlY3Rpb24g NS44LjIpLiBUaGUgbG9jYXRpb24gaXMgcmVzb2x2ZWQgcmVsYXRpdmUgdG8gdGhlIHJlcXVlc3Qg VVJJLiChsA0KDQpCYXNlZCBvbiB0aGUgYWJvdmUgdGV4dCwgYnkgdGhlIFVSSSB0aGUgdGFyZ2V0 IHJlc291cmNlIGNhbiBiZSBhY2Nlc3NlZC4NCkkgZ290IGEgbGl0dGxlIGNvbmZ1c2VkIHdldGhl ciB0aGUgdGFyZ2V0IHJlc291cmNlIGlzIGEgRGV2aWNlIG9yIGEgcGhpc2NhbCByZXNvdXJjZT8N Cg0KSWYgdGhlIFVSSSBpbmRpY2F0ZXMgYSBEZXZpY2UsIHRoZSBtZWFucyB0byBhY2Nlc3MgcGhp c2NhbCByZXNvdXJjZXMgaXMgcmVxdWlyZWQuDQpJZiB0aGUgVVJJIGluZGljYXRlcyBhIHBoeXNp Y2FsIHJlc291cmNlLCBDb0FQIKhDMTggaGFzIHRoZSBtZWFucyB0byB0ZWxsIHRoZSBkaWZmZXJl bmNlcy4NCg0KDQpSZWdhcmRzLA0KDQpHZW5neXUNCg0KTmV0d29yayBUZWNobm9sb2d5IENlbnRl cg0KU2Nob29sIG9mIENvbXB1dGVyDQpCZWlqbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyAmIFRlbGVj b21tdW5pY2F0aW9ucw0KDQoNCkZyb206IERpamssIEVza288bWFpbHRvOmVza28uZGlqa0BwaGls aXBzLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjcsIDIwMTMgMTE6MTMgUE0NClRv OiBMaWtlcGVuZzxtYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbT4gOyBjb3JlQGlldGYub3JnPG1h aWx0bzpjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBIb3cgdG8gY29ycmVsYXRl IHJlcXVlc3QgYW5kIHJlc3BvbnNlcyBpbiBncm91cCBjb21tdW5pY2F0aW9uDQoNClllcywgaXSh r3MgY3VycmVudGx5IGRlZmluZWQgdG8gdXNlIHRoZSBVRFAgbGF5ZXIgZm9yIHRoYXQgaW5mb3Jt YXRpb24uIEF0IGxlYXN0IGl0oa9zIGVmZmljaWVudCA6KQ0KDQpJZiBpbmZvcm1hdGlvbiBvdGhl ciB0aGFuIElQIGFkZHJlc3MgaXMgbmVlZGVkLCBzdWNoIGFzIGEgbm9uLXZvbGF0aWxlIEdVSUQs IHRoZSBDb0FQIHNlcnZlciBjb3VsZCBpbmNsdWRlIHRoaXMgYXMgcGFydCBvZiBpdHMgcmVzcG9u c2UgcGF5bG9hZCAoaW4gY2FzZSBvZiBHRVQgb3IgUFVUKS4NCkJ1dCB0aGF0oa9zIG5vdCB0aGUg bW9zdCBiZWF1dGlmdWwgc29sdXRpb24gSSBhZ3JlZS4NCg0KRXNrbw0KDQpGcm9tOiBMaWtlcGVu ZyBbbWFpbHRvOmxpa2VwZW5nQGh1YXdlaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVy IDI3LCAyMDEzIDA5OjMyDQpUbzogRGlqaywgRXNrbzsgY29yZUBpZXRmLm9yZzxtYWlsdG86Y29y ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gSG93IHRvIGNvcnJlbGF0ZSByZXF1ZXN0 IGFuZCByZXNwb25zZXMgaW4gZ3JvdXAgY29tbXVuaWNhdGlvbg0KDQpIaSBFc2tvLA0KDQo+VGhl IGlkZW50aWZpY2F0aW9uIG9mIHRoZSBpbmRpdmlkdWFsIHJlc3BvbnNlIGlzIGJ5IHRoZSAodW5p Y2FzdCkgSVAgc291cmNlIGFkZHJlc3Mgb2YgdGhlIHJlc3BvbmRpbmcgQ29BUCBlbmRwb2ludC4N Cg0KSW4gdGhlIHJlc3BvbnNlLCB0aGUgb25seSBwbGFjZSB0byBwdXQgdGhlICh1bmljYXN0KSBJ UCBzb3VyY2UgYWRkcmVzcyBpcyB0aGUgVURQIGxheWVyLCByaWdodD8gQmVjYXVzZSBIUkktSG9z dCBpcyB1c2VkIHRvIGluZGljYXRlIHRoZSB0YXJnZXQgbm9kZSwgbm90IHRoZSBzb3VyY2Ugbm9k ZS4NCg0KKENvQVAgc2VjdGlvbiA1LjEwLjEpIFRoZSBVcmktSG9zdCwgVXJpLVBvcnQsIFVyaS1Q YXRoIGFuZCBVcmktUXVlcnkgT3B0aW9ucyBhcmUgdXNlZCB0byBzcGVjaWZ5IHRoZSB0YXJnZXQg cmVzb3VyY2Ugb2YgYSByZXF1ZXN0IHRvIGEgQ29BUCBvcmlnaW4gc2VydmVyLg0KDQpUaGF0IG1l YW5zLCB0aGUgcmVxdWVzdG9yIGhhcyB0byByZWx5IG9uIFVEUCBsYXllciB0byBnZXQgdGhlICh1 bmljYXN0KSBJUCBzb3VyY2UgYWRkcmVzcyBmcm9tIHRoZSByZXNwb25zZSwgdGhlbiBjb3JyZWxh dGUgdGhlIG11bHRpY2FzdCByZXF1ZXN0IGFuZCB0aGUgdW5pY2FzdCByZXNwb25zZS4gQnV0IGlu IG15IG9waW5pb24sIHRoZSBjb3JyZWxhdGlvbiBzaG91bGQgYmUgZG9uZSBpbiB0aGUgQ29BUCBs YXllci4gQ29BUCBsYXllciBzaG91bGQgcHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIHRvIGJlIHVz ZWQgZm9yIHRoaXMgcHVycG9zZS4NCg0KSW4gQ29BUCBzcGVjLCBpdCBtZW50aW9ucyB0aGF0IFRv a2VuIE1VU1QgYmUgdXNlZCB0byBtYXRjaCB0aGUgcmVzcG9uc2VzIHdpdGggdGhlIG11bHRpY2Fz dCByZXF1ZXN0LiBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgcmVzcG9uc2VzLCB3ZSBoYXZlIHRvIHVz ZSBzb3VyY2UgZW5kcG9pbnQgdG8gZGlmZmVyZW50aWF0ZS4gQnV0IHRoaXMgaW5mb3JtYXRpb24g Y2FuIGJlIG9ubHkgZ290IGZyb20gVURQIGxheWVyLiBUaGF0IGlzIGFuIGlzc3VlLCBpbiBteSBv cGluaW9uLg0KDQpDb0FQIFNlY3Rpb24gOC4yDQogICBXaGVuIG1hdGNoaW5nIGEgcmVzcG9uc2Ug dG8gYSBtdWx0aWNhc3QgcmVxdWVzdCwgb25seSB0aGUgdG9rZW4gTVVTVA0KICAgbWF0Y2g7IHRo ZSBzb3VyY2UgZW5kcG9pbnQgb2YgdGhlIHJlc3BvbnNlIGRvZXMgbm90IG5lZWQgdG8gKGFuZCB3 aWxsDQogICBub3QpIGJlIHRoZSBzYW1lIGFzIHRoZSBkZXN0aW5hdGlvbiBlbmRwb2ludCBvZiB0 aGUgb3JpZ2luYWwgcmVxdWVzdC4NCg0KQW55IHRob3VnaHRzPw0KDQpUaGFua3MsDQpLaW5kIFJl Z2FyZHMNCktlcGVuZw0KDQq3orz+yMs6IERpamssIEVza28gW21haWx0bzplc2tvLmRpamtAcGhp bGlwcy5jb21dDQq3osvNyrG85DogMjAxM8TqMTHUwjI3yNUgMTU6MDENCsrVvP7IyzogTGlrZXBl bmc7IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQrW98ziOiBSRTogW2NvcmVd IEhvdyB0byBjb3JyZWxhdGUgcmVxdWVzdCBhbmQgcmVzcG9uc2VzIGluIGdyb3VwIGNvbW11bmlj YXRpb24NCg0KSGVsbG8gS2VwZW5nLA0KDQpUaGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIGluZGl2 aWR1YWwgcmVzcG9uc2UgaXMgYnkgdGhlICh1bmljYXN0KSBJUCBzb3VyY2UgYWRkcmVzcyBvZiB0 aGUgcmVzcG9uZGluZyBDb0FQIGVuZHBvaW50Lg0KSW5kZWVkIHRoaXMgd291bGQgYmUgZ29vZCB0 byBtZW50aW9uIHNvbWV3aGVyZSBpbiBncm91cGNvbW0uDQpDb3JyZWxhdGlvbiBvZiBhIHNpbmds ZSByZXF1ZXN0IHdpdGggYSBzZXQgb2YgcmVzcG9uc2VzIGlzIHZpYSBUb2tlbjsgaW4gY2FzZSB0 aGVyZSBhcmUgbXVsdGlwbGUgb3V0c3RhbmRpbmcgbXVsdGljYXN0IHJlcXVlc3RzIGZyb20gYSBz aW5nbGUgZW5kcG9pbnQuDQoNCkFsc28gY29yZS1jb2FwIGhhcyBzb21lIGluZm9ybWF0aW9uIG9u IHVzZSBvZiBJUCBhZGRyZXNzIG9mIHRoZSByZXNwb25kaW5nIGVuZHBvaW50LCBzZWN0aW9uIDgu MjoNCg0KRm9yIHRoZSBwdXJwb3NlcyBvZiBpbnRlcnByZXRpbmcgdGhlIExvY2F0aW9uLSogb3B0 aW9ucyBhbmQgYW55IGxpbmtzDQogICBlbWJlZGRlZCBpbiB0aGUgcmVwcmVzZW50YXRpb24gYW5k LCB0aGUgcmVxdWVzdCBVUkkgKGJhc2UgVVJJKQ0KICAgcmVsYXRpdmUgdG8gd2hpY2ggdGhlIHJl c3BvbnNlIGlzIGludGVycHJldGVkLCBpcyBmb3JtZWQgYnkgcmVwbGFjaW5nDQogICB0aGUgbXVs dGljYXN0IGFkZHJlc3MgaW4gdGhlIEhvc3QgY29tcG9uZW50IG9mIHRoZSBvcmlnaW5hbCByZXF1 ZXN0DQogICBVUkkgYnkgdGhlIGxpdGVyYWwgSVAgYWRkcmVzcyBvZiB0aGUgZW5kcG9pbnQgYWN0 dWFsbHkgcmVzcG9uZGluZy4NCg0KRXNrbw0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGlrZXBlbmcNClNlbnQ6IFdlZG5lc2RheSwgTm92 ZW1iZXIgMjcsIDIwMTMgMDM6NTANClRvOiBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYu b3JnPg0KU3ViamVjdDogW2NvcmVdIEhvdyB0byBjb3JyZWxhdGUgcmVxdWVzdCBhbmQgcmVzcG9u c2VzIGluIGdyb3VwIGNvbW11bmljYXRpb24NCg0KSGkgYWxsLA0KDQpXaGVuIEkgcmVhZCB0aGUg Z3JvdXAgY29tbXVuaWNhdGlvbiBkcmFmdCwgSSBjb21lIHVwIHdpdGggb25lIHF1ZXN0aW9uLCBo b3cgdG8gY29ycmVsYXRlIGEgbXVsdGljYXN0IHJlcXVlc3Qgd2l0aCB0aGUgbXVsdGlwbGUgcmVz cG9uc2VzIGZyb20gZGlmZmVyZW50IG5vZGVzPw0KDQpGb3IgZXhhbXBsZSwgYSBjbGllbnQgc2Vu ZHMgYSBtdWx0aWNhc3QgR0VUIHJlcXVlc3QgdG8gYSBncm91cCBVUkk6IGFsbC5ibGRnNi5leGFt cGxlLmNvbSwgYW5kIGFmdGVyIHNvbWUgdGltZSwgaXQgd2lsbCByZWNlaXZlIG11bHRpcGxlIHJl c3BvbnNlcyBmcm9tIGRpZmZlcmVudCBub2Rlcy4gSW4gdGhlIHJlcXVlc3QsIGl0IGNvbnRhaW5z IG9uZSB0b2tlbi4gSW4gdGhlIHJlc3BvbnNlcywgSSBhc3N1bWUgdGhhdCBhbGwgdGhlIHJlc3Bv bnNlcyBzaG91bGQgdXNlIHRoZSBzYW1lIHRva2VuIGFjY29yZGluZyB0byB0aGUgYmFzZSBjb2Fw IHNwZWMuIFRoZW4gaG93IGNhbiB0aGUgY2xpZW50IGRpZmZlcmVudGlhdGUgdGhlIGRpZmZlcmVu dCByZXNwb25zZXMgZnJvbSBkaWZmZXJlbnQgbm9kZXMsIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHNh bWUgcmVxdWVzdD8NCg0KSSBzZWFyY2hlZCB0aGUgd2hvbGUgZ3JvdXAgY29tbXVuaWNhdGlvbiBk cmFmdCwgdG9rZW4gaXMgbm90IG1lbnRpb25lZC4gU28gSSBob3BlIHRvIGdldCBvcGluaW9uIGZy b20gdGhlIGdyb3VwLg0KDQpUaGFua3MsDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5k ZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0 aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0 cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== --_000_031DD135F9160444ABBE3B0C36CED6180CC43638011DB3MPN2082MG_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I don= =A1=AFt know the OMA LWM2M details, but the CoAP endpoint is likely to be d= ifferent =A8C one Device (=3Dnode?) usually supports many endpoints which c= ould correspond e.g. to different applications on the Device. And the CoAP endpoint is identified by IP address (plus por= t, plus security context) so this is not a suitable UID since the IP addres= s may change over time.

=  

CoAP = doesn=A1=AFt support specific options to communicate a node/Device unique I= D back and forth AFAIK. That could be accomplished at lower layer through s= ecurity (DTLS authentication) or at higher layer in the application-level payloads (e.g. a resource /uid that tells t= he unique ID of a device, or a UID that is included in the payload of a CoA= P response.)

=  

Esko<= o:p>

=  

From: weigengyu [mailto:weigengyu@bupt.edu.cn]
Sent: Thursday, November 28, 2013 10:14
To: Dijk, Esko
Cc: core@ietf.org
Subject: Re: [core] How to correlate request and responses in group = communication

 =

Hi Esko,

 

In OMA LWM2M Requirements,

    6. Requirements (Norma= tive)

    6.1 High-Level Functio= nal Requirements

    LightweightM2MHLF-001 = The Lightweight M2M enabler SHALL support a unique ID to identify the LWM2M= Device.

 

It is understood that each device needs a= unique ID.

And within a decvice there may have a few= of physical resources that can be remotely accessed individually.

 

Based on CoAP =A8C18 terminology, it seem= s that Endpoint is correspondant to the OMA Device.

Whether or not?   If it is, att= entions need to pay for that. 

 

I think that giving the description how t= o define and how to access the device or the physical resources is better t= han leaving that to the application.

 

By the way, Location option is defined in= CoAP =A8C18.

The current version describes the locatio= n-query and location-path used as the response to POST request.

And In CoAP =A8C18,    =A1=B0=

     5.10.6.1. ETag as a Response Option

The ETag Option in a response provides the current value (i.e.= , after the request was processed) of the entity-tag for the "tagged

representation". If no Location-* options are present, th= e tagged representation is the selected representation (Section 5.5.3) of the

target resource. If one or more Location-* options are present= and thus a location URI is indicated (Section 5.10.7), the tagged

representation is the representation that would be retrieved b= y a GET request to the location URI.

    5.10.7. Location-Path and Location-Query

The Location-Path and Location-Query Options together indicate= a relative URI that consists either of an absolute path, a query string

or both. A combination of these options is included in a 2.01 = (Created) response to indicate the location of the resource created

as the result of a POST request (see Section 5.8.2). The locat= ion is resolved relative to the request URI. =A1=B0

 

Based on the above text, by the URI the t= arget resource can be accessed.

I got a little confused wether the target= resource is a Device or a phiscal resource? 

 

If the URI indicates a Device, the means = to access phiscal resources is required.

If the URI indicates a physical resource,= CoAP =A8C18 has the means to tell the differences.

 

 

Regards,

 

Gengyu

 

Network Technology Center

School of Computer

Beijng University of Posts & Telecomm= unications

 

 

From: Di= jk, Esko

Sent: Wednesday, November 27, 2013 11:13 PM

Subject: Re: [core] How to correlate request and responses in group communication

 

Yes, = it=A1=AFs currently defined to use the UDP layer for that information. At l= east it=A1=AFs efficient :)

 

If in= formation other than IP address is needed, such as a non-volatile GUID, the= CoAP server could include this as part of its response payload (in case of= GET or PUT).

But t= hat=A1=AFs not the most beautiful solution I agree.

 

Esko<= o:p>

 

From: Likepeng [mailto:likepeng@huawei.com]
Sent: Wednesday, November 27, 2013 09:32
To: Dijk, Esko; core@ietf.org Subject: Re: [core] How to correlate request and responses in group = communication

 

Hi Esko,

 

>T= he identification of the individual response is by the (unicast) IP source = address of the responding CoAP endpoint.=

 

In the response, the o= nly place to put the (unicast) IP source address is the UDP layer, right? B= ecause HRI-Host is used to indicate the target node, not the source node.

 

(CoAP section 5.10.1) = The Uri-Host, Uri-Port, Uri-Path and Uri-Query Options are used to specify = the target resource of a request to a CoAP origin server.=

 

That means, the reques= tor has to rely on UDP layer to get the (unicast) IP source address from th= e response, then correlate the multicast request and the unicast response. = But in my opinion, the correlation should be done in the CoAP layer. CoAP layer should provide some information to b= e used for this purpose.

 

In CoAP spec, it menti= ons that Token MUST be used to match the responses with the multicast reque= st. If there are multiple responses, we have to use source endpoint to diff= erentiate. But this information can be only got from UDP layer. That is an issue, in my opinion.

 

CoAP Section 8.2<= /o:p>

   When matc= hing a response to a multicast request, only the token MUST

   match; th= e source endpoint of the response does not need to (and will

   not) be t= he same as the destination endpoint of the original request.

 

Any thoughts?

 

Thanks,

Kind Regards

Kepeng

 

=B7= =A2=BC=FE=C8=CB: Dijk, Esko [mailto:esko.dijk@phil= ips.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C227=C8=D5 15:01
=CA=D5=BC=FE=C8=CB: Likepeng; core@ietf.org
=D6=F7=CC=E2: RE: [core] How to correlat= e request and responses in group communication

 

Hello= Kepeng,

 = ;

The i= dentification of the individual response is by the (unicast) IP source addr= ess of the responding CoAP endpoint.

Indee= d this would be good to mention somewhere in groupcomm.

Corre= lation of a single request with a set of responses is via Token; in case th= ere are multiple outstanding multicast requests from a single endpoint.

 = ;

Also = core-coap has some information on use of IP address of the responding endpo= int, section 8.2:

 = ;

For t= he purposes of interpreting the Location-* options and any links

 = ;  embedded in the representation and, the request URI (base URI)

 = ;  relative to which the response is interpreted, is formed by replaci= ng

 = ;  the multicast address in the Host component of the original request=

 = ;  URI by the literal IP address of the endpoint actually responding.<= /span>

 = ;

Esko<= /span>

 = ;

From: core [mailto:core-bounces@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: core@ietf.org
Subject: [core] How to correlate request and responses in group comm= unication

 

Hi all,

 =

When I read the group co= mmunication draft, I come up with one question, how to correlate a multicas= t request with the multiple responses from different nodes?

 =

For example, a client se= nds a multicast GET request to a group URI: all.bldg6.example.com, and afte= r some time, it will receive multiple responses from different nodes. In th= e request, it contains one token. In the responses, I assume that all the responses should use the same token a= ccording to the base coap spec. Then how can the client differentiate the d= ifferent responses from different nodes, corresponding to the same request?=

 =

I searched the whole gro= up communication draft, token is not mentioned. So I hope to get opinion fr= om the group.

 =

Thanks,

Kind Regards<= /span>

Kepeng=

 

The information contained in this message may be confidential and= legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you ar= e hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are not = the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message=

_________________________________________= ______
core mailing list
core@ietf.org
https://www.ietf.org= /mailman/listinfo/core

--_000_031DD135F9160444ABBE3B0C36CED6180CC43638011DB3MPN2082MG_-- From trac+core@trac.tools.ietf.org Thu Nov 28 03:00:06 2013 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 EBCE81ADFDB for ; Thu, 28 Nov 2013 03:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 LGcMDEkOQMPW for ; Thu, 28 Nov 2013 03:00:03 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0DD1AE002 for ; Thu, 28 Nov 2013 03:00:03 -0800 (PST) Received: from localhost ([127.0.0.1]:40343 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VlzKB-0001LR-Sg; Thu, 28 Nov 2013 11:59:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 28 Nov 2013 10:59:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/354#comment:2 Message-ID: <075.784386b980d46822fb7e4742689163a6@trac.tools.ietf.org> References: <060.28d199cdef36507776dfc929478c735c@trac.tools.ietf.org> X-Trac-Ticket-ID: 354 In-Reply-To: <060.28d199cdef36507776dfc929478c735c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Cc: core@ietf.org Subject: Re: [core] #354: Group configuration API should enable deletion of individual group memberships X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 11:00:06 -0000 #354: Group configuration API should enable deletion of individual group memberships Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Solution included in [1560] -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Nov 28 03:00:35 2013 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 28FA81AE02A for ; Thu, 28 Nov 2013 03:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 8_9Rzh39279w for ; Thu, 28 Nov 2013 03:00:33 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BB35C1ADFDB for ; Thu, 28 Nov 2013 03:00:33 -0800 (PST) Received: from localhost ([127.0.0.1]:40398 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VlzKi-0001gq-2R; Thu, 28 Nov 2013 12:00:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 28 Nov 2013 11:00:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/355#comment:1 Message-ID: <075.0d7e801b4bdd08d9e314543aee8c3568@trac.tools.ietf.org> References: <060.178361dc4332d6174c594b7781e4603f@trac.tools.ietf.org> X-Trac-Ticket-ID: 355 In-Reply-To: <060.178361dc4332d6174c594b7781e4603f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Cc: core@ietf.org Subject: Re: [core] #355: Clarify assumptions on reliable/unreliable multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 11:00:35 -0000 #355: Clarify assumptions on reliable/unreliable multicast Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Text added in [1560] -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From weigengyu@bupt.edu.cn Thu Nov 28 03:09:40 2013 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 4F0E51AE02B for ; Thu, 28 Nov 2013 03:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.549 X-Spam-Level: X-Spam-Status: No, score=0.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-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 AMQh8d_7QeXV for ; Thu, 28 Nov 2013 03:09:34 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB621ADBCC for ; Thu, 28 Nov 2013 03:09:31 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id ACBED19F372; Thu, 28 Nov 2013 19:09:15 +0800 (HKT) Message-ID: From: "weigengyu" To: "Dijk, Esko" References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <72478E14D297435C8430474E749919F7@WeiGengyuPC> <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Thu, 28 Nov 2013 19:09:14 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01CEEC6D.54328330" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] How to correlate request and responses in group communication 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, 28 Nov 2013 11:09:40 -0000 һ MIME ʽĶ෽ʼ ------=_NextPart_000_0023_01CEEC6D.54328330 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Esko,=20 Thank you for you email.=20 I got that the endpiont is identified by IP address (plus port, plus = security context), and there may be a number of applicatons in one = endpoint. =20 CoAP URI could indicate an endpiont or an physical resourse. CoAP could tell the different resours by CoAP contents (Payload).=20 However, Location option is defined in CoAP =A8C18.=20 In CoAP =A8C18, 5.10.6.1. ETag as a Response Option If one or more Location-* options are present and thus a location = URI is indicated (Section 5.10.7), the tagged representation is the representation that would be retrieved by a = GET request to the location URI. Why not to use Location opotion?=20 Regards,=20 Gengyu=20 Network Technology Center=20 School of Computer Beijng University of Posts & Telecommunications From: Dijk, Esko=20 Sent: Thursday, November 28, 2013 5:30 PM To: weigengyu=20 Cc: core@ietf.org=20 Subject: RE: [core] How to correlate request and responses in group = communication I don=A1=AFt know the OMA LWM2M details, but the CoAP endpoint is likely = to be different =A8C one Device (=3Dnode?) usually supports many = endpoints which could correspond e.g. to different applications on the = Device. And the CoAP endpoint is identified by IP address (plus port, = plus security context) so this is not a suitable UID since the IP = address may change over time. =20 CoAP doesn=A1=AFt support specific options to communicate a node/Device = unique ID back and forth AFAIK. That could be accomplished at lower = layer through security (DTLS authentication) or at higher layer in the = application-level payloads (e.g. a resource /uid that tells the unique = ID of a device, or a UID that is included in the payload of a CoAP = response.) =20 Esko =20 From: weigengyu [mailto:weigengyu@bupt.edu.cn]=20 Sent: Thursday, November 28, 2013 10:14 To: Dijk, Esko Cc: core@ietf.org Subject: Re: [core] How to correlate request and responses in group = communication =20 Hi Esko,=20 =20 In OMA LWM2M Requirements,=20 6. Requirements (Normative) 6.1 High-Level Functional Requirements LightweightM2MHLF-001 The Lightweight M2M enabler SHALL support a = unique ID to identify the LWM2M Device.=20 =20 It is understood that each device needs a unique ID.=20 And within a decvice there may have a few of physical resources that can = be remotely accessed individually.=20 =20 Based on CoAP =A8C18 terminology, it seems that Endpoint is = correspondant to the OMA Device.=20 Whether or not? If it is, attentions need to pay for that. =20 =20 I think that giving the description how to define and how to access the = device or the physical resources is better than leaving that to the = application.=20 =20 By the way, Location option is defined in CoAP =A8C18.=20 The current version describes the location-query and location-path used = as the response to POST request.=20 And In CoAP =A8C18, =A1=B0 5.10.6.1. ETag as a Response Option The ETag Option in a response provides the current value (i.e., after = the request was processed) of the entity-tag for the "tagged representation". If no Location-* options are present, the tagged = representation is the selected representation (Section 5.5.3) of the target resource. If one or more Location-* options are present and thus = a location URI is indicated (Section 5.10.7), the tagged representation is the representation that would be retrieved by a GET = request to the location URI.=20 5.10.7. Location-Path and Location-Query The Location-Path and Location-Query Options together indicate a = relative URI that consists either of an absolute path, a query string or both. A combination of these options is included in a 2.01 (Created) = response to indicate the location of the resource created as the result of a POST request (see Section 5.8.2). The location is = resolved relative to the request URI. =A1=B0 =20 Based on the above text, by the URI the target resource can be accessed. = I got a little confused wether the target resource is a Device or a = phiscal resource? =20 =20 If the URI indicates a Device, the means to access phiscal resources is = required.=20 If the URI indicates a physical resource, CoAP =A8C18 has the means to = tell the differences.=20 =20 =20 Regards,=20 =20 Gengyu=20 =20 Network Technology Center=20 School of Computer Beijng University of Posts & Telecommunications =20 =20 From: Dijk, Esko=20 Sent: Wednesday, November 27, 2013 11:13 PM To: Likepeng ; core@ietf.org=20 Subject: Re: [core] How to correlate request and responses in group = communication =20 Yes, it=A1=AFs currently defined to use the UDP layer for that = information. At least it=A1=AFs efficient :) =20 If information other than IP address is needed, such as a non-volatile = GUID, the CoAP server could include this as part of its response payload = (in case of GET or PUT). But that=A1=AFs not the most beautiful solution I agree. =20 Esko =20 From: Likepeng [mailto:likepeng@huawei.com]=20 Sent: Wednesday, November 27, 2013 09:32 To: Dijk, Esko; core@ietf.org Subject: Re: [core] How to correlate request and responses in group = communication =20 Hi Esko, =20 >The identification of the individual response is by the (unicast) IP = source address of the responding CoAP endpoint. =20 In the response, the only place to put the (unicast) IP source address = is the UDP layer, right? Because HRI-Host is used to indicate the target = node, not the source node. =20 (CoAP section 5.10.1) The Uri-Host, Uri-Port, Uri-Path and Uri-Query = Options are used to specify the target resource of a request to a CoAP = origin server. =20 That means, the requestor has to rely on UDP layer to get the (unicast) = IP source address from the response, then correlate the multicast = request and the unicast response. But in my opinion, the correlation = should be done in the CoAP layer. CoAP layer should provide some = information to be used for this purpose. =20 In CoAP spec, it mentions that Token MUST be used to match the responses = with the multicast request. If there are multiple responses, we have to = use source endpoint to differentiate. But this information can be only = got from UDP layer. That is an issue, in my opinion. =20 CoAP Section 8.2 When matching a response to a multicast request, only the token MUST match; the source endpoint of the response does not need to (and will not) be the same as the destination endpoint of the original request. =20 Any thoughts? =20 Thanks, Kind Regards Kepeng =20 =B7=A2=BC=FE=C8=CB: Dijk, Esko [mailto:esko.dijk@philips.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C227=C8=D5 15:01 =CA=D5=BC=FE=C8=CB: Likepeng; core@ietf.org =D6=F7=CC=E2: RE: [core] How to correlate request and responses in group = communication =20 Hello Kepeng, =20 The identification of the individual response is by the (unicast) IP = source address of the responding CoAP endpoint. Indeed this would be good to mention somewhere in groupcomm. Correlation of a single request with a set of responses is via Token; in = case there are multiple outstanding multicast requests from a single = endpoint. =20 Also core-coap has some information on use of IP address of the = responding endpoint, section 8.2: =20 For the purposes of interpreting the Location-* options and any links embedded in the representation and, the request URI (base URI) relative to which the response is interpreted, is formed by replacing the multicast address in the Host component of the original request URI by the literal IP address of the endpoint actually responding. =20 Esko =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Likepeng Sent: Wednesday, November 27, 2013 03:50 To: core@ietf.org Subject: [core] How to correlate request and responses in group = communication =20 Hi all, =20 When I read the group communication draft, I come up with one question, = how to correlate a multicast request with the multiple responses from = different nodes? =20 For example, a client sends a multicast GET request to a group URI: = all.bldg6.example.com, and after some time, it will receive multiple = responses from different nodes. In the request, it contains one token. = In the responses, I assume that all the responses should use the same = token according to the base coap spec. Then how can the client = differentiate the different responses from different nodes, = corresponding to the same request? =20 I searched the whole group communication draft, token is not mentioned. = So I hope to get opinion from the group. =20 Thanks, Kind Regards Kepeng =20 -------------------------------------------------------------------------= ------- The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0023_01CEEC6D.54328330 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Esko,
 
Thank you for you email.
I got that the endpiont is identified by IP address (plus port, plus security = context),=20 and there may be a number of applicatons in one endpoint. 
CoAP URI could indicate an endpiont or an physical resourse.
CoAP could tell the different resours by CoAP contents (Payload). =
 
However, Location option is defined in CoAP =A8C18.

    In CoAP = =A8C18,=20 5.10.6.1. ETag as a = Response=20 Option

    If one = or more=20 Location-* options are present and thus a location URI is indicated = (Section=20 5.10.7), the tagged

    = representation is=20 the representation that would be retrieved by a GET request to the = location=20 URI.

Gengyu

Network Technology Center

School of Computer

Beijng University of Posts &=20 Telecommunications

From: Dijk, Esko
Sent: Thursday, November 28, 2013 5:30 PM
Subject: RE: [core] How to correlate request and responses = in group=20 communication
 

I = don=A1=AFt know=20 the OMA LWM2M details, but the CoAP endpoint is likely to be different = =A8C one=20 Device (=3Dnode?) usually supports many endpoints which could correspond = e.g. to=20 different applications on the Device. And the CoAP endpoint is = identified by IP=20 address (plus port, plus security context) so this is not a suitable UID = since=20 the IP address may change over time.

 

CoAP doesn=A1=AFt=20 support specific options to communicate a node/Device unique ID back and = forth=20 AFAIK. That could be accomplished at lower layer through security (DTLS=20 authentication) or at higher layer in the application-level payloads = (e.g. a=20 resource /uid that tells the unique ID of a device, or a UID that is = included in=20 the payload of a CoAP response.)

 

Esko

 

From: weigengyu = [mailto:weigengyu@bupt.edu.cn]
Sent: Thursday, November 28, = 2013=20 10:14
To: Dijk, Esko
Cc: = core@ietf.org
Subject:=20 Re: [core] How to correlate request and responses in group=20 communication

 

Hi Esko, =

 

In OMA LWM2M Requirements,=20

    6. = Requirements=20 (Normative)

    6.1 = High-Level=20 Functional Requirements

    = LightweightM2MHLF-001=20 The Lightweight M2M enabler SHALL support a unique ID to identify the = LWM2M=20 Device.

 

It is understood that each = device needs a=20 unique ID.

And within a decvice there may = have a few=20 of physical resources that can be remotely accessed individually.=20

 

Based on CoAP =A8C18 = terminology, it seems=20 that Endpoint is correspondant to the OMA Device. =

Whether or not?   If = it is,=20 attentions need to pay for that. 

 

I think that giving the = description how to=20 define and how to access the device or the physical resources is better = than=20 leaving that to the application.

 

By the way, Location option is = defined in=20 CoAP =A8C18.

The current version describes = the=20 location-query and location-path used as the response to POST request.=20

And In=20 CoAP =A8C18,    =A1=B0

    =20 5.10.6.1. ETag as a Response Option

The=20 ETag Option in a response provides the current value (i.e., after the = request=20 was processed) of the entity-tag for the = "tagged

representation".=20 If no Location-* options are present, the tagged representation is the = selected=20 representation (Section 5.5.3) of the

target=20 resource. If one or more Location-* options are present and thus a = location URI=20 is indicated (Section 5.10.7), the tagged

representation=20 is the representation that would be retrieved by a GET request to the = location=20 URI.

   =20 5.10.7. Location-Path and Location-Query

The=20 Location-Path and Location-Query Options together indicate a relative = URI that=20 consists either of an absolute path, a query = string

or=20 both. A combination of these options is included in a 2.01 (Created) = response to=20 indicate the location of the resource = created

as the=20 result of a POST request (see Section 5.8.2). The location is resolved = relative=20 to the request URI. =A1=B0

 

Based on the above text, by the = URI the=20 target resource can be accessed.

I got a little confused wether = the target=20 resource is a Device or a phiscal resource? 

 

If the URI indicates a Device, = the means=20 to access phiscal resources is required.

If the URI indicates a physical = resource,=20 CoAP =A8C18 has the means to tell the differences.

 

 

Regards,

 

Gengyu

 

Network Technology Center =

School of Computer

Beijng University of Posts & = Telecommunications

 

 

From: Dijk, Esko=20

Sent:=20 Wednesday, November 27, 2013 11:13 PM

To: Likepeng ; core@ietf.org=20

Subject: Re:=20 [core] How to correlate request and responses in group=20 communication

 

Yes, it=A1=AFs=20 currently defined to use the UDP layer for that information. At least = it=A1=AFs=20 efficient :)

 

If = information=20 other than IP address is needed, such as a non-volatile GUID, the CoAP = server=20 could include this as part of its response payload (in case of GET or=20 PUT).

But = that=A1=AFs not=20 the most beautiful solution I agree.

 

Esko

 

From:=20 Likepeng [mailto:likepeng@huawei.com]=20
Sent: Wednesday, November 27, 2013 09:32
To: Dijk, = Esko; core@ietf.org
Subject: Re: = [core] How=20 to correlate request and responses in group=20 communication

 

Hi = Esko,

 

>The=20 identification of the individual response is by the (unicast) IP source = address=20 of the responding CoAP endpoint.

 

In the response, the = only place=20 to put the (unicast) IP source address is the UDP layer, right? Because = HRI-Host=20 is used to indicate the target node, not the source = node.

 

(CoAP section = 5.10.1) The=20 Uri-Host, Uri-Port, Uri-Path and Uri-Query Options are used to specify = the=20 target resource of a request to a CoAP origin = server.

 

That means, the = requestor has to=20 rely on UDP layer to get the (unicast) IP source address from the = response, then=20 correlate the multicast request and the unicast response. But in my = opinion, the=20 correlation should be done in the CoAP layer. CoAP layer should provide = some=20 information to be used for this purpose.

 

In CoAP spec, it = mentions that=20 Token MUST be used to match the responses with the multicast request. If = there=20 are multiple responses, we have to use source endpoint to differentiate. = But=20 this information can be only got from UDP layer. That is an issue, in my = opinion.

 

CoAP Section=20 8.2

   When = matching a=20 response to a multicast request, only the token = MUST

   match; = the source=20 endpoint of the response does not need to (and = will

   not) be = the same as=20 the destination endpoint of the original request.

 

Any=20 thoughts?

 

Thanks,

Kind=20 Regards

Kepeng

 

=B7=A2=BC=FE=C8=CB: Dijk, Esko = [mailto:esko.dijk@philips.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C227=C8=D5 = 15:01
=CA=D5=BC=FE=C8=CB: Likepeng; core@ietf.org
=D6=F7=CC=E2: RE: [core] How to correlate = request and responses in=20 group communication

 

Hello=20 Kepeng,

 

The = identification of the individual response is by the (unicast) IP source = address=20 of the responding CoAP endpoint.

Indeed this=20 would be good to mention somewhere in groupcomm.

Correlation of=20 a single request with a set of responses is via Token; in case there are = multiple outstanding multicast requests from a single = endpoint.

 

Also core-coap=20 has some information on use of IP address of the responding endpoint, = section=20 8.2:

 

For = the=20 purposes of interpreting the Location-* options and any = links

  =20 embedded in the representation and, the request URI (base = URI)

  =20 relative to which the response is interpreted, is formed by=20 replacing

  =20 the multicast address in the Host component of the original = request

  =20 URI by the literal IP address of the endpoint actually = responding.

 

Esko

 

From: core=20 [mailto:core-bounces@ietf.org] = On=20 Behalf Of Likepeng
Sent: Wednesday, November 27, 2013=20 03:50
To: core@ietf.org
Subject: = [core] How to=20 correlate request and responses in group communication

 

Hi = all,

 

When I read the group=20 communication draft, I come up with one question, how to correlate a = multicast=20 request with the multiple responses from different = nodes?

 

For example, a client = sends a=20 multicast GET request to a group URI: all.bldg6.example.com, and after = some=20 time, it will receive multiple responses from different nodes. In the = request,=20 it contains one token. In the responses, I assume that all the responses = should=20 use the same token according to the base coap spec. Then how can the = client=20 differentiate the different responses from different nodes, = corresponding to the=20 same request?

 

I searched the whole = group=20 communication draft, token is not mentioned. So I hope to get opinion = from the=20 group.

 

Thanks,

Kind = Regards

Kepeng

 

The=20 information contained in this message may be confidential and legally = protected=20 under applicable law. The message is intended solely for the = addressee(s). If=20 you are not the intended recipient, you are hereby notified that any = use,=20 forwarding, dissemination, or reproduction of this message is strictly=20 prohibited and may be unlawful. If you are not the intended recipient, = please=20 contact the sender by return e-mail and destroy all copies of the = original=20 message

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

------=_NextPart_000_0023_01CEEC6D.54328330-- From trac+core@trac.tools.ietf.org Thu Nov 28 03:47:53 2013 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 E58A31AE017 for ; Thu, 28 Nov 2013 03:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 pzOvCjYpzcv3 for ; Thu, 28 Nov 2013 03:47:52 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA871AD68D for ; Thu, 28 Nov 2013 03:47:52 -0800 (PST) Received: from localhost ([127.0.0.1]:44949 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vm04T-0004Co-IQ; Thu, 28 Nov 2013 12:47:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 28 Nov 2013 11:47:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/356#comment:1 Message-ID: <075.ea66f105dfc20abd183a9242389e252c@trac.tools.ietf.org> References: <060.91cbb7f0396300e887521dbfdfaad3bc@trac.tools.ietf.org> X-Trac-Ticket-ID: 356 In-Reply-To: <060.91cbb7f0396300e887521dbfdfaad3bc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Cc: core@ietf.org Subject: Re: [core] #356: Which IPv6 multicast scopes for the "All CoAP Nodes" address? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 11:47:54 -0000 #356: Which IPv6 multicast scopes for the "All CoAP Nodes" address? Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: In groupcomm [1560]: reference to draft-droms-6man-multicast-scopes included; guideline added for CoAP server to join link-local and site- local "All CoAP Nodes" address. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Thu Nov 28 03:51:06 2013 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 9160D1AE0AA; Thu, 28 Nov 2013 03:51:06 -0800 (PST) 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 lj53ESPgcljG; Thu, 28 Nov 2013 03:51:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0F01AE0C6; Thu, 28 Nov 2013 03:51:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131128115103.24212.20749.idtracker@ietfa.amsl.com> Date: Thu, 28 Nov 2013 03:51:03 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-17.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, 28 Nov 2013 11:51:06 -0000 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 : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-17.txt Pages : 45 Date : 2013-11-28 Abstract: 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 document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-17 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 esko.dijk@philips.com Thu Nov 28 04:01:55 2013 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 11FD51AE016 for ; Thu, 28 Nov 2013 04:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 5akgrML77nWK for ; Thu, 28 Nov 2013 04:01:53 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id D95E71AD68D for ; Thu, 28 Nov 2013 04:01:51 -0800 (PST) Received: from mail212-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE038.bigfish.com (10.243.66.103) with Microsoft SMTP Server id 14.1.225.22; Thu, 28 Nov 2013 12:01:50 +0000 Received: from mail212-co1 (localhost [127.0.0.1]) by mail212-co1-R.bigfish.com (Postfix) with ESMTP id C2638404D9; Thu, 28 Nov 2013 12:01:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(zz217bI15d6Oc85fh9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h1155h) Received: from mail212-co1 (localhost.localdomain [127.0.0.1]) by mail212-co1 (MessageSwitch) id 1385640108639251_18590; Thu, 28 Nov 2013 12:01:48 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.237]) by mail212-co1.bigfish.com (Postfix) with ESMTP id 96FF210004E; Thu, 28 Nov 2013 12:01:48 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 28 Nov 2013 12:01:47 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.03.0158.002; Thu, 28 Nov 2013 12:01:47 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" , "Carsten Bormann (cabo@tzi.org)" , "Andrew McGregor (andrewmcgr@google.com)" Thread-Topic: GroupComm I-D updated to -17 Thread-Index: Ac7sMLTspNcT6RmKQsWl3NkZWEyLDA== Date: Thu, 28 Nov 2013 12:01:46 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC43768@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180CC43768011DB3MPN2082MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [core] GroupComm I-D updated to -17 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, 28 Nov 2013 12:01:55 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180CC43768011DB3MPN2082MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, the groupcomm I-D has been updated to version 17 now, closing the remaining= open tickets. See below for a log of changes made. It includes the proposed changes to th= e group membership configuration interface as discussed in last IETF meetin= g. Carsten, Andrew: we believe the I-D is ready for WGLC. If you agree with ou= r viewpoint, could you start the WGLC process? regards, Esko & Akbar --- Changes from ietf-16 to ietf-17: o Added guidelines on joining of IPv6/IPv4 "All CoAP Nodes" multicast addresses (#356). o Added MUST support default port in case multicast discovery is available. o In section 2.1 (IP Multicast Background), clarified that IP multicast is not guaranteed and referenced a definition of Reliable Group Communication (#355). o Added section 2.5 (Messages and Responses) to clarify how responses are identified and how Token/MID are used in multicast CoAP. o In section 2.6.2 (RESTful Interface for Configuring Group Memberships), clarified that group management interface is an optional approach for dynamic commissioning and that other approaches can also be used if desired. o Updated section 2.6.2 (RESTful Interface for Configuring Group Memberships) to allow deletion of individual group memberships (#354). o Various editorial updates based on comments by Peter van der Stok. Removed reference to expired draft-vanderstok-core-dna at request of its author. o Various editorial updates for improved readability. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED6180CC43768011DB3MPN2082MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

the groupcomm I-D has been updated to version 17 now= , closing the remaining open tickets.

See below for a log of changes made. It includes the= proposed changes to the group membership configuration interface as discus= sed in last IETF meeting.

 

Carsten, Andrew: we believe the I-D is ready for WGL= C. If you agree with our viewpoint, could you start the WGLC process?

 

regards,

Esko & Akbar

 

---

   Changes from ietf-16 to ietf-17:

 

   o  Added guidelines on joining of = IPv6/IPv4 "All CoAP Nodes"

      multicast addresses (= #356).

 

   o  Added MUST support default port= in case multicast discovery is

      available.

 

   o  In section 2.1 (IP Multicast Ba= ckground), clarified that IP

      multicast is not guar= anteed and referenced a definition of

      Reliable Group Commun= ication (#355).

 

   o  Added section 2.5 (Messages and= Responses) to clarify how

      responses are identif= ied and how Token/MID are used in multicast

      CoAP.

 

   o  In section 2.6.2 (RESTful Inter= face for Configuring Group

      Memberships), clarifi= ed that group management interface is an

      optional approach for= dynamic commissioning and that other

      approaches can also b= e used if desired.

 

   o  Updated section 2.6.2 (RESTful = Interface for Configuring Group

      Memberships) to allow= deletion of individual group memberships

      (#354).

 

   o  Various editorial updates based= on comments by Peter van der Stok.

      Removed reference to = expired draft-vanderstok-core-dna at request

      of its author.

 

   o  Various editorial updates for i= mproved readability.

 

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED6180CC43768011DB3MPN2082MG_-- From cabo@tzi.org Thu Nov 28 06:33:52 2013 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 788401AE141 for ; Thu, 28 Nov 2013 06:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, 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 HavKD1Azc520 for ; Thu, 28 Nov 2013 06:33:50 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 033FC1AE13E for ; Thu, 28 Nov 2013 06:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rASEXYXS013153; Thu, 28 Nov 2013 15:33:36 +0100 (CET) Received: from [192.168.217.105] (p5489053C.dip0.t-ipconnect.de [84.137.5.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0D9935F0; Thu, 28 Nov 2013 15:33:33 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=gb18030 From: Carsten Bormann X-Priority: 3 In-Reply-To: Date: Thu, 28 Nov 2013 15:33:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E5E0631-C787-47AA-90F4-9ECA6A205B56@tzi.org> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <72478E14D297435C8430474E749919F7@WeiGengyuPC> <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: weigengyu X-Mailer: Apple Mail (2.1822) Cc: "core \(core@ietf.org\)" Subject: Re: [core] How to correlate request and responses in group communication 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, 28 Nov 2013 14:33:52 -0000 On 28 Nov 2013, at 12:09, weigengyu wrote: > However, Location option is defined in CoAP =A8C18. In REST, there are two ways for a client to ask the server to create a = resource: =A1=AA PUT, where the client supplies the URI for the new resource, and =A1=AA POST on a resource that supports creating new resources, where = the server selects the URI for the new resource. The Location options are for the latter case; they allow the server to = indicate the URI that it actually chose, to the client, with the = response to the POST request. I=A1=AFm not sure I understand what you are trying to achieve with this = set of options. Gr=A8=B9=810=898e, Carsten From weigengyu@bupt.edu.cn Thu Nov 28 20:03:43 2013 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 D23E71AE0D9 for ; Thu, 28 Nov 2013 20:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.326 X-Spam-Level: * X-Spam-Status: No, score=1.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 HfXZGwbd7e1c for ; Thu, 28 Nov 2013 20:03:41 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id A07EE1AE0C9 for ; Thu, 28 Nov 2013 20:03:40 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 178DD19F374; Fri, 29 Nov 2013 12:03:37 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carsten Bormann" References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <72478E14D297435C8430474E749919F7@WeiGengyuPC> <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> <2E5E0631-C787-47AA-90F4-9ECA6A205B56@tzi.org> In-Reply-To: <2E5E0631-C787-47AA-90F4-9ECA6A205B56@tzi.org> Date: Fri, 29 Nov 2013 12:03:35 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb18030"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] How to correlate request and responses in group communication 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, 29 Nov 2013 04:03:44 -0000 Hi Carsten, Thank you for your explanations. > Im not sure I understand what you are trying to achieve with this set of > options. I would like to use the CoAP already defined mechanisms to resolve umbiguity locations. Using CoAP-defined mechanisms is better than leaving it to applications. The CoAP -18 gives descriptions about Location options are used by POST. And in CoAP -18 "5.10.6 ETag" is defined as a request option and a response option, and ETag may contain Location Options. In "5.10.6.1. ETag as a Response Option, If one or more Location-* options are present and thus a location URI is indicated (Section 5.10.7), the tagged representation is the representation that would be retrieved by a GET request to the location URI. In CoAP -18 6. CoAP URIs CoAP uses the "coap" and "coaps" URI schemes for identifying CoAP resources and providing a means of locating the resource. Based on above texts, I see that the URI from Location options could be used "by a GET request to the location URI." Current CoAP -18 has not given descriptions whether the GET is prohibited from Location options. So, GET request could use the URI, or Etag, or Location options. Then the responese(s) might use URI, or Etag, or Location options even though caches are existed. When Location option(s) is in GET, the client can use the standard means to see the different responses from multiple locations. I believe this CoAP Location facility could be beneficial to a number of location-based applicatons. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----ԭʼʼ----- From: Carsten Bormann Sent: Thursday, November 28, 2013 10:33 PM To: weigengyu Cc: Dijk, Esko ; core (core@ietf.org) Subject: Re: [core] How to correlate request and responses in group communication On 28 Nov 2013, at 12:09, weigengyu wrote: > However, Location option is defined in CoAP C18. In REST, there are two ways for a client to ask the server to create a resource: PUT, where the client supplies the URI for the new resource, and POST on a resource that supports creating new resources, where the server selects the URI for the new resource. The Location options are for the latter case; they allow the server to indicate the URI that it actually chose, to the client, with the response to the POST request. Im not sure I understand what you are trying to achieve with this set of options. Gr08e, Carsten From esko.dijk@philips.com Fri Nov 29 01:52:09 2013 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 E2B331AC7F1 for ; Fri, 29 Nov 2013 01:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 leVLOeiBD6BX for ; Fri, 29 Nov 2013 01:52:07 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id C60631A1F55 for ; Fri, 29 Nov 2013 01:52:07 -0800 (PST) Received: from mail96-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Fri, 29 Nov 2013 09:52:05 +0000 Received: from mail96-ch1 (localhost [127.0.0.1]) by mail96-ch1-R.bigfish.com (Postfix) with ESMTP id 9FAFC1E04E0; Fri, 29 Nov 2013 09:52:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(z579ehz217bI15d6O168aJ542I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzd9hz1de098h1033IL8275dh1de097hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h1155h) Received: from mail96-ch1 (localhost.localdomain [127.0.0.1]) by mail96-ch1 (MessageSwitch) id 1385718723305176_16172; Fri, 29 Nov 2013 09:52:03 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail96-ch1.bigfish.com (Postfix) with ESMTP id 44A89100079; Fri, 29 Nov 2013 09:52:03 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 29 Nov 2013 09:52:03 +0000 Received: from 011-DB3MMR1-017.MGDPHG.emi.philips.com (10.128.28.102) by 011-DB3MMR1-001.MGDPHG.emi.philips.com (10.128.28.51) with Microsoft SMTP Server (TLS) id 14.3.158.2; Fri, 29 Nov 2013 09:51:46 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-017.MGDPHG.emi.philips.com ([10.128.28.102]) with mapi id 14.03.0158.002; Fri, 29 Nov 2013 09:51:45 +0000 From: "Dijk, Esko" To: weigengyu , Carsten Bormann Thread-Topic: [core] How to correlate request and responses in group communication Thread-Index: Ac7rG1cGT4fNhozCS7KwdPTKZ1kSxwAIgb/gAAIa26AADwLsQAAmFA0AAABYPeAAA6/RAAAHIpYAABxKaYAAC3jlIA== Date: Fri, 29 Nov 2013 09:51:44 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC439B1@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <72478E14D297435C8430474E749919F7@WeiGengyuPC> <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> <2E5E0631-C787-47AA-90F4-9ECA6A205B56@tzi.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.85.136.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org" Subject: Re: [core] How to correlate request and responses in group communication 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, 29 Nov 2013 09:52:10 -0000 If I understand correctly, the proposed idea is to use the Location-* Optio= ns in a response to indicate the identity/source of a response. In a respon= se to a multicast, the identity/source of a response is not visible at the = CoAP layer. (Only below it, in the UDP layer.) However, there is no "Location-Host" option defined, only the relative Loca= tion-Path and Location-Query options. So this would not help in identifying= the source of the response! Unless we define an option like "Location-Hos= t". Perhaps a better solution is to allow the existing "Uri-Host" option in a r= esponse (optionally) to identify the source of the response. This is quite = close to the current meaning of Uri-Host, but then applied to a CoAP respon= se situation. The contents of Uri-Host may be an IP literal or a hostname (= which I assume to be the most stable identifier). In terms of standardizati= on, this looks like an easy thing to add, but there could be impact on impl= ementations. Any thoughts - do we need server identification as a standardized CoAP Opti= on? Are there any transports other than UDP/TCP - that allow multicast - bu= t somehow don't provide the source IP address of the response in the layer = below COAP? Esko -----Original Message----- From: weigengyu [mailto:weigengyu@bupt.edu.cn] Sent: Friday, November 29, 2013 05:04 To: Carsten Bormann Cc: Dijk, Esko; core@ietf.org Subject: Re: [core] How to correlate request and responses in group communi= cation Hi Carsten, Thank you for your explanations. > I'm not sure I understand what you are trying to achieve with this set > of options. I would like to use the CoAP already defined mechanisms to resolve umbiguit= y locations. Using CoAP-defined mechanisms is better than leaving it to applications. The CoAP -18 gives descriptions about Location options are used by POST. And in CoAP -18 "5.10.6 ETag" is defined as a request option and a response= option, and ETag may contain Location Options. In "5.10.6.1. ETag as a Response Option, If one or more Location-* options are present and thus a location URI i= s indicated (Section 5.10.7), the tagged representation is the representation that would be retrieved by a GET r= equest to the location URI. In CoAP -18 6. CoAP URIs CoAP uses the "coap" and "coaps" URI schemes for identifying CoAP resou= rces and providing a means of locating the resource. Based on above texts, I see that the URI from Location options could be use= d "by a GET request to the location URI." Current CoAP -18 has not given descriptions whether the GET is prohibited f= rom Location options. So, GET request could use the URI, or Etag, or Location options. Then the responese(s) might use URI, or Etag, or Location options even thou= gh caches are existed. When Location option(s) is in GET, the client can use the standard means to= see the different responses from multiple locations. I believe this CoAP Location facility could be beneficial to a number of lo= cation-based applicatons. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From likepeng@huawei.com Fri Nov 29 02:51:48 2013 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 671881AD8F4 for ; Fri, 29 Nov 2013 02:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 FL2ZA18kecTV for ; Fri, 29 Nov 2013 02:51:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6331ACCE5 for ; Fri, 29 Nov 2013 02:51:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAV48479; Fri, 29 Nov 2013 10:51:42 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 Nov 2013 10:51:04 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 Nov 2013 10:51:37 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.45]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 29 Nov 2013 18:51:34 +0800 From: Likepeng To: "Dijk, Esko" , weigengyu , Carsten Bormann Thread-Topic: [core] How to correlate request and responses in group communication Thread-Index: AQHO7Oizu8QSP4CrekiRRg0n3K3w6Jo8BR8w Date: Fri, 29 Nov 2013 10:51:33 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC12C9@SZXEMA501-MBS.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <72478E14D297435C8430474E749919F7@WeiGengyuPC> <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> <2E5E0631-C787-47AA-90F4-9ECA6A205B56@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC439B1@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC439B1@011-DB3MPN2-082.MGDPHG.emi.philips.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] How to correlate request and responses in group communication 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, 29 Nov 2013 10:51:48 -0000 PlBlcmhhcHMgYSBiZXR0ZXIgc29sdXRpb24gaXMgdG8gYWxsb3cgdGhlIGV4aXN0aW5nICJVcmkt SG9zdCIgb3B0aW9uIGluIGEgcmVzcG9uc2UgKG9wdGlvbmFsbHkpIHRvIGlkZW50aWZ5IHRoZSBz b3VyY2Ugb2YgdGhlIHJlc3BvbnNlLg0KDQpUbyBhdm9pZCBjb25mdXNpb24sIEkgcHJlZmVyIHRv IGRlZmluZSBhbiBvcHRpb24gbGlrZSAiTG9jYXRpb24tSG9zdCIuDQoNCj5BbnkgdGhvdWdodHMg LSBkbyB3ZSBuZWVkIHNlcnZlciBpZGVudGlmaWNhdGlvbiBhcyBhIHN0YW5kYXJkaXplZCBDb0FQ IE9wdGlvbj8gDQoNClllcywgSSB0aGluayB3ZSBuZWVkIHRoYXQuDQoNCj5BcmUgdGhlcmUgYW55 IHRyYW5zcG9ydHMgb3RoZXIgdGhhbiBVRFAvVENQIC0gdGhhdCBhbGxvdyBtdWx0aWNhc3QgLSBi dXQgc29tZWhvdyBkb24ndCBwcm92aWRlIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBvZiB0aGUgcmVz cG9uc2UgaW4gdGhlIGxheWVyIGJlbG93IENPQVA/DQoNClNNUyBhbGxvd3MgbXVsdGljYXN0Lg0K DQpFdmVuIGlmIHRyYW5zcG9ydHMgb3RoZXIgdGhhbiBVRFAvVENQIHByb3ZpZGUgc291cmNlIGFk ZHJlc3Mgb3RoZXIgdGhhbiBJUCBhZGRyZXNzLCB3ZSBzdGlsbCBuZWVkIHRvIHJlbHkgb24gdHJh bnNwb3J0IGxheWVyLiBXZSBzaG91bGQgaWRlbnRpZnkgdGhlIHNvdXJjZSBpbiB0aGUgQ29BUCBs YXllci4NCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+ yMs6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGlqaywgRXNrbw0K t6LLzcqxvOQ6IDIwMTPE6jEx1MIyOcjVIDE3OjUyDQrK1bz+yMs6IHdlaWdlbmd5dTsgQ2Fyc3Rl biBCb3JtYW5uDQqzrcvNOiBjb3JlQGlldGYub3JnDQrW98ziOiBSZTogW2NvcmVdIEhvdyB0byBj b3JyZWxhdGUgcmVxdWVzdCBhbmQgcmVzcG9uc2VzIGluIGdyb3VwIGNvbW11bmljYXRpb24NCg0K SWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIHByb3Bvc2VkIGlkZWEgaXMgdG8gdXNlIHRo ZSBMb2NhdGlvbi0qIE9wdGlvbnMgaW4gYSByZXNwb25zZSB0byBpbmRpY2F0ZSB0aGUgaWRlbnRp dHkvc291cmNlIG9mIGEgcmVzcG9uc2UuIEluIGEgcmVzcG9uc2UgdG8gYSBtdWx0aWNhc3QsIHRo ZSBpZGVudGl0eS9zb3VyY2Ugb2YgYSByZXNwb25zZSBpcyBub3QgdmlzaWJsZSBhdCB0aGUgQ29B UCBsYXllci4gKE9ubHkgYmVsb3cgaXQsIGluIHRoZSBVRFAgbGF5ZXIuKQ0KDQpIb3dldmVyLCB0 aGVyZSBpcyBubyAiTG9jYXRpb24tSG9zdCIgb3B0aW9uIGRlZmluZWQsIG9ubHkgdGhlIHJlbGF0 aXZlIExvY2F0aW9uLVBhdGggYW5kIExvY2F0aW9uLVF1ZXJ5IG9wdGlvbnMuIFNvIHRoaXMgd291 bGQgbm90IGhlbHAgaW4gaWRlbnRpZnlpbmcgdGhlIHNvdXJjZSBvZiB0aGUgcmVzcG9uc2UhICBV bmxlc3Mgd2UgZGVmaW5lIGFuIG9wdGlvbiBsaWtlICJMb2NhdGlvbi1Ib3N0Ii4NCg0KUGVyaGFw cyBhIGJldHRlciBzb2x1dGlvbiBpcyB0byBhbGxvdyB0aGUgZXhpc3RpbmcgIlVyaS1Ib3N0IiBv cHRpb24gaW4gYSByZXNwb25zZSAob3B0aW9uYWxseSkgdG8gaWRlbnRpZnkgdGhlIHNvdXJjZSBv ZiB0aGUgcmVzcG9uc2UuIFRoaXMgaXMgcXVpdGUgY2xvc2UgdG8gdGhlIGN1cnJlbnQgbWVhbmlu ZyBvZiBVcmktSG9zdCwgYnV0IHRoZW4gYXBwbGllZCB0byBhIENvQVAgcmVzcG9uc2Ugc2l0dWF0 aW9uLiBUaGUgY29udGVudHMgb2YgVXJpLUhvc3QgbWF5IGJlIGFuIElQIGxpdGVyYWwgb3IgYSBo b3N0bmFtZSAod2hpY2ggSSBhc3N1bWUgdG8gYmUgdGhlIG1vc3Qgc3RhYmxlIGlkZW50aWZpZXIp LiBJbiB0ZXJtcyBvZiBzdGFuZGFyZGl6YXRpb24sIHRoaXMgbG9va3MgbGlrZSBhbiBlYXN5IHRo aW5nIHRvIGFkZCwgYnV0IHRoZXJlIGNvdWxkIGJlIGltcGFjdCBvbiBpbXBsZW1lbnRhdGlvbnMu DQoNCkFueSB0aG91Z2h0cyAtIGRvIHdlIG5lZWQgc2VydmVyIGlkZW50aWZpY2F0aW9uIGFzIGEg c3RhbmRhcmRpemVkIENvQVAgT3B0aW9uPyBBcmUgdGhlcmUgYW55IHRyYW5zcG9ydHMgb3RoZXIg dGhhbiBVRFAvVENQIC0gdGhhdCBhbGxvdyBtdWx0aWNhc3QgLSBidXQgc29tZWhvdyBkb24ndCBw cm92aWRlIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBvZiB0aGUgcmVzcG9uc2UgaW4gdGhlIGxheWVy IGJlbG93IENPQVA/DQoNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHdlaWdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbl0NClNlbnQ6IEZyaWRheSwg Tm92ZW1iZXIgMjksIDIwMTMgMDU6MDQNClRvOiBDYXJzdGVuIEJvcm1hbm4NCkNjOiBEaWprLCBF c2tvOyBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIEhvdyB0byBjb3JyZWxhdGUg cmVxdWVzdCBhbmQgcmVzcG9uc2VzIGluIGdyb3VwIGNvbW11bmljYXRpb24NCg0KSGkgQ2Fyc3Rl biwNCg0KVGhhbmsgeW91IGZvciB5b3VyIGV4cGxhbmF0aW9ucy4NCj4gSSdtIG5vdCBzdXJlIEkg dW5kZXJzdGFuZCB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGFjaGlldmUgd2l0aCB0aGlzIHNldCAN Cj4gb2Ygb3B0aW9ucy4NCkkgd291bGQgbGlrZSB0byB1c2UgdGhlIENvQVAgYWxyZWFkeSBkZWZp bmVkIG1lY2hhbmlzbXMgdG8gcmVzb2x2ZSB1bWJpZ3VpdHkgbG9jYXRpb25zLg0KVXNpbmcgQ29B UC1kZWZpbmVkIG1lY2hhbmlzbXMgaXMgYmV0dGVyIHRoYW4gbGVhdmluZyBpdCB0byBhcHBsaWNh dGlvbnMuDQoNClRoZSBDb0FQIC0xOCBnaXZlcyBkZXNjcmlwdGlvbnMgYWJvdXQgTG9jYXRpb24g b3B0aW9ucyBhcmUgdXNlZCBieSBQT1NULg0KQW5kIGluIENvQVAgLTE4ICI1LjEwLjYgRVRhZyIg aXMgZGVmaW5lZCBhcyBhIHJlcXVlc3Qgb3B0aW9uIGFuZCBhIHJlc3BvbnNlIG9wdGlvbiwgYW5k IEVUYWcgbWF5IGNvbnRhaW4gTG9jYXRpb24gT3B0aW9ucy4NCkluICI1LjEwLjYuMS4gRVRhZyBh cyBhIFJlc3BvbnNlIE9wdGlvbiwNCiAgICBJZiBvbmUgb3IgbW9yZSBMb2NhdGlvbi0qIG9wdGlv bnMgYXJlIHByZXNlbnQgYW5kIHRodXMgYSBsb2NhdGlvbiBVUkkgaXMgaW5kaWNhdGVkIChTZWN0 aW9uIDUuMTAuNyksIHRoZSB0YWdnZWQNCiAgICByZXByZXNlbnRhdGlvbiBpcyB0aGUgcmVwcmVz ZW50YXRpb24gdGhhdCB3b3VsZCBiZSByZXRyaWV2ZWQgYnkgYSBHRVQgcmVxdWVzdCB0byB0aGUg bG9jYXRpb24gVVJJLg0KSW4gQ29BUCAtMTggNi4gQ29BUCBVUklzDQogICAgQ29BUCB1c2VzIHRo ZSAiY29hcCIgYW5kICJjb2FwcyIgVVJJIHNjaGVtZXMgZm9yIGlkZW50aWZ5aW5nIENvQVAgcmVz b3VyY2VzIGFuZCBwcm92aWRpbmcgYSBtZWFucyBvZiBsb2NhdGluZyB0aGUgcmVzb3VyY2UuDQpC YXNlZCBvbiBhYm92ZSB0ZXh0cywgSSBzZWUgdGhhdCB0aGUgVVJJIGZyb20gTG9jYXRpb24gb3B0 aW9ucyBjb3VsZCBiZSB1c2VkICJieSBhIEdFVCByZXF1ZXN0IHRvIHRoZSBsb2NhdGlvbiBVUkku Ig0KDQpDdXJyZW50IENvQVAgLTE4IGhhcyBub3QgZ2l2ZW4gZGVzY3JpcHRpb25zIHdoZXRoZXIg dGhlIEdFVCBpcyBwcm9oaWJpdGVkIGZyb20gTG9jYXRpb24gb3B0aW9ucy4NClNvLCBHRVQgcmVx dWVzdCBjb3VsZCB1c2UgdGhlIFVSSSwgb3IgRXRhZywgb3IgTG9jYXRpb24gb3B0aW9ucy4NClRo ZW4gdGhlIHJlc3BvbmVzZShzKSBtaWdodCB1c2UgVVJJLCBvciBFdGFnLCBvciBMb2NhdGlvbiBv cHRpb25zIGV2ZW4gdGhvdWdoIGNhY2hlcyBhcmUgZXhpc3RlZC4NCg0KV2hlbiBMb2NhdGlvbiBv cHRpb24ocykgaXMgaW4gR0VULCB0aGUgY2xpZW50IGNhbiB1c2UgdGhlIHN0YW5kYXJkIG1lYW5z IHRvIHNlZSB0aGUgZGlmZmVyZW50IHJlc3BvbnNlcyBmcm9tIG11bHRpcGxlIGxvY2F0aW9ucy4N CkkgYmVsaWV2ZSB0aGlzIENvQVAgTG9jYXRpb24gZmFjaWxpdHkgY291bGQgYmUgYmVuZWZpY2lh bCB0byBhIG51bWJlciBvZiBsb2NhdGlvbi1iYXNlZCBhcHBsaWNhdG9ucy4NCg0KDQpSZWdhcmRz LA0KDQpHZW5neXUNCg0KTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0KU2Nob29sIG9mIENvbXB1 dGVyDQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgJiBUZWxlY29tbXVuaWNhdGlvbnMNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVj dGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlz c2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBh bmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxp c3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29yZQ0K From weigengyu@bupt.edu.cn Fri Nov 29 03:33:51 2013 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 464BA1ADBCC for ; Fri, 29 Nov 2013 03:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.326 X-Spam-Level: * X-Spam-Status: No, score=1.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 A_kLA8LQdZ7v for ; Fri, 29 Nov 2013 03:33:48 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 365F31AD8DB for ; Fri, 29 Nov 2013 03:33:45 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id CA3E819F374; Fri, 29 Nov 2013 19:33:41 +0800 (HKT) Message-ID: <8030FBAA46014FD6851F4200211A66D5@WeiGengyuPC> From: "weigengyu" To: "Likepeng" , "Dijk, Esko" , "Carsten Bormann" References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <72478E14D297435C8430474E749919F7@WeiGengyuPC> <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> <2E5E0631-C787-47AA-90F4-9ECA6A205B56@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC439B1@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252AC12C9@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC12C9@SZXEMA501-MBS.china.huawei.com> Date: Fri, 29 Nov 2013 19:33:42 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] How to correlate request and responses in group communication 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, 29 Nov 2013 11:33:51 -0000 >> If I understand correctly, the proposed idea is to use the Location-* >> Options in a response to indicate the identity/source of a response. In a response to a multicast, the identity/source of a response is not visible at the CoAP layer. (Only below it, in the UDP layer.) Yes. >> Perhaps a better solution is to allow the existing "Uri-Host" option in a >> response (optionally) to identify the source of the response. >To avoid confusion, I prefer to define an option like "Location-Host". Actually, it is an extension of Location option. >>Any thoughts - do we need server identification as a standardized CoAP >>Option? > Yes, I think we need that. +1. >>In terms of standardization, this looks like an easy thing to add, but >>there could be impact on implementations. I do not think that "impact on implementations" is a server problem. >>Any thoughts - do we need server identification as a standardized CoAP >>Option? Perhaps not. With URI or extended Location option, a server could be accessed and servers could be distinguishied. It seems that the CoAP Device should be defined. The term "CoAP Device" has been appeared in CoAP drafts, but not as a terminology. >>Are there any transports other than UDP/TCP - that allow multicast - but >>somehow don't provide the source IP address of the response in the layer >>below COAP? > SMS SMS is a transmission facility. It depends on what you put into the SMS 140bytes' payload. Regards, Gengyu -----ԭʼʼ----- From: Likepeng Sent: Friday, November 29, 2013 6:51 PM To: Dijk, Esko ; weigengyu ; Carsten Bormann Cc: core@ietf.org Subject: Re: [core] How to correlate request and responses in group communication >Perhaps a better solution is to allow the existing "Uri-Host" option in a >response (optionally) to identify the source of the response. To avoid confusion, I prefer to define an option like "Location-Host". >Any thoughts - do we need server identification as a standardized CoAP >Option? Yes, I think we need that. >Are there any transports other than UDP/TCP - that allow multicast - but >somehow don't provide the source IP address of the response in the layer >below COAP? SMS allows multicast. Even if transports other than UDP/TCP provide source address other than IP address, we still need to rely on transport layer. We should identify the source in the CoAP layer. Kind Regards Kepeng -----ʼԭ----- : core [mailto:core-bounces@ietf.org] Dijk, Esko ʱ: 20131129 17:52 ռ: weigengyu; Carsten Bormann : core@ietf.org : Re: [core] How to correlate request and responses in group communication If I understand correctly, the proposed idea is to use the Location-* Options in a response to indicate the identity/source of a response. In a response to a multicast, the identity/source of a response is not visible at the CoAP layer. (Only below it, in the UDP layer.) However, there is no "Location-Host" option defined, only the relative Location-Path and Location-Query options. So this would not help in identifying the source of the response! Unless we define an option like "Location-Host". Perhaps a better solution is to allow the existing "Uri-Host" option in a response (optionally) to identify the source of the response. This is quite close to the current meaning of Uri-Host, but then applied to a CoAP response situation. The contents of Uri-Host may be an IP literal or a hostname (which I assume to be the most stable identifier). In terms of standardization, this looks like an easy thing to add, but there could be impact on implementations. Any thoughts - do we need server identification as a standardized CoAP Option? Are there any transports other than UDP/TCP - that allow multicast - but somehow don't provide the source IP address of the response in the layer below COAP? Esko -----Original Message----- From: weigengyu [mailto:weigengyu@bupt.edu.cn] Sent: Friday, November 29, 2013 05:04 To: Carsten Bormann Cc: Dijk, Esko; core@ietf.org Subject: Re: [core] How to correlate request and responses in group communication Hi Carsten, Thank you for your explanations. > I'm not sure I understand what you are trying to achieve with this set > of options. I would like to use the CoAP already defined mechanisms to resolve umbiguity locations. Using CoAP-defined mechanisms is better than leaving it to applications. The CoAP -18 gives descriptions about Location options are used by POST. And in CoAP -18 "5.10.6 ETag" is defined as a request option and a response option, and ETag may contain Location Options. In "5.10.6.1. ETag as a Response Option, If one or more Location-* options are present and thus a location URI is indicated (Section 5.10.7), the tagged representation is the representation that would be retrieved by a GET request to the location URI. In CoAP -18 6. CoAP URIs CoAP uses the "coap" and "coaps" URI schemes for identifying CoAP resources and providing a means of locating the resource. Based on above texts, I see that the URI from Location options could be used "by a GET request to the location URI." Current CoAP -18 has not given descriptions whether the GET is prohibited from Location options. So, GET request could use the URI, or Etag, or Location options. Then the responese(s) might use URI, or Etag, or Location options even though caches are existed. When Location option(s) is in GET, the client can use the standard means to see the different responses from multiple locations. I believe this CoAP Location facility could be beneficial to a number of location-based applicatons. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core


On Tue, Nov 26, 2013 at 10:50 AM, Nicolas Damour <ndamour@sierraw= ireless.com> wrote:

Hello.<= u>

=C2= =A0

I may be swimming against the current here, so I=E2=80=99m sorry= to be a little iconoclast here (and if I am wrong, please accept my apolog= ies in advance).

I would sa= y that from a strict theoretical point of view, authorization does absol= utely not require authentication.

=C2= =A0

A very simple example in the physical world is access to a safe = in some (possibly Swiss) banks.

As long as= you have the key (or passcode), you can get access to the safe.<= /u>

And no one= will ever ask you for your identity.

As a matter of fact, in some of t= hese cases it is absolutely essential that authorization happens with no fo= rm of authentication whatsoever.

=C2= =A0

In the IT world, it=E2=80=99s quite the same.

An applica= tion could access a service by displaying some sort of credential, while ne= ver authenticating itself.

I believe = that OAuth, for example, does provide that sort of mechanism.=

=C2= =A0

Now, of course there is value in authentication as well.<= u>

=C2= =A0

But I would think that to say that authorization requires authen= tication is plainly wrong.

=C2= =A0

Just my two cents,

=C2= =A0

Nicolas.

=C2= =A0

=C2=A0

=C2= =A0

Nicolas DAMOUR=C2=A0::=C2=A0S= enior Manager, Business and Innovation Development=

SIERRA WIRELESS=C2=A0::=C2=A0CTO Office

Phone +33 (0) 670 706 003

ndamour@sierrawireless.com :: www= .sierrawireless.com=

=C2=A0

De=C2=A0:= core [mailto:core-bounces@ietf.org] De la part de = Likepeng
Envoy=C3=A9=C2=A0: mardi 26 novembre 2013 02:19
=C3=80=C2=A0:<= /b> Bert Greevenbosch; Rene Struik; Ludwig Seitz; core@ietf.org
Objet=C2=A0: Re: [cor= e] Security use cases for CoRE

=C2=A0<= /u>

= >authentication is essential for authorization

=C2=A0<= /span>

+1.

=C2=A0<= /span>

>we aim to get this draft accepted as (informational) w= orking group document at some point.

=C2=A0<= /span>

I believe a separate WG is more appropriate for this item,= since we have a lot of security issues and we really need the help from se= curity area experts and we need more new energies for this area.<= /u>

=C2=A0<= /span>

Thanks,

Kind Re= gards

Kepeng

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: core [mailto:core-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Bert Greevenbosch
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B411=E6=9C=8826=E6=97=A5 8:31
=E6=94=B6=E4=BB=B6=E4=BA=BA: Rene Struik; Ludwig Seitz; core@ietf.org
=E4=B8=BB=E9=A2=98: Re: [core] Security use cases for CoRE

=C2=A0

+1, authentication is essential for authorisation.=

= =C2=A0

From: cor= e [mailto:core-b= ounces@ietf.org] On Behalf Of Rene Struik
Sent: 25 November 2013 21:20
To: Ludwig Seitz; core@ietf.org
Subject: Re: [core] Security use cases for CoRE

=C2=A0

=

Hi Ludwig:

Authoriz= ation can only be enforced via proper authentication mechanisms, so I do ex= pect any description of the former to refer to the latter.

Rene

On 11/25/2013 6:28 AM, Ludwig Seitz wrote:=

He= llo,


as those of you who attended IETF88 might remember, I am working on= a draft on CoRE security use cases [1] with a group of interested people f= rom this WG.

The current structure of the draft contains usecases f= or general communication security, DoS prevention, authentication as well a= s authorization.

In an offline discussion it has been suggested that the use cases for c= ommSec and authentication are well understood by CoRE and mostly covered by= the work of DICE. It was therefore suggested to focus on authorization use= cases.

I'd like to solicit the opinion of the WG on this matter, especiall= y since we aim to get this draft accepted as (informational) working group = document at some point.


tl;dr : Should [1] be about authorizati= on use cases only?


Regards,

Ludwig Seitz

[1] draft-seitz-core-sec-usec= ases-00 




_______________________________________________

core mailing list
=
cor=
e@ietf.org
https://w=
ww.ietf.org/mailman/listinfo/core






-- 
email: rstruik.ext@gmail.com |=
 Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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