A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum
RFC 4195

Network Working Group                                        W. Kameyama
Request for Comments: 4195                       GITS, Waseda University
Category: Informational                                     October 2005

    A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a Uniform Resource Name (URN) namespace that
   is engineered by the TV-Anytime Forum for naming persistent resources
   published by the TV-Anytime Forum including the TV-Anytime Forum
   Standards, XML (Extensible Markup Language) Document Type
   Definitions, XML Schemas, Namespaces, and other documents.

1.  Introduction

   The TV-Anytime Forum produces many kinds of documents (i.e.,
   specifications, working documents, and schemas) that are currently
   being considered for adoption by many standardization bodies such as
   ETSI (European Telecommunication Standardization Institute), DVB
   (Digital Video Broadcasting), ARIB (Association of Radio Industries
   and Businesses), and ATSC (Advance Television Systems Committee).

   The TV-Anytime Forum wishes to provide global, distributed,
   persistent, location-independent names for these resources.

Kameyama                     Informational                      [Page 1]
RFC 4195        A URN Namespace for the TV-Anytime Forum    October 2005

2.  Specification Template

   Namespace ID:

      "tva"

   Registration information:

      Registration Version Number: 1
      Registration Date: 2005-1-6

   Declared registrant of the namespace:

      Name:        Wataru KAMEYAMA
      Title:       Vice Chairman and Secretary, The TV-Anytime Forum
      Affiliation: Graduate School of Global Information
                   and Telecommunication Studies, Waseda University
      Address:     1011 Okuboyama, Nishi-tomida, Honjo-shi, Saitama
                   367-0035, JAPAN
      Phone:       +81 495 24 6052
      Email:       wataru@waseda.jp

   Declaration of structure:

      The Namespace Specific String (NSS) of all URNs assigned by the
      TV-Anytime Forum will have the following hierarchical structure:

                  urn:tva:{category}:{string}

      where the "category" is a US-ASCII string that conforms to URN
      syntax requirements ([RFC2141]), and "{string}" is a string that
      confirms to URN syntax requirements ([RFC2141]).

   Relevant ancillary documentation:

      The TV-Anytime Forum specifications have been publicly available
      at all stages during their development from
      "ftp://tva:tva@ftp.bbc.co.uk/Specifications/".  The final
      specifications are also available as formal ETSI (European
      Telecommunication Standardization Institute) technical
      specification documents, ETSI TS 102 822 series.

   Identifier uniqueness considerations:

      The TV-Anytime Forum shall establish unique identifiers as
      appropriate.

Kameyama                     Informational                      [Page 2]
RFC 4195        A URN Namespace for the TV-Anytime Forum    October 2005

      Uniqueness is guaranteed as long as the assigned "{category}" is
      never reassigned for other categories.  The TV-Anytime Forum is
      responsible for this.

   Identifier persistence considerations:

      The TV-Anytime Forum is committed to maintaining the accessibility
      and persistence of all resources that are officially assigned URNs
      by the organization.  Persistence of identifiers is dependent upon
      suitable delegation at the level of "category"s, and persistence
      of category assignment.

   Process of identifier assignment:

      All the assignments of identifiers are fully controlled and
      managed by the TV-Anytime Forum.

   Process of identifier resolution:

      The namespace is not listed with an RDS; this is not relevant.

   Rules for Lexical Equivalence:

      The "{category}" is case-insensitive.  Thus, the portion of the
      URN:

                  urn:tva:{category}:

      is case-insensitive for matches.  The remainder of the identifier
      shall be considered case-sensitive; hence, URNs are only lexically
      equivalent if they are also lexically identical in the remaining
      {string} field.

   Conformance with URN Syntax:

      No special considerations.

   Validation mechanism:

      Validation shall be done by a syntax grammar corresponding to each
      "{category}".

   Scope:

      Global.

quot;;
        }
      }
    }

    rpc set-current-datetime {
      nacm:default-deny-all;
      description
        "Set the /system-state/clock/current-datetime leaf
         to the specified value.

         If the system is using NTP (i.e., /system/ntp/enabled
         is set to 'true'), then this operation will fail with
         error-tag 'operation-failed' and error-app-tag value of
         'ntp-active'.";
      input {
        leaf current-datetime {
          type yang:date-and-time;
          mandatory true;
          description
            "The current system date and time.";
        }
      }
    }

    rpc system-restart {
      nacm:default-deny-all;
      description
        "Request that the entire system be restarted immediately.
         A server SHOULD send an rpc reply to the client before
         restarting the system.";
    }

    rpc system-shutdown {
      nacm:default-deny-all;
      description
        "Request that the entire system be shut down immediately.
         A server SHOULD send an rpc reply to the client before
         shutting down the system.";
    }

  }

   <CODE ENDS>

Bierman & Bjorklund          Standards Track                   [Page 30]
RFC 7317                 YANG System Management              August 2014

7.  IANA Considerations

   IANA has created an IANA-maintained YANG module called
   "iana-crypt-hash", based on the contents of Section 5, which will
   allow for new hash algorithms to be added to the type "crypt-hash".
   The registration procedure will be Expert Review, as defined by
   [RFC5226].

   This document registers two URIs in the "IETF XML Registry"
   [RFC3688].  Following the format in RFC 3688, the following
   registrations have been made.

      URI: urn:ietf:params:xml:ns:yang:iana-crypt-hash
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.

      URI: urn:ietf:params:xml:ns:yang:ietf-system
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.

   This document registers two YANG modules in the "YANG Module Names"
   registry [RFC6020].

      name: iana-crypt-hash
      namespace: urn:ietf:params:xml:ns:yang:iana-crypt-hash
      prefix: ianach
      reference: RFC 7317

      name: ietf-system
      namespace: urn:ietf:params:xml:ns:yang:ietf-system
      prefix: sys
      reference: RFC 7317

8.  Security Considerations

   The YANG modules defined in this memo are designed to be accessed via
   the NETCONF protocol [RFC6241].  The lowest NETCONF layer is the
   secure transport layer and the mandatory to implement secure
   transport is SSH [RFC6242].  The NETCONF access control model
   [RFC6536] provides the means to restrict access for particular
   NETCONF users to a pre-configured subset of all available NETCONF
   protocol operations and content.

   There are a number of data nodes defined in the "ietf-system" YANG
   module which 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.,

Bierman & Bjorklund          Standards Track                   [Page 31]
RFC 7317                 YANG System Management              August 2014

   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  /system/clock/timezone: This choice contains the objects used to
      control the time zone used by the device.

   o  /system/ntp: This container contains the objects used to control
      the Network Time Protocol servers used by the device.

   o  /system/dns-resolver: This container contains the objects used to
      control the Domain Name System servers used by the device.

   o  /system/radius: This container contains the objects used to
      control the Remote Authentication Dial-In User Service servers
      used by the device.

   o  /system/authentication/user-authentication-order: This leaf
      controls how user login attempts are authenticated by the device.

   o  /system/authentication/user: This list contains the local users
      enabled on the system.

   Some of the readable data nodes in the "ietf-system" 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:

   o  /system/platform: This container has objects that may help
      identify the specific NETCONF server and/or operating system
      implementation used on the device.

   o  /system/authentication/user: This list has objects that may help
      identify the specific user names and password information in use
      on the device.

   Some of the RPC operations in the "ietf-system" YANG module may be
   considered sensitive or vulnerable in some network environments.  It
   is thus important to control access to these operations.  These are
   the operations and their sensitivity/vulnerability:

   o  set-current-datetime: Changes the current date and time on the
      device.

   o  system-restart: Reboots the device.

   o  system-shutdown: Shuts down the device.

Bierman & Bjorklund          Standards Track                   [Page 32]
RFC 7317                 YANG System Management              August 2014

   Since this document describes the use of RADIUS for purposes of
   authentication, it is vulnerable to all of the threats that are
   present in other RADIUS applications.  For a discussion of such
   threats, see [RFC2865] and [RFC3162], and Section 4 of [RFC3579].

   This document provides configuration parameters for SSH's "publickey"
   and "password" authentication mechanisms.  Section 9.4 of [RFC4251]
   and Section 11 of [RFC4252] discuss security considerations for these
   mechanisms.

   The "iana-crypt-hash" YANG module defines a type "crypt-hash" that
   can be used to store MD5 hashes.  [RFC6151] discusses security
   considerations for MD5.  The usage of MD5 is NOT RECOMMENDED.

9.  References

9.1.  Normative References

   [FIPS.180-4.2012]
              National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
              <http://csrc.nist.gov/publications/fips/fips180-4/
              fips-180-4.pdf>.

   [IEEE-1003.1-2008]
              Institute of Electrical and Electronics Engineers,
              "POSIX.1-2008", IEEE Standard 1003.1, March 2008.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3162]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
              RFC 3162, August 2001.

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62,
              RFC 3418, December 2002.

Bierman & Bjorklund          Standards Track                   [Page 33]
RFC 7317                 YANG System Management              August 2014

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

   [RFC4252]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, January 2006.

   [RFC4253]  Ylonen, T. and C. Lonvick, Kameyama                     Informational                      [Page 3]
RFC 4195        A URN Namespace for the TV-Anytime Forum    October 2005

3.  Examples

   The following examples are not guaranteed to be real.  They are
   provided for pedagogical reasons only.

         urn:tva:metadata:2002
         urn:tva:metadata:cs:IntentionCS:2002
         urn:tva:metadata:cs:ActionTypeCS:2002
         urn:tva:rmp:tvax

4.  Community Considerations

   The names in this namespace are to be used in any public
   implementations of the TV-Anytime Forum specifications so that
   anybody can benefit from the officially assigned namespace.

   Potential beneficiary communities include:

   a) Implementers of the TV-Anytime specifications.

      Resources that comply with the TV-Anytime Forum specifications
      (including TV-Anytime schemas, instance documents that comply with
      TV-Anytime schemas, and TV-Anytime default Classification Schemes)
      may, by means of the registered namespace, become exposed to the
      general Internet and gain from the interoperability benefits of
      the Internet at large.

   b) Implementers of other specifications that incorporate components
      of the TV-Anytime specifications.

      URNs used to identify TV-Anytime components may be used to enable
      their inclusion in, and enhancement of, other specifications while
      maintaining, to a certain degree, interoperability with the TV-
      Anytime community (see a) above).

   c) Implementers of other semantically related specifications that do
      not directly incorporate components of the TV-Anytime
      specifications.

      URNs used to identify components of the TV-Anytime specifications,
      such as identifiers of terms within default Classification
      Schemes, may enable interoperation with other semantically
      determined specifications (including present and future
      metadata/resource description and ontology specifications) of
      relevance to TV-Anytime implementation communities (see a) and b)
      above).

Kameyama                     Informational                      [Page 4]
RFC 4195        A URN Namespace for the TV-Anytime Forum    October 2005

5.  Namespace Considerations

   This application requires a unique namespace because the assignment
   mechanism requires delegation to the TV-Anytime Forum.  As a
   namespace used to identify components of the TV-Anytime
   specifications, the TV-Anytime Forum will manage the inter-
   relationship of the components and the uniqueness of the identifiers.

6.  Security Considerations

   There are no additional security considerations other than those
   normally associated with the use and resolution of URNs in general.

Informative References

   [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.

Author's Address

   Wataru KAMEYAMA
   GITS, Waseda University
   1011 Okuboyama, Nishi-tomida
   Honjo-shi, Saitama, 367-0035
   JAPAN

   Phone: +81 495 24 6052
   EMail: wataru@waseda.jp

Kameyama                     Informational                      [Page 5]
RFC 4195        A URN Namespace for the TV-Anytime Forum    October 2005

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Kameyama                     Informational                      [Page 6]