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 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] 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

[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

[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.

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

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] 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] [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] 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] 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 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?

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 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 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 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 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] [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] 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] 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

[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] 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] 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] 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

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] 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] 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] [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] 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 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-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-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 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] 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] 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] 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] 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 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 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

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 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] 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] 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] 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] 答复: 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)

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] 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] 答复: 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)

? > > > > 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] 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] 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] 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] [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] [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] [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] 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] 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 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 1:48 PM Jeffrey Haas wrote: > Andy, > > On Apr 13, 2023, at 4:42 PM, Andy Bierman wrote: > >> >> Repeating my question to Acee... did you read the draft? This isn't a >> theoretical use case. >> > > Seeing no response, I&#x

Re: [netmod] Unknown bits - backwards compatibility

On Thu, Apr 13, 2023 at 2:00 PM Jason Sterne (Nokia) wrote: > Hi Jeff, > > > > We avoided getting into subtleties about “severity” of an NBC change (hard > enough to just get agreement on basic rules). But I do think it is useful > to come up with changes and approaches that have lower impact on

Re: [netmod] Unknown bits - backwards compatibility

g to make an NBC change to fix a mistake. Quite another to use NBC changes are part of the data model design. Jason > Andy > > > -Original Message- > > From: Jürgen Schönwälder > > Sent: Friday, April 14, 2023 2:12 AM > > To: Andy Bierman > > Cc: Ja

Re: [netmod] Unknown bits - backwards compatibility

On Fri, Apr 14, 2023 at 7:33 AM Italo Busi wrote: > Hi Jeff, > > > > I agree with you on the preference for hex-string versus binary in YANG > > > > I also agree with you concerns with hexdump, but parsing has some issues > when something is unknown (these are the issues that have triggered your

Re: [netmod] Unknown bits - backwards compatibility

On Fri, Apr 14, 2023 at 11:45 AM Jürgen Schönwälder wrote: > On Fri, Apr 14, 2023 at 03:23:03PM +, 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.

Re: [netmod] WGLC on node-tags-09

On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen wrote: > This email begins a two-week WGLC on: > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09 > > Please take time to review this draft and post comments by May 2nd. > Favorable comments are especially welcomed. > > I have re

Re: [netmod] WGLC on node-tags-09

Hi, Adding a couple missed comments inline... On Wed, Apr 19, 2023 at 11:38 AM Andy Bierman wrote: > > > On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen wrote: > >> This email begins a two-week WGLC on: >> >> >> https://datatracker.ietf.org/doc/html/draft-i

Re: [netmod] ietf-yang-types:date-and-time canonical value

On Mon, Apr 24, 2023 at 7:48 AM Carsten Bormann wrote: > On 2023-04-24, at 14:20, Michal Vasko wrote: > > > > canonical > > Hi Michal, > > I don’t know what exactly “canonical” means here. > >From the date-and-time typedef: The canonical format for date-and-time values with a known time

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

On Tue, Apr 25, 2023 at 6:15 AM Jürgen Schönwälder wrote: > On Tue, Apr 25, 2023 at 12:46:05PM +, Kent Watsen wrote: > > > > > > > Which merge fails? > > > > + = > > So far this merge step does not exist (and it may be bad if it would > exist). The WGs need to think very careful about intr

[netmod] Comments on draft-ietf-netmod-yang-module-versioning-09

Hi, Most of the document focuses on the administrative details that will be required to update a YANG module. (Lots of them). My concern is with YANG 1.1 Co-existence and deployment of this new RFC. (Sec 3.1) https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#secti

Re: [netmod] Clarify the meaning of property in RFC7950

Hi, On Sat, May 13, 2023 at 12:02 PM Jason Sterne (Nokia) < jason.ste...@nokia.com> wrote: > Hi Frank, > > > > The table just after the text has this: > > > > +--+--+-+ > >| substatement | section | cardinality | > >+---

Re: [netmod] Comments on draft-ietf-netmod-yang-module-versioning-09

odule versioning draft also updates that the change from current or > deprecated to obsolete is NBC. Going “obsolete” is an impact to a client. > > > > Jason > > > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Tuesday, May 9, 2023 2:06 PM > *To:

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

On Tue, May 16, 2023 at 11:10 AM Robert Varga wrote: > On 09/05/2023 00.49, Kent Watsen wrote: > > Dear NETMOD WG, > > > > This message begins a joint two-week WGLC for > draft-ietf-netmod-yang-semver-11 and > draft-ietf-netmod-yang-module-versioning-09 > > ending on Monday, May 22nd. Neither

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

On Tue, May 30, 2023 at 5:13 PM Robert Varga wrote: > On 30/05/2023 20.28, Jürgen Schönwälder wrote: > >It is unclear what "identical" means here. If two people extract a > >module from an RFC, they may not end up with identical byte > >sequences. So does white space matter when we ta

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

On Wed, May 31, 2023 at 12:50 AM Jürgen Schönwälder wrote: > On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote: > > On 30/05/2023 20.28, Jürgen Schönwälder wrote: > > >It is unclear what "identical" means here. If two people extract a > > >module from an RFC, they may not end u

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

On Wed, May 31, 2023 at 3:12 AM Andy Bierman wrote: > > > On Wed, May 31, 2023 at 12:50 AM Jürgen Schönwälder > wrote: > >> On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote: >> > On 30/05/2023 20.28, Jürgen Schönwälder wrote: >> > >It

Re: [netmod] Query RFC-8348 hardware model

Hi, No changes are needed. The notification definition says each leaf will be set to a value that matches an instance of the leafref path. The 'current()' linkage in your example links the sibling 'ifname' leaf to select a matching instance. That is not relevant to this notification example. And

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

On Thu, Jun 1, 2023 at 1:55 PM Kent Watsen wrote: > Hi Quifang, > > The latest update looks very good to me - IMO, ready for adoption. > > Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been > addressed? > > IMO the problem statement and solution are still rough and unclear. Th

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

On Sun, Jun 4, 2023 at 7:01 AM Kent Watsen wrote: > As an individual contributor and faithful YANG custodian, I cannot > support work that changes YANG-semantics without versioning YANG itself. > As Andy wrote before: > > The only correct way to remove MUST/MUST NOT from the "YANG contract" >

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

On Mon, Jun 5, 2023 at 5:32 AM Jürgen Schönwälder wrote: > On Mon, Jun 05, 2023 at 12:07:49PM +, Kent Watsen wrote: > > > > Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next > design team, asked to produce a limited-scope I-D they think best. > WG-objections of the form "m

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

On Wed, Jun 7, 2023 at 12:22 AM Martin Björklund wrote: > Hi, > > But the two drafts go way beyond fixing the problem your three > examples illustrate. If the goal is to indicate that non-backwards > compatible changes have occured, a single new extension statement > could solve that. (As I pro

[netmod] Module updates in imported modules

Hi, It is not clear how the new drafts work for changes in imported groupings. This is a very common design pattern. module A { // version 1.0.0 grouping A { leaf one { type string; } leaf two { type string; } } } module A { // version 1.1.0 grouping A { l

Re: [netmod] Module updates in imported modules

= sid-file-version=1 - module C using A(2.0.0) == sid-file-version=2 It is valid for a server to use any 1 of the 3 revisions of module A. Of course, this is a "hello world" example. A "real world" example will be much more complicated. Allowing NBC changes to YANG makes the p

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

ions are useful to YANG 1.0 and YANG 1.1 > modules. > > > > I still feel the work is a good practical step forward for the YANG > ecosystem. > > > > Jason > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Wednesday, June 7, 2023 4:49 PM > *

Re: [netmod] Module updates in imported modules

by seeing where that grouping is used, > whether the client uses those nodes, etc). > Perhaps an example showing an NBC change to an imported module should be added. > > Jason > Andy > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Friday, June 9,

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

YANG 1.2 is ever developed then the module update rules can officially change. Jason > > > Andy > *From:* Andy Bierman > *Sent:* Tuesday, June 13, 2023 12:45 PM > *To:* Jason Sterne (Nokia) > *Cc:* Martin Björklund ; rwilton= > 40cisco@dmarc.ietf.org; netmod@i

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

On Wed, Jun 14, 2023 at 3:00 AM Martin Björklund wrote: > "Rob Wilton (rwilton)" wrote: > > Hi Martin, > > > > > -Original Message- > > > From: netmod On Behalf Of Martin Björklund > > > Sent: 07 June 2023 08:22 > > > To: rwilton=40cisco@dmarc.ietf.org > > > Cc: netmod@ietf.org > >

[netmod] questions about revision-label-scheme extension

Hi, It is not really clear how this extension works. This extension is used to specify the format and semantics of the 'label' and 'recommended-min' argument string contents. Q1) What specific requirements (if any) are being addressed by this solution? https://datatracker.ietf.org/doc/html/draft-

Re: [netmod] WGLC on node-tags-09

On Mon, Jun 26, 2023 at 2:34 AM Qin Wu wrote: > Andy: > > Sorry for late followup, please see my reply inline below. > > > > *发件人:* netmod [mailto:netmod-boun...@ietf.org] *代表 *Andy Bierman > *发送时间:* 2023年4月20日 2:39 > *收件人:* Kent Watsen > *抄送:* netmod@ietf.org >

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund wrote: > What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules > > This is the approach I also suggested on the mailing list. > - As it works today; the IETF *has* published bugfixed modules that break > the > rules. (and many ve

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

blank check using the current "MAY" (3.1, para 2) is not a good idea. Jason > Andy > > > *From:* Andy Bierman > *Sent:* Wednesday, July 19, 2023 1:13 PM > *To:* Martin Björklund > *Cc:* Jason Sterne (Nokia) ; netmod@ietf.org > *Subject:* Re: [netmod

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

ll of the YANG update rules. Changing the normative text to SHOULD NOT instead of MAY does not require any specification of a bugfix. Regards Balazs > Andy > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Wednesday, 19 July, 2023 10:13 > *To:* Martin Björklund >

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

ole out a new version of the modules every few months. These can not > > live without some NBC changes. > > A more fine grained versioning system is required. > > > > Regards Balazs > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Th

Re: [netmod] YANG Versioning: Key Issues #2 and #3 - revision labels

On Sun, Jul 23, 2023 at 6:52 PM Balázs Lengyel wrote: > Hello, > > While I fully agree with Jason’s comments, I would like to state both as > an Ericsson guy and as a 3GPP delegate that for us Key issue 2 (multiple > label schemes) is not important. The only important point is that it should > b

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

t; IMO using both MAY and SHOULD NOT is confusing and unnecessary. "SHOULD > NOT" allows a thing while discouraging it. > > Thanks, > Chris. > > Andy > > > > be agreeable? > > > > Regards Balazs > > > > > > > > From:

Re: [netmod] [core] WG Last Call on draft-ietf-core-comi-16

Hi, I have some minor comments about this draft. I did not find any major issues. It is almost ready for publication. Andy # comments on draft-ietf-core-comi-16 ## sec 2.3 Examples of each media type would be helpful here ## sec 2.4 It is not clear how any interoperability would be possib

Re: [netmod] WG Last Call on draft-ietf-core-sid-21

Hi, I do not have time to do another full review of this draft. These are high-level comments. ## document scope is too large The draft should be split into 2 or 3 drafts. 1) SID File Definition 2a) SID Management Procedures 2b) Initial SID File Definitions ## document scope is not CORE-specif

Re: [netmod] Adoption poll for draft-ma-netmod-immutable-flag-08

On Tue, Sep 5, 2023 at 5:42 AM Kent Watsen wrote: > NETMOD WG, > > This email begins a 2-week adoption poll for: > https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/08 > > There is no known IPR on this draft (IPR call >

Re: [netmod] [core] WG Last Call on draft-ietf-core-sid-21

On Sun, Sep 10, 2023 at 11:59 AM Michael Richardson wrote: > > Andy Bierman wrote: > > I do not have time to do another full review of this draft. > > These are high-level comments. > > > ## document scope is too large > > > The draf

Re: [netmod] Poll on YANG Versioning NBC Approach

On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen wrote: > WG, > > Please help the YANG-versioning effort move forward by participating in > the following poll: > > - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login > required) > > The draft proposed to change many specific MUST and

Re: [netmod] Poll on YANG Versioning NBC Approach

On Tue, Sep 12, 2023 at 8:54 AM Reshad Rahman wrote: > > > On Tuesday, September 12, 2023, 11:23:55 AM EDT, Andy Bierman < > a...@yumaworks.com> wrote: > > > > > On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen wrote: > > WG, > > Please help the YANG-ve

  1   2   3   4   5   6   7   8   9   10   >