Re: [yang-doctors] [Netconf] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-10

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 03 April 2018 19:33 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48812EA59; Tue, 3 Apr 2018 12:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 kFmEEu0v99P0; Tue, 3 Apr 2018 12:33:01 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2DEC12D948; Tue, 3 Apr 2018 12:33:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8164; q=dns/txt; s=iport; t=1522783981; x=1523993581; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RUSNZ4uWTkfRaMBEEBJ3h3MHhQ7s6YJqTxLyyOweqx8=; b=BIkPMUrB+zIpBPnN67B086x2cKFiT9g9YUQkrfc1kW0++MOMglGblIOn BX0sJAxNhPQK4cRoavJsjJVItDzwuoONLnsL6a56AG7vfuld0JMMi/LMb 8wauK4hRvvtTSIDoent8OTi4qXYL2zc1sOfb/n9MdQ993R7O5n9VOApez c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAACG1sNa/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMXK2FvKAqLVY0FgXSBD5JVgXoLH4RkAoRCITQYAQIBAQEBAQE?= =?us-ascii?q?CayiFIgEBAQEDOj0CEAIBCA4HAw0REDIlAgQOBQiFBa9uiESCIAWHYYFUP4EMg?= =?us-ascii?q?lYugxECgTwBAQiFSiAChz2ENYEdiiwIAo4liymBFo9WAhETAYEkARw4gVJwFYJ?= =?us-ascii?q?9gkhpAQIHjRJvjAeBH4EXAQE?=
X-IronPort-AV: E=Sophos;i="5.48,402,1517875200"; d="scan'208";a="158215056"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2018 19:33:00 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w33JX03n013160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2018 19:33:00 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 3 Apr 2018 15:32:56 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 3 Apr 2018 15:32:59 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "andy@yumaworks.com" <andy@yumaworks.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "draft-ietf-netconf-subscribed-notifications.all@ietf.org" <draft-ietf-netconf-subscribed-notifications.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-10
Thread-Index: AQHTvP9v9ARZDJYwE0mt60SgwmbJJaPbVUpwgAKqJYCAA7598IAAuKcAgAz+D1A=
Date: Tue, 3 Apr 2018 19:32:59 +0000
Message-ID: <eb62ab2757f0425d8fd634241a838367@XCH-RTP-013.cisco.com>
References: <f675d003813f4212975167c35ed751c6@XCH-RTP-013.cisco.com> <20180323.123631.1717671339304960054.mbj@tail-f.com> <e989a39a44ea4938b2eb9a5686cf8dbc@XCH-RTP-013.cisco.com> <20180326.094758.1920158070824114086.mbj@tail-f.com>
In-Reply-To: <20180326.094758.1920158070824114086.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/YbZ3PkDUxq0bUUT7ROoZULMytNw>
Subject: Re: [yang-doctors] [Netconf] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-10
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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, 03 Apr 2018 19:33:05 -0000

Hi Martin,

After reflecting on this for a bit, I am ok with your argument that if the system is quickly generating notification-messages, then the replay buffer might be continuously emptying.  And therefore a hint for replay start time might not be accurate for very long.   As a result, it is better to start the replay immediately with the oldest buffered event.

I have updated the establish-subscription RPC as follows.   Does this cover your concern (per this sub-thread)?

  rpc establish-subscription {
    input {     }
    output {
      leaf identifier {      }
      leaf replay-start-time {
        if-feature "replay";
        type yang:date-and-time;
          description
            "If a replay has been requested, this represents the 
            earliest time covered by the event buffer for the requested 
            stream.  The value of this object is the 
            'replay-log-aged-time' if it exists.  Otherwise it is the 
            'replay-log-creation-time'.  All buffered event records 
            after this time will be replayed to a receiver.  Note that 
            this object will only be sent if the 'replay-start-time' is 
            later than the time requested by the subscriber.";
      }
    }
  }

If you are ok, I will spread the change through the rest of the document.

Eric


> "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > From: Martin Bjorklund, March 23, 2018 7:37 AM
> > >
> > > Hi,
> > >
> > >
> > > "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > > Hi Martin,
> > > >
> > > > > From: Martin Bjorklund, March 16, 2018 4:19 AM
> > > > >
> > > > > Hi,
> > > > >
> > > > > Andy Bierman <andy@yumaworks.com> wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > 2.4.2.1.  Replay Subscription
> > > > > >
> > > > > >    If the "replay-start-
> > > > > >    time" contains a value that is earlier than content stored within
> > > > > >    the
> > > > > >    publisher's replay buffer, then the subscription MUST be
> rejected,
> > > > > >    and the leaf "replay-start-time-hint" MUST be set in the reply.
> > > > > >
> > > > > >    >> this is a significant and bad change from RFC 5277 behavior
> > > > > >    >> the start-time says "send all events that you have stored
> > > > > >       since this time" The server sends its oldest event and does
> > > > > >       not reject the request.  This draft incorrectly interprets
> > > > > >       the request as "the server MUST have an event stored at least
> > > > > >       this old"
> > > > >
> > > > > I agree, and I have pointed this out in earlier reviews.
> > > >
> > > > In our past discussions, it looked like you were ok after reading
> > > > Yves requirement here:
> > > >
> > > > https://www.ietf.org/mail-
> archive/web/netconf/current/msg12154.htm
> > > > l
> > > >
> > > > Beyond this functional requirement, the design pattern used is
> > > > that an establish-subscription RPC must send the exact parameters
> > > > accepted by the publisher.
> > > >
> > > >
> > > > > If a client sends a too early time, and the server doesn't send
> > > > > the optional hint, the client will have to guess the time.  Not
> > > > > very robust.
> > > > >
> > > > > If the motivation is that the client should be informed that he
> > > > > might have missed some notifs b/c the replay-start-time is too
> > > > > early, this information can be passed in the rpc-reply from
> > > > > establish-subscription instead.
> > > >
> > > > Yes this could be done.  But this doesn't follow the design
> > > > pattern of making the client explicitly ask for what they want.
> > > > Consistent design patterns do matter.
> > >
> > > Well, "what they want" depends on the semantics of this leaf!  If we
> > > keep the old semantics, then if the client passes this parameter
> > > with some start time, it "explicitly asked for what it wanted".
> > >
> > > Anyway, if the objective is to ensure that no notifs are sent unless
> > > the replay-start-time exactly matches the event-time of a
> > > notification in the buffer, then we can add a parameter to ensure
> > > that.
> >
> > The current definition of replay-start-time is:
> >
> > "Used to trigger the replay feature and indicate that the replay
> > should start at the time specified..."
> >
> > To me, that means the replay-start-time has to be covered by the scope
> > of the replay buffer.  It does not mean that it is required that the
> > requested replay-start-time needs to exactly match the time of a
> > buffered event.
> 
> The text is quite unclear:
> 
>   Used to trigger the replay feature and indicate that the
>   replay should start at the time specified.
> 
> and:
> 
>   If the "replay-start- time" contains a value that is earlier than
>   content stored within the publisher's replay buffer, then the
>   subscription MUST be rejected
> 
> In lack of a clear definition, I assume that "content stored [in] replay buffer"
> refers to event records, since I assume that nothing else can be stored in
> the replay buffer?
> 
> Next question is what it means that a time value is earlier than "content"?
> Again, my assumption is that it means "earlier than the 'eventTime' of the
> event records".  Is this not what is intended?
> 
> From what you write here though, I think that what you propose is
> that:
> 
>   If "replay-start-time" is less than the latest of
>   "replay-log-aged-time" and "replay-log-creation-time", then the
>   request is rejected.
> 
> This must be clarified.  Also, ensure that the required behavior is clearly
> defined in the YANG module, and not just in the text in the document.
> 
> But I still think that there should be some way for the client to get all
> buffered event records, just like what was supported in RFC 5277, without
> extra round trips.  Note that if the system is quickly generating notifs, the
> client might need many round trips before it manages to replay anything.
> 
> 
> > > In all cases, if the client receives a notif with a time later than
> > > what it asked for, it knows that it might have lost some notifs.
> >
> > Why would this mean it might have lost some notifs?  In the current
> > embodiment, the replay will not start unless the subscriber asked for
> > a time that is within the scope covered by the buffer.  I.e., a time
> > later than both "replay-log-creation-time" and "replay-log-aged-time".
> 
> See above.  But the reason for rejection is that the client might have lost
> some notifs.
> 
> > >   leaf replay-exact-start-time {
> > >     if-feature "replay";
> > >     when "../replay-start-time";
> > >     type empty;
> > >     description
> > >       "If this parameter is present, and the server does not have any
> > >        stored event record with 'eventTime' equal to the requested
> > >        'replay-start-time', then the server MUST reject the request.";
> > >   }
> 
> If we add something like this, the leaf name and description text needs to
> be tweaked for the clarified semantics of replay-start-time.
> 
> > Something like this parameter *might* be applicable if we choose to
> > respond to a dynamic replay request with events later than those
> > requested.  (i.e., in the establish-subscription success response.) As
> > noted in other threads, this is a legitimate way to approach the
> > issue.  However if the WG chooses this way, this will result in an
> > exception to the design pattern of requiring the subscriber to ask for
> > what they are going to receive.
> 
> I disagree.  The client explicitly asks the server to send all buffered event
> records.
> 
> > In addition, we might end up sending a stream of information to the
> > subscriber which is not sufficient, and therefore not verifiably
> > relevant.
> 
> It is up to the client to define what is relevant.  Maybe I just want to view
> the replay buffer for trouble shooting purposes.
> 
> 
> 
> /martin