Minutes for the NETCONF 120 WG Session

WG Page:
https://datatracker.ietf.org/meeting/120/materials/agenda-120-netconf
Materials: https://datatracker.ietf.org/meeting/120/session/netconf

Session:

Thursday, 25 July 2024
Morning Session I 0930-1130 (local time)
Room Name: Georgia B

WG Chairs:

Kent Watsen (kent plus ietf at watsen dot net)
Per Andersson (per dot ietf at ionio dot se)

Available During and After Session:

Notes: https://notes.ietf.org/notes-ietf-120-netconf
Slides: https://datatracker.ietf.org/meeting/120/session/netconf
Drafts (PDF):
https://datatracker.ietf.org/meeting/120/agenda/netconf-drafts.pdf
Drafts (TGZ):
https://datatracker.ietf.org/meeting/120/agenda/netconf-drafts.tgz
ICS: https://datatracker.ietf.org/meeting/120/sessions/netconf.ics
Zulip (chat): https://zulip.ietf.org/#narrow/stream/netconf

Available After Session:

Recording: https://www.meetecho.com/ietf120/recordings#NETCONF
Youtube: https://www.youtube.com/watch?v=Mn0POkucLWg
Jabber Logs: https://www.ietf.org/jabber/logs/netconf

1) Session Intro & WG Status (10 min)

Presenter: chairs

We are encouraging participation from members. There are mutiple ways to
participate: mailing list participation, document reviewer or
implementer, document shepherd and WG secretary (vacant position).
We will request authors of WG documents to provide a status update to
the WG at every IETF meeting.

Post WG document status:

• sztp-csr and first 6 "x-client-server" in RFC Editor Queue
  (RFC-Editor)
• netconf-tls-13 in MISSREF
• https-notif and http-client-server in IESG Evaluation (AD Followup)
• netconf-client-server and restconf-client-server in AD Evaluation

Mahesh Jethanandani (current AD): about drafts that passed WGLC

• {netconf,restconf}-client-server : kept Rob Wilton's (previous AD)
  evaluation
• https-notif: need to address DISCUSS
• http-client-server: waiting for DISCUSS to be addressed

Kent Watsen (as author): http-client-server document was updated,
waiting to see if updates satisfies DISCUSS raised.

Rob Wilton: to get to this next week.

Chartered items:

2) List Pagination for YANG-driven Protocols (starts 9:40)

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-04

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-nc-04

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-rc-04

Discussion Leader: Qin Wu

Qin Wu: 3 drafts: 1 for standard mechanism, 1 for RESTCONF extension and
1 for NETCONF extension. We got YANG Doctor review comments from Lada.
Before IETF120 authors reached agreement and posted version new
revisions to address these comments and other changes (fixed incorrect
examples, added error identity examples and updated "sort-by" string
pattern). Also updated implementation status. We have 3 open issues
remaining. Need feedback from WG. Olof Hagsand made an almost complete
NETCONF + RESTCONF implementation in CLIXON project (missing "cursor",
"locale" and "sublist-limit"). Other implementations are not as complete
(e.g. support just 1 of the 2 protocols).

Addressed following issues from YD review:

• For XPath default context we follow section 6.4.1 of RFC7950
  (prefixes for NETCONF and module names for RESTCONF).
• The documents cater mostly to SQL databases. Authors have strived to
  standardize on broadly available database functionality.

Open issues from YD review:

• Should we allow limit=0 since "limit" is evaluated last? Useful to
  validate query validity.
• Reporting locale for ordered-by lists used without "sort-by"?
  Probbaly not for ordered-by user. We could for ordered-by system.
• Validation of yang-data+xml-list. Need to add XML encoding for
  RESTCONF? Need to define model to validate some RESTCONF examples.

Next steps:

• Get more reviews
• Close on the 3 open issues
• Get documents ready for publication

Kent Watsen: as chairs, we hope to get to WGLC soon.
Mahesh Jethanandani:

• Happy to see an implementation of the drafts.
• On the question of locale: locale might be useful ordered by system,
  why ordered by user is an issue w.r.t. locale?
  Per Andersson (as co-author): user-ordered entry ordering don't make
  sense, decided by user randomly, so as to no way to return the
  locale.

3) Transaction ID Mechanism for NETCONF and NETCONF/RESTCONF extension headers to suppport trace context (starts 21:40)

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-transaction-id-05

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trace-ctx-extension-01

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-trace-ctx-headers-01

Discussion Leader: Jan Lindblad, Roque Gagliano

Jan Lindblad: presenting "transaction id". Minimal changes between 03
and 06, based on feddback in various reviews. Functionally no big
changes (corrected namespace).
Related drafts:

• draft-ietf-*trace* and
  draft-ietf-netconf-configuration-tracing-01, separation of concerns
  now clear.
• draft-ietf-netconf-privcand overlap has been cleaned up in -04. It
  now allows transaction-id style conflict detecton to be used. And
  -04 allows aborting privcand transactions with conflicts
• New document draft-lopez-opsawg-yang-provenance-03 defines similar
  mechanism for crypto checksums over data trees. Some alignment may
  be needed there.

Next steps:

• Time for WGLC?
• We have partial implementation, working fine.

Kent Watsen (as chair): WGLC, if no objection we will kick it after this
meeting.

Roque Gagliano: presenting trace context extension
(netconf-trace-ctx-extension and restconf-trace-ctx-headers). 1 doc for
NETCONF and 1 doc for RESTCONF.
netconf-trace-ctx-extension uses W3C defined REST headers. SHOULD
changed to MUST. Cisco implemented client and server.
restconf-trace-ctx-headers uses W3C defined REST headers. SHOULD changed
to MUST. Cisco implemented server (tested against opensource client).
Authors believe both documents are mature.
Overview of implementation: use of open telemetry in backend to use
trace context for performance. Backends can identify application
relationships too (trace contexts are chained between apps).
There is an option to register these protocols in W3C registry (via git
repo). Looking for any interest from NETCONF and RESTCONF
implementations.
ALso monitoring the W3C "baggage headers" development.

Per Andersson (as co-chair): do you want the chairs to do the
registration?

Roque Gagliano: I am happy to do it, it’s just a PR.

From chat: this is the registry:
https://www.w3.org/TR/trace-context-protocols-registry/ (for
completeness)

Per Andersson: what is the IETF process to do this? I don't know.

Mahesh Jethanandani: I don't know either but if you know the process and
think it’s beneficial, go ahead (Roque)

Kent Watsen (as co-chair): I don't believe it is necessary, but if it is
needed and benefical, let's do it. Who would do it?

Mahesh Jethanandani: I believe an individial can do the registry. Does
the IETF have to be involved?

Roque Gagliano: I believe it is good for awareness of the work for IETF
to be involved.

Rob Wilton: Chris Hopps mentioned in the chat that we might have a
liaison to W3C, I cannot remember who the liaison manager is, but might
be worth to check with him

Mahesh Jethanandani: I believe Chris is in the room. Does it have to be
a liason statement?

Kent Watsen: Chris can not come to the microphone.

Per Andersson and Kent Watsen (as chairs): authors, are you asking for
WGLC?

Roque Gagliano: yes we do.

Per Andersson (as co-chair): We will start WGLC after this meeting.

4) External Trace ID for Configuration Tracing

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-configuration-tracing-01

Discussion Leader: Jean Quilbeuf

Jean Quilbeuf: goal is to be able to trace from orchestrator to the
network element. Inline with work from Jan and Roque.
Main update:

• Pass client-id as an RPC attribute (similar to trace context).
  traceparent implemented in netopeer2/sysrepo/yanglint, had to define
  annotation to get it accepted. Is that the correct way?

Jan: Annotation draft doesn't speak how you would annotate RPC, it only
talks about how you would apply these to content node. That is why I
didn't use it for transaction ID. We are in the undefined area right now
wrt to using annotation for RPC. Maybe some tools require it.

Kent Watsen (as contributor): You have a XML/NETCONF example, is there a
RESTCONF example? If no, please add it.

Jean Quilbeuf: we will add a RESTCONF example.

Next steps:

• Jan already did the work to align the document with the trace
  context and transaction-id documents

Andy Bierman:

• RPC element is not modeled in YANG, and never will be. It doesn't
  need the annotation, that only applies to things modeled in YANG.
• RFC6241 mandates that all attributes in the RPC returned unchanged
  with the rpc-reply. Be aware of that and make sure to conform to it.

5) NETCONF Private Candidates

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-privcand-04
Discussion Leader: James Cumming

James Cumming: reminder that the document adds independent candidate
datastores per session basis for NETCONF and RESTCONF. -03 containes
significant updates based on WG feedback. -04 has minor updates.

Outstanding issues:

• 2 approaches for the YANG
• Selecting if private candidate is used
• Do we need source datastore in RPC?
• Clarifying how conflicts are resolved

Key updates in -03 and -04:

• What constitutes a conflict (section 6.4.1)? Now allows use of
  transaction id
• Clarified commit-confirm behaviour
• Provided solution for delete-config
• Updated NMDA diagram with private candidate datastores
• added section to list what this document updates from existing RFCs

2 approaches for YANG models:

• Make privcand look like other datastores by updating base YANG
  models. Issue is that YANG 1.0 does not support "or" in if-feature
  (original models are YANG 1.0)
• Single model for privcand by using augments. Downside is that we
  have a different approach for the privcand datastores compared to
  the base operations.

Authors plan on using the augment approach based on mailing list
discussions. That will be in the next revision.

How to select if private candidates are used:

• Should non-NMDA clients be supported? Authors feel that they should
  be supported since most clients are not NMDA-aware.
• Should an indvidual client be able to select whether it uses
  privcand? Or do we use a config option?

Andy Bierman (referring to previous discussion on approaches for YANG
models): because initial model is 1.0, you’re not allowed to augment it
with 1.1 (Andy later clarified that it is 1.0 not allowed to import 1.1,
he got it backwards). You are not allowed to publish a YANG 1.0 module
either, so the solution doesn't work.
James Cumming: If you could point to that text, that would be great. We
did some experimentation with linters but they might not follow the
standard.

Source datastore in commit operation?

• If yes, privcand and shared candidate can be used at the same time.
  Consistent with fact that they can be locked independently.
• If no, everything in a session is either privcand or shared
  candidate. Then do we need private candidate in client capabilities?

Kent Watsen(as a contributor): would prefer not to have private
candidate and shared candidate in the same session (prefer second
option). If private candidate and shared candidate cannot in the same
session, maybe private candidate can be called candidate, that is
cleaner and more backwards compatible.

James Cumming: only concern is that it feels a bit less NMDA-like than
other NMDA extensions.

Rob Wilton：If private candidate can be called candidate, then you don't
have to differentiate in the RPC operation and use different names.
Private would just be a property of a candidate datastore.

Feedback from side-meeting:

• Augmentation approach for YANG model, intent to roll the solution
  into a NETCONF-next solution
• Preference to support non-NMDA clients
• Approach for NMDA clients: no clear preference. Authors to go the
  list again and pick an approach.

Next steps:

• Additional rpc-error error-tag (appendix A of RFC6241)
• Finalise solution for NMDA clients
• Does editing a node resolve a conflict?
• WGLC

6) Support of Versioning in YANG Notifications Subscription (starts 54:20)

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning-05

Discussion Leader: Thomas Graf

Reminder: the document adds to the subscription-started message the
module name, revision date and revision label. Also added to YANG-Push
the ability to subscribe to a specific revision.
-04 has a fix to make "case" statement identifiers unique. Thanks to
Jeremie Leska from 6Wind for reporting this issue.
Implementation status: 2 YANG-Push subscription (RFC8639)
implementations (6WIND VSR and Huawei VRP).

This document is part of the NMOP YANG message broker work.

No questions.

7) UDP-based Transport for Configured Subscriptions (starts 56:15)

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-13
Discussion Leader: Alex Huang Feng

Changes in -13 and -14:

• Now using UDP client grouping from udp-client-server. Node is now
  capable of sending to a inet:host rather than only to
  inet:ip-address-no-zone and is able to set its local address
• Instead of default value for the port, we have the port as mandatory
  now (thanks Med).

No pending items. Requesting WGLC.

Mahesh Jethanandani: Do we need a default port? Should we be requesting
one? Where are we currently with the requesting for a default port?
Alex Huang Feng: feedback was that default port is not needed, but
including the udp-client-server grouping we inherit the default
statement
Rob Wilton: That’s not gonna pass IANA, IANA will not give a default
port (limited resource)
Kent Watsen(as contributor): When we published NC/RC call-home, we did
ask IANA for a port number assigned.
Alex Huang Feng: that's the remote port for the receiver
Kent Watsen: we didn't need to ask for port for http-notif because we
have port 443
Rob Wilton: Ask for help from designated experts

Christian Hopps (on chat): You aren't doing first contact to a server,
so you don't need a reserved default port.

Alex Huang Feng: then we won’t make the request to IANA

8) YANG Groupings for UDP Clients and UDP Servers (starts 1:01:30)

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-client-server-03

Discussion Leader: Alex Huang Feng

ietf-udp-client: remote-address changed to inet:host. Addition of
local-address and local-port.
ietf-udp-server: support for server using IPv4 and IPv6 at the same time

UDP groupings mimick the TCP client/server groupings in
draft-ietf-netconf-tcp-client-server.
Removed default port 0 to allow more flexibility as requested by Med.
But this is inconsistent with TCP gouping.

Kent Watsen: is the default port for remote or local?
Alex Huang Feng: I think it's for both but I need to double-check.
Kent Watsen: Consistency with TCP is good. What is the reason to change
the port-number definition?
Alex Huang Feng: Comment from Med to allow make the the port mandatory
for users of the grouping. We can refine it, but we cannot remove it,
which is actually needed by netconf-udp-notif (a default statement can
not be removed by a user of a grouping).
Kent Watsen：it is true that we can't remove a default statement, but not
sure it's important. Take it to the list.

Pending the discussion on default port, the document is ready for WGLC.

9) Subscription to Distributed Notifications (starts 1:05:22)

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-09

Discussion Leader: Alex Huang Feng

Only minor changes done:

• Updated implementation status
• Added message-publisher-id to push-update and push-change-update.
  This has led to its removal from
  draft-tgraf-netconf-notif-sequencing-06

Rob Wilton: You may want to know what part of the subscription is
handled by each publisher. Maybe pass the XPath to that subscription.
Needed for parent subscriptions and child subscriptions. I had a
discussion with Thomas on this at the Hackathon. Need some discussion on
this.

Thomas Graf: what Rob said is correct

Kent Watsen: would like to see more traffic on the mailing list before
requesting WGLC. The draft got parked for some time and not much
discussions on the list. Encourage pushing the other documents first.
Mahesh Jethanandani: some history: distributed notif was parked waiting
for udp groupings to pass through (https-notif document)
Thomas Graf: we now also have 3 vendor implementations, that is another
reason why we were waiting

Non-Chartered items:

10) YANG model for NETCONF Event Notifications (Starts 1:09:26)

https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-05

Discussion Leader: Alex Huang Feng

RFC8641 uses event notification definitions from RFC5277. We can
validate YANG-Pish messages in XML but not in JSON or CBOR.
YANG model for NETCONF veent notifications:

• Interest from WG: lots of support during adoption call but push-back
  from Mohamed Boucadair (why model notifications only and not whole
  of RFC5277)
• Triggered other discussions related to YANG-Push

Andy Bierman: The structure only validates event time. There is no
industry problem having to parse a notification and the event time leaf.
The structure would be good only for the 1st element, not for the next
one (not supported in YANG). So there is no way to do the entire
message. Defining YANG for header is only useful for obtaining a SID
file. You are not able to validate it. Can't do RPC element either.

Alex Huang Feng: implementors of YANG-Push have asked about why there is
no model for part of the header. I agree we are only supporting event
time header.

Thomas Graf: confirming what Alex is saying.

Rob Wilton: Having a YANG definition is useful. It seems that things are
fragmented between various pieces. RFC5277 is defining the XML and other
documents define other parts. Maybe we need commonality, that would be
nice. Is that YANG-Next issue?

Andy Bierman: any parser will get the entire message, not just event
time. We won’t be possible to model everything in YANG because we have
arbitrary structure.

Alex Huang Feng: explainign why the YANG defines a "structure" instead
of a "container"

Andy Bierman: would you be adding normative text for this procedure? I
believe the validation will fail.

Alex Huang Feng: let's discuss offline

Jean Quilbeuf: I think it's very useful for the SIDs (as Andy was
explaining) and to have a common encoding for cbor, json, and xml.

Proposal:

• Use normative text for how message needs to be encoded with NETCONF
  (mimick RFC8040)
• Define a notification structure in YANG
• RESTCONF out of scope
• This document updates RFC5277, RFC8639, RFC7951 and RFC9254

Kent Watsen: why is RESTCONF out of scope?
Alex Huang Feng: RFC8040 section 6 already has normative text

Thomas Graf: to add to what Rob said about fragmentation: we have text
in RFC8040 and http-notif, here we're trying to do a common way.

Rob Wilton: Could we have a virtual interim for this? a lot of details
need to be discussed.

Kent Watsen: sounds like a good idea

11) Support of Hostname and Sequencing in YANG Notifications (Starts 1:20:00)

https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing-06

Discussion Leader: Thomas Graf

Adding hostname and sequence-number to notification element. hostname is
useful when the data is forwarded from the YANG-Push receiver to another
entity doing the processing. Use of capability for client to know that
server will be adding those new fields or not.

Reshad Rahman: Sequence number used to check if some messages are
dropped?

Thomas Graf: that is correct.

Reshad Rahman: Depending on transport used (we are trying to do similar
things for BFD), out of order might be incorrectly tagged as lost.

Thomas Graf: we differentiate between transport and messaging, we want
to have this information end to end accross the messaging processing
chain (since this message can be forwarded to other processing
elements).

Per Andersson (as contributor): do you forsee more meta-data to be added
in the future?

Thomas Graf: No. We need in network telemetry protocols a common set of
basic attributes needed for processing the data. See
https://datatracker.ietf.org/doc/html/draft-boucadair-nmop-rfc3535-20years-later-04#name-inconsistent-data-structure

Mahesh Jethanandani: Reshad refers to fact that in BFD, if you get
updates out of sequence, you might decrement the count when you should
be increasing it
Reshad Rahman: not exactly the point, but good question as well
Thomas Graf: The sequence numbers are on messaging layer. Not to be
confused with transport.

Andy Bierman: other transports preserve order, so we only need sequence
numer for UDP. Message-id already in UDP, why do you need seq number in
the notification? Same for hostname, maybe we don’t want to have it in
every message (concern about having an extra long string in every
notification message sent. Why not have it for YANG-Push only. That
meta-data can be useful to some, but not everyone will want it.

Thomas Graf: how else do you know what host the message comes from?

Andy Bierman: that information is available from the IP address

Thomas Graf: when the receiver forwards the message, it needs to augment
the data with hostname.

Andy Bierman: that is an implementation detail.

Kent Watsen (as contributor): it’s a change of behavior if the server
automatically sends that extra data. The client should ask from it in
order to support backward compatibility.

Thomas Graf: I was earlier referring to RFC3535-bis, attributes which
should be made available by all telemetry protocols. One of the
requirements is where the data is being pushed from.

Kent Watsen: I don't dispute the requirement, but we need backwards
compatibility

Thomas Graf: I understand. We support that through netconf, systems and
notification capabilities (RFC 9196).

Rob Wilton: Maybe we can make the server behaviour configurable.
Rob Wilton: UDP sequence number is only for communication from publisher
to first receiver, the sequence number being added in the notification
here is for the end to end message

Benoit Claise: if we take the IP address as id of the publisher, we
won’t see the same for netflow, syslog, YANG-push etc. So it’s not an
implementation detail, it's a basic problem.

12) Support of Network Observation Timestamping in YANG Notifications (Starts 1:30:05)

https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-yang-push-observation-time-02

Discussion Leader: Thomas Graf

The exisitng event time indicates when the update (periodic or
on-change) was sent but does not indicate when the event was observed.
Adding observation timestamp in notifications defined in RC8641.
point-in-time indicates at which point in time the value of
observation-time was observed (periodic v/s on-change update v/s
on-change sync-start).
System capabilities (RFC9196) extended to discover observation
timestamping capability.

Requesting feedback from WG.

13) Using NETCONF over QUIC connection (Starts 1:32:17)

https://datatracker.ietf.org/doc/html/draft-dai-netconf-quic-netconf-over-quic-06

Discussion Leader: Per Andersson

Why NETCONF over QUIC? Addresses TCP's shortcomings: head-of-line
blocking, 3-way handshake and slow connection establishment and no
connection migration. Shaves ~45 mins in deep-space usecases.

Authors request adoption call.

Kent Watsen: asking for show of hands to show interest (a few hands up)

Andy Bierman: for the record, BEEP and SOAP have been marked historic.

14) YANG Groupings for QUIC clients and QUIC servers (Starts 1:36:56)

https://datatracker.ietf.org/doc/html/draft-andersson-netconf-quic-client-server-00

Discussion Leader: Per Andersson

Defining usable YANG groupings for the QUIC protocol. Reusing
tls-client-server and udp-client-server. TLS1.3 needed.

http-client-server has some YANG for QUIC.

No need to hold up netconf-client-server document (augment)

Kent Watsen: Glad that netconf-client-server will not be held up. What
about http-client-server document?
Per Andersson: we would need to hold it up.

Mahesh Jethanandani: it's not just the http one since the ones which
need it wil be impacted too.

Kent Watsen: what harm will it do if we go ahead with
http-client-server?
Per Andersson: could we refine it if needed
Mahesh Jethanandani: We should go ahead with the drafts we have and then
looks what needs to change. I don't want to hold those drafts anymore.
Kent Watsen: could do a bis

Rob Wilton: Regarding previous presentation, for quick setup for NETCONF
over QUIC there maybe some security drawbacks, need to look into it.
Per Andersson: I think that is mentioned in the document.

15) Augmented-by Addition into the IETF-YANG-Library (Starts 1:43:38)

https://datatracker.ietf.org/doc/html/draft-lincla-netconf-yang-library-augmentedby-01

Discussion Leader: Zhuoyao Lin (remote)

Need for real-time knowledge of a YANG module's dependency list when a
YANG-Push notification is received. get-all-schema is not an option for
closed loop automation (it takes too long).
Worked on open-source implementations (sysrepo/libyang) in the past
hackathons.
All past issues have been resolved.
Open issue: call for adoption or do 8525bis instead? Authors favour call
for adoption.

Andy Bierman: I support the use case that you want to retrieve a subset
of modules from the server. Doing a lot of get-schema is not effective
(the issue is not with YANG library). Need the optimization of
get-schema, instead of yang-library. There is no get-all-schema, but we
could add that so that it's 1 call instead of multiple.

Thomas Graf: thanks for the implementation. I favour an incremental
approach so that we can move with this quickly. I agree with Andy that
we need to optimize get-schema.

Benoit Claise: on the 2 options, Andy you're right that some systems
have e.g. 1500 YANG models. One way or the other, we need the
optimization described in this document. 8525bis is cleaner, but it
takes too long, so future work for me.

Mahesh Jethanandani (as contributor): I support this work. Optimization
proposed by Andy would not solve the issue for getting a lot of schema.

Andy Bierman: no but it would allow an RPC getting the relevant schemas
(not all)

Thomas Graf: for what Andy suggested we need the dependencies and this
is what this draft is about.

Poll on adoption for this document (augment yang lib):

yes: 11
no: 1
no opinion: 0

Call for adoption will be made.

16) NETCONF WG Open Mic

Kent Watsen: future compatibility between NETCONF and RESTCONF. We
should ensure that as a WG we have the feature parity between the 2.
Andy Bierman: RESTCONF supports RPCs and actions, so whatever is modeled
in YANG is automatically supported by RESTCONF.
Kent Watsen：The sentiment is that we should do this (saw a few nods).
Looking at Mahesh Jethanandani our AD, perhaps we should update the
charter to state this.
Mahesh Jethanandani: in concrete terms, does that mean we will evaluate
every submission to make sure that it abides? Wondering what are the
implications of having this in the charter, instead of an implicit
assumption.
Kent Watsen: maybe not needed in the charter but I'd like it somewhere
official so that we can point to it.
Per Andersson: could we do this via a milestone? Tongue-in-cheek comment
but it's a way of having it official without being in the charter, it's
something we'd be aiming for.
Mahesh Jethanandani: let's chat about the mechanics on how to do this.
Not a fan of adding it to the charter, it's implicit.
Kent Watsen: Because it's implicit, it's not obvious to everyone.