Early Review of draft-ietf-teas-yang-te-types-01

Request Review of draft-ietf-teas-yang-te-types-01
Requested rev. 01 (document currently at 13)
Type Early Review
Team YANG Doctors (yangdoctors)
Deadline 2018-11-08
Requested 2018-10-18
Requested by Lou Berger
Authors Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin
Draft last updated 2018-10-30
Completed reviews Yangdoctors Early review of -01 by Jan Lindblad (diff)
Rtgdir Last Call review of -06 by Ines Robles (diff)
Secdir Last Call review of -09 by Valery Smyslov (diff)
Genart Last Call review of -09 by Linda Dunbar (diff)
This document was derived from other work that is wrapping up in the WG and was separated as it contains types that are generally useful to other TE models.  It is expected to complete LC without any substantive changes and the for YANG DR review is needed prior to submitting the publication request.  It would be great to have the review completed and document submitted for publication before Bangkok, but also understand if this deadline is too tight given meeting preparation. 

Thank you,
(As doc shepherd/wg-chair)
Assignment Reviewer Jan Lindblad 
State Completed
Review review-ietf-teas-yang-te-types-01-yangdoctors-early-lindblad-2018-10-30
Reviewed rev. 01 (document currently at 13)
Review result Ready with Issues
Review completed: 2018-10-30


This is my YANG Doctor early review of draft-ietf-teas-yang-te-types, or more specifically ietf-te-types.yang . I find the module ready with a couple of issues. I have also noted a few nits. Generally speaking, I'm not sure if reviewing a -types module with plenty of groupings on its own is the best way to go about it. The groupings defined here may be used in good or not so good ways later.

General questions:

#1: There are many locations in the YANG talking about an "ERO subobject index" (and once RRO index, record route subobject). What is this, and how is it supposed to be used? The document is silent on this matter, and I have seen modules with problems around numeric index leafs much like this earlier. Are these numbers stable, i.e. remains the same forever?

#2: There are few leafs (5) with default values given, and none with mandatory. Probably needs to increase before we get to last call.

#3: There are several choices in the module that are meant to be augmented with additional cases. In many instances, this is explicitly spelled out, very good. If this is meant to happen in all choices, it would be nice to point this out in every instance. Also, if there are any specific assumptions or considerations to keep in mind when augmenting in a new technology, please note that in the description as well.

Issues and nits:

#4: Unclear data type
  typedef admin-group {
    type binary {
      length 4;

What is the format of this binary? If this is always a 4-byte binary, wouldn't a numeric type be more user friendly, e.g. uint32?

#5: identifier in container with optional leafs
  grouping te-topology-identifier {

The name suggests this is used as an identifier, but all the leafs are optional. This is not typical. They are also in a container, precluding them from being used as list keys. Is that as intended?

#6: Optional -id leafs again
          leaf node-id {
          leaf link-tp-id {
        leaf address {
        leaf node-id {
        leaf link-tp-id {

Leafs that appear to be used as identifiers are optional

#7: binary length in bits?

           leaf as-number {
            type binary {
              length 16;
        leaf ip-flags {
          type binary {
            length 8;
          leaf label-flags {
            type binary {
              length 8;

It appears to me the modeler might have thought the length is given in bits. The value of length is in bytes, however.

#8: Must expression copy paste
    container label-end {
      must "not(../label-end/te-label/direction) or "
        + "not(te-label/direction) "
        + "or ../label-end/te-label/direction = te-label/direction" {

This must expression appears to have been copied from label-start. In any case, it always evaluates to true and has no effect.

#9: Unclear bit field
    leaf range-bitmap {
      type binary;
        "When there are gaps between label-start and label-end,
         this attribute is used to specify the positions
         of the used labels.";

Need more information on how to interpret this leaf. Which bits map to what, and what does the bit field values 0 and 1 indicate?

#10: Canonical representation
  typedef te-bandwidth {

The type is based on a string with a pattern allowing hex characters and an upper or lowercase P. Since the pattern allows multiple representations of the same underlaying value (0x1p10 presumably means the same as 0x1p0xa and 0x1P0XA) the question comes up if there is a canonical representation of this value, e.g. using all lowercase and all hex, or if the string must be remembered exactly as given by the client. The description could answer this question.

#11: Mix of upper and lowercase
The module specifies many enumeration and identity values. Some are all lowercase. Some are all uppercase. The principle of least astonishment suggests to pick one and stick with it. YANG recommendations suggest to use all lowercase when in doubt.

  typedef te-link-direction {
  typedef te-label-direction {
  typedef te-hop-type {
  identity LSP_METRIC_TYPE {

Best Regards,