On 14/05/2021 17:59, Mahesh Jethanandani wrote:
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.
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
Cheers.
On May 14, 2021, at 9:34 AM, tom petch <daedulus@xxxxxxxxxxxxx> wrote:
On 14/05/2021 17:17, Mahesh Jethanandani wrote:
Hi Tom,
Can you point to something specific? Thanks.
action reset
...[RFC ZZZZ]
...
leaf value
[RFC2104]...[RFC4868]... [RFC8697]... [RFC7693]
...
leaf value
[RFC7468]
Tom Petch
On May 14, 2021, at 3:20 AM, tom petch <daedulus@xxxxxxxxxxxxx>
wrote:
On 12/05/2021 21:46, Mahesh Jethanandani wrote:
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
On Apr 12, 2021, at 1:38 AM, tom petch
<daedulus@xxxxxxxxxxxxx> 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:
Mahesh Jethanandani mjethanandani@xxxxxxxxx
Mahesh Jethanandani
mjethanandani@xxxxxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
