Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt

Top posting to assure everyone reads: I don’t think I could of come up with a better strategy to guarantee that IETF YANG models aren’t used if I tried. We’ll still specify them in IETF document and they’ll provide a useful reference model for other SDOs and vendor native models, but no one is

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt

From: netmod on behalf of Andy Bierman Date: Wednesday, December 7, 2022 at 10:48 PM To: Kent Watsen Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt On Wed, Dec 7, 2022 at 7:02 PM Kent Watsen mailto:kent%2bi...@watsen.net>> wrote: >>

Re: [netmod] The NETMOD WG has placed draft-dbb-netmod-acl in state "Candidate for WG Adoption"

NETMOD WG, From: netmod on behalf of Mahesh Jethanandani Date: Tuesday, December 6, 2022 at 6:58 PM To: "netmod-cha...@ietf.org" Cc: netmod Subject: Re: [netmod] The NETMOD WG has placed draft-dbb-netmod-acl in state "Candidate for WG Adoption" Is this in-lieu of a call for adoption, or

Re: [netmod] [yang-doctors] Length on keys in YANG

Jeff, From: Jeff Haas Date: Wednesday, October 5, 2022 at 10:25 AM To: Acee Lindem Cc: Ladislav Lhotka , tom petch , "netmod@ietf.org" , YANG Doctors Subject: Re: [yang-doctors] [netmod] Length on keys in YANG Acee, On Oct 5, 2022, at 10:18 AM, Acee Lindem (acee) mailto:a...

Re: [netmod] [yang-doctors] Length on keys in YANG

Hi Jeff, From: yang-doctors on behalf of Jeff Haas Date: Wednesday, October 5, 2022 at 9:53 AM To: Ladislav Lhotka Cc: tom petch , "netmod@ietf.org" , YANG Doctors Subject: Re: [yang-doctors] [netmod] Length on keys in YANG Lada, On Oct 5, 2022, at 7:03 AM, Ladislav Lhotka

Re: [netmod] usage of ip-address in openconfig

Hi Andy, I like this suggestion. From: Andy Bierman Date: Wednesday, April 20, 2022 at 9:19 PM To: Acee Lindem Cc: Juergen Schoenwaelder , NetMod WG Subject: Re: [netmod] usage of ip-address in openconfig On Wed, Apr 20, 2022 at 4:02 PM Acee Lindem (acee) mailto:a...@cisco.com>>

Re: [netmod] usage of ip-address in openconfig

On 4/20/22, 6:35 PM, "netmod on behalf of Jürgen Schönwälder" wrote: On Wed, Apr 20, 2022 at 02:51:35PM -0700, Andy Bierman wrote: > On Wed, Apr 20, 2022 at 2:34 PM Jürgen Schönwälder < > j.schoenwael...@jacobs-university.de> wrote: > > > I am not sure it helps to look

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

14, 2022 at 8:01 AM Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org>> wrote: While RFC 4001 really didn't need to extend the zone index to IPv4, the conversation also pertains to IPv6 address types. At least RFC 4001 got it right by not making the zone index part of the defaul

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

While RFC 4001 really didn't need to extend the zone index to IPv4, the conversation also pertains to IPv6 address types. At least RFC 4001 got it right by not making the zone index part of the default types and defining ipv4z and ipv6z. Thanks, Acee On 4/14/22, 10:04 AM, "Lsr on behalf of

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

From: netmod on behalf of Andy Bierman Date: Wednesday, April 13, 2022 at 12:43 PM To: tom petch Cc: "l...@ietf.org" , "netmod@ietf.org" , "Rob Wilton (rwilton)" Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt On Wed, Apr 13, 2022 at 2:22 AM tom

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

link local addresses do not exist or do not need to be supported, then you may want to bring the news to other WGs. /js On Tue, Apr 12, 2022 at 02:54:16PM +0000, Acee Lindem (acee) wrote: > That was a hypothetical example based on IPv6 Link Local addresses - not one anyone ha

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote: > Joel, > > There are plenty of examples of where the ip-address types are used and a zone is not accepted. Show me the examples where it is expected? I do have reason to believe there aren't any significant usages of t

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Joel, There are plenty of examples of where the ip-address types are used and a zone is not accepted. Show me the examples where it is expected? I do have reason to believe there aren't any significant usages of the ip-address types where zone is accepted. Show me the models Acee On

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

From: netmod on behalf of Andy Bierman Date: Tuesday, April 12, 2022 at 4:54 AM To: Martin Björklund Cc: "l...@ietf.org" , NetMod WG , Robert Wilton Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt On Tue, Apr 12, 2022 at 12:26 AM Martin Björklund

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Speaking as WG member inline. From: netmod on behalf of Andy Bierman Date: Monday, April 11, 2022 at 1:28 PM To: "Rob Wilton (rwilton)" Cc: "l...@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt On Mon, Apr 11, 2022 at

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

See inline. On 4/11/22, 5:13 AM, "tom petch" wrote: From: Lsr on behalf of Reshad Rahman Sent: 10 April 2022 21:42 Inline. On Wednesday, April 6, 2022, 06:04:42 PM EDT, Acee Lindem (acee) wrote: Hi Chris (as WG member), On 4/5/22, 10:47 AM, "

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi Andy, My opinion remains the same that RFC 4001 got it right with types including the zone specification being the exception rather than the default. I know that when people think IP address, they think the dotted 4 octet without “%” appended. I’d still like to know if there are

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

I hate when people selectively snip my Emails and respond out of context. Please don't do that in the future! I'll reply to the more constructive thread. Acee On 4/8/22, 4:45 PM, "Lsr on behalf of Randy Presuhn" wrote: Hi - On 2022-04-08 12:25 PM, Acee Lindem (a

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

See inline. On 4/8/22, 1:59 PM, "netmod on behalf of Randy Presuhn" wrote: Hi - On 2022-04-08 5:11 AM, Christian Hopps wrote: .. > Instead, Acee (I'm not sure I'd call him WG B :) is asserting that > *nobody* actually wanted the current type, and it has been misused

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Jürgen, On 4/7/22, 12:08 PM, "Jürgen Schönwälder" wrote: On Thu, Apr 07, 2022 at 02:35:03PM +0000, Acee Lindem (acee) wrote: > > We already a large number of models that use the existing inet:ip-address types whose implementations don't support the zone. Why

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

reasonably, use a different typedef in this model. Point me to a usages where the zone is actually desired and supported? Acee Yours, Joel On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote: > Hi Martin, > > On 4/7/22, 1:02 PM, "netmod on behalf of M

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

eps its import "revision-or-derived" extension, would also allow > > such modules to indicate the dependency on the updated revision/definition > > of ietf-inet-types.yang. > > > > Of course, the description associated with the updated > > iet

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Kent, On 4/7/22, 4:39 AM, "Kent Watsen" wrote: Juergen et. al. , > What are our options? > > a) Do nothing and accept that types are called as they are. > b) Change the types as suggested and accept that doing so breaks > modules where zone indexes are meaningful.

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

Hey Kent, Are you behind on your Emails or choosing to ignore the ongoing discussion of the ip-address, ipv4-address, and ipv6-address types? Thanks, Acee From: netmod on behalf of Kent Watsen Date: Wednesday, April 6, 2022 at 9:25 PM To: "draft-ietf-netmod-rfc6991-...@ietf.org" Cc:

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi Chris (as WG member), On 4/5/22, 10:47 AM, "Christian Hopps" wrote: > On Apr 5, 2022, at 09:48, Acee Lindem (acee) wrote: > > [wg-member] > > The thing is that most of the existing RFCs use inet:ip-address rather inet:ip-address-no-zone. It

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Jürgen and netmod WG, +IESG, It is not just the IETF models that are using the inet:ip-address for the standard IPv4/IPv6 addresses without zones. Every vendor’s native models and the OpenConfig models use the base types and expect the standard IP address notation. If we don’t fix this, it is

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On 4/5/22, 11:37 AM, "Lsr on behalf of Jürgen Schönwälder" wrote: On Tue, Apr 05, 2022 at 01:48:25PM +0000, Acee Lindem (acee) wrote: > [wg-member] > > The thing is that most of the existing RFCs use inet:ip-address rather inet:ip-address-no-zone.

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hopps" wrote: If they are new leaf values why not use the correct no-zone variant, what's the harm in doing it right? It has a nice side effect of basically restricting the base spec zone values to no-zone only. :) Thanks, Chris. [wg member] > On Apr 4, 2022, at 12:30

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On 4/4/22, 11:55 AM, "tom petch" wrote: From: Acee Lindem (acee) Sent: 04 April 2022 15:58 Hi Tom, +Juergen, netmod WG, I think the question you ought to be asking is whether the base IPv4 and IPv6 address types should be modified to NOT include the zone an

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi Tom, +Juergen, netmod WG, I think the question you ought to be asking is whether the base IPv4 and IPv6 address types should be modified to NOT include the zone and the zone versions should be added as a separate YANG type. The RFC 6991 is under revision now:

Re: [netmod] [babel] NULL value for uint16

All, From: netmod on behalf of Mahesh Jethanandani Date: Tuesday, September 14, 2021 at 1:38 PM To: Juergen Schoenwaelder Cc: Babel at IETF , "STARK, BARBARA H" , "netmod@ietf.org" Subject: Re: [netmod] [babel] NULL value for uint16 Hi Juergen, On Sep 14, 2021, at 10:17 AM, Jürgen

Re: [netmod] Typedefs for bandwidth

I'd be all for using some unsigned integer quantity. I think it was a mistake for using IEEE floating point in the first place. This floating point nonsense was carried over to Traffic Engineering (TE) from early work done on transport area on RSVP. For example,

Re: [netmod] YANG questions

Hi Tony, I would argue that YANG is a data modeling language. Another disadvantage of the bits type that it isn't augmentable with new bits. Hence, usage of unused bits requires a new version of the module as opposed to an augmentation. For that reason, we greatly limited their usage in

Re: [netmod] [mpls] [Technical Errata Reported] RFC8349 (6251)

Hi Tarek, Can you also add the description of the native MPLS RIB to the text? Thanks, Acee On 8/14/20, 12:27 PM, "mpls on behalf of Acee Lindem (acee)" wrote: Hi Tarek, This works for me. Thanks, Acee On 8/14/20, 12:25 PM, "Tarek Saad" wrote:

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

" as input (that points to a local-label leaf). If this is acceptable, we believe the errata 6251 can be rejected and we'll proceed with the change in the MPLS RIB model. Regards, Tarek (for authors) On 8/11/20, 9:08 AM, "Acee Lindem (acee)" wrote: [External Emai

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

was the MPLS RIB that was the source of confusion as the local-label leaf was an optional attribute for AF IPv4/IPv6 RIB sbut the primary RIB key for AF MPLS. Hopefully the MPLS-specific destination-prefix leaf will make this more obvious. Thanks, Acee Tom Petch Regards, Tarek (fo

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

the AF-agnostic model. This shouldn't and can't be fixed with an Errata for RFC 8349. Thanks, Acee On 8/14/20, 7:45 AM, "tom petch" wrote: From: Acee Lindem (acee) Sent: 11 August 2020 14:08 Hi Tom, Draft Authors, The draft could easily be fixed. You just need to

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

Hi Tarek, On 8/11/20, 1:36 PM, "Tarek Saad" wrote: Hi Acee and Tom, Thanks for your feedback and suggestions. Please see further response inline.. On 8/11/20, 9:08 AM, "Acee Lindem (acee)" wrote: [External Email. Be cautious of content] H

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

On 8/11/20, 6:10 AM, "tom petch" wrote: From: Acee Lindem (acee) Sent: 11 August 2020 10:47 Hi Tom, I fully understood your original comment. There are other problems with this model. See inline. On 8/11/20, 4:59 AM, "tom petch" wrote: Tarek

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

> Address-family-specific modules MUST augment input > parameters with a leaf named 'destination-address'."; Regards, Tarek On 8/10/20, 3:27 PM, "Acee Lindem (acee)" wrote: [External Email. Be cautious of content] All (Speakin

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

destination prefix."; } } Given the above, can you take another look and let us know? I think you must follow the AFI specific augmentations set forth in RFC 8349. It is not for the augmenting models to break these conventions One more nit, why is label-block_state not label-block

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

> Address-family-specific modules MUST augment input > parameters with a leaf named 'destination-address'."; Regards, Tarek On 8/10/20, 3:27 PM, "Acee Lindem (acee)" wrote: [External Email. Be cautious of content]

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

; -Original Message- > From: tom petch > Sent: 10 August 2020 17:32 > To: RFC Errata System ; lho...@nic.cz; Acee > Lindem (acee) ; yingzhen...@huawei.com; war...@kumari.net; > Rob Wilton (rwilton) ; joe...@bogus.com; > kent+i...@watsen.net; lber...@labn.net

Re: [netmod] rfc6991bis: loopback addresses

Hi Qin, On 7/30/20, 9:23 PM, "Qin Wu" wrote: -邮件原件- 发件人: 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]

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

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

Hi Qin, From: Qin Wu Date: Friday, July 10, 2020 at 2:59 AM To: Acee Lindem Cc: NetMod WG 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

Re: [netmod] Adoption of versioning design team docs

I support adoption of the design team work as well. Thanks, Acee On 3/9/20, 11:10 AM, "netmod on behalf of Ladislav Lhotka" wrote: I support the adoption of the entire document set. Lada Lou Berger writes: > Hi, > We'd like to start a two week adoption call for

Re: [netmod] ID submission YANG validation errors?

Also, the YANG validator tool is broken - https://www.yangcatalog.org/yangvalidator/ On 1/22/20, 9:41 AM, "netmod on behalf of Christian Hopps" wrote: I've just submitted a YANG module draft and received what i think to be a bogus validation error:

Re: [netmod] Yangdoctors last call review of draft-ietf-netmod-yang-instance-file-format-04

Hi Balazs, I think this satisfies all my comments. Please upload the -05 version and I will complete the YANG doctors review. Thanks, Acee On 11/6/19, 11:23 AM, "Balázs Lengyel" wrote: Hello, Thanks for the comments and the updated file accordingly. See below. Regards Balazs

Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

Hi Rob, Any update on getting the YANG tools issue resolved with the ieee802-dot1q-types.yang model in the search path? Thanks, Acee From: netmod on behalf of "Rob Wilton (rwilton)" Date: Tuesday, November 5, 2019 at 4:50 AM To: Stephen Cheng , "netmod@ietf.org" Subject: Re: [netmod] Mail

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

--- From: netmod On Behalf Of Acee Lindem (acee) Sent: 10 July 2019 14:09 To: Kent Watsen ; netmod@ietf.org Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 I have reviewed the subject document and support publication. I have the following comment:

Re: [netmod] Add network instance name on interface, IPv4, IPv6

Hi Qin, From: Qin Wu Date: Monday, August 5, 2019 at 10:11 AM To: "draft-ietf-rtgwg-ni-model@ietf.org" Cc: Routing WG , "netmod@ietf.org" , "Wangleilei (DOPRA SSP)" Subject: Add network instance name on interface, IPv4, IPv6 Resent-From: Resent-To: , Christian Hopps , Acee Lindem ,

Re: [netmod] HTTP: or HTTPS:

On 7/31/19, 7:09 AM, "netmod on behalf of Ladislav Lhotka" wrote: On Wed, 2019-07-31 at 11:00 +, tom petch wrote: > YANG modules contain several URL - e.g. for the Working Group, Legal > provisions, RFC - for which some authors use http:, some use https: and > some use a

Re: [netmod] WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-05

I've reviewed this document and support publication. I don’t have comments on the module per se. However, the IETF tools need to include the IEEE YANG model needed for successful validation. Thanks, Acee On 7/9/19, 8:15 PM, "netmod on behalf of Kent Watsen" wrote: All, This

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

I have reviewed the subject document and support publication. I have the following comment: Perhaps ietf-interface-ethernet-like module ethlike:ethernet-like/ethlike:statistics could include a subset of the counters from RFC 3635. I say a subset since some of these counters are a bit archaic

Re: [netmod] 6021 ipv4-prefix

Hi Juergen, On 4/26/19, 11:36 AM, "netmod on behalf of Juergen Schoenwaelder" wrote: On Fri, Apr 26, 2019 at 05:07:52PM +0200, Kristian Larsson wrote: > > I think the canonical representation is quite clear as is the part that the > server must return data (and

Re: [netmod] 6021 ipv4-prefix

Agreed. Thanks, Acee On 4/26/19, 1:52 AM, "netmod on behalf of Jeff Tantsura" wrote: +1 Cheers, Jeff > On Apr 18, 2019, at 6:12 AM, Lou Berger wrote: > > Having worked with UIs that have the behavior of accepting an address/prefix-len and mapping it to a

Re: [netmod] 6021 ipv4-prefix

Hi Mikael, On 4/18/19, 3:17 AM, "netmod on behalf of Mikael Abrahamsson" wrote: On Tue, 16 Apr 2019, 7ri...@gmail.com wrote: > We might need to clarify this with the libyang folk. I see that Michal fixed the bug in libyang. Good. There is another thing I am

Re: [netmod] Doubts about static routes in RFC 8349

Hi Martin, On 4/3/19, 7:57 AM, "Martin Bjorklund" wrote: "Acee Lindem (acee)" wrote: > Hi Sasha, > > On 4/3/19, 7:27 AM, "Alexander Vainshtein" > wrote: > > Martin, > Lots of thanks for a promp

Re: [netmod] Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

pper that splits such a list into multiple 4292-compliant routes (simpler than merge, but still non-trivial IMHO). Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Acee Lindem (acee) Sent: Tuesday, April 2, 2019 7:45 PM To: Alexander

Re: [netmod] Doubts about static routes in RFC 8349

Hi Sasha, On 4/3/19, 7:27 AM, "Alexander Vainshtein" wrote: Martin, Lots of thanks for a prompt response. My reading of your response is that, if you need multiple static routes with the same destination but different next hops, you configure them as a single route with

Re: [netmod] Doubts about static routes in RFC 8349

Hi Sasha, Martin, Just one clarification below. On 4/3/19, 7:05 AM, "Martin Bjorklund" wrote: Hi, Alexander Vainshtein wrote: > Martin, > > Lots of thanks for an interesting input. > > I have noticed that Appendix A in RFC >

Re: [netmod] Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

Hi Sasha, You are correct that there is no per-next-hop preference in the current model. However, this is included in the augmentation in draft-ietf-rtgwg-yang-rib-extend. Thanks, Acee From: Alexander Vainshtein Date: Tuesday, April 2, 2019 at 9:53 AM To: Acee Lindem , Ladislav Lhotka Cc:

Re: [netmod] 6991bis: address-with-prefix-length

Hi Rob, On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)" wrote: > -Original Message- > From: netmod On Behalf Of Martin Bjorklund > Sent: 02 April 2019 13:47 > To: j.schoenwael...@jacobs-university.de > Cc: netmod@ietf.org > Subject:

Re: [netmod] 6991bis: address-with-prefix-length

(i.e., the last statement in the description). Thanks, Acee On 4/1/19, 3:40 PM, "Kristian Larsson" wrote: On 2019-04-01 19:38, Acee Lindem (acee) wrote: > > On 4/1/19, 1:30 PM, "Martin Bjorklund" wrote: > > Hi,

Re: [netmod] 6991bis: address-with-prefix-length

o CLI. Thanks, Acee /martin "Acee Lindem (acee)" wrote: > Ok, now I'm confused. I see that the ietf-inet-type model already has the types ipv4-prefix and ipv6-prefix. How are these any different??? > Thanks, > Acee > > On

Re: [netmod] 6991bis: address-with-prefix-length

Ok, now I'm confused. I see that the ietf-inet-type model already has the types ipv4-prefix and ipv6-prefix. How are these any different??? Thanks, Acee On 4/1/19, 12:31 PM, "Acee Lindem (acee)" wrote: I believe the "address-" could be omitted from the type identifie

Re: [netmod] 6991bis: address-with-prefix-length

I believe the "address-" could be omitted from the type identifiers. At least within the routing area, "ipv4-prefix" is unambiguous. Thanks, Acee On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder" wrote: This is the right time for this and I would call these

Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00

I support WG adoption. Acee From: netmod on behalf of Kent Watsen Date: Monday, March 25, 2019 at 4:31 PM To: "netmod@ietf.org" Subject: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00 This email begins a 2-week adoption poll for:

Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01

I support WG adoption. Thanks, Acee From: netmod on behalf of Kent Watsen Date: Monday, March 25, 2019 at 4:33 PM To: "netmod@ietf.org" Subject: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01 This email begins a 2-week adoption poll for:

Re: [netmod] for a future rfc6991bis

> > > > Does a percentage really need a single standard type in the first > > > > place? How about "units percent;"? > > > > > > > > At this point, after hearing about how different modules have > > > > differin

Re: [netmod] for a future rfc6991bis

On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder" wrote: On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote: > Hello, > > In some cases I want a percentage without fractions. This could be defined > using range, by specifying the numbers 0 |

Re: [netmod] for a future rfc6991bis

I’ll participate as well. I agree it should be a separate YANG module and draft from the geo-location advertisement protocol specifications (currently OSPF, IS-IS, BGP, and LISP). Thanks, Acee From: netmod on behalf of Qin Wu Date: Friday, November 2, 2018 at 8:16 AM To: Juergen Schoenwaelder

Re: [netmod] for a future rfc6991bis

longitude and latitude, why not use DMS (Degree, Minute, Second)? I'd be happy to reach consensus on this but we're going to solve it in this Email thread. Thanks, Acee -Qin -邮件原件- 发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 发送时间: 2018年11月1日 22:18 收件人: Qin Wu

Re: [netmod] for a future rfc6991bis

Hi Qin, We'd tried to converge on geo-coordinates in the protocols and received and a rather wide range of opinions as to the precision and what was required. An IETF consensus is required and not everyone is going to be happy. However, I'm not sure where this work lies and it hasn't been a

Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

Support. On 10/1/18, 2:48 PM, "netmod on behalf of Kent Watsen" wrote: The IETF 102 in-room poll should really good support to adopt this draft, and no objections. This email starts an adoption poll for: https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00

Re: [netmod] YANG module security considerations template - TLS reference

> has since passed to Ignas. > > Kent > > > > ?-Original Message- > From: "Acee Lindem (acee)" > Date: Monday, October 1, 2018 at 10:25 AM > To: Martin Bjorklund , "netmod-cha...@ietf.org" > ,

Re: [netmod] YANG module security considerations template - TLS reference

Agreed - although I'm not sure who has control over the template either. For drafts that are in-progress, IDNITs will flag this obsolete reference and, for at least one of the drafts I'm an editor, I've already made the update. Thanks, Acee On 10/1/18, 3:19 AM, "netmod on behalf of Martin

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

Yes/support Thanks, Acee On 9/26/18, 10:41 AM, "netmod on behalf of joel jaeggli" wrote: This is start of a two week poll on making draft-ietf-netmod-module-tags-02 a NetMod working group document. You may review at:

Re: [netmod] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

Mirja, See inline. On 9/25/18, 6:29 PM, "netmod on behalf of Mirja Kuehlewind (IETF)" wrote: Hi Mahesh, hi Eliot, please see below. > Am 25.09.2018 um 22:25 schrieb Eliot Lear : > > Just on this point: > > On 25.09.18 20:35, Mahesh Jethanandani

Re: [netmod] xpath for must statements

Hi William, On 8/8/18, 4:41 AM, "netmod on behalf of Ivory, William" wrote: On 07/08/18 23:01, Acee Lindem (acee) wrote: Is it possible to indicate that choice statement must be specified in a YANG 1.1 “must” clause w/o specifying every case? Similarly, it is there a wa

Re: [netmod] xpath for must statements

Thanks Martin - see inline. On 8/8/18, 3:43 AM, "Martin Bjorklund" wrote: Hi, "Acee Lindem \(acee\)" wrote: > Is it possible to indicate that choice statement must be specified > in a YANG 1.1 “must” clause w/o specifying every case?

[netmod] xpath for must statements

Is it possible to indicate that choice statement must be specified in a YANG 1.1 “must” clause w/o specifying every case? Similarly, it is there a way specify that a container cannot be empty in “must” clause? Thanks, Acee ___ netmod mailing list

Re: [netmod] 6087bis - Security Considerations template

Hi Martin, On 8/6/18, 2:51 PM, "netmod on behalf of Martin Bjorklund" wrote: Hi, Ladislav Lhotka wrote: > Hi, > > Shawn Emery reviewed draft-ietf-netmod-schema-mount-10 and made this > editorial comment: > > OLD: > > These are the subtrees and

Re: [netmod] "iana" in yang modules' name/namespace/prefix

Hi Benoit, et al, I couldn't agree more. The IETF has much more exigent issues with respect to YANG models and the attendant protocol infrastructure than whether IANA might go away in the future. Thanks, Acee On 7/22/18, 9:54 AM, "netmod on behalf of Benoit Claise" wrote: Martin,

Re: [netmod] "iana" in yang modules' name/namespace/prefix

Hi Martin, I would prefer not using "reg" since it will always be an abbreviation for a machine language register to me. I'd favor using "registry" in the module name and the more cryptic "reg" in the module prefix. Thanks, Acee On 7/20/18, 9:46 AM, "netmod on behalf of Martin Vigoureux"

Re: [netmod] YANG identities and identityref's

On 5/3/18, 4:23 PM, "Martin Bjorklund" <m...@tail-f.com> wrote: "Acee Lindem (acee)" <a...@cisco.com> wrote: > > > On 5/3/18, 2:40 PM, "Ladislav Lhotka" <lho...@nic.cz> wrote: > > On Thu, 2018-05-0

Re: [netmod] YANG identities and identityref's

as the base of an identityref (or in Xpath functions derived-from/derived-from- or-self) should be the most general identity that can match at the given place. Do you have any example illustrating your case? Lada On Thu, 2018-05-03 at 17:30 +0000, Acee Lindem (acee) wr

[netmod] YANG identities and identityref's

Let’s say one define a base identity with a hierarchy of identifyref’s using it. This will allow for augmentation in future models. Should one also define an identityref for the class of unknown identities? Or, should one simply return the lowest parent in the hierarchy matching the value? Many

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

From: netmod on behalf of "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" Date: Friday, March 9, 2018 at 9:59 AM To: Adam Roach , Andy Bierman Cc: NetMod WG Chairs ,

Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

I support netmod WG adoption. Thanks, Acee From: netmod on behalf of joel jaeggli Date: Tuesday, February 6, 2018 at 6:58 PM To: "netmod@ietf.org" Subject: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll:

Re: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-11.txt

Just a small fix to the RIP YANG example based on comments from Francis Dupont. Thanks, Acee On 1/26/18, 8:06 AM, "netmod on behalf of internet-dra...@ietf.org" wrote: A New Internet-Draft is available from the on-line

Re: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-10.txt

This version addresses Ben Campbell's and Suresh Krishnan's IESG Telechat comments. Thanks, Acee On 1/25/18, 12:07 PM, "netmod on behalf of internet-dra...@ietf.org" wrote: A New Internet-Draft is available from the

Re: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)

Hi Suresh, Thanks for the review - see inline. On 1/24/18, 10:43 AM, "Suresh Krishnan" wrote: Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-rfc8022bis-09: No Objection When responding, please keep the subject line intact

Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)

Hi Ben, On 1/23/18, 9:56 PM, "Ben Campbell" wrote: Ben Campbell has entered the following ballot position for draft-ietf-netmod-rfc8022bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in

Re: [netmod] Genart telechat review of draft-ietf-netmod-rfc8022bis-06

Thanks Francis! Acee On 1/23/18, 5:55 PM, "Francis Dupont" wrote: Reviewer: Francis Dupont Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed

Re: [netmod] schema mount and YANG library

2, 2018 at 04:18:15PM +0000, Acee Lindem (acee) wrote: > Hi Lada, > > My primary concern is that the YANG Schema Mount delay will not only hold the NI/LNE but all the models that are dependent on them (e.g., L2VPN and L3VPN). This is for a document that has already finished WG

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

Hi Sonal, From: netmod > on behalf of Sonal Agarwal > Date: Wednesday, January 17, 2018 at 7:25 PM To: Kent Watsen > Cc:

Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams

Hi Rob, On 1/15/18, 10:07 AM, "netmod on behalf of Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" wrote: >Hi Martin, > >All OK with me except where I have further comments/questions inline >below: > >On 15/01/2018 14:39, Martin

Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping"

Hi Jon, From: netmod > on behalf of Jon Shallow > Date: Monday, January 8, 2018 at 10:47 AM To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"

  1   2   3   >