Stephen Banghart Dave Waltermire ROLIE Stephen Banghart Dave Waltermire

-04 changes “Background and Motivation” section rewritten to be more concise and clear. Authentication and authorization sections combined and normative requirements removed and slated for inclusion in a separate draft. Added TLS requirements derived from RFC7589 Added requirements for handling unsupported “/” resource, and the case where a RID endpoint is not available. Streamlined discussion of link relationships throughout the draft Defined the use of the rolie:format element based on working group input Removed Search requirements and slated for inclusion in a future draft Added new sections that explain use of extension points in ROLIE Completed IANA registrations for ROLIE parameters and information type Added RelaxNG Compact schema for rolie:format

-05 changes Added ROLIE specific terminology to section 2 Added AtomPub Category Document in section 5.2 Edited document, improving consistency in terminology usage and capitalization of key terms, as well as enhancing clarity. Removed unused format parameter type in section 8.3 Full schema removed, schema changes from Atom are presented in the requirements sections.

Remaining Work Outstanding review questions: Is the categorization of normative vs informative references correct? (Issue #49) Are the XML snippets in Examples valid as per the ROLIE schema? (Issue #50) Are TLS requirements and Security Considerations sufficient? (Issue #27)

ROLIE “property” Extension Point (#51) Often there are identifying or characterizing properties of the content that doesn’t belong in a atom:category element (e.g. IODEF ID). A decision needs to be made regarding these “properties”. These options prevent a requesting client from needing to download the content to find these vital properties: Option 1: Create an extensible rolie:property element with strict constraints that allows for arbitrary exposure of data model specific properties. The scheme and name attributes are registered. Option 2: Require any arbitrary property exposure to be done through a locally defined element.

Option 1 Option 2 <atom:entry xmlns:rolie=… > <!—Other elements elided--> <atom:id> cb440117-1db0-4a47-b13f -b21de62607db</atom:id> <atom:published>2016-08 -04T18:13:51.0Z</atom:published> <rolie:format ns=“urn:ns:example:iodef"/> <rolie:property scheme=“ROLIE:CSIRT:iodef” name=“id”>897923</rolie:property> <rolie:property scheme=“iodef-date” term=“2016-06-01T18:13:51.0Z”> </atom:entry> <atom:entry xmlns:rolie=… xmlns:iodef=“urn:local:mycompany:rolie:iodef”> <!—Other elements elided--> <atom:id> cb440117-1db0-4a47-b13f -b21de62607db</atom:id> <atom:published>2016-08 -04T18:13:51.0Z</atom:published> <rolie:format ns=“urn:ns:example:iodef"/> <iodef:id>897923</iodef:id> <iodef:date> 2016-06-01T18:13:51.0Z </IODEF-DATE> </atom:entry>

Data Model Enumeration/Registration (#30) Data model enumeration/registration would involve extension documents to register the data models that support the registered information type to a global location (i.e. IANA). Pros: Provides one location that holds all officially listed data formats. Cons: Requires document authors to choose (often arbitrarily!) and register data format namespaces Registered identifiers don’t help implementations understand data formats, and if chosen arbitrarily may not even help identify Proposal: Do not require data format registration in extension drafts.

Switching Intended Status to Standards Track (#52) The current ROLIE draft’s intended status is marked as informational. Since ROLIE contains normative requirements the intended status should be standards track. Proposal: Switch ROLIE to standards track.

Discoverable Service Document Location (#53) ROLIE uses the Service Document to list all available collections. The current requirement is that this document SHOULD be discoverable in a standard location ("https://{host:port}/rolie/servicedocument“). Proposal: Change this requirement to a MUST in order to make service documents reliably discoverable.

Discoverable Categories Document Location (#54) Atom Category Documents list all the categories in use by the server, allowing clients to dynamically discover the categories and their allowed values. The ROLIE draft doesn’t provide a requirement around these documents. Proposal: Add a MUST requirement for generating and maintaining a Category document, and add a MUST requirement for a standard location. ("https://{host:port}/rolie/categorydocument“).

Example of Category Document <app:categories fixed="yes”> <atom:category scheme=“example.com/cat/classification” term=“cleared" /> <atom:category scheme=“example.com/cat/classification” term=“secret" /> <atom:category scheme=“urn:ietf:params:rolie:category:information-type” term=“incident" /> </app:categories> This document provides a dynamic list of categories (schemes) and their allowed values (terms).

Way Forward ROLIE core draft is in WGLC, these issues need resolved, and final reviews and comments need to be integrated. ROLIE extensions (software descriptor, CSIRT) are in development, we need help with these drafts! We need people interested in writing new ROLIE extensions (Configuration, Vulnerabilities, etc.), we are willing to help anyone involved.

ROLIE CSIRT Extension Draft Consists of CSIRT (Computer Security Incident Response Team) specific text that was removed from ROLIE and recast as a ROLIE extension under the new ROLIE extension system. Contains registrations for the “incident” and the “indicator” information types. Recently uploaded as a personal draft.

IODEF Purpose and Restriction These two vital IODEF (Incident Object Description Exchange Format) attributes have been added as category extensions in the CSIRT extension. Purpose: <category scheme=“urn:ietf:params:rolie:category:purpose” term=“watch”> Restriction: <category scheme=“urn:ietf:params:rolie:category:restriction” term=“green”>

IODEF ID and Date exposure As stated in the “property” issue, some elements don’t fit in the category extension but are still valuable to expose. IODEF ID and Date values made this obvious, since we can’t use atom:id and atom:published as these are established values. The “property” extension as described would make it easy to expose ID, Date, or other crucial identifying and characterizing information.

Way Forward The document needs review and developmental help from IODEF/CSIRT experts. Issues can be opened on github.