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

Hi,

"Alexander Clemm" <ludwig@clemm.org> wrote:
> Hi Benoit,
> 
> I am not sure I understand your comment?

I think the issue is that the leaf-list router-id should be of type
yang:dotted-quad, and not inet:ip-address.

> I was referring to the typedef
> router-id, which we define in example-ospf-topology.

There is no such typedef.  There's an area-id though.

/martin

We made many changes
> to make it clear that this is just an example, not a part of the actual
> model, reflected in the description, naming, removal of contact and revision
> information, etc.  
> 
> The tree diagram in section 5 is for the ietf-l3-unicast-topology module.
> It is not part of an example.  The same is true for the grouping
> l3-node-attributes.  It is part of the model.  
> 
> The example-ospf-topology model serves as an example as to how the model
> might be refined/extended for other topologies.  As stated: "This module is
> intended to serve as an example that illustrates how the general topology
> model can be refined across multiple levels."  The sentence at the top of
> the section "Extending the model - Example OSPF Topology - Model Overview"
> states (slightly rephrased with inserted ", in this case") to "The following
> model shows how the Layer 3 Unicast topology model can be extended, in this
> case to cover OSFP topologies."
> 
> Does this clarify or did you mean something else? 
> 
> Thanks
> --- Alex
> 
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise
> Sent: Thursday, December 14, 2017 3:33 AM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org;
> i2rs-chairs@ietf.org; shares@ndzh.com
> Subject: [i2rs] Benoit Claise's Discuss on
> draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS)
> 
> 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#
> 
> 
> 
> 
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
> 
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
> 