[{"author": "Jan Lindblad", "text": "

Yes, clearly better

", "time": "2023-03-31T00:30:00Z"}, {"author": "Robert Wilton", "text": "

I've have reviewed rfc6991-bis, but Kent is right that Juergen/WG is waiting on me for a response, which should be soon.

", "time": "2023-03-31T00:36:25Z"}, {"author": "Michael Richardson", "text": "

Sounds like all the issues that YANG-CORE has had to deal with.

", "time": "2023-03-31T00:54:51Z"}, {"author": "Robert Wilton", "text": "

Another way of thinking about this is something like the difference between runtime compatibility vs compile time compatibility [as a contributor]

", "time": "2023-03-31T00:55:37Z"}, {"author": "Michael Richardson", "text": "

I assume counter_t has more bits of precision than uint8_t :-)

", "time": "2023-03-31T00:58:27Z"}, {"author": "Jason Sterne", "text": "

We probably need to more carefully define that example. We're still debating a lot of these cases in the weekly calls and haven't worked through all the details.

", "time": "2023-03-31T00:59:33Z"}, {"author": "Per Andersson", "text": "

It was a bit contrived example, and not presented in full, but the idea is that the base type for counter_t is uint8

", "time": "2023-03-31T00:59:39Z"}, {"author": "Jason Sterne", "text": "

In that case, we might not classify that as NBC even in the schema algorithm.

", "time": "2023-03-31T01:00:15Z"}, {"author": "Jason Sterne", "text": "

But if we rename a typedef that is being used by that leaf, then that would be NBC in the schema algorithm.

", "time": "2023-03-31T01:00:40Z"}, {"author": "Michael Richardson", "text": "

Ah so, uint8_t -> counter_t is just a change of typedef, not increased number of bits. CBOR, JSON and XML mostly do not care about the transfer.

", "time": "2023-03-31T01:01:08Z"}, {"author": "Christian Hopps", "text": "

integers and strings are strings in xml

", "time": "2023-03-31T01:10:40Z"}, {"author": "Alex Huang Feng", "text": "

Shouldn't the encodings be covered by other rfc such as yang-CBOR or yang-json ?

", "time": "2023-03-31T01:11:11Z"}, {"author": "Christian Hopps", "text": "

and very different things in binary :)

", "time": "2023-03-31T01:11:14Z"}, {"author": "Michael Richardson", "text": "

yang-CBOR is RFC9254.

", "time": "2023-03-31T01:13:05Z"}, {"author": "Jason Sterne", "text": "

The encodings are covered elsewhere, but what we define as NBC in the on-wire algorithm will have to take into account all the encodings that we want to consider. (which should include CBOR, gRPC IMO)

", "time": "2023-03-31T01:14:43Z"}, {"author": "Lou Berger", "text": "

(as contributor) I'm very warry of going down a path where yang ends up being encoding \"aware\"

", "time": "2023-03-31T01:14:44Z"}, {"author": "Christian Hopps", "text": "

It seems to me that \"on-wire\" compatability has a lot to do with the chosen transports encoding

", "time": "2023-03-31T01:14:52Z"}, {"author": "Christian Hopps", "text": "

it might even be the definition of \"on-wire\"

", "time": "2023-03-31T01:15:21Z"}, {"author": "Jason Sterne", "text": "

Maybe. But what if we said the only differences for on-wire is that it ignores typedef name changes & grouping name changes (at the limit)

", "time": "2023-03-31T01:15:40Z"}, {"author": "Carsten Bormann", "text": "

Now is it 1400 UTC or 1400 UK time?

", "time": "2023-03-31T01:16:01Z"}, {"author": "Carsten Bormann", "text": "

(GMT is a colloquial term only, used for UK winter time.)

", "time": "2023-03-31T01:16:24Z"}, {"author": "Joe Clarke", "text": "

The meeting will be 1500 now for the UK, 1400 UTC if my math is right.

", "time": "2023-03-31T01:17:38Z"}, {"author": "Jason Sterne", "text": "

We should check and update the WG list. The meeting may have been rebooked in EST at some point.

", "time": "2023-03-31T01:18:09Z"}, {"author": "Jason Sterne", "text": "

I'll check on that.

", "time": "2023-03-31T01:18:23Z"}, {"author": "Carsten Bormann", "text": "

EST or ET?

", "time": "2023-03-31T01:18:29Z"}, {"author": "Carsten Bormann", "text": "

(ET is EDT now)

", "time": "2023-03-31T01:18:40Z"}, {"author": "Joe Clarke", "text": "

Yep. It's 10:00 am EDT on my calendar.

", "time": "2023-03-31T01:18:51Z"}, {"author": "Joe Clarke", "text": "

The on-wire (as Jason mentioned) is more of, \"will this break the client\". And one open question is still config v. oper. So on-wire has been initially construed as will it break the client from a config standpoint.

", "time": "2023-03-31T01:20:21Z"}, {"author": "Carsten Bormann", "text": "

Maybe having an .ics somewhere might help...

", "time": "2023-03-31T01:20:30Z"}, {"author": "Bal\u00e1zs Lengyel", "text": "

referenced by instance-identifier should be considered

", "time": "2023-03-31T01:25:39Z"}, {"author": "Bal\u00e1zs Lengyel", "text": "

If autocopy is deferred, configuring nodes below it might be impossible

", "time": "2023-03-31T01:27:07Z"}, {"author": "Joe Clarke", "text": "

@Carsten sent one to netmod@

", "time": "2023-03-31T01:27:30Z"}, {"author": "Carsten Bormann", "text": "

Thanks. This came in as 09:00-04:00, which is 1300Z.

", "time": "2023-03-31T01:30:36Z"}, {"author": "Joe Clarke", "text": "

Ahh! My brain is still foggy this morning. I have a regular sync up meeting at 10:00 am on Mondays. This one is 9:00 am ET on Tuesday. The ICS is correct.

", "time": "2023-03-31T01:32:20Z"}, {"author": "Michael Richardson", "text": "

I didn't understand your document before, your slide makes it clearer. I will think on how I would be less confused.

", "time": "2023-03-31T01:32:20Z"}, {"author": "Mohamed Boucadair", "text": "

Why pointing to Section 3.7 of rfc8407 wouldn't sufficient ?

", "time": "2023-03-31T01:33:52Z"}, {"author": "Michael Richardson", "text": "

Does the revision of the wiki require an RFC? Why?

", "time": "2023-03-31T01:35:52Z"}, {"author": "Christian Hopps", "text": "

And RFC

", "time": "2023-03-31T01:35:58Z"}, {"author": "Christian Hopps", "text": "

An RFC is what they want

", "time": "2023-03-31T01:36:07Z"}, {"author": "Jeffrey Haas", "text": "

I\u2019m surprised external organizations are satisfied with something as unstable as a wiki.

", "time": "2023-03-31T01:36:58Z"}, {"author": "Christian Hopps", "text": "

Jeff, they aren't that's what this presentation is saying :)

", "time": "2023-03-31T01:37:27Z"}, {"author": "Christian Hopps", "text": "

they want a document not a wiki

", "time": "2023-03-31T01:37:36Z"}, {"author": "Jeffrey Haas", "text": "

I clearly missed that intent. What I thought I understood was seeing if referring to the wiki was fine.

", "time": "2023-03-31T01:38:14Z"}, {"author": "Lou Berger", "text": "

me too

", "time": "2023-03-31T01:38:25Z"}, {"author": "Christian Hopps", "text": "

Yes, it was stated a little confusingly

", "time": "2023-03-31T01:38:44Z"}, {"author": "Christian Hopps", "text": "

They want a document.

", "time": "2023-03-31T01:38:53Z"}, {"author": "Christian Hopps", "text": "

They did say this in the presentation but not forcefully/clearly.

", "time": "2023-03-31T01:39:17Z"}, {"author": "Jeffrey Haas", "text": "

What I would expect is an external organization would want license to borrow our text and then fork for their own internal processes

", "time": "2023-03-31T01:40:37Z"}, {"author": "Jeffrey Haas", "text": "

Rather than refer to us.

", "time": "2023-03-31T01:40:48Z"}, {"author": "Kathleen Moriarty", "text": "

@Christian, three is a link that I need to fix the xref and then this is more clear int he document. It's in the XML and will be fixed.

", "time": "2023-03-31T01:42:53Z"}, {"author": "Christian Hopps", "text": "

Well I understood you... :) I think someone else made a comment about the document.

", "time": "2023-03-31T01:43:48Z"}, {"author": "Joe Clarke", "text": "

Speaking of XML, there is likely some tooling asks here to ensure the TEMPLATE TEXT markers are added and the text is consistent within those tags, yes?

", "time": "2023-03-31T01:44:01Z"}, {"author": "Lou Berger", "text": "

FYI Poll coming on slide 9

", "time": "2023-03-31T01:45:34Z"}, {"author": "Bal\u00e1zs Lengyel", "text": "

speak up please

", "time": "2023-03-31T01:50:13Z"}, {"author": "Jan Lindblad", "text": "

The requirements to serve 3GPP and ITU can be fulfilled without removing core YANG principles

", "time": "2023-03-31T01:54:32Z"}, {"author": "Christian Hopps", "text": "

i voted from outside the room :)

", "time": "2023-03-31T01:54:38Z"}, {"author": "Michael Richardson", "text": "

\"You Have No Tea\"

", "time": "2023-03-31T01:58:31Z"}, {"author": "Bal\u00e1zs Lengyel", "text": "

It is a new rule for compatibility

", "time": "2023-03-31T01:59:59Z"}, {"author": "Jason Sterne", "text": "

I'm not sure we want to have a specific compatibility rule for this specific typedef? Does that not become a bit of a slippery slope?

", "time": "2023-03-31T02:06:14Z"}, {"author": "Jason Sterne", "text": "

(although I can see the desire for this case...)

", "time": "2023-03-31T02:06:31Z"}, {"author": "Jason Sterne", "text": "

We hit a number of situations during our YANG Versioning work where we said \"yeah - but for this particular case, it could be considered backwards compatible\". But then we decide to try and keep the rules simple & mostly aligned with 7950 rather than document too many indivdual BC cases. Maybe this is a similar situation and should just be considered NBC. It will be flagged, the client/user can look at it and decide they don't really care. (vs not flagging it as NBC).

", "time": "2023-03-31T02:10:03Z"}, {"author": "Beno\u00eet Claise", "text": "

This is great work. Applause to Mahesh and Jeff. We have been lacking this YANG coordination at the IETF. You are defining the first YANG package.

", "time": "2023-03-31T02:14:05Z"}, {"author": "Joe Clarke", "text": "

The way I read the draft, I'm not sure we'd need a special rule for this. Old clients would still work provided the server still accepted the new bit as unknown.

", "time": "2023-03-31T02:14:06Z"}, {"author": "Qin Wu", "text": "

@Mahesh, do we have strong agreement to delegate thing to IANA? would it be great to provide more examples to help understand how this practice is excercised

", "time": "2023-03-31T02:14:40Z"}, {"author": "Joe Clarke", "text": "

+1 on the BGP work. Also interesting to see the OC \"donation\".

", "time": "2023-03-31T02:14:42Z"}, {"author": "Beno\u00eet Claise", "text": "

Next, we'll follow the same process for the topology-related YANG modules (what we call the Digital Map)

", "time": "2023-03-31T02:15:05Z"}, {"author": "Qin Wu", "text": "

@Mahesh BTW, it is a good work.

", "time": "2023-03-31T02:15:23Z"}, {"author": "Jeffrey Haas", "text": "

Thanks for the supportive words. Enabling better work is a useful goal.

", "time": "2023-03-31T02:16:18Z"}, {"author": "Lou Berger", "text": "

straw poll - should we have an interim to discuss lessons learned?

", "time": "2023-03-31T02:17:14Z"}, {"author": "Qin Wu", "text": "

@jeff,:grinning:, thank you too.

", "time": "2023-03-31T02:17:18Z"}, {"author": "Lou Berger", "text": "

BGO

", "time": "2023-03-31T02:17:22Z"}, {"author": "Lou Berger", "text": "

sigh, BGP lessons learned

", "time": "2023-03-31T02:17:38Z"}, {"author": "Qin Wu", "text": "

I think it is a good idea, I have resonance on packing model for test and validation. We have see a lot of initiate to do this.

", "time": "2023-03-31T02:18:40Z"}, {"author": "Jeffrey Haas", "text": "

Joe Clarke said:

\n
\n

+1 on the BGP work. Also interesting to see the OC \"donation\".

\n
\n

We decided to change direction from several things in the oc module. Many of our motivations for such are differing agendas between the orgs. IETF cares about all the stuff, oc is an operational focused subset.

\n

But it\u2019s important to recognize the history and contributions. We\u2019ll likely borrow ideas both ways over the maintenance life

", "time": "2023-03-31T02:18:47Z"}, {"author": "Jan Lindblad", "text": "

+1 for interim on lessons learned

", "time": "2023-03-31T02:19:57Z"}, {"author": "Jeffrey Haas", "text": "

One bit of work mahesh skipped in the slides is how collaboration tools for integrated testing, draft generation and model validation was incredibly helpful.

\n

Some baseline tools like we used that are IETF supportive would be generally helpful to the organization.

", "time": "2023-03-31T02:20:47Z"}, {"author": "Juan Cardona", "text": "

Some kind of tooling for model examples, model coverage, etc for ietf models could be very useful.. I would even dare to say that it should be mandatory. Jeff, what tools did you use?

", "time": "2023-03-31T02:25:04Z"}, {"author": "Bal\u00e1zs Lengyel", "text": "

intersted in lessons learned

", "time": "2023-03-31T02:30:15Z"}, {"author": "Michael Richardson", "text": "

I would be happy to show up at any virtual interim...

", "time": "2023-03-31T02:30:27Z"}, {"author": "Jeffrey Haas", "text": "

The usual tools.

\n

Just inside a docker container with good make files

", "time": "2023-03-31T02:30:30Z"}, {"author": "Jeffrey Haas", "text": "

No need for local installs

", "time": "2023-03-31T02:30:42Z"}]