[i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS)

[Benoit Claise <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-i2rs-yang-l3-topology-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

We're making progress. Thanks.

>>
>> 4.
>>
>>         leaf-list router-id {
>>             type inet:ip-address;
>>             description
>>               "Router-id for the node";
>>           }
>>
>> My initial DISCUSS was: We don't want to wait for
>> https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we
>> should expedite this publication), but any good reason why this is
>> aligned with its definition?
>>      typedef router-id {
>>         type yang:dotted-quad;
>>         description
>>           "A 32-bit number in the dotted quad format assigned to each
>>            router. This number uniquely identifies the router within an
>>            Autonomous System.";
>>       }
>>
>> My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th,
>> it makes sense to import its router-id
>
> <ALEX> This is only used in the example.  The point of the example is to
> show how the model can be extended, not to define something normative, hence
> I don't think there is a need to introduce a dependency here which would
> only be distracting.
> </ALEX>
Can you help me understand how this is an example?
Section 5

   module: ietf-l3-unicast-topology
     augment /nw:networks/nw:network/nw:network-types:
       +--rw l3-unicast-topology!
     augment /nw:networks/nw:network:
       +--rw l3-topology-attributes
          +--rw name?   string
          +--rw flag*   l3-flag-type
     augment /nw:networks/nw:network/nw:node:
       +--rw l3-node-attributes
          +--rw name?        inet:domain-name
          +--rw flag*        node-flag-type
          +--rw router-id*   inet:ip-address
          +--rw prefix* [prefix]
             +--rw prefix    inet:ip-prefix
             +--rw metric?   uint32
             +--rw flag*     prefix-flag-type

And section 6:

     grouping l3-node-attributes {
       description "L3 node scope attributes";
       container l3-node-attributes {
         description
           "Containing node attributes";
         leaf name {
           type inet:domain-name;
           description
             "Node name";
         }
         leaf-list flag {
           type node-flag-type;
           description
             "Node flags";
         }
         leaf-list router-id {
           type inet:ip-address;
           description
             "Router-id for the node";
         }
         list prefix {
           key "prefix";
           description
             "A list of prefixes along with their attributes";
           uses l3-prefix-attributes;
         }
       }
     }

A different view at
https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-l3-unicast-topology#