Subject: [netmod] netmod session agendas

From: "David Harrington" <[email-masked]>
Date: Wed, 16 Jul 2008 12:00:19 -0400

Hi,

Below is the proposed agenda for the two sessions. 
Sorry this is so late. 
For the past month, DaveP has been on vacation, and I have been
travelling on business.

Can each author-team confirm that they will be able to present an
overview powerpoint of their proposal during the Thursday session? 

Phil, can you do an overview of the netmod architecture including the
purpose of each deliverable and how the deliverables fit together, for
the Thursday session?

For Friday:
Martin has proposed driving dicussion of the YANG open issues and
questions.
Juergen, do you need time to discuss library issues?
Can the DSDL team be prepared to drive discussion of the DSDL open
issues?

Comments welcome.

--
NETMOD WG 
IETF 72, Dublin, Ireland 
  WG Chairs: 
  David Partain ([email-masked])
  David Harrington ([email-masked]) 

THURSDAY, July 31, 2008 0900-1130 
Overview of NETMOD Deliverables

  Scribes, 
  Agenda bashing, 
  WG status review - David Partain (15 minutes) 

  Presentations providing an overview of the deliverables, 
  plus discussion of drafts proposed as WG items.

       1. NETMOD Architecture - How do the Deliverables fit together?
(20 min)
           Phil Shafer
           No internet-draft available

       2. YANG - A data modeling language for NETCONF (40 min)
           M. Bjorklund
           http://tools.ietf.org/html/draft-ietf-netmod-yang-00
           This presentation will include YIN and XML deliverables 

       3. Common YANG Data Types (15 min)
           Juergen Schoenwaelder         
 
http://tools.ietf.org/html/draft-schoenw-netmod-yang-types-01 

       4. Mapping of YANG to DSDL (20 min)
            Ladislav Lhotka, Sharon Chisholm, Rohan Mahy 
            http://tools.ietf.org/html/draft-mahy-canmod-dsdl-02 
            Ladislav Lhotka 
            http://tools.ietf.org/html/draft-lhotka-yang-dsdl-map-00 

  Open mic (20 minutes) 
      Hot topics to discuss? 

  Consensus for Adoption of Drafts as WG Items (10 minutes)
	How many have read? 
	How many believe the doc is mature enough to be a WG draft?
	Hums for and against (as contribution toward WG consensus)
	David Harrington
		YANG
		YIN (separate or combined with YANG?)
		XML Mapping (separate or combined with YANG?)
		YANG Datatypes
		DSDL Mapping

  Wrapup David Partain (10 min)

FRIDAY, Aug 1, 2008 0900-1130 
Open Issues in NETMOD

  Scribes, 
  Agenda bashing, 
  WG status review - chairs (15 minutes) 

  Open issues and questions for YANG/YIN/XML/LIB - Martin (60 min)

	Augment a grouping
	augment a leaf
	overlays
	module conformance vs. agent-variance
	list keys
	refinements and augments
		Conditional content
	ordered-by statement
	use of prefix with local names
	anyxml
	Rpcs and Notification inside lists
	default and mandatory
	Provisioning in anticipation of upgrade
	ip prefix types
	deprecated and conformance
	change control rules
	order of subelements
	range/length and pattern statements
	regexp for domain name
	ABNF for YANG comments
	Keyrefs
	deprecated & obsolete

  Open issues and questions for DSDL (30 min)

  Open discussion (30 min)

  Wrapup - David Partain (15 min)

--
Thanks,
David Harrington
[email-masked]
[email-masked]
[email-masked]

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Jul 2008 18:12:00 +0200

> For Friday:

..

> Can the DSDL team be prepared to drive discussion of the DSDL open

I am trying to change my booking for the return flight and hotel, if I
succeed, I'll be prepared.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Jul 2008 22:25:06 +0200

> overview powerpoint of their proposal during the Thursday session? 

I will take care of the data types document.

> Juergen, do you need time to discuss library issues?

At this point in time, I believe it is more critical to get core YANG
language issues resolved. So lets put data types last and I fine with
skipping this altogether in order to get more YANG language issues
resolved.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Jul 2008 13:47:44 -0700

> skipping this altogether in order to get more YANG language issues

I extracted the new modules and there are a few typos/errors:

module: yang-types, pg. 5:

OLD:

     revision 2009-05-22 {

NEW:

     revision 2008-05-22 {

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

module: inet-types, pg. 17:

OLD:

               express 'URI absent' where required."
           reference "RFC 3986 STD 66 and RFC 3305"

NEW:

               express 'URI absent' where required.";
           reference "RFC 3986 STD 66 and RFC 3305";

> /js

Andy

Warning: Revision date in the future (2009-05-22)
yang-types-00.yang:20.5: warning(421): revision date in the future

Warning: no valid revision statements, setting version to '2008-07-16' for module 'yang-types'
*** yang-types-00.yang: 0 Errors, 2 Warnings

inet-types.yang:321.11: error(245): wrong token type  Expected: semi-colon or left brace

inet-types.yang:322.7: error(245): wrong token type  Expected: semi-colon or left brace

*** inet-types.yang: 2 Errors, 0 Warnings
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Jul 2008 23:39:17 +0200

> module: yang-types, pg. 5:

Thanks, both fixed in my sources.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Jul 2008 14:57:08 -0700

> skipping this altogether in order to get more YANG language issues

Agreed.

I reviewed the draft, and it looks fine to me.
I attached the diff files in case anyone wants to verify that
clarifications and bugfixes are the only changes from yang-00.

Andy

Index: yang-types.yang
===================================================================
--- yang-types.yang	(revision 54)
+++ yang-types.yang	(working copy)
@@ -9,14 +9,15 @@
         "YANG Language Design Team";
 
     contact
-        "Martin Bjorklund (Editor) <[email-masked]>";
+        "Juergen Schoenwaelder (Editor)
+         <[email-masked]>";
 
     description
         "This module contains standard derived YANG types.";
 
-    reference "draft-ietf-netmod-yang-00.txt";
+    reference "draft-schoenw-netmod-yang-types-01.txt";
 
-    revision 2007-10-02 {
+    revision 2009-05-22 {
         description "Initial revision.";
     }
 
@@ -147,7 +148,7 @@
     typedef uri {
         type string;
         description
-           "A uri type represents Uniform Resource Identifier (URI) 
+           "A uri type represents Uniform Resource Identifier (URI)
             as defined by STD 66.
 
             Objects using this type MUST be in US-ASCII encoding, and
@@ -176,12 +177,13 @@
 
     typedef object-identifier {
         type string {
-            pattern '[0-2](\.\d+)+';
+            pattern '([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*)))'
+                  + '(\.(0|([1-9]\d*)))*';
         }
         description
            "The object-identifier type represents administratively
             assigned names in a registration-hierarchical-name tree.
-  
+
             Values of this type are denoted as a sequence of numerical
             non-negative sub-identifier values. Each sub-identifier
             value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers
@@ -229,13 +231,14 @@
             date-time       = full-date "T" full-time';
         reference "RFC 3339";
     }
-    
+
     typedef timeticks {
         type uint32;
         description
            "The timeticks type represents a non-negative integer
             which represents the time, modulo 2^32 (4294967296
             decimal), in hundredths of a second between two epochs.
+
             When objects are defined which use this type, the
             description of the object identifies both of the reference
             epochs.";
@@ -271,7 +274,7 @@
         type string;
         description
            "Represents media- or physical-level addresses.";
-        reference 
+        reference
            "RFC 2579 (STD 58)";
     }
 }
Index: inet-types.yang
===================================================================
--- inet-types.yang	(revision 54)
+++ inet-types.yang	(working copy)
@@ -1,278 +1,325 @@
-module inet-types {
+  module inet-types {
 
-    // XXX namespace to be allocated by IANA
+      // XXX namespace to be allocated by IANA
 
-    namespace "urn:ietf:params:xml:ns:yang:inet-types";
-    prefix "inet";
+      namespace "urn:ietf:params:xml:ns:yang:inet-types";
+      prefix "inet";
 
-    organization
-        "YANG Language Design Team";
+      organization
+          "YANG Language Design Team";
 
-    contact
-        "Martin Bjorklund (Editor) <[email-masked]>";
+      contact
+          "Juergen Schoenwaelder (Editor)
+           <[email-masked]>";
 
-    description
-        "This module contains standard derived YANG types
-         for Internet addresses and related things.";
+      description
+          "This module contains standard derived YANG types
+           for Internet addresses and related things.";
 
-    reference "draft-ietf-netmod-yang-00.txt";
+      reference "draft-schoenw-netmod-yang-types-01.txt";
 
-    revision 2007-10-02 {
-        description "Initial revision.";
-    }
+      revision 2008-06-07 {
+          description "Initial revision.";
+      }
 
-    /*
-     * collection of protocol field related types
-     */
+      /*
+       * collection of protocol field related types
+       */
 
-    typedef ip-version {
-        type enumeration {
-            enum unknown {
-                value 0; 
-                description
-                   "An unknown or unspecified version of the 
-                    Internet protocol.";
-            }
-            enum ipv4 {
-                value 1;
-                description
-                   "The IPv4 protocol as defined in RFC 791.";
-            }
-            enum ipv6 {
-                value 2;
-                description
-                   "The IPv6 protocol as defined in RFC 2460.";
-            }
-        }
-        description
-           "This value represents the version of the IP protocol.";
-        reference
-           "RFC 791 (STD 5), RFC 2460";
-    }
+      typedef ip-version {
+          type enumeration {
+              enum unknown {
+                  value 0;
+                  description
+                     "An unknown or unspecified version of the
+                      Internet protocol.";
+              }
+              enum ipv4 {
+                  value 1;
+                  description
+                     "The IPv4 protocol as defined in RFC 791.";
+              }
+              enum ipv6 {
+                  value 2;
+                  description
+                     "The IPv6 protocol as defined in RFC 2460.";
+              }
+          }
+          description
+             "This value represents the version of the IP protocol.";
+          reference
+             "RFC 791 (STD 5), RFC 2460";
+      }
 
-    typedef dscp {
-        type uint8 {
-            range "0..63";
-        }
-        description
-           "The dscp type represents a Differentiated Services
-            Code-Point that may be used for marking a traffic
-            stream.";
-        reference 
-           "RFC 3289, RFC 2474, RFC 2780";
-    }
+      typedef dscp {
+          type uint8 {
+              range "0..63";
+          }
+          description
+             "The dscp type represents a Differentiated Services
+              Code-Point that may be used for marking a traffic
+              stream.";
+          reference
+             "RFC 3289, RFC 2474, RFC 2780";
+      }
 
-    typedef flow-label {
-        type uint32 {
-            range "0..1048575";
-        }
-        description
-           "The flow-label type represents flow identifier or 
-            Flow Label in an IPv6 packet header that may be 
-            used to discriminate traffic flows.";
-        reference
-           "RFC 2460";
-    }
+      typedef flow-label {
+          type uint32 {
+              range "0..1048575";
+          }
+          description
+             "The flow-label type represents flow identifier or
+              Flow Label in an IPv6 packet header that may be
+              used to discriminate traffic flows.";
+          reference
+             "RFC 2460";
+      }
 
-    typedef port-number {
-        type uint16 {
-            range "1..65535";
-        }
-        description
-           "The port-number type represents a 16-bit port
-            number of an Internet transport layer protocol
-            such as UDP, TCP, DCCP or SCTP. Port numbers are
-            assigned by IANA.  A current list of all 
-            assignments is available from
-            <http://www.iana.org/>.
+      typedef port-number {
+          type uint16 {
+              range "1..65535";
+          }
+          description
+             "The port-number type represents a 16-bit port
+              number of an Internet transport layer protocol
+              such as UDP, TCP, DCCP or SCTP. Port numbers are
+              assigned by IANA.  A current list of all
+              assignments is available from
+              <http://www.iana.org/>.
 
-            Note that the value zero is not a valid port
-            number. A union type might be used in situations
-            where the value zero is meaningful.";
-        reference
-           "RFC 4001";
-    }
-    
-    /*
-     * collection of autonomous system related types
-     */
+              Note that the value zero is not a valid port
+              number. A union type might be used in situations
+              where the value zero is meaningful.";
+          reference
+             "RFC 4001";
+      }
 
-    typedef asn {
-        type uint32;
-        description
-           "The asn type represents autonomous system numbers which
-            identify an Autonomous System (AS). An AS is a set of
-            routers under a single technical administration, using an
-            interior gateway protocol and common metrics to route
-            packets within the AS, and using an exterior gateway
-            protocol to route packets to other ASs'. IANA maintains
-            the AS number space and has delegated large parts to the
-            regional registries.
+      /*
+       * collection of autonomous system related types
+       */
 
-            Autonomous system numbers are currently limited to 16 bits
-            (0..65535). There is however work in progress to enlarge
-            the autonomous system number space to 32 bits. This
-            textual convention therefore uses an uint32 base type
-            without a range restriction in order to support a larger
-            autonomous system number space.";
-        reference
-           "RFC 1771, RFC 1930, RFC 4001";
-    }
+      typedef as-number {
+          type uint32;
+          description
+             "The as-number type represents autonomous system numbers
+              which identify an Autonomous System (AS). An AS is a set
+              of routers under a single technical administration, using
+              an interior gateway protocol and common metrics to route
+              packets within the AS, and using an exterior gateway
+              protocol to route packets to other ASs'. IANA maintains
+              the AS number space and has delegated large parts to the
+              regional registries.
 
-    /*
-     * collection of IP address and hostname related types
-     */
+              Autonomous system numbers are currently limited to 16 bits
+              (0..65535). There is however work in progress to enlarge
+              the autonomous system number space to 32 bits. This
+              textual convention therefore uses an uint32 base type
+              without a range restriction in order to support a larger
+              autonomous system number space.";
+          reference
+             "RFC 1771, RFC 1930, RFC 4001";
+      }
 
-    typedef ip-address {
-        type union {
-            type inet:ipv4-address;
-            type inet:ipv6-address;
-        }
-        description
-           "The ip-address type represents an IP address and
-            is IP version neutral. The format of the textual
-            representations implies the IP version.";
-    }
+      /*
+       * collection of IP address and hostname related types
+       */
 
-    typedef ipv4-address {
-        type string {
-            pattern 
-               '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}'
-             + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])'
-             + '(%[\p{N}\p{L}]+)?';
-        }
-        description
-           "The ipv4-address type represents an IPv4 address in
-            dotted-quad notation. The IPv4 address may include
-            a zone index, separated by a % sign.";
-    }
+      typedef ip-address {
+          type union {
+              type inet:ipv4-address;
+              type inet:ipv6-address;
+          }
+          description
+             "The ip-address type represents an IP address and
+              is IP version neutral. The format of the textual
+              representations implies the IP version.";
+      }
 
-    typedef ipv6-address {
-        type string {
-            pattern
-               /* full */
-               '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})'
-            +  '(%[\p{N}\p{L}]+)?)'
-               /* mixed */
-            +  '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.'
-            +      '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
-            +   '(%[\p{N}\p{L}]+)?)'
-              /* shortened */
-            + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
-            +   '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
-            +   '(%[\p{N}\p{L}]+)?)'
-              /* shortened mixed */
-            + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
-            +  '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
-            +  '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
-            +   '(%[\p{N}\p{L}]+)?)';
-        }
-        description
-           "The ipv6-address type represents an IPv6 address in
-            full, mixed, shortened and shortened mixed notation.
-            The IPv6 address may include a zone index, separated
-            by a % sign.";
-    }
+      typedef ipv4-address {
+          type string {
+              pattern
+                 '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+               + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])'
+               + '(%[\p{N}\p{L}]+)?';
+          }
 
-    typedef ip-prefix {
-        type union {
-            type inet:ipv4-prefix;
-            type inet:ipv6-prefix;
-        }
-        description
-           "The ip-prefix type represents an IP prefix and
-            is IP version neutral. The format of the textual
-            representations implies the IP version.";
-    }
+          description
+             "The ipv4-address type represents an IPv4 address in
+              dotted-quad notation. The IPv4 address may include
+              a zone index, separated by a % sign.
 
-    typedef ipv4-prefix {
-        type string {
-            pattern 
-               '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}'
-             + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])'
-             + '/\p{N}+';
-        }
-        description
-           "The ipv4-prefix type represents an IPv4 address prefix.
-            The prefix length is given by the number following the
-            slash character and must be less than or equal 32. 
-            Values larger than 32 should be treated as 32.
+              The zone index is used to disambiguate identical address
+              values.  For link-local addresses, the zone index will
+              typically be the interface index number or the name of an
+              interface. If the zone index is not present, the default
+              zone of the device will be used.";
+      }
 
-            A prefix length value of n corresponds to an IP address
-            mask which has n contiguous 1-bits from the most
-            significant bit (MSB) and all other bits set to 0.
+      typedef ipv6-address {
+          type string {
+              pattern
+                 /* full */
+                 '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})'
+              +  '(%[\p{N}\p{L}]+)?)'
+                 /* mixed */
+              +  '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.'
+              +      '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
+              +   '(%[\p{N}\p{L}]+)?)'
+                /* shortened */
+              + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
+              +   '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
+              +   '(%[\p{N}\p{L}]+)?)'
+                /* shortened mixed */
+              + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
+              +  '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
+              +  '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
+              +   '(%[\p{N}\p{L}]+)?)';
+          }
+          description
+             "The ipv6-address type represents an IPv6 address in
+              full, mixed, shortened and shortened mixed notation.
+              The IPv6 address may include a zone index, separated
+              by a % sign.
 
-            The IPv4 address represented in dotted quad notation 
-            should have all bits that do not belong to the prefix
-            set to zero.";
-    }
+              The zone index is used to disambiguate identical address
+              values.  For link-local addresses, the zone index will
+              typically be the interface index number or the name of an
+              interface. If the zone index is not present, the default
+              zone of the device will be used.";
+          reference
+              "RFC 4007: IPv6 Scoped Address Architecture";
+      }
 
-    typedef ipv6-prefix {
-        type string {
-            pattern
-               /* full */
-               '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})'
-            +  '/\p{N}+)'
-               /* mixed */
-            +  '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.'
-            +      '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
-            +   '/\p{N}+)'
-               /* shortened */
-            +  '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
-            +   '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
-            +   '/\p{N}+)'
-               /* shortened mixed */
-            + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
-            +  '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
-            +  '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
-            +   '/\p{N}+)';
-        }
-        description
-           "The ipv6-prefix type represents an IPv6 address prefix.
-            The prefix length is given by the number following the
-            slash character and must be less than or equal 128. 
-            Values larger than 128 should be treated as 128.
+      typedef ip-prefix {
+          type union {
+              type inet:ipv4-prefix;
+              type inet:ipv6-prefix;
+          }
+          description
+             "The ip-prefix type represents an IP prefix and
+              is IP version neutral. The format of the textual
+              representations implies the IP version.";
+      }
 
-            A prefix length value of n corresponds to an IP address
-            mask which has n contiguous 1-bits from the most
-            significant bit (MSB) and all other bits set to 0.
+      typedef ipv4-prefix {
+          type string {
+              pattern
+                 '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+               + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])'
+               + '/\p{N}+';
+          }
+          description
+             "The ipv4-prefix type represents an IPv4 address prefix.
+              The prefix length is given by the number following the
+              slash character and must be less than or equal 32.
 
-            The IPv6 address represented in dotted quad notation 
-            should have all bits that do not belong to the prefix
-            set to zero.";
-    }
+              A prefix length value of n corresponds to an IP address
+              mask which has n contiguous 1-bits from the most
+              significant bit (MSB) and all other bits set to 0.
 
-    typedef domain-name {
-        type string {
-            pattern '([\p{L}\p{N}]+\.)*[\p{L}\p{N}]';
-        }
-        description
-           "The domain-name type represents a DNS domain
-            name. The name SHOULD be fully qualified
-            whenever possible.
+              The IPv4 address represented in dotted quad notation
+              should have all bits that do not belong to the prefix
+              set to zero.";
+      }
 
-            The description clause of objects using the
-            domain-name type MUST describe how (and when)
-            these names are resolved to IP addresses.
+      typedef ipv6-prefix {
+          type string {
+              pattern
+                 /* full */
+                 '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})'
+              +  '/\p{N}+)'
+                 /* mixed */
+              +  '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.'
+              +      '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
+              +   '/\p{N}+)'
+                 /* shortened */
+              +  '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
+              +   '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
+              +   '/\p{N}+)'
+                 /* shortened mixed */
+              + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
+              +  '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
+              +  '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
+              +   '/\p{N}+)';
+          }
+          description
+             "The ipv6-prefix type represents an IPv6 address prefix.
+              The prefix length is given by the number following the
+              slash character and must be less than or equal 128.
 
-            Note that the resolution of a domain-name value 
-            may require to query multiple DNS records (e.g.,
-            A for IPv4 and AAAA for IPv6).  The order of the
-            resolution process and which DNS record takes
-            precedence depends on the configuration of the
-            resolver.";
-        reference
-           "RFC 1034";
-    }
+              A prefix length value of n corresponds to an IP address
+              mask which has n contiguous 1-bits from the most
+              significant bit (MSB) and all other bits set to 0.
 
-    typedef host {
-        type union {
-            type inet:ip-address;
-            type inet:domain-name;
-        }
-        description
-           "The host type represents either an IP address
-            or a DNS domain name.";
-    }
+              The IPv6 address should have all bits that do not belong
+              to the prefix set to zero.";
+      }
 
-}
+      /*
+       * Domain name and URI types.
+       */
+
+      typedef domain-name {
+          type string {
+              pattern '([a-zA-Z0-9\-]+\.)*[a-zA-Z0-9\-]+';
+          }
+          description
+             "The domain-name type represents a DNS domain
+              name. The name SHOULD be fully qualified
+              whenever possible.
+
+              The description clause of objects using the
+              domain-name type MUST describe how (and when)
+              these names are resolved to IP addresses.
+
+              Note that the resolution of a domain-name value
+              may require to query multiple DNS records (e.g.,
+              A for IPv4 and AAAA for IPv6).  The order of the
+              resolution process and which DNS record takes
+              precedence depends on the configuration of the
+              resolver.";
+          reference
+             "RFC 1034";
+      }
+
+      typedef host {
+          type union {
+              type inet:ip-address;
+              type inet:domain-name;
+          }
+          description
+             "The host type represents either an IP address
+              or a DNS domain name.";
+      }
+
+      typedef uri {
+          type string;    // TBD: add the regex from RFC 3986 here?
+          description
+             "The uri type represents a Uniform Resource Identifier
+              (URI) as defined by STD 66.
+
+              Objects using the uri type must be in US-ASCII encoding,
+              and MUST be normalized as described by RFC 3986 Sections
+              6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
+              percent-encoding is removed, and all case-insensitive
+              characters are set to lowercase except for hexadecimal
+              digits, which are normalized to uppercase as described in
+              Section 6.2.2.1.
+
+              The purpose of this normalization is to help provide
+              unique URIs.  Note that this normalization is not
+              sufficient to provide uniqueness.  Two URIs that are
+              textually distinct after this normalization may still be
+              equivalent.
+
+              Objects using the uri type may restrict the schemes that
+              they permit.  For example, 'data:' and 'urn:' schemes
+              might not be appropriate.
+
+              A zero-length URI is not a valid URI.  This can be used to
+              express 'URI absent' where required.";
+          reference "RFC 3986 STD 66 and RFC 3305";
+      }
+
+  }
+

// Generated by yangdiff 0.1.0
// old: yang-types (2007-10-02) yang-types.yang
// new: yang-types (2008-07-16) yang-types.yang

M contact
M reference
D revision '2007-10-02'
A revision '2009-05-22'
M typedef object-identifier
  M type
    M pattern

// Generated by yangdiff 0.1.0
// old: inet-types (2007-10-02) inet-types.yang
// new: inet-types (2008-06-07) inet-types.yang

M contact
M reference
D revision '2007-10-02'
A revision '2008-06-07'
D typedef asn
M typedef ipv4-address
  M description 
M typedef ipv6-address
  M description 
  A reference 'RFC 4007: IPv6 Scope...'
M typedef ipv4-prefix
  M description 
M typedef ipv6-prefix
  M description 
M typedef domain-name
  M type
    M pattern
A typedef as-number
A typedef uri

// Generated by yangdiff 0.1.0
// old: yang-types (2007-10-02) yang-types.yang
// new: yang-types (2008-07-16) yang-types.yang

  revision 2008-07-16 {
    description "
      - Changed contact
      - Changed reference
      - Removed revision '2007-10-02'
      - Added revision '2009-05-22'
      - Changed typedef object-identifier
        - Changed type
          - Changed pattern
    ";
  }

// Generated by yangdiff 0.1.0
// old: inet-types (2007-10-02) inet-types.yang
// new: inet-types (2008-06-07) inet-types.yang

  revision 2008-07-16 {
    description "
      - Changed contact
      - Changed reference
      - Removed revision '2007-10-02'
      - Added revision '2008-06-07'
      - Removed typedef asn
      - Changed typedef ipv4-address
        - Changed description 
      - Changed typedef ipv6-address
        - Changed description 
        - Added reference 'RFC 4007: IPv6 Scope...'
      - Changed typedef ipv4-prefix
        - Changed description 
      - Changed typedef ipv6-prefix
        - Changed description 
      - Changed typedef domain-name
        - Changed type
          - Changed pattern
      - Added typedef as-number
      - Added typedef uri
    ";
  }
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: "David Harrington" <[email-masked]>
Date: Mon, 21 Jul 2008 10:53:12 -0400

Hi,

Masrtin has asked whether we should just present the same presentation
again for new people. Here is my long response, so the WG can
understand my viewpoint of what the Thursday meeting should be about.

This is the first meeting of the WG. I expect that will draw a number
of people who have not been involved in the past. 

In Philadelphia, the YANG preentation was about YANG versus the CANMOD
requirements. That presentation is a sales job for why YANG is needed,
and why it is better than the alternatives. 

In Vancouver, YANG Boot Camp was presented in the OPS Open Area
meeting. This showed some examples, focusing a great deal on
demonstrating how human-readable YANG is as a modeling language, and
sprinkled a description of YANG with sales messages.

We are not in the CANMOD BOF anymore. We are not trying to convince
the IAB and IESG to approve work on a netconf DML. We do not need to
sell people on a "new approach to network management"; we do not need
to sell people on why Netconf will revolutionize the world. The new
approach to network management has been accepted by the IETF. Netconf
has been approved as a proposed standard. We need to stop focusing on
selling that solution. We do not need to keep focusing on why YANG is
the answer for netconf data modeling. We have convinced the IETF this
is a worthwhile effort on which to spend IETF resources - we have a
WG.

Now we need to start talking about the pieces of the solution in
detail. The whole thing starts at YANG, so we need a discussion of how
YANG goes about modeling things. This is all old hat to the YANG GANG,
but we have a new audience - the IETF general community - to start
training about how this stuff actually works.

YANG is relatively mature already. But now that the WG has been
approved, there are people who will begin to get more involved in the
details. People from other areas that have a need for configuration
will have been watching while the IETF community leaders decided
whether to approve this direction, but not necessarily reading the
drafts in depth. 

Now people from other IETF areas need to develop an understanding of
how to use YANG to do modeling. Representatives from companies that
have decided the Netconf solution looks promising want to know what
they need to implement to also provide support for standardized
models. That is where we should focus our Thursday session - on our
potential new customers, not on the IAB or IESG.

I suggest discussing the main modeling concepts of YANG that module
users need to know: 
how are modules defined? 
how are namespaces handled?
how are standard and proprietary modules differentiated?
If you are the editor for a WG model, how do you get a namespace for
your module?
If you are the editor for a proprietary model, how do you define a
neamspace?
What naming conventions should be used for standard and proprietary
objects?
what structure are available to organize information conceptually
(containers, lists, leafs) 
what information gets defined for objects - indices, units, must,
presence, defaults, mandatory)
what information gets included about relationships between structures?
(uses)
what information allows reuse of information?  (grouping, imports,
uses, augment, extensions ...)
what information allows defining new operations (rpc, notification,
etc. )

Many of the people who will want to use YANG already have some
experience with SMIv2. For those things that are similar to SMIv2, you
might want to mention the similarity. For those things that are new,
such as rpcs and groupings, you might want to mention how this
addresses problems that SMIv2 cannot.

You also need to talk about XML-in-the-wire. I expect this will be an
obvious output, and will not require much discussion in Thirsday's
session. You also need to discuss YIN - why it's there, and how
modelres can utilize it (maybe for things like design reviews and
model validation and relationship checking using existing XML-based
tools).

All of this stuff is engrained in your thinking, but there are a whole
bunch of new people who you need to help understand how to use YANG,
YIN, and the XML-on-the-wire.

You might want to mention what's available for YANG tools.
You might want to quickly mention areas of YANG that still need work,
like compliance.

The LIB presentation should discuss what's available for standard
types. How does a WG or a company define new types if needed?

YANG, YIN, XML, and LIB have been available in internet-drafts for a
long time already. The active participants in netmod are already in
agreement that ese documents are mature enough to use as the starting
documents. In Thursday's meeting, we will decide whether to adopt
these as WG items, and consensus is alreadt apparent they will be
adopted.

The Arch presentation needs to put YANG, YIN, XMLL, LIB, and DSDL into
context. It needs to discuss the inputs and outputs of YANG, the
purpose of each format, and how the pieces are expected to be used,
and how they fit together to provide a modeling solution for people
that need to do modeling for Netconf. It should not focus on selling
the new approach to network management or selling netconf; it should
be a design review of how the netmod deliverables provide an
environment to help modelers model.

The DSDL presentations are different. they need to present the
proposals and show that each document (or a proposed merged document)
is mature enough to be consideed a WG item to meet the chartered DSDL
deliverable. 

Those are my suggestions for the Thursday presentations.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]] 
> Sent: Sunday, July 20, 2008 3:50 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [netmod] netmod session agendas
> 
> Hi,
> 
> "David Harrington" <[email-masked]> wrote:

> 
> Do we expect new people with no clues about YANG at this session?
We
> have presented YANG three times during the last two IETF meetings...
> I guess I can present these same slides again if necessary, but at
the
> same time I know how it feels to sit in the audience listening to
the
> same presentation as last time again...  IMO it's usually a waste of
> time for the people that actually did read the draft or actually do
> remember the last session.  This being said, I think the other
> overview presentations will be useful - we haven't heard an
> architectural presentation or a yang->dsdl presentation.
> 
> > For Friday:
> I'm looking forward to this technical session!
> 
> 
> /martin
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Jul 2008 17:06:41 +0200

Hi Dave,

> is mature enough to be consideed a WG item to meet the chartered DSDL

I can prepare 2-3 overview slides describing what the DSDL output looks
like and what it can be used for.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Mon, 21 Jul 2008 11:34:29 -0400

"David Harrington" writes:
>This is all old hat to the YANG GANG,

So Thursday is a training session for non-BOFers, meant to give the
rest of the IETF a jump start on using YANG for their modeling work.
You want less marketing of the ideas/history/motivation behind YANG
and more training on how the parts fit together and how they work
to deliver useful functionality.  Am I reading you right?

My concern is that non-BOFers won't understand why we need this and
why they care.  Yes, the IETF is onboard the YANG Love Fest, but
that doesn't mean we'll automatically win over the world at large.

I think there are two pieces to winning the world.  Deliver a usable
solution in a timely manner, and generate excitement about our
solution.  IMHO we should work on the former and save the latter
until we are ready to deliver.  Or is your take that we have a
sufficiently usable solution that we should get people to start
using now?

Your questions list is great, and there are a number of such questions
without answers.  Should we spend the first session working out
these answers?

My concern is that we'll get the same audience as the last few
IETFs, since this is by definition the folks that are interested
in this topic (and are on this mailing list) and that we'll spend
valuable face-2-face time listening to information we already know
(while those not on this mailing list read their email ;^).

How about this:  we take a show of hands at the start of the session
for the number of audience members that have read the YANG spec
(the folks that come to the meeting prepared) who didn't attend the
OPS-AREA boot camp or BOF (who already know what we're doing).  If
this group is sufficently small, the WG chairs can decide to skip
the training agenda items and move on into open issues and real
work.  Otherwise the work issues are pushed to Friday's session.
We can have these training materials available (and online) and if
they aren't needed, no problem.

Thanks,
 Phil

---

From: "David Harrington" <[email-masked]>
Date: Mon, 21 Jul 2008 16:42:28 -0400

Hi, 

> From: Phil Shafer [mailto:[email-masked]] 
> Sent: Monday, July 21, 2008 11:34 AM
> To: David Harrington
> Cc: [email-masked]

yes.

> sufficiently usable solution that we should get people to start

I think we need to work on the first. The "generate excitement" is the
purpose of vendors' marketing departments, not the IETF.

I think we have a sufficiently usable proposal to start working on
developing an IETF proposed standard. Standards are developed by WGs,
and I think we need to let the WG get more involved.

> without answers.  Should we spend the first session working out

I think Thursday should review what we already have proposed answers
for, and which we do not. I think Friday is the session to try to work
out the engineering answers.

> (while those not on this mailing list read their email ;^).

Let me give you a different perspective. Huawei thinks netconf and its
new approach to network management loosk like a reasonable solution to
device configuration, and have started prototyping. But they have a
concern about netconf data modeling. The netconf WG basically said
"oh, just invent your own DML". Huawei has followed the discussions in
the IETF about XSD vs RelaxNG vs YANG (to the degree those have been
public discussions, and not discussions held in ad-hoc meetings or
over dinners by the "inner circle" of the netconf world). It has becoe
obvious that designing DMLs is not an easy thing to do, and developing
one that could be approved as a standard is a highly political
process.

By approving the netmod WG, the IETF has signalled that "ok, now we
are serious about developing a standard modeling language for use with
netconf". At this point, Huawei and other companies that are
considering supporting netconf know there is a reasonable chance the
IETF is going to produce a standard DML for netconf. Now they want a
better understanding of the design that is being considered as the
starting point. Our charter actually makes the Dublin meeting an
important point in deciding whether the proposed documents should be
adopted as WG items. This will be the first there **is** a WG to make
such decisions. 

> they aren't needed, no problem.

If we were only going to discuss the technical issues, I would have
only requested one session. We deliberately requested two sessions
because there are two purposes we need to achieve - first we need to
make new WG people aware of the work we are doing and what the design
of the work is, and to allow the WG (not just the design team) to
choose to adopt the starting point documents, and secondly, we need to
have our engineers work through some detailed problems in the specs. 

Making people aware of the architectural designs greatly benefits from
f2f powerpoint sessions. There is a significant barrier to entry in
this WG because YANG was developed by a closed team, all of whom were
implementers of the netconf/YANG solution. Any new members of this WG
(and many who have been following the progress) are at a significant
disadvantage as compared to the YANG team members. This is an IETF WG;
as a chair, it is my job to ensure that we have a fair and open
process. And jumping straight into detailed discussions of things like
keyrefs and pattern statements and deprecated statements is not fair
to the new members attending the first meeting of this WG. 

I do consider it fair to announce that the second session will be a
detailed working session where contributors are expected to have fully
read and understood the documents because we will be dealing with
issues like keyrefs and patterns, and deprecated status. And I expect
that we can require for future sessions that contributors have fully
read and understood the documents. But I do not think it is fair to
expect that of the first official meeting of the WG.

Most of the detailed engineering work can be done effectively on the
mailing list; In fact, because some of the key contributors will not
be in attendance, the mailing list is probably a better place (and the
IETF-required place) to reach consensus on the technical engineering
issues. 

dbh

---

From: Phil Shafer <[email-masked]>
Date: Mon, 21 Jul 2008 21:55:31 -0400

"David Harrington" writes:
>Let me give you a different perspective.

Cool.  I'm onboard.

Thanks,
 Phil

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Jul 2008 06:31:22 -0700

>>>>> On Mon, 21 Jul 2008 11:34:29 -0400, Phil Shafer <[email-masked]> said:

PS> How about this:  we take a show of hands at the start of the session
PS> for the number of audience members that have read the YANG spec
PS> (the folks that come to the meeting prepared) who didn't attend the
PS> OPS-AREA boot camp or BOF (who already know what we're doing).

An additional two questions you might consider asking the room: How many
*not in the design group or "in crowd"* have read the draft.  And then
ask, of those and feel they understand the specs well enough to write a
YANG module without asking a lot of questions of an expert (or if they
could read a moderately complex one written by someone else and
understand how it would translate to an XML-encoded netconf message).

If the goal of YANG is to define something simpler to use the same
number of hands should ideally be up both times.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 23 Jul 2008 17:24:22 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "David Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 21, 2008 5:34 PM
Subject: Re: [netmod] netmod session agendas

> they aren't needed, no problem.

There seems to be an assumption here that reading the YANG spec will obviate the
need for training, something of which I have yet to be convinced:-)  Look at
dbh's list, and tell me where the answers are
in the YANG spec: eg

how are modules defined?

Do you notice something?  There is an awful lot of names and namespaces,
something that XML has got badly wrong (IMHO) and which I am unclear how much
YANG has improved on.  But reading 263kbyte of the YANG spec does not enlighten
me
much:-(

And I would see the discussions on the list on mandatory, default, config,
presence etc as a symptom not that the YANG spec is unclear, but that the
concepts need spelling out, and I wonder if that is done, then those concepts
may turn out to be
unclear

By contrast, I recall when first I read RFC1155 - in some ways, an analogous
document - and immediately getting a clear idea of the key concepts.

I think you need something else, an RFC that enables people to understand the
concepts of YANG before they dive into the encyclopaedia that this I-D is.

Answers to dbh's questions would provide a start.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Jul 2008 10:44:57 -0700

> Subject: Re: [netmod] netmod session agendas

I don't really understand this whole thread.
NETMOD has a complicated problem to solve.
There exists a draft-00 for the main component,
and a draft-01 for the spun-off data types.
The WG has yet to meet even once.

Of course the specifications are unclear.
Of course they are not ready to be training manuals
for novice data modelers.

People with the proper expertise to complete the
WG charter items should be involved at this point,
not novice data modelers.  This WG will never
finish anything if it has to train people how
to design data modeling languages which support
real world NE devices and operator requirements.

I think Dave's idea of 1 session to bring more people
up to speed is fine.  I also think the open issue
list, and the job ahead, is rather non-trivial.
Anyone who thinks that we'll knock it out
in 2.5 hours is not paying attention.
Try 25 or 50 hours of f2f meetings.

> YANG has improved on.  But reading 263kbyte of the YANG spec does not enlighten

What is the alternative? OIDs?
At least YANG abstracts away the namespace by
equating it with the module naming scope.
At least XPath absolute paths are readable,
and happen to look exactly like the unix pathspec
operators already know.

> concepts of YANG before they dive into the encyclopaedia that this I-D is.

I sure hope we don't need an RFC to read before
you can read the YANG RFC.  I agree that a newbie
would have no hope of figuring out the complex concepts
and constructs by reading the current -00 spec.

We have to decide how much of the training is really in
scope for the YANG standard.  Maybe a companion Information RFC
with lots more examples and guidelines would be a good idea,
but this is not usually part of the standard.

> Answers to dbh's questions would provide a start.

How are modules defined?  RTFM!

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jul 2008 13:49:07 -0400

>dbh's list, and tell me where the answers are

I think there are a lots of open questions, including many on dbh's
list.  My concern is that the training dbh is after is the level
of "tell me what the spec says", not the "I read the spec and still
have questions".

>YANG has improved on.  But reading 263kbyte of the YANG spec does not enlighten

We didn't fix XML namespace issues :-(

>concepts need spelling out, and I wonder if that is done, then those concepts

The spec definitely needs work, which is my concern about burning
face time on training, versus finding problems in the spec and
correcting them.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jul 2008 14:49:02 -0400

>Try 25 or 50 hours of f2f meetings.

Right, so if we spend 2.5 hours on real issues each IETF, we can
plan on 20 IETFs (7 years).  If we use both sessions (5 hrs) we
need only 10 IETFs (3.5 years).  Guess which one I'm rooting for?

;^)

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Jul 2008 12:08:16 -0700

> need only 10 IETFs (3.5 years).  Guess which one I'm rooting for?

I'm OK with slideware for the missing drafts and
the complex issues for the first meeting,
but not for overviews of the current drafts.

2 years + a 3-day interim meeting

1 year + 2 3-day interim meetings

Andy

---

From: "tom.petch" <[email-masked]>
Date: Tue, 29 Jul 2008 18:24:45 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 23, 2008 7:49 PM
Subject: Re: [netmod] netmod session agendas

<snip>
> face time on training, versus finding problems in the spec and
I think that what is needed, what would speed the process of developing yang, is
another I-D which focuses on the concepts.  The current one is great on the
detail but hard to use to understand the approach that yang is taking - on
names, reuse, groupings/containers,  OO v .... the topics I see generating
discussion on the mailing lists.  What I have seen more than once is a
discussion starting out as a point of detail in the spec and ending up some time
later as a discussion of a point of principle, of approach.  Were the principles
spelt out more clearly to start with, then I think that you would shorten those
discussions, get more involvement in the discussion, with prospects of reaching
a rough consensus faster.

Andy has made the point that yang is a bottom up language, that you have to
start at the lowest leaf and apply all the various refinements etc in order to
arrive at the actual data definitions.  This may - may not - be the best way to
model network data but I do not see it as the best way to communicate what the
language is; that should be top down.

And of course, I am thinking of a document whose target audience is experienced
data modellers, who now want to get up to speed in yang.

Tom Petch