Re: [i2rs] I-D Action: draft-ietf-i2rs-pub-sub-requirements-03.txt

Joe Clarke <jclarke@cisco.com> Tue, 06 October 2015 13:04 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86AC1A9240 for <i2rs@ietfa.amsl.com>; Tue, 6 Oct 2015 06:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, USER_IN_DEF_DKIM_WL=-7.5] 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 aTRLro9u2J3F for <i2rs@ietfa.amsl.com>; Tue, 6 Oct 2015 06:04:41 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7201A923B for <i2rs@ietf.org>; Tue, 6 Oct 2015 06:04:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2890; q=dns/txt; s=iport; t=1444136682; x=1445346282; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=T6We48BUL/umeWZdrPKVP9MJFroIFXil+57b+hYIDgU=; b=AgoxfqOnAUeJcjVEUFKQggqEpjYKso0hfVhYk5i0sh8nPREYMfkTz/D5 A842Z16qKm1fOJGIXJxEKdv8pwQVM+hsaneWzi5cgfsJE2KVfQlrxeOSU jN2D+/bzVZfs4c6dP3JRxAJG573ekqzlz7WquWpAOD+cVh0MqaSgzW9HU U=;
X-IronPort-AV: E=Sophos;i="5.17,644,1437436800"; d="scan'208";a="195063691"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2015 13:04:37 +0000
Received: from [10.150.6.135] ([10.150.6.135]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t96D4aj0027876; Tue, 6 Oct 2015 13:04:36 GMT
To: "Eric Voit (evoit)" <evoit@cisco.com>
References: <20151002190856.30194.1040.idtracker@ietfa.amsl.com> <5612AC63.4020000@cisco.com> <f8a6b4a291e54fa2a681d0db1af83a9d@XCH-ALN-013.cisco.com> <5612EB41.60902@cisco.com> <72b2ab0f1e1a449983aee81503564aec@XCH-ALN-013.cisco.com>
From: Joe Clarke <jclarke@cisco.com>
Organization: Cisco Systems, Inc.
Message-ID: <5613C6E3.9030401@cisco.com>
Date: Tue, 06 Oct 2015 09:04:35 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <72b2ab0f1e1a449983aee81503564aec@XCH-ALN-013.cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/DGbzYh5wU2C0Rm7hkRnHhNfA6hY>
Cc: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-pub-sub-requirements-03.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2015 13:04:42 -0000

On 10/5/15 18:16, Eric Voit (evoit) wrote:
>>> And as I read on, Section 4.2.3 describes what happens in the case of a "breach
>> of contract."  Perhaps that paragraph needs to folded in to the Negotiation
>> section:
>>>
>>> "When a Subscription Service is not able to send updates per its
>>>       subscription contract, the Subscription must notify subscribers and
>>>       put the subscription into a state of indicating the Subscription was
>>>       suspended by the service.  When able to resume service, subscribers
>>>       need to be notified as well.  If unable to resume service, the
>>>       Subscription Service may terminate the subscription and notify
>>>       Subscribers accordingly."
>>> <Eric> Yes, this is paragraph 3 of Section 4.2.3.   I think you are suggesting we
>> make more robust error/informational codes for a Suspended subscription,
>> including giving parameters which might work to un-suspend.   The Subscriber
>> could then attempt a "Modify Subscription" which would then have a chance to
>> bring things back to "Active".   The hard part is knowing when to send these
>> parameters when a suspension is very temporary due to short during overload
>> conditions.  This will be especially difficult as many subscriptions could be
>> suspended (and modifications synchronized) at the same time due to an
>> transient overload event.
>>
>> That would be ideal, but at its simplest, I am suggesting some of the wording in
>> section 4.2.3 make it into the Negotiation section to be clear what would
>> happen if negotiated attributes are no longer able to be maintained.
>
> There will be multiple ways that a Subscription Update could fail to get pushed.  Examples could be based on Bandwidth, CPU, or flow control reasons.  Or it could be that someone put a huge set of data under a subtree which wasn't there during the establishment of the original subscription.   I wouldn't want to prohibit the sending of parameters which might result in a successful reinstatement on the subscription.  But I wouldn't mandate it either.
>
> My suggestion is that there is the option to send suggested parameters.  But that we don't mandate this, nor which parameters may be sent.

Agreed.

>> So did I.  I didn't think it was clear given the word "fetch."  Perhaps you should
>> state that these data must be available via the subscription service.
>
> "It must be possible to fetch a list and status of all Subscription Requests made over a period of time to a Subscription Service.    If a Subscription failed to establish or has been suspended, reasons must be provided.  Example reasons might include:"

Sure, that sounds better, but my contention here was the make explicit 
that "fetch" meant to make these data available via the Subscription 
Service itself.  That is, define how one would fetch these data.

Joe