Lightweight Directory Access Protocol (LDAP): Schema for Printer Services
draft-mcdonald-ldap-printer-schema-02

RTGWG                                                              Y. Qu
Internet-Draft                                                 Futurewei
Intended status: Standards Track                             J. Tantsura
Expires: July 5, 2020                                             Apstra
                                                               A. Lindem
                                                                   Cisco
                                                                  X. Liu
                                                          Volta Networks
                                                         January 2, 2020

            A YANG Data Model for Routing Policy Management
                    draft-ietf-rtgwg-policy-model-08

Abstract

   This document defines a YANG data model for configuring and managing
   routing policies in a vendor-neutral way and based on actual
   operational practice.  The model provides a generic policy framework
   which can be augmented with protocol-specific policy configuration.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 5, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Qu, et al.                Expires July 5, 2020                  [Page 1]
Internet-Draft            Routing Policy Model              January 2020

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Goals and approach  . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology and Notation  . . . . . . . . . . . . . . . . . .   3
     2.1.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Prefixes in Data Node Names . . . . . . . . . . . . . . .   4
   3.  Model overview  . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Route policy expression . . . . . . . . . . . . . . . . . . .   5
     4.1.  Defined sets for policy matching  . . . . . . . . . . . .   6
     4.2.  Policy conditions . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Policy actions  . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Policy subroutines  . . . . . . . . . . . . . . . . . . .   9
   5.  Policy evaluation . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Applying routing policy . . . . . . . . . . . . . . . . . . .  10
   7.  Routing protocol-specific policies  . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   10. YANG modules  . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Routing policy model . . . . . . . . . . . . . . . . . .  14
   11. Policy examples . . . . . . . . . . . . . . . . . . . . . . .  31
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
     12.1.  Normative references . . . . . . . . . . . . . . . . . .  31
     12.2.  Informative references . . . . . . . . . . . . . . . . .  32
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1.  Introduction

   This document describes a YANG [RFC6020] [RFC7950] data model for
   routing policy configuration based on operational usage and best
   practices in a variety of service provider networks.  The model is
   intended to be vendor-neutral, in order to allow operators to manage
   policy configuration in a consistent, intuitive way in heterogeneous
   environments with routers supplied by multiple vendors.

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA) [RFC8342].

Qu, et al.                Expires July 5, 2020                  [Page 2]
Internet-Draft            Routing Policy Model              January 2020

1.1.  Goals and approach

   This model does not aim to be feature complete -- it is a subset of
   the policy configuration parameters available in a variety of vendor
   implementations, but supports widely used constructs for managing how
   routes are imported, exported, and modified across different routing
   protocols.  The model development approach has been to examine actual
   policy configurations in use across a number of operator networks.
   Hence the focus is on enabling policy configuration capabilities and
   structure that are in wide use.

   Despite the differences in details of policy expressions and
   conventions in various vendor implementations, the model reflects the
   observation that a relatively simple condition-action approach can be
   readily mapped to several existing vendor implementations, and also
   gives operators an intuitive and straightforward way to express
   policy without sacrificing flexibility.  A side affect of this design
   decision is that legacy methods for expressing policies are not
   considered.  Such methods could be added as an augmentation to the
   model if needed.

   Consistent with the goal to produce a data model that is vendor
   neutral, only policy expressions that are deemed to be widely
   available in existing major implementations are included in the
   model.  Those configuration items that are only available from a
   single implementation are omitted from the model with the expectation
   they will be available in separate vendor-provided modules that
   augment the current model.

2.  Terminology and Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The following terms are defined in [RFC8342]:

   o  client

   o  server

   o  configuration

   o  system state

   o  operational state

Qu, et al.                Expires July 5, 2020                  [Page 3]
Internet-Draft            Routing Policy Model              January 2020

   o  intended configuration

   The following terms are defined in [RFC7950]:

   o  action

   o  augment

   o  container

   o  container with presence

   o  data model

   o  data node

   o  feature

   o  leaf

   o  list

   o  mandatory node

   o  module

   o  schema tree

   o  RPC (Remote Procedure Call) operation

2.1.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [RFC8340].

2.2.  Prefixes in Data Node Names

   In this document, names of data nodes, actions, and other data model
   objects are often used without a prefix, as long as it is clear from
   the context in which YANG module each name is defined.  Otherwise,
   names are prefixed using the standard prefix associated with the
   corresponding YANG module, as shown in Table 1.

Qu, et al.                Expires July 5, 2020                  [Page 4]
Internet-Draft            Routing Policy Model              January 2020

   #x27; attributes, per
   IEEE-ISTO PWG IPP WG review.  
   - Revised section 7.2 to assign new OIDs for the LDAP Printer Schema 
   new attributes, per IEEE-ISTO PWG IPP WG review.  
   - Revised section 10.1 to add BCP 14 to [RFC2119] definition, per
   IEEE-ISTO PWG IPP WG review.  
   - Revised section 10.1 and section 10.2 to move [RFC2617], [RFC3987],
   [RFC4122], [RFC5198], [RFC5246], [RFC5280], [RFC5870], [STD63] from
   informative to normative references, per IEEE-ISTO PWG IPP WG review.
   
   3 April 2012 - draft-mcdonald-ldap-printer-schema-01.txt 
   - Second draft - for IEEE-ISTO PWG IPP Everywhere project 
   - Global - changed [IPPEVE1] to [PWG5100.EVE] and [IPPJPS3] to
   [PWG5100.JPS3], per IEEE-ISTO PWG IPP WG review.  
   - Revised section 1.1, to add printer-charge-info-uri and
   printer-uuid to discussion of URI syntax, per IEEE-ISTO PWG IPP WG
   review.  
   - Revised section 1.2 and section 1.3, to add printer-device-id to
   discussions of equality and substring matching, per IEEE-ISTO PWG IPP
   WG review.  
   - Revised section 3.2, section 4, and section 7.2, to delete
   redundant printer-organization and printer-organizational-unit
   (already covered by 'O' and 'OU'), per IEEE-ISTO PWG IPP WG review.  
   - Revised section 3.2, section 4, and section 7.2, to add missing
   printer-charge-info, per IEEE-ISTO PWG IPP WG review.  
   - Revised section 3.5, section 4, and section 7.2, to rename
   printer-ipp-extensions-supported to printer-ipp-features-supported,
   per IEEE-ISTO PWG IPP WG review.  
   - Revised numerous section 4 subsections, to add references to
   [IANAIPP] or [RFC3805] as appropriate for enumerations and keywords, 
   per IEEE-ISTO PWG IPP WG review.  
   - Revised section 4.2, to add 'negotiate' as value for 'auth' and
   references to [PWG5100.JPS3], [RFC4559], and [IANAIPP], per IEEE-ISTO
   PWG IPP WG review.  
   - Revised section 4.2, to use 'example.com' for all DNS names, per
   IEEE-ISTO PWG IPP WG review.  
   - Revised section 4.22 and section 4.23, to add normative reference
   to PWG Media Standardized Names [PWG5101.1], per IEEE-ISTO PWG IPP WG
   review.  
   - Revised section 4.24, to divide notes into two separate paragraphs,
   per IEEE-ISTO PWG IPP WG review.  
   - Revised section 4.31, section 4.32, and section 4.33, to change
   'Values ...  include' to 'Values ...  are' (i.e., closed set), per
   IEEE-ISTO PWG IPP WG review.  
   - Revised section 4.35 printer-device-id, to add warning about
   ordering of required key/value pairs (first) and truncation only at
   key/value pair boundaries for interoperability, per IEEE-ISTO PWG IPP

Fleming, McDonald           Expires 20 November 2012           [Page 47]
Internet-Draft       LDAP Schema for Printer Services        20 May 2012

   WG review.  
   - Revised section 4, to add printer-charge-info from [PWG5100.JPS3], 
   per IEEE-ISTO PWG IPP WG review.  
   - Revised section 4.38 printer-geo-location, to change 'should' to
   'must' for conformance to [RFC5870], per IEEE-ISTO PWG IPP WG review.
   - Revised section 4.39, to change printer-ipp-extensions-supported to
   printer-ipp-features-supported per [PWG5100.JPS3] and add examples,
   per IEEE-ISTO PWG IPP WG review.  
   - Revised section 4 subsection printer-uuid, to change 'should' to
   'must' for conformance to [RFC4122], per IEEE-ISTO PWG IPP WG review.
   - Revised section 10 References, to update out-of-date references.  
   
   2 October 2011 - draft-mcdonald-ldap-printer-schema-00.txt 
   - Initial version - for IEEE-ISTO PWG IPP Everywhere project 
   - Revised document to add current I-D individual submission
   boilerplate.  
   - Revised Abstract and section 1 Introduction, to cite [PWG5107.2]
   and [PWG5100.JPS3] new attribute sources.  
   - Revised section 3.2 printerAbstract, to add new attributes from
   [PWG5107.2] and [IPPJPS3].  
   - Revised section 3.5, to add new attributes from [IPPJPS3].  
   - Revised section 4 Definition of Attribute Types, to add new
   attributes from [PWG5107.2] and [IPPJPS3] to table and later specific
   definitions.  
   - Revised section 7.2 Registration of Attribute Types, to add new
   attributes from [PWG5107.2] and [IPPJPS3] - new OIDs needed.  
   - Revised section 10 References, to update out-of-date references.  
   

13.  Authors' Addresses

   Please send comments to the authors at the addresses listed below.  
   
   
   Pat Fleming
   IBM
   3065 Highway 52 N
   Rochester, MN 55901
   USA
   Phone: +1 507-253-7583
   EMail: patfleming@us.ibm.com
   
   
   Ira McDonald
   High North Inc
   221 Ridge Ave
   Grand Marais, MI 49839
   USA
   Phone: +1 906-494-2434

Fleming, McDonald           Expires 20 November 2012           [Page 48]
Internet-Draft       LDAP Schema for Printer Services        20 May 2012

   Email: blueroofmusic@gmail.com

Fleming, McDonald           Expires 20 November 2012           [Page 49]