system DS.
Why not? The system-config draft indicates that the contents of the
datastore may change based on events such as a software/hardware/license
change. What else of you think the draft intends then?
[keep scrolling]
> Jason
>
>> -Original Message-
>>
>>>>>>>There are RFCs that don’t include the full tree,
>> but
>>>> AFAIK there
>>>>>>>is no RFCs that include a stable pointer for a
>> tree.
>>>> There are
>>>>>>>I-Ds under development that
> I think it is important to keep the distinction between 'or:system'
> and 'sysds:system' since config generated by the system is different
> than config originating from a system datastore.
I saw this comment last night and it didn’t sit right.
Assume a server initially has no datastore, and
They are? That’s news to me. I will ping Sabrina ASAP.
Kent // RFC 9644 (ssh-client-server) author
> On Nov 5, 2024, at 4:23 PM, Joe Clarke (jclarke) wrote:
>
> Sabrina said that they are pending Kent’s review of some last-minute module
> updates since there was an issue running a script
Dear NETMOD,
Thursday’s NETMOD session has a special focus on Templates. There are four
10-min presentations, each presenting a different idea for how templates could
be done.
Since 10-minutes is not enough time for each idea to be covered in detail,
please prepare for the session by readin
Folks,
There’s something wrong with one of the links in the Agenda, which states "No
Session Ongoing”
Please use this link instead:
https://meetecho.ietf.org/client/?session=33378
Kent // as chair
___
netmod mailing list -- netmod@ietf.org
To uns
used for a sensitive service (can be used for dos, service disruption by
modifying the listen address/port, access other data, etc.). Of course, one has to access to the info to misuse it, but still that’s a vulnerability to report.
Cheers,
Med
De : Kent Watsen
Envoyé : mercredi 30 octobre
FWIW, my client-server drafts do consider the security of nodes defined only in groupings. Then, in other drafts using those groupings, the Security Considerations would say to also look at the Security Considerations from RFCs containing the imported modules. This way: - the considerations aren’t
Folks,
These slides were incomplete and sent to the list by accident.
Please ignore!
Kent
> On Oct 29, 2024, at 2:49 PM, Mahesh Jethanandani
> wrote:
>
> Hi Kent,
>
> Thanks for setting the context for the discussion. It is helpful.
>
> Cheers.
>
>>
Chiming in here...
Without bias:
> On Oct 9, 2024, at 11:06 AM, Reshad Rahman wrote:
>
> However, I also see a similar approach to the one we followed: e.g.,
> draft-ietf-netconf-tcp-client-server/draft-ietf-netconf-udp-client-server/..
> include a note:
>
>
>
>
> These examples ca
The draft agenda for the NETMOD session has been updated:
- moved the “Packages" preso to the “Chartered” section (was in
LC-section)
- added 5-minutes to Day 2’s "Session Intro" section
- subtracted 5-minutes from Day 2’s “Open Discussion” section.
https://datatracker.ie
The draft agenda for the two NETMOD sessions at IETF 121 has been updated:
- shortened time for YANG Versioning Post Last Call Update.
- added slot for YANG Versioning – Packages Update.
- shortened time for the YANG++ presentation.
https://datatracker.ietf.org/meeting/121/
NETMOD WG (especially presenters!)
The draft agenda has been posted here:
https://datatracker.ietf.org/meeting/121/materials/agenda-121-netmod-01
Please unicast any comments to the chairs (CC-ed)
Thanks,
Kent and Lou___
netmod mailing list --
Hi Jason,
I hope others chime in, but my thoughts are that MAY return
CT-nodes that are not configured via , but its “origin” attribute MUST
correctly indicate where it came from.
Some examples:
- the node is *configured* by the datastore
- the node is *configured* by a “dynamic” dat
ddiff?url1=draft-ietf-netmod-rfc8407bis-09&url2=draft-ietf-netmod-rfc8407bis-10&difftype=--html
>>
>> Cheers,
>> Med
>>
>> De : Lou Berger <mailto:lber...@labn.net>
>> Envoyé : mardi 1 octobre 2024 00:24
>> À : netmod@ietf.org <mailto:
available as the document itself by including
> the long diagram in an appendix.
>
> I would like to see this section reverted to the original.
>
> Authors,
>
> What is the motivation for the change to URLs and making this a "SHOULD NOT"?
>
> Thanks,
>
Hi Qiufang,
Thank you for this update.
I believe this fully addresses the issue raised by Juergen.
I appreciate the simplicity and robustness of this approach.
I hope that NETCONF-next and RESTCONF-next will assert the use of NMDA.
Kent
> On Sep 29, 2024, at 10:36 PM, maqiufang (A)
>
|
If you still think we need to make the change, I’d like we formally ask for WG consensus on the way to proceed here. A 1-week call would be OK. Thanks.
Cheers,
Med
De : Kent Watsen
Envoyé : vendredi 27 septembre 2024 16:01
À : BOUCADAIR Mohamed INNOV/NET ; maqiufang (A)
Cc : draft-ietf
Hi Med et. al.,
> On Sep 27, 2024, at 5:34 AM, mohamed.boucad...@orange.com wrote:
>
> Section 4.14 specifies a set of YANG statements that MUST have a description
> substatement, but I don’t think anydata should be omitted here. Thoughts?
> [Med] This list is inherited from 8407, which in its t
with it?
Thanks,
Kent and Lou (chairs)
> On May 6, 2024, at 9:57 AM, Kent Watsen wrote:
>
> This email begins a two-week WGLC on:
>
> Guidelines for Authors and Reviewers of Documents Containing YANG Data
> Models
> https://datatracker.ietf.org/doc/dr
guidelines need to be added to the already
> completed rfc8407bis.
> This is a design decision based on the intended reuse of the groupings.
>
> Here is a common sense guideline: Document the grouping reuse limitations
> in the description-stmt.
>
>
> Andy
>
>
>
&g
of this discussion guidelines on reusable YANG groupings.
>
> Best wishes
> Thomas
>
> From: Kent Watsen mailto:kent+i...@watsen.net>>
> Sent: Wednesday, September 18, 2024 3:12 AM
> To: Andy Bierman mailto:a...@yumaworks.com>>
> Cc: netc...@ietf.org &
’/’validation’
>
> In my humble opinion, we have to include a clause in ‘Payload
> Parsing’ section of RFC, mentioning, “If all mandatory leafs are not present,
> when the edit-config operation is ‘create’, then the server MUST reply with a
> "missing-element&
the RPC or action operation.
You’re right. Validation is context dependent.
K.
> Andy
>
>
>> K.
>>
>>
>>> Thanks & Regards,
>>> Partha.
>>>
>>> From: Kent Watsen mailto:k...@watsen.net>>
>>> Sent: Tuesday, S
e it create/merge).
Yes, you make a point, such nodes exist in the request message 99% of the time,
but it is possible that they may alternatively be set via defined
configuration, or via a template.
K.
> Thanks & Regards,
> Partha.
>
> From: Kent Watsen mailto:k...
Hi Partha,
> On Sep 6, 2024, at 1:13 PM, parthasarath...@fujitsu.com
> wrote:
>
> Hi,
> I am a Software Engineer working in Fujitsu’s NMS product
> supporting Netconf devices. I want a clarification in RFC 7950 on the
> behavior of constraint validation in an edit-config request
Hi Med,
Sorry this is taking so long, but we’re getting there! ;)
>
> The reference of QUIC is to the protocol, RFC 9000, not NETCONF over QUIC, an
> I-D as you note; just as the reference is to SSH protocol, RFC 4252, not
> NETCONF over SSH, RFC 6242.
> [Med] I understand the intent is to
Hi Paul,
> On Sep 9, 2024, at 9:28 PM, Paul Wouters via Datatracker
> wrote:
>
> Related question: Is it one certificate+key that used for the TLS connection
> as
> well as to sign data within the payload of packets?
The issue you’re raising is one that could’ve (should’ve?) been discussed w
Hi Med,On Sep 12, 2024, at 3:14 AM, mohamed.boucad...@orange.com wrote:
Hi Mahesh,
Please see inline.
Cheers,
Med
De : Mahesh Jethanandani
Envoyé : jeudi 12 septembre 2024 00:49
À : BOUCADAIR Mohamed INNOV/NET
Cc : Kent Watsen ; netmod@ietf.org
Objet : Re: [netmod] AD - Re
NETMOD,
A group of folks are meeting tomorrow to continue reviewing the YANG-next issue
tracker.
In case anyone wants to join, the meeting is 9-11am US/Eastern. The Zoom link
is:
https://us02web.zoom.us/j/84044654674?pwd=7z4Ql9u33W0edXP3RhppXfJsBr2COa.1#success
Kent // contributor
cols, such as NETCONF [RFC6241] and
RESTCONF [RFC8040]. These protocols have mandatory-to-implement secure
transport layers (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and
mandatory-to-implement mutual authentication.
Kent // contributor
> On Sep 4, 2024, at 10:28 AM, Kent
ilable, too long trees can be displayed in the HTML
> version of documents that include such trees.
>
> I know that Italo tried to have a discussion in 121 with Carsten for md(?),
> but I don’t know if that discussion actually happened. Italo can clarify this.
>
> Cheers,
[removing the IESG]
Hi Joe, authors, and NETMOD.
> On Sep 10, 2024, at 10:04 AM, Joe Clarke (jclarke)
> wrote:
>
> Thanks for the comments and feedback, Paul. I’ve opened GitHub issue
> https://github.com/netmod-wg/syslog-model/issues/14 so Mahesh and I can track
> the necessary changes on
Hi Med,
1) Regarding "For example, authors of a module with such identifiers have to
indicate...”, I’m unsure how the registrant is suppose to propose valid YANG
identifiers. First, I wonder if the registrant would even be aware of the
existence of a YANG module for the underlying registry.
TP/1.1 [RFC9112]
- HTTP/2 [RFC9112]
- HTTP/3 [RFC9112]
Thoughts?
Kent // contributor
> Begin forwarded message:
>
> From: Mahesh Jethanandani
> Subject: Re: AD - Re: AUTH48: RFC-to-be 9644
> for your review
> Date: September 3, 2024 at 5:41:58 PM EDT
> To: Kent Watse
> Please see inline.
>
> Cheers,
> Med
>
> De : Kent Watsen mailto:kent+i...@watsen.net>>
> Envoyé : dimanche 11 août 2024 20:48
> À : netmod@ietf.org <mailto:netmod@ietf.org>
> Objet : [netmod] Regarding draft-ietf-netmod-rfc8407bis
>
>
&
> On Aug 22, 2024, at 1:24 PM, Andy Bierman wrote:
> On Tue, Aug 20, 2024 at 5:54 AM Jürgen Schönwälder
> wrote:
>> On Tue, Aug 20, 2024 at 12:20:55PM +, Jan Lindblad (jlindbla) wrote:
>> >
>> > PS: And with a well designed merge operation, one might in the future
>> > even move towar
Hi Andy,
> So you are planning new protocol versions with NBC changes as well?
Yes. The NETCONF WG already kicked-off (sort of) the NETCONF-next and
RESTCONF-next efforts. The “plan” is to first publish a BC (backwards
compatible) version of the protocols to address low-hanging items, and the
NETMOD WG,
A small group is meeting tomorrow to score YANG-next issues [0].
This is the second such meeting and, as such, will begin with Issue #51.
In case anyone wants to join, please review issues >= 51beforehand.
YANG-next: Score more issues
Scheduled: Aug 23, 2024 at 9:00 AM
Hi Andy,
> The example in the appendix shows a device that would boot without any
> interfaces in .
> They would only be in . If this is the case, then all non-NMDA
> clients and all current NMDA clients need to be rewritten to know about the
> config. IMO breaking all existing clients woul
Hi Qiufang,
> Regarding #1, I’m sympathetic to not flipping an established client-contract
> without warning. My proposal is to version the protocols (i.e. NETCONF 1.2
> and RESTCONF 1.1) to indicate this change in behavior. That is, a server
> implementing the datastore would have to imple
Hi Jan,
> After us all now having investigated this line of reasoning, my conclusion is
> that we have to choose one of two approaches:
The primary open-question is if it is *needed* for a client to copy
nodes into . IMO, to understand the requirements, this question must
be answered first.
Hi Jürgen,
> On Aug 15, 2024, at 11:10 AM, Jürgen Schönwälder
> wrote:
>
> On Sun, Aug 11, 2024 at 02:10:31PM +, Kent Watsen wrote:
>>
>> This email begins a two-week WGLC on:
>>
>> System-defined Configuration
>> https://datatracker.
system nodes triggered by
>"resolve-system" parameter might conflict with the contents of
>, the conflict resolution is no different than the
>resolution of conflict caused by configuration explicitly provided by
>the client.
>
> I’m afraid I don’t un
Kent Watsen has requested publication of draft-ietf-netmod-syslog-model-32 as
Proposed Standard on behalf of the NETMOD working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
___
n
The minutes for the NETMOD 120 session [0] captures this dialog:
Tim Carey: What is the update for the best practices document and
node-tags document
Lou Berger: Best practices - I do not recall and will have to come back.
The update follows, in the form of the history/s
NETMOD WG,
We did a WGLC in May on the -05 version of this document. The diffs since then
are substantial
(https://author-tools.ietf.org/iddiff?url1=draft-ietf-netmod-system-config-05&url2=draft-ietf-netmod-system-config-08&difftype=--html)
and so it seems prudent to run a fresh WGLC on this d
Hi Juergen,
Thank you for the update!
I believe the conversation right now is with the AD.
Best regards,
Kent // shepherd
> On Aug 7, 2024, at 6:43 AM, Carsten Bormann wrote:
>
> On 2024-08-07, at 09:59, Jürgen Schönwälder
> wrote:
>>
>> It is what it is.
>
> I agree that this is a vali
[CC-ing Med]
I wonder if rfc8047bis should have a recommendation to use groupings
extensively?
FWIW, my "client-server” suite of drafts in NETCONF use groupings extensively.
In fact, whenever a data-node is needed, it is always just a container that
uses a grouping.
Kent
> On Aug 2, 2024, a
Added to YANG-next tracker here:
https://github.com/netmod-wg/yang-next/issues/129
> On Aug 1, 2024, at 4:48 PM, Alexander L Clemm
> wrote:
>
> Hello Shiya,
>
> re your comment on the "Once models have been defined this way, they
> cannot be altered after the fact": Well, I guess as William
Please ignore
Sorry for the noise, but the tools-team pointed me to a mailman3 setting that
might be causing my CC’s being removed. CC-ing Rob again as a test.
K.
> On Jul 30, 2024, at 1:08 PM, Kent Watsen wrote:
>
> [CC-ing Rob]
>
>
>> On Jul 30, 2024, at 1:02 P
[CC-ing Rob]
> On Jul 30, 2024, at 1:02 PM, Kent Watsen wrote:
>
> Hi Juergen,
>
> During the IETF 120 NETMOD session, there was a discussion regarding the
> status of this document. The chairs asked if anyone would be willing to help
> get it over the line. Both
Hi Juergen,
During the IETF 120 NETMOD session, there was a discussion regarding the status
of this document. The chairs asked if anyone would be willing to help get it
over the line. Both Rob and Joseph (CC-ed) volunteered.
Is there a repo that you were working out of?
Kent // as shepherd
> Do you have any reference (URL) to "NIST-like bake off" for people like me
> who are not aware of it?
I’ll summarize, most likely incorrectly, but it should suffice.
1) NIST puts out a call for an algorithm
2) NIST evaluates submissions on varying axes: strength, speed, size,
implementabi
> This means to me that templating mechanism might more easily be applied to
> the data input versus the schema itself.
Yes, but both input and output. That is, would return what
set.
A server would advertise that it supports, e.g., via a capability, but
otherwise its YANG Library would b
NETMOD 120 presenters,
Please submit a draft version of slides no later than Friday Jul 19th (any
timezone).
Please propose slides at the following URL:
https://datatracker.ietf.org/meeting/120/session/netmod
If it is not possible to propose slides on DataTracker, send them by
unicast
/converter.html?iso=20240722T20&p1=256
Room: Georgia B
https://datatracker.ietf.org/meeting/120/floor-plan?room=georgia-b
## WG Chairs:
Lou Berger(lberger at labs dot net)
Kent Watsen (kent plus ietf at watsen dot net)
## WG Secretary
James Cumming (james.cumming at nokia
Dear NETMOD WG,
Jason has let us know that he needs a break from being Secretary and, very
fortunately, James Cumming (CC-ed) has volunteered to step in.
We appreciate all the help that Jason has provided, and look forward to his
continued contribution to the WG going forwards.
Welcome James!
Hi folks,
I took a swing at YANG-next…
I started by asking RFC Editor for the XML for 7950, which I then updated to
the new v3 format. Lastly I created a PR to move the XML-specific text to a
new “yang-xml” document. Here are the results.
1. rfc7950bis
FWIW, IDK this work will obsolete 602
A message from one of the Ops Area ADs. Good advice!
> From: Warren Kumari
> Date: June 30, 2024 at 6:14:51 AM EDT
> To: ops-chairs
> Subject: A short note / request…
>
>
> Hi there all,
>
> As you've probably all realized by now, the IESG goes through cycles of what
> it thinks is super
> I believe this was a deliberate decision. The info about module versions is
> available elsewhere (in the module proper and/or in YANG library data), so I
> don't see any necessity of having it in the namespace.
Yes, but I wonder if it assumed the update rules in Section 11. Thinking out
l
NETMOD WG,
I was recently asked why YANG module namespaces aren’t versioned. For example,
the “1.0” at the end of this URI
"urn:ietf:params:xml:ns:yang:ietf-crypto-types:1.0”. The stated concern was
"because without this, then management of backward compatibility becomes a
nightmare.”
Th
Hi Carsten,
> On Jun 3, 2024, at 4:12 PM, Carsten Bormann wrote:
>
> (2) I’d love to know what kinds of timestamps real YANG implementations send
> here — do they really pollute their timestamps with local-time offset
> information?
> Does any recipient actually care about the local-time relat
This email begins a two-week WGLC on:
Guidelines for Authors and Reviewers of Documents Containing YANG Data
Models
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/
Please take time to review this draft and post comments by May 20.
Favorable comments are especiall
None of the authors are aware of any IPR.
Please note that Qin’s response isn’t threaded correctly, but can be found
here: https://mailarchive.ietf.org/arch/msg/netmod/NDygxJmY6FEOwXS8ifGo08INR58/
Kent
> On Apr 29, 2024, at 6:05 PM, Kent Watsen wrote:
>
> Authors, Contributors, WG
Authors, Contributors, WG,
As a prerequisite for the WGLC on this document:
Guidelines for Authors and Reviewers of Documents Containing YANG Data
Models
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11
Are you aware of any IPR that applies to draft
following repo
has been created for you: https://github.com/netmod-wg/schedule-yang.
Kent and Lou
> On Mar 26, 2024, at 11:49 AM, Kent Watsen wrote:
>
> NETMOD WG,
>
> This email begins a 2-week adoption poll for:
>
> A Common YANG Data Model for Scheduling
>
> This can never happen since the '#' char is not allowed in a YANG module name.
> YANG 1.1 tools look for MODNAME[@DATE].EXT.
> If the YANG module name is not in this format the tool will not find the
> module.
https://datatracker.ietf.org/doc/html/rfc7950#section-5.2 says:
The name of
This email begins a two-week WGLC on:
System-defined Configuration
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/
Please take time to review this draft and post comments by April 12. Favorable
comments are especially welcomed.
There is no known IPR for this
> Chongfeng
>
> 发件人: Kent Watsen [mailto:kent+i...@watsen.net]
> 发送时间: 2024年3月26日 9:31
> 收件人: maqiufang (A) ; Qin Wu ;
> Chongfeng Xie
> 抄送: netmod@ietf.org
> 主题: IPR Call on draft-ietf-netmod-system-config-05
>
> Authors, Contributors, WG,
>
> As a prer
NETMOD WG,
This email begins a 2-week adoption poll for:
A Common YANG Data Model for Scheduling
https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang
PS: This draft moved from OPSAWG to NETMOD
There is no known IPR on this draft:
https://mailarchive.
All authors and contributors have responded indicating no awareness of IPR
applying to this draft.
The adoption call may proceed now.
Kent // chair
> On Mar 25, 2024, at 7:44 PM, Kent Watsen wrote:
>
> [This draft moved from OPSAWG to NETMOD]
>
>
> Authors, Contribut
No, I'm not aware of any IPR that applies to this draft.
Kent // contributor
> On Mar 26, 2024, at 11:40 AM, Kent Watsen wrote:
>
> My last message didn’t tag all authors and contributors.
>
> This message adds to the “To” line the following additional authors
My last message didn’t tag all authors and contributors.
This message adds to the “To” line the following additional authors and
contributors:
- Chong Feng
- Kent Watsen
- Jan Linblad
- Jason Stern
Kent // chair
> On Mar 25, 2024, at 9:30 PM, Kent Watsen wr
y no IPR is filed for this draft:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-netmod-system-config.
Thanks.
Kent Watsen (as co-chair)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
se to the list above, and not unicast it.
PS: Currently no IPR is filed for this draft:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ma-opsawg-schedule-yang
Thanks.
Kent Watsen (as co-chair)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
time
>> zone).
>>
>> Thanks,
>> Jason (+ chairs Kent and Lou)
>>
>> Draft Agenda for the NETMOD 119 WG Session
>> https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod
>> https://datatracker.ietf.org/meeting/119/session/netmod
>>
"draft-ietf-netmod-immutable-flag-00" and upload to data tracker. Any
adoption-comments should be addressed in a -01 version.
No IPR was reported:
https://mailarchive.ietf.org/arch/msg/netmod/g_Rh24gXHZcfTUXDo0xZ-sXK-vU/
Thanks,
Kent and Lou
> On Feb 22, 2024, at 12:41 PM
and tree-diagram
views.
K.
> On Mar 5, 2024, at 11:21 AM, Italo Busi
> wrote:
>
> I like the idea of relying on tooling with hyperlinks
>
> For txt and pdf, I agree that a link is the best option since these formats
> are not optimized for including YANG trees
>
It seems that there are two camps:
1) those that want the tree-diagrams to be as DRY as possible
2) those that want the tree-diagrams to be as WET as possible
DRY = Don't Repeat Yourself
WET = Write Every Time
Tooling can help both cases.
For (1)
Hi Italo,
> On Mar 4, 2024, at 1:38 PM, Italo Busi
> wrote:
>
> I am wondering whether the issue of YANG tree too-long could be resolved by
> updating the IETF tooling. For example, I have noted that the html-ized
> version of the I-Ds is now working well with artwork exceeding the 72
> char
This email begins a two-week WGLC on:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11
Please take time to review this draft and post comments by March 14. Favorable
comments are especially welcomed.
Aside: this draft went through a WGLC six months ago, to which t
Hi Jan,
> On Feb 28, 2024, at 9:21 AM, Jan Lindblad wrote:
>
> Med, author team,
>
> Thank you for taking the time to get this work done, and well done! This is
> one of those fundamental bricks that saves time and improves quality for the
> entire YANG community.
>
> I read the -09 version
Hi Med,
I’ve been slow to provide follow-up responses to you regarding the "Adherence
to the NMDA" and "Security Considerations" sections, which I have refined even
more since our last interactions here.
1) In the Adherence to the NMDA section, I know that I pushed before to invert
the recomme
NETMOD WG,
This email begins a 2-week adoption poll for:
YANG Metadata Annotation for Immutable Flag
https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09
There is no known IPR on this draft:
https://mailarchive.ietf.org/arch/msg/netmod/g_Rh24gXHZcfTU
Thank you authors and contributors for your responses.
No IPR is being declared at this time.
Kent (and Lou)
> On Feb 12, 2024, at 5:50 PM, Kent Watsen wrote:
>
> Authors, Contributors, WG,
>
> As a prerequisite for the adoption on this document:
>
> YANG Me
Juergen, Tom, Andy,
Gentle reminder.
Kent // shepherd
> On Nov 14, 2023, at 4:49 PM, Kent Watsen wrote:
>
> Juergen, Tom, Andy,
>
> The previous WGLC for this draft didn’t succeed due to your comments.
> Qin’s update (1) below removes all the (metric) specific node-tag
> De : netmod mailto:netmod-boun...@ietf.org>> De la
> part de Kent Watsen
> Envoyé : vendredi 16 février 2024 21:55
> À : Andy Bierman mailto:a...@yumaworks.com>>
> Cc : netmod@ietf.org <mailto:netmod@ietf.org>
> Objet : Re: [netmod] Rfc8407 - what does this text
ine a
“temporary non-NMDA module”.
PS: top-posting for simplicity
K.
> On Feb 16, 2024, at 3:25 PM, Andy Bierman wrote:
>
>
>
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen <mailto:kent%2bi...@watsen.net>> wrote:
>> NETMOD,
>>
>> An IESG member rev
NETMOD,
An IESG member reviewing one of my drafts flagged a section I had written to
satisfy this text from
https://datatracker.ietf.org/doc/html/rfc8407#section-3.5:
If the document contains a YANG module(s) that is compliant with NMDA
[RFC8342], then the Introduction section sho
Authors, Contributors, WG,
As a prerequisite for the adoption on this document:
YANG Metadata Annotation for Immutable Flag
https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09
Are you aware of any IPR that applies to draft identified above?
Please sta
Hi Mohamad,
Thanks for the response.
Some thoughts below.
K
> On Feb 8, 2024, at 3:36 AM, mohamed.boucad...@orange.com wrote:
>
> Hi Kent, all,
>
> Let’s me also provide some background and explain why we are not using any
> normative language for enum vs identities. We used to have this te
Hi Mohamad,
Thanks for the response.
Some thoughts below.
K
> On Feb 8, 2024, at 3:36 AM, mohamed.boucad...@orange.com wrote:
>
> Hi Kent, all,
>
> Let’s me also provide some background and explain why we are not using any
> normative language for enum vs identities. We used to have this te
Authors, WG,
Following is a comment on Section 4.30.2.
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-06#section-4.30.2
The text says:
START
An IANA-maintained module may use identities (e.g., [RFC8675]) or enumerations
(e.g., [RFC9108]). The decision about which typ
Authors, WG,
Following is a comment on Section 4.30.3.1.
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-06#section-4.30.3.1
The text says: "The name of the "identity" is the lower-case of the name
provided in the registry.”
Yet Section 4.3.1. (Identifier Naming Conventions)
The draft interim minutes have been updated.
Thank you Jason, Jurgen, and Carsten for your valuable comments.
Link to minutes:
https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/
The minutes are reproduced below for convenience.
Please report any updates needed here.
Reminder that NETMID is having another Virtual Interim a week from today.
Kent
> On Jan 22, 2024, at 10:22 AM, IESG Secretary wrote:
>
> The Network Modeling (netmod) WG will hold a virtual interim meeting on
> 2024-02-06 from 09:00 to 11:00 America/New_York (14:00 to 16:00 UTC).
>
> Agenda:
Hi Juergen,
> Well, statements like "the WG agrees" are problematic for things that
> have not been discussed on the mailing list. Perhaps it is the people
> attending the interim agreed? Well, I can't tell, I have not been
> there...
Maybe but…
- it was an official Interim meeting (not just a
may work in circumstances where the operator doesn’t use
> templates or inactive config *or* the client reproduces the server logic for
> the running->intended transforms
>
> Jason
>
> From: netmod mailto:netmod-boun...@ietf.org>> On
> Behalf Of Kent Watsen
> Sent:
Link to minutes:
https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/
Reproduced below for convenience.
Please report any updates needed here.
Kent (and Lou)
This virtual interim was soley focused on the "system-config" draft.
Qiufang Ma presented.
Draft: https://dat
1 - 100 of 1026 matches
Mail list logo
