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

On Thu, Apr 13, 2023 at 1:27 PM Jeffrey Haas wrote: > > > On Apr 13, 2023, at 3:59 PM, Andy Bierman wrote: > It is somewhat strange to model "unknown-bits" as if it was a property of > the data model. > Protocols generally have version detection or rules (e.g. rec

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

On Thu, Apr 13, 2023 at 12:17 PM Jeffrey Haas wrote: > Andy, > > > > On Apr 12, 2023, at 1:27 PM, Andy Bierman wrote: > > I unclear on the "ease of use" gained by using YANG bits to define bit > positions. > > IMO is would be much easier to use a proto

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

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 same leaf, the value > "changes meaning" once you end up with the new identity for the value when > it's assigned and then end u

Re: [netmod] [Editorial Errata Reported] RFC8407 (7416)

idnits would not be very interesting. What is cited here are excerpt from RFC8407. > > > > Cheers, > > Med > Andy > > > *De :* Andy Bierman > *Envoyé :* vendredi 7 avril 2023 17:36 > *À :* RFC Errata System > *Cc :* BOUCADAIR Mohamed INNOV/NET ; > net

Re: [netmod] [Editorial Errata Reported] RFC8407 (7416)

Hi, This errata cites a documentation convention that was created after RFC 8407 was published. It is unfortunate that this RFC is an ad-hoc mix of YANG Usage Guidelines and IETF Documentation Guidelines. The latter is much less stable. Andy On Fri, Apr 7, 2023 at 5:50 AM RFC Errata System w

Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata

On Thu, Apr 6, 2023 at 4:09 AM tom petch wrote: > I do not know what we are talking about. Perhaps I will know if and when > I see minutes from the last IETF meeting. Meanwhile > > From: netmod on behalf of Jürgen Schönwälder > > Sent: 05 April 2023 1

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

On Tue, Mar 28, 2023 at 2:37 PM Kent Watsen wrote: > Hi Andy, > > No customer would ever let us take away this tenet, no matter what RFC > comes out. > > > What tenet? That is valid or that the representation returned > to clients is valid? > both. But I think the expectation is for non-NMDA s

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

On Sun, Mar 26, 2023 at 7:04 PM Jan Lindblad wrote: > Rob, Jürgen, Kent, WG, > > I am strongly opposed to giving up the idea that running must always be > valid. This is one of the landmark properties that has made NETCONF the > most useful management interface for network automation ever. For a

Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15

On Thu, Mar 23, 2023 at 5:11 AM tom petch wrote: > From: netmod on behalf of Jürgen Schönwälder > > Sent: 23 March 2023 11:13 > > On Wed, Mar 22, 2023 at 01:31:43PM +, Rob Wilton (rwilton) wrote: > > Hi Jürgen, > > > > Thanks for the draft. Please see my AD review comments below, except >

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

? > > > > I think there are other cases where uri could be an appropriate type to > use for a key … > > > It's just another 'pattern' to check to the YANG compiler. If 'uri' is appropriate then use it. Same goes for 'uuid'. > Thank

Re: [netmod] 答复: CORE-SID and SX:structure and draft-ietf-anima-rfc8366bis-01.txt

On Fri, Jan 13, 2023 at 9:31 AM Michael Richardson wrote: > > Andy Bierman wrote: > >> Fengchong (frank) wrote: > >> > Hi Michael, > >> > You can use augment-structure to extend a yang structure. > >> > >> You can&#x

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

e type and the length sub- > > statement is optional > > > > > > While it is true that unrestricted strings can cause an implementation > to run > > out of memory, it is also true that in some cases it is not trivial to > define the > > maximum length for a s

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

er SHOULD be used instead of string for key leafs. That does not mean yang-identifier is always the most appropriate type to use for a key. > > > I think that what I have understood would make sense > > > > Any other opinion or suggestion? > > > > Thanks, Italo

Re: [netmod] 答复: CORE-SID and SX:structure and draft-ietf-anima-rfc8366bis-01.txt

On Thu, Jan 12, 2023 at 8:10 AM Michael Richardson wrote: > > Fengchong (frank) wrote: > > Hi Michael, > > You can use augment-structure to extend a yang structure. > > You can't use augment-structure to extend in-place an existing yang > structure > Augment-structure produces a new stru

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

On Thu, Jan 12, 2023 at 8:33 AM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Thu, Jan 12, 2023 at 07:08:05AM -0800, Andy Bierman wrote: > > > > Just because the escaped string is "safe" inside a NETCONF protocol > message > >

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

gured? > > > > What is your view/opinion about using the string type in IETF standard > YANG models? > > > > Thanks, Italo > > > > *From:* Andy Bierman > *Sent:* mercoledì 21 dicembre 2022 00:30 > *To:* Martin Björklund > *Cc:* ie...@btconnect.com; netmod@

Re: [netmod] naming scope of a grouping which uses a grouping

On Mon, Dec 19, 2022 at 5:15 AM Martin Björklund wrote: > tom petch wrote: > > From: Martin Björklund > > Sent: 19 December 2022 12:18 > > To: tom petch > > > > tom petch wrote: > > > draft-ietf-opsawg-sap-12 > > > defines a grouping sap-list which uses grouping sap-entry. The > groupings are

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

On Mon, Dec 12, 2022 at 7:11 AM Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Fri, Dec 9, 2022 at 8:29 AM Acee Lindem (acee) > wrote: > > > >> Top posting to assure everyone reads: > >> > >> > >> > >> I don’t t

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

and complexity introduced by the "NMDA redo", we should be extra careful not to do that again. SDOs and vendors need a stable foundation on which to build their domain-specific data models. Thanks, > Acee > Andy > > > *From: *netmod on behalf of Andy Bierman < >

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

On Fri, Dec 9, 2022 at 7:41 AM Kent Watsen wrote: > > > The idea to encode all relevant semantics of a type in a type's name >> has far-reaching consequences: >> >> - Are we going to deprecate counter32 and introduce >> non-zero-based-counter32 because we have also zero-based-counter32? >> >> -

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

On Wed, Dec 7, 2022 at 11:42 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Thu, Dec 08, 2022 at 03:02:39AM +, Kent Watsen wrote: > > > > We are addressing the current/existing confusion, as discussed in the > last 9 months and in a virtual interim. Not doing anythi

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

On Wed, Dec 7, 2022 at 11:42 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Thu, Dec 08, 2022 at 03:02:39AM +, Kent Watsen wrote: > > > > We are addressing the current/existing confusion, as discussed in the > last 9 months and in a virtual interim. Not doing anythi

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

On Wed, Dec 7, 2022 at 7:02 PM Kent Watsen wrote: > > >> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably > the > >> most disruptive > >> change to YANG that one could make. > > No, the most disruptive thing would be to do what roughly 1/2 of the WG > was proposing before,

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

On Mon, Dec 5, 2022 at 2:37 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Mon, Dec 05, 2022 at 08:19:12PM +, Kent Watsen wrote: > > > > > > Hi Juergen, > > > > > > > > >> 3) There are two "time-with-zone-offset" typedefs (one should be > "time-without-zone-offset"?)

Re: [netmod] draft-ietf-netmod-yang-module-versioning-05: NBC Changes

x27;Where pragmatic' could be removed from the text. It implies that only people who do not want to be pragmatic need to follow the SHOULD. I do not object to the versioning work. We might even implement some of it when the RFCs get published. > Regards Balazs > Andy > > >

Re: [netmod] Deprecated/obsolete nodes and validation

On Wed, Oct 12, 2022 at 11:00 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.ste...@nokia.com> wrote: > Hi all, > > IMO an obsolete node is not in the schema: > - any mandatory statement should be ignored (i.e. it is fine for a > datastore to *not* have data for mandatory obsolete nodes) > - trying

Re: [netmod] YANG module versioning: Proposed change to "Import by derived revision"

On Tue, Oct 4, 2022 at 7:02 AM Rob Wilton (rwilton) wrote: > Hi Juergen, WG, > > draft-ietf-netmod-yang-module-versioning defines section "4. Import by > derived revision" that allows an author to specify a minimum revision of a > module that is allowed to satisfy a YANG import. > > IIRC, and ho

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

On Wed, Oct 5, 2022 at 2:07 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Wed, Oct 05, 2022 at 09:53:23AM -0700, Andy Bierman wrote: > > > > The length "64" is not random. > > https://www.rfc-editor.org/rfc/rfc7950.html#section-6.

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

On Wed, Oct 5, 2022 at 4:03 AM Ladislav Lhotka wrote: > > > Dne 05. 10. 22 v 12:01 tom petch napsal(a): > > From: netmod on behalf of Jeffrey Haas < > jh...@pfrc.org> > > Sent: 03 October 2022 20:41 > > > > [I had promised Mahesh that I'd take my comments here, but I realize > that this > > is a

Re: [netmod] YANG module versioning: Proposed change to "Import by derived revision"

On Tue, Oct 4, 2022 at 2:15 PM Randy Presuhn < randy_pres...@alumni.stanford.edu> wrote: > Hi - > > On 2022-10-04 12:15 PM, Jürgen Schönwälder wrote: > ... > > I am hoping for a technically sound solution that provides predictable > > behaviour of independently developed tools. Some "hints" that m

Re: [netmod] YANG module versioning: Proposed change to "Import by derived revision"

On Tue, Oct 4, 2022 at 12:15 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > Rob, > > I understand your attempt to find a compromise but from a technical > perspective I consider the design of computer languages where the > resolution of imports is vaguely defined and to a l

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

On Mon, Oct 3, 2022 at 12:41 PM Jeffrey Haas wrote: > [I had promised Mahesh that I'd take my comments here, but I realize that > this > is a topic that likely will result in no short term solutions. It may also > result in no action whatsoever.] > > YANG strings are bounded in length, theoretic

Re: [netmod] Schema mount support

On Mon, Sep 26, 2022 at 8:57 AM Joey Boyd wrote: > All, > > > > Does anyone on this mailing list have insight into the lack of movement > among NETCONF server implementations (both commercially available and open > source) to support schema mount? There are applications inside the access > networ

Re: [netmod] CBOR tags for Common YANG Data Types (RFC6991/bis)

On Sat, Jul 30, 2022 at 10:05 PM Carsten Bormann wrote: > On 31. Jul 2022, at 02:12, Andy Bierman wrote: > > > > leaf foo { > > type inet:ipv6-address; > > ext:cbor-type cbor:bin-ipv6-address; > > } > > This looks like the right th

Re: [netmod] CBOR tags for Common YANG Data Types (RFC6991/bis)

Hi, On Sat, Jul 30, 2022 at 1:54 PM Michael Richardson wrote: > > I had a few (well.. two) hallway conversations about RFC9164 (IPv4/IPv6) > tags > for CBOR this week. > > Specifically... in large YANG described dumps (such as a BGP FIB table) it > becomes critical not spend so many bytes on som

Re: [netmod] Answer to ORAN liason

On Wed, Jul 27, 2022 at 11:52 PM Balázs Lengyel wrote: > Hello, > > I propose we send the following statement to ORAN as an answer to their > liaison statement available at: https://datatracker.ietf.org/liaison/1785/ > I support this action. IMO these 2 drafts are the most useful and also the c

[netmod] YANG Push issues with encoding leaf

Hi, After implementation of CBOR encoding for YANG Push, I have found some minor issues in ietf-subscribed-notifications.yang (RFC 8639) 1) encode-cbor identity An identity is needed that represents draft-ietf-core-yang-cbor-20 (RFC-to-be 9254) encoding. No such standard identity exists at this t

Re: [netmod] unresolved module prefixes in grouping definitions

Hi, I think this is an error because any module that uses this grouping will fail. The prefixes are resolved in the module they are defined in, not the module they are used in. Andy On Fri, Jul 1, 2022 at 3:24 AM Vladimir Vassilev < vladi...@lightside-instruments.com> wrote: > Hi, > > Should

[netmod] draft-ietf-netmod-yang-module-versioning-05: NBC Changes

Hi, The draft-05 version has expired and is no longer on the NETMOD WG WEB page. Sec 3.1 includes this text: Where pragmatic, updates to YANG modules SHOULD be backwards- compatible, following the definition in Section 3.1.1

Re: [netmod] yang versioning solution complexity and alternative approaches

On Wed, Jun 8, 2022 at 10:04 AM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Wed, Jun 08, 2022 at 04:40:05PM +, Rob Wilton (rwilton) wrote: > > > > > > Rob, > > > > > > discussing details is likely distracting from the main difference in > > > our viewpoints so I will

Re: [netmod] yang versioning solution complexity and alternative approaches

On Tue, Jun 7, 2022 at 7:22 AM Joe Clarke (jclarke) wrote: > Thanks, Andy. We know it's been a while, and we're trying to take care of > all of these comments. See below. > > On 3/9/22 13:13, Andy Bierman wrote: > > > > On Wed, Mar 9, 2022 at 2:16 AM J

Re: [netmod] [netconf] 答复: 答复: 答复: A question about YANG identifier design

On Wed, May 25, 2022 at 1:36 AM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > I am not sure that listing specific types in a protocol specification > is what I would do for a generic solution. Anyway, people who were > actively involved in the design of RESTCONF should get in

Re: [netmod] Does defining a feature require the module be implemented?

On Mon, May 23, 2022 at 6:57 AM Kent Watsen wrote: > Hi Andy, > > I feel vindicated, but also feel that Martin is right about this being the >> solution for now. I don't even feel that it is necessarily bad. But I do >> think we should act on this in some way. Here are some options: >> >> 1) p

Re: [netmod] Does defining a feature require the module be implemented?

On Fri, May 20, 2022 at 6:15 AM Kent Watsen wrote: > Martin, Andy, > > > 2) If it is the case that the module must be implemented to use its >> > features, then I need to update some of my modules (e.g., crypto-types >> > and friends) to explicitly disable the protocol-accessible tree when >> > t

Re: [netmod] Does defining a feature require the module be implemented?

On Thu, May 19, 2022 at 12:05 AM Martin Björklund wrote: > Kent Watsen wrote: > > > > > Hmm, I don't remember why this was changed in RFC 8525. Perhaps this > was by accident? The only text I can find is this in RFC 7950: > > Not by accident. I did not want the new list. The main rationale wa

Re: [netmod] Does defining a feature require the module be implemented?

On Thu, May 19, 2022 at 12:05 AM Martin Björklund wrote: > Kent Watsen wrote: > > > > > > > On May 18, 2022, at 2:05 AM, Martin Björklund > > > wrote: > > > > > >> PS: the answer to this impacts the "crypto-types and friends" drafts > > >> in the NETCONF WG, where it is assumed (and various too

Re: [netmod] Does defining a feature require the module be implemented?

On Wed, May 18, 2022 at 10:52 PM Jan Lindblad wrote: > Andy wrote: > > A server can support a module without any protocol-accessible objects in 3 > ways >- implement the module with no features supported >- implement the module with features supported >- import the module without impl

Re: [netmod] Does defining a feature require the module be implemented?

On Wed, May 18, 2022 at 7:30 AM Kent Watsen wrote: > > > On May 18, 2022, at 2:05 AM, Martin Björklund wrote: > > PS: the answer to this impacts the "crypto-types and friends" drafts > in the NETCONF WG, where it is assumed (and various tools agreed, sans > a recent change in `yanglint`) that th

Re: [netmod] Does defining a feature require the module be implemented?

> Thanks, > Kent > > > Andy > > On May 13, 2022, at 12:04 PM, Andy Bierman wrote: > > > > On Fri, May 13, 2022 at 8:49 AM Robert Varga wrote: > >> On 13/05/2022 17:03, Kent Watsen wrote: >> > True, the current YANG Library structure

Re: [netmod] Does defining a feature require the module be implemented?

On Fri, May 13, 2022 at 8:49 AM Robert Varga wrote: > On 13/05/2022 17:03, Kent Watsen wrote: > > True, the current YANG Library structure allows features to be declared > > only for implemented modules, but I'm unsure how intentional that was. > > > > We always talk about how a module needs to b

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

On Wed, Apr 27, 2022 at 11:04 AM Randy Presuhn < randy_pres...@alumni.stanford.edu> wrote: > Hi - > > I think you've just made the argument for taking no action at all. > I do think that argument is more persuasive than the ones advanced so > far for changing deployed typedefs, and think the "no a

Re: [netmod] NBC changes and warnings

t will change or go away soon". Andy *发件人:* netmod [mailto:netmod-boun...@ietf.org] *代表 *Andy Bierman > *发送时间:* 2022年4月21日 0:30 > *收件人:* NetMod WG > *主题:* [netmod] NBC changes and warnings > > > > Hi, > > > > Before any significant NBC change can be introdu

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

On Wed, Apr 20, 2022 at 4:02 PM Acee Lindem (acee) wrote: > > > On 4/20/22, 6:35 PM, "netmod on behalf of Jürgen Schönwälder" < > netmod-boun...@ietf.org on behalf of j.schoenwael...@jacobs-university.de> > wrote: > > On Wed, Apr 20, 2022 at 02:51:35PM

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

d IP address or a DNS > domain name."; > } > > and hence they can't generally send log messages to a link-local log > server. > > /js > > On Wed, Apr 20, 2022 at 02:11:05PM -0700, Andy Bierman wrote: > > Hi, > > > > https://github.com/ope

[netmod] usage of ip-address in openconfig

Hi, https://github.com/openconfig/public Looking at the actual YANG modules, I cannot find any usage of ip-address-zoned (or any of the zoned variants). There are some places where inet:ip-address is used instead of oc-inet:ip-address. It is not clear if the intention is to allow a zone index.

[netmod] NBC changes and warnings

Hi, Before any significant NBC change can be introduced, a process needs to be in place to minimize the disruption that the NBC change will cause. Consider the recent change by GitHub to remove support for SSH passwords and require keys instead. They warned people for about 2 years this change w

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

On Tue, Apr 19, 2022 at 1:26 AM Jan Lindblad wrote: > Balázs, Qin, WG, > > >> - for each extension statement the following should be described > >> + Changing this extension statement is a backwards-compatible change > >> yes/no/editorial-only > > [Qin Wu] Can you provide an example for this iss

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

On Fri, Apr 15, 2022 at 12:25 PM Randy Presuhn < randy_pres...@alumni.stanford.edu> wrote: > Hi - > > I took a fresh look at RFC 6991, and a couple of things that have > already been mentioned in this thread bear repetition. > > (1) in both the ipv4-address and ipv6-address typdefs, the zone > is

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

On Fri, Apr 15, 2022 at 9:44 AM tom petch wrote: > From: netmod on behalf of Andy Bierman < > a...@yumaworks.com> > Sent: 14 April 2022 22:25 > > On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn < > randy_pres...@alumni.stanford.edu<mailto:randy_pres...@alumni.stanfor

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

On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn < randy_pres...@alumni.stanford.edu> wrote: > Hi - > > On 2022-04-14 1:33 PM, Andy Bierman wrote: > > > > > > On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder > > > <mailto:j.schoenwael...@jacobs-univ

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

On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote: > > > The proposal is for a 2 year phase to change modules > > that really do want a zone index. It is not b

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

On Thu, Apr 14, 2022 at 12:38 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Thu, Apr 14, 2022 at 09:23:38AM -0700, Andy Bierman wrote: > > > > > So is this a correct summary: > > > > - zone index is not used in IPv4 at all > >

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

On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee) 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 default types and defining > ipv4z and

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 petch wrote: > From: netmod on behalf of Rob Wilton (rwilton) > > Sent: 11 April 2022 18:06 > > Hi all, > > Thanks for the comments on this thread so far. It would be nice if we are > able to come to some sort of rough consensus to a solution. > > I think th

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

On Tue, Apr 12, 2022 at 7:45 AM Kent Watsen wrote: > > > For me, the only sensible option (other than accepting that types are > named the way they are) is to introduce ip-address-with-zone and to > deprecate ip-address and stop there. Yes, this means coexistance of > inet:ip-address and ip-addre

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 wrote: > Hi, > > Here's another suggestion. We keep the ip-address pattern as is, but > document in the description that implementations do not have to > support the optional zone index. This would essentially document the > behavior of most cur

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

eal (as this thread clearly demonstrates). There are corner-cases where an incompatible change is the least worst solution. > Randy > > Andy > > Yours, > > Joel > > > > On 4/11/2022 1:28 PM, Andy Bierman wrote: > >> > >> > >> On Mon, Apr

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

On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) wrote: > Hi all, > > Thanks for the comments on this thread so far. It would be nice if we are > able to come to some sort of rough consensus to a solution. > > I think that there is consensus that the YANG type ip-address (and the > v4/v6 ve

[netmod] new extensions in draft-ietf-netmod-node-tags-06

Hi, I do not find this draft useful. I am curious about the extensions introduced. It looks like all containers and lists are tagged as 'object'. All config=true terminals are tagged as 'property' and perhaps all config=false terminals are tagged as 'metric' (although the example shows a config=t

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

he unsnipped email below. > > > > *From: *netmod on behalf of Andy Bierman < > a...@yumaworks.com> > *Date: *Saturday, April 9, 2022 at 1:38 PM > *To: *Randy Presuhn > *Cc: *"l...@ietf.org" , "netmod@ietf.org" > *Subject: *Re: [netmod] [Lsr] I-D

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

On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn < randy_pres...@alumni.stanford.edu> wrote: > Hi - > > On 2022-04-09 4:36 AM, Christian Hopps wrote: > ... > > FWIW, I'm not arguing for this change; however, to be fair, isn't this > > also about the existing published modules that are using the incorr

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

On Thu, Apr 7, 2022 at 10:01 AM Martin Björklund wrote: > Andy Bierman wrote: > > On Thu, Apr 7, 2022 at 9:11 AM tom petch wrote: > > > > > From: Lsr on behalf of Rob Wilton (rwilton) > > > > > > Sent: 07 April 2022 10:25 > > > > > >

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

o-zone, and ipv6-address-no-zone types and add *-zone types > for the remote possibility that someone actually wants to include the > zone. In the existing RFC 6991 BIS document, we could merely remove the > zone from the ip-address, ipv4-address, and ipv6-address types and classify >

Re: [netmod] IETF WG state changed for draft-ietf-netmod-rfc6991-bis

On Thu, Apr 7, 2022 at 8:31 AM Kent Watsen wrote: > > Hi Juergen, > > On Apr 7, 2022, at 3:13 AM, Jürgen Schönwälder < > j.schoenwael...@jacobs-university.de> wrote: > > On Wed, Apr 06, 2022 at 05:49:26PM -0700, IETF Secretariat wrote: > > > The IETF WG state of draft-ietf-netmod-rfc6991-bis has

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

On Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman wrote: > > > > > > The best outcome would be to fix ip-address to not include the zone, > > > introdu

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

On Tue, Apr 5, 2022 at 8:45 AM Acee Lindem (acee) wrote: > > > On 4/5/22, 11:37 AM, "Lsr on behalf of Jürgen Schönwälder" < > lsr-boun...@ietf.org on behalf of j.schoenwael...@jacobs-university.de> > wrote: > > On Tue, Apr 05, 2022 at 01:48:25PM +, Acee Lindem (acee) wrote: > > [wg-m

Re: [netmod] RPC input parameter definition order (uses augment)

On Mon, Apr 4, 2022 at 4:48 AM Jernej Tuljak wrote: > On 01/04/2022 15:49, Andy Bierman wrote: > > > > On Fri, Apr 1, 2022 at 4:24 AM Kent Watsen wrote: > >> >> Hi Jernej, >> >> > RFC7950, 7.14.4. says: >> > >> >Input

Re: [netmod] [Errata Held for Document Update] RFC8407 (6899)

always been correct. Only the name was wrong. > > We intended to include the text provided. If people follow the guidelines in Appendix A now, and use the word "Simplified", it is going to need to be fixed later. Better to avoid that if possible. R's, > John > Andy >

Re: [netmod] RPC input parameter definition order (uses augment)

On Fri, Apr 1, 2022 at 4:24 AM Kent Watsen wrote: > > Hi Jernej, > > > RFC7950, 7.14.4. says: > > > >Input parameters are encoded as child XML elements to the rpc node's > >XML element, in the same order as they are defined within the "input" > >statement. > > > > For the following mo

Re: [netmod] [Errata Held for Document Update] RFC8407 (6899)

On Thu, Mar 31, 2022 at 9:56 AM John R. Levine wrote: > > There are not thousands of RFCs that include a "Module Review Checklist" > :-), which is the purpose of this erratum. Thanks. > > > > > > > > I agree. There may be lots of RFC in error because RFC8407 gets it > wrong but if the update to

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

Hi, I read the -02 draft. It does not conflict with RFC 8407. I don't think sec 3, para 3 is really needed, but the guideline to document the reasoning behind using enum vs. identity is more relevant for IANA modules than other modules. Andy On Fri, Mar 25, 2022 at 8:05 AM wrote: > Re-, > > T

Re: [netmod] [CCAMP][TEAS][NETMOD] Efficiency issues with YANG model data in integration

On Fri, Mar 25, 2022 at 3:17 PM Robert Varga wrote: > On 17/03/2022 17:32, tom petch wrote: > > > > When the data definition language that we know as YANG was being > specified, the question did arise of how object-oriented it should be and > the consensus was that it should not be. Seeking to

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

a SHOULD, not a MUST. > Regards Balazs > Andy > > > *From:* Jan Lindblad > *Sent:* Thursday, 24 March, 2022 21:38 > *To:* Andy Bierman ; Balázs Lengyel < > balazs.leng...@ericsson.com>; Kent Watsen > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] Comm

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

t with user-provided rule-lists. > Balazs > Andy > > > *From:* maqiufang (A) > *Sent:* Thursday, 24 March, 2022 15:23 > *To:* Andy Bierman > *Cc:* Balázs Lengyel ; Kent Watsen < > kent+i...@watsen.net>; NETMOD Group > *Subject:* RE: [netmod] Alt

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

the operator would be confused. This problem exists no matter what external (AND PURELY OPTIONAL) statement is used. > > Best Regards, > > Qiufang > Andy > > > *From:* netmod [mailto:netmod-boun...@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Thursday, March 2

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

On Wed, Mar 23, 2022 at 4:33 PM Balázs Lengyel wrote: > *From:* Kent Watsen > *Sent:* Thursday, 24 March, 2022 00:05 > *To:* Balázs Lengyel > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] Common etag, timestamp on all interfaces > (draft-lindblad-netconf-transaction-id) > > > > > > > > I assu

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel wrote: > > > > > *From:* Andy Bierman > *Sent:* Wednesday, 23 March, 2022 22:32 > *To:* Balázs Lengyel > *Cc:* NetMod WG > *Subject:* Re: [netmod] Alternative approach to > draft-ma-netmod-immutable-flag-00 > >

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

e work to undo the extension used in an ancestor node. This impacts the extension usage within a grouping. Regards Balazs > Andy > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Wednesday, 23 March, 2022 21:10 > *To:* NetMod WG > *Subject:* [netmod] Alternativ

[netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi, IMO the problem should be viewed as a refinement to the access control policy of the device. A standard mechanism such as a YANG extension would be better than a growing mix of proprietary solutions. We have such a YANG extension called "user-write" that is widely deployed. A simple boolean

Re: [netmod] [Technical Errata Reported] RFC7950 (6885)

On Wed, Mar 16, 2022 at 1:44 PM Randy Presuhn < randy_pres...@alumni.stanford.edu> wrote: > Hi - > > On 2022-03-15 11:13 PM, Jürgen Schönwälder wrote: > > YANG update rules expect clients to be lenient about values they > > received but did not expect. It is possible to debate that design > > choi

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

On Tue, Mar 15, 2022 at 6:01 AM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Mon, Mar 14, 2022 at 05:21:01PM -0700, Andy Bierman wrote: > > On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen > wrote: > > > > > All, > > > > >

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

On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen wrote: > All, > > 1) If you provided WGLC comments on this draft, please review the -12 diff > to > ensure that the updates made are good. > > 2) Juergen notes below that he also r

Re: [netmod] yang versioning solution complexity and alternative approaches

On Wed, Mar 9, 2022 at 2:16 AM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > Hi, > > the YANG versioning solution appears to be complex. > > strongly agree. There are many new procedures (for using extensions) that are not likely to be adopted outside of the IETF/ There was

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

n, allowing conformance requirements to be properly expressed Rob > > // As an individual contributor > > > > > Andy > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* 03 March 2022 16:56 > *To:* William Lupton > *Cc:* NetMod WG > *Subject:* Re: [ne

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

And for revision labels: > > > > Revision labels MUST be unique amongst all revisions of a > > module or submodule. > > > > Regards, > > Rob > > // As an author/contributor. > > > > > > > > *From:* netmod *On Behalf Of *Andy Bierman >

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

do not work. Andy > On Tue, 1 Mar 2022 at 14:49, Andy Bierman wrote: > >> >> I think that this should be fixed. What's the best way to achieve this? >>> >> >> I think this issue should be resolved as well. >> >

Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

On Tue, Mar 1, 2022 at 8:15 AM Carsten Bormann wrote: > (Removing RFC-editor from the list:) > > On 2022-03-01, at 16:42, SADOVNIKOV, ALEXEI wrote: > > > > I continue to doubt if this optimization continues to have value in > presence of JSON processing, where such optimization is not possible.

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

On Tue, Mar 1, 2022 at 4:54 AM William Lupton wrote: > All, > > Sorry if (as is quite likely) this is a duplicate. > > I noticed from > https://yangcatalog.org/private-page/BBFYANGPageCompilation.html that > there's a (long-standing?) problem in iana-if-type.yang >

Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

to resolve that ambiguity). > > > > Jason > > > > From: SADOVNIKOV, ALEXEI > > Sent: Friday, February 25, 2022 4:15 PM > > To: Sterne, Jason (Nokia - CA/Ottawa) ; Rob > Wilton (rwilton) ; Andy Bierman > > Cc: Kent Watsen ; m...@tail-f.com; > war...@kumar

Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

On Fri, Feb 25, 2022 at 8:21 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.ste...@nokia.com> wrote: > Hi all, > > > > There is an interesting consequence of the wording for lists. > > > > > The list's key nodes are encoded as subelements to the list's > > > identifier element, in the same o

<    1   2   3   4   5   6   7   8   9   10   >