Re: [lmap] Mirja Kühlewind's Discuss on draft-ietf-lmap-yang-11: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Tue, 21 March 2017 13:05 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8255012984B; Tue, 21 Mar 2017 06:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Mc8CEWX2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c5crFF/l
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be28tGK2qeMD; Tue, 21 Mar 2017 06:05:35 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF9A129445; Tue, 21 Mar 2017 06:05:35 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 482F120C55; Tue, 21 Mar 2017 09:05:32 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 21 Mar 2017 09:05:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=bQcf2ZM9hSYWVbaiu8 0RpwTq/Bfxq/lTFj8tJA/76+k=; b=Mc8CEWX2Nl8aNAjr8X/iEXmYeQL+IsYFoL yUAl+G+YuAve6jspey6fNAugKWxed8XjcKPkULd1CnaQG4fDx5ad+npEFD7Z+ZEl 6JuoreLG3JO6sMZ4FxWl2Z1KTplW5o8Ec27VIGck8VOa4CxdkLjCmMnp7wu6ZbIr bE8/sPzbKpecRxor/iIvRpytd3PF1dbepZ9ub93p6HQlbS6uaX2hn/BqIN/0KlVt uLjtK7sjBz2j9VoFoKLAOY+Lgp5oZbvYcDEr+zefZqyzjL9dWzIN4SNgklWV5tql 29J+WthBGLXwltFDFWeWnAfGpqp5BU2Pzl9TsgwPDK67IvSshoUQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=bQcf2ZM9hSYWVbaiu80RpwTq/Bfxq/lTFj8tJA/76+k=; b=c5crFF/l VWiqNNzFq7coysUutCDz7oJ2ioGHAkN+1NL+DiX22Q7UQsf3U+H0iVM1XT5/pqpz OoCr0suRaMGkCb66JdiWyB2S6Hk8b2HPmo9lunP8QKJ3O+yIPZVuPp9qWW/GlS8j YItyhwpLRGdUbXMOYUK4IiZUfBrNMQR+XMsNALxISk5p+Y7FTTL9mecGmPgdiIuQ xSioKxJEaK2sWKMUy5jIhIuI+Y9NNgRxVr/KmVZXbZxRETWvWw46vZIa28xDquks 2cEIQTWvsu4tj0gQUeIDT1Kr73fjgCPfvg4n04oOnPyxcBfUshcuN1bzq1AOl/qU 2ol3L880Xi7Law==
X-ME-Sender: <xms:HCXRWFHE354_WU0Md4C0zbJY-UtPmxFJCfloRoxcnzRG3UL_SwSi9Q>
X-Sasl-enc: 13MzOQvfv8WBCBiAn8MqNVOZdcBNTr7BN6Eln084Su7d 1490101531
Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.164]) by mail.messagingengine.com (Postfix) with ESMTPA id DEEA07E334; Tue, 21 Mar 2017 09:05:30 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <20170321115522.GA35872@elstar.local>
Date: Tue, 21 Mar 2017 09:05:29 -0400
Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Dan Romascanu <dromasca@gmail.com>, lmap-chairs@ietf.org, IESG <iesg@ietf.org>, draft-ietf-lmap-yang@ietf.org, lmap@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F07EFC4-0C8D-47CD-8DB9-4FD267DD3CC0@cooperw.in>
References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net> <20170321064636.GA34900@elstar.local> <FBFBCEE9-D3E9-47B9-99B1-10A9C9831937@kuehlewind.net> <20170321115522.GA35872@elstar.local>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/KOmBDvbseicWJXgka617M3dLJz8>
Subject: Re: [lmap] Mirja Kühlewind's Discuss on draft-ietf-lmap-yang-11: (with DISCUSS and COMMENT)
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 13:05:37 -0000

> On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> On Tue, Mar 21, 2017 at 09:11:09AM +0100, Mirja Kuehlewind (IETF) wrote:
>> Hi Jürgen,
>> 
>> thanks for you replies. I went back an had another look at the framework document which answered some of my questions. I guess the minimum you can do is to make the reference to RFC7594 normative (as well as the reference to I-D.ietf-lmap-information-model as Benoit mentioned in this comment). I guess without trying to implement it, I will not be able to figure out if there is anything missing or if I’m missing something and as such I will clear my discuss now.
> 
> To me, it feels a bit strange to make RFC 7594 normative

I agree, there is nothing specified in RFC 7594 that needs to be implemented in order for the YANG model to be implementable.

Alissa

> but if there
> is IESG consensus that RFC 7594 should be normative I will implement
> the change and hold my breath.
> 
>> I still think that it could be good to give some further guidance on how connectivity is established. Something like, in most cases the controller will connect the MA and the controller should make sure that it reconnects frequently based on the timeout configuration of the MA. If the MA e.g. is behind a NAT, the MA must establish the initial connection and try to reconnect when the timeout expires. Btw. is it enough to open a transport connection or do you mean by checking connectivity that there also should be some data transmitted to ensure that the controller is no only reachable but also active?
> 
> Depends to some extend on the protocol used. I think it is more than a
> TCP connection, you also need to successfully authenticate (I
> think). And then some protocols immediately become chatty - NETCONF
> has a <hello> exchange, with RESTCONF things could be silent but I
> would assume a controller will likely fetch some status information.
> (When you kid returns home, you likely ask how it is doing. ;-)
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>