Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

IOT Operations (iotops)

WG	Name	IOT Operations
	Acronym	iotops
	Area	Operations and Management Area (ops)
	State	Active
	Charter	charter-ietf-iotops-01 Approved
	Document dependencies	Document dependencies Loading... Pan and zoom the dependency graph after the layout settles. Show legend Loading...
	Additional resources	Zulip stream
Personnel	Chairs	Alexey Melnikov, Henk Birkholz
	Area Director	Warren "Ace" Kumari
	Editor	Warren "Ace" Kumari
Mailing list	Address	iotops@ietf.org
	To subscribe	https://www.ietf.org/mailman/listinfo/iotops
	Archive	https://mailarchive.ietf.org/arch/browse/iotops/
Chat	Room address	https://zulip.ietf.org/#narrow/stream/iotops

Charter for Working Group

The IOTOPS Working Group is chartered for the discussion of operational issues related to Internet of Things (IoT) devices, in particular related to device onboarding and lifecycle management.

IoT has a rather nebulous definition with different meanings for different people.

For the purposes of this WG, its focus is on devices that

are networked, either to the Internet or within limited administrative domains
have a very limited end user interface or no end-user interface at all
are deployed in sufficiently large numbers that they cannot easily be managed or maintained manually

The IETF works on a number of technologies related to IoT. This includes, but is not limited to work done in ACE, ANIMA, CBOR, CORE, DRIP, LAKE, LPWAN, LWIG, ROLL, SUIT, TEEP, 6LO, 6TISCH, and other working groups. IOTOPS is intended to be a discussion venue where people can discuss how various IoT-related technologies fit together.

IOTOPS provides a venue for IoT experts and other interested parties to engage in discussions of operational IoT requirements, as well as proposals for new uses of IP technology related to IoT devices and network operations.

Revision, updates, and extensions to work from existing WGs will be done in those WGs. Where new work may be needed, IOTOPS will help identify candidate venues within IETF for their development.

IOTOPS WG charter is restricted to:

1) Taking input and discussing issues related to the operational management of IoT devices.
This includes (but is not limited to):
- factory provisioning of devices
- onboarding of devices
- access control of devices to network resources
- administrative control of devices
- software/firmware upgrades
- isolation/quarantine of devices+-----------+-------------------------------------------------------+ | '29' | 'staple-dual-top': Bind the Document(s) with two | | | staples (wire stitches) along the top edge, assuming | | | a portrait Document (see above). | +-----------+-------------------------------------------------------+ | '30' | 'staple-dual-right': Bind the Document(s) with two | | | staples (wire stitches) along the right edge, | | | assuming a portrait Document (see above). | +-----------+-------------------------------------------------------+ | '31' | 'staple-dual-bottom': Bind the Document(s) with two | | | staples (wire stitches) along the bottom edge, | | | assuming a portrait Document (see above). | +-----------+-------------------------------------------------------+ Table 10: "finishings" Enum Values 5.2.7. page-ranges (1setOf rangeOfInteger(1:MAX)) This RECOMMENDED attribute identifies the range(s) of Input Pages that the Printer uses for each Set to be printed prior to imposition of those pages onto Impressions. Nothing is printed for any pages identified that do not exist in the Set/Document(s). Ranges MUST be in ascending order (1-3, 5-7, 15-19, etc.) and MUST NOT overlap so that a non-spooling Printer can process the Job in a single pass. If the ranges are not ascending or are overlapping, the Printer MUST reject the request and return the 'client-error-bad-request' status-code. The attribute is associated with Input Pages and not application-numbered pages such as the page numbers found in the headers and/or footers for certain word processing applications. For Jobs with multiple Documents, the "multiple-document-handling" attribute determines what constitutes a Set for purposes of the specified page range(s). When "multiple-document-handling" is 'single-document', the Printer MUST apply each supplied page range once to the concatenation of the Input Pages. For example, if there are 8 Documents of 10 pages each, the page range '41-60' prints the pages in the 5th and 6th Documents as a single Document, and none of the pages of the other Documents are printed. When "multiple-document-handling" is 'separate-documents-uncollated-copies' or 'separate-documents-collated-copies', the Printer MUST apply each supplied page range repeatedly to each Document copy. For the same Job, the page range '1-3, 10-10' would print the first 3 pages and the 10th page of each of the 8 Documents in the Job, as 8 separate Sets. Sweet & McDonald Standards Track [Page 118] RFC 8011 IPP/1.1: Model and Semantics January 2017 "page-ranges-supported" is a boolean value indicating whether the Printer is capable of supporting the printing of page ranges. This capability can differ from one PDL to another. There is no "page-ranges-default" attribute. If the "page-ranges" attribute is not supplied by the Client, all pages of the Document are printed. Note: In many cases, the Client supplies only those Input Pages that need to be printed in the Document data, and the "page-ranges" Job Template attribute is not used. However, Clients that submit already-generated Document data (either static content from some web site or previously submitted content the End User wishes to reprint) can use this attribute to print just a subset of the pages contained in the Document. In this case, if a "page-ranges" value of 'n-m' is specified, the first page to be printed will be page n. All subsequent pages of the Document will be printed through and including page m. Note: The effect of this attribute on Jobs with multiple Documents is controlled by the "multiple-document-handling" Job attribute (Section 5.2.4). The relationship of this attribute and the other attributes that control Document processing is described in Appendix C.3. 5.2.8. sides (type2 keyword) This RECOMMENDED attribute specifies how Impressions are placed upon the sides of a Media Sheet. The standard 'keyword' values are: o 'one-sided': imposes each consecutive Impression upon the same side of consecutive Media Sheets. o 'two-sided-long-edge': imposes each consecutive pair of Impressions upon front and back sides of consecutive Media Sheets, such that the orientation of each pair of Impressions on the medium would be correct for the reader as if for binding on the long edge. This imposition is sometimes called 'duplex' or 'head-to-head'. o 'two-sided-short-edge': imposes each consecutive pair of Impressions upon front and back sides of consecutive Media Sheets, such that the orientation of each pair of Impressions on the medium would be correct for the reader as if for binding on the short edge. This imposition is sometimes called 'tumble' or 'head-to-toe'.
- remediation of broken devices
- end of life management of devices

2) Taking input and discussing issues related to IoT operational security.

3) Publishing operational practices.

4) Documenting requirements.

Approximately one year after chartering, the WG chairs will prepare a report for the IESG summarizing what the group has accomplished; this is both as a checkpoint for this working group and as a demonstration to the IESG that this style of working groups such as this have value and should be considered more often.