Re: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-yang-26: (with COMMENT)

Mirja Kuehlewind <> Tue, 20 August 2019 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D408120987; Tue, 20 Aug 2019 08:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7nXqDltpLqGQ; Tue, 20 Aug 2019 08:51:57 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3209C12096D; Tue, 20 Aug 2019 08:51:57 -0700 (PDT)
Received: from ([2001:16b8:2c91:c600:bdef:7f40:a09b:d364]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1i06QL-0005sY-Nn; Tue, 20 Aug 2019 17:51:53 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Tue, 20 Aug 2019 17:51:53 +0200
Cc: The IESG <>, "" <>, Stephane Litkowski <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Acee Lindem (acee)" <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1i06QL-0005sY-Nn
Archived-At: <>
Subject: Re: [Lsr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ospf-yang-26=3A_=28with_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Aug 2019 15:51:59 -0000

Hi Acee,

Thanks for these changes/additions.

One comment below.

> On 20. Aug 2019, at 17:05, Acee Lindem (acee) <>; wrote:
> Hi Mirja, 
> On 8/19/19, 12:25 PM, "Mirja Kühlewind via Datatracker" <>; wrote:
>    Mirja Kühlewind 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
>    for more information about IESG DISCUSS and COMMENT positions.
>    The document, along with other ballot positions, can be found here:
>    ----------------------------------------------------------------------
>    ----------------------------------------------------------------------
>    Just two quick questions about references:
>    - Is there no reference for mtu-ignore (see section 2.4)? If not, can you
>    further describe what exactly would be disabled?
> I added "specified in section 10.6 of [RFC2328]." to the sentence. 
>    - Also is there no reference for OSPF Non-Stop Routing (NSR) (see section
>    2.4)...?
> While many vendors have implemented this feature, there is no standard as the goal is to restart without other OSPF routers being impacted. We did add the additional text to describe the feature and differences with OSPF Graceful Restart. 
>    And one more comment:
>    In the interface-common-config part (p76 and p77) you provide example or
>    default values for various intervals and delays. Where does those values come
>    from? Would it be possible to provide a reference/RFC that specifies actual
>    default values? Especially when you specify something normatively ("The value
>    MUST be greater than 'hello-interval'.") it would be good to provide a
>    reference!  Do any specification maybe also specify min and max value? If so,
>    you should mention them here as well! If not would it make sense to recommend
>    min and max values? If possible I would strongly support to describe min and
>    max values as well!
> The whole question of defaults generated quite a lot of discussion as there isn't really any one-size-fits all default and the sample values are very conservative. This is how we ended up with sample values in the text rather than YANG defaults. Since the protocol specification doesn’t specify min and max values, we were hesitant to specify them in the YANG model more than 20 years later. Also, many vendors have supported sub-second hellos. This wasn't a good idea and it has been supplanted by BFD. I will add RFC 2328 Appendix C as a reference for the sample values. 

Good to hear that this was discussed! I understand the problem and a YANG is not the right place to “change” the spec. Adding a reference would be good!

One more question regarding the sentence with normative language above: Is that already specified in some other spec and it would make sense to not use normative language here but provide the reference? 


> Thanks,
> Acee