Resource-Oriented Lightweight Information Exchange (ROLIE)
draft-ietf-mile-rolie-16

[Ballot comment]
Thank you for addressing my DISCUSS points.

I talked to Mark Nottingham about use of RFC5005 link relations and he explained that I was mistaken. However we agreed that slightly modifying link relation definitions from RFC5005 is not the best thing.

I am still concerned that user authentication is under-specified, but I can live with existing text.

[Ballot discuss]
This is a useful document and I will be balloting "Yes" once the following small issues are resolved/discussed (some of these come from Martin's ARTART review):

1) [Addressed in the latest revision]

2) [Addressed in the latest revision]

3) I think some of the text in 6.1.2 is misleading (or I might be wrong):

  Based on RFC5005 section 3 [RFC5005], link
  elements SHOULD be included in all Feeds to support paging using the
  following link relation types:

  o  "first" - Indicates that the href attribute value of the link
      identifies a resource URI for the furthest preceding page of the
      Feed.

  o  "last" - Indicates that the href attribute value of the link
      identifies a resource URI for the furthest following page of the
      Feed.

  o  "previous" - Indicates that the href attribute value of the link
      identifies a resource URI for the immediately preceding page of
      the Feed.

  o  "next" - Indicates that the href attribute value of the link
      identifies a resource URI for the immediately following page of
      the Feed.

Original definitions of these link relations don't include the word "page". I should double check with Mark Nottigham, but I think they reference the next/previous, first/last entry, not page. (And a page may contain several entries.) If I am correct, I don't think it is Ok to redefine meaning of existing link relations the way you do.

4) [Addressed in the latest revision]

[Ballot comment]
Recommending use of .well-known was my fault. I am looking forward to further discussion of this issue. I think the document needs some form of service discovery (and lack of DNS SRV details is a pity) and discovery of root entry for ROLIE. So I think some form of .well-known is probably needed.

I am glad you got rid of IRIs. That was one of my discussion points on -11.

I am still concerned that user authentication is under-specified, but I can live with existing text.

[Ballot discuss]
This is a useful document and I will be balloting "Yes" once the following small issues are resolved/discussed (some of these come from Martin's ARTART review):

1) 7.4.  The "rolie:property" Extension Point

  urn:ietf:params:rolie:property:content-id  The "value" attribute of
      this property is a text representation of an identifier pertaining
      to or extracted from the content referenced by the "src" attribute
      of the entry's atom:content element.

Maybe it is just me, but I can't figure out what is the syntax of this field. Can you provide a reference or at least give an example?

2) From Martin's review:

Section 5.5 prohibits the use of GET on "/".  This prohibits use of the resource for other purposes.  It seems reasonable to accept POST messages as defined in RFC 6546, but this requirement is overly strict (and further entrenches the violation of RFC 7320).  If, for instance, the server operator wishes to provide HTML in response to a GET request to "/", this would prohibit that.  The requirement to return 404 if RFC 6546 is not supported is worse; not supporting RFC 6546 might be a choice that a deployment makes to avoid the need to reserve "/" for that protocol.

Alexey: The text in -12 is an improvement, but I think it is still confusing. Maybe mention something along the lines of Martin's suggestion for the case when RFC 6546 is not supported (or at least not followed as far as the "/" resource is concerned).

5.5.  / (forward slash) Resource URL

  If the "/" resource is unsupported, then a request for this resource
  MAY be handled as deemed appropriate by the server.

Nit: You haven't expressed any requirement on implementations here, so use of MAY does not seem appropriate. What are you actually suggesting here?

3) I think some of the text in 6.1.2 is misleading (or I might be wrong):

  Based on RFC5005 section 3 [RFC5005], link
  elements SHOULD be included in all Feeds to support paging using the
  following link relation types:

  o  "first" - Indicates that the href attribute value of the link
      identifies a resource URI for the furthest preceding page of the
      Feed.

  o  "last" - Indicates that the href attribute value of the link
      identifies a resource URI for the furthest following page of the
      Feed.

  o  "previous" - Indicates that the href attribute value of the link
      identifies a resource URI for the immediately preceding page of
      the Feed.

  o  "next" - Indicates that the href attribute value of the link
      identifies a resource URI for the immediately following page of
      the Feed.

Original definitions of these link relations don't include the word "page". I should double check with Mark Nottigham, but I think they reference the next/previous, first/last entry, not page. (And a page may contain several entries.) If I am correct, I don't think it is Ok to redefine meaning of existing link relations the way you do.

4) In Section 8.3:

  Registration in the ROLIE URN Parameters registry is via the
  Specification Required policy [RFC8126].  Designated Expert reviews
  should be routed through the MILE WG mailing list.  Failing this, the
  Designated Expert will be assigned by the IESG.

As other people already pointed out, the last 2 sentences are confusing.
Are you trying to say that registration requests must be sent to the MILE mailing list or that they must be reviewed there? This is actually significant for IANA workflow.

One possibility is that all requests are sent to the MILE mailing list and then the designated expert forwards approved requests to IANA. In this case if a Designated Expert misses a request, IANA wouldn't even know that the requester is waiting for the Designated Expert.

Another possibility is for all requests to be submitted to IANA directly, then IANA can track them. IANA might either forward requests to the MILE mailing list or require that all request being submitted to the MILE mailing list first before being sent to IANA.

So please clarify.

[Ballot comment]
Recommending use of .well-known was my fault. I am looking forward to further discussion of this issue. I think the document needs some form of service discovery (and lack of DNS SRV details is a pity) and discovery of root entry for ROLIE. So I think some form of .well-known is probably needed.

I am glad you got rid of IRIs. That was one of my discussion points on -11.

I am still concerned that user authentication is under-specified, but I can live with existing text.

6.2.1.  Use of the "atom:content" Element

  This restricts atomContent in ROLIE to the atomOutofLine forumulation
  presented in[RFC4287].

Typo: formulation


In 6.2.3.  Use of the "rolie:format" Element

  The rolie:format element MAY provide a "schema-type" attribute, which
  is a mime type identifying the format of the schema resource

"mime type" should be either "MIME type" or "media type". The latter is the preferred term these days.
You also need a normative reference to media types, at least to RFC 2045.

  identified by the "schema-location" attribute.

  The following nominal example shows how these attributes describe the
  format of the content:



I think you meant "schema-type=" (note you have "-" instead of "=").

In 6.2.3 (on page 17)

  The URI used for the "ns" attribute value MUST be an absolute
  or opaque URI.

What is "opaque" URI? The sentence make it sound as if it is a term, opposite to absolute URI. Or are you trying to say that non resolvable URNs are Ok here? I suggest deleting "or opaque" from the above sentence or replacing it with something clearer.

In 6.2.4.  Use of the rolie:property Element

  Implementations MAY use locally defined and namespaced elements in an
  Entry in order to provide additional information.  Clients that do
  not recognize a property with an unregistered name attribute MAY
  ignore the rolie:property.

The second "MAY": or do what? Should the MAY be changed to a MUST?

[Ballot comment]
The schema registration in Section 8.1 says "See section A of this document." I think you mean Appendix A? Also, as with Ben I don't understand what it implies for the schema to be informative.

Section 8.3 says "Designated Expert reviews should be routed through the MILE WG mailing list.  Failing this, the Designated Expert will be assigned by the IESG." Might it be better to assign a back-up designated expert at the time of the document's approval, so that we don't end up in a situation of prolonging a registration delay by having to find and approve an expert after the WG mailing list has proved unresponsive?

[Ballot discuss]
I agree with Ben, Martin, and Mark: the way this document uses /.well-known/ URIs is not consistent with RFC5785, section 1.1. It should be understood that /.well-known/ URLs are already a carve-out from overall REST principles regarding the agency of content publishers to assign URLs within their domain as they see fit; and, as such, need non-trivial justification for their use.

If there were some fully-defined autodiscovery mechanism that were (non-artificially) constrained in such a way that only a host and port were available, then the use of /.well-known/ URIs would be more understandable. The only constraint hinted at in this document that might have these properties is the use of DNS SRV records. Given that ROLIE is defining a green-field protocol, the use of something as constrained as SRV seems ill-advised, given that the use of NAPTR records would trivially allow retrieval of a complete URL instead of just a host/port combination.

The bottom line, however, is that we need to defer specification of a /.well-known/ URL until we completely define a discovery protocol that requires it. The corollary is that we should avoid defining a discovery protocol that requires it.

[Ballot comment]
Since ROLIE requires the use of TLS client certificates, all of its resources need to be conveyed over HTTPS (i.e., ROLIE resources can never use "http" IRI schemes, only "https" IRI schemes). The following examples need to be fixed to reflect this:

Section 6.1.2:

       
       
       
       
       

Section B.1:

       
...
       
...
       
...
     
     
...
       
...
     

------------------------------------------------------------

Additionally, the following href values (also in B.1) are illegal, and need to contain a scheme (presumably, https):

         
...
         

[Ballot discuss]
-5.1.3:

I don't think Martin's  ART-ART review concern (and Mark's support) about the  .well-known URL registration has been fully resolved. While version 11 removed some of the well-known registrations, it still leaves the one.  Mark pointed out that RFC 5785 offers explicit guidance that .well-known URLs are intended to offer site-wide policy or metadata, and are not intended for general information retrieval, or to establish a namespace.  This usage seems to me to be exactly the sort of thing that the RFC advises against.

I recognize that security information is important, but I don't understand why it's discovery needs to be fundamentally different than for other stuff on using ATOM. I'm willing to be convinced, but if there's been a convincing argument so far I've missed it.

I'm not sure what to make of the second paragraph. It says DNS SRV can be used to determine the host and port. Is the expectation that people can just do that without further specification, or that someone could specify it in the future? The former is generally not true. If the intent is the latter, please clarify that in the text.

[Ballot comment]
Substantive:

-2: There are a number of lower case versions of 2119 keywords. If those are intentional, please use the updated boilerplate from RFC 8174. That being said, the following paragraph says the keywords are used for conformance.  2219/8174 keywords are not about conformance. They are about interoperability. If you want to use them for conformance, that's okay--but that means they are no longer being used as intended by 2119, and the boilerplate should be adjusted accordingly.

-3.2: I'm confused by the idea the schema is informative. I expect that at least some implementors will implement  to the schema. We have a perennial problem where implementors implement the examples rather than the text. It seems like a non-normative schema is even more of an attractive hazard in that regard.

-5.4, 2nd paragraph: This seems like an odd thing to state normatively. It seems to push for a specific organizational model for consortiums. It's reasonable to offer guidance, but I think consortiums are going to do whatever they want here.

-8.3: What is the registration policy for the top level registry?

-10:  "Overall, ROLIE introduces few privacy concerns above and beyond those present in any other HTTP protocol. "
I'm skeptical that that is true. Security information seems likely to be privacy sensitive, especially compared to some notional "generic" HTTP based protocol.






Editorial:

-5.1.2, definition of ROLIE collection: This uses the MUST as a definition, rather than a normative requirement. It would be sufficient to say that a ROLIE collection _is_ one that contains...

-5.1.3: Typo on first word "..his".
-- "requires that an implementation MUST publish"
"requires" and "MUST" are redundant. Consider simply saying "An implementation MUST publish..."

-6: "The normative requirements in this section are generally oriented towards any content to be published to a ROLIE server."
I don't understand the intent here. What else would they be about?

8.1, XML:
s/"section A" / "appendix A"

[Ballot comment]
OVERALL
I share Martin Thomson's concerns about the restriction on 0-RTT. In
the discussion, I saw two sets of concerns about 0-RTT:

- Replay
- Lack of FS

As Martin says, the replay issue is an issue for the HTTP profile, so
any concerns should be directed there. I agree that 0-RTT has inferior
FS properties, but it's worth noting that TLS 1.2 session resumption
with tickets has FS properties that are as bad or worse than those
with TLS 1.3 0-RTT, and I don't see a prohibition here on session
resumption. This leaves me a bit unclear on the security rationale
here, and I think this needs to be consistent.


INLINE COMMENTS
      or serialization.  This approach allows the provider to support
      multiple, compatible formats allowing the consumer to select the
      most suitable version.
What does "compatible" mean here. Do you mean isomorphic?


  supporting interactive user logins by members of the consortium
  SHOULD support client authentication via a federated identity scheme.
Such as?


  Proper usage of TLS as described in Section 5.3 will in many cases
  aid in the mitigation of these issues.
You should also note that TLS 1.2 and lower client auth leaks the user's identity to on-the-wire attackers.


  supported.  TLS 1.2 SHOULD be implemented according to all
  recommendations and best practices present in [RFC7525].
You need a citation to 6125 about valiation, though I realize that 7525 cites it.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-mile-rolie-10. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are seven actions which we must complete.

First, in the ns registry on the IETF XML registry page located at:

https://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: rolie-1.0
URI: urn:ietf:params:xml:ns:rolie-1.0
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Second, in the schema registry also on the IETF XML registry page located at:

https://www.iana.org/assignments/xml-registry/

a new schema will be registered as follows:

ID: rolie-1.0
URI: urn:ietf:params:xml:ns:rolie-1.0
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Because this registry also requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Third, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry on the Uniform Resource Name (URN) Namespace for IETF Use registry page located at:

https://www.iana.org/assignments/params/

a new parameter identifier will be registered as follows:

Registered Parameter Identifier: rolie
Reference: [ RFC-to-be ]
IANA Registry Reference: [ TBD-at-Registration ]

Fourth, a new, top-level registry page will be created called "Resource Oriented Lightweight Information Exchange (ROLIE) Parameters" on the IANA Matrix at:

https://www.iana.org/protocols

On this new registry page, a new registry is to be created called the ROLIE URN Parameters registry. The new registry will be managed via Specification Required as defined in [ RFC 8126 ].

There are initial registrations in the new registry as follows:

Name: category:information-type
Extension IRI: urn:ietf:params:rolie:category:information-type
Reference: [ RFC-to-be Section 8.4 ]
Sub-Registry: None

Name:
Extension IRI: urn:ietf:params:rolie:
Reference: [ RFC-to-be ]
Sub-Registry: https://www.iana.org/assignments/rolie/category/information-type

Name: property:local
Extension IRI: urn:ietf:params:rolie:property:local
Reference: [ RFC-to-be Section 7.4 ]
Sub-Registry: None

Name: category:local
Extension IRI: urn:ietf:params:rolie:category:local
Reference: [ RFC-to-be Section 7.1 ]
Sub-Registry: None

Name: property:content-author-name
Extension IRI: urn:ietf:params:rolie:property:content-author-name
Reference: [ RFC-to-be Section 7.4 ]
Sub-Registry: None

Name: property:content-id
Extension IRI: urn:ietf:params:rolie:property:content-id
Reference: [ RFC-to-be Section 7.4 ]
Sub-Registry: None

Name: property:content-published-date
Extension IRI: urn:ietf:params:rolie:property:content-published-date
Reference: [ RFC-to-be Section 7.4 ]
Sub-Registry: None

Name: property:content-updated-date
Extension IRI: urn:ietf:params:rolie:property:content-updated-date
Reference: [ RFC-to-be Section 7.4 ]
Sub-Registry: None

Fifth, a new registry is to be created called the ROLIE Information Types registry.

We note that the authors request that the registry be created in the following, specific location:

https://www.iana.org/assignments/rolie/category/information-type

The registry is to be located on the Registry Page created in step four above.

The registry is to be managed via Specification Required as defined in [ RFC 8126 ].

We understand that there are no initial registrations in the new registry.

Sixth, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a new URI is to be registered as follows:

URI Suffix: rolie/servicedocument
Change Controller: IETF
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Seventh, also in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a new URI is to be registered as follows:

URI Suffix: rolie/categorydocument
Change Controller: IETF
Reference: [ RFC-to-be ]

Because this registry also requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these seven actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-13):

From: The IESG
To: IETF-Announce
CC: ncamwing@cisco.com, mile-chairs@tools.ietf.org, mile@ietf.org, Kathleen.Moriarty.ietf@gmail.com, mile-chairs@ietf.org, draft-ietf-mile-rolie@ietf.org, Nancy Cam-Winget
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Resource-Oriented Lightweight Information Exchange) to Proposed Standard


The IESG has received a request from the Managed Incident Lightweight
Exchange WG (mile) to consider the following document: - 'Resource-Oriented
Lightweight Information Exchange'
  as Proposed Standard

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 2017-10-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a resource-oriented approach for security
  automation information publication, discovery, and sharing.  Using
  this approach, producers may publish, share, and exchange
  representations of software descriptors, security incidents, attack
  indicators, software vulnerabilities, configuration checklists, and
  other security automation information as web-addressable resources.
  Furthermore, consumers and other stakeholders may access and search
  this security information as needed, establishing a rapid and on-
  demand information exchange network for restricted internal use or
  public access repositories.  This specification extends the Atom
  Publishing Protocol and Atom Syndication Format to transport and
  share security automation resource representations.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ballot/


No IPR declarations have been submitted directly on this I-D.

draft-ietf-mile-rolie shepherd write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is being requested for publication as a Standards RFC. It defines an HTTP and Atom Publishing protocol to exchange information relevant to security applications.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes a Resource-Oriented Lightweight Information Exchange (ROLIE).  Based on a RESTful architecture, security resources are expected to be maintained in a web-accessible repository structured as Atom Syndication Format (RFC 4287) feeds.  The document details  extensions to AtomPub (RFC 5023)  and Atom Syndication Format (RFC 4287) to facilitate the sharing of information relevant to security applications.

Working Group Summary:

The document has undergone working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item.  In addition, implementations have been demonstrated through the IETF Hackathon.

Document Quality:

This document has been reviewed and revised several times. It is well written and clear. There were no specific external expert reviews conducted.

Personnel:

Nancy Cam-Winget is acting as the Document Shepherd.  Kathleen is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Document Shepherd is comfortable with this document as it represents the consensus of the working group.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors have confirmed that they have dealt with all appropriate IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents strong WG consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.



(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.

(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Normative references all look fine.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references in the document.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The specification adds a new entry to the "IETF URN Sub-namespace for Registered
  Protocol Parameter Identifiers" to define the ROLIE 1.0 as a namespace.
It conforms to RFC 3688 in its usage and addition of ROLIE 1.0’s namespace and schema.

The following new registry entry titled "Resource Oriented Lightweight Information Exchange (ROLIE) Parameters" is defined with its appropriate definition and sub-entries titled "ROLIE URN Parameters" and “ROLIE Information Types”.

Two new registrations are also added to the “Well-Known URI” to add the URI suffixes “rolie/servicedocument” and “rolie/categorydocument”.

The newly created registries look well defined.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A there are two new registries to better define the ROLIE capabilities, categories and information details, it could benefit from better review.  While the registration and new entries to these new registries will go through the MILE WG expert review; it would be beneficial to have experts in the URN and general new IANA assignments to review the process defined in this specification.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

XML snippets were validated using https://www.xmlvalidation.com