Re: [core] group-comm comments

["weigengyu" <[e-mail]>]

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: [e-mail]
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:[e-mail]]
Sent: Thursday 20 December 2012 11:26
To: Dijk, Esko
Cc: [e-mail]; 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: <missing>
>  - 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: <missing> / dependency on IANA IPv6 allocation
>  - any configurations with a central controller on the backbone
> multicasting: <missing>

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:[e-mail]]
>  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,
>
> <not so constrained> 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
>
>  <Instance>.<ServiceType>.<Domain>, 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.<Domain> is defined and it points to an SRV
>
>  record having the <Instance>.<ServiceType>.<Domain> 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.<Domain>.
>
> 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 | |
>
>  | | </rd>;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: [e-mail]
>
> www: www.vanderstok.org [3]
>
> tel NL: [phone] F: [phone]
>
> -------------------------
>  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
[e-mail]
https://www.ietf.org/mailman/listinfo/core