Subject: [netmod] review of yang-types-01

From: "David Harrington" <[email-masked]>
Date: Fri, 18 Jul 2008 18:16:52 -0400

Hi,

as an individual contributor ...

I have reviewed yang-types and have some comments. Overall, the
document looks good, and I recommend it be adopted as a WG item.

1) The modules start with // XXX namespace to be allocated by IANA.
Similar to not self-assigning an OID for a MIB module, should we be
publishing with a namespace that is not yet assigned?

2) I think the organization and contact info should be the same as for
IETF MIB modules:
>From RFC4181:
   - If the module was developed by an IETF working group, then the
     ORGANIZATION clause MUST provide the full name of the working
     group, and the CONTACT-INFO clause MUST include working group
     mailing list information.  The CONTACT-INFO clause SHOULD also
     provide a pointer to the working group's web page.

3) Similar to IETF MIB modules, should the revision clause include
"published as RFC XXX"?

4) I think IETF documents are not supposed to make any claims about
being standard. Should the description clause be "This module contains
derived YANG types."?

5) typedef uri
s/A uri type represents Uniform/A uri type represents a Uniform/

6) typedef object-identifier mentions the SMIv1/v2 limit of 128
sub-ids. SMIv1/v2 should probably be mentioned in the reference
clause.

7) typedef ipv4-prefix
s/less than or equal 32/less than or equal to 32/

8) typedef uri - is it necessary to have a yang:uri (p8) and an
inet:uri (p17)? What's the difference?

9) typedef bridgeid - this is the equivalent of BridgeId from RFC4188.
Notice the dfference in capitalization. Do we really need to be
inconsistent in our naming, including the Id part?

In BridgeId, the first two octets contain a priority. In bridgeid, the
first four octets do.
In BridgeId, there is no colon; in bridgeid, there is.
In BridgeId, the last 6 octets contain the MAC address; in bridgeid,
the number of octets is not specified.
Is bridgeid supposed to follow the definition of BridgeId from
RFC4188, as the reference says?
If the definition is changed from RFC4188 to meet ieee changes, we
should reference the document that provides the new specification.

s/identifers/identifiers/

10) If we are going to define types for vlans, then I recommend
mirroring the textual conventions that were developed as a joint
effort of the IETF Bridge WG and IEEE 802, and documented in the
Q-BRIDGE-MIB (RFC4363). These would include VlanIndex, VlanId,
VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone, and possibly PortList:

   Various Working Groups have defined standards-track MIB documents
   (for example, [RFC2613] and [RFC3318]), that contain objects and
   Textual Conventions to represent a Virtual Local Area Network
   Identifier (VLAN-ID) [802.1Q].  New definitions are showing up in
   various documents (for example, [RFC4323] and [RFC4149]).
   Unfortunately, the result is a set of different definitions for the
   same piece of management information.  This may lead to confusion
and
   unnecessary complexity.  In order to address this situation, three
   new textual conventions are defined in the Q-BRIDGE-MIB, called
   VlanIdOrAny, VlanIdOrNone, and VlanIdOrAnyOrNone.  These new
textual
   conventions should be (re)used in MIB modules so that they all
   represent a VLAN-ID in the same way.

   These textual conventions provide a means to specify MIB objects
that
   refer to a specific VLAN, to any VLAN, or to no VLAN.  For an
example
   of how these textual conventions might be used, consider a MIB
   object, with SYNTAX of VlanIdOrAnyOrNone, that specifies the VLAN
on
   which to accept incoming packets of a particular protocol.  Such an
   object would allow the device to be configured to accept packets of
   this protocol received with a specific 802.1q tag value, with any
   802.1q tag value, or with no 802.1q tag.  Note that a MIB object
that
   is defined using one of these textual conventions should clarify
the
   meaning of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause.

11) References - there are "reference" clauses in the typedefs. Those
references should eb included in the References section. Since many of
the typedefs are representing a textual convention from other RFCs,
these are probably normative references.

12) Should the IANA Considerations section discuss how new values can
be added to yang-types, inet-types, and ieee-types namespaces, as per
BCP26 (RFC5226)?

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jul 2008 09:40:01 +0200

> publishing with a namespace that is not yet assigned?

In the SMI world, IANA assigns the next free number, which is easy for
IANA to do and difficult to predict. 

In the YANG world, IANA needs to assign a suitable name and I believe
at the end the WG needs to tell IANA what a suitable name will be. The
ID spells out these names in the IANA considerations sections. So my
response to your comment would be to remove the comments since the
IANA considerations take care of the assignment. ;-)

RFC 5226 says on page 16:

  For values that are text strings, a
  specific name can be suggested.  IANA will normally assign the
  name, unless it conflicts with a name already in use.

>      provide a pointer to the working group's web page.

will be fixed once this becomes a WG document

> 3) Similar to IETF MIB modules, should the revision clause include

fixed

> being standard. Should the description clause be "This module contains

fixed

> s/A uri type represents Uniform/A uri type represents a Uniform/

fixed

> sub-ids. SMIv1/v2 should probably be mentioned in the reference

I suggest to only refer to SMIv2. But this raises a different
question. I would prefer to use multiple reference statements if
multiple references are needed, but YANG does not allow this today. I
will raise this feature request in a separate thread.

> s/less than or equal 32/less than or equal to 32/

fixed

> inet:uri (p17)? What's the difference?

oops - I have removed the yang:uri definition in favour of the
inet:uri type

> In BridgeId, the first two octets contain a priority. In bridgeid, the

The text says the "first four hexadecimal digits" which is two octets
and not four.

> In BridgeId, there is no colon; in bridgeid, there is.

RFC 4188 does not specify a textual representation of BridgeId. I
tried to follow what CLIs present but then I might be looking at the
wrong CLI. In any case, we need to define the textual representation
that makes most sense.  RFC 4188 only specifies a binary
representation.

> the number of octets is not specified.

The number of octets is defined in the pattern.

> RFC4188, as the reference says?

yes

> should reference the document that provides the new specification.

I am not aware of any. In general, it would be good is some IEEE
experts can review the ieee-types.yang module.

> s/identifers/identifiers/

fixed

>    meaning of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause.

I am in favour of adding things but we should represent things in a
textual way suitable for XML and CLI usage. Constructs like
VlanIdOrAny or VlanIdOrNone are likely not needed in YANG because you
can use choices and groupings to deal with these things in a much
cleaner way. The PortList uses a compact binary encoding using a bit
field. On CLIs, you usually find representations such as '3,5-8,12',
that is a list of port numbers and port ranges separated by colons or
something like that. Or a port list might simply become a YANG
grouping with a leaf-list.

> these are probably normative references.

will add references

> be added to yang-types, inet-types, and ieee-types namespaces, as per

We only allocate values - we do not setup a new registry. Which
paragraph in section 5.1 of BCP26 do you think requires us to discuss
how new values can be added to YANG modules?

/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