Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension
draft-ietf-manet-dlep-pause-extension-08

[Ballot discuss]
[Future 'Scale' allocations will be done via Updates:]

In Section 3.1.1:

  DS Field Qn:

      The data item contains a sequence of 8 bit DS Fields.  The number
      of DS Fields present MUST equal the sum of all Num DSCPs field
      values.

Perhaps I'm misreading, but I thought the Num DSCPs Qn field was global
for this queue index, so there would just be one of them and no need to
take a sum.

[Restart Data may not lead to data restart due to other conditions on the router]

Section 4

                                The extension does not inherently
  introduce any additional vulnerabilities above those documented in
  [RFC8175].  [...]

As noted by others, this sentence is just not true.
I will not duplicate the suggestions for additional considerations that
need to be documented.  In particular, I agree with Roman that the use
of TLS needs to be mandatory, especially since this protocol is
nominally only defined for use with radio links.

[Ballot comment]
DISCUSS cleared, leaving in my previous COMMENT:

I support the DISCUSS positions of Warren and Magnus.

I'm unclear on why this specification is necessary, i.e. why the use of existing transport protocols and processing of DSCPs do not suffice to achieve what this specification is aiming to achieve. Is that explained in another document somewhere?

= Section 1 =

"Various flow control methods are possible, e.g.,
  see [I-D.ietf-manet-dlep-da-credit-extension]."

The referenced document does not specify a flow control method. Maybe draft-ietf-manet-dlep-credit-flow-control is what was intended?

[Ballot comment]
DISCUSS -> NoObj.

Lou will add:
  Implementations of the extension defined in this document MUST support
  configuration of TLS usage, as describe in ,
  in order to protect configurations where injection attacks are
  possible, i.e., when the link between a modem and router is not
  otherwise protected.

to address my DISCUSS.


--- Archived DISCUSS position for hysterical raisins ---

Please note that I'm really not a DLEP person, and so this may be completely incorrect -- in which case I'm (of course!) happy to clear my discuss.

Hypothetical Scenario:
My next-door neighbor keeps using up all the bandwidth, making my Internets slow! Stupid neighbor!

Until now I didn't have much motivation to mess with DLEP (it didn't really gain me anything), but now I can spoof Pause Data Items to get the router to stop sending traffic to her, freeing up all the bandwidth for me.

The security considerations section doesn't *really* cover this -- it says:
" Note that this extension does allow a compromised or impersonating modem to suppress transmission by the router, but this is not a substantively different attack by such a compromised modem simply dropping all traffic destined to, or sent by a router." -- that only covers compromised modems, not impersonating modems.

It also says:
"[RFC8175] defines the use of TLS to protect against the impersonating attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't require it.

RFC8175 Security Considerations also say:
" This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed." and "Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput."

It seems that this specification is specifically allowing the dataplane to be affected by (spoofed) DLEP messages, and in a much more direct way than discussed in the RFC8175 security considerations section. I think that this is dangerous without much more direct advice (like "MUST use TLS" or similar).
-------

[Ballot discuss]
Section 3.1 defines 'Scale' as a four-bit unsigned integer field but only the
values 0-3 are assigned, leaving 4-16k usable.  How will future values be
assigned?

In Section 3.1.1:

  DS Field Qn:

      The data item contains a sequence of 8 bit DS Fields.  The number
      of DS Fields present MUST equal the sum of all Num DSCPs field
      values.

Perhaps I'm misreading, but I thought the Num DSCPs Qn field was global
for this queue index, so there would just be one of them and no need to
take a sum.

In Section 3.3:

  A router which receives the Restart Data Item SHOULD resume
  transmission of the identified traffic to the modem.

Why is this only a "SHOULD"?

Section 4

                                The extension does not inherently
  introduce any additional vulnerabilities above those documented in
  [RFC8175].  [...]

As noted by others, this sentence is just not true.
I will not duplicate the suggestions for additional considerations that
need to be documented.  In particular, I agree with Roman that the use
of TLS needs to be mandatory, especially since this protocol is
nominally only defined for use with radio links.

[Ballot comment]
Section 3.1

                                Any errors or inconsistencies
  encountered in parsing Sub Data Items are handled in the same fashion
  as any other Data Item parsing error encountered in DLEP.

I had a hard time finding the indicated behavior in RFC 8175 -- "error"
does not appear at all (and "erroneous" only twice, for IP address
processing, v4 and v6); "parse" only appears once (in the Session
Initialization State); "inconsistent" apprears several times but I did
not see one that seemed to be a generic catch-all case.  It's probably
worth putting in a section reference or changing the text to use
keywords that are searchable in RFC 8175.

Section 3.1.1

  Queue Size Qn:

      A 24-bit unsigned integer representing the size, in the octet
      scale indicated by the Scale field, of the queue supporting
      traffic with the DSCPs associated with the queue index.

Is there any value in including a specific sentinel value that indicates
that the modem cannot or does not wish to state the size of the
corresponding queue?

Section 3.2

  A router which receives the Pause Data Item MUST cease sending the
  identified traffic to the modem.  This may of course translate into
  the router's queues exceeding their own thresholds.  If a received
  Pause Data Item contains a Queue Index value other than 255, or a
  queue index established by a Session Initialization or Session Update
  Message, the router MUST terminate the session with a Status Data
  Item indicating Invalid Data.

This would be a nit, but actually has serious functional consequences:
remove the comma after "255".  The current text says that if the router
receives a queue index established by a Session Initialization message,
the router MUST terminate the session, which does not seem to be the
intent!

Section 3.3

  The Restart Data Item is used by a modem to indicate to its peer that
  transmission of previously suppressed traffic may be resumed.  An
  example of when a modem might send this data item is when an internal
  queue length drops below a particular threshold.

This seems like a fine place to suggest the application of hysteresis
(i.e., that the "particular threshold" here might be lower than the one
indicated in Section 3.2).

Section 5.x

It's not clear to me what value there is in repeating the registration
policy of the registries from which codepoints are being allocated.
IANA will apply the correct policy, and the reader of this document
doesn't need to care what policy was applied.

[Ballot comment]

Thanks to everyone who worked on this document.

I share Roman and Warren's concerns about authentication of pause messages.

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

§3.2:

>  particular threshold.  Other use cases are possible, e.g., when there
>  a non queue related congestion points within a modem, but such are

Nit: I can't quite parse the "when there a non queue" part of this.

[Ballot discuss]
Unauthenticated shutdown of the network seems exceedingly dangerous.  An expansion of the implementation scenarios described in Section 4 of RFC8175 and the architecture laid out in Figure 1 of RFC8175 appears to be:

(a) single direct connect (1x modem + 1x router)
(b) single dedicated switch (1x modem + 1x switch + 1x router)
(c) multiple connect (>1x modem + >=0 switches + 1x router)
(d) mobile environment (>=1x modem + switch + router + other devices in the switch)
(e) networked deployment (as stated in RFC8175/anything more complicated)

I believe that the safest thing is that using TLS with this extension should be a MUST.  If that is problematic, then I’d only soften it to (text that amounts to) “in environments and deployment scenarios (a) and (b), TLS SHOULD be used.  In all other environments, TLS MUST be used.”

Warren: I believe that your neighbor scenario is likely scenario (c).

As the current security considerations say, using TLS in scenario (a) won’t help if the modem gets compromised.  In the above recommendation, there is an assumption that the switch(s) isn’t compromised (and that should be documented).

[Ballot comment]
(0) I support Warren and Magnus’s DISCUSS positions.

(1) Section 3.1.  Per the Query Parameters data item, what is the router behavior when it receives:

** Num Queues = 0
** Num Queues <> the queues sent?

(2) Section 3.1.  Nit.  The size of the Reserved field is not indicated in the text (like the other fields)

(3) Section 3.1.1, Please provide a section reference into RFC8175 on error parsing.

(4) Section 3.2  Per “Each Pause Data Item identifies the traffic to be suppressed by the Queue Index defined by Section 3.1”, am I reading it right that a Queue Parameter Data Item needs to be sent before a Pause is sent?  If so, I’m not sure that is said anywhere and should be.  Furthermore, how does a router behave if it does get a Pause message prior to getting a Parameter Data Item message?

(5) Section 3.3  Related to comment-4, How does a router behave if it gets a Restart message prior to getting a Parameter Data Item or Pause message?

[Ballot discuss]
This work item does not appear to be inside the scope of the MANET charter, at least based on my reading of the charter. Am I missing something?

[Ballot comment]
I support the DISCUSS positions of Warren and Magnus.

I'm unclear on why this specification is necessary, i.e. why the use of existing transport protocols and processing of DSCPs do not suffice to achieve what this specification is aiming to achieve. Is that explained in another document somewhere?

= Section 1 =

"Various flow control methods are possible, e.g.,
  see [I-D.ietf-manet-dlep-da-credit-extension]."

The referenced document does not specify a flow control method. Maybe draft-ietf-manet-dlep-credit-flow-control is what was intended?

[Ballot discuss]
I support the DISCUSS positions of Warren and Magnus.

Also, this work item does not appear to be inside the scope of the MANET charter, at least based on my reading of the charter. Am I missing something?

[Ballot comment]
I'm unclear on why this specification is necessary, i.e. why the use of existing transport protocols and processing of DSCPs do not suffice to achieve what this specification is aiming to achieve. Is that explained in another document somewhere?

= Section 1 =

"Various flow control methods are possible, e.g.,
  see [I-D.ietf-manet-dlep-da-credit-extension]."

The referenced document does not specify a flow control method. Maybe draft-ietf-manet-dlep-credit-flow-control is what was intended?

[Ballot discuss]
Please note that I'm really not a DLEP person, and so this may be completely incorrect -- in which case I'm (of course!) happy to clear my discuss.

Hypothetical Scenario:
My next-door neighbor keeps using up all the bandwidth, making my Internets slow! Stupid neighbor!

Until now I didn't have much motivation to mess with DLEP (it didn't really gain me anything), but now I can spoof Pause Data Items to get the router to stop sending traffic to her, freeing up all the bandwidth for me.

The security considerations section doesn't *really* cover this -- it says:
" Note that this extension does allow a compromised or impersonating modem to suppress transmission by the router, but this is not a substantively different attack by such a compromised modem simply dropping all traffic destined to, or sent by a router." -- that only covers compromised modems, not impersonating modems.

It also says:
"[RFC8175] defines the use of TLS to protect against the impersonating attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't require it.

RFC8175 Security Considerations also say:
" This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed." and "Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput."

It seems that this specification is specifically allowing the dataplane to be affected by (spoofed) DLEP messages, and in a much more direct way than discussed in the RFC8175 security considerations section. I think that this is dangerous without much more direct advice (like "MUST use TLS" or similar).

[Ballot discuss]
I have similar questions as Magnus does about the specific use case for this mechanism. Moreover I wonder about the assumed usage of the different DSCPs. If the router would want to assign code points to the traffic, then it would need to know what the requirements of the traffic is which is usually unknown to a router. If there is an assumption that the traffic is marked with the right DSCP by the origin than the router does not need to know about the available DS queue configuration. Can you please clarify!

[Ballot discuss]
I have similar questions as Magnus does about the specific use case for this mechanism. Moreover I wonder about the assumed usage of the different DSCPs. If he router would want to assign assign code points to the traffic, then it would need to know what the requirement of the traffic is which is usually unknown. If there is an assumption that the traffic is marked with the right DSCP by the origin than the router does not need to know about the available DS queue configuration. Can you please clarify!

[Ballot discuss]
It is unclear to me what the purpose of the pause and resume is here?

Is it to enable the router to build the queue rather than the modem if there is a queue buildup in the modem?
If that is the case, then pause and resume will be done frequently and on short time scales due to variability of the link. And then the router resumes transmission to the modem when the buffer has been reduced? As this is enabled to be done on a queue level what how does one ensure the per hop behavior that is intended based on the DSCP with this split. Because you will get an interaction between the two queue that are in series for the same link which makes ensuring the PHB difficult.

I hope for a timely clarification to determine if this is a discuss or not and make it more actionable.

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

The IANA Functions Operator has completed its review of draft-ietf-manet-dlep-pause-extension-05. If any part of this review is inaccurate, please let us know.

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

In the Extension Type Values registry on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at:

https://www.iana.org/assignments/dlep-parameters/

a single new value is to be registered from the existing unassigned range as follows:

Code: [ TBD-at-Registration ]
Description: Control Plane Based Pause
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the Data Item Type Values registry also on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at:

https://www.iana.org/assignments/dlep-parameters/

three new registrations are to be made as follows:

Type Code: [ TBD-at-Registration ]
Description: Queue Parameters
Reference: [ RFC-to-be ]

Type Code: [ TBD-at-Registration ]
Description: Pause
Reference: [ RFC-to-be ]

Type Code: [ TBD-at-Registration ]
Description: Restart
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, a new registry is to be created called the Queue Parameters Sub Data Item Type Values registry. The new registry will be located on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at:

https://www.iana.org/assignments/dlep-parameters/

Values 0-65407 are managed via Specification Required and values 65408-65534 are managed via Private Use as defined by RFC 8126. Value 65535 is reserved.

There are initial registrations in the new registry as follows:

Type Code: Description: Reference:
-----------+------------------------------+-----------------
0 Reserved
1 Queue Parameter [ RFC-to-be ]
2-65407 Unassigned
65408-65534 Private Use
65535 Reserved

The IANA Functions Operator understands that these are the only actions 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 meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-04-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-manet-dlep-pause-extension@ietf.org, sratliff@idirect.net, Stan Ratliff , manet-chairs@ietf.org, manet@ietf.org, aretana.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DLEP Control Plane Based Pause Extension) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to
consider the following document: - 'DLEP Control Plane Based Pause Extension'
  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 2019-04-03. 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 an extension to the DLEP protocol that enables
  a modem to use DLEP messages to pause and resume data traffic coming
  from its peer router.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ballot/


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

=== AD Evaluation of draft-ietf-manet-dlep-pause-extension-04 ===
https://mailarchive.ietf.org/arch/msg/manet/YMwOuhXt-D9-6eJA2B9B-3YkfZQ


Dear authors:

I just finished reviewing this document.  I have several comments (see below) and a couple of significant issues, which I'm mentioning in the next 2 bullets.  I will wait for these to be addressed before starting the IETF LC.

(1) This is a comment for the WG (not just the authors):

This is the first draft that specifies a Sub Data Item.  Given that rfc8175 says that the Value in a Data Item "contains data specific to a particular Data Item", I don't think it is necessary to define a generic DLEP Sub Data Item.  However, not all future extensions may follow the same model.  Is there a need/interest in normatively specifying the characteristics of a Sub Data Item?

(2) Security Considerations:  The extension in itself doesn't change the security characteristics of DLEP, I agree with that.  However, I think that the functionality does -- please see specific comments below.

Thanks!

Alvaro.


[Line numbers from idnits.]

...
70 1.  Introduction
...
78   The base DLEP specification does not include any data plane flow
79   control capability.  Various flow control methods are possible, e.g.,
80   see [I-D.ietf-manet-credit-window].  The extension defined in this
...

[minor] A reference to something other than I-D.ietf-manet-credit-window (expired, etc.) may be more appropriate.


...
103 2.  Extension Usage and Identification

105   The use of the Control Plane Based Pause Extension SHOULD be
106   configurable.  To indicate that the Control Plane Based Pause
107   Extension is to be used, an implementation MUST include the Control
108   Plane Based Pause Extension Type Value in the Extensions Supported
109   Data Item.  The Extensions Supported Data Item is sent and processed
110   according to [RFC8175].

[minor] "The use of the Control Plane Based Pause Extension SHOULD be configurable."  Is there a default recommended configuration?


...
201 3.1.1.  Queue Parameter Sub Data Item
...
234   Sub Data Item Type:

236       A 16-bit unsigned integer that indicates the type and
237       corresponding format of the Sub Data Item's Value field.  Sub Data
238       Item Types are scoped within the Data Item in which they are
239       carried, i.e., the Sub Data Item Type field MUST be used together
240       with the Data Item Type to identify the format of the Sub Data
241       Item.  This field MUST be set to one (1) for the Queue Parameter
242       Sub Data Item.

[minor] "...the Sub Data Item Type field MUST be used together with the Data Item Type to identify the format of the Sub Data Item."  It sounds as if this text wants to specify the behavior for *any* Sub Data Item Type.  Please reword to be specific in to this document.  [Also, see my note at the top.]

[major] Please define a registry for the Sub Data Item Types to be used with the Queue Parameters Data Item.

244   Length:  Variable

246       Copying [RFC8175], Length is the number of octets in the sub data
247       item, excluding the Type and Length fields.

[minor] Copying?  As far as I can tell, rfc8175 doesn't define any sub data items.

249   Queue Index:

251       An 8-bit field indicating the queue index of the queue parameter
252       represented in the sub data item.  Only the first instance a a
253       particular Queue Index value is meaningful.  Subsequent sub data
254       items containing the same Queue Index values, if present, MAY be
255       logged via a management interface and MUST otherwise be ignored.

[nit] s/a a/of a

[minor] Pause and Restart reserve the Queue Index of 255 to indicate "all traffic", but that value is not reserved here.  Should it?


...
269   DS Field Qn:

271       The data item contains a sequence of 8 bit DS Fields.  The
272       position in the sequence identifies the associated queue index.
273       The number of DS Fields present should equal the sum of all Num
274       DSCPs field values.

[major] "should equal", or "MUST equal"?  If the number of DS Fields doesn't add up, should the sub data item be considered invalid?  I assume that would invalidate the whole data item.


...
286 3.2.  Pause
...
293   A modem may indicate that traffic is to be suppressed on a device
294   wide or destination specific basis.  An example of when a modem might
295   use device wide indications is when output queues are shared across
296   all destinations, and destination specific might be used when per
297   destination queuing is used.  To indicate that suppression applies to
298   all destinations, a modem MAY send the Pause Data Item in a Session
299   Update Message.  To indicate that suppression applies to a particular
300   destination a modem MAY send the Pause Data Item in a Destination
301   Update Message.

[major] I think that the two MAYs above are out of place.  I understand that sending the Pause Data Item in the corresponding Update Message is optional, but the sentences say that "To indicate that suppression applies...", which means that if the Pause Data Item is not sent, then there is no indication...so sending it is not optional.


...
312   A router which receives the Pause Data Item MUST cease sending the
313   identified traffic to the modem.  This may of course translate into
314   the router's queues exceeding their own thresholds.  If a received
315   Pause Data Item contains a Queue Index value other than 0, 255, or a
316   queue index established by a Session Initialization or Session Update
317   Message, the router MUST terminate the session with a Status Data
318   Item indicating Invalid Data.

[major] Terminating the session seems drastic to me given that the wrong index relates to a single destination and the action has an impact over all.


...
347 3.3.  Restart
...
354   The sending of this data item parallels the Pause Data Item, see the
355   previous section, and follows the same rules.  This includes that to
356   indicate that transmission can resume to all destinations, a modem
357   MAY send the Restart Data Item in a Session Update Message.  It also
358   includes that to indicate that transmission can resume to a
359   particular destination a modem MAY send the Pause Restart Item in a
360   Destination Update Message.  Finally, the same rules apply to queue
361   indexes.

[major] Same comment as above about the MAYs.

363   A router which receives the Restart Data Item SHOULD resume
364   transmission of the identified traffic to the modem.

[minor] Should the Restart always follow a Pause?  I think that is the intent.  The question is whether it MUST happen that way?  As is, the text leaves the possibility open for a modem to send a Restart without having sent a Pause.  I think that is ok, just checking...


...
384 4.  Security Considerations

386   The extension introduces a new mechanism for flow control between a
387   router and modem using the DLEP protocol.  The extension does not
388   inherently introduce any additional threats above those documented in
389   [RFC8175].  The approach taken to Security in that document applies
390   equally when running the extension defined in this document.

[major] The extension gives the modem the ability to stop the traffic sent by a router.  A rogue or compromised modem could stop traffic sent by the attached router.  Protecting the modem is out of scope, but I think the threat should at least be pointed out.

rfc8175 already mentions the risk that "an attacker might pretend to be a DLEP participant...by injection of DLEP Messages once a session has been established", which is related to this case.  However, I think that the point still needs to be called out specifically because of the new functionality introduced.


...
466 Appendix A.  Acknowledgments

468   The sub data item format was inspired by Rick Taylor's "Data Item
469   Containers".

[nit] Is this a draft?  Reference?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) The document is being submitted as a proposed standard, because it documents an extension of functionality for DLEP itself (RFC 8175). The document is marked "Standards Track".

(2)

Technical Summary

This document defines an extension to the DLEP protocol that enables
a modem to use DLEP messages to pause and resume data traffic coming
from its peer router.

Working Group Summary

The WG process was smooth, there are no issues or concerns arising from this document.

Document Quality

  The document is clear and well-written. To the shpeherd's knowledge, there are no implementations of the document. However, vendors have indicated a plan to implement the document once published. The document does not reference a MIB, or specific Media Type. Therefore, no extpert reviews were necessary.
Personnel

  The Document Shepherd is Stan Ratliff. The Responsible Area Director is Alvaro Retana.

(3) The Shepherd has reviewed the document; no issues were noticed.

(4) The Shepherd has no concerns about the depth or breadth of the reviews done.

(5) No expert reviews are needed from other groups or areas. The document describes an extension to the DLEP protocol.

(6) The Shepherd has no concerns or issues with the document.

(7) All IPR disclosures have been filed by all of the authors. No IPR exists.

(8) No IPR exists.

(9) The WG consensus is strong, amongst the DLEP experts in the group. Some have been silent on the issue, as this technology does not coincide with their interests.   

(10) No appeals have been threatened, or even discussed.

(11) No nits were found.

(12) The document does not reference MIBs, media types, or URIs. Therefore, no formal reviews of that type were required.

(13) All references are defined as either normative or informative.

(14) All normative references are to documents already published as RFCs.

(15) No downward references exist.

(16) The document will not change the status of any existing document.

(17) The Shepherd reviewed the IANA considerations, and found them to be consistent with both current IANA process, and with the document itself. No new registries are defined.

(18) The DLEP Extensions Registry "Extension Type Values" requires expert review. The experts for that registry have already been communicated to IANA.

(19) No XML code, BNF rules, or MIB definitions exist in the document.