[yang-doctors] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05

Ladislav Lhotka via Datatracker <noreply@ietf.org> Tue, 29 October 2019 07:10 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: yang-doctors@ietf.org
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FB71200CE; Tue, 29 Oct 2019 00:10:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ladislav Lhotka via Datatracker <noreply@ietf.org>
To: <yang-doctors@ietf.org>
Cc: last-call@ietf.org, netconf@ietf.org, draft-ietf-netconf-notification-capabilities.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.108.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <157233302184.6593.3869700028694968875@ietfa.amsl.com>
Date: Tue, 29 Oct 2019 00:10:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/iKJsu7uz_Hc_WYm1yLmbwzsVJlw>
Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 07:10:22 -0000

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.