Re: [netmod] What's the plan with draft-ietf-netmod-node-tags

[Qin Wu]

Hi, Lou and Adrian:
We authors plan to issue a new version. We heard some feedback from Balazs and 
Rob, had some offline discussion with them during last IETF, come up with 
proposal and questions and brought up on the list on August, Juergen provided 
his thoughts on these proposal, it looks addition extension is not needed based 
on Juergen’s feedback. Silence for a while seems to stand for agreement,My 
feeling is some wording and clarification text is needed, but I love to hear if 
there are different options.

Chairs, please let us know anything else is needed from us.




吴钦 Wu Qin
Mobile：+86-13914734360(Mobile Number)
Email：bill...@huawei.com

发件人： Lou Bergermailto:lber...@labn.net>>
收件人： 
adrianmailto:adr...@olddog.co.uk>>;netmod-chairsmailto:netmod-cha...@ietf.org>>
抄送： 
netmodmailto:netmod@ietf.org>>;draft-ietf-netmod-node-tagsmailto:draft-ietf-netmod-node-t...@ietf.org>>
主题： Re: [netmod] What's the plan with draft-ietf-netmod-node-tags
时间： 2022-10-11 02:56:33

Adrian,

Thanks for this -- as far as I can tell, Jurgen's comments were not
addressed in the on-list discussion in August.  Do think that they
were?  We were at least expecting some document update based on the
discussion.

Authors/Contributors,

 Where do you think we stand in resolving the on-list discussion?

Thanks,

Lou (and Kent)

On 10/10/2022 4:29 AM, Adrian Farrel wrote:
> Hi,
>
> Discussion of this document seemed to fizzle out in August, and the last
> email seems to be Qin saying "I'm happy to make no change if no change is
> needed."
>
> Where does that leave us with regards to the WG last call comments and the
> discussion at IETF-114?
>
> Thanks,
> Adrian
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IETF 115 Slot Requests

[Lou Berger]

WG,

The *draft* agenda for IETF115 has been posted -
https://datatracker.ietf.org/meeting/115/agenda

The NetMod session information is scheduled to be held:

   Tuesday, November 8, 2022
   09:30-11:30 Tuesday Session I
   Richmond 4
   https://datatracker.ietf.org/meeting/115/sessions/netmod.ics

This will be a (new) normal in-person with remote participation meeting.

Please send slot requests to netmod-cha...@ietf.org before the end of 
the day Monday October 24 (any TZ, but earlier is appreciated).  Please 
include draft names(s), presenter, desired slot length.  Also, please 
let us know if you think the topic would be better covered in a Virtual 
Interim to be held at a future date.


Thank you!

Lou (Kent and Joel)

Important dates:

IETF 115
2022-11-05, London, GB
DateWeekday Description
2022-10-12  Wednesday   Cut-off date for requests to reschedule
Working Group or BOF meetings UTC 23:59
2022-10-14  Friday  Final agenda to be published
2022-10-24  Monday  Internet Draft submission cut-off (for all
drafts, including -00) by UTC 23:59 Upload
using the ID Submission Tool.
2022-10-24  Monday  Standard rate registration and payment cut-off
at UTC 23:59.
2022-10-26  Wednesday   Draft Working Group agendas due by UTC
23:59 Upload using the Meeting Materials
Management Tool.
2022-10-31  Monday  Registration cancellation cut-off at UTC 23:59
2022-10-31  Monday  Revised Working Group agendas due by UTC 23:59
Upload using the Meeting Materials Management
Tool.
2022-12-02  Friday  Proceedings submission cutoff date by UTC 23:59
Upload using the Meeting Materials Management
Tool.
2022-12-26  Monday  Proceedings submission corrections cutoff date
by UTC 23:59

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What's the plan with draft-ietf-netmod-node-tags

[Lou Berger]

Adrian,

Thanks for this -- as far as I can tell, Jurgen's comments were not 
addressed in the on-list discussion in August.  Do think that they 
were?  We were at least expecting some document update based on the 
discussion.


Authors/Contributors,

    Where do you think we stand in resolving the on-list discussion?

Thanks,

Lou (and Kent)

On 10/10/2022 4:29 AM, Adrian Farrel wrote:

Hi,

Discussion of this document seemed to fizzle out in August, and the last
email seems to be Qin saying "I'm happy to make no change if no change is
needed."

Where does that leave us with regards to the WG last call comments and the
discussion at IETF-114?

Thanks,
Adrian



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG module versioning: Proposed change to "Import by derived revision"

[Andy Bierman]

On Tue, Oct 4, 2022 at 7:02 AM Rob Wilton (rwilton)  wrote:

> Hi Juergen, WG,
>
> draft-ietf-netmod-yang-module-versioning defines section "4.  Import by
> derived revision" that allows an author to specify a minimum revision of a
> module that is allowed to satisfy a YANG import.
>
> IIRC, and hopefully you will correct me if I am wrong, you had two
> concerns about this approach:
> (1) It potentially changes the behaviour of a YANG compiler without a
> corresponding version change in the YANG language.
> (2) It is embedding version constraint information directly into the YANG
> module.
>
> The main reason for wanting this import was to help specify a minimum
> import dependency, e.g., perhaps a module depends on a new type that is
> only defined in version 1.1 and not available in any of the previous
> versions.  Here, having some level of minimum dependency in the importing
> YANG module seems broadly helpful (like a more helpful version of the
> existing import by exact revision-date), given that in many cases modules
> may be independently versioned.
>
> Anyway, I would like to propose a change (a softening) of the definition
> of the "revision-or-derived" extension statement in the Module Versioning
> Draft so rather than referring to a hard "minimum required revision" for
> the import to be valid, instead it is changed to refer to a softer
> "suggested minimum revision".  I.e., the intention is that the
> "revision-or-derived" statement is no longer a hard constraint on the
> import statement at all, it is just a suggestion for use by tooling and
> module readers, and which they are at liberty to entirely ignore.
>
> Tools that support the "revision-or-derived" would generally be expected
> to pick a revision that is derived from the revision/version specified in
> the "revision-or-derived" statement but are not required to do so.  E.g.,
> if they don't have a suitable version available, then they can import
> another module version.  Further, if such a tool does choose a version that
> isn't derived from the "revision-or-derived" statement then generating a
> YANG compiler warning message would be reasonable, but not required.
>
> The potential benefits of the new approach are:
> - arguably, this approach is more compatible with existing YANG 1.1 import
> rules.
> - sets of YANG modules that were compiled by tools that don't understand
> the "revision-or-derived" statement would still compile with tools that do
> understand it, possibly with the addition of some warning messages..
> - with a branched revision history, there are cases where the tighter
> import constraint isn't so helpful.
>
>
I do not think these extensions need to change.
In general, I would prefer a new YANG version but this specific extension
works with the most common usage mode.

OK to use extension:

   import foo {
  prefix f;
   }

Not OK to use extension:

  import foo {
  prefix f;
  revision-date 2000-01-01;
   }

If no revision-date is present, then a YANG 1.1 tool should expect any
revision.
The 'revision-or-derived' extension cannot be used together with
'revision-date' because a YANG 1.1
tool is expecting an exact revision in this case.


If/when YANG 2.0 comes along, we could either keep with the relaxed
> definition proposed above, or possibly tighten the definition to what we
> have today.
>
>
The trade-off for using an extension is that is conditional and optional to
implement.
A general YANG tool can ignore the 'nacm:default-deny-all' extension, but
it is mandatory
for a NACM implementation to support it.

I would be interested in Juergen's and the WG's opinion on this proposed
> change in behaviour.
>
> Regards,
> Rob
>
>

Andy


> // As a contributor to the versioning work.
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] What's the plan with draft-ietf-netmod-node-tags

[Adrian Farrel]

Hi,

Discussion of this document seemed to fizzle out in August, and the last
email seems to be Qin saying "I'm happy to make no change if no change is
needed."

Where does that leave us with regards to the WG last call comments and the
discussion at IETF-114?

Thanks,
Adrian

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod