Traffic Engineering Link Management Information Base
draft-ietf-mpls-telink-mib-07

IESG has approved the document

  There are a number of data nodes defined in this YANG module that are
  writable/creatable/deletable (i.e., config true, which is the
  default).  These data nodes may be considered sensitive or vulnerable
  in some network environments.  Write operations (e.g., edit-config)
  to these data nodes without proper protection can have a negative
  effect on network operations.  These are the subtrees and data nodes
  and their sensitivity/vulnerability:

  o  /ipfix/psamp/observation-point: The configuration parameters in
      this subtree specify where packets are observed and by which
      Selection Processes they will be processed.  Write access to this
      subtree allows observing packets at arbitrary interfaces or
      linecards of the Monitoring Device and may thus lead to the export
      of sensitive traffic information.

  o  /ipfix/psamp/selection-process: The configuration parameters in
      this subtree specify for which packets information will be
      reported in Packet Reports or Flow Records.  Write access to this
      subtree allows changing the subset of packets for which
      information will be reported and may thus lead to the export of
      sensitive traffic information.

  o  /ipfix/psamp/cache: The configuration parameters in this subtree
      specify the fields included in Packet Reports or Flow Records.
      Write access to this subtree allows adding fields which may
      contain sensitive traffic information, such as IP addresses or
      parts of the packet payload.

  o  /ipfix/exporting-process: The configuration parameters in this
      subtree specify to which Collectors Packet Reports or Flow Records
      are exported.  Write access to this subtree allows exporting
      potentially sensitive traffic information to illegitimate
      Collectors.  Furthermore, TLS/DTLS parameters can be changed,
      which may affect the mutual authentication between Exporters and
      Collectors as well as the encrypted transport of the data.

  o  /ipfix/collecting-process: The configuration parameters in this
      subtree may specify that collected Packet Reports and Flow Records
      are reexported to another Collector or written to a file.  Write
      access to this subtree potentially allows reexporting or storing
      the sensitive traffic information.

  Some of the readable data nodes in this YANG module may be considered
  sensitive or vulnerable in some network environments.  It is thus
  important to control read access (e.g., via get, get-config, or
  notification) to these data nodes.  These are the subtrees and data
  nodes and their sensitivity/vulnerability:

Boyd & Seda              Expires April 25, 2019                [Page 62]
Internet-Draft  IPFIX/PSAMP/Bulk Data Export Data Models    October 2018

  o  /ipfix/psamp/observation-point: Parameters in this subtree may be
      sensitive because they reveal information about the Monitoring
      Device itself and the network infrastructure.

  o  /ipfix/psamp/selection-process: Parameters in this subtree may be
      sensitive because they reveal information about the Monitoring
      Device itself and the observed traffic.  For example, the counters
      packetsObserved and packetsDropped inferring the number of
      observed packets.

  o  /ipfix/psamp/cache: Parameters in this subtree may be sensitive
      because they reveal information about the Monitoring Device itself
      and the observed traffic.  For example, the counters activeFlows
      and dataRecords allow inferring the number of measured Flows or
      packets.

  o  /ipfix/exporting-process: Parameters in this subtree may be
      sensitive because they reveal information about the network
      infrastructure and the outgoing IPFIX Transport Sessions.  For
      example, it discloses the IP addresses of Collectors as well as
      the deployed TLS/DTLS configuration, which may facilitate the
      interception of outgoing IPFIX Messages.

  o  /ipfix/collecting-process: Parameters in this subtree may be
      sensitive because they reveal information about the network
      infrastructure and the incoming IPFIX Transport Sessions.  For
      example, it discloses the IP addresses of Exporters as well as the
      deployed TLS/DTLS configuration, which may facilitate the
      interception of incoming IPFIX Messages.

  (The section needs to be expanded to include bulk data export YANG.)

6.  Acknowledgments

  TBD

7.  References

7.1.  Normative References

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

  [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

Boyd & Seda              Expires April 25, 2019                [Page 63]
Internet-Draft  IPFIX/PSAMP/Bulk Data Export Data Models    October 2018

  [RFC5476]  Claise, B., Ed., Johnson, A., and J. Quittek, "Packet
              Sampling (PSAMP) Protocol Specifications", RFC 5476,
              DOI 10.17487/RFC5476, March 2009,
              <https://www.rfc-editor.org/info/rfc5476>.

  [RFC6728]  Muenz, G., Claise, B., and P. Aitken, "Configuration Data
              Model for the IP Flow Information Export (IPFIX) and
              Packet Sampling (PSAMP) Protocols", RFC 6728,
              DOI 10.17487/RFC6728, October 2012,
              <https://www.rfc-editor.org/info/rfc6728>.

  [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

  [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/info/rfc7011>.

  [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

  [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/info/rfc8342>.

  [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.

7.2.  Informative References

  [BBF.TR-352]
              Broadband Forum, "Multi-wavelength PON Inter-Channel-
              Termination Protocol (ICTP) Specification", May 2017,
              <https://www.broadband-forum.org/technical/download/
              TR-352.pdf>.

Boyd & Seda              Expires April 25, 2019                [Page 64]
Internet-Draft  IPFIX/PSAMP/Bulk Data Export Data Models    October 2018

  [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

  [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

  [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

  [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012,
              <https://www.rfc-editor.org/info/rfc6536>.

  [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

  [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

  [RFC8407]  Bierman, A., "Guidelines for Authors and Reviewers of
              Documents Containing YANG Data Models", BCP 216, RFC 8407,
              DOI 10.17487/RFC8407, October 2018,
              <https://www.rfc-editor.org/info/rfc8407>.

Appendix A.  Example: ietf-ipfix Usage

  This configuration example configures an IPFIX exporter for a BBF
  TR-352 ICTP Proxy.

Boyd & Seda              Expires April 25, 2019                [Page 65]
Internet-Draft  IPFIX/PSAMP/Bulk Data Export Data Models    October 2018

<ipfix>
    <exporting-process>
        <name>TR352-exporter</name>
        <destination>
            <name>ICTP-Proxy1-collector</name>
            <tcp-exporter>
                <source-method>source-address
                    <source-address>192.0.2.1</source-address>
                </source-method>
                <destination-method>destination-address
                    <destination-address>ictp-proxy-1.ngpon2-system1.com</destination-address>
                </destination-method>
            </tcp-exporter>
        </destination>
        <options>
            <name>Options 1</name>
            <options-type>extended-type-information</options-type>
            <options-timeout>0</options-timeout>
        </options>
    </exporting-prrocess>
</ipfix>

  This configuration example configures an IPFIX mediator.

Boyd & Seda              Expires April 25, 2019                [Page 66]
Internet-Draft  IPFIX/PSAMP/Bulk Data Export Data Models    October 2018

<ipfix>
    <collecting-process>
      <name>OLT-collector</name>
      <tcp-collector>
        <name>myolt-tcp-collector</name>
        <local-address-method>local-ip-address
          <local-ip-address>192.100.2.1</local-ip-address>
        </local-address-method>
      </tcp-collector>
      <exporting-process>OLT-exporter</exporting-process>
    </collecting-process>
    <exporting-process>
        <name>OLT-exporter</name>
        <destination>
            <name>big-collector</name>
            <tcp-exporter>
                <source-method>source-address
                    <source-address>192.100.2.1</source-address>
                </source-method>
                <destination-method>destination-address
                    <destination-address>big-collector1.system.com</destination-address>
                </destination-method&

[Ballot discuss]
I'd like to understand why in table

  1.3.6.1.2.1.10.200.1.4      teLinkBandwidthTable
  1.3.6.1.2.1.10.200.1.4.1    teLinkBandwidthEntry
  1.3.6.1.2.1.10.200.1.4.1.1  teLinkBandwidthPriority
  1.3.6.1.2.1.10.200.1.4.1.2  teLinkBandwidthUnreserved
  1.3.6.1.2.1.10.200.1.4.1.4  teLinkBandwidthRowStatus
  1.3.6.1.2.1.10.200.1.4.1.5  teLinkBandwidthStorageType

there is a gap between column 2 and 4. I.e. why was ccolumn 3 skipped?

Same for:

  1.3.6.1.2.1.10.200.1.7  componentLinkBandwidthTable
  1.3.6.1.2.1.10.200.1.7.1  componentLinkBandwidthEntry
  1.3.6.1.2.1.10.200.1.7.1.1  componentLinkBandwidthPriority
  1.3.6.1.2.1.10.200.1.7.1.2  componentLinkBandwidthUnreserved
  1.3.6.1.2.1.10.200.1.7.1.4  componentLinkBandwidthRowStatus
  1.3.6.1.2.1.10.200.1.7.1.5  componentLinkBandwidthStorageType

Also...
If you do not intend to represent fractional values, then it would
be good to add some text to this TC:

  TeLinkBandwidth ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
      "This type is used to represent link bandwidth in bps. This
        value is represented using a 4 octet IEEE floating point
        format."
    REFERENCE
      "IEEE Standard for Binary Floating-Point Arithmetic,
        Standard 754-1985"
    SYNTAX      OCTET STRING (SIZE(4))

[Ballot comment]
Section 4 should add to the list of requirements met:  Create and bundle TE links.
(RFC Editor Note material).

The Security Considerations warning about the read-write/read-create objects
could be stronger, given how powerful this MIB is.

Does the IANA search through MIBs still, or should there be an IANA Considerations?

Gone through MIB-doc review, Bert shepharded it.
There are some outstanding comments from the mib doctor (Dave Thaler), but would like to IETF LC it and address
all potential issues together.

MIB Doctor review

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: maandag 1 september 2003 20:43
To: 'Martin Dubuc'; Mpls (E-mail)
Subject: MIB Doctor review:draft-ietf-mpls-telink-mib-03.txt


- Interesting that title page claims that doc expires feb 2003?
  You porobably mean feb 2004

- I get this WMICng warning:
  W: f(telink.mi2), (1564,19) MIN-ACCESS value identical to access
    specified for "teLinkBandwidthUnreserved"
  Seems to me you can just remove that MIN-ACCESS from the MODULE
  COMPLIANCE.

- I see
    TeLinkSonetSdhIndication ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
          "SONET/SDH indication type."
      SYNTAX      INTEGER {
                    standard(0),
                    arbitrary(1)
                }
  Since we normallyh do not start with zero (but with 1), I assume
  there is a reason you start with zero. Could that reason be described
  and is there a doc that explains this, so that you refernece it?

NITS:

- I see
    teLinkGroups
      OBJECT IDENTIFIER ::= { teLinkConformance 1 }

    teLinkCompliances
      OBJECT IDENTIFIER ::= { teLinkConformance 2 }
  Normally we do it the other way around, first Compliances, then Groups,
  See page 35, appendix D of draft-ietf-ops-mib-review-guidelines-02.txt

- I see in OBJECT-GROUP statement things like:
    DESCRIPTION
          "Collection of objects needed for the monitoring of
          resources associated with TE links."
  I would think the objects *at least a subset) are also usefull for
  configuration. How about:
    DESCRIPTION
          "Collection of objects for management of
          resources associated with TE links."
  Most OBJECT-GROUP descritpion clauses have similar "problem".

- I see:
    teLinkModuleFullCompliance MODULE-COMPLIANCE
      STATUS current
      DESCRIPTION
      "Compliance statement for agents that support the
        configuration and monitoring of TE Link MIB module."
  Mmmm. I would word it a bit different:
      "Compliance statement for agents that support read-create
        so that both configuration and monitoring of TE Links can
        be accomplished via this MIB module."
  Matter of taste I guess.

- I see:
    teLinkModuleReadOnlyCompliance MODULE-COMPLIANCE
      STATUS current
      DESCRIPTION
      "Compliance statement for agents that support the
        monitoring of TE link MIB module."
      MODULE -- this module

      -- The mandatory groups have to be implemented
      -- by all devices supporting TE links. However, they may all
      -- be supported as read-only objects in the case where manual
      -- configuration is unsupported.

      MANDATORY-GROUPS    { teLinkGroup,
                            teLinkBandwidthGroup,
                            componentLinkBandwidthGroup }

  It seems to me that that all of those 4 comment lines are redundant.
  The idea of the MODULE-COMPLIANCE statements is that they are both
  human and machine readable.

- I see hyphenation. That is something the RFC-Editor does not want/like.

- Section 6 starts with:
    6.  Brief Description of MIB Objects

      Sections 6.1-6.4 describe objects pertaining to TE links.  The MIB
      objects were derived from the link bundling document [BUNDLING].
  How abaout the section 6.5-6.7 ??

Thanks,
Bert