Re: [netmod] New Version Notification for draft-acee-rtgwg-vrrp-rfc8347bis-03.txt

dra...@ietf.org wrote: > > A new version of Internet-Draft draft-acee-rtgwg-vrrp-rfc8347bis-03.txt has > been successfully submitted by Acee Lindem and posted to the > IETF repository. > > Name: draft-acee-rtgwg-vrrp-rfc8347bis > Revision: 03 > Title:A YANG Data Model for th

Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints (fix draft address)

d “deviations of observed behavior”. However, it might be good to explicitly cover “mandatory” since this indicates to return a data node rather than suppress data nodes not being returned due to validation. Thanks, Acee > > No? > > Cheers, > Med > > De : netmod

Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints (fix draft address)

Hi Andy, > On Jan 19, 2024, at 12:17, Andy Bierman wrote: > > > > On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem <mailto:acee.i...@gmail.com>> wrote: >> Along the same lines, what is the sentiment for “mandatory true” data nodes >> for operational stat

Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints

Hi Andy, > On Jan 19, 2024, at 12:17, Andy Bierman wrote: > > > > On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem <mailto:acee.i...@gmail.com>> wrote: >> Along the same lines, what is the sentiment for “mandatory true” data nodes >> for operational stat

Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints

Along the same lines, what is the sentiment for “mandatory true” data nodes for operational state (i.e., “config false” nodes)? Does this make sense to identify data nodes the must be returned if the parent node is returned? Thanks Acee > On Dec 22, 2023, at 2:36 PM, Jürgen Schönwälder >

[netmod] Operational State usage of YANG choices and constraints

We’ve had some discussions as to whether YANG models should put constraints or use choices for ‘config false’ data nodes. For example, if you have a two mutually exclusive containers, should the YANG model reflect this for ‘config false’ data? Or, if you have a leaf that would only make sense

Re: [netmod] Poll on YANG Versioning NBC Approach

> On Sep 14, 2023, at 12:40, Andy Bierman wrote: > > > > On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem <mailto:acee.i...@gmail.com>> wrote: >> >> >> > On Sep 13, 2023, at 10:36, Ladislav Lhotka >> > mailto:40nic...@dmarc.ietf.org>>

Re: [netmod] Poll on YANG Versioning NBC Approach

> On Sep 13, 2023, at 10:36, Ladislav Lhotka > wrote: > > > > Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a): >> On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote: >>> Jernej, >>> >>> Hat off for the tools (and tool vendors!) that assist authors to stay true >>> to YANG RFC sections 10

Re: [netmod] WG adoption call: draft-boucadair-netmod-rfc8407bis-02

I support adoption of the document as well. Adopting conventions for modeling different types of information will make the models easier to consume. Thanks, Acee > On Sep 13, 2023, at 17:53, Mahesh Jethanandani > wrote: > > Support this effort, and agree that this document should be

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

> On Sep 5, 2023, at 16:25, Jeffrey Haas wrote: > > Acee, > > >> On Sep 5, 2023, at 12:42 PM, Acee Lindem wrote: >> >> What I’d thought about for this requirement is an optional read-only leaf >> containing the hex representation of only the

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

What I’d thought about for this requirement is an optional read-only leaf containing the hex representation of only the unknown bits. This would be simpler to model and would be fully backward compatible. For example: leaf unknown-flags { type yang:hex-string;

Re: [netmod] RFC 847BIS - VRRP YANG Model

> On Sep 4, 2023, at 04:01, tom petch wrote: > > From: rtgwg on behalf of Acee Lindem > > Sent: 03 September 2023 22:16 > > For the ietf-vrrp.yang model, I’m updating the YANG model to correspond to > the terminology in > https://datatracker.ietf.org/doc/draft

[netmod] RFC 8347BIS - VRRP YANG Model

Note that the original YANG model is in RFC 8347 - https://datatracker.ietf.org/doc/rfc8347/ > On Sep 3, 2023, at 17:16, Acee Lindem wrote: > > For the ietf-vrrp.yang model, I’m updating the YANG model to correspond to > the terminology in > https://datatracker.ietf.org/doc/d

[netmod] RFC 847BIS - VRRP YANG Model

For the ietf-vrrp.yang model, I’m updating the YANG model to correspond to the terminology in https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/. Will I have retain all the existing identities, types, leaves, and notifications that include “master” in their identifiers and

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

I don’t support adoption as I think this solution to the problem of receiving unknown bits is excessive and the fact that it is Non-Backward Compatible (NBC) change to remove the unknown bits once they are defined. Rather, just add an optional read-only unknown-foo-bits leaf of type

Re: [netmod] Unknown bits - backwards compatibility

> On Apr 14, 2023, at 11:23 AM, Jason Sterne (Nokia) > wrote: > > IETF and vendor models are already doing NBC changes. The versioning work is > mostly just adding a way to indicate that to users/clients when it happens. But with new versions of the complete model and not incremental

Re: [netmod] Unknown bits - backwards compatibility

> On Apr 14, 2023, at 07:46, Martin Björklund wrote: > > Acee Lindem wrote: >> >>> On Apr 14, 2023, at 04:39, Martin Björklund wrote: >>> >>> Hi, >>> >>> I am quite confused after reading this thread, so I had to go back to &g

Re: [netmod] Unknown bits - backwards compatibility

> On Apr 14, 2023, at 04:39, Martin Björklund wrote: > > Hi, > > I am quite confused after reading this thread, so I had to go back to > this first message: > > "Jason Sterne (Nokia)" wrote: >> Hi Jeff, >> >> One topic that came up during the IETF 116 NETMOD meeting was >> backwards

Re: [netmod] Request for WG adoption, draft-haas-netmod-unknown-bits-01.txt

Jeff, > On Apr 13, 2023, at 15:36, Jeffrey Haas wrote: > > Acee, > > >> On Apr 13, 2023, at 9:57 AM, Acee Lindem wrote: >>> I unclear on the "ease of use" gained by using YANG bits to define bit >>> positions. >>> IMO is would

Re: [netmod] Request for WG adoption, draft-haas-netmod-unknown-bits-01.txt

> On Apr 12, 2023, at 13:27, Andy Bierman wrote: > > > > On Wed, Apr 12, 2023 at 10:04 AM Jeffrey Haas > wrote: >> Tom, >> >> >> > On Apr 12, 2023, at 12:44 PM, tom petch > > > wrote: >> >> The reason to disconsider it is that within the

Re: [netmod] Request for WG adoption, draft-haas-netmod-unknown-bits-01.txt

Hi Jeff, So the way you offer backward compatibility is that each bit-encoded field would have two leaves, one for the known bits and one for the unknown. Then when a bit is defined and supported by a YANG model implementation, the known flags could be augmented and the corresponding unknown

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

Hi Andy, From: Andy Bierman Date: Thursday, April 14, 2022 at 12:24 PM To: Acee Lindem Cc: Martin Björklund , Juergen Schoenwaelder , "l...@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt On Thu, Apr

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

was the original intent of the base types, this is what those of us who work on software products would classify as a requirements bug. Thanks, Acee From: Andy Bierman Date: Tuesday, April 5, 2022 at 3:21 PM To: Juergen Schoenwaelder , Andy Bierman , Acee Lindem , "l...@ietf.org" , "

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

Title : YANG Model for OSPFv3 Extended LSAs Authors : Acee Lindem Sharmila Palani Yingzhen Qu Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt Pages : 29

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

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

rds Balazs -Original Message- From: Acee Lindem via Datatracker Sent: 2019. október 30., szerda 13:59 To: yang-doct...@ietf.org Cc: draft-ietf-netmod-yang-instance-file-format@ietf.org; last-c...@ietf.org; netmod@ietf.org Subject: Yangdoctors last call review

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

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

Reviewer: Acee Lindem Review result: Ready with Issues Document: draft-ietf-netmod-yang-instance-file-format-04.txt Reviewer: Acee Lindem Review Date: Oct 30st, 2019 Review Type: Working Group Last Call Intended Status: Standards Track Summary: Ready with Issues Modules: "ietf-yang-insta

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: ,

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)

this key advantage in our models. Thanks, Acee From: Alexander Vainshtein Date: Wednesday, April 3, 2019 at 3:14 AM To: Acee Lindem , Ladislav Lhotka Cc: Routing WG , "netmod@ietf.org" Subject: RE: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

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

  1   2   3   >