[coman] Minutes of the COMAN site meeting at IETF 85

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

Hi All,

the COMAN site meeting at IETF 85 was on Thursday, November 8, 2012,
betw. 1130am - 1pm.

Attendees:
Dominique Barthel, Carsten Bormann, Paul Chilton, Benoit Claise, Mehmet
Ersue, Ulrich Herberg, Sye Loong Keoh, Alan Luchuk, David Reid, Dan
Romascanu, Juergen Schoenwaelder, Peter van der Stok, Bert Wijnen

1) Terminology

Carsten reported from the LWIG session where it has been discussed and
supported to merge the terminology sections from
draft-ietf-lwig-guidance (section 2) and draft-ersue-constrained-mgmt
(section 1.3) into a new terminology draft. The aim is to avoid any
inconsistencies or redundancy for the defined terminologies for
constrained device and networks. Draft-ersue will still have a
terminology section but will exclude joint terminology in the new draft.
The new draft is planned to adopt in LWIG working group as WG 
item, which will be then cited by related documents. 

Peter proposed to add a classification on power availability to classify
the nodes according to their power-supply expressed as their
transmission capacity. Power availability is a basic concern for
constrained devices. 
Note: Peter already provided some text.

2) Class of networks in focus

There can be several networking dimensions, such as the dynamic topology
(mobile, mesh, etc.), media type (e.g. based on bandwidth, lossyness of
the network), network topology, traffic flows, sleep cycles,
non-continuous connections. The current draft describes the network
classes mainly from the network topology pov. The new version of the
draft should describe all dimensions and state which of them are
supported.
- Ulrich agreed to provide text for the definition of network
dimensions.

The current draft excludes MANET for the discussion of network
management. MANET working group will write their own management use case
draft. The MANET use case in draft-ersue-constrained-mgmt will be kept
with a note that MANET management is handled in another draft.

3) Necessity of a analysis of detailed management features and matching
features to device classes and use cases

The draft currently categorizes the requirements following management
tasks (like FM, CM, etc.) and adds categories like Energy Management, SW
Distribution, and Implementation Requirements. The editor's team
questioned whether a fine-granular list of management features is
necessary to match to device classes and use cases. It is assumed that
such a discussion might become unnecessarily complex. 

The issue of how many and which features a constrained device can
support has been discussed. Vendors might decide to support different
subsets of requirements for a particular device type to use the scarce
memory in an optimal way for the particular application on the device.
The document notes that the defined requirements need to be seen as
stand-alone and currently does not propose any feature profile
appropriate for specific device classes. 
Based on missing objections a detailed management feature analysis will
not be added to the requirements section.

4) Requirements section

The requirements section has been found as extensive and a good starting
point. However, there is a redundancy and some of the requirements might
be less important. 
- Everybody is encouraged to review Section 4 and give comments for
improvement.

5) Next steps and aim of the Coman activity

The section for the gap analysis highlighting potential new work needs
yet to be written. If there are sufficient amount of new work proposals,
which were relevant for a working group, the Coman activity might lead
to a chartering discussion.
It has been asked whether there is already sufficient material to start
a BoF. A gap analysis with some concrete results seems to be a
prerequisite before a useful charter discussion can be started.

It has been agreed to divide the current draft into two documents and
provide for review. One focusing on the problem statement, and the
second one assembled by the use cases and requirements. A new draft
should be written for the gap analysis. 
It has been seen as suitable to provide an initial gap analysis, which
highlights concrete missing features in existing protocols and data
models. As a result of this work, we might be able come up with a
concrete new work proposal with success potential.
A thorough gap validation together with protocol authors and a detailed
analysis of the required protocol features (and/or protocols) might take
more than six months and needs the attention of the OPS and APP area
communities. As such, the gap validation and the protocol feature
analysis might be appropriate to do as part of a new working group.

Cheers, 
Mehmet