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
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]
发送时间:
-邮件原件-
发件人: 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
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
> 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.
>
+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,
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?
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
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
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.
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
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
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
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
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:
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
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
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
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] 代表
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
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
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,
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
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
25 matches
Mail list logo
