Web of Things (WoT), Architecture, Thing Description, Scripting API | W3C

Documents

Web of Things (WoT) Architecture, 2017-09-14.

Summary
  1. WoT Thing Description
  2. WoT Scripting API
  3. WoT Binding Templates.

Web of Things (WoT) Thing Description, 2017-09-14.

Summary

Describes the metadata and interfaces of Things.

Web of Things (WoT) Scripting API, 2017-09-14.

Summary

Operates on Things characterized by Properties, Actions and Events.

Abstracts

Web of Things (WoT) Architecture

Abstract

The W3C Web of Things (WoT) is intended to enable interoperability across IoT Platforms and application domains. Primarily, it provides mechanisms to formally describe IoT interfaces to allow IoT devices and services to communicate with each other, independent of their underlying implementation, and across multiple networking protocols. Secondarily, it provides a standardized way to define and program IoT behavior.

This document describes the abstract architecture for the W3C Web of Things. It is derived from a set of use cases and can be mapped onto a variety of concrete deployment scenarios, several examples of which are given. This document is focused on the standardization scope of W3C WoT, which consists of three initial building blocks that are briefly introduced and their interplay explained.

The WoT Thing Description (TD) provides a formal mechanism to describe the network interface provided by IoT devices and services, independent of their implementation. Provision of a TD is the primary requirement for a device to participate in the Web of Things. In fact, defining a Thing Description for an existing device allows that device to participate in the Web of Things without having to make any modifications to the device itself. WoT Binding Templates define how a WoT device communicates using a concrete protocol. The WoT Scripting API—whose use is not mandatory—provides a convenient mechanism to discover, consume, and expose Things based on the WoT Thing Description.

Other non-normative architectural blocks and conditions underlying the Web of Things are also described in the context of deployment scenarios. In particular, recommendations for security and privacy are included, while the goal is to preserve and support existing device mechanisms and properties. In general, W3C WoT is designed to describe what exists rather than to prescribe what to implement.

Web of Things (WoT) Thing Description

Abstract

This document describes a formal model and common representation for a Web of Things (WoT) Thing Description. A Thing Description describes the metadata and interfaces of Things, where a Thing is an abstraction of a physical entity that provides interactions to and participates in the Web of Things. Thing Descriptions provide a narrow-waist set of interactions based on a small vocabulary that makes it possible both to integrate diverse devices and to allow diverse applications to interoperate. Thing Descriptions, by default, are encoded in JSON-LD. JSON-LD provides both a powerful foundation to represent knowledge about Things and simplicity, since it allows processing as a JSON document. In addition to physical entities, Things can also represent virtual entities. A Thing Description instance can be hosted by the Thing itself or hosted externally due to Thing’s resource restrictions (e.g. limited memory space) or when a Web of Things-compatible legacy device is retrofitted with a Thing Description.

Web of Things (WoT) Scripting API

Abstract

The Web of Things (WoT) provides layered interoperability between Things by using the WoT Interfaces.

This specification describes a programming interface representing the WoT Interface that allows scripts run on a Thing to discover and consume (retrieve) other Things and to expose Things characterized by properties, Actions and Events.

Scripting is an optional “convenience” building block in WoT and it is typically used in gateways that are able to run a WoT Runtime and script management, providing a convenient way to extend WoT support to new types of endpoints and implement WoT applications like Thing Directory.

Mentions

  • JSON-LD

Argot

The Suitcase Words
  • W3C Web of Things (WoT)
  • IoT Platforms
  • interfaces
  • devices
  • services
  • implementation
  • multiple networking protocols
  • standardized
  • behavior
  • abstract architecture
  • use cases
  • mapped
  • scenarios,
    deployment scenarios,
    concrete deployment scenarios
  • standardization scope
  • WoT Thing Description (TD),
    Thing Description (TD)
  • formal mechanism
  • network interface
  • independent of implementation
  • participate
  • WoT Binding Templates,
    Binding Templates. [no acronym]
  • WoT Scripting API,
    Scripting API.
  • blocks,
    blocks and conditions,
    architectural blocks and conditions,
    non-normative architectural blocks and conditions.
  • scenarios,
    deployment scenarios,
    the context of deployment scenarios,
    in the context of deployment scenarios.
  • Web of Things (WoT)
  • Thing Description
  • narrow-waist
    a narrow-waist set,
    a narrow-waist set of interactions,
    a narrow-waist set of interactions based on a small vocabulary,
    a narrow-waist set of interactions based on a small vocabulary that makes it possible both,
    a narrow-waist set of interactions based on a small vocabulary that makes it possible both to integrate diverse devices and to allow diverse applications to interoperate.
  • JSON-LD
  • foundation … knowledge
  • a Web of Things-compatible legacy device
  • layered interoperability
  • Things
  • WoT Interface
  • Actions
  • Events
  • gateways
  • WoT Runtime
  • script management
  • endpoints
  • Thing Directory

Previously filled.

A Product Management Framework for the Internet of Things | Daniel Elizalde

; A Product Management Framework for the Internet of Things; ; In His Blog; 2016 (circa, per copyright) .

Mentions

The 5×7 matrix of Technology (Stack layer) × Concern

Frameworks

Technology Stack

  1. Device Hardware
  2. Device Software
  3. Communications
  4. Cloud Platform
  5. Cloud Application

Decision Framework

  • UX
  • Data
  • Business
  • Technology
  • Security
  • Standards
  • Regulations

Theories

  • Gap Analysis
  • Lean
  • N-somethning P-something I-something (NPI)
    New Product Introduction (NPI)

Claims

  • All steps are order-dependent.
  • The process must be done “just right” or it won’t work.
  • Rinse, repeat.

Actualities

Previously

In His Blog

Overview of the Digital Object Architecture (DOA) | ISOC

Overview of the Digital Object Architecture (DOA); an Information Paper, The Internet Society; 2016-10-25; 8 pages; landing.
contributor credit: Chip Sharp, scrivener

Contents

  • Introduction
  • What is the Digital Object Architecture?
  • What is a Handle?
  • Handle Resolution
  • Who Runs the Global Handle System?
  • Examples of systems based on the Digital Object Architecture/Handle System
  • Standards and the Handle System
  • Policy Considerations
  • Trademarks and Service Marks
  • Resourcs

Introduction

<quote>The Digital Object Architecture (DOA) and associated Handle System® originated at the Corporation for National Research Initiatives (CNRI) in the early 1990’s based on its work on digital libraries under contract for the Defense Advanced Research Projects Agency (DARPA).1 One of the original motivations for its design was the need to identify and retrieve information over long periods of time (on the order of tens or hundreds of years) so persistence was a critical design requirement. At the time it was developed, the Digital Object Architecture was an attempt to shift from a view of the Internet as organized around a set of hosts and the transport to reach them to a view in which the Internet was organized around the discovery and delivery of information in the form of digital objects.<quote>

Mentions

  • Digital Object Architecture (DOA)
  • associated Handle System®
    Yes, that’s a registration mark, ®.
  • Corporation for National Research Initiatives (CNRI)
  • Defense Advanced Research Projects Agency (DARPA)
  • um, like “digital libraries”
  • DONA Foundation
  • International Telecommunication Union (ITU)
  • Memoranda of Understanding (MOUs)
  • Multi-Primary Administrators (MPAs), manage the partitions of the namespace of the root servers of the top level GHR.
  • Policy Development Process (PDP)

Architecture

Digital Objects
The records, blobs of bits.
Repositories
The containers of records objects.
Handles
The names are global contextually scoped, universal, persistent.
There is a Handle Protocol, in (at least) version v2.1.
Resolution System and Registries
Like DNS, but different; maps “names” to Handles.

  • Global Handle Registry (GHR), is the root server.
  • Local Handle Services (LHS), are the regional delegates.
Handles
The names are, e.g. GUIDs, UUIDs.
  • unique
  • persistent
  • location-agnostic
  • taxonomy-agnostic

Handle

Defined as a string:
prefix “/” identifier
where
prefix is a “like a” reversed FQDN.
identifier is “like a” filename on the FQDN so referenced.
Thus handles are

  • unique
  • persistent
  • location-agnostic
  • taxonomy-agnostic
Example

For the FQDN of the U.S. Library of Congress (LOC)
FQDN: ye-auguste-national-librarye.loc.gov
Handle: gov.loc.ye-auguste-national-librarye

Registrars>

  • Coalition for Handle Services (ETIRI, CDI and CHC)
  • Communications and Information Technology Commission (CITC)
  • Corporation for National Research Initiatives (CNRI)
  • Gesellschaft für Wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG)/ePIC
  • International DOI Foundation (IDF)

Participants

DOI® System
  • International DOI Foundation (IDF)
    UK, non-profit, 1998
  • Prefix 10
  • Handle semantics is idiosyncratic, known to themselves.
  • Examples
Persistent Identifier Consortium for eResearch (ePIC)
  • [for the benefit of the] European Research Community
  • Prefix 21

Standards

RFC 3650
S. Sun, L. Lannom, B. Boesch. Handle System Overview, RFC 3650, 2003-11.
RFC 3651
S. Sun, Reilly, L. Lannom. Handle System Namespace and Service Definition, RFC 3651, 2003-11.
RFC 3652
S. Sun, S. Reilly, L. Lannom, J. Petrone. Handle System Protocol (ver 2.1) Specification, RFC 3652, 2003-11.
RFC 4452
H. Van de Sompel, T. Hammond, E. Neylon, S. Weibel. The “info” URI Scheme for Information Assets with Identifiers in Public Namespaces, RFC 4452, 2006-04.
ISO 26324:2012
International Organization for Standardization (ISO), “ISO 26324:2012 Information and documentation — Digital object identifier system“, ISO Standard 26324, 2012-06.
ANSI/NISO Z39.84-2005 (R2010)
ANSI/NISO Z39.84-2005 (R2010) Syntax for the Digital Object Identifier. (revised 2010)
X.1255
ITU-T Recommendation X.1255, Framework for discovery of identity management information, ITU-T, 2014

Trademarks and Service Marks

International DOI Foundation, Inc.
DOI, DOI.ORG, “short DOI” are registered service marks of …
DONA Foundation
DONA, GLOBAL HANDLE REGISTRY, HANDLE SYSTEM are registered service marks of…
Corporation for National Research Initiatives (CNRI)
HANDLE.NET, HDL, HDL.NET, CNRI are registered service marks of …
HDL, HDL.NET are registered trademarks of …
Internet Society
Internet Society is a registered service mark of the …

References

References

  • Documents at the DONA Foundation
  • open-stand.org
  • ANSI/NISO Z39.84-2005 (R2010) Syntax for the Digital Object Identifier. (revised 2010)
  • Corporation for National Research Initiatives, Overview of the Digital Object Architecture, July 28, 2012
  • DONA Foundation. DONA Foundation Statutes. Geneva. 2014.
  • International Organization for Standardization (ISO), “ISO 26324:2012 Information and documentation — Digital object identifier system”, ISO Standard 26324, 2012-06.
  • ITU-T Recommendation X.1255, Framework for discovery of identity management information, ITU-T, 2014.
  • R. Kahn, R. Wilensky. “A Framework for Distributed Digital Object Services”, In International Journal of Digital Libraries (2006) 6: 115.
  • Norman, Paskin. The Digital Object Identifier: From Ad Hoc to National to International. In The Critical Component: Standards in the Information Exchange Environment, edited by Todd Carpenter, ALCTS, 2015.
  • Peter J. Denning & Robert E. Kahn, The Long Quest for Universal Information Access. In Communications of the ACM, Vol. 53 No. 12, Pages 34-36.
  • RFC 3650. S. Sun, L. Lannom, B. Boesch. Handle System Overview, IETF, RFC 3650, 2003-11.
  • RFC 3651. S. Sun, S. Reilly, L. Lannom. Handle System Namespace and Service Definition, IETF, RFC 3651, 2003-11.
  • RFC 3652. S. Sun, S. Reilly, L. Lannom. J. Petrone, Handle System Protocol (ver 2.1) Specification, IETF, RFC 3652, 2003-11.
  • RFC 4452. H. Van de Sompel, T. Hammond, E. Neylon, S. Weibel, The “info” URI Scheme for Information Assets with Identifiers in Public Namespaces, IETF, RFC 4452, 2006-04.

Previously filled.

BUS 145 — Product Management for the Internet of Things

BUS 145 — Product Management for the Internet of Things

Instructor: Daniel Elizalde

Syllabus

Daniel Elizalde, Founder, TechProductManagement

Daniel Elizalde trains product managers to become successful at managing IoT products through his IoT Decision Framework. He has over fifteen years of experience managing the lifecycle of IoT products. He regularly speaks at conferences and publishes the IoT product management blog TechProductManagement.

From the Survey

Greatest Challenge

Longevity and continuity concepts in product design and business model operation for consumer IoT operation. By way of perspective, my home is 60 years old.  My truck is fifteen years old.  All of them still “work.”  However, in the time span that I have owned the house, I have installed and a whole generation of television technology (the cutover to HDTV and encrypted digital cable from terrestrial broadcast analog signal transmission) and I have installed and remaindered two separate generations of analog and hybrid copper telecom infrastructure.  Today I use a 2nd generation of VoIP (whereas AT&T committed to and abandoned their VoiP business line [CallVantage]).  The challenge for IoT is how to provide significant lifespan to the technologies underpinning the services being offered.  Product lifetimes are short, frequently being circumscribed to a single build plan or kickstarter initiative at all.  More frequently now one sees abandonment of whole products and even lines of business in toto within a single fiscal year; c.f. Intel’s recent repudiation of their IoT product lines.  By the time the class starts, the IoT SBC line, Edison, Curie, etc., will be in final-order EOL status.

What to Learn
The learning would be around business model development under ephemeral technology constraints and the tie-in to product design. One is very cognizant of the “How to Survive on a Diet of Poisoned Fruit” thinking.  My trade is in and around online entertainment experiences. These are today are primarily driven from the WinTel platform, but moving onto Apple/Google. They are funded by advertising. The business model for the experiences is oriented around aggregation of “eyeballs”  Success is measured in “unique user counts” or “gross rating points” or “daily active users.”  Monetization (how the money happens) occurs through the introduction of gently intrusive messaging (advertising) wherein sponsors insert reminders of their call to action within the media being created. Whereas “data is the new oil”, the great martech and adtech machinery amplifies the efficacy of the media delivery by allowing audience-based buying and selling of the media.  The current form of the media is “pages” or short-form linear media (video snippets).  None of this makes any sense for an IoT world.  It is unclear how IoT will fund itself.  Consumers will simply not put up with advertising prior to turning on their thermostats or prior to commanding their oven to ignite.  And having a $35-$100/month bill for a “connected light bulb fleet” doesn’t make any sense at all.  We already do this for cell phones and telecom value-added services. Of course one can comprehend that budget-heavy enterprise solutions for predictive maintenance amortization will be useful, that too does not make sense in a consumer or household type setting.

Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture” | Fielding, Taylor, Erenkrantz, Gorlick, Whitehead, Khare, Oreizy

Roy T. Fielding, Richard N. Taylor, Justin Erenkrantz, Michael M. Gorlick, E. James Whitehead, Rohit Khare, Peyman Oreizy; Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture; In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017); 2017; pages 4-11 (8 pages); landing.

Performed

Reflections on REST; keynote address; performed at the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017); by one of Roy Fielding, Richard Taylor, Rohit Khare (expect: Rohit Khare); video; 0:47:41; slides (42 slides).

Abstract

Seventeen years after its initial publication at ICSE 2000, the Representational State Transfer (REST) architectural style continues to hold significance as both a guide for understanding how the World Wide Web is designed to work and an example of how principled design, through the application of architectural styles, can impact the development and understanding of large-scale software architecture. However, REST has also become an industry buzzword: frequently abused to suit a particular argument, confused with the general notion of using HTTP, and denigrated for not being more like a programming methodology or implementation framework. In this paper, we chart the history, evolution, and shortcomings of REST, as well as several related architectural styles that it inspired, from the perspective of a chain of doctoral dissertations produced by the University of California’s Institute for Software Research at UC Irvine. These successive theses share a common theme: extending the insights of REST to new domains and, in their own way, exploring the boundary of software engineering as it applies to decentralized software architectures and architectural design. We conclude with discussion of the circumstances, environment, and organizational characteristics that gave rise to this body of work.

Mentions

  • REpresentational State Transfer (REST)
  • Computational REpresentational State Transfer (CREST)
    Computational REST (CREST)
  • Capability Uniform Resource Locator (CURL)
    Capability URL (CURL)
  • COmputAtional State Transfer (COAST)
  • Computing Resource Exchange with Security (COAST)
  • ARRESTED
  • Application Programming Interface (API)
  • Distributed Hash Table (DHT)
  • SIENA (Scalable Internet Event Notification Architectures)
  • XML
  • DHT
  • HTTP
  • REST
  • bit.ly
  • Persistsent Uniform Resource Locator (PURL)
    Persistsent URL (PURL)
  • Notifications
    • e.g. on page transitions
    • HTML ping
    • DOM, onClick, onLoad, onAnything
    • M. Thomson, E. Damaggio, B Raymor. Generic Event Delivery Using HTTP Push. RFC 8030. Internet Engineering Task Force (IETF). 2016.
  • Google Analytics
  • Google Docs
  • Google Sheets
  • AJAX
  • JavaScript
  • HTTP
    • LINK
    • UNLINK
  • Peer-to-Peer (P2P)
  • Decentralized Applications (DAPPs, dApps)
  • Client/Server
  • Web Distributed Authoring and Versioning (WebDAV, WEBDAV)
    • lock-based concurrency control
    • An RPC-based client-server centralized ile system with remote access “over HTTP”
  • Limitations of REST
    • one-shot
    • one-to-one
    • one-way
  • execution engine
  • binding environment
  • COAST
    • Capabilities
      • Services
      • Messaging
      • Interpretation
    • Claims
      • Secure remote code execution (RCE)
      • Live update
      • Novel
      • Monitoring & Traceability
      • Something about refactoring:
        Server abdication, client redelegation, server re-offering (fewer services), client reprogramming of the server.
      • Dynamic Reconfiguration
  • Group Consensus and Simultaneous Agreement (GCSA)
  • WebRTC,
  • Websockets
  • Webhooks
  • HTTP/2
  • Internet of Things (IoT)
  • Content Distrubtion Network (CDN)
  • TrueTime
  • GlobalClock
  • Apache Kafka
  • Amazon Kinesis,
  • Google Cloud Pub/Sub
  • Amazon Lambda,
  • IFTTT
  • ‘assistants’, a natural language conversational product concept, within the buzzy AI business culture. Think: Eliza, that you built in high school.
  • Cassandra
  • NoSQL
  • Federated Learning
  • Merkle Hash Trees (not MHT)
  • Bitcoin
  • <buzz>blockchain</buzz>
  • Git
    • is a decentralized in concept.
    • is not decentrlaized in practice, c.f. GitHub
  • Software-as-a-Service (SaaS)
  • Computational REpresentational State Transfer (CREST)
  • Aura
  • Nikander
  • Trickles
  • network continuations
  • Hypertext Transport Protocol (HTTP)
    • HTTP/1.1
    • HTTP/2
  • DARPA
  • NSF
  • ISR (Irvine Software Rationalization?)
  • Arcadia

Behavior, Asynchrony, State, Execution (BASE)

Concept

Adapability requires the design-time  actions…

LP1
making the parts that are subject to change identifiable, discrete and manipulable.
LP2
providing mechanisms for controlling interactions between the parts subject to change.
LP3
providing techniques for managing state.

Elaborated

  • Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor. Runtime Software Adaptation: Framework, Approaches, and Styles. In Companion of 30th International Conference on Software Engineering (ICSE Companion). 2008. ACM. pages 899–910.
  • Richard N. Taylor, Nenad Medvidovic, Peyman Oreizy. Architectural Styles for Runtime Software Adaptation. In Proceedings of the Eighth Joint Working IEEE/IFIP Conference on Software Architecture and Third European Conference on Software Architecture. IEEE Computer Society, 171–180. 2009.

Exemplars

  • C2
  • CREST
  • MapReduce
  • Pipe-and-Filter
  • Event Notifications
  • “and others.”

Disambiguation

  1. within the transaction formalization of Database Theory
    • Basically Available, Soft state, Eventual consistency (BASE)
      not as used herein.
    • a consistency model wherein everything almost works
      riposte: “eventually we are all dead.”
    • Contra
      • Always Computing In Denial (ACID)
      • Atomicity Consistency Isolation Durability (ACID)
  2. within the Dynamic Software Architectures Theory, page 9.
    • Behavior
    • Asynchrony
    • State
    • Execution
  3. within the ARRESTED Theory, page 10.
    the “mindset” of a node in a distributed network.
    Best-Effort
    Others are making their best effort, as are you.
    Approximate
    There is only approximate knowledge of the state of The Other; your theory of mind is limited & foggy, slacky-latent.
    Self-centered
    Others are self-centered, as are you.
    Efficient
    Make efficient use of the only global resource: communication bandwidth to others; i.e. time is the only finite resource.

Asynchronous, Routed, REpresentational State Transfer with Estimation & Delgation (A+R+REST+E+D, ARRESTED)

  • Polling (and its inverse Asynchrony)
  • Asynchrony (and its inverse Polling)
  • Routing
  • Delegation
  • Estimation

Concept

Theory
REST+P
REST with Polling.
REST+E
REST with Estimation.
A+REST
REST with Asynchrony (callbacks).
R+REST
REST with Routing (packets).
REST+D
REST with Delegation (proxies, gateways).
ARREST
Asynchronous, Routed, REST.
ARREST+E
Asynchronous, Routed, REST, with Estimation.
ARREST+D
Asynchronous, Routed, REST, with Delgation.
ARREST+D
Asynchronous, Routed, REST, with Estimation & Delgation.
ARRESTED
A synonym for slow, yes?
Topology

The metaphor.

Poles
North
Centralized Systems
East
Estimated Systems
South
Decentralized Systems
West
Distributed Systems
Boundaries
now horizon
  • Master-Slave Styles
  • Peer-to-Peer Styles
agency boundary
  • Consensus-Based Styles
  • Consensus-Free Styles

Elaborated

Techniques

  • Bitcoin
  • and other distributed ledger schemes.

Computational REpresentational State Transfer (CREST)

Is just like functional programming.

  • The Poetry
    • mashups of Web culture are “the same as” continuations in programming language theory & culture. c.f. Scheme & SML
    • 300-series redirects are continuations

Principles

CP1
The key abstraction of computation is a resource, named by an URL.
CP2
The representation of a resource is a program, a closure, a continuation, or a binding environment plus metadata to describe the program, closure, continuation, or binding environment.
CP3
All computations are context-free.
CP4
Only a few primitive operations are always available, but additional per-resource operations are also encouraged.
CP5
The presence of intermediaries is promoted.

Concept

  • Ship code+data as a package to evaluate off-box (over there, on their box).
  • Receive code+data as a package to evaluate on-box (here on our box).
  • What could go possibly wrong here? [over there?]

Elaborations

  • Justin R. Erenkrantz. Computational REST: A New Model for Decentralized, Internet-Scale Applications. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA. 2009.
  • Justin R. Erenkrantz, Michael Gorlick, Girish Suryanarayana, Richard N. Taylor. Harmonizing Architectural Dissonance in REST-based Architectures. Technical Report UCI-ISR-06-18. Institute for Software Research, University of California, Irvine. 2006.
  • Justin R. Erenkrantz, Michael M. Gorlick, Girish Suryanarayana, Richard N. Taylor. From Representations to Computations: The Evolution of Web Architectures. In ACM SIGSOFT Symposium on The Foundations of Software Engineering (FSE). 2007. pages 255–264.
  • Roy T. Fielding. Maintaining distributed hypertext infostructures: Welcome to MOMspider’s Web. In Computer Networks and ISDN Systems, 27, 2. 1994. pages 193–204. doi:10.1016/0169-7552(94)90133-3. Series title? Selected Papers of the First World-Wide Web Conference.

Techniques

  • web mashups
  • session management
  • cookies in client/server interactions
    <quote>, and the (misplaced) role of cookies in client/server interactions</quote>
  • time-dependent resources; e.g. weather forecasts.
  • time-series responses; e.g. stock tickers.

<editorial>Why aren’t cookies necessary again? They uniquely number the consumer base. They are used to develop Measurement, Targeting, Retargeting & Profiling which are the explicit and probably only renumerative use case of the (online) media business model. Oh, right, and paywalls. And, um, public televison-type “membership drive” tip jars.</editorial>

References

There are 59 references.

Abstracted

  • Roy T. Fielding, Richard N. Taylor. Principled Design of the Modern Web Architecture. In Proceedings of the 22nd International Conference on Software Engineering (ICSE). 2000. pages 407–416. IEEE, Limerick, Ireland.

Dissertated

  • Justin R. Erenkrantz. Computational REST: A New Model for Decentralized, Internet-Scale Applications. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA. 2009.
  • Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. Ph.D. Dissertation. University of California, Irvine, California, USA. 2000.
  • Michael Martin Gorlick. Computational State Transfer: An Architectural Style for Decentralized Systems. Ph.D. Dissertation. Technical Report UCI-ISR-16-3. University of California, Irvine, Irvine, California, USA. 2016.
  • David Alan Halls. Applying Mobile Code to Distributed Systems. Ph.D. Dissertation. University of Cambridge, Cambridge, UK. 1997.
  • Michael Hicks. Dynamic Software Updating. Ph.D. Dissertation. Computer and Information Science, University of Pennsylvania, Philadelphia, Pennsylvania, USA. 2001.
  • Rohit Khare. Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems. Ph.D. Dissertation. University of California, Irvine, California, USA. 2003.
  • Mark Samuel Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. Ph.D. Dissertation. Johns Hopkins University, Baltimore, Maryland, USA. 2006.
  • Peyman Oreizy. Open architecture software: a flexible approach to decentralized software evolution. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA.
  • Emmet James Whitehead, Jr. An Analysis of the Hypertext Versioning Domain. Ph.D. Dissertation. Univ. of California, Irvine, Irvine, California, USA. 2000.

Complete

  1. T. Aura, P. Niklander. Stateless Connections. In Proceedings of the First International Conference on Information and Communication Security (Lecture Notes In Computer Science), Y. Han, T. Okamoto, S. Qing (editors), Vol. 1334. Springer-Verlag, 1997. pages 87–97.
  2. Tim Berners-Lee, Robert Cailliau, Ari Luotonen, Henrik Frystyk Nielsen, Arthur Secret. The World-Wide Web. In Communications of the ACM, 37, 8. 1994-08. pages 76–82. doi:10.1145/179606.179671.
  3. Tim Berners-Lee, Roy T. Fielding, Larry Masinter. Uniform Resource Identifier (URI): Generic Syntax. RFC 3986. Internet Engineering Task Force (IETF). 2005-01. doi:10.17487/RFC3986.
  4. Tim Berners-Lee, Roy T. Fielding, Henrik Frystyk Nielsen. Hypertext Transfer Protocol – HTTP/1.0. RFC 1945. Internet Engineering Task Force (IETF). 1996-05. doi:10.17487/RFC1945.
  5. Tim Berners-Lee, Jean-Francois Groff. The World Wide Web (a.k.a. WWW). In SIGBIO Newsletter, 12, 3. 1992-09. pages 37–40. doi:10.1145/147126.147133.
  6. Keith Bonawitz, Vladimir Ivanov, Ben Kreuter, Antonio Marcedone, H. Brendan McMahan, Sarvar Patel, Daniel Ramage, Aaron Segal, Karn Seth. Practical Secure Aggregation for Federated Learning on User-Held Data. In Proceedings of the NIPS Workshop on Private Multi-Party Machine Learning. 2016. landing.
  7. Antonio Carzaniga, David S. Rosenblum, Alexander L. Wolf. Design and Evaluation of a Wide-Area Event Notification Service. In ACM Transactions on Computer Systems, 19, 3. 2001-08. pages 332–383. paywall.
  8. James C. Corbett, Jeffrey Dean et. al. Spanner: Google’s Globally-distributed Database. In Proceedings of the 10th USENIX Conference on Operating Systems Design and Implementation (OSDI). 2012. pages 251–264. paywall, landing. slides: pptx, event: session.
  9. Chris Dixon. Crypto Tokens: A Breakthrough in Open Network Design. In His Blog, centrally hosted on Medium. 2017-06.
  10. L. Dusseault. HTTP Extensions for Web Distributed Authoring and Versioning (WEBDAV). RFC 4918. Internet Engineering Task Force (IETF). 2007.
  11. Justin R. Erenkrantz. Computational REST: A New Model for Decentralized, Internet-Scale Applications. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA. 2009.
  12. Justin R. Erenkrantz, Michael Gorlick, Girish Suryanarayana, Richard N. Taylor. Harmonizing Architectural Dissonance in REST-based Architectures. Technical Report UCI-ISR-06-18. Institute for Software Research, University of California, Irvine. 2006.
  13. Justin R. Erenkrantz, Michael M. Gorlick, Girish Suryanarayana, Richard N. Taylor. From Representations to Computations: The Evolution of Web Architectures. In ACM SIGSOFT Symposium on The Foundations of Software Engineering (FSE). 2007. pages 255–264.
  14. Roy T. Fielding. Maintaining distributed hypertext infostructures: Welcome to MOMspider’s Web. In Computer Networks and ISDN Systems, 27, 2. 1994. pages 193–204. doi:10.1016/0169-7552(94)90133-3. Series title? Selected Papers of the First World-Wide Web Conference.
  15. Roy T. Fielding. Relative Uniform Resource Locators. RFC 1808. Internet Engineering Task Force (IETF). 1995-06. doi:10.17487/RFC1808.
  16. Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. Ph.D. Dissertation. University of California, Irvine, California, USA. 2000.
  17. Roy T. Fielding, Gail Kaiser. The Apache HTTP Server Project. In IEEE Internet Computing. 1, 4. 1997-07. pages 88–90. doi:10.1109/4236.612229
  18. Roy T. Fielding, Henrik Frystyk Nielsen, Jeffrey Mogul, Jim Gettys, Tim Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. RFC 2068. 1997-01. doi:10.17487/RFC2068
  19. Roy T. Fielding, Julian Reschke. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC 7231. Internet Engineering Task Force (IETF). 2014-06. doi:10.17487/RFC7231.
  20. Roy T. Fielding, Richard N. Taylor. Principled Design of the Modern Web Architecture. In Proceedings of the 22nd International Conference on Software Engineering. 2000. pages 407–416. IEEE, Limerick, Ireland.
  21. Roy T. Fielding, Richard N. Taylor. Principled Design of the Modern Web Architecture. In ACM Transactions on Internet Technology, 2, 2. 2002-05. pages 115–150.
  22. Roy T. Fielding, E. James Whitehead, Jr., Kenneth M. Anderson, Gregory A. Bolcer, Peyman Oreizy, Richard N. Taylor. Web-Based Development of Complex Information Products. In Communications of the ACM, 41, 8. 1998-08. pages 84–92.
  23. Matias Giorgio, Richard N. Taylor. Accountability Through Architecture for Decentralized Systems: A Preliminary Assessment. Technical Report UCI-ISR-15-2. Institute for Software Research, University of California, Irvine. 2015.
  24. Cristiano Giuffrida, Anton Kuijsten, Andrew S. Tanenbaum. 2013. Safe and Automatic Live Update for Operating Systems. In Proceedings of the Eighteenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS’13). ACM, New York City, New York, USA, 279–292.
  25. Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. HTTP Extensions for Distributed Authoring – WEBDAV. RFC 2518. Internet Engineering Task Force. 1999.
  26. Michael Martin Gorlick. Computational State Transfer: An Architectural Style for Decentralized Systems. Ph.D. Dissertation. Technical Report UCI-ISR-16-3. University of California, Irvine, Irvine, California, USA. 2016.
  27. Michael M. Gorlick, Kyle Strasser, Richard N. Taylor. COAST: An Architectural Style for Decentralized On-Demand Tailored Services. In Proceedings of 2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture (WICSA/ECSA). 2012. pages 71–80.
  28. David Alan Halls. Applying Mobile Code to Distributed Systems. Ph.D. Dissertation. University of Cambridge, Cambridge, UK. 1997.
  29. Michael Hicks. Dynamic Software Updating. Ph.D. Dissertation. Computer and Information Science, University of Pennsylvania, Philadelphia, Pennsylvania, USA. 2001.
  30. Irvine Research Unit in Software (IRUS). The Workshop on Internet-Scale Technology (TWIST). A series, 1998-2000.
  31. R. Kadia. Issues Encountered in Building a Flexible Software Development Environment: Lessons from the Arcadia Project. In Proceedings of the Fifth ACM SIGSOFT Symposium on Software Development Environments (SDE). 1992. ACM, New York, NY, USA. pages 169–180. doi:10.1145/142868.143768.
  32. Rohit Khare. Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems. Ph.D. Dissertation. University of California, Irvine, California, USA. 2003.
  33. Rohit Khare, Richard N. Taylor. Extending the REpresentational State Transfer Architectural Style for Decentralized Systems. In Proceedings of the 26th International Conference on Software Engineering (ICSE). 2004. IEEE Computer Society, Edinburgh, Scotland, UK. pages 428–437.
  34. Avinash Lakshman, Prashant Malik. Cassandra: A Decentralized Structured Storage System. In SIGOPS Operating Systems Review, 44, 2. 2010-04. pages 35–40.
  35. David Mazieres. The stellar consensus protocol: A federated model for internet-level consensus. Stellar Development Foundation. 2015.
  36. Mark Samuel Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. Ph.D. Dissertation. Johns Hopkins University, Baltimore, Maryland, USA. 2006.
  37. Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.
  38. Peyman Oreizy. Open architecture software: a flexible approach to decentralized software evolution. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA.
  39. Peyman Oreizy, Michael M. Gorlick, Richard N. Taylor, Dennis Heimbigner, Gregory Johnson, Nenad Medvidovic, Alex Quilici, David Rosenblum. An Architecture-based Approach to Self-Adaptive Software. In IEEE Intelligent Systems, 14, 3. 1999-05 (May-June). pages 54–62.
  40. Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the 20th International Conference on Software Engineering (ICSE). 1998. pages 177–186.
  41. Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor. Runtime Software Adaptation: Framework, Approaches, and Styles. In Companion of 30th International Conference on Software Engineering (ICSE Companion). 2008. ACM. pages 899–910.
  42. Peyman Oreizy, Richard N. Taylor. 1998. On the role of software architectures in runtime system reconfiguration. In IEE Proceedings-Software, 145, 5. 1998. pages 137–145.
  43. Dewayne E. Perry, Alexander L. Wolf. 1992. Foundations for the Study of Software Architecture. In SIGSOFT Software Engineering Notes, 17, 4. 1992-10. pages 40–52. doi:10.1145/141874.141884.
  44. Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, Harlan Yu. OpenDHT: A Public DHT Service and Its Uses. In SIGCOMM Computing Communication Review, 35, 4. 2005-08. pages 73–84.
  45. Alan Shieh, Andrew C. Myers, Emin G. Sirer. Trickles: A Stateless Network Stack for Improved Scalability, Resilience, and Flexibility. In Proceedings of Symposium on Networked Systems Design and Implementation,/em> (NSDI), Vol. 2. USENIX Association. 2005. pages 175–188.
  46. Alan Shieh, Andrew C. Myers, Emin Gün Sirer. A Stateless Approach to Connection-Oriented Protocols. In ACM Transactions on Computer Systems, 26, 3. 2008-09. pages 8:1–8:50.
  47. James W. Stamos, David K. Gifford. Implementing Remote Evaluation. In IEEE Transactions on Software Engineering, 16, 7. 1990-07. pages 710–722.
  48. James W. Stamos, David K. Gifford. Remote Evaluation. In ACM Transactions on Programming Languages and Systems (TOPLAS), 12, 4. 1990-10. pages 537–564.
  49. Chengzheng Sun, Xiaohua Jia, Yanchun Zhang, Yun Yang, David Chen. Achieving Convergence, Causality Preservation, and Intention Preservation in Real-time Cooperative Editing Systems. In ACM Transactions on Complicating Human Interactions (HCI), 5, 1. 1998-03. pages 63–108.
  50. Richard N. Taylor, Nenad Medvidovic, et al. A Component- and Message- Based Architectural Style for GUI Software. In Transactions on Software Engineering. 1996-06. pages 390–406.
  51. Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy. Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons. 2010. ASIN:B012AQ8M42: Kindle: no, paper: $151-$600.
  52. Richard N. Taylor, Nenad Medvidovic, Peyman Oreizy. Architectural Styles for Runtime Software Adaptation. In Proceedings of the Eighth Joint Working IEEE/IFIP Conference on Software Architecture and Third European Conference on Software Architecture. IEEE Computer Society, 171–180. 2009.
  53. R.D. Tennant. 1976. The Denotational Semantics of Programming Languages. In Communications of the ACM 19, 8. 1976-08. pages 437–453.
  54. M. Thomson, E. Damaggio, B Raymor. Generic Event Delivery Using HTTP Push. RFC 8030. Internet Engineering Task Force (IETF). 2016.
  55. Emmet James Whitehead, Jr. An Analysis of the Hypertext Versioning Domain. Ph.D. Dissertation. Univ. of California, Irvine, Irvine, California, USA. 2000.
  56. Emmet James Whitehead, Jr., Yaron Goland. The WebDAV Property Design. In Software, Practice and Experience 34 2004, 135–161.
  57. Wikipedia. 2017. Representational state transfer,/a>. In Wikipedia. 2017.
  58. Scott Wolchok, J Alex Halderman. Crawling BitTorrent DHTs for Fun and Profit. In Proceedings of the Fourth USENIX Workshop on Offensive Technologies (WOOT10). 2010.
  59. Gavin Wood. 2014. Ethereum: A secure decentralised generalised transaction ledger. Paper 151. Ethereum Project Yellow Papers 2014.

Previously filled.

A Comprehensive Look at Low Power, Wide Area Networks (LPWAN) | LinkLabs

A Comprehensive Look at Low Power, Wide Area Networks (LPWAN); a whitepaper; LinkLabs; 2017?; 16 pages (2 of content)
Teaser: For ‘Internet of Things’ Engineers and Decision Makers Important People Like You

Promotion

Mentions

  • Low Power, Wide Area Network (LPWAN)
  • Internet of things (IoT)
  • Machine to Machine (M2M)
  • Topologies
    • Mesh
    • Star
  • Energy per symbol
    • Shannon-Hartley Theorem
    • Information Theory
  • Regulations
    • FCC Part 15 (requrement)
    • ETSI (rules)
  • Signal-to-Noise Ratio (SNR)
  • Radio Frequency (RF)
  • Code Division Multiplexing (CDMA)
  • Chirp Spread Sprectum (CSS)
  • Frequency Shift Keying (FSK)
  • LoRaWAN
  • Groupe Speciale Mobile Association (GSMA)
  • Adaptive Data Rate
  • IoT Platform sector
  • Cellular IoT (CIoT) LPWAN.
  • Forking 4G with LTE-M.
  • LoRa, LoRaWAN
  • “clobbered,” a technical term.
  • Band
    • Europe (868 MHz)
      U.S. (915 MHz)
  • MAC
  • SATCOM
  • MTU
  • Ultra Narrowband (UNB) Radio
  • Random Phase Multiple Access (RPMA)
  • BPSK
Definition
  • long range
    10km
  • low power
    Aspirationally: half-a-generation, a decade, ten years.
  • low data rate
    metaphorical inverse of “blazing-fast”

Folklore

  • ZigBee has “trouble” in the 20-30m range; unusable beyond 30m.
  • Star topology is best.
  • LPWAN operate at 140-160 decibels (dB) of total path.
  • Receiver sensitivity
    • LPWAN  is more than -130 dBm
    • [some] other wireless is within -90 to -110 dBm.
  • The 915 MHz band is available only in ⅓ of the world.
    Therefore LPWAN is “not ready”
    There is no globally available band for LPWAN technologies like there is at the 2.4 GHz level (for Bluetooth and WiFi).

Standards

  • 802.11 of IEEE
    • 802.11ac
    • 802.11ad
    • 802.11n
    • 802.11a
    • 802.11g
    • 802.11b
  • 802.15 of IEEE
    • 802.15.4 ZigBee
    • 802.15.4 WPAN
    • 802.15.4k Nwave, Random Phase Multiple Access (RPMA)
    • 802.15.5 WBAN
  • The ‘G of The Telecom Sphere
    • 2G
    • 3G
    • 4G
    • 5G
    • you guessed it … “6G”
  • Bluetooth
    • Bluetooth (Classic)
    • Bluetooth Low Energy (BLE)
  • and
    • RFID
    • NFC

Products

  • Sigfox

    • What Is Sigfox
    • Proprietary
    • Concept
      12-byte packets, 300 baud, BPSK
      message repetition.
      15 byte messages, 10 messages/day up, 4 acknowledgements/day (down).
    • Something about: 2015, protocol upgrade, guaranteed message acknowledgment for up to four messages per day.
    • Scheme
      BPSK, 868 MHz,,915 MHz
  • Nwave
    • Proprietary
      • Capabilites unknown
      • Unpublished, undocumented
    • Scheme
      Ultra Narrowband (UNB) radio, sub-1 GHz ISM bands.
  • Ingenu
    • Proprietary
    • Founder, IEEE 802.15.4k task group
    • Something about: has a MAC concept.
    • Scheme
      Random Phase Multiple Access (RPMA); 2.4GHz
  • Weightless
    • Weightless Special Interests Group (SIG)
      unknown, unproven specifications & capabilities.
    • Concept
      10 year battery life
      2-way communication
    • Three sub-standards.
      • Weightless-W
    • Scheme
      sub-1GHz, unlicensed; in “unused TV spectrum”
  • LoRaWAN
    • LoRa Alliance
      • Specification, request
      • Intellectual Property
        • Semtech
        • with
          • IBM Research
          • Actility.
    • Concept
      Like Sigfox, but different
    • Dependencies
      • Any “code” must b be run off-box “in the cloud.”
      • Requires a “cloud vendor.”
      • Thus, heavy monthly fees for the compute.
        How much would you pay to have “smart light bulb?”
        With a monthly “subscription” and bill presentment?
    • Vendors
      • none
      • Aspiration
        • STMicroelectronics

Referenced

Actualities

Link Labs, 130 Holiday Court, Suite 100, Annapolis, MD 21401,

LinkLabs
130 Holiday Court, Suite 100
Annapolis, MD 21401,
http://www.nwave.io/

Previously filled.

Surviving on a Diet of Poisoned Fruit: Reducing the National Security Risks of America’s Cyber Dependencies | Danzig (CNAS)

Richard J. Danzig; Surviving on a Diet of Poisoned Fruit Reducing the National Security Risks of America’s Cyber Dependencies; Center for a New American Security; 2014-07; 64 pages; landing.

tl;dr → a metaphor for an ambivalent relationship with the technical platforms upon which all things depend.  Writ large into the relationship with the supply chain that we do not control and is inimical to our interests..

Executive Summary

Digital technologies, commonly referred to as cyber systems, are a security paradox: Even as they grant unprecedented powers, they also make users less secure. Their communicative capabilities enable collaboration and networking, but in so doing they open doors to intrusion. Their concentration of data and manipulative power vastly improves the efficiency and scale of operations, but this concentration in turn exponentially increases the amount that can be stolen or subverted by a successful attack. The complexity of their hardware and software creates great capability, but this complexity spawns vulnerabilities and lowers the visibility of intrusions. Cyber systems’ responsiveness to instruction makes them invaluably flexible; but it also permits small changes in a component’s design or direction to degrade or subvert system behavior. These systems’ empowerment of users to retrieve and manipulate data democratizes capabilities, but this great benefit removes safeguards present in systems that require hierarchies of human approvals. In sum, cyber systems nourish us, but at the same time they weaken and poison us.

The first part of this paper illuminates this intertwining. The second part surveys the evolution of strategies to achieve greater cybersecurity. Disadvantaged by early design choices that paid little attention to security, these strategies provide some needed protection, especially when applied collectively as a coordinated “defense in depth.” But they do not and never can assure comprehensive protection; these strategies are typically costly, and users will commonly choose to buy less security than they could obtain because of the operational, financial or convenience costs of obtaining that security.

Three other factors, discussed in Section V, amplify cyber insecurity. First, the cyber domain is an area of conflict. Cyberspace is adversarial, contested territory. Our adversaries (including criminals, malevolent groups and opposing states) co-evolve with us. The resulting ecosystem is not static or stable. Second, the speed of cyber dissemination and change outpaces our recognition of problems and adoption of individual and societal safeguards to respond to them. Protective actions are likely to continue to lag behind security needs. Third, in cyberspace America confronts greater-than customary limits to U.S. government power because of the global proliferation of cyber capabilities, cyber attackers’ ability to remain outside the United States even while operating within the country’s systems and our likely inability, over the long term, to avoid technological surprise. Two-thirds of a century of technological dominance in national security matters has left the United States intuitively ill-prepared for technology competitions that it probably will not continue to dominate and in which there is a high likelihood of surprise.

What then is to be done? The concluding part of this paper does not attempt to recapitulate or evaluate efforts now extensively debated or in progress. It focuses instead on recommending initiatives that deserve fresh attention from U.S. government decision-makers. These include:

  1. Articulate a national security standard defining what it is imperative to protect in cyberspace. The suggested standard is: “The United States cannot allow the insecurity of our cyber systems to reach a point where weaknesses in those systems would likely render the United States unwilling to make a decision or unable to act on a decision fundamental to our national security.” A more stringent standard may later be in order, but this standard can now secure a consensus, illuminate the minimum that the United States needs to do and therefore provide an anvil against which the nation can hammer out programs and priorities.
  2. Pursue a strategy that self-consciously sacrifices some cyber benefits in order to ensure greater security for key systems on which security depends. Methods for pursuing this strategy include stripping down systems so they do less but have fewer vulnerabilities; integrating humans and other out-of-band (i.e., non-cyber) factors so the nation is not solely dependent on digital systems; integrating diverse and redundant cyber alternatives; and making investments for graceful degradation. Determining the trade-offs between operational loss and security gain through abnegating choices will require and reward the development of a new breed of civilian policymakers, managers and military officers able to understand both domains.
  3. Recognize that some private-sector systems fall within the national security standard. Use persuasion, federal acquisition policies, subsidy and regulation to
  4. apply the abnegating approach to these systems. While doing this, reflect an appreciation of the rapidity of cyber change by focusing on required ends while avoiding specification of means. Refrain from regulating systems that are not critical.
  5. Bolster cyber strategic stability between the United States and other major nation-states by seeking agreement on cyber constraints and confidence-building measures. As an early initiative of this kind, focus on buttressing the fragile norm of not using cyber as a means of physical attack between China, Russia and the United States.
  6. Evaluate degradation in the sought-after certainties of mutually assured destruction (MAD) as a result of uncertainties inherent in cyber foundations for nuclear command, control and attack warning. If we are moving to a regime of mutually unassured destruction (MUD), suggest to China and Russia that we are all becoming less secure. Then pursue agreements that all parties refrain from cyber intrusions into nuclear command, control and warning systems.
  7. Map the adversarial ecosystem of cyberspace in anthropological detail with the aim of increasing our understanding of our adversaries and our own incentives and methods of operation.
  8. Use the model of voluntary reporting of near-miss incidents in aviation to establish a data collection consortium that will illuminate the character and magnitude of cyber attacks against the U.S. private sector. Use this enterprise as well to help develop common terminology and metrics about cybersecurity.
  9. Establish a federally funded research and development center focused on providing an elite cyber workforce for the federal government. Hire that workforce by cyber competition rather than traditional credentials, and promote, train, retain and assign (including to the private sector) that workforce by standards different from those currently used in federal hiring.

Previously filled.

tinyLiDAR | The Maker-Friendly Laser Sensor

tinyLiDAR: The Maker-Friendly Laser Sensor; At IndieGoGo; campaign through 2017-08-13.
A Higher Performance, Arduino Compatible Time-of-Flight Sensor with Dedicated Micro

Mentions

Specifications

Distance measurements from 30 mm → 2000 mm.

Pricing

1x board → $15
3x boards →$39 + $5 SHT

Delivery

2017-10(ish)

Deadline

2017-08-13

References

  • VL53L0X, ST Microelectronics
  • Pololu VL53L0X/ Library

Promotions

Actualities

Fedora 25, installation notes & experiences

Issues

  • IPv6 addresses come up with RFC7217 privacy mode enabled
    As such, the local radvd does not tag the machine with a “known” address.
    Remediation: turn off IPV6_ADDR_GEN_MODE=stable-privacy or set IPV6_ADDR_GEN_MODE=eui64 in the relevant /etc/sysconfig/network-scripts/enp1s0.

Reminder

Fedora Live Workstation…

  • … does not enable sshd. The firewall is configured to allow it, but the service is not enabled or started after the build.
  • … builds to graphical.target.  To back down to the non-graphical mode, systemctl set-default multi-user.target.  See the guidance in the (legacy) /etc/inittab commentary.
  • … uses firewalld to manage the iptables.  If you need to install a custom iptables setup, e.g. with xtables-addons xt_geoip rules then you need iptable-services.

Actualities

sudo dnf install -y xtables-addons

See the separate recipe for bringing down firewalld and bringing up the separable iptables services

systemctl get-default
sudo systemctl set-default multi-user.target
sudo systemctl enable sshd
sudo systemctl start sshd
nmcli reload
nmcli modify enp1s0 ipv5.addr-gen-mode eui64
nmcli con down enp1s0
nmcli con up enp1s0
$ cat /etc/sysconfig/network-scripts/ifcfg-enp1s0
HWADDR=00:EC:AC:CD:E6:12
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
#IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp1s0
UUID=6c463f92-11d2-30ba-8273-d86bb3c58859
ONBOOT=yes
AUTOCONNECT_PRIORITY=-999
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

References

Standards

RFC 7217
A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)
F. Gont (SI6 Networks & UTN-FRH); IETF; 2014-04.
Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).
RFC 4941
Privacy Extensions for Stateless Address Autoconfiguration in IPv6
Narten (IBM), Draves (Microsoft) Krishnan (Ericsson); IETF; 2007-09.
Abstract: Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.

Omega2 by Onion

Availability

variously …

Documentation


Omega2 Project Book

MediaTek

Imagination

Promotions

RFC 6844 – DNS Certification Authority Authorization (CAA) Resource Record

RFC 5844DNS Certification Authority Authorization (CAA) Resource Record; IETF; P. Hallam-Baker (Comodo), R. Stradling (Comodo); 2013-01.

Example

$ORIGIN example.com
 .       CAA 0 issue "ca.example.net; account=230123
 .       CAA 0 iodef "mailto:security@example.com"
 .       CAA 0 iodef "http://iodef.example.com/"
$ORIGIN example.com
.       CAA 0 issue "ca.example.net; policy=ev"
.       CAA 128 tbs "Unknown"

Note the value 128 is the bit zero as the order of the bits is big endian.

Flags

Issuer Critical
If set to ’1′, indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer. Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set.

Property Tags

issue Issuer Domain Name [; name=value ]*
The issue property entry authorizes the holder of the domain name <Issuer Domain Name> or a party acting under the explicit authority of the holder of that domain name to issue certificates for the domain in which the property is published.
issuewild Issuer Domain Name [; name=value ]*
The issuewild property entry authorizes the holder of the domain name Issuer Domain Name or a party acting under the explicit authority of the holder of that domain name to issue wildcard certificates for the domain in which the property is published.
iodef URL
Specifies a URL to which an issuer MAY report certificate issue requests that are inconsistent with the issuer’s Certification Practices or Certificate Policy, or that a Certificate Evaluator may use to report observation of a possible policy violation. The Incident Object Description Exchange Format (IODEF) format is used [RFC5070].

Notes

Note that according to the conventions set out in [RFC1035], bit 0 is the Most Significant Bit and bit 7 is the Least Significant Bit. Thus, the Flags value 1 means that bit 7 is set while a value of 128 means that bit 0 is set according to this convention.

Referenced

RFC5070
The Incident Object Description Exchange Format (IODEF)

Sender Policy Framework (SPF)

Standards

  • RFC 7372Email Authentication Status Codes; M Kucherawy; IETF; 2014-09.
  • RFC 7208Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1; Kitterman (Kitterman); IETF; 2014-04.
  • RFC 4408Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1; M. Wong, W. Schilitt; IETF; 2006-04

Argot

  • ADministrative Management Domain (ADMD)
  • Sender Policy Framework (SPF)

PubNub

Mentions

  • PubNub
  • CrunchBase
  • Recent press
    • Twitter integration
    • HARMAN (audio)
  • pubnub, on GitHub
  • BLOCKS, a product (SaaS)
  • PubNub Data Stream Network, a product (SaaS)

Observation

  • PubNub powers the Logitech Harmony remote system
  • The remote (handset?) communicates
    • with PubNub services
    • on Amazon AWS
    • via HTTP
    • every five minutes (!!!).
  • Logitech Powers Smart Home Hub, Remote Control and App Using PubNub; a promotion, a case study; in Their Blog; WHEN?
    Mentioned

    • Harmony Hub
    • PubNub Data Streams
    • William Chien, Director of Product Management at Logitech.

Who

Previously

Actualities

WebRTC and STUN for intra-LAN exploration & end-user tracking

WebRTC

  • WebRTC, promotional site
  • Availabilities
    all the browsers that matter

    • Android
    • Chrome (Linux, Android, Windows)
    • Firefox
    • Opera
    • Safari (iOS)

STUN

Related

Standards

  • RFC 7350Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN); Petit-Huguenin, Salgueiro; IETF; 2014-08.
  • RFC 7064URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol; Nandakumar, Salgueiro, Jones, Petit-Huguenin; IETF; 2013-11.
  • RFC 5928Traversal Using Relays around NAT (TURN) Resolution Mechanism; Petit-Huguenin; IETF; 2010-08.
  • RFC 5389Session Traversal Utilities for NAT (STUN); Rosenberg, Mahy, Matthews, Wing; IETF; 2008-10.
    (obsoleted)

    • RFC 3489STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs); Rosenberg, Weinberger, Huitema, Mahy; 2003-03.

In Jimi Wales’ Wiki.

Implementation

Tracking

In archaeological order

Leaking


665909webrtc WebRCT Tracking; In Bugzilla of Mozilla; 2011-06-21 →2016-01-11; Closed as INVALID


Some droid using the self-asserted identity token cchen; How to Stop WebRTC Local IP Address Leaks on Google Chrome and Mozilla Firefox While Using Private IPs; In Privacy Online Forums; 2015-01→2015-03.

Mentions

  • Availability
    of the problem (not of WebRTC in general)

    • Chrome of Google
      • Windows
    • Firefox of Mozilla
      • Unclear, perhaps Windows only
    • Internet Explorer of Microsoft
      WebRTC is not available at all.
    • Opera of Mozilla
      • Unclear
    • Safari of Apple
      WebRTC is not available except through a plugin
    • Unavailable
      • Chrome of Google
        • OS/X
        • Android
      • Linux at all
        not clear; not mentioned at all.
  • Blocking
    • Chrome of Google
    • Firefox of Mozilla
      • Production
        • about:config
        • media.peerconnection.enabled set to true (default true)
      • Development
        same

        • Canary
        • Nightly
        • Bowser
    • Opera of Opera
  • API Directory
    • voice calls
    • video chats
    • p2p file sharing

Configuration

  • Chrome
    default is available and active
  • Firefox
    • about:config
    • media.peerconnection.enabled set to true (default true)
  • Opera
    only when configured, with a plugin, to run Google Chrome extensions

Demonstration

webrtc-ips, a STUN & WebRTC test rig

  • diafygi/webrtc-ips
  • via on-page JavaScript, makes latent requests to certain STUN servers.
  • Firefox 34 → Does. Not. Work.
  • Fails with
    Error: RTCPeerConnection constructor passed invalid RTCConfiguration - missing url webrtc-ips:58

Argot

  • Private Internet Access (PIA)
  • Real-Time-Communication (RTC)
  • Virtual Private Network (VPN)
  • WebRTC

Previously

In Privacy Online Forums:

Referenced

  • 2013
  •  Since WebRTC uses javascript requests to get your IP address, users of NoScript or similar services will not leak their IP addresses.

Via: backfill.


Firefox

  • about:config
  • media.peerconnection.enabled set to true (default true)

There are now 229 unicorn startups, with $175B in funding and $1.3T valuation | VentureBeat


There are now 229 unicorn startups, with $175B in funding and $1.3T valuation; ; In VentureBeat; 2016-01-18.

tl;dr → VentureBeat has expertise in market research compendia; the promoted pamphlet exhibits such; landinghires.



Listings

Categorized

As organized in the infographic.

Enterprise

  • Applications
    • Customer Relationship Management (CRM)
      • Apttus
      • InsideSales.com
      • Medallia
      • Zeta Interactive
    • Finance & Accounting
      • Coupa
      • Xero
      • Zuora
    • Human Resource Management (HR)
      • Gusto
      • Workday
      • Zenefits
    • Marketing & eCommerce
      • AdKnowledge
      • AppNexus
      • Blippar
      • Deem
      • Hootsuite
      • InMobi
      • IronSource
      • Marketo
      • MediaMath
      • Qualtrics
      • Shopify
      • Sprinklr
      • Surveymonkey
  • Infrastructure
    • Analytics (Big Data & Business Intelligence)
      • Cloudera
      • Domo
      • Hortonworks
      • MarkLogic
      • MongoDB
      • Mu Sigma
      • MuleSoft
      • New Relic
      • Palantir
    • Cloud
      • Actiflo
      • AppDirect
      • AppDynamics
      • CloudFlare
      • Docker
      • Nutanix
      • Simplivity
    • Content Management & Collaboration
      • Atlassian Software Systems
      • Automattic
      • Box
      • DocuSign
      • Dropbox
      • Evernote
      • GitHub
      • Slack
      • Yammer
    • Mobile
      • Good Technology
      • Meitu, Inc.
      • Wandoujia
      • Yello Mobile
    • Networking
      • Cisco Meraki
      • Nicra
      • Twilio
    • Security
      • AVAST Software as.
      • Avant
      • Illumio
      • Lookout
      • Okta
      • Palo Alto Networks
      • Tanium
      • Zscaler
    • Storage
      • Fusion-io
      • Infinidat
      • Nimble Storage
      • Pure Storage
      • Tintri

Industries

  • Cleantech
    • Betterplace
    • Bloom Energy
    • Sapphire Energy
    • Sunrun
  • Fintech
    • Insurance
      • ZhongAn
    • Investment
      • Credit Karma
      • Hanhua Financial
    • Lending
      • China Rapid Finance
      • Funding Circle
      • Jimubox
      • Kabbage
      • Lending Club
      • Lufax
      • Prosper
      • SoFi
      • TransferWise
    • Payments
      • Adyen
      • Klarna
      • Mozido
      • Powa
      • Square
      • Stripe
  • Healthcare & BioTech
    • Intarcia Therapeutics
    • Moderna Therapeutics
    • NantHealth
    • Oscar
    • Proteus Digital Health
    • Stemcentrx
    • Theranos
    • ZocDoc
  • Internet of Things (IoT)
    • Dji
    • Fitbit
    • Jasper Technologies
    • Jawbone
    • Mobileye
    • Nest
  • Other
    • AUTO1
    • Fisker Automotive
    • Njoy
    • Sogou
    • SpaceX
    • WiFi Master Key

Consumer

  • Online Media
    • AVITO.ru
    • BuzzFeed
    • Panshi
    • Rocket Internet
    • Taboola
    • Vox Media
  • Electronics (Consumer Electronics)
    • GoPro
    • Magic Leap
    • Meizu
    • Oculus VR
    • Xiaomi
  • Games & Entertainment
    • FanDuel
    • Kabam
    • Legenary Pictures
    • Machine Zone
    • Razer
    • Vice Media
    • Zynga
  • Retail
    • Coupons, Bargains. Loyalty
      • Coupang
      • Fanil
      • Groupon
      • LaShou
      • LivingSocial
      • Meituan
      • Quotient Technology
    • Home Furnishing
      • Fab.com
      • Houzz
      • Home24
      • Wayfair
    • Marketplaces
      • Alibaba
      • Auction.com
      • Etsy
      • JD.com
      • Snapdeal
      • 58 Daojia
    • Shopping
      • Mobile Shopping
        • Koudai Gouwu
        • One97 Communications
      • Non-Mobile (Laptop/Officework/Desktop) Shopping
        • BelBel
        • Dianping
        • Fanatics
        • Farfetch
        • Flipkart
        • Gilt Groupe Incorporated
        • Global Fashion Group
        • JustFab
        • Lazada
        • Mogujie
        • NONAME LOGO (magenta/purple, with a ‘J’)
        • Trendy International Group
        • VANCL
        • Wish
        • Zalando
        • Zulily
    • Wellness
      • Honest Company
      • Warby Parker
  • Services (Services to Consumers)
    • Audio
      • Beats Electronics
      • Shazam
      • Spotify
    • Education
      • Lynda.com
      • Pluralsight
      • Renaissance Learning
      • Udacity
    • Messaging
      • Kik
      • Tango
      • WhatsApp (of Facebook)
    • Sharing (The Sharing Economy)
      • Airbnb
      • BlaBlaCar
      • Blue Apron
      • Delivery Hero
      • Didi Chuxing
      • Ele.me
      • GrabTaxi
      • HelloFresh
      • HomeAway
      • Instacart
      • Kuaidi Dache
      • Lwjw
      • Lyft
      • Ola
      • Quickr
      • Thumbtack
      • Tujla
      • Uber
      • Wework
      • Yidao Yongche
      • YouTube
    • Social (Networking)
      • Instagram (of Facebook)
      • Facebook
      • Lamabang
      • LinkedIn
      • Nextdoor
      • Pinterest
      • Snapchat
      • Tumblr (of Yahoo)
      • Twitter
    • Other
      • Eventbrite
      • Waze (of Google)

Alphabetical

  • 58 Daojia
  • AUTO1
  • AVAST Software as.
  • AVITO.ru
  • Actiflo
  • AdKnowledge
  • Adyen
  • Airbnb
  • Alibaba
  • AppDirect
  • AppDynamics
  • AppNexus
  • Apttus
  • Atlassian Software Systems
  • Auction.com
  • Automattic
  • Avant
  • Beats Electronics
  • BelBel
  • Betterplace
  • BlaBlaCar
  • Blippar
  • Bloom Energy
  • Blue Apron
  • Box
  • BuzzFeed
  • China Rapid Finance
  • Cisco Meraki
  • CloudFlare
  • Cloudera
  • Coupa
  • Coupang
  • Credit Karma
  • Deem
  • Delivery Hero
  • Dianping
  • Didi Chuxing
  • Dji
  • Docker
  • DocuSign
  • Domo
  • Dropbox
  • Ele.me
  • Etsy
  • Eventbrite
  • Evernote
  • Fab.com
  • Facebook
  • FanDuel
  • Fanatics
  • Fanil
  • Farfetch
  • Fisker Automotive
  • Fitbit
  • Flipkart
  • Funding Circle
  • Fusion-io
  • Gilt Groupe Incorporated
  • GitHub
  • Global Fashion Group
  • GoPro
  • Good Technology
  • GrabTaxi
  • Groupon
  • Gusto
  • Hanhua Financial
  • HelloFresh
  • Home24
  • HomeAway
  • Honest Company
  • Hootsuite
  • Hortonworks
  • Houzz
  • Illumio
  • InMobi
  • Infinidat
  • InsideSales.com
  • Instacart
  • Instagram (of Facebook)
  • Intarcia Therapeutics
  • IronSource
  • JD.com
  • Jasper Technologies
  • Jawbone
  • Jimubox
  • JustFab
  • Kabam
  • Kabbage
  • Kik
  • Klarna
  • Koudai Gouwu
  • Kuaidi Dache
  • LaShou
  • Lamabang
  • Lazada
  • Legenary Pictures
  • Lending Club
  • LinkedIn
  • LivingSocial
  • Lookout
  • Lufax
  • Lwjw
  • Lyft
  • Lynda.com
  • Machine Zone
  • Magic Leap
  • MarkLogic
  • Marketo
  • Medallia
  • MediaMath
  • Meitu, Inc.
  • Meituan
  • Meizu
  • Mobileye
  • Moderna Therapeutics
  • Mogujie
  • MongoDB
  • Mozido
  • Mu Sigma
  • MuleSoft
  • NONAME LOGO (magenta/purple, with a ‘J’)
  • NantHealth
  • Nest
  • New Relic
  • Nextdoor
  • Nicra
  • Nimble Storage
  • Njoy
  • Nutanix
  • Oculus VR
  • Okta
  • Ola
  • One97 Communications
  • Oscar
  • Palantir
  • Palo Alto Networks
  • Panshi
  • Pinterest
  • Pluralsight
  • Powa
  • Prosper
  • Proteus Digital Health
  • Pure Storage
  • Qualtrics
  • Quickr
  • Quotient Technology
  • Razer
  • Renaissance Learning
  • Rocket Internet
  • Sapphire Energy
  • Shazam
  • Shopify
  • Simplivity
  • Slack
  • Snapchat
  • Snapdeal
  • SoFi
  • Sogou
  • SpaceX
  • Spotify
  • Sprinklr
  • Square
  • Stemcentrx
  • Stripe
  • Sunrun
  • Surveymonkey
  • Taboola
  • Tango
  • Tanium
  • Theranos
  • Thumbtack
  • Tintri
  • TransferWise
  • Trendy International Group
  • Tujla
  • Tumblr (of Yahoo)
  • Twilio
  • Twitter
  • Uber
  • Udacity
  • VANCL
  • Vice Media
  • Vox Media
  • Wandoujia
  • Warby Parker
  • Wayfair
  • Waze (of Google)
  • Wework
  • WhatsApp (of Facebook)
  • WiFi Master Key
  • Wish
  • Workday
  • Xero
  • Xiaomi
  • Yammer
  • Yello Mobile
  • Yidao Yongche
  • YouTube (of Google)
  • Zalando
  • Zenefits
  • Zeta Interactive
  • ZhongAn
  • ZocDoc
  • Zscaler
  • Zulily
  • Zuora
  • Zynga

Philips Closes Down the Hue IoT Ecosystem – No More 3rd Party Hardware

Recommendation:

Avoid

Friends of Hue – Update; Hue Developer Program, Philips.

<quote>As part of this program, last week, we started deployment of the 1.11 software for both versions of the Philips Hue bridge (version 01029624). Alongside big feature updates to our group and scene APIs (which you can read about here <snip/>) we introduced a change which stops untested products being able to join the Philips Hue bridge.</quote>

Does Philips block bulbs of other manufacturers since the latest firmware update?; Hue Developer Program, Philips.
Mentions

Promotions

In archaeological order, derivatives on top, more original opinements below.

Vendors

Blocked: at least

  • Cree
  • General Electric (GE)
  • Osram

Products

Lockin: at least

  • Bloom
  • Friends of Hue
  • Hue
  • LightStrips

Previously

Via: backfill.

Actualities

Automatic Empty Zones (including RFC 1918 prefixes) transition between BIND v9.8 and BIND v9.9

References

Standards

  • RFC 1918Address Allocation for Private Internets, 1996-02.
  • RFC 4193Unique Local IPv6 Unicast Addresses, 2005-11.
  • RFC 5737IPv4 Address Blocks Reserved for Documentation, 2010-01.
  • RFC 6598IANA-Reserved IPv4 Prefix for Shared Address Space, 2012-04.

Interesting

The two zones pertaining to the unknown address and the localhost address of IPv6 are each considered individually and separately as a zone:

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA

To amplify, there is not a containing zone that is expected to hold both of these names

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA

 Exhibitions

As of BIND v9.9, the following empty zones may be produced:

10.IN-ADDR.ARPA
16.172.IN-ADDR.ARPA
17.172.IN-ADDR.ARPA
18.172.IN-ADDR.ARPA
19.172.IN-ADDR.ARPA
20.172.IN-ADDR.ARPA
21.172.IN-ADDR.ARPA
22.172.IN-ADDR.ARPA
23.172.IN-ADDR.ARPA
24.172.IN-ADDR.ARPA
25.172.IN-ADDR.ARPA
26.172.IN-ADDR.ARPA
27.172.IN-ADDR.ARPA
28.172.IN-ADDR.ARPA
29.172.IN-ADDR.ARPA
30.172.IN-ADDR.ARPA
31.172.IN-ADDR.ARPA
168.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA

Earlier versions produced empty zones for the following:

0.IN-ADDR.ARPA
127.IN-ADDR.ARPA
254.169.IN-ADDR.ARPA
2.0.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA
D.F.IP6.ARPA
8.E.F.IP6.ARPA
9.E.F.IP6.ARPA
A.E.F.IP6.ARPA
B.E.F.IP6.ARPA

sendmail, still, intermittently, gives “host map: lookup ($domain): deferred”

Previously

sendmail gives “host map: lookup ($domain): deferred”, 2015-03-04.

Continuing

And yet it continues to happen intermittently

  • Has something to do with IPv6 vs IPv4
  • Once sendmail is in that state, it never recovers
    i.e.

    • the queue never clears
    • its growth is unbounded
  • the only remedies are manual intervention
    • sendmail -q (manually)
    • systemctl restart sendmail (manually)

Debug

$ sendmail -v -d8.32 -qIMessageID

Actualities

$ sudo sendmail -v -d8.32 -qIt85HF6hG025984
Running /var/spool/mqueue/t85HF6hG025984 (sequence 1 of 1)
dns_getcanonname(sender.example.com, trymx=1)
dns_getcanonname: trying sender.example.com. (AAAA)
	NO: errno=0, h_errno=4
dns_getcanonname: trying sender.example.com. (A)
	YES
dns_getcanonname: sender.example.com
dns_getcanonname(emerson.baker.org, trymx=1)
dns_getcanonname: trying emerson.baker.org. (AAAA)
	NO: errno=0, h_errno=4
dns_getcanonname: trying emerson.baker.org. (A)
	NO: errno=0, h_errno=4
dns_getcanonname: trying emerson.baker.org. (MX)
	YES
dns_getcanonname: emerson.baker.org
getmxrr(smart.mail.example.emerson.baker.org, droplocalhost=1)
getmxrr: res_search(smart.mail.example.emerson.baker.org) failed (errno=0, h_errno=4)
dns_getcanonname(smart.mail.example.emerson.baker.org, trymx=0)
dns_getcanonname: trying smart.mail.example.emerson.baker.org. (AAAA)
	NO: errno=0, h_errno=4
dns_getcanonname: trying smart.mail.example.emerson.baker.org. (A)
	YES
dns_getcanonname: smart.mail.example.emerson.baker.org
... Connecting to smart.mail.example.emerson.baker.org. via relay...
220 mta.emerson.baker.org ESMTP Sendmail 8.14.5/8.14.5; Thu, 10 Sep 2015 10:17:26 -0700
>>> EHLO sender.example.com
250-mta.emerson.baker.org Hello sender.example.emerson.baker.org [192.0.2.19], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP
>>> STARTTLS
220 2.0.0 Ready to start TLS
>>> EHLO sender.example.com
250-mta.emerson.baker.org Hello sender.example.emerson.baker.org [192.0.2.19], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-DELIVERBY
250 HELP
>>> MAIL From: SIZE=845
250 2.1.0 ... Sender ok
>>> RCPT To:
>>> DATA
250 2.1.5 ... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 t8AHHQ0v004865 Message accepted for delivery
... Sent (t8AHHQ0v004865 Message accepted for delivery)
Closing connection to smart.mail.example.emerson.baker.org.
>>> QUIT
221 2.0.0 mta.emerson.baker.org closing connection

The Network is Reliable | ACM Queue

Peter Bailis (UC Berkeley), Kyle Kingsbury (Jepsen Networks); The Network is Reliable; In ACM. Queue; Volume 12, issue 7; 2014-07-23.

Mentions

References