Subject: [Rtg-yang-coord] LIME connection-less draft-rtgyangdt-rtgwg-routing-types

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Nov 2016 12:08:31 +0900

draft-rtgyangdt-rtgwg-routing-types authors,

I see the following typedef in draft-ietf-lime-yang-connectionless-oam

      typedef IPv4-Multicast-Group-Address {
             type string {
              pattern '(2((2[4-9])|(3[0-9]))\.)'
                          +'(([0-9]|[1-9][0-9]|1[0-9][0-9]|'
                          +'2[0-4][0-9]|25[0-5])\.){2}'
                          +'([0-9]|[1-9][0-9]|1[0-9][0-9]'
                          +'|2[0-4][0-9]|25[0-5])';
             }
             description
               "The IPv4-Multicast-Group-Address type
                represents an IPv4 multicast address
                in dotted-quad notation.";
             reference "RFC4607 <https://tools.ietf.org/html/rfc4607>";
       } // typedef IPv4-Multicast-Group-Address
       typedef IPv6-Multicast-Group-Address {
             type string {
             pattern
                         '(((FF|ff)[0-9a-fA-F]{2}):)([0-9a-fA-F]'
                         +'{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?'
                         +'(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4]'
                         +'[0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|'
                         +'2[0-4][0-9]|[01]?[0-9]?[0-9])))';
             pattern
             '(([^:]+:){6}(([^:]+:[^:]+)|'
                         +'(.*\..*)))|((([^:]+:)*[^:]+)'
                         +'?::(([^:]+:)*[^:]+)?)';
              }
             description
                         "The IPv6-Multicast-Group-Address
                         type represents an IPv6 address in full,
                         mixed, shortened, and shortened-mixed
                         notation.";
             reference "RFC4291 <https://tools.ietf.org/html/rfc4291>  2.7.
             ietf-inet-types:ipv6-address";
       }
       typedef IP-Multicast-Group-Address {
             type union {
               type IPv4-Multicast-Group-Address;
               type IPv6-Multicast-Group-Address;
             }

             description
              "The IP-Multicast-Group-Address type
               represents an IP multicast address and
               is IP version neutral. The format of the
               textual representations implies the IP version.";
       } // typedef IP-Multicast-Group-Address

It's probably a good idea to introduce those typedefs in your draft, for 
everybody's interest.
Now, hopefully, your draft will be published very soon. We can't delay 
other doc publications.

Also, look at this new tool, developed during this hackathon (new tool, 
so bare with us): http://yangcatalog.org/yang-search/yang-search.php
You should do a couple of searches with specific keywords.
For example, I searched on "multicast" and typedef.
     Note: we get some hits from YANG modules generated from MIB. Not 
sure how useful that is.
We want to make sure there are no discrepancies in the typedef, and that 
the typedef definitions are not spread around in too many documents.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2016 07:39:38 +0100

Another option could be to reuse the definitions from ietf-inet-types
and to subtype them to constrain them to multicast addresses. Also
double check that you will never ever need a zone index.

/js

On Mon, Nov 14, 2016 at 12:08:31PM +0900, Benoit Claise wrote:
> Now, hopefully, your draft will be published very soon. We can't delay other
> doc publications.
> 
> Also, look at this new tool, developed during this hackathon (new tool, so
> bare with us): http://yangcatalog.org/yang-search/yang-search.php
>     Note: we get some hits from YANG modules generated from MIB. Not sure
> how useful that is.
> We want to make sure there are no discrepancies in the typedef, and that the
> typedef definitions are not spread around in too many documents.
> 
> Regards, Benoit
> 
> 

> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

-- 
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/>

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 14 Nov 2016 06:54:22 +0000

I hesitated to include these types because I thought that inet-types could be a better place for them. Do we now agree to cover them in routing-types?

Thanks,

- Xufeng

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Monday, November 14, 2016 1:40 AM
> To: [email-masked]
> Cc: Benoit Claise <[email-masked]>; [email-masked]; <[email-masked]> <rtg-
> [email-masked]>; [email-masked]; Joe Clarke (jclarke)
> <[email-masked]>
> Subject: Re: [Rtg-yang-coord] LIME connection-less draft-rtgyangdt-rtgwg-
> routing-types
> 
> Another option could be to reuse the definitions from ietf-inet-types and to
> subtype them to constrain them to multicast addresses. Also double check that
> you will never ever need a zone index.
> 
> /js
> 
> > It's probably a good idea to introduce those typedefs in your draft,
> > for everybody's interest.
> > Also, look at this new tool, developed during this hackathon (new
> > tool, so bare with us):
> > http://yangcatalog.org/yang-search/yang-search.php
> > We want to make sure there are no discrepancies in the typedef, and
> > that the typedef definitions are not spread around in too many documents.
> >
> > Regards, Benoit
> >
> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2016 08:15:53 +0100

I would say that generic types for Internet addresses and related
things should go inet-types. Other generally useful derived should go
into ietf-yang-types. It will at the end be a matter of consensus what
goes where.

/js