lass or type registration
>> has been
>> > deprecated or obsoleted. IANA "deprecated" maps to YANG
>> > status "deprecated", and IANA "obsolete" maps to YANG status
>> > "obsolete".
>> >
>> > Does
> below, but it may be helpful for you, Warren, I, possibly Michelle, to have a
> quick chat to see if we can resolve it.
>
>
>
>> -Original Message-
>> From: Ladislav Lhotka
>> Sent: 03 June 2021 14:17
>> To: Rob Wilton (rwilton) ; The IESG
>>
ut I do wonder if
>> > any identifier more closely aligned to the registry's role is available.
>>
>> Again, it is only required to work for the initial revision. I would be
>> happy to work with IANA on a more "durable" version of the stylesheet but,
parameters-2" and "dns-parameters-4" is in the
> class of things that (if I understand correctly) IANA is not always keen
> on people doing. In this case it's probably not a big issue, since the
> output of the transformation will be looked at by a human before
tions spelled out in the YANG
specification [RFC7950] apply for this document as well.
Is it sufficient?
Thanks, Lada
>
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
my knowledge) RESTCONF is the name of the
protocol and no expansion exists.
>
> 2. -
>
> FP: I believe it would be good to add a sentence in the terminology section
> stating that DNS terminology is used throughout the document, and point to RFC
> 8499 and/or RFC 10
>
> --
> COMMENT:
> --
>
> Hi,
>
> Thanks for this document. I think that documenting this fields in YANG is a
> good thin
Operations WG of the
IETF.
Title : YANG Types for DNS Classes and Resource Record
Types
Authors : Ladislav Lhotka
Petr Spacek
Filename: draft-ietf-dnsop-iana-class-type-yang-03.txt
Pages : 13
Date
be used for configuration data: old clients can always use
corresponding numeric values in place of unsupported enums.
If the module update rules of sec. 11 in RFC 7950 are observed, then the risk
of interoperability issues is IMO reasonably low.
Lada
>
> Nits/editorial comments:
>
>
;
> Nits:
> I think that RFC 8174 should also be referenced (along with RFC 2119).
>
Updated, thanks.
Lada
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Such items will be clearly labelled in both the IANA registry and YANG module.
If they are used in new implementations, it might mostly be, I suspect, due to
some external pressures rather than implementers' ignorance.
Ladislav
>
> Paul
>
> _____
nd Resource Record Types
> Authors : Ladislav Lhotka
> Petr Spacek
> Filename: draft-ietf-dnsop-iana-class-type-yang-01.txt
> Pages : 13
> Date: 2020-05-15
>
> Abstract:
>This doc
On 13. 05. 20 12:25, Joe Abley wrote:
> Hi Lada,
>
> On 13 May 2020, at 03:19, Ladislav Lhotka wrote:
>
>> IANA did an early review of the draft in $subj. As you can see below,
>> Michelle proposes that the XSLT stylesheet be removed upon publication of
>> the
>
> > Just letting you know the review has commenced.
> >
> > Best regards,
> >
> > Michelle Cotton
> > Protocol Parameters Engagement Sr. Manager
> > IANA Services
> >
End of forwarded message
--
Ladislav Lhotk
On Tue, 2019-12-17 at 11:06 -0500, Paul Wouters wrote:
> On Tue, 17 Dec 2019, Ladislav Lhotka wrote:
>
> > this draft replaces draft-lhotka-dnsop-iana-class-type-yang-02.
>
> Although it seems to have no defined that yet in the datatracker. I
> think you can still do it af
the IETF.
>
> Title : YANG Types for DNS Classes and Resource Record Types
> Authors : Ladislav Lhotka
> Petr Spacek
> Filename: draft-ietf-dnsop-iana-class-type-yang-00.txt
> Pages : 13
>
On Fri, 2019-10-11 at 10:03 -0400, Joe Abley wrote:
> On 10 Oct 2019, at 09:55, Paul Wouters wrote:
>
> > On Thu, 10 Oct 2019, Ladislav Lhotka wrote:
> >
> > > They should not actually be reading the RFC but get the latest revision of
> > > the modul
Paul Wouters writes:
> On Thu, 10 Oct 2019, Ladislav Lhotka wrote:
>
>> They should not actually be reading the RFC but get the latest revision of
>> the module from this page:
>>
>> https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
>
> Y
Paul Wouters writes:
> On Tue, 8 Oct 2019, Ladislav Lhotka wrote:
>
>>> Speaking for myself, as long as we are not populating RFCs with
>>> obsoleted DNS data or just create RFC with copies of IANA registries,
>>> I'm fine with helping on a document. But n
Paul Wouters writes:
> On Tue, 8 Oct 2019, Ladislav Lhotka wrote:
>
> (added IESG to CC:)
>
>>> We don't want to have to update the RFC every time the registry is updated.
>>> Could the RFC just describe exactly how to to convert the registry to YANG?
>>
NA will then handle all future updates on their own. This is explained in the
I-D itself (last paragraph of the Introduction) and has already been discussed
in this mailing list.
The IANA Considerations sections then gives details about converting new
registry entries into the corresponding YANG types.
Several years of experience with the interface type registry (RFC 7224) shows
that this process works quite smoothly.
Lada
>
> --
> Bob Harold
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
NA registries, then it should be
corrected there in the first place. Making a YANG module as an improved version
of an IANA registry sounds like a bad idea to me, also because it would be
difficult to coordinate future updates.
Or do you have another suggestion?
Lada
>
> Paul
-
co-chair
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
This call for adoption ends: 29 July 2019
Thanks,
Benno Overeinder DNSOP co-chair
___ DNSOP mailing
list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
--
Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
reference to A6. The status of A6 in this
draft is set to obsolete, as it should be. But what should the
status of DLV be in this document? This question I guess proves
Paul's argument that putting snapshots of IANA registries in an
I-D is a bad idea.
Ladislav Lhotka, the primary auth
mentors of the
module, and clients of management protocols such as NETCONF cannot
expect anything else from the server than an error, if they use such an
enum value.
Lada
>
> Paul
>
> _______
> DNSO
Petr Špaček writes:
> On 13. 11. 18 7:03, Paul Wouters wrote:
>> On Mon, 12 Nov 2018, Ladislav Lhotka wrote:
>>> we would like to ask the working group to adopt the following I-D as a
>>> WG item:
>>>
>>> https://tools.ietf.org/html/draft-lhotka-dn
Joe Abley writes:
> On 13 Nov 2018, at 14:07, Ladislav Lhotka wrote:
>
>> Paul Wouters writes:
>>
>>> On Mon, 12 Nov 2018, Ladislav Lhotka wrote:
>>>
>>>> we would like to ask the working group to adopt the following I-D as a
>>>>
Paul Wouters writes:
> On Mon, 12 Nov 2018, Ladislav Lhotka wrote:
>
>> we would like to ask the working group to adopt the following I-D as a
>> WG item:
>>
>> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-00
>
> I'll leave that c
On Mon, 2018-11-12 at 12:37 +0200, Joe Abley wrote:
> Hi Ladislav,
>
> On 12 Nov 2018, at 12:31, Ladislav Lhotka wrote:
>
> > we would like to ask the working group to adopt the following I-D as a
> > WG item:
> >
> > https://tools.ietf.org/html/draft-
ourse welcome.
Thanks,
Lada and Petr
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is is my question, too. The "description" and "reference" strings make sense
in the YANG module as human-readable documentation, and some user interfaces
also use them as context-sensitive help messages. In contrast, I don't see any
use for "template" and "reg
> > Your DNSOP chairs
> > > (Suzanne, Tim and Benno)
> > >
> > > ___
> > > DNSOP mailing list
> > > DNSOP at ietf.org
> > > https://www.ietf.org/mailman/listinfo/dnsop
> >
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
34 matches
Mail list logo
