Hi all,
FWIW, a new version that reflects the comments heard so far is available
online:
URL:
https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-01.txt
Status:
https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/
Htmlized:
htt
> I don’t see a specific need for timestamps, so I can accept your arguments
> against it. Just add a sentence about it somewhere into the draft. It can be
> an appendix.
>
>
> OK with me.
> A timestamp could be added in the future if it is really important enough.
LastModified is drop-dead
Hi Jan,
> On Mar 24, 2022, at 4:37 PM, Jan Lindblad wrote:
>
> f this isn't obvious, here's an example:
> 1. Client A sends an edit to the server If-Unmodified-Since t0. Successful.
> Receives a Last-Modified timestamp t1.
> 2. Client B sends a an edit to the server. Last-Modified timestamp on
On Thu, Mar 24, 2022 at 1:52 PM Balázs Lengyel
wrote:
> Hello Jan,
>
> I don’t see a specific need for timestamps, so I can accept your arguments
> against it. Just add a sentence about it somewhere into the draft. It can
> be an appendix.
>
>
>
OK with me.
A timestamp could be added in the futu
Hello Jan,
I don’t see a specific need for timestamps, so I can accept your arguments
against it. Just add a sentence about it somewhere into the draft. It can be an
appendix.
Common/Uniform ETAGs for multiple interfaces is only important if you actually
use multiple interfaces. That actually h
Andy, Balazs, Kent,
Thanks for your very good questions. Comments inline.
> I assume that the etag defined in your I-D is the same as the one defined in
> Restconf. Does or should your draft include a statement like:
>
> “The etag values maintained by the server are protocol/interface independen
See as BALAZS3, below!
From: Andy Bierman
Sent: Thursday, 24 March, 2022 18:48
To: Balázs Lengyel
Cc: maqiufang (A) ; Kent Watsen
; NETMOD Group
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00
On Thu, Mar 24, 2022 at 10:14 AM Balázs Lengyel
mailto:balazs.len
On Thu, Mar 24, 2022 at 10:14 AM Balázs Lengyel
wrote:
> As mentioned earlier immutable is not enough for predefined NACM rules
>
> because the client may always
>
> insert a rule(-list) before the immutable rule(s) that will make the
> immutable
>
> rules ineffective. The problem is that the rul
From: netmod on behalf of Jürgen Schönwälder
Sent: 22 March 2022 07:11
So we have the following options:
a) Leave revision-date to be defined in ietf-yang-revisions.
b) Define revision-date in ietf-yang-types.
c) Define a date-no-zone type (derived from the date type) which does
not have
As mentioned earlier immutable is not enough for predefined NACM rules
because the client may always
insert a rule(-list) before the immutable rule(s) that will make the immutable
rules ineffective. The problem is that the rule(-sets) are a user ordered list
where the order matters. It is not enoug
Hello,
So it seems we agree, that a schema level immutable property based on yang
extensions is needed. (I am not commenting on the other parts just now.)
Regards Balazs
From: Andy Bierman
Sent: Thursday, 24 March, 2022 16:13
To: maqiufang (A)
Cc: Balázs Lengyel ; Kent Watsen
; NETMOD Group
S
On Thu, Mar 24, 2022 at 7:22 AM maqiufang (A) wrote:
> Hi, Andy, Balazs,
>
>
>
> I can see your points in some of the use cases.
>
> But as Kent mentioned, the motivation of this work is that we have some
> system-defined instance which are read-only to clients.
>
> And there may be some cases wh
Hi, Andy, Balazs,
I can see your points in some of the use cases.
But as Kent mentioned, the motivation of this work is that we have some
system-defined instance which are read-only to clients.
And there may be some cases where a list/leaf-list data node may exist in
multiple instances with diff
On Thu, Mar 24, 2022 at 11:23:39AM +, Qin Wu wrote:
> >-邮件原件-
> >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
> >发送时间: 2022年3月24日 18:56
> >收件人: mohamed.boucad...@orange.com
> >抄送: netmod@ietf.org
> >主题: Re: [netmod] TR: New Version Notification for
> >draft-boucad
Re-,
Agree with Qin. This is one of the usual comments from yangdoctors.
The proposed clarification in draft-boucadair-netmod-iana-registries makes
explicit that, for IANA-maintained modules, designers should make a decision
based solely on their specific context.
Cheers,
Med
> -Message
>-邮件原件-
>发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
>发送时间: 2022年3月24日 18:56
>收件人: mohamed.boucad...@orange.com
>抄送: netmod@ietf.org
>主题: Re: [netmod] TR: New Version Notification for
>draft-boucadair-netmod-iana-registries-00.txt
>On Thu, Mar 24, 2022 at 10:44:42AM
On Thu, Mar 24, 2022 at 10:44:42AM +, mohamed.boucad...@orange.com wrote:
> > It seems that later on you are actually changing what RFC 8407 says
> > although I am not sure I understand the reasoning. RFC 8407 recommends
> > to use enums if there is a single naming authority allocating values a
Hi Jürgen,
Thank you for the feedback.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Jürgen Schönwälder
> Envoyé : jeudi 24 mars 2022 11:27
> À : BOUCADAIR Mohamed INNOV/NET
> Cc : netmod@ietf.org
> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair
Hi,
the document says that it updates RFC 8407. I assume that the intended
semantic here is that this document augments what is being said in RFC
8407 but it does not change anything said in RFC 8407. I like the
recommendation given in other places of being explicit about what
"updates" means.
OL
Hi all,
We had in alto wg a discussion about consistent use of IANA-maintained modules.
This document provides some guidelines that I hope will ensure some consistency
about how we are interacting with IANA registries. The goal is avoid
transforming YANG modules (if not maintained by IANA) as
20 matches
Mail list logo
