Re: [netmod] Key selection for next hop list in RFC8349

[Qin Wu]

Thank Acee for clarification, it helps.

-Qin
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2020年7月13日 23:24
收件人: Qin Wu 
抄送: NetMod WG 
主题: Re: Key selection for next hop list in RFC8349

Hi Qin,

From: Qin Wu mailto:bill...@huawei.com>>
Date: Friday, July 10, 2020 at 2:59 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Key selection for next hop list in RFC8349

Hi, Acee, Lada, Yingzhen:
In RFC8349, a string type index parameter is defined as the key for next hop 
list, this index has no semantics and can be used as unique ID for each next 
hop entry.
I am wondering why not select next hop address as the key instead of using no 
semantic meaning index? What’s the rationale behind, when we will use index as 
the key, when we will use next hop address as the key?

The model was designed either IPv4 or IPv6 without a requirement on either 
being present. This could not have been done with the next-hop address and 
outgoing interface as the list key.

Hope this helps,
Acee

Thanks in advance.
The following YANG data model snippets is for reference.
 grouping next-hop-content {
   description
 "Generic parameters of next hops in static routes.";
   choice next-hop-options {
 mandatory true;
 description
   "Options for next hops in static routes.

It is expected that further cases will be added through
augments from other modules.";
 case next-hop-list {
   container next-hop-list {
 description
   "Container for multiple next hops.";
 list next-hop {
   key "index";
   description
 "An entry in a next-hop list.
  Modules for address families MUST augment this list
  with a leaf containing a next-hop address of that
  address family.";
   leaf index {
 type string;
 description
   "A user-specified identifier utilized to uniquely
reference the next-hop entry in the next-hop list.
The value of this index has no semantic meaning
other than for referencing the entry.";
   }
   leaf outgoing-interface {
 type if:interface-ref;
 description
   "Name of the outgoing interface.";
   }
 }
   }
 }
   }
 }

-Qin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Qin Wu]

Thanks Chris and Jurgen for clarification,
Chris, I am not sure I catch what you said. Does adding new typedef for 
longtitude and latitude do harm to draft-ietf-netmod-geo-location-05?
Type in my opinion is  more reusable building block.

-Qin
发件人: Christian Hopps [mailto:cho...@chopps.org]
发送时间: 2020年7月31日 0:38
收件人: Juergen Schoenwaelder 
抄送: Christian Hopps ; Qin Wu ; 
netmod@ietf.org; netmod-cha...@ietf.org
主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, 
yang:country-code

I received specific external feedback from the geo experts to just use a number 
instead of a type. I think they may have been thinking that it would be easier 
to redefine the values meaning for different systems.

Thanks,
Chris.


On Jul 30, 2020, at 12:23 PM, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:

Looking in the I-Ds, I see that draft-ietf-netmod-geo-location-05
defines a grouping geo-location. draft-ietf-teas-yang-te-topo-22
has:

 +--ro geolocation
+--ro altitude?int64
+--ro latitude?geographic-coordinate-degree
+--ro longitude?   geographic-coordinate-degree

You might simply use the grouping here that comes out of
draft-ietf-netmod-geo-location-05 - but then the grouping is
also a bit more complex than what you have.

Unfortunately, draft-ietf-netmod-geo-location-05 does not define
helper types. The latitude and longitude leafs are simply decimal64s
with all details spelled out inline:

leaf latitude {
  type decimal64 {
fraction-digits 16;
  }
  units "decimal degrees";
  description
"The latitude value on the astronomical body. The
 definition and precision of this measurement is
 indicated by the reference-frame value.";
}
leaf longitude {
  type decimal64 {
fraction-digits 16;
  }
  units "decimal degrees";
  description
"The longitude value on the astronomical body. The
 definition and precision of this measurement is
 indicated by the reference-frame.";
}

The teas document has

typedef geographic-coordinate-degree {
type decimal64 {
  fraction-digits 8;
}
description
  "Decimal degree (DD) used to express latitude and longitude
   geographic coordinates.";
}

leaf latitude {
  type geographic-coordinate-degree {
range "-90..90";
  }
  description
"Relative position north or south on the Earth's surface.";
}

leaf longitude {
  type geographic-coordinate-degree {
range "-180..180";
  }
  description
"Angular distance east or west on the Earth's surface.";
}

Note also the differences in the precision. Obviously,
draft-ietf-netmod-geo-location-05 could have defined
helper types like

   typedef latitude {
 type decimal64 {
 fraction-digits 16;
 }
 units "decimal degrees";
 description
"The latitude value on the astronomical body.";
   }

   typdef longitude {
 type decimal64 {
 fraction-digits 16;
 }
 units "decimal degrees";
 description
   "The longitude value on the astronomical body. The
definition and precision of this measurement is
indicated by the reference-frame.";
   }

and a bunch more and used them to define the leafs. These types could
then have been reused in situations where the grouping in all its
details is not needed.

I am not entirely sure where draft-ietf-netmod-geo-location-05 is in
the WG process, the datatracker says "In WG Last Call, Revised I-D
Needed - Issue raised by WGLC" - so perhaps there is a chance to get
the inline type definitions factored out so that they can be reused.

I think this is something where the input from Chris Hopps and the
NETMOD chairs is important to determine the path forward. Since we
have an ietf-geo-location module, I would prefer to have common types
for location information defined there and not in yang-types.

/js

On Thu, Jul 30, 2020 at 04:02:51PM +0200, Juergen Schoenwaelder wrote:

But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated
or you need to use a grouping. I think we should not have overlapping
work in different documents.

/js

On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:

That is a good option, but draft-ietf-netmod-geo-location-05 only define 
grouping, there is typedef for longitude and latitude, altitude.

-Qin
-邮件原件-
发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
发送时间: 2020年7月30日 21:32
收件人: Qin Wu mailto:bill...@huawei.com>>
抄送: netmod@ietf.org
主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, 
yang:country-code

But there is 

Re: [netmod] rfc6991bis: loopback addresses

[Qin Wu]

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2020年7月31日 5:06
收件人: Kent Watsen ; Juergen Schoenwaelder 

抄送: Carlos Pignataro (cpignata) ; netmod@ietf.org
主题: Re: [netmod] rfc6991bis: loopback addresses

Hi Kent,

On 7/30/20, 4:55 PM, "netmod on behalf of Kent Watsen" 
 wrote:


> Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang.
> With that, your request is relatively clear now

Looking at draft-nainar-mpls-lsp-ping-yang, the proposal is a “typedef” 
that constrains inet:ipv[46]-address so that it can only contain loopback 
address values.


> and the question the WG
> needs to answer is whether these types are common enough to warrant being
> part of inet-types, i.e., are there any other places where these types
> may be useful?

I don’t think so, but I’m not a routing person.

I wouldn't think that an internal loopback address would be widely used. In 
fact, I checked our Cisco native models for IOS-XE and there is no such 
definition. 

[Qin]: I am not sure we are talking about loopback type or loopback address
See section 2.4 in draft-ietf-netmod-intf-ext-yang-10, 3 type loopbacks are 
defined:
1.Internal loopback
2.Line loopback
3.Loopback Connector
3 types loopback can be classified into local loopback and remote loopback.
I am not sure they are common, but we have some support for this. 

Thanks,
Acee


> /js

K.  // contributor
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: loopback addresses

[Acee Lindem (acee)]

Hi Kent,

On 7/30/20, 4:55 PM, "netmod on behalf of Kent Watsen" 
 wrote:


> Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang.
> With that, your request is relatively clear now

Looking at draft-nainar-mpls-lsp-ping-yang, the proposal is a “typedef” 
that constrains inet:ipv[46]-address so that it can only contain loopback 
address values.


> and the question the WG
> needs to answer is whether these types are common enough to warrant being
> part of inet-types, i.e., are there any other places where these types
> may be useful?

I don’t think so, but I’m not a routing person.

I wouldn't think that an internal loopback address would be widely used. In 
fact, I checked our Cisco native models for IOS-XE and there is no such 
definition. 

Thanks,
Acee


> /js

K.  // contributor
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: loopback addresses

[Kent Watsen]

> Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang.
> With that, your request is relatively clear now

Looking at draft-nainar-mpls-lsp-ping-yang, the proposal is a “typedef” that 
constrains inet:ipv[46]-address so that it can only contain loopback address 
values.


> and the question the WG
> needs to answer is whether these types are common enough to warrant being
> part of inet-types, i.e., are there any other places where these types
> may be useful?

I don’t think so, but I’m not a routing person.


> /js

K.  // contributor
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Reshad Rahman (rrahman)]

+1



On 2020-07-30, 10:04 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated
or you need to use a grouping. I think we should not have overlapping
work in different documents.

/js

On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:
> That is a good option, but draft-ietf-netmod-geo-location-05 only define 
grouping, there is typedef for longitude and latitude, altitude. 
> 
> -Qin
> -邮件原件-
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> 发送时间: 2020年7月30日 21:32
> 收件人: Qin Wu 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
yang:postal-code, yang:country-code
> 
> But there is draft-ietf-netmod-geo-location-05... What about using the 
types defined in there?
> 
> /js
> 
> On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
> > See geolocation definition in draft-ietf-teas-yang-te-topo-22 which 
defines longitude and latitude, altitude.
> > I know it is beneficial for future document to import these types from 
rfc6991bis instead of from te topo model.
> > 
> > -Qin
> > -邮件原件-
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> > 发送时间: 2020年7月18日 3:16
> > 收件人: netmod@ietf.org
> > 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
> > yang:postal-code, yang:country-code
> > 
> >   - It was suggested to add types for longitude, latitude, postal
> > code, country-code. Do we go there or do we leave these for other
> > modules to define? It seems such definitions should go into
> > draft-ietf-netmod-geo-location.
> > 
> >   - Geo location is covered by draft-ietf-netmod-geo-location
> > (so do nothing).
> > 
> >   - For country codes, there is ISO 3166, which defines two-letter,
> > three-letter, and numeric country codes. I assume people wanted
> > two-letter codes (as used in the DNS), i.e. they want DE and not
> > DEU. But note that it is GB and not UK, i.e., what we commonly
> > use in the DNS may not be exactly ISO 3166. (The devil is always
> > in the details.)
> > 
> >   - For postal codes, it is unclear what the requirements are or what
> > a proper definition for postal codes is. It is not entirely clear
> > what the authoritative definition of the format of postal codes
> > is, perhaps the Universal Postal Union.
> > 
> >   - Options: (i) do nothing or (ii) add a country code definition
> > only or (iii) add both a country code definition and a postal
> > code definition (which might be to some extend vague)
> > 
> >   - Proposal: do nothing
> >   
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Christian Hopps]

I received specific external feedback from the geo experts to just use a number 
instead of a type. I think they may have been thinking that it would be easier 
to redefine the values meaning for different systems.

Thanks,
Chris.

> On Jul 30, 2020, at 12:23 PM, Juergen Schoenwaelder 
>  wrote:
> 
> Looking in the I-Ds, I see that draft-ietf-netmod-geo-location-05
> defines a grouping geo-location. draft-ietf-teas-yang-te-topo-22
> has:
> 
>  +--ro geolocation
> +--ro altitude?int64
> +--ro latitude?geographic-coordinate-degree
> +--ro longitude?   geographic-coordinate-degree
> 
> You might simply use the grouping here that comes out of
> draft-ietf-netmod-geo-location-05 - but then the grouping is
> also a bit more complex than what you have.
> 
> Unfortunately, draft-ietf-netmod-geo-location-05 does not define
> helper types. The latitude and longitude leafs are simply decimal64s
> with all details spelled out inline:
> 
> leaf latitude {
>   type decimal64 {
> fraction-digits 16;
>   }
>   units "decimal degrees";
>   description
> "The latitude value on the astronomical body. The
>  definition and precision of this measurement is
>  indicated by the reference-frame value.";
> }
> leaf longitude {
>   type decimal64 {
> fraction-digits 16;
>   }
>   units "decimal degrees";
>   description
> "The longitude value on the astronomical body. The
>  definition and precision of this measurement is
>  indicated by the reference-frame.";
> }
> 
> The teas document has
> 
> typedef geographic-coordinate-degree {
> type decimal64 {
>   fraction-digits 8;
> }
> description
>   "Decimal degree (DD) used to express latitude and longitude
>geographic coordinates.";
> }
> 
> leaf latitude {
>   type geographic-coordinate-degree {
> range "-90..90";
>   }
>   description
> "Relative position north or south on the Earth's surface.";
> }
> 
> leaf longitude {
>   type geographic-coordinate-degree {
> range "-180..180";
>   }
>   description
> "Angular distance east or west on the Earth's surface.";
> }
> 
> Note also the differences in the precision. Obviously,
> draft-ietf-netmod-geo-location-05 could have defined
> helper types like
> 
>typedef latitude {
>  type decimal64 {
>  fraction-digits 16;
>  }
>  units "decimal degrees";
>  description
> "The latitude value on the astronomical body.";
>}
> 
>typdef longitude {
>  type decimal64 {
>  fraction-digits 16;
>  }
>  units "decimal degrees";
>  description
>"The longitude value on the astronomical body. The
> definition and precision of this measurement is
> indicated by the reference-frame.";
>}
> 
> and a bunch more and used them to define the leafs. These types could
> then have been reused in situations where the grouping in all its
> details is not needed.
> 
> I am not entirely sure where draft-ietf-netmod-geo-location-05 is in
> the WG process, the datatracker says "In WG Last Call, Revised I-D
> Needed - Issue raised by WGLC" - so perhaps there is a chance to get
> the inline type definitions factored out so that they can be reused.
> 
> I think this is something where the input from Chris Hopps and the
> NETMOD chairs is important to determine the path forward. Since we
> have an ietf-geo-location module, I would prefer to have common types
> for location information defined there and not in yang-types.
> 
> /js
> 
> On Thu, Jul 30, 2020 at 04:02:51PM +0200, Juergen Schoenwaelder wrote:
>> But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated
>> or you need to use a grouping. I think we should not have overlapping
>> work in different documents.
>> 
>> /js
>> 
>> On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:
>>> That is a good option, but draft-ietf-netmod-geo-location-05 only define 
>>> grouping, there is typedef for longitude and latitude, altitude.
>>> 
>>> -Qin
>>> -邮件原件-
>>> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
>>> 发送时间: 2020年7月30日 21:32
>>> 收件人: Qin Wu 
>>> 抄送: netmod@ietf.org
>>> 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
>>> yang:postal-code, yang:country-code
>>> 
>>> But there is draft-ietf-netmod-geo-location-05... What about using the 
>>> types defined in there?
>>> 
>>> /js
>>> 
>>> On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
 See geolocation definition in draft-ietf-teas-yang-te-topo-22 which 
 defines longitude and latitude, altitude.
 I know it is beneficial for future document to 

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Juergen Schoenwaelder]

Looking in the I-Ds, I see that draft-ietf-netmod-geo-location-05
defines a grouping geo-location. draft-ietf-teas-yang-te-topo-22
has:

  +--ro geolocation
 +--ro altitude?int64
 +--ro latitude?geographic-coordinate-degree
 +--ro longitude?   geographic-coordinate-degree

You might simply use the grouping here that comes out of
draft-ietf-netmod-geo-location-05 - but then the grouping is
also a bit more complex than what you have.

Unfortunately, draft-ietf-netmod-geo-location-05 does not define
helper types. The latitude and longitude leafs are simply decimal64s
with all details spelled out inline:

 leaf latitude {
   type decimal64 {
 fraction-digits 16;
   }
   units "decimal degrees";
   description
 "The latitude value on the astronomical body. The
  definition and precision of this measurement is
  indicated by the reference-frame value.";
 }
 leaf longitude {
   type decimal64 {
 fraction-digits 16;
   }
   units "decimal degrees";
   description
 "The longitude value on the astronomical body. The
  definition and precision of this measurement is
  indicated by the reference-frame.";
 }

The teas document has

 typedef geographic-coordinate-degree {
 type decimal64 {
   fraction-digits 8;
 }
 description
   "Decimal degree (DD) used to express latitude and longitude
geographic coordinates.";
 }
 
 leaf latitude {
   type geographic-coordinate-degree {
 range "-90..90";
   }
   description
 "Relative position north or south on the Earth's surface.";
 }

 leaf longitude {
   type geographic-coordinate-degree {
 range "-180..180";
   }
   description
 "Angular distance east or west on the Earth's surface.";
 }

Note also the differences in the precision. Obviously,
draft-ietf-netmod-geo-location-05 could have defined
helper types like

typedef latitude {
  type decimal64 {
  fraction-digits 16;
  }
  units "decimal degrees";
  description
 "The latitude value on the astronomical body.";
}

typdef longitude {
  type decimal64 {
  fraction-digits 16;
  }
  units "decimal degrees";
  description
"The longitude value on the astronomical body. The
 definition and precision of this measurement is
 indicated by the reference-frame.";
}

and a bunch more and used them to define the leafs. These types could
then have been reused in situations where the grouping in all its
details is not needed.

I am not entirely sure where draft-ietf-netmod-geo-location-05 is in
the WG process, the datatracker says "In WG Last Call, Revised I-D
Needed - Issue raised by WGLC" - so perhaps there is a chance to get
the inline type definitions factored out so that they can be reused.

I think this is something where the input from Chris Hopps and the
NETMOD chairs is important to determine the path forward. Since we
have an ietf-geo-location module, I would prefer to have common types
for location information defined there and not in yang-types.

/js

On Thu, Jul 30, 2020 at 04:02:51PM +0200, Juergen Schoenwaelder wrote:
> But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated
> or you need to use a grouping. I think we should not have overlapping
> work in different documents.
> 
> /js
> 
> On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:
> > That is a good option, but draft-ietf-netmod-geo-location-05 only define 
> > grouping, there is typedef for longitude and latitude, altitude. 
> > 
> > -Qin
> > -邮件原件-
> > 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> > 发送时间: 2020年7月30日 21:32
> > 收件人: Qin Wu 
> > 抄送: netmod@ietf.org
> > 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
> > yang:postal-code, yang:country-code
> > 
> > But there is draft-ietf-netmod-geo-location-05... What about using the 
> > types defined in there?
> > 
> > /js
> > 
> > On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
> > > See geolocation definition in draft-ietf-teas-yang-te-topo-22 which 
> > > defines longitude and latitude, altitude.
> > > I know it is beneficial for future document to import these types from 
> > > rfc6991bis instead of from te topo model.
> > > 
> > > -Qin
> > > -邮件原件-
> > > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> > > 发送时间: 2020年7月18日 3:16
> > > 收件人: netmod@ietf.org
> > > 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
> > > yang:postal-code, yang:country-code
> > > 
> > >   - It was suggested to add types for longitude, latitude, postal
> > > code, 

Re: [netmod] rfc6991bis: yang:percentage

[Juergen Schoenwaelder]

On Thu, Jul 30, 2020 at 04:48:41PM +0100, William Lupton wrote:
> except that percent doesn't really seem like a routing-specific data type!
> 
> (perhaps the "right" thing to do is to deprecate, and eventually obsolete,
> the routing one and define it in a core netmod module?)
>

Yes, the percentage type is not not routing specific. But if we choose
to go down this route, we likely have to move more definitions, I also
see timeticks64 and uint24 in RFC 8294 that don't seem to be routing
specific. Since RFC 8294 comes from a different WG in a different IETF
"area", deprecation requires some internal communication and
collaboration (but not deprecating also won't hurt much for these
fairly simple types).

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:percentage

[William Lupton]

except that percent doesn't really seem like a routing-specific data type!

(perhaps the "right" thing to do is to deprecate, and eventually obsolete,
the routing one and define it in a core netmod module?)

On Thu, 30 Jul 2020 at 14:59, Benoit Claise  wrote:

> On 30/07/2020 15:25, Juergen Schoenwaelder wrote:
>
> On Thu, Jul 30, 2020 at 02:58:22PM +0200, Benoit Claise wrote:
>
> On 20/07/2020 11:19, Ladislav Lhotka wrote:
>
> Juergen Schoenwaelder  
>  writes:
>
>
>- Percentages are frequently used in YANG models but usages differ a
>  lot in precision and range. It is not clear what the proper
>  generic definition of a percentage type would be and whether it is
>  worth having it.
>
>  RFC 7950 example:
>
>   typedef percent { type uint8 { range "0 .. 100"; } }
>
>  RFC 8294:
>
>   typedef percentage { type uint8 { range "0..100"; } }
>
>  I-Ds:
>   typedef percentage { type decimal64 { fraction-digits 5; } }
>   typedef percentile { type decimal64 { fraction-digits 2; } }
>
>  The yang catalogue seems to be down. :-(
>
>- Proposal: do not add a percentage type since it is trivial to
>  define a context specific percentage type that matches range and
>  precision requirements (and there is already a definition in RFC
>  8294 for those who need exactly that definition).
>
> I agree with this proposal. It is also possible to use
>
> units percent;
>
> where necessary.
>
> On the other hand, when I look at the numerous percent/percentage
> occurrences in YANG model, it doesn't hurt to define that typedef.
> https://yangcatalog.org/yang-search/ => search on "node name" and typedef
> only
> We can find 56 entries from IETF, IEEE, BBF, OC, MEF, vendors
> Most of them points to:
>
>*typedef*  percent {
>   *type*  uint8 {
>   *range*  "0 .. 100";
>
>   }
>}
>
>
> But that one is already defined in RFC 8294 in ietf-routing-types.
> Does it make sense to define it again in yang-types?
>
>
>
> My point was taht it makes sense to group typedefs in a few documents:
> RFC6991, 6991bis (hopefully published soon) and  my bad,  I forgot that
> RFC 8294 is "Common YANG *data types* for the routing area"
>
> So we're good. Thanks.
>
> Regards, Benoit
>
> /js
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: loopback addresses

[Nagendra Kumar Nainar (naikumar)]

Hi Juergen,

Thank you for the response.

I am not aware of any other use cases that leverage (Internal host) loopback 
address. I will wait for the WG to decide if it can be included as part of 
inet-types. If not, we will stick with the typedef defined in 
draft-nainar-mpls-lsp-ping-yang.

Thanks,
Nagendra

On 7/30/20, 9:47 AM, "Juergen Schoenwaelder" 
 wrote:

Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang.
With that, your request is relatively clear now and the question the WG
needs to answer is whether these types are common enough to warrant being
part of inet-types, i.e., are there any other places where these types
may be useful?

/js

On Thu, Jul 30, 2020 at 01:19:11PM +, Nagendra Kumar Nainar (naikumar) 
wrote:
> Hi,
> 
> As Reshad mentioned, RFC8029 uses internal host loopback address 
(127..0.0.0/8 range as defined in section 4.2.2.11 of RFC1812). The YANG module 
for LSP Ping (RFC8029) defined in draft-nainar-mpls-lsp-ping-yang is using this 
address and so we felt it will be good to have the same included in the right 
document.
> 
> Thanks,
> Nagendra
> 
> On 7/20/20, 2:54 PM, "Reshad Rahman (rrahman)"  wrote:
> 
> Hi,
> 
> I think what you're referring to is the use of "loopback interfaces". 
The loopback addresses Juergen was referring to do not belong to loopback 
interfaces. 
> 
> Regards,
> Reshad.
> 
> 
> On 2020-07-20, 11:30 AM, "tom petch"  wrote:
> 
> From: Reshad Rahman (rrahman) 
> Sent: 20 July 2020 14:39
> 
> I don't understand the comment "...implementation choice of one 
manufacturer."
> 
> 
> Go back to the early specifications of IPv4 routers and routing 
protocols, which are still the ones we use today, and loopback was a state into 
which an interface could be put, with a loop back in hardware or software, 
often used for testing.  A router had a router id, a 32 bit number with no 
syntax.  One major manufacturer conflated parts of this and created a virtual 
address  or addresses which could be used to send and receive packets for the 
router, as opposed to an interface on the router, which had no physical 
manifestation; fine until they called it the loopback address(es) which, sadly, 
caught on and many people, included those writing IETF I-D think that the 
router id can only be such a routable address.  Some even think that there can 
only be one such address on a box, as opposed to one for network management, 
one for the control plane and so on.  Not so.
> 
> Tom Petch.
> 
> As for the details, see 
https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00
> 
> Regards,
> Reshad.
> 
> 
> On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
 wrote:
> 
> I am not a fan of loopback seeing it as the implementation 
choice of one manufacturer.  On the other hand, the IETF has defined 
documentation addresses which many if not most writers of examples for YANG 
modules seem unaware of so if we add anything, I would add those.
> 
> Tom Petch
> 
> From: netmod  on behalf of Juergen 
Schoenwaelder 
> Sent: 17 July 2020 20:25
> 
>   - There was a request to add types for loopback addresses
> (127.0.0.0/8 and ::1/128).
> 
>   - This is related to an effort to define a YANG module for 
MPLS LSP
> Ping (RFC 8029) but the details are unclear, i.e., what 
is exactly
> needed and how such a type will be used and whether there 
is a
> common need for types for loopback addresses.
> 
>   - Proposal: do not add such types at this point in time
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen 
| Germany
> Fax:   +49 421 200 3103 

> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Qin Wu]

Works for me, thanks.
-邮件原件-
发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
发送时间: 2020年7月30日 22:03
收件人: Qin Wu 
抄送: netmod@ietf.org
主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, 
yang:country-code

But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated or you 
need to use a grouping. I think we should not have overlapping work in 
different documents.

/js

On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:
> That is a good option, but draft-ietf-netmod-geo-location-05 only define 
> grouping, there is typedef for longitude and latitude, altitude. 
> 
> -Qin
> -邮件原件-
> 发件人: Juergen Schoenwaelder 
> [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2020年7月30日 21:32
> 收件人: Qin Wu 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
> yang:postal-code, yang:country-code
> 
> But there is draft-ietf-netmod-geo-location-05... What about using the types 
> defined in there?
> 
> /js
> 
> On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
> > See geolocation definition in draft-ietf-teas-yang-te-topo-22 which defines 
> > longitude and latitude, altitude.
> > I know it is beneficial for future document to import these types from 
> > rfc6991bis instead of from te topo model.
> > 
> > -Qin
> > -邮件原件-
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen 
> > Schoenwaelder
> > 发送时间: 2020年7月18日 3:16
> > 收件人: netmod@ietf.org
> > 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
> > yang:postal-code, yang:country-code
> > 
> >   - It was suggested to add types for longitude, latitude, postal
> > code, country-code. Do we go there or do we leave these for other
> > modules to define? It seems such definitions should go into
> > draft-ietf-netmod-geo-location.
> > 
> >   - Geo location is covered by draft-ietf-netmod-geo-location
> > (so do nothing).
> > 
> >   - For country codes, there is ISO 3166, which defines two-letter,
> > three-letter, and numeric country codes. I assume people wanted
> > two-letter codes (as used in the DNS), i.e. they want DE and not
> > DEU. But note that it is GB and not UK, i.e., what we commonly
> > use in the DNS may not be exactly ISO 3166. (The devil is always
> > in the details.)
> > 
> >   - For postal codes, it is unclear what the requirements are or what
> > a proper definition for postal codes is. It is not entirely clear
> > what the authoritative definition of the format of postal codes
> > is, perhaps the Universal Postal Union.
> > 
> >   - Options: (i) do nothing or (ii) add a country code definition
> > only or (iii) add both a country code definition and a postal
> > code definition (which might be to some extend vague)
> > 
> >   - Proposal: do nothing
> >   
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: inet:host

[Ladislav Lhotka]

On 30. 07. 20 15:44, Juergen Schoenwaelder wrote:
> On Wed, Jul 29, 2020 at 01:55:38PM +0200, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>>
 If we want to allow non-ASCII names, then it would IMO be safer to use a
 type that expects straight Unicode for lexical representation and leave
 it to the implementations to convert to Punycode where necessary, e.g.
 when querying DNS.
>>>
>>> Perhaps. But I am not sure this is the time to fix this or how this
>>> can be done in a backwards compatible way. At least this likely can't
>>> be done by disallowing ACE. It may be possible to add an additional
>>> member to the inet:host union that catches internationalized names.
>>
>> I think it would be better to have an extra set of parallel definitions such 
>> as idn-domain-name, or perhaps u-domain-name.
>>
> 
> So if we define idn-domain-name, what do we do with your hostname?
> Have hostname derived from domain-name (as discussed before) with
> 
>  typedef host {
>type union {
>  type inet:ip-address;
>  type inet:host-name;
>  }
> 
> and we add
> 
>  typedef idn-host {
>type union {
>  type inet:ip-address;
>  type inet:idn-hostname;
>  }
> 
> and then YANG module writers can opt-in to use the new definition if
> they want idn host names without requiring ACE encoding?

Yes, that was my idea. If IDN becomes widespread (ever), the "idn-host"
version would be much easier to use.

Lada

> 
>> Lada
>>
>>> Since this would be enlarging the value space, I believe this is
>>> inline with the spirit of section 11 of RFC 7950. Removing the ACE
>>> names, however, restricts the value space and hence seem to contradict
>>> section 11 of RFC 7950. (The explicit removal of underscore and single
>>> letter hostnames may be considered a clarification since we have other
>>> RFCs stating these constraints.)
>>>
>>> /js
>>>
>>> -- 
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 
>>
>> -- 
>> Ladislav Lhotka 
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
> 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Juergen Schoenwaelder]

But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated
or you need to use a grouping. I think we should not have overlapping
work in different documents.

/js

On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:
> That is a good option, but draft-ietf-netmod-geo-location-05 only define 
> grouping, there is typedef for longitude and latitude, altitude. 
> 
> -Qin
> -邮件原件-
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> 发送时间: 2020年7月30日 21:32
> 收件人: Qin Wu 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, 
> yang:country-code
> 
> But there is draft-ietf-netmod-geo-location-05... What about using the types 
> defined in there?
> 
> /js
> 
> On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
> > See geolocation definition in draft-ietf-teas-yang-te-topo-22 which defines 
> > longitude and latitude, altitude.
> > I know it is beneficial for future document to import these types from 
> > rfc6991bis instead of from te topo model.
> > 
> > -Qin
> > -邮件原件-
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> > 发送时间: 2020年7月18日 3:16
> > 收件人: netmod@ietf.org
> > 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
> > yang:postal-code, yang:country-code
> > 
> >   - It was suggested to add types for longitude, latitude, postal
> > code, country-code. Do we go there or do we leave these for other
> > modules to define? It seems such definitions should go into
> > draft-ietf-netmod-geo-location.
> > 
> >   - Geo location is covered by draft-ietf-netmod-geo-location
> > (so do nothing).
> > 
> >   - For country codes, there is ISO 3166, which defines two-letter,
> > three-letter, and numeric country codes. I assume people wanted
> > two-letter codes (as used in the DNS), i.e. they want DE and not
> > DEU. But note that it is GB and not UK, i.e., what we commonly
> > use in the DNS may not be exactly ISO 3166. (The devil is always
> > in the details.)
> > 
> >   - For postal codes, it is unclear what the requirements are or what
> > a proper definition for postal codes is. It is not entirely clear
> > what the authoritative definition of the format of postal codes
> > is, perhaps the Universal Postal Union.
> > 
> >   - Options: (i) do nothing or (ii) add a country code definition
> > only or (iii) add both a country code definition and a postal
> > code definition (which might be to some extend vague)
> > 
> >   - Proposal: do nothing
> >   
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:percentage

[Benoit Claise]

On 30/07/2020 15:25, Juergen Schoenwaelder wrote:

On Thu, Jul 30, 2020 at 02:58:22PM +0200, Benoit Claise wrote:

On 20/07/2020 11:19, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


- Percentages are frequently used in YANG models but usages differ a
  lot in precision and range. It is not clear what the proper
  generic definition of a percentage type would be and whether it is
  worth having it.

  RFC 7950 example:

   typedef percent { type uint8 { range "0 .. 100"; } }

  RFC 8294:

   typedef percentage { type uint8 { range "0..100"; } }

  I-Ds:
   typedef percentage { type decimal64 { fraction-digits 5; } }
   typedef percentile { type decimal64 { fraction-digits 2; } }

  The yang catalogue seems to be down. :-(

- Proposal: do not add a percentage type since it is trivial to
  define a context specific percentage type that matches range and
  precision requirements (and there is already a definition in RFC
  8294 for those who need exactly that definition).

I agree with this proposal. It is also possible to use

 units percent;

where necessary.

On the other hand, when I look at the numerous percent/percentage
occurrences in YANG model, it doesn't hurt to define that typedef.

https://yangcatalog.org/yang-search/ => search on "node name" and typedef
only
We can find 56 entries from IETF, IEEE, BBF, OC, MEF, vendors
Most of them points to:

*typedef*  percent {
*type*  uint8 {
*range*  "0 .. 100";

}
}


But that one is already defined in RFC 8294 in ietf-routing-types.
Does it make sense to define it again in yang-types?



My point was taht it makes sense to group typedefs in a few documents: 
RFC6991, 6991bis (hopefully published soon) and  my bad,  I forgot 
that RFC 8294 is "Common YANG _data types_ for the routing area"


So we're good. Thanks.

Regards, Benoit



/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Qin Wu]

That is a good option, but draft-ietf-netmod-geo-location-05 only define 
grouping, there is typedef for longitude and latitude, altitude. 

-Qin
-邮件原件-
发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
发送时间: 2020年7月30日 21:32
收件人: Qin Wu 
抄送: netmod@ietf.org
主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, 
yang:country-code

But there is draft-ietf-netmod-geo-location-05... What about using the types 
defined in there?

/js

On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
> See geolocation definition in draft-ietf-teas-yang-te-topo-22 which defines 
> longitude and latitude, altitude.
> I know it is beneficial for future document to import these types from 
> rfc6991bis instead of from te topo model.
> 
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> 发送时间: 2020年7月18日 3:16
> 收件人: netmod@ietf.org
> 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
> yang:postal-code, yang:country-code
> 
>   - It was suggested to add types for longitude, latitude, postal
> code, country-code. Do we go there or do we leave these for other
> modules to define? It seems such definitions should go into
> draft-ietf-netmod-geo-location.
> 
>   - Geo location is covered by draft-ietf-netmod-geo-location
> (so do nothing).
> 
>   - For country codes, there is ISO 3166, which defines two-letter,
> three-letter, and numeric country codes. I assume people wanted
> two-letter codes (as used in the DNS), i.e. they want DE and not
> DEU. But note that it is GB and not UK, i.e., what we commonly
> use in the DNS may not be exactly ISO 3166. (The devil is always
> in the details.)
> 
>   - For postal codes, it is unclear what the requirements are or what
> a proper definition for postal codes is. It is not entirely clear
> what the authoritative definition of the format of postal codes
> is, perhaps the Universal Postal Union.
> 
>   - Options: (i) do nothing or (ii) add a country code definition
> only or (iii) add both a country code definition and a postal
> code definition (which might be to some extend vague)
> 
>   - Proposal: do nothing
>   
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: loopback addresses

[Juergen Schoenwaelder]

Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang.
With that, your request is relatively clear now and the question the WG
needs to answer is whether these types are common enough to warrant being
part of inet-types, i.e., are there any other places where these types
may be useful?

/js

On Thu, Jul 30, 2020 at 01:19:11PM +, Nagendra Kumar Nainar (naikumar) 
wrote:
> Hi,
> 
> As Reshad mentioned, RFC8029 uses internal host loopback address 
> (127..0.0.0/8 range as defined in section 4.2.2.11 of RFC1812). The YANG 
> module for LSP Ping (RFC8029) defined in draft-nainar-mpls-lsp-ping-yang is 
> using this address and so we felt it will be good to have the same included 
> in the right document.
> 
> Thanks,
> Nagendra
> 
> On 7/20/20, 2:54 PM, "Reshad Rahman (rrahman)"  wrote:
> 
> Hi,
> 
> I think what you're referring to is the use of "loopback interfaces". The 
> loopback addresses Juergen was referring to do not belong to loopback 
> interfaces. 
> 
> Regards,
> Reshad.
> 
> 
> On 2020-07-20, 11:30 AM, "tom petch"  wrote:
> 
> From: Reshad Rahman (rrahman) 
> Sent: 20 July 2020 14:39
> 
> I don't understand the comment "...implementation choice of one 
> manufacturer."
> 
> 
> Go back to the early specifications of IPv4 routers and routing 
> protocols, which are still the ones we use today, and loopback was a state 
> into which an interface could be put, with a loop back in hardware or 
> software, often used for testing.  A router had a router id, a 32 bit number 
> with no syntax.  One major manufacturer conflated parts of this and created a 
> virtual address  or addresses which could be used to send and receive packets 
> for the router, as opposed to an interface on the router, which had no 
> physical manifestation; fine until they called it the loopback address(es) 
> which, sadly, caught on and many people, included those writing IETF I-D 
> think that the router id can only be such a routable address.  Some even 
> think that there can only be one such address on a box, as opposed to one for 
> network management, one for the control plane and so on.  Not so.
> 
> Tom Petch.
> 
> As for the details, see 
> https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00
> 
> Regards,
> Reshad.
> 
> 
> On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
>  wrote:
> 
> I am not a fan of loopback seeing it as the implementation choice 
> of one manufacturer.  On the other hand, the IETF has defined documentation 
> addresses which many if not most writers of examples for YANG modules seem 
> unaware of so if we add anything, I would add those.
> 
> Tom Petch
> 
> From: netmod  on behalf of Juergen 
> Schoenwaelder 
> Sent: 17 July 2020 20:25
> 
>   - There was a request to add types for loopback addresses
> (127.0.0.0/8 and ::1/128).
> 
>   - This is related to an effort to define a YANG module for MPLS 
> LSP
> Ping (RFC 8029) but the details are unclear, i.e., what is 
> exactly
> needed and how such a type will be used and whether there is a
> common need for types for loopback addresses.
> 
>   - Proposal: do not add such types at this point in time
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
> Germany
> Fax:   +49 421 200 3103 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: inet:host

[Juergen Schoenwaelder]

On Wed, Jul 29, 2020 at 01:55:38PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> >> If we want to allow non-ASCII names, then it would IMO be safer to use a
> >> type that expects straight Unicode for lexical representation and leave
> >> it to the implementations to convert to Punycode where necessary, e.g.
> >> when querying DNS.
> >
> > Perhaps. But I am not sure this is the time to fix this or how this
> > can be done in a backwards compatible way. At least this likely can't
> > be done by disallowing ACE. It may be possible to add an additional
> > member to the inet:host union that catches internationalized names.
> 
> I think it would be better to have an extra set of parallel definitions such 
> as idn-domain-name, or perhaps u-domain-name.
>

So if we define idn-domain-name, what do we do with your hostname?
Have hostname derived from domain-name (as discussed before) with

 typedef host {
   type union {
 type inet:ip-address;
 type inet:host-name;
 }

and we add

 typedef idn-host {
   type union {
 type inet:ip-address;
 type inet:idn-hostname;
 }

and then YANG module writers can opt-in to use the new definition if
they want idn host names without requiring ACE encoding?

> Lada
> 
> > Since this would be enlarging the value space, I believe this is
> > inline with the spirit of section 11 of RFC 7950. Removing the ACE
> > names, however, restricts the value space and hence seem to contradict
> > section 11 of RFC 7950. (The explicit removal of underscore and single
> > letter hostnames may be considered a clarification since we have other
> > RFCs stating these constraints.)
> >
> > /js
> >
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> 
> -- 
> Ladislav Lhotka 
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Juergen Schoenwaelder]

But there is draft-ietf-netmod-geo-location-05... What about using the
types defined in there?

/js

On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
> See geolocation definition in draft-ietf-teas-yang-te-topo-22 which defines 
> longitude and latitude, altitude.
> I know it is beneficial for future document to import these types from 
> rfc6991bis instead of from te topo model.
> 
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> 发送时间: 2020年7月18日 3:16
> 收件人: netmod@ietf.org
> 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, 
> yang:country-code
> 
>   - It was suggested to add types for longitude, latitude, postal
> code, country-code. Do we go there or do we leave these for other
> modules to define? It seems such definitions should go into
> draft-ietf-netmod-geo-location.
> 
>   - Geo location is covered by draft-ietf-netmod-geo-location
> (so do nothing).
> 
>   - For country codes, there is ISO 3166, which defines two-letter,
> three-letter, and numeric country codes. I assume people wanted
> two-letter codes (as used in the DNS), i.e. they want DE and not
> DEU. But note that it is GB and not UK, i.e., what we commonly
> use in the DNS may not be exactly ISO 3166. (The devil is always
> in the details.)
> 
>   - For postal codes, it is unclear what the requirements are or what
> a proper definition for postal codes is. It is not entirely clear
> what the authoritative definition of the format of postal codes
> is, perhaps the Universal Postal Union.
> 
>   - Options: (i) do nothing or (ii) add a country code definition
> only or (iii) add both a country code definition and a postal
> code definition (which might be to some extend vague)
> 
>   - Proposal: do nothing
>   
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Qin Wu]

See geolocation definition in draft-ietf-teas-yang-te-topo-22 which defines 
longitude and latitude, altitude.
I know it is beneficial for future document to import these types from 
rfc6991bis instead of from te topo model.

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
发送时间: 2020年7月18日 3:16
收件人: netmod@ietf.org
主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, 
yang:country-code

  - It was suggested to add types for longitude, latitude, postal
code, country-code. Do we go there or do we leave these for other
modules to define? It seems such definitions should go into
draft-ietf-netmod-geo-location.

  - Geo location is covered by draft-ietf-netmod-geo-location
(so do nothing).

  - For country codes, there is ISO 3166, which defines two-letter,
three-letter, and numeric country codes. I assume people wanted
two-letter codes (as used in the DNS), i.e. they want DE and not
DEU. But note that it is GB and not UK, i.e., what we commonly
use in the DNS may not be exactly ISO 3166. (The devil is always
in the details.)

  - For postal codes, it is unclear what the requirements are or what
a proper definition for postal codes is. It is not entirely clear
what the authoritative definition of the format of postal codes
is, perhaps the Universal Postal Union.

  - Options: (i) do nothing or (ii) add a country code definition
only or (iii) add both a country code definition and a postal
code definition (which might be to some extend vague)

  - Proposal: do nothing
  
-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:percentage

[Juergen Schoenwaelder]

On Thu, Jul 30, 2020 at 02:58:22PM +0200, Benoit Claise wrote:
> On 20/07/2020 11:19, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> > 
> > >- Percentages are frequently used in YANG models but usages differ a
> > >  lot in precision and range. It is not clear what the proper
> > >  generic definition of a percentage type would be and whether it is
> > >  worth having it.
> > > 
> > >  RFC 7950 example:
> > > 
> > >   typedef percent { type uint8 { range "0 .. 100"; } }
> > > 
> > >  RFC 8294:
> > > 
> > >   typedef percentage { type uint8 { range "0..100"; } }
> > > 
> > >  I-Ds:
> > >   typedef percentage { type decimal64 { fraction-digits 5; } }
> > >   typedef percentile { type decimal64 { fraction-digits 2; } }
> > > 
> > >  The yang catalogue seems to be down. :-(
> > > 
> > >- Proposal: do not add a percentage type since it is trivial to
> > >  define a context specific percentage type that matches range and
> > >  precision requirements (and there is already a definition in RFC
> > >  8294 for those who need exactly that definition).
> > I agree with this proposal. It is also possible to use
> > 
> > units percent;
> > 
> > where necessary.
> On the other hand, when I look at the numerous percent/percentage
> occurrences in YANG model, it doesn't hurt to define that typedef.
> 
> https://yangcatalog.org/yang-search/ => search on "node name" and typedef
> only
> We can find 56 entries from IETF, IEEE, BBF, OC, MEF, vendors
> Most of them points to:
> 
>*typedef*  percent {
>   *type*  uint8 {
>   *range*  "0 .. 100";
> 
>   }
>}
>

But that one is already defined in RFC 8294 in ietf-routing-types.
Does it make sense to define it again in yang-types?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: loopback addresses

[Nagendra Kumar Nainar (naikumar)]

Hi,

As Reshad mentioned, RFC8029 uses internal host loopback address (127..0.0.0/8 
range as defined in section 4.2.2.11 of RFC1812). The YANG module for LSP Ping 
(RFC8029) defined in draft-nainar-mpls-lsp-ping-yang is using this address and 
so we felt it will be good to have the same included in the right document.

Thanks,
Nagendra

On 7/20/20, 2:54 PM, "Reshad Rahman (rrahman)"  wrote:

Hi,

I think what you're referring to is the use of "loopback interfaces". The 
loopback addresses Juergen was referring to do not belong to loopback 
interfaces. 

Regards,
Reshad.


On 2020-07-20, 11:30 AM, "tom petch"  wrote:

From: Reshad Rahman (rrahman) 
Sent: 20 July 2020 14:39

I don't understand the comment "...implementation choice of one 
manufacturer."


Go back to the early specifications of IPv4 routers and routing 
protocols, which are still the ones we use today, and loopback was a state into 
which an interface could be put, with a loop back in hardware or software, 
often used for testing.  A router had a router id, a 32 bit number with no 
syntax.  One major manufacturer conflated parts of this and created a virtual 
address  or addresses which could be used to send and receive packets for the 
router, as opposed to an interface on the router, which had no physical 
manifestation; fine until they called it the loopback address(es) which, sadly, 
caught on and many people, included those writing IETF I-D think that the 
router id can only be such a routable address.  Some even think that there can 
only be one such address on a box, as opposed to one for network management, 
one for the control plane and so on.  Not so.

Tom Petch.

As for the details, see 
https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00

Regards,
Reshad.


On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
 wrote:

I am not a fan of loopback seeing it as the implementation choice 
of one manufacturer.  On the other hand, the IETF has defined documentation 
addresses which many if not most writers of examples for YANG modules seem 
unaware of so if we add anything, I would add those.

Tom Petch

From: netmod  on behalf of Juergen 
Schoenwaelder 
Sent: 17 July 2020 20:25

  - There was a request to add types for loopback addresses
(127.0.0.0/8 and ::1/128).

  - This is related to an effort to define a YANG module for MPLS 
LSP
Ping (RFC 8029) but the details are unclear, i.e., what is 
exactly
needed and how such a type will be used and whether there is a
common need for types for loopback addresses.

  - Proposal: do not add such types at this point in time

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: loopback addresses

[Nagendra Kumar Nainar (naikumar)]

Hi Erik,

Thank you for catching this inconsistency. The choice of v4-mapped-v6 address 
was discussed while co-authoring RFC8029 and I think I mixed up and used the 
IPv6 loopback address in the YANG module. I will fix the same in the next 
revision of draft-nainar-mpls-lsp-ping-yang.

Thanks,
Nagendra

On 7/20/20, 2:49 PM, "Reshad Rahman (rrahman)"  wrote:

Hi Erik,

You are correct, for IPV6 RFC8029 mentions 0:0:0:0:0::7F00:0/104.

Regards,
Reshad.

On 2020-07-20, 10:30 AM, "Erik Auerswald"  
wrote:

Hello Reshad,

while the I-D draft-nainar-mpls-lsp-ping-yang-00 only specifies ::1/128
as IPv6 loopback address, RFC 8029 sections 2.1., 3.4.1.1.1., and 4.3.
specify to use the IPv4 loopback range as IP4-mapped IPv6 addresses for
IPv6 MPLS echo request UDP packets, not the IPv6 loopback address 
::1/128.

This seems to be inconsistent to me.

Best regards,
Erik

On Mon, Jul 20, 2020 at 01:39:02PM +, Reshad Rahman (rrahman) wrote:
> I don't understand the comment "...implementation choice of one 
manufacturer."
> 
> As for the details, see 
https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00
> 
> Regards,
> Reshad.
> 
> 
> On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
 wrote:
> 
> I am not a fan of loopback seeing it as the implementation choice 
of one manufacturer.  On the other hand, the IETF has defined documentation 
addresses which many if not most writers of examples for YANG modules seem 
unaware of so if we add anything, I would add those.
> 
> Tom Petch
> 
> From: netmod  on behalf of Juergen 
Schoenwaelder 
> Sent: 17 July 2020 20:25
> 
>   - There was a request to add types for loopback addresses
> (127.0.0.0/8 and ::1/128).
> 
>   - This is related to an effort to define a YANG module for MPLS 
LSP
> Ping (RFC 8029) but the details are unclear, i.e., what is 
exactly
> needed and how such a type will be used and whether there is a
> common need for types for loopback addresses.
> 
>   - Proposal: do not add such types at this point in time
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
Germany
> Fax:   +49 421 200 3103 



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Session links...

[Lou Berger]

Hi,

Here are some (hopefully) useful links for today's sessions:

Joint note taking: https://codimd.ietf.org/notes-ietf-108-netmod?both

Session material: https://datatracker.ietf.org/meeting/108/session/netmod

Join session: https://meetings.conf.meetecho.com/ietf108/?group=netmod

See you soon,
Lou

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:percentage

[Benoit Claise]

On 20/07/2020 11:19, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


   - Percentages are frequently used in YANG models but usages differ a
 lot in precision and range. It is not clear what the proper
 generic definition of a percentage type would be and whether it is
 worth having it.

 RFC 7950 example:

  typedef percent { type uint8 { range "0 .. 100"; } }

 RFC 8294:

  typedef percentage { type uint8 { range "0..100"; } }

 I-Ds:
  typedef percentage { type decimal64 { fraction-digits 5; } }
  typedef percentile { type decimal64 { fraction-digits 2; } }

 The yang catalogue seems to be down. :-(

   - Proposal: do not add a percentage type since it is trivial to
 define a context specific percentage type that matches range and
 precision requirements (and there is already a definition in RFC
 8294 for those who need exactly that definition).

I agree with this proposal. It is also possible to use

units percent;

where necessary.
On the other hand, when I look at the numerous percent/percentage 
occurrences in YANG model, it doesn't hurt to define that typedef.


https://yangcatalog.org/yang-search/ => search on "node name" and 
typedef only

We can find 56 entries from IETF, IEEE, BBF, OC, MEF, vendors
Most of them points to:

   *typedef*  percent {
*type*  uint8 {
*range*  "0 .. 100";

}
   }
 


Regards, Benoit




Lada


--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod