IETF Logo Mail Archive

Re: [lmap] Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 29 June 2015 16:49 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524BD1B2AB9; Mon, 29 Jun 2015 09:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 hXVMicJ4igaY; Mon, 29 Jun 2015 09:49:43 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934771B2AB5; Mon, 29 Jun 2015 09:49:29 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiIGAHvmdlXGmAcV/2dsb2JhbABcgmYqVF4GrF8BAQEBAQEGk26FeQKBSEwBAQEBAQGBAAuEIgEBAQEDEig0CwwEAgEIDQQBAwEBCxQFBAcyFAMGCAIEDgUIGogMAQyhPK5+AQEBAQEBAQECAQEBAQEBAQEBAQETBIYZhSqEVTEHBoMRgRYFkz6EQoJThUuDe4J1j0skYoEoHBWBPW+BRoEBAQEB
X-IronPort-AV: E=Sophos;i="5.13,581,1427774400"; d="scan'208";a="127056955"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Jun 2015 12:49:28 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 29 Jun 2015 12:49:27 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 29 Jun 2015 12:49:26 -0400
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC
Thread-Index: AQHQsnwZ8VMhG5B+QkSHejS8k3Acip3Dr38w
Date: Mon, 29 Jun 2015 16:49:26 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com>
References: <20150629145822.7722.8876.idtracker@ietfa.amsl.com>
In-Reply-To: <20150629145822.7722.8876.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.48]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/lmap/bwVmSZpU2ktiTPATb4KQ5oypGu4>
Cc: "netconf@ietf.org" <netconf@ietf.org>, "lmap@ietf.org" <lmap@ietf.org>
Subject: Re: [lmap] Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 29 Jun 2015 16:49:45 -0000

(I apologize for cross-posting) but it seems justified in this case) 

I find this work useful. 

I have two questions: 
- why was not this document adopted by the NETCONF WG? Lack of time, out of focus, or are there any other (technical?) reasons? Why did it had to go on AD-sponsored and Experimental track?
- This work may potentially be useful for LMAP which has scheduling and time-stamping features in its architecture and framework. LMAP however just selected RESTCONF as their preferred protocol. What would it take to extend this work to RESTCONF)? (may be another piece of work)

Thanks and Regards,

Dan


> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of
> The IESG
> Sent: Monday, June 29, 2015 5:58 PM
> To: IETF-Announce
> Subject: Last Call: <draft-mm-netconf-time-capability-05.txt> (Time
> Capability in NETCONF) to Experimental RFC
> 
> 
> The IESG has received a request from an individual submitter to consider the
> following document:
> - 'Time Capability in NETCONF'
>   <draft-mm-netconf-time-capability-05.txt> as Experimental RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document defines a capability-based extension to the Network
>    Configuration Protocol (NETCONF) that allows time-triggered
>    configuration and management operations. This extension allows
>    NETCONF clients to invoke configuration updates according to
>    scheduled times, and allows NETCONF servers to attach timestamps to
>    the data they send to NETCONF clients.
> 
> 
> The Network Configuration Protocol (NETCONF) Capability URNs registry
> requires a standards action in order to populate the registry. This document
> was taken out of the ISE stream and brought forward as an AD sponsored
> individual-submission to address this consideration.
> 
> 
> The file can be obtained via
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime-
> 2Dcapability_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNX
> CJfQzvlsiLQfucBXRucPvdrphpBsFA&m=eIbq6OXE65r_w9lwmd5WrktViMncM
> zhCDjk3tyjnVvU&s=B6e1FBSZH9H-
> OYAnRMYEgTJVYQ6SSqa2K9XpuIyx3mI&e=
> 
> IESG discussion can be tracked via
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime-
> 2Dcapability_ballot_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR3
> 1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=eIbq6OXE65r_w9lwmd5WrktVi
> MncMzhCDjk3tyjnVvU&s=WbISmWkVGVo43riTMHY7kzIkAREkQrB2aq-
> lyYOad-Y&e=
> 
> 
> No IPR declarations have been submitted directly on this I-D.
>

v2.23.0 | Report a Bug | By Email