Hi Lou, all,
No, I'm not aware of any IPR that applies to this draft.
Cheers,
Med
> -Message d'origine-
> De : Lou Berger
> Envoyé : lundi 5 décembre 2022 23:51
> À : OSCAR GONZALEZ DE DIOS ;
> samier.barguilgiraldo@telefonica.com; BOUCADAIR Mohamed
> INNOV/NET
> Cc : NetMod WG
On Mon, Dec 5, 2022 at 2:37 PM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:
> On Mon, Dec 05, 2022 at 08:19:12PM +, Kent Watsen wrote:
> >
> >
> > Hi Juergen,
> >
> >
> >
> > >> 3) There are two "time-with-zone-offset" typedefs (one should be
>
Authors, Contributors, WG,
In preparation for WG Adoption
Are you aware of any IPR that applies to drafts identified above?
Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"
If so, has this IPR been disclosed
The NETMOD WG has placed draft-dbb-netmod-acl in state
Candidate for WG Adoption (entered by Lou Berger)
The document is available at
https://datatracker.ietf.org/doc/draft-dbb-netmod-acl/
___
netmod mailing list
netmod@ietf.org
On Mon, Dec 05, 2022 at 08:19:12PM +, Kent Watsen wrote:
>
>
> Hi Juergen,
>
>
>
> >> 3) There are two "time-with-zone-offset" typedefs (one should be
> >> "time-without-zone-offset"?)
> >
> > No, I only see one.
>
> My bad, I didn't see the subtype.
>
> But I may've been thrown off
Hi Juergen,
>> 3) There are two "time-with-zone-offset" typedefs (one should be
>> "time-without-zone-offset"?)
>
> No, I only see one.
My bad, I didn't see the subtype.
But I may've been thrown off by the following "no-zone" types...should they be
named consistently?
- date-no-zone
Hi all,
A follow up for the comments below about “10. Security Considerations”:
We added some more detailed text in the security section of Module Versioning
and it will be in the next published version that goes to LC.
You can see the text here for now:
updated security considerations by
Hi Automation Gurus,
YANG modules may be treated like a "digital twin" of the network with different
resolution/accuracy (depending on Module details).
It looks like RFC 8969 is discussing that different YANG models (for different
layers or functions) of the same network should be the
On Mon, Dec 05, 2022 at 01:24:03PM +, Kent Watsen wrote:
> Thanks for this update Juergen. I was just thinking this morning to ping you
> on it.
>
>
> ietf-yang-types:
>
> 1) The table in the "Overview" section needs to reflect new names (e.g.,
> s/date/date-with-zone-offset/)
Fixed.
>
Thanks for this update Juergen. I was just thinking this morning to ping you
on it.
ietf-yang-types:
1) The table in the "Overview" section needs to reflect new names (e.g.,
s/date/date-with-zone-offset/)
2) The "revision" statement needs to reflect new names (e.g.,
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.
Title : Common YANG Data Types
Author : Jürgen Schönwälder
Filename: draft-ietf-netmod-rfc6991-bis-14.txt
Hi,
Alex Huang Feng wrote:
> Dear NETMOD WG,
>
> Some time ago I sent this email to the YANG doctors to check with
> them. I would also like to have your insights on mandatory augmented
> leaves.
>
> We are working on a YANG module for the following draft:
>
Dear NETMOD WG,
Some time ago I sent this email to the YANG doctors to check with them. I would
also like to have your insights on mandatory augmented leaves.
We are working on a YANG module for the following draft:
13 matches
Mail list logo