This was my thought as well, that it would be best to have the
smallest-possible draft update 6020/7950. That way, when someone follows the
“Updated” links, they’re not overloaded with material that could’ve been left
out.
Jason was saying that just doing MUST/SHOULD by alone isn’t great, that
Hi Jan,
RFC 8342 defines the ability for "configuration transformations” to map
to , which is "subject to validation”.Section 5.1.4
describes cross-cutting features, such as deactivating nodes and templating,
that can result in an invalid , when is considered alone.
However, clients can
“Must” statements on opstate usefully helps clients know when certain values
will always appear, enabling better optimization and usability.
E.g., for Syslog messages, there must always be a timestamp, severity, and a
message. It would be unhelpful for the server to not declare its intention to
My confusion, sorry, I was thinking “mandatory”.
Must statements on opstate are useful, but less important.
Kent
> On Nov 6, 2023, at 5:26 PM, Kent Watsen wrote:
>
> “Must” statements on opstate usefully helps clients know when certain values
> will always appear, ena
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-tags.
All that is left now is the generic mechanism for tagging nodes.
Can you confirm that this update (-11) addresses your concerns?
Thanks,
Dear NETMOD WG,
Following up on an action from the 118 session, the chairs would like to
schedule an Interim meeting to discuss draft-ietf-netmod-system-config.
Considering various time-options with Qiufang, as author, it seemed that the
following 2-hour slot was best for all (see table at bott
son
>> (perander)
>> Sent: Monday, December 4, 2023 7:05 PM
>> To: Kent Watsen ; netmod@ietf.org
>> Subject: Re: [netmod] Proposed date for Interim on system-config-04
>>
>>
>> CAUTION: This is an external email. Please be very careful when clicking
With limited experience wrt the impact on servers, as a client, it’s always
best for the opstate data to be modeled as accurately as possible, for better
processing and user experience.
K.
> On Dec 22, 2023, at 1:37 PM, Acee Lindem wrote:
>
> We’ve had some discussions as to whether YANG mod
In the “here’s something different” category…
I’m interested in creating an SPA (single page application) on top of a
RESTCONF server.
Popular SPA frameworks include AngularJS, Ember.js, ExtJS, Knockout.js,
Meteor.js, React, Vue.js, and Svelte. TypeScript is a used by these frameworks
to “t
Thanks Lada!
> On Jan 2, 2024, at 6:50 AM, Ladislav Lhotka wrote:
>
> Hi Kent,
>
> it's not exactly what you are asking for but FWIW Yangson has a method
> DataModel.schema_digest [1]
> that returns a “schema digest” - a JS object that contains all information
> that is necessary for such a
> On Jan 3, 2024, at 4:58 AM, Ladislav Lhotka wrote:
>
> Kent Watsen mailto:kent+i...@watsen.net>> writes:
>
>> Thanks Lada!
>>
>>
>>> On Jan 2, 2024, at 6:50 AM, Ladislav Lhotka wrote:
>>>
>>> Hi Kent,
>>>
&g
Dear NETMOD WG,
The chairs would like to schedule an Interim meeting to discuss
draft-ietf-netmod-immutable-flag.
- note that this is in addition to the Interim on Jan 23 for the
system-config draft.
Considering various time-options with Qiufang, as author, with Chinese Lunar
New Year
I’m going to schedule this Interim now but, please be advised that, per Jan’s
comment on for the "system-config” interim, the “CET” label should’ve been
“UTC” instead.
Kent
> On Jan 11, 2024, at 6:18 PM, Kent Watsen wrote:
>
> Dear NETMOD WG,
>
> The chairs would
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
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:
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
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:
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.
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)
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
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, 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
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
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
> 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
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
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
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
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
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
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 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
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)
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
>
"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
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
>>
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
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
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
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
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
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.
> 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
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
> 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
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
>
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
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
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
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
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
> 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
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
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
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!
/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
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
> 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
> 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
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
[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
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
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
[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
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
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
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
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
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.
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 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 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
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,
> 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
> 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
> 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
>
>
&
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
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.
[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
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,
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
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
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
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,
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 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
> As you probably know from a previous message to the list, Jürgen
>>announced his plans to step down as co-chair.
>> Please welcome Kent Watsen, who has accepted to serve as NETMOD
>>co-chair.
>> As agreed with Jürgen, the NETMOD WG will run with three chairs until
>>
It's unclear to me why Y45-04 is needed at all. Doesn't a newer revision
of a module contain all the same typedefs from before, and thus a module
could import just the more recent revision to get everything it needs?
Why would a module ever have to import an older revision?
RFC 6020 says "New t
>You seem to be suggesting that Kent is an uninformed observer and Y45-04
>is actually really easy to understand. Neither is true.
I appreciate Andy's vote of confidence, but the reality is that I fell
into a black hole right at the end of the Dallas meeting and just now
caught up on the Y45 d
Following up on
https://www.ietf.org/mail-archive/web/netmod/current/msg12549.html, and
also to help other drafts progress, we'd like to schedule 3-4 one-hour
virtual interim meetings before the meeting in Prague.
The first meeting is already set in terms of time and agenda (see below),
but the
There has only been one response so far. Please respond by tomorrow if
interested in having time during an interim meeting.
Thanks,
Kent
On 5/22/15, 5:39 PM, "Kent Watsen" wrote:
>
>Following up on
>https://www.ietf.org/mail-archive/web/netmod/current/msg12549.html, and
> Otherwise, the leafref value MUST be a valid value of the
> data type that is defined for the referenced leaf.
Is it a MUST or a SHOULD?
Obviously, if it's not a valid value, a match will never occur, but that's
a user error, no?
It comes down to a validation warning versus a validation erro
>I think the two leafs are coupled through the path statement and so the
>values of both should conform to the same type. If I extend Balazs¹
>example with uint8 and 1..10 range:
>
>1. Would a leafref value of 256 be acceptable?
>
>2. How about "foo"?
I agree it doesn't makes sense, but is the
On 6/8/15, 12:33 PM, "Martin Bjorklund" wrote:
>Andy Bierman wrote:
>> On Mon, Jun 8, 2015 at 8:39 AM, Kent Watsen wrote:
>>> The leafref is marked require-instance=false, it just means a matching
>> > condition will never succeed.
>> >
>>
Hi Andy,
Yes, it makes sense to add guidelines for YANG 1.1 before attempting a
Last Call.
Thanks for bring attention to this.
Kent
On 6/13/15, 2:53 AM, "Andy Bierman" wrote:
>Hi,
>
>This update to the YANG guidelines draft addresses all the github
>issues. I don't think there are any ope
This is a notice to start a NETMOD WG last call for the document "JSON Encoding
of Data Modeled with YANG":
https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04
Please indicate your support by Monday June 29, 2015 at 9PM EST.
We are not only interested in receiving defect reports, we are
This is a notice to start a NETMOD WG last call for the document "Defining and
Using Metadata with YANG":
https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-01
Please indicate your support by Monday June 29, 2015 at 9PM EST.
We are not only interested in receiving defect reports, we ar
Netmod WG:
This mail starts the IPR poll on draft-ietf-netmod-yang-json-04.
Are you aware of any IPR that applies to draft-ietf-netmod-yang-json-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details).
If you are listed as a
NETMOD WG:
This mail starts the IPR poll on draft-ietf-netmod-yang-metadata-01.
Are you aware of any IPR that applies to draft-ietf-netmod-yang-metadata-01?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details).
If you are list
101 - 200 of 1082 matches
Mail list logo
