Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Nov 2019 15:46:10 +0000

[moving yang-doctors to BCC]

Thank you Lada.

Authors, please update the draft as needed to address these YANG Doctor comments.

Kent // as Shepherd

> On Oct 29, 2019, at 3:10 AM, Ladislav Lhotka via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Ladislav Lhotka
> Review result: Ready with Nits
> 
> ***** Section 2. Introduction
>      - Paragraph 3: the use of MAY is inappropriate: publishers
>        indeed may have limitations, but this should follow from RFC
>        8641, and this document should take it as a fact.
> ***** Section 3. Notification Capability Model
>      - The use of RFC 2119 terms is again questionable: I understand
>        the ietf-notification-capabilities data as an optional aid for
>        the implementors, but requiring that "The file SHALL be
>        available in implementation time ..." is way too strict.
> ***** Section 3.2. YANG Module
>      - This is one of the cases where it would be helpful to know
>        which of the imported modules, such as ietf-netconf-acm, is
>        also intended to be implemented. This may be addressed in a
>        future YANG version (see issue #95 in yang-next), until then I
>        would suggest to include YANG library data describing a
>        minimum implementation.
> ***** Appendix A. Instance data examples
>      - Example in Fig. 2: the <datastore> element has an incorrect
>        XML namespace (of the ietf-datastores module).
>      - Many enum values are invalid because they contain
>        leading/trailing whitespace. It would be better to encode the
>        examples in JSON.
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 5 Nov 2019 14:38:27 +0000

Hello Lada,
Thanks for the comments. See answers below.
Regards Balazs

-----Original Message-----
From: Ladislav Lhotka via Datatracker <[email-masked]> 
Sent: 2019. október 29., kedd 8:10
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05

***** Section 2. Introduction
      - Paragraph 3: the use of MAY is inappropriate: publishers
        indeed may have limitations, but this should follow from RFC
        8641, and this document should take it as a fact.
BALAZS: OK
***** Section 3. Notification Capability Model
      - The use of RFC 2119 terms is again questionable: I understand
        the ietf-notification-capabilities data as an optional aid for
        the implementors, but requiring that "The file SHALL be
        available in implementation time ..." is way too strict.
BALAZS: OK, changed to SHOULD. Other reviewers wanted strong statements.
***** Section 3.2. YANG Module
      - This is one of the cases where it would be helpful to know
        which of the imported modules, such as ietf-netconf-acm, is
        also intended to be implemented. This may be addressed in a
        future YANG version (see issue #95 in yang-next), until then I
        would suggest to include YANG library data describing a
        minimum implementation.
BALAZS: OK. Yes, it would be useful information. I added it as a description substatement to import.  
***** Appendix A. Instance data examples
      - Example in Fig. 2: the <datastore> element has an incorrect
        XML namespace (of the ietf-datastores module).
BALAZS: I don't understand the comment; I don't see the error. Could you please advise me what you think should be there? Exactly where? 
      - Many enum values are invalid because they contain
        leading/trailing whitespace. It would be better to encode the
        examples in JSON.
BALAZS: I would like to keep the examples as they are.
In many previous RFCs lines in XML examples were broken into multiple lines. E.g. 
RFC7950 7.16.3
rfc8341 A.4
rfc8641 4.4.1
rfc6022 4.1
rfc8525 B
rfc8072 A.1.1
rfc6243  A.3.1
IMHO it is readable. It is better to use longer descriptive names in YANG, then to use short names just to avoid long lines in XML examples.

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 5 Nov 2019 15:14:46 +0000

Hello,

I have updated the draft, but missed the dead-line, so I can’t upload it.  I
will upload it when possible.  I attached it to this mail.

The changes are small, so I hope it is not a big problem.

I accepted + corrected all comments except 2 from Lada, which I do not fully
understand, as described in a reply to him.

Regards Balazs

P.S. very busy with Yangifying 3GPP  :-)

From: Kent Watsen <[email-masked]> 
Sent: 2019. november 1., péntek 16:46
To: Ladislav Lhotka <[email-masked]>;
[email-masked]
Cc: [email-masked]
Subject: Re: [netconf] Yangdoctors last call review of
draft-ietf-netconf-notification-capabilities-05

 

Thank you Lada.

Authors, please update the draft as needed to address these YANG Doctor
comments.

Kent // as Shepherd

On Oct 29, 2019, at 3:10 AM, Ladislav Lhotka via Datatracker
<[email-masked] <mailto:[email-masked]> > wrote:

_______________________________________________
netconf mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netconf

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 05 Nov 2019 17:43:43 +0100

On Tue, 2019-11-05 at 14:38 +0000, Balázs Lengyel wrote:

...
> BALAZS: I don't understand the comment; I don't see the error. Could you
> please advise me what you think should be there? Exactly where?

This element:

        <datastore xmlns="urn:ietf:params:xml:ns:yang:ietf-datastores">
          ds:operational
        </datastore>

The re-declaration of the default XML namespace is wrong and should be removed
(as in Fig. 1).
> IMHO it is readable. It is better to use longer descriptive names in YANG,
> then to use short names just to avoid long lines in XML examples.

The problem with this approach is that it may mislead casual readers into
thinking that the whitespace can be freely added to such values.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 17 Nov 2019 03:50:42 +0000

-----Original Message-----
From: Ladislav Lhotka <[email-masked]> 
Sent: 2019. november 6., szerda 0:44
To: Balázs Lengyel <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05
> BALAZS: I don't understand the comment; I don't see the error. Could 
> you please advise me what you think should be there? Exactly where?

This element:

The re-declaration of the default XML namespace is wrong and should be removed (as in Fig. 1).
BALAZS2: OK