From stokcons@xs4all.nl Wed May 1 02:10:54 2013 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A07121F8E96 for ; Wed, 1 May 2013 02:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.946 X-Spam-Level: * X-Spam-Status: No, score=1.946 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MANGLED_TOOL=2.3] 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 KOKf58TrYFi2 for ; Wed, 1 May 2013 02:10:48 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id E3FD921F8E7C for ; Wed, 1 May 2013 02:10:47 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube3.xs4all.net [194.109.20.199]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id r419Ajt2077891 for ; Wed, 1 May 2013 11:10:45 +0200 (CEST) (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); Wed, 01 May 2013 11:10:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 01 May 2013 11:10:45 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: Message-ID: <70f8daef651e2906c73cd49d75d4a789@xs4all.nl> X-Sender: stokcons@xs4all.nl (ERPM0CWc3xR+1rbXkH4KbJvQCXaASNSc) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [coman] requirement selection X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 09:10:54 -0000 Dear coman list, In my personal notes I found that I volunteered to propose a selection of requirements from the ones proposed in the constrained-mgmt-03 draft. Below I propose a selection based on some additional grouping. Questions are welcome. I hope that other selections will be proposed in addition to mine. Peter ____________________________________________________________________________________________________________________________________________- Reading through the requirements of draft-ersue-constrained-mgmt-03 means covering a wide area of technological requirements. Making a selection of just 3-4 requirements proves to be very hard because sometimes a group of requirements exhibits very tight relations between its members and selecting one almost implies selecting all the accompanying ones as well. Another aspect is that some of the requirements seem to be covered, or are likely to be covered by existing IETF working groups. Below I will group and comment the requirements according to my own whimsy (being a fan of Dorothy Sayers). A criterion I thought helpful is selecting those requirements which can be covered by a possible COMAN working group. All comments below are motivated by my knowledge of building control and reflect my own opinion and nothing else. Group 1: Req. 4.1.001, Req. 4.1.002, Req. 4.1.004, Req. 4.1.006 are basic to any work done on management of devices for future large scale networks. Basing the management on a RESTful approach may indeed lead to a minimization of protocol code and leads to abolishment/replacement of SNMP? Group 2: Req. 4.1.003. A hierarchical approach seems the best understood way forward to manage a large set of devices and can be used as design axiom. Group 3: Req. 4.1.005, Req. 4.1.007, Req. 4.1.008, Req. 4.3.004, Req. 4.4.009, Req. 4.5.001, Req. 4.9.002 discuss auto management, auto reconfiguration and fault tolerance. They point at a future in which enough knowledge and rules exist in which auto management is possible. However, appropriate solutions may need quite a lot of application specific assumptions, and satisfying these requirements is probably best left to other Standards Developing Organizations (SDO). Group 4: Req. 4.2.005, Req. 4.2.006, Req. 4.2.007. These may be interpreted as defining a management model that provides basic facilities for low resource devices on which the SDOs can build in a later stage. This looks like work for COMAN. The design satisfying the requirements should follow the group 1 and group 2 requirements. Group 5: Req. 4.3.001, Req. 4.3.002, Req. 4.3.003, These may be interpreted as a plug and play behavior of the devices. Part of the requirements is looked after by Homenet wg and the new to start DNSext wg. Additional work will need to be defined on top of Homenet and DNSext results. In particular it is interesting that clients can automatically bind to servers at start-up and possibly during operation. Group 6: Req. 4.4.001 - Req. 4.4.008, Req. 4.4.011, and Req. 4.4.012, and Req. 4.7.001-4.7.004. concern monitoring and notification mechanisms which can be specified in COMAN using the results of group 4. SDOs can define their own functions on top. Group 7: Req. 4.6.001- 4.6.004, Req. 4.10.004 all concern security aspects which are the concern of future security wgs beyond TLS. Already efforts have started in lwig and an initiative exists to start a common Sec and APPS area spin-out. Group 8: Req. 4.8.001 The requirement for a SW update for a group devices stands on its own and is indeed wanted. Up till now these facilities are specified by SDOs in a rather ad-hoc manner. Group 9: Req. 4.9.001, 4.9.003, 4.10.001 – 4.10.003 concern reliable transport, congestion avoidance, time aspects, etc. Specifying these requirements correctly taking into account the relevant operational boundary conditions would be a major step forward from the current clash of opinions and initiatives. Does not look like a COMAN subject. Group 10: Req. 4.2.001 - 4.2.004, Req. 4.11.001, Req. 4.11.002 concern modular and lean implementation and are probably best served by lwig In conclusion: groups 4 and 5 requirements, supported by group 1 and 2 requirements, are for me the most opportune ones in connection to the management of low resource devices in large scale networks. My hope is that it leads to ONE secure RESTful protocol that supports boot strapping, configuration of devices, followed by binding of clients to servers without operator intervention. Automating of the configuration and reconfiguration, group 3, is interesting but may rely on a large number of application dependent characteristics and objectives. Gap analysis: plug and play and management is done by SDOs for different application areas, often with much functional overlap but without common technical solutions apart from the reliance on multicasting techniques. A new common solution supported by IETF is needed given the large scale networks composed of low-cost IP based devices. Low resource devices may profit from one RESTful protocol with one security solution that is the same for the applications as for the management. Provisioning of multiple management solutions based on different protocols like snmp, http, and other protocols will need too much memory for storage of code. The management based on MIBs misses the modeling flexibility needed by future solutions which support the auto-management of the devices. -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From mehmet.ersue@nsn.com Mon May 20 23:29:44 2013 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC30A21F86D3 for ; Mon, 20 May 2013 23:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 WhLYakYpXmYm for ; Mon, 20 May 2013 23:29:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DCCC521F86CB for ; Mon, 20 May 2013 23:29:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r4L6TbcY028972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 May 2013 08:29:37 +0200 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r4L6Taxh009735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 08:29:36 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.156]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Tue, 21 May 2013 08:29:36 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Anuj Sehgal , "coman@ietf.org" Thread-Topic: Review of draft-ersue-constrained-mgmt-03 Thread-Index: AQHONjtx2uY+hU+Cw0ySjFE29DCKD5kOfRvw Date: Tue, 21 May 2013 06:29:35 +0000 Message-ID: References: <6CF8F4DE-F136-4995-82CF-35FD7B76B66C@jacobs-university.de> In-Reply-To: <6CF8F4DE-F136-4995-82CF-35FD7B76B66C@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 11114 X-purgate-ID: 151667::1369117778-000076D0-549540C3/0-0/0-0 Subject: Re: [coman] Review of draft-ersue-constrained-mgmt-03 X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 06:29:44 -0000 Dear Anuj, sorry for this late response and thank you for your thorough review.=20 See my comments below. Cheers,=20 Mehmet=20 > -----Original Message----- > From: coman-bounces@ietf.org [mailto:coman-bounces@ietf.org] On Behalf Of= ext > Sehgal, Anuj > Sent: Thursday, April 11, 2013 12:34 AM > To: > Subject: [coman] Review of draft-ersue-constrained-mgmt-03 >=20 > Hi, >=20 > After reading draft-ersue-constrained-mgmt-03 there are a few > questions that came up in my mind. There also some general editorial > things I would like to point out, and as such, I will break up the > email into two sections for readability. >=20 > 1. Questions Regarding draft-ersue-constrained-mgmt-03 >=20 > a. From reading the document, it is not completely clear whether > end-to-end IP connectivity is assumed in all cases? Or is it > possible that the gateways in between act as translators for > different protocols? In general there seems to be an implied > understanding that end-to-end IP connectivity exists, but it might > be useful to make this clear in the document. The document talks on "Constrained devices, which are connected directly to= the Internet or an IP network" and=20 "Constrained devices, which are connected to the Internet or an IP network = via a gateway/proxy". As such it is not important whether the "very constrained" devices, which n= eed the help of a proxy, are themselves able to use IP stack or not. > b. Section 1.3 focuses on the class of networks that are within the > scope of this document but the terminology defined here (CN0, CN1, > etc.) is not used elsewhere in the document. Since it is not used > in the document, is it still relevant? Maybe it is better to just > remove this from the document? It is true that they are defined and used in section 1.3. I think they shou= ld be used through the document. > c. It might be best to check all the terminology against the LWIG > document once since things could have changed there and to make > sure that all the terminologies are still relevant. Sure. At the time where this draft has been submitted, the LWIG terminology= draft was not available. > d. Section 2 makes a claim that "the current management protocols seem > to be too heavyweight compared to the capabilities the constrained > devices". It would seem that at least SNMPv1 performs decently > within the resource constraints of the environment. I still have the opinion that "the current management protocols seem to be = too heavyweight compared to the capabilities the constrained devices". If w= e say "current management protocols" we mean actually the current version o= f the protocol. And the current version of SNMP is version 3, which is btw = strongly recommended to use by RFC 3410. =20 > As such, either this needs a reference to solidify this position or > needs to be expanded in order to make it clear that this not > necessarily a resource usage issue but more of an issue related to > the fact that the IoT protocol stack (e.g. CoAP) is what should > be/people like to reuse in this environment for management and > application. There are different reasons why I wouldn't support SNMPv1 for constrained d= evices, however this is my personal opinion. Others might have other opinio= ns.=20 The fact that SNMPv1 is simple and easy to implement does not mean it is a = state-of-the-art network management protocol. =20 > e. The Industrial Application examples provided in Section 3.3 may not > be the best ones. Things like centralized control of energy, HVAC, > lighting and access control can also be categorized under Home > Automation, Building Automation or Energy Management. On the other > hand use cases like manufacturing, assembly lines and etc. do fit > well within this section. It would seem that this section needs > some examples to be changed and improved. > > f. Currently there is a big intersect between the Industrial > Application, Home Automation and Building Automation use cases. The > examples and text in these sections needs to be clarified in order > to make sure that the differences between these closely related use > cases is clear to the reader. Agree, the use case sections need to be improved. Do you have any concrete = suggestions for editing? =20 > g. In Section 3.5 it is stated that "Contrary to home automation in > building management all devices are known to a set of commissioning > tools and a data storage...". >=20 > I suggest changing the language a little bit to say that this is > expected, rather than always being the ground truth. While normally > assets might be tightly managed in such an environment, it may not > necessarily be so. Maybe writing, "Contrary to home automation in > building management all devices are expected to be managed assets, > and as such, known to a set of commissioning tools and a data > storage...". Agree, text revision makes sense. Any concrete suggestions for new text? =20 > h. The whole use case of Mobile Applications in Section 3.10 seems to > be not really a use case, but rather special cases related to > access technologies. All the issues discussed here seem to be use > case issues that should be part of other use case sections. It > might be better to merge this section into the previous sections. I don't think so. Different people with mobile background were agreeing tha= t such a section listing and summarizing the mobility scenarios as well as = their technologies makes sense. =20 > i. Section 3.12, MANET Concept of Operations (CONOPS) in Military, is > considerably more detailed than any of the other use case > sections. Furthermore, it would likely make more sense to shift the > focus of this use case from MANET and CONOPS to purely military > applications, since the use case here is not specifically MANETs, > but rather the special conditions that come with military > operations. Also, in light of increased international military unit > cooperation it makes even more sense to have a section focusing > specifically on military applications since in these scenarios it > is quite likely that multiple different standards, best practices > and implementation approaches may conflict/contradict, thereby > needing special management of such networks. Interesting proposal, which could be discussed on the maillist. BTW: The us= e case sections have been always contributor-driven. > j. It is stated in Section 4 that the document does not recommend the > realization of a profile of requirements. What does "profile of > requirements" refer to? This is quite unclear because a list of > requirements, that seem to be a profile, is present in the document > as well. Please read 2nd paragraph of section 4. May be we should change the sentenc= e as: NEW: A device might be able to provide only a particular profile of requirements= (i.e. selected set of requirements) and might not be capable to provide al= l requirements in this document at once. =20 > k. From reading the document it is quite unclear what Functional > Requirement, Non-Functional Requirement and Design Constraint > exactly mean. For example, Requirement 4.1.004 is marked as > non-functional, however, it could be argued that due to the > resource constraints on devices, minimizing state maintained on > them should be a functional requirement, or even a design > constraint since it is forced by the platform. An explicit > clarification between these requirement types in the document would > be useful. Agree, the requirement types should be defined and the usage should be cros= s-checked for correctness. =20 > l. After reading Requirement 4.3.001, I have the feeling that using > Mandatory and Optional as priorities is likely not > appropriate. Making something mandatory makes it an absolute > requirement, and in case of constrained devices making > self-configuration mandatory for C0 and C1 devices might be > overkill. As such, I propose that the terminology for priorities be > changed to using "High, Medium and Low" since that more accurately > represents the importance of implementing a requirement. I tend to agree. Different device vendors might see different requirements = as must-have. =20 > m. Requirement 4.10.002, regarding reliable unicast transport has a > title that is a bit ambiguous. Just by reading the title an > impression is had that the requirement might apply to the transport > protocol, which would make CoAP, for example, not usable. However, > reading the description provides a bit of inferred clarity that > reliability applies to the message transport, and not the transport > protocol. As such, I suggest replacing the title with the current > description, which is quite short; it would then make sense to have > a more precise and clearly worded description, which would not lead > to this ambiguity or misinterpretation. The title could be changed as: "Reliable unicast transport of messages". Th= is was actually meant with the current version.=20 What would be your proposal for a more precise and clearly worded descripti= on? =20 > 2. Editorial Issues >=20 > a. In Section 1.6, the statement, "Faults in network operation > including hardware and software errors, failures detected by the > transport protocol and other self-monitoring mechanisms can be used > to provide fault tolerance.", is unclear. This needs to be reworded > to clearly explain the goal. This sentence needs a reformulation as the first part does not fit the seco= nd part. =20 > b. In Section 2, the paragraph starting with, "The terminology for the > "Internet of Things" is still nascent, and...", is unclear and not > easy to read. Specifically, the second sentence, "In this context, > we need to differentiate between...", does not make sense and when > taken in context of the first one, it is plain confusing. What you mean as the 2nd sentence is actually the 3rd sentence. And the 3rd= sentence builds on the 2nd sentence.=20 Or is there anything else confusing?=20 > c. The statement, "Hence, the management of a network with constrained > devices might...", in Section 2 needs to be reworded as it is > grammatically incorrect. I see here an issue of clarity and it can be solved somewhat easily. =20 > If I find more issues upon reading the document again, I shall post > them to the mailing list as well. Thank you again for your detailed review. I hope you can further contribute= with text proposals. > Warm regards, > Anuj Sehgal > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From dromasca@avaya.com Wed May 22 11:00:24 2013 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33E221F8E06 for ; Wed, 22 May 2013 11:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.008 X-Spam-Level: X-Spam-Status: No, score=-103.008 tagged_above=-999 required=5 tests=[AWL=-0.409, 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 QHpqoqagDuDr for ; Wed, 22 May 2013 11:00:19 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id DE0D521F8E3C for ; Wed, 22 May 2013 11:00:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMGAOgGnVGHCzI1/2dsb2JhbABagmchMMFugQcWbQeCIwEBAQEDEig0FwYBCA0EBAEBCxQFBDkUBwEBBQUEEwgah2sBC5oXhDOcDReObD6CbWEDmGGFGIp/gViBN4Im X-IronPort-AV: E=Sophos;i="4.87,722,1363147200"; d="scan'208";a="12765659" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 May 2013 14:00:18 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 May 2013 13:56:10 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Wed, 22 May 2013 20:00:15 +0200 From: "Romascanu, Dan (Dan)" To: "coman@ietf.org" Thread-Topic: Last Call: (Terminology for Constrained Node Networks) to Informational RFC Thread-Index: AQHOVwhe/sb36dy/f0SHJxW5KWKjBZkRfiOQ Date: Wed, 22 May 2013 18:00:15 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA174637@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [coman] FW: Last Call: (Terminology for Constrained Node Networks) to Informational RFC X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 18:00:24 -0000 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of The IESG Sent: Wednesday, May 22, 2013 7:21 PM To: IETF-Announce Cc: lwip@ietf.org Subject: Last Call: (Terminology for C= onstrained Node Networks) to Informational RFC The IESG has received a request from the Light-Weight Implementation Guidan= ce WG (lwig) to consider the following document: - 'Terminology for Constrained Node Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2013-06-05. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract The Internet Protocol Suite is increasingly used on small devices with severe constraints, creating constrained node networks. This document provides a number of basic terms that have turned out to be useful in the standardization work for constrained environments. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lwig-terminology/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lwig-terminology/ballot/ No IPR declarations have been submitted directly on this I-D. From Bert.Greevenbosch@huawei.com Fri May 24 17:11:15 2013 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CD211E812F for ; Fri, 24 May 2013 17:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.417 X-Spam-Level: X-Spam-Status: No, score=-5.417 tagged_above=-999 required=5 tests=[AWL=1.181, 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 isjfovxjtm6h for ; Fri, 24 May 2013 17:11:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 904C611E812D for ; Fri, 24 May 2013 17:11:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATD54840; Sat, 25 May 2013 00:11:08 +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.1.323.7; Sat, 25 May 2013 01:10:50 +0100 Received: from SZXEML463-HUB.china.huawei.com (10.82.67.206) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 25 May 2013 01:11:06 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml463-hub.china.huawei.com ([10.82.67.206]) with mapi id 14.01.0323.007; Sat, 25 May 2013 08:11:00 +0800 From: Bert Greevenbosch To: "coman@ietf.org" Thread-Topic: New version of the Candidate Tech draft Thread-Index: Ac5Y3FTd/FCpsYB8QYuxIacdNNkxDQ== Date: Sat, 25 May 2013 00:10:59 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D76E13F@szxeml558-mbx.china.huawei.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_46A1DF3F04371240B504290A071B4DB63D76E13Fszxeml558mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [coman] New version of the Candidate Tech draft X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 00:11:15 -0000 --_000_46A1DF3F04371240B504290A071B4DB63D76E13Fszxeml558mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have uploaded a new version of the Candidate Technology draft: http://datatracker.ietf.org/doc/draft-greevenbosch-coman-candidate-tech/ The draft updates the BACnet text, and aligns the numbering in the draft wi= th the new numbering in the use case and requirements document. Peter van der Stok has become a co-author. Best regards, Bert --_000_46A1DF3F04371240B504290A071B4DB63D76E13Fszxeml558mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have uploaded a new version of the Candidate Techn= ology draft:

http://datatracker.ietf.org/doc/draft-gree= venbosch-coman-candidate-tech/

 

The draft updates the BACnet text, and aligns the nu= mbering in the draft with the new numbering in the use case and requirement= s document.

 

Peter van der Stok has become a co-author.

 

Best regards,

Bert

--_000_46A1DF3F04371240B504290A071B4DB63D76E13Fszxeml558mbxchi_--