Subject: Re: [babel] Last Call: <draft-ietf-babel-yang-model-09.txt> (YANG Data Model for Babel) to Proposed Standard

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 12 May 2021 13:46:58 -0700

This has been addressed in -10 version of the draft. Cheers.

> On Apr 12, 2021, at 1:38 AM, tom petch <[email-masked]> wrote:
> 
> This I-D introduces a new and unnecessary YANG prefix in defiance of BCP216 s.4.2.
> 
> It imports ietf-yang-types, perhaps the most widely imported module in the world, and RFC6991, where that module is specified, defines the proper prefix as 'yang'.  This I-D invents a different one. Technically, YANG can cope with this but that does not make it a sensible thing to do.
> 
> Tom Petch
> 
> On 08/04/2021 13:43, The IESG wrote:
>> 
>> The IESG has received a request from the Babel routing protocol WG (babel) to
>> consider the following document: - 'YANG Data Model for Babel'
>>   <draft-ietf-babel-yang-model-09.txt> as Proposed Standard
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits final
>> comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2021-04-22. Exceptionally, comments may
>> be sent to [email-masked] instead. In either case, please retain the beginning
>> of the Subject line to allow automated sorting.
>> 
>> Abstract
>> 
>> 
>>    This document defines a data model for the Babel routing protocol.
>>    The data model is defined using the YANG data modeling language.
>> 
>> 
>> 
>> 
>> 
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/
>> 
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> IETF-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> .
>> 

Mahesh Jethanandani
[email-masked]

---

From: tom petch <[email-masked]>
Date: Fri, 14 May 2021 11:20:03 +0100

> This has been addressed in -10 version of the draft. Cheers.

Indeed it has.

I note that some YANG clauses have [references] in them which are likely 
not plain text; doubtless that will be fixed at some point in the process.

Tom Petch

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 14 May 2021 09:17:00 -0700

Hi Tom,

Can you point to something specific? Thanks.

> On May 14, 2021, at 3:20 AM, tom petch <[email-masked]> wrote:
> 
> I note that some YANG clauses have [references] in them which are likely not plain text; doubtless that will be fixed at some point in the process.
> 
> Tom Petch
>> 

Mahesh Jethanandani
[email-masked]

---

From: tom petch <[email-masked]>
Date: Fri, 14 May 2021 17:34:43 +0100

> Can you point to something specific? Thanks.

action reset
...[RFC ZZZZ]
...
leaf value
[RFC2104]...[RFC4868]... [RFC8697]...  [RFC7693]
...
leaf value
[RFC7468]

Tom Petch

>> I note that some YANG clauses have [references] in them which are
>> likely not plain text; doubtless that will be fixed at some point
>> in the process.
>>
>> Tom Petch
>>>
>>>> It imports ietf-yang-types, perhaps the most widely imported
>>>> module in the world, and RFC6991, where that module is
>>>> specified, defines the proper prefix as 'yang'.  This I-D
>>>> invents a different one. Technically, YANG can cope with this
>>>> but that does not make it a sensible thing to do.
>>>>
>>>> Tom Petch
>>>>
>>>>> The IESG has received a request from the Babel routing
>>>>> protocol WG (babel) to consider the following document: -
>>>>> 'YANG Data Model for Babel'
>>>>> The IESG plans to make a decision in the next few weeks, and
>>>>> solicits final comments on this action. Please send
>>>>> substantive comments to the [email-masked] mailing lists
>>>>> by 2021-04-22. Exceptionally, comments may be sent to
>>>>> [email-masked] instead. In either case, please retain the
>>>>> beginning of the Subject line to allow automated sorting.
>>>>>
>>>>> Abstract
>>>>>
>>>>>
>>>>> This document defines a data model for the Babel routing
>>>>> protocol. The data model is defined using the YANG data
>>>>> modeling language.
>>>>>
>>>>>
>>>>>
>
> Mahesh Jethanandani [email-masked]
>
>
>
>
>
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 14 May 2021 09:59:11 -0700

Hi Tom,

Are you suggesting that there should be no references to RFC numbers in the description statement? Note, the reference statement that follows the description statement has the complete reference to the RFC which is being cited in the description statement.

Cheers.

> On May 14, 2021, at 9:34 AM, tom petch <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: tom petch <[email-masked]>
Date: Sat, 15 May 2021 12:06:27 +0100

> Are you suggesting that there should be no references to RFC numbers in the description statement? Note, the reference statement that follows the description statement has the complete reference to…

I am saying that [RFC ZZZZ] and such like are usually xML and not plain 
text and that a YANG module is required to be plain text as when it is 
extracted from the RFC and floats off on is own independent of the rest 
of the RFC.  The 'canonical form' of a YANG module is plain text!

Tom Petch

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 16 May 2021 21:27:40 -0700

Hi Tom,

> On May 15, 2021, at 4:06 AM, tom petch <[email-masked]> wrote:
> 
> I am saying that [RFC ZZZZ] and such like are usually xML and not plain text and that a YANG module is required to be plain text as when it is extracted from the RFC and floats off on is own independent of the rest of the RFC.  The 'canonical form' of a YANG module is plain text!

Where in RFC 7950 or RFC 8407 does it say that?

Mahesh Jethanandani
[email-masked]

---

From: tom petch <[email-masked]>
Date: Fri, 21 May 2021 09:10:25 +0100

> Where in RFC 7950 or RFC 8407 does it say that?

It ia implicit in RFC8407 as a careful reading may show.

Tom Petch