From nobody Thu Dec 1 05:44:09 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBA61294B6; Thu, 1 Dec 2016 05:44:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148059984824.10475.8807326530789951127.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2016 05:44:08 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-agent-overload-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 13:44:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions of the IETF. Title : Diameter Agent Overload and the Peer Overload Report Author : Steve Donovan Filename : draft-ietf-dime-agent-overload-07.txt Pages : 17 Date : 2016-12-01 Abstract: This specification documents an extension to RFC 7683 (Diameter Overload Indication Conveyance (DOIC)) base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-agent-overload-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 1 05:45:54 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C751294B6 for ; Thu, 1 Dec 2016 05:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no 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 w4Pnq-eHjtB4 for ; Thu, 1 Dec 2016 05:45:51 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06861294A6 for ; Thu, 1 Dec 2016 05:45:50 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:50074 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cCRgB-002pZJ-SG for dime@ietf.org; Thu, 01 Dec 2016 05:45:50 -0800 To: dime@ietf.org References: <148059984824.10475.8807326530789951127.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <699f5053-97b6-43f6-c0d0-6b126235bcf8@usdonovans.com> Date: Thu, 1 Dec 2016 07:45:39 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <148059984824.10475.8807326530789951127.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------9B65D5BE3AF4E7142EDC00C9" X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] I-D Action: draft-ietf-dime-agent-overload-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 13:45:53 -0000 This is a multi-part message in MIME format. --------------9B65D5BE3AF4E7142EDC00C9 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit This new version contains some old review comments and recent changes based on a Working Group Chair review. I've attached the diff file for this new version. Regards, Steve On 12/1/16 7:44 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and Extensions of the IETF. > > Title : Diameter Agent Overload and the Peer Overload Report > Author : Steve Donovan > Filename : draft-ietf-dime-agent-overload-07.txt > Pages : 17 > Date : 2016-12-01 > > Abstract: > This specification documents an extension to RFC 7683 (Diameter > Overload Indication Conveyance (DOIC)) base solution. The extension > defines the Peer overload report type. The initial use case for the > Peer report is the handling of occurrences of overload of a Diameter > agent. > > Requirements > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dime-agent-overload-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------9B65D5BE3AF4E7142EDC00C9 Content-Type: text/html; charset=UTF-8; name="Diff_ draft-ietf-dime-agent-overload-06.txt - draft-ietf-dime-agent-overload-07.html" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-agent-overload-06.txt - draft-ietf-dim"; filename*1="e-agent-overload-07.html" Diff: draft-ietf-dime-agent-overload-06.txt - draft-ietf-dime-agent-overload-07.txt
< draft-ietf-dime-agent-overload-06.txt   draft-ietf-dime-agent-overload-07.txt >
Diameter Maintenance and Extensions (DIME) S. Donovan Diameter Maintenance and Extensions (DIME) S. Donovan
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track June 21, 2016 Updates: RFC7683 (if approved) December 1, 2016
Expires: December 23, 2016 Intended status: Standards Track
Expires: June 4, 2017
Diameter Agent Overload and the Peer Overload Report Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-06.txt draft-ietf-dime-agent-overload-07.txt
Abstract Abstract
This specification documents an extension to the Diameter Overload This specification documents an extension to RFC 7683 (Diameter
Indication Conveyance (DOIC) [RFC7683] base solution. The extension Overload Indication Conveyance (DOIC)) base solution. The extension
defines the Peer overload report type. The initial use case for the defines the Peer overload report type. The initial use case for the
Peer report is the handling of occurrences of overload of a Diameter Peer report is the handling of occurrences of overload of a Diameter
agent. agent.
Requirements Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 1, line 40 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 23, 2016. This Internet-Draft will expire on June 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 46 skipping to change at page 2, line 47
6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14 6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15
6.3. SourceID . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. SourceID . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 15 6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16 7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This specification documents an extension to the Diameter Overload This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) [RFC7683] base solution. The extension Indication Conveyance (DOIC) [RFC7683] base solution. The extension
defines the Peer overload report type. The initial use case for the defines the Peer overload report type. The initial use case for the
Peer report is the handling of occurrences of overload of a Diameter Peer report is the handling of occurrences of overload of a Diameter
agent. agent.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
In the case where both agents are reporting overload, the client may In the case where both agents are reporting overload, the client may
need to start decreasing the total traffic sent to the agents. This need to start decreasing the total traffic sent to the agents. This
would be done in a similar fashion as discussed in Section 3.1.1 The would be done in a similar fashion as discussed in Section 3.1.1 The
amount of traffic depends on the combined reduction requested by the amount of traffic depends on the combined reduction requested by the
two agents. two agents.
3.1.3. Agent Chains 3.1.3. Agent Chains
There are also deployment scenarios where there can be multiple There are also deployment scenarios where there can be multiple
Diameter Agents between Diameter Clients and Diameter Servers. An Diameter Agents between Diameter Clients and Diameter Servers. An
example of this type of deployment include when there are edge agents example of this type of deployment include when there are Diameter
between Diameter networks. agents between administrative domains.
Figure 5 illustrates one such network deployment case. Note that Figure 5 illustrates one such network deployment case. Note that
while this figure shows a maximum of two agents being involved in a while this figure shows a maximum of two agents being involved in a
Diameter transaction, it is possible that more than two agents could Diameter transaction, it is possible that more than two agents could
be in the path of a transaction. be in the path of a transaction.
+---+ +---+ +-+ +---+ +---+ +-+
--|a11|-----|a21|---|s| --|a11|-----|a21|---|s|
+-+ / +---+ \ / +---+\ /+-+ +-+ / +---+ \ / +---+\ /+-+
|c|- x x |c|- x x
skipping to change at page 8, line 46 skipping to change at page 8, line 46
5. Peer Report Behavior 5. Peer Report Behavior
This section defines the normative behavior associated with the Peer This section defines the normative behavior associated with the Peer
Report extension to the DOIC solution. Report extension to the DOIC solution.
5.1. Capability Announcement 5.1. Capability Announcement
5.1.1. Reacting Node Behavior 5.1.1. Reacting Node Behavior
When sending a Diameter request a DOIC node that supports the When sending a Diameter request a DOIC node that supports the
OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP
an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.
When sending a request a DOIC node that supports the OC_PEER_REPORT When sending a request a DOIC node that supports the OC_PEER_REPORT
feature MUST include a SourceID AVP in the OC-Supported-Features AVP feature MUST include a SourceID AVP in the OC-Supported-Features AVP
with its own DiameterIdentity. with its own DiameterIdentity.
Note: This allows the DOIC nodes in the path of the request to
determine if the indication of support came from a Diameter peer
or if the request traversed a node that does not support the
OC_PEER_REPORT feature.
When an agent relays a request that includes a SourceID AVP in the When an agent relays a request that includes a SourceID AVP in the
OC-Supported-Features AVP, a DOIC node that supports the OC-Supported-Features AVP, a DOIC node that supports the
OC_PEER_REPORT feature MUST remove the received SourceID AVP and OC_PEER_REPORT feature MUST remove the received SourceID AVP and
replace it with a SourceID AVP containing its own Diameter identity. replace it with a SourceID AVP containing its own Diameter identity.
5.1.2. Reporting Node Behavior 5.1.2. Reporting Node Behavior
When receiving a request a DOIC node that supports the OC_PEER_REPORT When receiving a request a DOIC node that supports the OC_PEER_REPORT
feature MUST update transaction state with an indication of whether feature MUST update transaction state with an indication of whether
or not the peer from which the request was received supports the or not the peer from which the request was received supports the
skipping to change at page 16, line 9 skipping to change at page 16, line 9
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|OC-Peer-Algo TBD1 x.x Unsigned64 | | V | |OC-Peer-Algo TBD1 x.x Unsigned64 | | V |
|SourceID TBD2 x.x DiameterIdentity | | V | |SourceID TBD2 x.x DiameterIdentity | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
7. IANA Considerations 7. IANA Considerations
7.1. AVP codes 7.1. AVP codes
New AVPs defined by this specification are listed in Section 6. All New AVPs defined by this specification are listed in Section 6.4.
AVP codes are allocated from the 'Authentication, Authorization, and All AVP codes are allocated from the 'Authentication, Authorization,
Accounting (AAA) Parameters' AVP Codes registry. and Accounting (AAA) Parameters' AVP Codes registry.
One new OC-Report-Type AVP value is defined in Section 6.2.1
7.2. New registries 7.2. New registries
There are no new IANA registries introduced by this document. There are no new IANA registries introduced by this document.
The values used for the OC-Peer-Algo AVP are the subset of the "OC- The values used for the OC-Peer-Algo AVP are the subset of the "OC-
Feature-Vector AVP Values (code 622)" registry. Only the values in Feature-Vector AVP Values (code 622)" registry. Only the values in
that registry that apply to overload abatement algorithms apply to that registry that apply to overload abatement algorithms apply to
the OC-Peer-Algo AVP. the OC-Peer-Algo AVP.
 End of changes. 9 change blocks. 
18 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--------------9B65D5BE3AF4E7142EDC00C9-- From nobody Thu Dec 1 06:09:18 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D3312952C; Thu, 1 Dec 2016 06:09:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148060135574.10467.4047971104211781417.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2016 06:09:15 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-load-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 14:09:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions of the IETF. Title : Diameter Load Information Conveyance Authors : Ben Campbell Steve Donovan Jean-Jacques Trottin Filename : draft-ietf-dime-load-04.txt Pages : 22 Date : 2016-12-01 Abstract: This document defines a mechanism for conveying of Diameter load information. RFC7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-load-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 1 06:10:46 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD261294E7 for ; Thu, 1 Dec 2016 06:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no 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 7IswYIMzEPgn for ; Thu, 1 Dec 2016 06:10:41 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C3C1294DA for ; Thu, 1 Dec 2016 06:10:41 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:50438 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cCS4H-003BOf-Ss for dime@ietf.org; Thu, 01 Dec 2016 06:10:41 -0800 To: dime@ietf.org References: <148060135574.10467.4047971104211781417.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <22fd1622-1d14-8e93-3fe7-9e55d52a9d63@usdonovans.com> Date: Thu, 1 Dec 2016 08:10:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <148060135574.10467.4047971104211781417.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------ADD4E3A185CA5AC5D200F0B6" X-OutGoing-Spam-Status: No, score=3.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] I-D Action: draft-ietf-dime-load-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 14:10:44 -0000 This is a multi-part message in MIME format. --------------ADD4E3A185CA5AC5D200F0B6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I've posted a new version of the load draft based on comments received in a Working Group Chair review. I've also attached a diff from the last version. Regards, Steve On 12/1/16 8:09 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and Extensions of the IETF. > > Title : Diameter Load Information Conveyance > Authors : Ben Campbell > Steve Donovan > Jean-Jacques Trottin > Filename : draft-ietf-dime-load-04.txt > Pages : 22 > Date : 2016-12-01 > > Abstract: > This document defines a mechanism for conveying of Diameter load > information. RFC7068 describes requirements for Overload Control in > Diameter. This includes a requirement to allow Diameter nodes to > send "load" information, even when the node is not overloaded. > RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution > describes a mechanism meeting most of the requirements, but does not > currently include the ability to send load information. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dime-load/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dime-load-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------ADD4E3A185CA5AC5D200F0B6 Content-Type: text/html; charset=UTF-8; name="Diff_ draft-ietf-dime-load-03.txt - draft-ietf-dime-load-04.html" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-load-03.txt - draft-ietf-dime-load-04."; filename*1="html" Diff: draft-ietf-dime-load-03.txt - draft-ietf-dime-load-04.txt
< draft-ietf-dime-load-03.txt   draft-ietf-dime-load-04.txt >
Internet Engineering Task Force B. Campbell Internet Engineering Task Force B. Campbell
Internet-Draft S. Donovan, Ed. Internet-Draft S. Donovan, Ed.
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: March 31, 2017 JJ. Trottin Expires: June 4, 2017 JJ. Trottin
Nokia Nokia
September 27, 2016 December 1, 2016
Diameter Load Information Conveyance Diameter Load Information Conveyance
draft-ietf-dime-load-03 draft-ietf-dime-load-04
Abstract Abstract
This document defines a mechanism for conveying of Diameter load This document defines a mechanism for conveying of Diameter load
information. [RFC7068] describes requirements for Overload Control information. RFC7068 describes requirements for Overload Control in
in Diameter. This includes a requirement to allow Diameter nodes to Diameter. This includes a requirement to allow Diameter nodes to
send "load" information, even when the node is not overloaded. The send "load" information, even when the node is not overloaded.
Diameter Overload Information Conveyance (DOIC) [RFC7683] solution RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution
describes a mechanism meeting most of the requirements, but does not describes a mechanism meeting most of the requirements, but does not
currently include the ability to send load information. currently include the ability to send load information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2017. This Internet-Draft will expire on June 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
3. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Differences between Load and Overload information . . . . 4 4.1. Differences between Load and Overload information . . . . 4
4.2. How is Load Information Used? . . . . . . . . . . . . . . 5 4.2. How is Load Information Used? . . . . . . . . . . . . . . 5
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 8 5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 8
6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10 6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10
6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10 6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10
6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10 6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10
6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11 6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11
6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 12 6.2. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12
6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13
6.4. Addition and removal of Nodes . . . . . . . . . . . . . . 13 6.4. Addition and removal of Nodes . . . . . . . . . . . . . . 13
7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 13 7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 13
7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 14 7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 14
7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 14 7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 14
7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 14 7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 46 skipping to change at page 3, line 46
requirements from RFC 7068. requirements from RFC 7068.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
DOIC DOIC
Diameter Overload Information Conveyance ([RFC7683]) Diameter Overload Information Conveyance ([RFC7683])
Load Load
The he relative usage of the Diameter message processing capacity The relative usage of the Diameter message processing capacity of
of a Diameter node. A low load level indicates that the Diameter a Diameter node. A low load level indicates that the Diameter
node is under utilized. A high load level indicates that the node node is under utilized. A high load level indicates that the node
is closer to being fully utilized. is closer to being fully utilized.
Offered Load Offered Load
The actual traffic sent to the reporting node after overload The actual traffic sent to the reporting node after overload
abatement and routing decisions are made. abatement and routing decisions are made.
Reporting, Reacting Node Reporting, Reacting Node
Reporting node and reacting node terminology is defined in Reporting node and reacting node terminology is defined in
skipping to change at page 12, line 11 skipping to change at page 12, line 11
requirement is an implementation decision. requirement is an implementation decision.
The frequency of sending load reports is an implementation decision. The frequency of sending load reports is an implementation decision.
Note: In the case of peer load reports it is only necessary to Note: In the case of peer load reports it is only necessary to
include load reports when the load value has changed by some include load reports when the load value has changed by some
meaningful value, as long as the agent insures that all peers meaningful value, as long as the agent insures that all peers
receive the report. It is also acceptable to include the load receive the report. It is also acceptable to include the load
report in every answer message handled by the Diameter agent. report in every answer message handled by the Diameter agent.
6.2. Receiving Node Behavior 6.2. Reacting Node Behavior
This section defines the behavior of Diameter nodes processing load This section defines the behavior of Diameter nodes processing load
reports. reports.
A Diameter node MUST be prepared to process load reports of type HOST A Diameter node MUST be prepared to process load reports of type HOST
and of type PEER, as indicated in the Load-Type AVP included in the and of type PEER, as indicated in the Load-Type AVP included in the
Load AVP received in the same answer message or from multiple answer Load AVP received in the same answer message or from multiple answer
messages. messages.
Note that the node needs to be able to handle messages with no Note that the node needs to be able to handle messages with no
skipping to change at page 16, line 31 skipping to change at page 16, line 31
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>. <http://www.rfc-editor.org/info/rfc6733>.
[RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control
Requirements", RFC 7068, DOI 10.17487/RFC7068, November Requirements", RFC 7068, DOI 10.17487/RFC7068, November
2013, <http://www.rfc-editor.org/info/rfc7068>. 2013, <http://www.rfc-editor.org/info/rfc7068>.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015,
<http://www.rfc-editor.org/info/rfc7683>.
10.2. Informative References 10.2. Informative References
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>. <http://www.rfc-editor.org/info/rfc2782>.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015,
<http://www.rfc-editor.org/info/rfc7683>.
Appendix A. Topology Scenarios Appendix A. Topology Scenarios
This section presents a number of Diameter topology scenarios, and This section presents a number of Diameter topology scenarios, and
discusses how load information might be used in each scenario. discusses how load information might be used in each scenario.
A.1. No Agent A.1. No Agent
Figure 6 shows a simple client-server scenario, where a client picks Figure 6 shows a simple client-server scenario, where a client picks
from a set of candidate servers available for a particular realm and from a set of candidate servers available for a particular realm and
application. The client selects the server for a given transaction application. The client selects the server for a given transaction
 End of changes. 10 change blocks. 
17 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--------------ADD4E3A185CA5AC5D200F0B6-- From nobody Fri Dec 2 12:26:49 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1034A124281; Fri, 2 Dec 2016 12:26:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148071040405.31793.9252948156874009032.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 12:26:44 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-agent-overload-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 20:26:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions of the IETF. Title : Diameter Agent Overload and the Peer Overload Report Author : Steve Donovan Filename : draft-ietf-dime-agent-overload-08.txt Pages : 17 Date : 2016-12-02 Abstract: This specification documents an extension to RFC 7683 (Diameter Overload Indication Conveyance (DOIC)) base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-agent-overload-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 2 12:29:08 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B30E31289B0; Fri, 2 Dec 2016 12:29:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148071054272.31869.9211039488566684844.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 12:29:02 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-load-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 20:29:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions of the IETF. Title : Diameter Load Information Conveyance Authors : Ben Campbell Steve Donovan Jean-Jacques Trottin Filename : draft-ietf-dime-load-05.txt Pages : 22 Date : 2016-12-02 Abstract: This document defines a mechanism for conveying of Diameter load information. RFC7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-load-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 6 14:13:29 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1588129CC4; Tue, 6 Dec 2016 14:13:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148106240465.1899.11231943919336313667.idtracker@ietfa.amsl.com> Date: Tue, 06 Dec 2016 14:13:24 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-load-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 22:13:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions of the IETF. Title : Diameter Load Information Conveyance Authors : Ben Campbell Steve Donovan Jean-Jacques Trottin Filename : draft-ietf-dime-load-06.txt Pages : 22 Date : 2016-12-06 Abstract: This document defines a mechanism for conveying of Diameter load information. RFC7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-load-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 6 14:24:27 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3886129B15 for ; Tue, 6 Dec 2016 14:24:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148106306566.1903.5384694912666950980.idtracker@ietfa.amsl.com> Date: Tue, 06 Dec 2016 14:24:25 -0800 From: IETF Secretariat Archived-At: Subject: [Dime] Milestones changed for dime WG X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 22:24:25 -0000 Changed milestone "Submit I-D 'Diameter Load Information' to the IESG for consideration as a Proposed Standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/dime/charter/ From nobody Tue Dec 6 14:25:48 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A31129CFC for ; Tue, 6 Dec 2016 14:25:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148106314241.1710.18016517951153604781.idtracker@ietfa.amsl.com> Date: Tue, 06 Dec 2016 14:25:42 -0800 From: IETF Secretariat Archived-At: Subject: [Dime] Milestones changed for dime WG X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 22:25:45 -0000 Changed milestone "Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC", resolved as "Done". URL: https://datatracker.ietf.org/wg/dime/charter/ From nobody Tue Dec 6 14:35:16 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4585C129BAB for ; Tue, 6 Dec 2016 14:35:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148106371428.1746.6119790462647623118.idtracker@ietfa.amsl.com> Date: Tue, 06 Dec 2016 14:35:14 -0800 From: IETF Secretariat Archived-At: Subject: [Dime] Milestones changed for dime WG X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 22:35:14 -0000 Changed milestone "Submit I-D 'Diameter Agent Overload' to the IESG for consideration as a Proposed Standard ", resolved as "Done". URL: https://datatracker.ietf.org/wg/dime/charter/ From nobody Mon Dec 12 08:58:27 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E653129D2B for ; Mon, 12 Dec 2016 08:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hQrdvm5VbLoY for ; Mon, 12 Dec 2016 08:58:20 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1B2129D09 for ; Mon, 12 Dec 2016 08:57:15 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 3so1501582pgd.0 for ; Mon, 12 Dec 2016 08:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=JAwXhOf1aQC4AlfhpYz5IyHnZaJ8af5CAowSiF4a/pI=; b=EiDjcb+vccL1SBwL6EbDiSE/KQN5wGMsOjneiLRCEF7R1yiTZdH5529xGa/rhmSkq2 MTyeaDvb25FYnzMz6+LrSNZbM6ZrWYX2C4/m5KPEeN3IfQaswGl7dWVsPUA9iQBOcJjv 3am1dMin25uYKWvgG8cP4NZ/bJWZtfjNeWVCOK5+pALQ00CUohXgX6jMFAnLoDKOsEu/ ZyPacdJPL1qnWv+FqWMZ8QKNtfBaQjfOpfJ4lbCN8n/QhsbcO9//9sLc9zFd9ynrIUtJ //l239vVeVeKYDRjPh+pGiAdPDW8OCuZBqBK02qdzS5XcehAXHdM0GA89R0IetIe+atN flOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=JAwXhOf1aQC4AlfhpYz5IyHnZaJ8af5CAowSiF4a/pI=; b=Jkk0yFbQcKDlHgLAzwerMSE1O2yxflECqEUa/8CCMvxqLxMduE6GBIQcoLyeoHRn9+ bd2EwDK/ISx5/q553Fj+7nhwNkaiJ5/BDmDNy/onUCKT9HTb46er7FU5esZq+g46IyPv b3WPyqbBTIa7HyAsXjZ5V8FUHL5yp1af3lTRf5iJ3bnsRCfTi3GWIRudPyW3mWXyMwLn Fess9fuIj/fRAhlD1xZFY/E54TlnRYS5U5qTgzVMwPOjBSi/ZAw9KYk7uc8paSHUg8ec VHcABAvsuZ0mmB/UM71rMD9j3de53xNr+fvbf/2fgC3+TISLWUcVhf/rvTukEDNTtKgG xrnw== X-Gm-Message-State: AKaTC02VV0bXk+CZnLgR8hL6MIoUQ+XuZF7GKpObHkmm9aQdIoET17CUj9J2o4SBpJunDA== X-Received: by 10.84.202.12 with SMTP id w12mr189219208pld.156.1481561834623; Mon, 12 Dec 2016 08:57:14 -0800 (PST) Received: from dhcpw5-sj1-5.sj.broadcom.com ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id 13sm77020889pfz.30.2016.12.12.08.57.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Dec 2016 08:57:13 -0800 (PST) From: "jouni.nospam" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Mon, 12 Dec 2016 08:57:12 -0800 To: dime@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [Dime] status of draft-ietf-dime-doic-rate-control-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 16:58:25 -0000 Folks, Out of the overload document family we got still one in the WG: = draft-ietf-dime-doic-rate-control. There was already one WGLC for it but = afair the number of reviews/responses was low. Note that = draft-ietf-dime-agent-overload has a normative reference to this one, so = if we intend to complete the set of remaining overload related documents = they all need to be processed in parallel.=20 I had a quick glance over the document and think it would deserve a = quick WGLC just to make sure there are no issues since the last tweaks = in the other related overload documents. I will send out another mail = starting a one week WGLC and ending just before the Christmas. Regards, Jouni From nobody Mon Dec 12 09:03:00 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECFE129CC9 for ; Mon, 12 Dec 2016 09:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qUnFSgONjuwP for ; Mon, 12 Dec 2016 09:02:57 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9AE12953E for ; Mon, 12 Dec 2016 09:02:57 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 3so1515302pgd.0 for ; Mon, 12 Dec 2016 09:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=WSA6GeJMdEMuO8CQx7QJBJrpdHjMwnWxSmzVf+BU47c=; b=G2Szf6yi1rIgy+UEXUA372ufTTTHvCjDC97bLaJC5tqU5Hes2R8ByPGsWBwdlNd0Bg z2IeNZOYsBrfbe/bOjkOUOG2D3z1wfcvxuOic/lEFIZNDkT+k9vxlzsolvjgB3jsWbb+ aWQvqqOlBXISHGl21VLjaXeu1AMBpR2QwWvc69L/90oH6Szyfbv3fl8PKoAiIWhCUh1X YdmYjnjfZIYN0xwc2JmH5E62KynOlrYZsWjFUKJ9ECPFcflcrHF4kJmSxnQ/vBYfC4sq YcZutiPNVJqZEQG/7Vv/sRnkzlZdEdmmeQlC+lDTJv2eqR1ulWiZvvN9ncn6kyPZ/zkw /r6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=WSA6GeJMdEMuO8CQx7QJBJrpdHjMwnWxSmzVf+BU47c=; b=eSEDFYQYjiRALUr6CLJ56HkEg3NdmlBuX0POi/G77Tw7n633FZ1dGS7kO8Q7hP4kMo oqpTdnZeb+ezUrvCAtOBBlYDMu+iudtXrPqqA7sOv9Vlzv3IT9MtC78OpoW3C1DfuiYX 6EBkTgrwwtz0is7lhaz6o2S/hX91fYE1aWA7ZG8LPw0I0cMsz0mL4VWf5gNhzmusFJ6f oJdqnQvrh64eXU0S3kPhACyG+NaY2m4Q/pdaP09tQegYeUdG3GrZsrmlhpUj0TDd9k2+ A3OeZiay+sVH0cro9r5Vfd6mf5ieSp5wpiBciE5NzFNXOs+cfc5dADXYg84mTjYPUUqz ANZg== X-Gm-Message-State: AKaTC03nU7U8Jy+QMc4UhRYcZVpROfoXRaYWl7XbfVqX7IF77TZD5nvvGW0MgrSHLhot9g== X-Received: by 10.98.149.140 with SMTP id c12mr98987774pfk.100.1481562176981; Mon, 12 Dec 2016 09:02:56 -0800 (PST) Received: from dhcpw5-sj1-5.sj.broadcom.com ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id y73sm76960591pfa.68.2016.12.12.09.02.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Dec 2016 09:02:56 -0800 (PST) From: "jouni.nospam" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Mon, 12 Dec 2016 09:02:54 -0800 To: dime@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [Dime] WGLC #2 for draft-ietf-dime-doic-rate-control-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 17:02:59 -0000 Folks, This mail starts the WGLC #2 for draft-ietf-dime-doic-rate-control-04. The WGLC ends next Monday 19/12/2016 EOB (PDT). Please, read & review the draft, provide your support or opposition = and/or comments to the list. Regards, Jouni= From nobody Tue Dec 13 12:12:29 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F38512968E for ; Tue, 13 Dec 2016 12:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.098 X-Spam-Level: X-Spam-Status: No, score=-107.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 x4N2yQ3LFzFJ for ; Tue, 13 Dec 2016 12:09:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092B1129574 for ; Tue, 13 Dec 2016 12:09:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E8146B80BF0; Tue, 13 Dec 2016 12:09:45 -0800 (PST) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161213200945.E8146B80BF0@rfc-editor.org> Date: Tue, 13 Dec 2016 12:09:45 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 13 Dec 2016 12:12:28 -0800 Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Technical Errata Reported] RFC6733 (4887) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 20:09:47 -0000 The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4887 -------------------------------------- Type: Technical Reported by: Mikhail Zaytsev Section: 6.2 Original Text ------------- When a request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command: o The same Hop-by-Hop Identifier in the request is used in the answer. o The local host's identity is encoded in the Origin-Host AVP. o The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message. Corrected Text -------------- When a request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command: o The same Hop-by-Hop Identifier in the request is used in the answer. o The local host's identity is encoded in the Origin-Host AVP. o The local realm's identity is encoded in the Origin-Realm AVP. o The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message. Notes ----- Unlike Origin-Host AVP, it is not stated explicitly that Origin-Realm AVP MUST be encoded in the associated answer. While both these AVPs MUST be present in all Diameter messages according to their descriptions. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Dec 16 09:38:36 2016 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2AE1293FD for ; Fri, 16 Dec 2016 09:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 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_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Zt0GcWyeH-0N for ; Fri, 16 Dec 2016 09:38:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAC51279EB for ; Fri, 16 Dec 2016 09:38:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DCECFBE4D for ; Fri, 16 Dec 2016 17:38:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrTO5ojHobbL for ; Fri, 16 Dec 2016 17:38:26 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2FFABBE3E for ; Fri, 16 Dec 2016 17:38:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1481909906; bh=+h454cyGXAwWlYHz7+cLEvikxgCeFvxJ7Wc1u23ouNA=; h=To:From:Subject:Date:From; b=IzVtHQmKW9B49+NRACv2BgXZYmht5qyR0/2Jbt+HvKTPSgl1dVMG2qNuPgo2LQIx9 kIdUcG8pZs7I+s5NOH4Qlb4EgI22Nz4zdHhVk40Frm4R2QTHTXnlhzz30QW8KLHqvk 1Ph1itkasHL96czuySHpC2QOVmgcz6shIyoJJnWs= To: "dime@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> Date: Fri, 16 Dec 2016 17:38:26 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090008090709030309070306" Archived-At: Subject: [Dime] AD evaluation of draft-ietf-dime-load-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 17:38:35 -0000 This is a cryptographically signed message in MIME format. --------------ms090008090709030309070306 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Thanks for getting this stuff progressed. I've done my AD evaluation and have a few questions I'd like to ask before starting IETF last call. Those are below along with some more nitty comments that can be handled now or later as the authors/WG prefer. Cheers, S. Things to chat about before starting IETF LC: --------------------------------------------- (1) Is "server selection" sufficiently clear? Where is that defined? I was a bit confused as to what this means that is not next-hop selection. (2) PEER reports that are first received at a non-supporting node will be left in place and will reach the destination of the message. If that destination is in a different domain then that leaks some internal structure (the SourceID) to outsiders. Is that desirable? Why not have the first node that does support this AVP delete the PEER report even if the node that added the PEER report is not a peer of this node? (Note: I see this risk is ack'd in section 8, I'm asking if we can avoid it almost entirely by removing PEER reports that are useless.) (3) This spec is a bit like RFC7944 (DRMP) in that it defines some but not all of the things one needs to end up with a workable system. That aspect of DRMP caused some discussion during IESG evaluation. Have the authors of this reviewed that discussion to see if we can avoid any likely iterations being needed at that point? I'm hoping that Steve, as an author of both, won't find this too hard to do:-) If that's been done, great. If not, please consider if there's any additional explanatory material that could be added that might help us not to have to iterate to discuss the same kinds of concern. nits (fine to be considered last call comments): ------------------------------------------------- abstract: maybe put the 1st sentence last? that might read better 4.1: the "opinion of the authors" isn't really of interest at this point - is this also the opinion of the WG? (I assume it is) section 5 says "The load report includes a value indicating the load of the sending node relative load of the sending node, specified in a manner consistent with that defined for DNS SRV [RFC2782]." I can't parse that. - 6.2: What is a Diameter "connection?" I thought that Diameter could use UDP as well as TCP so is that really the right term? Maybe "message sender" is a better way to identify the peer? - section 8: "might require a transitive trust model" is far too coy IMO. I think you should say that DOIC and this entirely require transitive trust because we have no Diameter mechanism that allows authenticated adding and removal of AVPs as messages transit a network. (We did try develop that ages ago but it was too complex, so I'm not arguing to try again, just that we clearly ack the fact that this stuff requires transitive trust.) --------------ms090008090709030309070306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMTYx NzM4MjZaMC8GCSqGSIb3DQEJBDEiBCAM+cIcvBnUwbU0DwWRDb5b6YwtxGqzJLF+J7WFY6Li KzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQByjYCt5i7PNR0X5am36nMRge00MH487XVjevq4N9rDcielbLOt4wi+ rK0xh8LDLVVB/zyPaT785lIP572JfOU1w9doqOBbPuGdsZCVDWhKd37buHdpQ2FZqzvE/B4S uw8x5HzJMO8ohxvgdKF6RxCVRrl+aVMxiIRKDTgA5U78aNyFqLWUMErQExwOoXm5Y7V77Mrf L2So3V9sFtpIfPg6hbOFWzDNDxC/nUU6mNAYP5JIjrC2zbFxX3lRSyspjggQC67MIe7hGuL2 MB9Wq407AJ8Z3ajXb/jUSkTmMXadEuImXjiP0iQlOhRKpv5dtnNMptsCBio6GlC9xEailKcM AAAAAAAA --------------ms090008090709030309070306--