Opened 10 years ago

Closed 10 years ago

#237 closed editorial (wontfix)

Multicast -> reference groupcomm draft

Reported by: cabo@… Owned by: draft-ietf-core-observe@…
Priority: minor Milestone: post-WGLC-1
Component: observe Version: observe-05
Severity: In WG Last Call Keywords:
Cc:

Description

Peter van der Stok notes (msg03246):

Probably, this has been stated before, in that case I like to reiterate that a reference to the groupcomm draft is called for.

The subject: a node sends messages about resource state changes to a group of clients is indeed at the heart of group communication as pointed out in the groupcomm draft.

This draft also clarifies the different requirements on group communication and the protocols that satisfy a subset of these requirements.

In your implementation, each client is forced to ack a unicast when it is sent with a CON message, and otherwise the message is not ack’ed and no reliability is “guaranteed”.

Some multicast protocols can guarantee reliability without acking but by replicating a message along different paths.

IMO, the draft will certainly improve when these possibilities are taken into account by explaining how to use an appropriate group communication protocol when it is present.

Another point is the statement that the node should maintain a list of clients.

In principle this is not necessary when a multicast address is used for addressing the group. The node only needs to maintain the multicast address thus saving RAM space.

Groups can be maintained in DNS-SD, or the resource directory (Zach allowing this).

How the group communication to the group, using the multicast address, is done - with a multicast or with individual unicasts- is the concern of the group communication protocol.

-> add informative reference to groupcomm WIP; write text around that.
(Note that, in a similar vein, -coap should have an informative reference to -observe.)

Change History (1)

comment:1 Changed 10 years ago by hartke@…

  • Resolution set to wontfix
  • Status changed from new to closed

Esko and I agree with Peter that it would be interesting/useful to discuss the use of a group communication protocol in conjunction with -observe. However, with current document scopes, this scenario is out of scope for both the -observe and the -groupcomm draft.

Note: See TracTickets for help on using tickets.