Subject: [Lsr] Suresh Krishnan's No Objection on draft-ietf-ospf-yang-26: (with COMMENT)

From: Suresh Krishnan via Datatracker <[email-masked]>
Date: Thu, 22 Aug 2019 06:20:07 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-ospf-yang-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 2.7

Why are the neighbor configuration and operational state under different
subtrees here? I thought one of the goals of NMDA was to avoid this.

* Section 2.9

Is there a reason why the clear operation for neighbors is defined using an RPC
operation instead of simply an action under the relevant interface?

* Meta comment

NMDA is misspelt as NDMA in several places throughout the document including
the abstract and the introduction. Suggest a global search and replace.

Editorial
========

* Under ospfv2-lsa-option

s/Baes idenity/Base identity/

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 22 Aug 2019 19:53:23 +0000

Hi Suresh, 

On 8/22/19, 9:20 AM, "Lsr on behalf of Suresh Krishnan via Datatracker" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    * Section 2.7

I guess you mean the static-neighbors configuration. The reason is that the few parameters for static neighbors are only applicable to certain types of physical interfaces. You'll note that the operational state for neighbors is common to all interface types.
    
    * Section 2.9

It is interesting that we didn't get any comments suggesting to use "action" and now we've gotten two questions (including yours) in the last couple weeks. As defined, the RPCs are not specific to a single data node which is a requirement for "action" as they clear multiple neighbors and all the LSDBs. Also, they are functional as is defined. We could add more granular actions in the future. We've already started an augmentation for more recent protocol extensions. 

https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/

    * Meta comment

This will be in version -27. You can tell my fingers were accustomed to typing NBMA (Non-Broadcast Multi-Access) and NDMA was just too close. 
    
    Editorial
    ========

Fixed. 

Thanks,
Acee

    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lsr