:04
À : BOUCADAIR Mohamed INNOV/NET ;
netmod@ietf.org
Objet : RE: [netmod] TR: New Version Notification for draft-
boucadair-netmod-iana-registries-00.txt
writes:
...
As a proof of concept, I
prepared XSLT stylesheets for a dozen or so registries [1].
Although
it works quite well, I do
and also Section .
Cheers,
Med
> -Message d'origine-
> De : Ladislav Lhotka
> Envoyé : vendredi 25 mars 2022 15:04
> À : BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> Objet : RE: [netmod] TR: New Version Notification for draft-
> boucadair-netmod-iana-registrie
: BOUCADAIR Mohamed INNOV/NET
Objet : New Version Notification for
draft-boucadair-netmod-iana-registries-06.txt
A new version of I-D, draft-boucadair-netmod-iana-registries-06.txt
has been successfully submitted by Mohamed Boucadair and posted to the IETF
repository.
Name: draft-boucadair
this comment are more
than welcome.
Cheers,
Med
-Message d'origine-
De : internet-dra...@ietf.org
Envoyé : jeudi 8 septembre 2022 13:51
À : BOUCADAIR Mohamed INNOV/NET
Objet : New Version Notification for
draft-boucadair-netmod-iana-registries-04.txt
A new version of I-D, draft
Notification for
draft-boucadair-netmod-iana-registries-00.txt
Hi all,
FWIW, a new version with the change of a normative language is available at:
URL:
https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-03.txt
Status:
https://datatracker.ietf.org/doc
Hi all,
FWIW, a new version with the change of a normative language is available at:
URL:
https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-03.txt
Status:
https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/
Htmlized:
https
. Will keep that text. Thank you.
Cheers,
Med
De : Andy Bierman
Envoyé : lundi 28 mars 2022 20:05
À : BOUCADAIR Mohamed INNOV/NET
Cc : Ladislav Lhotka ; Jürgen Schönwälder
; netmod@ietf.org
Objet : Re: [netmod] TR: New Version Notification for
draft-boucadair-netmod-iana-registries-00.txt
Hi
Re-,
>
> Thanks, Lada.
>
> I updated the draft accordingly + reflected the interpretation shared by
> Jürgen.
>
> URL:
> https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-boucadair-netmod-ian
. The SAFI name space is defined in this document. The IANA
registered and maintains values for the SAFI namespace as follows:
===
Freezing afi-safis in an IETF-maintained module is indeed an example of designs
that draft-boucadair-netmod-iana-registries is trying to avoid.
Cheers,
Med
>
> > Cheers,
> > Med
> >
> > -Message d'origine-----
> > De : internet-dra...@ietf.org
> > Envoyé : jeudi 24 mars 2022 10:41
> > À : BOUCADAIR Mohamed INNOV/NET
> > Objet : New Version Notification for
> > draft-boucadair-netm
Re-,
Thanks, Lada.
I updated the draft accordingly + reflected the interpretation shared by Jürgen.
URL:
https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-02.txt
Status:
https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/
Htmlized
; netmod@ietf.org
>> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
>> netmod-iana-registries-00.txt
>>
>> Hi Med,
>>
>> here are my comments:
>>
>> YANG modules should be as tightly coupled as possible to the
>> corres
or draft-boucadair-
> netmod-iana-registries-00.txt
>
> Hi Med,
>
> here are my comments:
>
> YANG modules should be as tightly coupled as possible to the
> corresponding IANA registries. In an ideal world, YANG would simply have
> a statement for using a regist
ikely to be out of sync.
> >
> > Some more details/context are provided in the I-D.
> >
> > Comments and suggestions are appreciated.
> >
> > Cheers,
> > Med
> >
> > -Message d'origine-----
> > De : internet-dra...@ietf.org
> >
Message d'origine-
> De : internet-dra...@ietf.org
> Envoyé : jeudi 24 mars 2022 10:41
> À : BOUCADAIR Mohamed INNOV/NET
> Objet : New Version Notification for
> draft-boucadair-netmod-iana-registries-00.txt
>
>
> A new version of I-D, draft-boucadair-netmod-iana-r
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Jürgen Schönwälder
> > Envoyé : vendredi 25 mars 2022 09:01
> > À : BOUCADAIR Mohamed INNOV/NET
> > Cc : Qin Wu ; netmod@ietf.org
> > Objet : Re: [netmod] TR: New Version Notification for draf
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Jürgen Schönwälder
> Envoyé : vendredi 25 mars 2022 09:01
> À : BOUCADAIR Mohamed INNOV/NET
> Cc : Qin Wu ; netmod@ietf.org
> Objet : Re: [netmod] TR: New Version Notification for draft-boucad
On Fri, Mar 25, 2022 at 07:49:42AM +, mohamed.boucad...@orange.com wrote:
> > Anyway, my main point is that I do not see that the extensibility
> > implications of enumerations and identities change just because a module
> > is owned by IANA. Allocating a new enum requires an update of the
; new value, i.e., vendors can independently allocate values. This
> fundamental difference does not change just because a module is owned by
> IANA.
>
> /js
>
> On Fri, Mar 25, 2022 at 06:36:09AM +, mohamed.boucad...@orange.com
> wrote:
> > Hi all,
> >
> >
e.com wrote:
> 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
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
w Version Notification for
> >draft-boucadair-netmod-iana-registries-00.txt
>
> >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 no
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
>-邮件原件-
>发件人: 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 Th
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
fication for draft-boucadair-
> netmod-iana-registries-00.txt
>
> Hi,
>
> the document says that it updates RFC 8407.
[Med] yes, it is more "extends" than "amends" (as per
https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag) except for
one point
tails/context are provided in the I-D.
>
> Comments and suggestions are appreciated.
>
> Cheers,
> Med
>
> -Message d'origine-
> De : internet-dra...@ietf.org
> Envoyé : jeudi 24 mars 2022 10:41
> À : BOUCADAIR Mohamed INNOV/NET
> Objet : New Version Notificat
INNOV/NET
Objet : New Version Notification for
draft-boucadair-netmod-iana-registries-00.txt
A new version of I-D, draft-boucadair-netmod-iana-registries-00.txt
has been successfully submitted by Mohamed Boucadair and posted to the IETF
repository.
Name: draft-boucadair-netmod-iana
On 29. 11. 21 14:32, Robert Varga wrote:
On 26/11/2021 09:30, Ladislav Lhotka wrote:
And what do yo do with Early Allocation, which can last more than a
year?
Sorry, I am not familiar with early allocations, what could be the
problem here?
The problem is that early allocations are temporary
On 26/11/2021 09:30, Ladislav Lhotka wrote:
And what do yo do with Early Allocation, which can last more than a year?
Sorry, I am not familiar with early allocations, what could be the problem here?
The problem is that early allocations are temporary and automatically
expire in 12 months
Hi Lada,
> On 2021-11-26, at 09:48, Ladislav Lhotka wrote:
>
> Carsten Bormann writes:
>
>> On 2021-11-24, at 09:13, Ladislav Lhotka wrote:
>>>
>>> Please let me know what you think about this.
>>
>> I think it is amazing.
>>
>> So for each registry, you have
>>
>> — manually extracted
Carsten Bormann writes:
> On 2021-11-24, at 09:13, Ladislav Lhotka wrote:
>>
>> Please let me know what you think about this.
>
> I think it is amazing.
>
> So for each registry, you have
>
> — manually extracted an information model and kept that in your head,
Well, my old head doesn't serve
tom petch writes:
> From: netmod on behalf of Ladislav Lhotka
>
> Sent: 24 November 2021 08:13
>
> Hi,
>
> I tried to generalize the approach of RFC 9108 and develop XSLT stylesheets
> for generating YANG modules directly from IANA registries. The results are in
> this GitHub project:
>
>
On 2021-11-24, at 09:13, Ladislav Lhotka wrote:
>
> Please let me know what you think about this.
I think it is amazing.
So for each registry, you have
— manually extracted an information model and kept that in your head,
— written code that translates the information you could extract from
From: netmod on behalf of Ladislav Lhotka
Sent: 24 November 2021 08:13
Hi,
I tried to generalize the approach of RFC 9108 and develop XSLT stylesheets for
generating YANG modules directly from IANA registries. The results are in this
GitHub project:
https://github.com/llhotka/iana-yang
So
Hi,
I tried to generalize the approach of RFC 9108 and develop XSLT stylesheets for
generating YANG modules directly from IANA registries. The results are in this
GitHub project:
https://github.com/llhotka/iana-yang
So far I have processed 22 registries - most of them are related to DNS, but
Maybe this approach can be for the algorithms in the "iana-*algs.yang" modules
defined in the crypto-types draft. The '*' expands to symmetric, asymmetric,
and hash. The problem is that I'm unsure if there is exists 1-1 registries.
But, to the extent there are registries, this approach
Ladislav Lhotka writes:
> Hi,
>
> I would like to discuss the issue of developing YANG modules that mirror IANA
> registries. The main objection, raised in DNSOP WG in relation to
> draft-lhotka-dnsop-iana-class-type-yang-02, was that the RFC containing the
> initial revision of the module
On Tue, 2019-11-19 at 11:48 +, tom petch wrote:
> - Original Message -
> From: "Ladislav Lhotka"
> To: "Martin Bjorklund"
> Cc:
> Sent: Tuesday, November 19, 2019 10:29 AM
>
> > On Tue, 2019-11-19 at 11:17 +0100, Martin Bjorklund wrote:
> > > Ladislav Lhotka wrote:
> > > > Hi,
> >
On Tue, 2019-11-19 at 11:17 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka wrote:
> > Hi,
> >
> > I would like to discuss the issue of developing YANG modules that
> > mirror IANA registries. The main objection, raised in DNSOP WG in
> > relation to draft-lhotka-dnsop-iana-class-type-yang-02,
Ladislav Lhotka wrote:
> Hi,
>
> I would like to discuss the issue of developing YANG modules that
> mirror IANA registries. The main objection, raised in DNSOP WG in
> relation to draft-lhotka-dnsop-iana-class-type-yang-02, was that the
> RFC containing the initial revision of the module
Hi,
I would like to discuss the issue of developing YANG modules that mirror IANA
registries. The main objection, raised in DNSOP WG in relation to
draft-lhotka-dnsop-iana-class-type-yang-02, was that the RFC containing the
initial revision of the module doesn't get updated along with the IANA
On Mon, 2019-10-21 at 14:54 +, Kent Watsen wrote:
> Hi Lada,
>
> > Another option, also suggested in DNSOP WG, was to enable YANG to refer
> > directly to the IANA registry.
>
> For crypto types, I don’t know if this it possible, as there may be many
> registries involved.
>
> Regardless,
Hi Lada,
> Another option, also suggested in DNSOP WG, was to enable YANG to refer
> directly to the IANA registry.
For crypto types, I don’t know if this it possible, as there may be many
registries involved.
Regardless, what is it that is doing the referring? an identityref? there
Kent Watsen writes:
> All,
>
>>> That's a bit odd. But perhaps it can be solved by actually not
>>> filling in all values in this module, but rather make it a template
>>> and instruct IANA to fill it in with the contents of the registry at
>>> the time of publication.
>>
>> OK, so the module
All,
>> That's a bit odd. But perhaps it can be solved by actually not
>> filling in all values in this module, but rather make it a template
>> and instruct IANA to fill it in with the contents of the registry at
>> the time of publication.
>
> OK, so the module template in the RFC couldn't be
On Thu, 2019-10-10 at 14:07 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka wrote:
> > Hi,
> >
> > some of you have probably seen the discussions around
> >
> > https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02
> >
> > We proposed to adopt it as a work item in the DNSOP
Ladislav Lhotka wrote:
> Hi,
>
> some of you have probably seen the discussions around
>
> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02
>
> We proposed to adopt it as a work item in the DNSOP WG, but despite
> some support this is probably not going to happen. The
Hi,
some of you have probably seen the discussions around
https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02
We proposed to adopt it as a work item in the DNSOP WG, but despite some support
this is probably not going to happen. The substantial objections are:
1. It is not
49 matches
Mail list logo
