From glenzorn@gmail.com Mon Oct 1 00:54:01 2012 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 93D3021F85B6; Mon, 1 Oct 2012 00:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-1.485, BAYES_50=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6qyso7fQqXN; Mon, 1 Oct 2012 00:53:59 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6B3221F84BF; Mon, 1 Oct 2012 00:53:58 -0700 (PDT) Received: by padfb11 with SMTP id fb11so4045064pad.31 for ; Mon, 01 Oct 2012 00:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yF39Jf4qikHc9Lh8Kh0tIYwfGn02xF7sDf2uuLWhmsM=; b=xkjhU7LpuhhAxTPAzywrf4Bg4L2S7NUN3nbQk4nO81rXGekiyM2wo7T5VhOUCXNHRi Gpux81zuOMDGglQ35ZTznuC9/Ozlxa4Tg+chXrgqIbIjzcEFo4i28oaZTmx1ULvS2Aqx St7R/kD2+EQpNh6gkgsFf3ZhbXzp2akSxHUtmMBGdtOO9Z0OD+QTKqr5W9hnNwveGZTi RcxAXNk6FXJPwolAi8jPPNQgjgqXJ8afCZAf1a6no2isJxGD9Ol4sg86JLPzlN68+jHQ eSUP6SROn1g5TW358xp8Nk0qNU0acq56aisrRf0NdVGEmns24HIaw4C9YAF6ioA8PwFj ZO+Q== Received: by 10.68.197.104 with SMTP id it8mr39458789pbc.167.1349078038366; Mon, 01 Oct 2012 00:53:58 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-120-13-13.revip2.asianet.co.th. [124.120.13.13]) by mx.google.com with ESMTPS id bn1sm10000680pab.8.2012.10.01.00.53.54 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 00:53:57 -0700 (PDT) Message-ID: <50694C10.4050508@gmail.com> Date: Mon, 01 Oct 2012 14:53:52 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dave Crocker References: <50161436.8080900@bbiw.net> In-Reply-To: <50161436.8080900@bbiw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime mailing list , draft-ietf-dime-rfc4005bis.all@tools.ietf.org, apps-discuss@ietf.org, iesg Subject: Re: [Dime] Review of: draft-ietf-dime-rfc4005bis-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 07:54:01 -0000 On 07/30/2012 11:57 AM, Dave Crocker wrote: > G'day. > > > I have been selected as the Applications Area Directorate reviewer > for this draft (for background on appsdir, please see > > > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call > comments you may receive. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > > Document: draft-ietf-dime-rfc4005bis-09 Title: Diameter > Network Access Server Application Reviewer: Dave Crocker Review > Date: 18 June 2012 > > > Summary: > > This draft continues problems from the original, at a minimum lacking > definitions of terms, citation or definition of notational > conventions, apparent normative redundancy with base documents. > > > Major Issues: > > Active vs. passive voice -- the documents use of passive voice > greatly expands the verbiage but also sometimes make it difficult to > discern which participating entity is the identified actor. > > Apparently redundant normative text -- this document appears to > contain restatements of normative text from the base Diameter > document. This is extremely poor practice, since it invites > divergence. > > Possibly inconsistent use of terminology -- Some of the terms used > appear to have equivalent meaning but are not defines; to the extent > that they are meant to have different meaning I could not tell what > that was. > > Most significantly, it appears that this document cannot readily be > read without very deep familiarity with other Diameter documentation, > making this nearly an appendix to those. At the least, the > dependencies should be made explicit and detailed. The > Introduction's opening paragraph might have been thought to take care > of this requirement, but it doesn't, at least not for me. For one > thing, it isn't phrase so as to accomplish this. For another, the > references are to entire documents, implying -- but not saying -- > don't read this until you are deeply familiar with all of these other > documents. > > The broader comments appear to apply to the original documents as > well as this (and related) current ones. It's likely that making > changes accordingly would be a major effort. Whether that's worth > the effort isn't something I can judge. I think the revisions would > make for tighter, clearer specifications that are probably easier to > maintain, but I can't offer an opinion about the benefit this would > have in terms of existing implementers or better market adoption, > since I'm not familiar with Diameter's degree of market penetration > nor the skills of those who have (or might) adopt it. > > > > Minor Issues: -- > > > Nits: -- > > > Detailed comments: > > >> Network Working Group G. >> Zorn, Ed. Internet-Draft Network Zen Obsoletes: 4005 (if approved) >> May 18, 2012 Intended status: Standards Track Expires: November >> 19, 2012 >> >> >> Diameter Network Access Server Application >> draft-ietf-dime-rfc4005bis-09 >> >> Abstract >> >> This document describes the Diameter protocol application used for > > When summarizing the nature or purpose of a document, it is best for > the abstract and Introduction to use different words than are in the > title. Simply repeating the language of the title does not explain > the title. The simple rule should be to assume that the new reader > does not automatically understand the meaning of the title. > > In this case, I also have no idea what "the Diameter protocol > application" means here. RFC 3588. > "protocol application" is not typical > phrasing. Does it really mean that details are being specified for > software implementation of Diameter at the server? No. > > Typically, the IETF does not specify details about software > implementation, nevermind put such a specification on the standards > track. (And, yes, I see that this is a -bis document; but that does > not change the underlying concern.) > > What is the motivation for this version of the document? What > problems or improvements are being provided? That is, why was it > worth the effort to revise the previous document? These are not > explained in the bis document. Section 1.1 > > >> Authentication, Authorization, and Accounting (AAA) services in >> the Network Access Server (NAS) environment; it obsoletes RFC 4005. >> When combined with the Diameter Base protocol, Transport Profile, >> and Extensible Authentication Protocol specifications, this >> application specification satisfies typical network access services >> requirements. > > ... >> 1. Introduction >> >> This document describes the Diameter protocol application used for >> AAA in the Network Access Server (NAS) environment. When combined >> with the Diameter Base protocol [I-D.ietf-dime-rfc3588bis], >> Transport Profile [RFC3539], and EAP [RFC4072] specifications, >> this specification satisfies the NAS-related requirements defined >> in Aboba, et al. [RFC2989] and Beadles & Mitton [RFC3169]. > > This assertion raises a dilemma: The cited documents are extensive > and the topic(s?) complex. There is no way to know what details are > being referred to, to evaluate the assertion. If there were only specific details that were relevant, only specific sections of the document would be cited. To evaluate the assertion read the cited documents. All of them. To understand this document, read and understand the normative references. All of them. > Worse, fixing this > deficiency is certain to be a large effort. > > >> First, this document describes the operation of a Diameter NAS >> application. > > What is "a Diameter NAS application"? It does not seem to be > explained in this document, nor is there a citation to its > definition. > > >> Then it defines the Diameter message Command-Codes. The following >> sections list the AVPs used in these messages, grouped > > AVPs? > > Define acronyms when they are introduced. Explain their meaning. If > the acronym is not destined for regular use within the document, > consider replacing the acronym with the full term. > > If this document is a case of "this document only makes sense when > you are intimately familiar with these other documents", then specify > those other documents. As the document stands now, it does not > formally citte foundational documents, although it does seem to rely > on some. My understanding, as expressed above, is that in order for a reader to expect to understand an RFC, they must first have read and understood the normative references. Is that incorrect? > > In general, this document's frequent use of "AVP" appears to be an > oddly syntactic focus. Typical specifications refer to attributes, > without such frequent, explicit reference to the form of their having > values. On its own, this point could seem like quibbling, but it's > part of the reaction I had when reading the document, that is seemed > less accessible than one would wish for a new reader. This document is not intended to function as a primer on Diameter, AAA, or network access systems. As I mentioned above, the "new" reader is fully expected to have read and thoroughly understand all of the normative references. That reader would have found that Section 1.1 of RFC 3588 (referencing that document since RFC3588bis is still something of a moving target) says: All data delivered by the protocol is in the form of an AVP. Some of these AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter. The centrality of AVPs to the operation of the Diameter protocol might explain the focus of this draft upon them. > > >> by common usage. These are session identification, >> authentication, authorization, tunneling, and accounting. The >> authorization AVPs are further broken down by service type. > > This document appears to require deep knowledge of The Diameter Base > Protocol. In reality, I don't think this document can be > meaningfully read without that knowledge. So this document should > say that. (The language in the first paragraph of the Intro doesn't > actually say it.) One more time: read the normative references. Understand them. All of them. I realize that this is a rather tall order for a review, but the target audience for this draft is not people who are less than intimately familiar with the Diameter base protocol, as well as RADIUS ans network access systems in general. > > >> 1.1. Changes from RFC 4005 >> >> This document obsoletes RFC 4005 and is not backward compatible >> with that document. An overview of some the major changes are >> given below. > > "not backward compatible" automatically raises basic questions about > transition from old to new and support during an extended > transition. The word 'transition' does not appear in this document. > > >> o All of the material regarding RADIUS/Diameter protocol >> interactions has been removed. >> >> o The Command Code Format (CCF) [I-D.ietf-dime-rfc3588bis] for >> the > > presumably the references to I-Ds need to be changed for RFC > publication? Presumably the RFC Editor will take care of that; this draft is part of a rather large cluster that is waiting on the publication of RFC 3588 bis. > > >> Accounting-Request and Accounting-Answer messages has been changed >> to explicitly require the inclusion of the Acct-Application-Id AVP >> and exclude the Vendor-Specific-Application-Id AVP. Normally, this >> type of change would also require the allocation of a new command >> code and consequently, a new application-id (See Section 1.3.3 of >> [I-D.ietf-dime-rfc3588bis]). However, the presence of an instance >> of the Acct-Application-Id AVP was required in RFC 4005, as well: >> >> The ACR message [BASE] is sent by the NAS to report its session >> information to a target server downstream. >> >> Either of Acct-Application-Id or Vendor-Specific-Application-Id >> AVPs MUST be present. If the Vendor-Specific-Application-Id >> grouped AVP is present, it must have an Acct-Application-Id >> inside. >> >> Thus, though the syntax of the commands has changed, the semantics >> have not (with the caveat that the Acct-Application-Id AVP can no >> longer be contained in the Vendor-Specific-Application-Id AVP). > > Sounds oddly disruptive. /Why/ has the syntax been changed? What > problem is this solving? > >> >> >> >> >> Zorn Expires November 19, 2012 [Page 5] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> o The lists of RADIUS attribute values have been deleted in favor >> of references to the appropriate IANA registries. >> >> o The accounting model to be used is now specified. >> >> There are many other many miscellaneous fixes that have been >> introduced in this document that may not be considered significant >> but they are useful nonetheless. Examples are fixes to example IP > > Useful, but not significant. Interesting concept. Perhaps what is > meant is not major or not substantive or not normative? > > >> addresses, addition of clarifying references, etc. All of the >> errata previously filed against RFC 4005 have been fixed. A >> comprehensive list of changes is not shown here for practical >> reasons. >> >> 1.2. Terminology >> >> Section 1.2 of the base Diameter specification >> [I-D.ietf-dime-rfc3588bis] defines most of the terminology used in >> this document. Additionally, the following terms and acronyms are >> used in this application: >> >> NAS (Network Access Server) A device that provides an access >> service for a user to a network. The service may be a network >> connection or a value-added service such as terminal emulation >> [RFC2881]. > > Do not define a term by re-using the words in the term. In this > case, even a word as obvious as 'access' could mean a variety of > things. > > Everything is "a network connection". Perhaps the distinction here > is between host-level attachment service, versus user-level > application service? I can't tell. > > > ... >> VPN (Virtual Private Network) In this document, this term is used >> to describe access services that use tunneling methods. > > Since VPN is a well-entrenched, standard term of art, it seems odd -- > and likely counterproductive -- to imply that use in this document > will be non-standard, especially since the definition provided seems > on a par with usual definitions, such as wikipedia's. Fine. > > > >> 1.4. Advertising Application Support >> >> Diameter nodes conforming to this specification MUST advertise >> support by including the value of one (1) in the >> Auth-Application-Id of the Capabilities-Exchange-Request (CER) >> message. > > "this specification' -> this version of specification [???] > > There is no other reference to the CER message in this document. As > such, it's not clear what context for the message is meant. Offhand, > it appears that advertising support of the spec is made during a > session that implements the spec? This seems at least odd. > > Since this version of the spec uses a different syntax, it's not > likely that any implementation will be speaking a different version > of the protocol. > > >> 1.5. Application Identification >> >> When used in this application, the Auth-Application-Id AVP MUST be >> set to the value one (1) in the following messages >> >> o AA-Request (Section 3.1) >> >> >> >> >> >> Zorn Expires November 19, 2012 [Page 7] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> o Re-Auth-Request(Section 3.3) >> >> o Session-Termination-Request (Section 3.5) >> >> o Abort-Session-Request (Section 3.7) >> >> 1.6. Accounting Model >> >> It is RECOMMENDED that the coupled accounting model (Section 9.3 >> of [I-D.ietf-dime-rfc3588bis]) be used with this application; >> therefore, the value of the Acct-Application-Id AVP in the >> Accounting-Request (Section 3.10) and Accounting-Answer (Section >> 3.9) messages SHOULD be set to one (1). > > All of the values in those two sections (except the "271") are > symbolic. As such, setting a value to "1" has no obvious meaning. > > I assume that the issue would be fixed by using symbolic values > here? Or by reading RFC 3588. > > >> 2. NAS Calls, Ports, and Sessions >> >> The arrival of a new call or service connection at a port of a > > "a port"? is this a reference to a transport-level port? That's the > only use of the word in the base diameter document. > > What is a 'call' and what does it mean for it to "arrive", in this > context? How is it different from a service connection? > > The word 'call' in the base document does not have a usage that seems > relevant here. > > Is this document really trying to specify how a host dispatches a > server? If so, that means it's discussing implementation details > rather than protocol details. > > >> Network Access Server (NAS) starts a Diameter NAS message >> exchange. > > I would guess that the Diameter-level initiation of a NAS message > exchange is caused by a Diameter-level message, not the transport > connection it triggers. If so, what message would that be? > > >> Information about the call, the identity of the user, and the >> user's > > The base Diameter document does not specify the concept of a 'call'. > > >> authentication information are packaged into a Diameter AA-Request >> (AAR) message and sent to a server. >> >> The server processes the information and responds with a Diameter >> AA- > > "processes the information"? What does this mean, in protocol > interoperability terms? I'd expect some statement about the > semantics of the processes, relative to the overall exchange. > > >> Answer (AAA) message that contains authorization information for >> the NAS, or a failure code (Result-Code AVP). A value of >> DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication >> exchange, and several AAR and AAA messages may be exchanged until >> the transaction completes. > > "may"? > > This paragraph appears to be largely redundant with the base Diameter > document. Redundancy like this invites divergence over time and > ambiguity about which text is controlling. > > >> Depending on the value of the Auth-Request-Type AVP, the Diameter > > The reader is supposed to guess what values produce what results or > actions? I don't see the choices/mappings/whatever documented. > > > >> 3.1. AA-Request (AAR) Command >> >> The AA-Request (AAR), which is indicated by setting the >> Command-Code field to 265 and the 'R' bit in the Command Flags >> field, is used to request authentication and/or authorization for a >> given NAS user. > > The text provides detail about the internals of the AAR, but doesn't > say who sends it. > > By the way, does the AA- mean Authentication/Authorization? That's > implied but not stated. Since the labels are symbolic, mnemonic > utility is improved by explaining the basis of the string. > > >> The type of request is identified through the Auth-Request-Type >> AVP [I-D.ietf-dime-rfc3588bis] The recommended value for most >> situations is AUTHORIZE_AUTHENTICATE. >> >> If Authentication is requested, the User-Name attribute SHOULD be >> present, as well as any additional authentication AVPs that would >> carry the password information. A request for authorization >> SHOULD only include the information from which the authorization >> will be performed, such as the User-Name, Called-Station-Id, or >> Calling- > > This implies that some other sorts of information SHOULD NOT be > included, but gives no indication what it is (or why). > > >> Station-Id AVPs. All requests SHOULD contain AVPs uniquely >> identifying the source of the call, such as Origin-Host and >> NAS-Port. > > This is a classic and frequent bit of guidance, but lacks any > technical substance. The "such as" gives a concrete example, but > otherwise the implementer has no idea what will satisfy the SHOULD. > > >> Certain networks MAY use different AVPs for authorization >> purposes. A request for authorization will include some AVPs >> defined in Section 4.4. > > Which ones? How is the implementer to know? > > >> It is possible for a single session to be authorized first and >> then for an authentication request to follow. > > What is the implementer to do with this statement? > > >> This AA-Request message MAY be the result of a multi-round >> authentication exchange, which occurs when the AA-Answer message >> is received with the Result-Code AVP set to >> DIAMETER_MULTI_ROUND_AUTH. A subsequent AAR message SHOULD be sent, >> with the User-Password AVP that includes the user's response to the >> prompt, and MUST include any State AVPs that were present in the >> AAA message. >> >> Message Format > > What meta-syntax is being used for specifying formats? It isn't ABNF > and it isn't cited. > > > >> 3.2. AA-Answer (AAA) Command >> >> The AA-Answer (AAA) message is indicated by setting the >> Command-Code field to 265 and clearing the 'R' bit in the Command >> Flags field. It > > Is it really helpful to have each of these say how to set the > command, given that it's already listed in a table? Having prose > that merely repeats details, rather than explaining them, expands the > size of the document but, I believe, actually makes the substance > less accessible. > > Worse, isn't that already done in the base Diameter document? > > And by the way, the base document defines a command as a > request/answer pair. As such neither one, on its own, is a command. > That is, this one appears to be the a "command answer", rather than > a command. (And yes, that's painfully redundant, given the symbolic > name.) > > I notice that the text often uses the word 'message' to refer to one > of these transaction components of a command. That looks like a > simple and reasonable choice. Hence, AA-Answer (AAA) Message? This > assumes that "command" means a request/response pair. > > >> is sent in response to the AA-Request (AAR) message. If >> authorization was requested, a successful response will include >> the authorization AVPs appropriate for the service being provided, >> as defined in Section 4.4. > > The "if" seems odd, since the preceding sentence declares the > necessary (and obvious) predicate. > > >> >> For authentication exchanges requiring more than a single round >> trip, the server MUST set the Result-Code AVP to >> DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY >> include one Reply-Message or >> >> >> >> Zorn Expires November 19, 2012 [Page 12] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> more and MAY include zero or one State AVPs. >> >> If the Reply-Message AVP was present, the network access server >> SHOULD send the text to the user's client to display to the user, > > "was present" suffers the problem of passive sentence form in a > protocol specification -- and using past tense adds to the challenge: > it isn't clear who does what. Offhand, I would think that it is, in > fact, the server that generates replies (and presumably, therefore, > chooses to include Reply-Message text.) However the above sentence > implies otherwise. > > Since Diameter is a protocol specification, what does it mean for a > server to send text to the user's client? What is the protocol > mechanism for doing this? > > >> instructing the client to prompt the user for a response. For >> example, this capability can be achieved in PPP via PAP. If the >> access client is unable to prompt the user for a new response, it >> MUST treat the AA-Answer (AAA) with the Reply-Message AVP as an >> error and deny access. > > The 'it' means the client? The client must deny access? > > >> 3.3. Re-Auth-Request (RAR) Command >> >> A Diameter server may initiate a re-authentication and/or re- > > may? > > >> authorization service for a particular session by issuing a >> Re-Auth- Request (RAR) message [I-D.ietf-dime-rfc3588bis]. > > Re-authorization "service"? I don't understand what the word means > here and didn't find any obvious guidance in the base Diameter > document. > > The additional uses of the word in the next paragraph added to my > confusion. > > >> For example, for pre-paid services, the Diameter server that >> originally authorized a session may need some confirmation that >> the user is still using the services. > > I have no idea what this is about, what it's basis is or what it > means. It seems to presume that the reader knows exactly what is > being referred to, as 'pre-paid services' and why it would need some > (additional) confirmation. > > >> If a NAS receives an RAR message with Session-Id equal to a >> currently active session and a Re-Auth-Type that includes >> authentication, it MUST initiate a re-authentication toward the >> user, if the service supports this particular feature. > > and if it doesn't, then what? > > > >> 3.4. Re-Auth-Answer (RAA) Command >> >> The Re-Auth-Answer (RAA) message [I-D.ietf-dime-rfc3588bis] is >> sent in response to the RAR. The Result-Code AVP MUST be present >> and indicates the disposition of the request. >> >> A successful RAA transaction MUST be followed by an AAR message. > > transaction -> command { ? } > > >> 3.5. Session-Termination-Request (STR) Command >> >> The Session-Termination-Request (STR) message >> [I-D.ietf-dime-rfc3588bis] is sent by the NAS to inform the >> Diameter Server that an authenticated and/or authorized session is >> being terminated. > > "is being". Again, this is passive voice for a 'command'. > Consequently it is not clear whether the requestor has done the > termination or is requesting that the server terminate. I assume the > latter, but the text leaves this open. > > >> 3.6. Session-Termination-Answer (STA) Command >> >> The Session-Termination-Answer (STA) message >> [I-D.ietf-dime-rfc3588bis] is sent by the Diameter Server to >> acknowledge the notification that the session has been terminated. >> The Result-Code AVP MUST be present and MAY contain an indication >> that an error occurred while the STR was being serviced. >> >> Upon sending or receiving the STA, the Diameter Server MUST >> release all resources for the session indicated by the Session-Id >> AVP. Any intermediate server in the Proxy-Chain MAY also release >> any resources, if necessary. > > The server can /receive/ an STA? That appears to be at odds with the > first paragraph. > > >> 3.7. Abort-Session-Request (ASR) Command >> >> The Abort-Session-Request (ASR) message [I-D.ietf-dime-rfc3588bis] >> may be sent by any server to the NAS providing session service, to >> request that the session identified by the Session-Id be stopped. > > "by any server" suggests a multi-server model, with a NAS talking to > more than one at a time (for a given session...?) As I understand > it, NAS/Server sessions are bilateral, not multi-lateral. In > addition, the "providing session service" implies that a NAS could be > relevant to this text when it is /not/ providing session service. > This seems unlikely. > > So the language here probably should be: > > MAY be sent by the server to the NAS to request that... > > > >> 3.8. Abort-Session-Answer (ASA) Command >> >> The ASA message [I-D.ietf-dime-rfc3588bis] is sent in response to >> the ASR. The Result-Code AVP MUST be present and indicates the >> disposition of the request. > > Who sends to whom? > > >> 3.9. Accounting-Request (ACR) Command >> >> The ACR message [I-D.ietf-dime-rfc3588bis] is sent by the NAS to >> report its session information to a target server downstream. > > 'downstream'? Is it relayed through intermediaries? What does > 'downstream' mean here, beyond simply having a client/server > dialogue? > > >> The Acct-Application-Id AVP MUST be present. >> >> The AVPs listed in the Base protocol specification >> [I-D.ietf-dime-rfc3588bis] MUST be assumed to be present, as > > What does "assumed to be present" mean? What is the point behind > "assuming" and does this just mean supported by client and server > software? Required to be used in the protocol exchanges? Something > else? > > > >> 3.10. Accounting-Answer (ACA) Command >> >> The ACA message [I-D.ietf-dime-rfc3588bis] is used to acknowledge >> an > > is used to acknowledge -> acknowledges > > >> Accounting-Request command. The Accounting-Answer command >> contains the same Session-Id as the Request. The same level of >> security MUST be applied to both the Accounting-Request and the >> corresponding > > Is this security requirement special to this command or is it > univeral? Why? > > >> Accounting-Answer message. For example, if the ACR was protected >> using end-to-end security techniques then the corresponding ACA >> message MUST be protected in the same way; note, however, that the >> definition of such techniques is outside the scope of this >> document. >> >> Only the target Diameter Server or home Diameter Server SHOULD >> respond with the Accounting-Answer command. > > target vs. home. What distinguishes which is to respond? How are > they to know? > > > >> 4. Diameter NAS Application AVPs >> >> The following sections define a new derived AVP data format, a set >> of > > "new" will not mean much 10 years from now. RFCs should be written > for long-term reading. > > "derived"? What does this mean? > > >> application-specific AVPs and describe the use of AVPs defined in >> other documents by the Diameter NAS Application. >> >> 4.1. Derived AVP Data Formats >> >> 4.1.1. QoSFilterRule > > What is the /purpose/ of this? Presumably it has something to do > with filtering, but there's no context for it established. > > >> The QosFilterRule format is derived from the OctetString AVP Base >> Format. It uses the ASCII charset. Packets may be marked or >> metered based on the following information: >> > > marked vs. metered ? > > >> >> >> Zorn Expires November 19, 2012 [Page 23] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> o Direction (in or out) >> >> o Source and destination IP address (possibly masked) >> >> o Protocol >> >> o Source and destination port (lists or ranges) >> >> o DSCP values (no mask or range) > > DSCP? > > >> Rules for the appropriate direction are evaluated in order; the >> first > > "Rules for the appropriate direction"? What does this mean? > > >> matched rule terminates the evaluation. Each packet is evaluated >> once. If no rule matches, the packet is treated as best effort. >> An access device unable to interpret or apply a QoS rule SHOULD >> NOT terminate the session. > > This appears to be discussing a /set/ of rules, but there's been no > discussion of a set. This appears to presume a model that hasn't > been introduced. > > >> >> QoSFilterRule filters MUST follow the following format: > > There is more than one filter? Does this mean multiple sets or > multiple rules within a single set? > > >> action dir proto from src to dst [options] > > Where are the /semantics/ of these defined? > > >> where >> >> action tag Mark packet with a specific DSCP [RFC2474] meter >> Meter traffic >> >> dir The format is as described under IPFilterRule >> [I-D.ietf-dime-rfc3588bis] >> >> proto The format is as described under IPFilterRule >> [I-D.ietf-dime-rfc3588bis] >> >> src and dst The format is as described under IPFilterRule >> [I-D.ietf-dime-rfc3588bis] >> >> The options are described in Section 4.4.9. > > I didn't see them there. > >> >> The rule syntax is a modified subset of ipfw(8) from FreeBSD, and >> the ipfw.c code may provide a useful base for implementations. > > "may be provided"??? I thought this was a protocol specification > which defines its details or cites them formally. > > >> 4.2. NAS Session AVPs >> >> Diameter reserves the AVP Codes 0 - 255 for RADIUS Attributes that >> are implemented in Diameter. >> >> 4.2.1. Call and Session Information >> >> This section describes the AVPs specific to Diameter applications >> that are needed to identify the call and session context and >> status >> >> >> >> Zorn Expires November 19, 2012 [Page 24] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> information. On a request, this information allows the server to >> qualify the session. > > "on a request"? > > >> These AVPs are used in addition to the following AVPs from the >> base protocol specification [I-D.ietf-dime-rfc3588bis]: >> >> Session-Id Auth-Application-Id Origin-Host Origin-Realm >> Auth-Request-Type Termination-Cause >> >> The following table gives the possible flag values for the session >> level AVPs. > > "session-level"? > > >> +----------+ | AVP Flag | | rules | |----+-----+ |MUST| MUST| >> Attribute Name Section Defined | | NOT| >> -----------------------------------------|----+-----| NAS-Port >> 4.2.2 | M | V | NAS-Port-Id 4.2.3 | M | >> V | NAS-Port-Type 4.2.4 | M | V | >> Called-Station-Id 4.2.5 | M | V | >> Calling-Station-Id 4.2.6 | M | V | Connect-Info >> 4.2.7 | M | V | Originating-Line-Info 4.2.8 | M >> | V | Reply-Message 4.2.9 | M | V | >> -----------------------------------------|----+-----| >> >> 4.2.2. NAS-Port AVP >> >> The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains >> the physical or virtual port number of the NAS which is >> authenticating the user. Note that "port" is meant in its sense as >> a service connection on the NAS, not as an IP protocol identifier. > > "service connection on the NAS"? > > "virtual" port number? This is the only time the term is used, and I > don't see it in the base Diameter document and I don't know what it > means. > > >> Either the NAS-Port AVP or the NAS-Port-Id AVP (Section 4.2.3) >> SHOULD be present in the AA-Request (AAR, Section 3.1) command if >> the NAS differentiates among its ports. >> >> 4.2.3. NAS-Port-Id AVP >> >> The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and >> consists of ASCII text identifying the port of the NAS >> authenticating the >> >> >> >> Zorn Expires November 19, 2012 [Page 25] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> user. Note that "port" is meant in its sense as a service >> connection on the NAS, not as an IP protocol identifier. > > Although this doesn't distinguish physical from virtual, it does > explain the term port. I suspect such explanations should be broken > out into an earlier section that provides some framework and > terminology. This will avoid having definitions buried deeply and > possibly after first use. This can be especially helpful for > sections, like this one, that seem likely to be used for reference, > and therefore not read sequentially. > > >> >> Either the NAS-Port-Id AVP or the NAS-Port AVP (Section 4.2.2) >> SHOULD be present in the AA-Request (AAR, Section 3.1) command if >> the NAS differentiates among its ports. NAS-Port-Id is intended >> for use by NASes that cannot conveniently number their ports. >> >> 4.2.4. NAS-Port-Type AVP >> >> The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and > > "Enumerated"? Where are the types defined? > > >> 4.2.9. Reply-Message AVP >> >> The Reply-Message AVP (AVP Code 18) is of type UTF8String and >> contains text that MAY be displayed to the user. When used in an >> AA- > > Since I doubt that this specification is intended to cover user > interface design -- and hope that it is not -- I think that the > normative, semantic point in specification terms is that the strings > MUST be created with the intent of displaying them to humans. That > is, these are human-consumable strings, not (necessarily) > computer-consumable. > > > >> 4.4.1. Service-Type AVP >> >> The Service-Type AVP (AVP Code 6) is of type Enumerated and >> contains the type of service the user has requested or the type of >> service to be provided. One such AVP MAY be present in an >> authentication and/or authorization request or response. A NAS is >> not required to implement all of these service types. It MUST >> treat unknown or unsupported Service-Types received in a response >> as a failure and end the session with a DIAMETER_INVALID_AVP_VALUE >> Result-Code. >> >> When used in a request, the Service-Type AVP SHOULD be considered >> a hint to the server that the NAS believes the user would prefer >> the kind of service indicated. The server is not required to honor >> the > > A hint is a hint. It would be odd and probably wrong for an > implementer to be "required to honor the hint". If they are > required, it's not a hint. > > I believe the simpler and more useful phrasing would simply be: > > When used in a request, the Service-Type AVP is only a hint to the > server that the NAS believes... > > And then delete the sentence after. > >> hint. Furthermore, if the service specified by the server is >> supported, but not compatible with the current mode of access, the >> NAS MUST fail to start the session. The NAS MUST also generate the >> appropriate error message(s). > > Doesn't "MUST fail to start" equate to "MUST NOT start" and wouldn't > that be the simpler and more typical phrasing? > > "appropriate"? What are the criteria and how is the implementer to > know? > > > >> 4.4.10.5.4. Framed-Pool AVP >> >> The Framed-Pool AVP (AVP Code 88) is of type OctetString and >> contains the name of an assigned address pool that SHOULD be used >> to assign an address for the user. If a NAS does not support >> multiple address pools, the NAS SHOULD ignore this AVP. Address >> pools are usually used for IP addresses but can be used for other >> protocols if the NAS supports pools for those protocols. > > Hmmm. If the NAS does not support multiple address pools and doesn't > ignore this AVP, what happens and how will it be interoperable? > > This seems like something that requires an exact, shared model > between the two sides, or else it's merely a notational convenience > without interoperability substance. That is, either it's a MAY or a > MUST? Or there needs to be some explanation of how to deal with the > mismatch between the two sides. > > > > // > > d/ From dieter.jacobsohn@telekom.de Mon Oct 1 01:12:57 2012 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 63AEF21F8608 for ; Mon, 1 Oct 2012 01:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=1.414, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeL9Z3aY2ZRw for ; Mon, 1 Oct 2012 01:12:56 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3851B21F8595 for ; Mon, 1 Oct 2012 01:12:55 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 01 Oct 2012 10:12:52 +0200 Received: from HE113456.emea1.cds.t-internal.com ([169.254.3.121]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 1 Oct 2012 10:12:52 +0200 From: To: , Date: Mon, 1 Oct 2012 10:12:51 +0200 Thread-Topic: RE : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis Thread-Index: Ac2fEj5qIUyjgkHeRN2PlIhMMiVTugAmbTqA Message-ID: <1836CE1BA4F81F46921CA0334F7E4274583123B37A@HE113456.emea1.cds.t-internal.com> References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5066EA99.3020801@gmail.com> <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> <50684D98.8010400@cs.tcd.ie> In-Reply-To: <50684D98.8010400@cs.tcd.ie> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, Stefan.Schroeder06@telekom.de, dime@ietf.org, turners@ieca.com Subject: Re: [Dime] RE : Re: AW: unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 08:12:57 -0000 Hello all if I understood Lionel correctly he proposes and I would clearly support th= at "you MUST NOT send messages with "e2e-sensitive" AVPs without e2e security= " Best regards Dieter=20 -----Urspr=FCngliche Nachricht----- Von: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Gesendet: Sonntag, 30. September 2012 15:48 An: lionel.morand@orange.com Cc: Glen Zorn; Jacobsohn, Dieter; dime@ietf.org; draft-ietf-dime-rfc3588bis= @tools.ietf.org; turners@ieca.com; Schr=F6der, Stefan Betreff: Re: RE : Re: AW: [Dime] unexpected consequence of deprecating E2E = security in RFC 3588 bis Just checking I've got this right. The plan now is to say you MUST NOT send= "e2e-sensitive" AVPs without e2e security and to have a list of currently = known e2e-sensitive AVPs in 3588bis. If so, that seems like a good thing to= me. Maybe consider an IANA registry listing the e2e-sensitive AVPs that could b= e updated via expert review for when the current list gets outdated? Could = be done later if needed though, so just a suggestion. S. On 09/30/2012 12:15 PM, lionel.morand@orange.com wrote: > Hi Glen, >=20 > After the list of avps, we should say: >=20 > "Diameter messages containing these AVPs and any other AVP considered as = security-sensitive MUST only be sent..." >=20 > Regards, >=20 > Lionel > -----Message d'origine----- > De : Glen Zorn > Envoy=E9 : 29/09/2012, 14:33 > =C0 : MORAND Lionel RD-CORE > CC : Glen Zorn; dieter.jacobsohn@telekom.de; dime@ietf.org;=20 > draft-ietf-dime-rfc3588bis@tools.ietf.org; turners@ieca.com;=20 > stephen.farrell@cs.tcd.ie; Stefan.Schroeder06@telekom.de Objet : Re:=20 > AW: [Dime] unexpected consequence of deprecating E2E security in RFC=20 > 3588 bis >=20 > On 09/29/2012 05:39 PM, lionel.morand@orange.com wrote: >=20 >> It is actually needed if we don't want to lose info. These AVPs > > should be listed in a table in these sections with an indication=20 > that > is a list of AVPs that can be considered as=20 > security-sensitive, in > order to not start a discussion on which AVP=20 > is really sensitive and > which not. Anyway, designers will have to=20 > decide what they want to do > and this list is mainly for information. > > > OK, this is what I've got now: >=20 > 13.3. AVP Considerations >=20 > Diameter AVPs often contain security-sensitive data; for example, > user passwords and location data, network addresses and cryptographic > keys. The following AVPs defined in this document are considered to > be security-sensitive: >=20 > o Acct-Interim-Interval >=20 > o Accounting-Realtime-Required >=20 > o Acct-Multi-Session-Id >=20 > o Accounting-Record-Number >=20 > o Accounting-Record-Type >=20 > o Accounting-Session-Id >=20 > o Accounting-Sub-Session-Id >=20 > o Class >=20 > o Session-Id >=20 > o Session-Binding >=20 > o Session-Server-Failover >=20 > o User-Name >=20 > Diameter messages containing these AVPs MUST only be sent protected > via mutually authenticated TLS or IPsec. In addition, those messages > MUST NOT be sent via intermediate nodes unless there is end-to-end > security between the originator and recipient or the originator has > locally trusted configuration that indicates that end-to-end security > is not needed. For example, end-to-end security may not be required > in the case where an intermediary node is known to be operated as > part of the same administrative domain as the endpoints so that an > ability to successfully compromise the intermediary would imply a > high probability of being able to compromise the endpoints as well. > Note that no end-to-end security mechanism is specified in this > document. >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 From dieter.jacobsohn@telekom.de Tue Oct 2 03:40:31 2012 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 6062621F8B15 for ; Tue, 2 Oct 2012 03:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6avhBSvef8g4 for ; Tue, 2 Oct 2012 03:40:30 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 40B2E21F8B1E for ; Tue, 2 Oct 2012 03:40:30 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 02 Oct 2012 12:40:27 +0200 Received: from HE113456.emea1.cds.t-internal.com ([169.254.3.121]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 2 Oct 2012 12:40:27 +0200 From: To: , Date: Tue, 2 Oct 2012 12:40:27 +0200 Thread-Topic: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis Thread-Index: Ac2fEj5qIUyjgkHeRN2PlIhMMiVTugBd9bOA Message-ID: <1836CE1BA4F81F46921CA0334F7E4274583132FE03@HE113456.emea1.cds.t-internal.com> References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5066EA99.3020801@gmail.com> <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> <50684D98.8010400@cs.tcd.ie> In-Reply-To: <50684D98.8010400@cs.tcd.ie> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, Stefan.Schroeder06@telekom.de, dime@ietf.org, turners@ieca.com Subject: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2012 10:40:31 -0000 Hello all a question for me is also what exactly do we mean by: > "MUST NOT be sent via intermediate nodes unless there is end-to-end=20 > security between the originator and recipient " Which kind of e2e security? There is no such thing in Diameter right now, o= r did I miss something? We can only do e2e security by hop-by-hop security (IPsec or TLS), if there= is NO intermediate (Diameter) node. So, either we have e2e security, then there is no intermediate node - or we= have intermediate nodes, then there can't be e2e security.=20 Best regards Dieter Jacobsohn Deutsche Telekom AG Group Technology Dieter Jacobsohn Landgrabenweg 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801 46624 (Fax) +49 171 2088 710 (Mobil) E-Mail: dieter.jacobsohn@telekom.de www.telekom.com =20 Erleben, was verbindet. =20 Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Manfred Balz, Reinhard Clemens, Niek Jan van Damme, Timotheus H=F6ttges, Claudia Nemat, Prof. Dr. Marion Schick Handelsregister: Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft Bonn USt-IdNr. DE 123475223 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken.=20 From eric.mcmurry@tekelec.com Tue Oct 2 11:47:42 2012 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 1800821F8585 for ; Tue, 2 Oct 2012 11:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUe6LtNQ3s9s for ; Tue, 2 Oct 2012 11:47:41 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id 68E0221F8574 for ; Tue, 2 Oct 2012 11:47:41 -0700 (PDT) Received: from ericlaptop.casamcmurry.com (cpe-76-184-161-215.tx.res.rr.com [76.184.161.215]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q92IlWPb008014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Oct 2012 13:47:38 -0500 (CDT) (envelope-from eric.mcmurry@tekelec.com) From: Eric McMurry Content-Type: multipart/alternative; boundary="Apple-Mail=_E6F02722-5B8B-486B-BF55-74E12182B817" Message-Id: <6E6A4865-E7A7-47C5-B747-67B7CC2F1DEE@tekelec.com> Date: Tue, 2 Oct 2012 13:47:26 -0500 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [Dime] overload requirements feedback X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2012 18:47:42 -0000 --Apple-Mail=_E6F02722-5B8B-486B-BF55-74E12182B817 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The diameter overload control requirements: https://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs have received some feedback on the list and everything received to date = is addressed in the latest version. We are seeing significant interest = on this topic and we'd like to move this along to ensure that the = requirements are good, and stable, so that they are more useful for = mechanism work. To that end, additional comments would be appreciated. Also, we'd like to get some dedicated reviewers though to go through = this to add some additional viewpoints and thoughts. Please respond if = you are able to do this. Thanks, Eric --Apple-Mail=_E6F02722-5B8B-486B-BF55-74E12182B817 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = diameter overload control requirements:

My understanding, as expressed above, is that in order for a reader to > expect to understand an RFC, they must first have read and understood > the normative references. Is that incorrect? It depends upon what is being drawn from the references, and it is the job of the referring text to explain its use of the reference. It also is not typical to require the reader to check the references section to find out what is normative and what isn't. That's why we have normative vocabulary. By requiring the reader to flip back and forth to the references section, to find out what is normative and what isn't, the specification is made markedly more cumbersome to use. > > In general, this document's frequent use of "AVP" appears to be an > > oddly syntactic focus. Typical specifications refer to attributes, > > without such frequent, explicit reference to the form of their having > > values. On its own, this point could seem like quibbling, but it's > > part of the reaction I had when reading the document, that is seemed > > less accessible than one would wish for a new reader. > > This document is not intended to function as a primer on Diameter, AAA, > or network access systems. Except that the document does provide /some/ primer material: The Diameter base protocol provides the following facilities: ... all data delivered by the protocol is in the form of an AVP Documents need to define their normative context. There is benefit in making different documents minimize that context. Obviously documents that extend a service must rely on the foundation of that service, but the specification of an extension can be made more or less complicated by the way divide-and-conquor writing is done. > The centrality of AVPs to the operation of the Diameter protocol might > explain the focus of this draft upon them. My point was not that the use of attributes was unusual, but that the terminologic focus on what is essentially a syntactic aspect of the construct is unusual and, in my view, overly detailed. It's a bit like spelling out 'period' at the end of every sentence in a document. Distracting and unnecessary. And again, the term isn't defined in this document, in spite of there being a Terminology section. >> > > > >> by common usage. These are session identification, > >> authentication, authorization, tunneling, and accounting. The > >> authorization AVPs are further broken down by service type. > > > > This document appears to require deep knowledge of The Diameter Base > > Protocol. In reality, I don't think this document can be > > meaningfully read without that knowledge. So this document should > > say that. (The language in the first paragraph of the Intro doesn't > > actually say it.) > > One more time: read the normative references. Understand them. All of > them. Once again: say that. have the text cite them as musts for background and familiarity. > >> 1.6. Accounting Model > >> > >> It is RECOMMENDED that the coupled accounting model (Section 9.3 > >> of [I-D.ietf-dime-rfc3588bis]) be used with this application; > >> therefore, the value of the Acct-Application-Id AVP in the > >> Accounting-Request (Section 3.10) and Accounting-Answer (Section > >> 3.9) messages SHOULD be set to one (1). > > > > All of the values in those two sections (except the "271") are > > symbolic. As such, setting a value to "1" has no obvious meaning. > > > > I assume that the issue would be fixed by using symbolic values > > here? > > Or by reading RFC 3588. Which part? in my review I tried to make clear that I actually had looked in RFC 3588 to resolve questions about the text I was reviewing. Had that succeeded I would have made more specific suggestions for resolving specific issues. So, for the current case, the word 'symbolic' appears in RFC 3588 exactly one time, for icmptypes types, very deep in Section 4.3. I did not find it at all helpful for resolving the point I raised here in the review. Just to check, it appears the response to the review ended with this item. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Mon Oct 1 12:20:08 2012 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 9C06521F8816; Mon, 1 Oct 2012 12:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEjUL3uhAn4k; Mon, 1 Oct 2012 12:20:07 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E0521F8814; Mon, 1 Oct 2012 12:20:07 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q91JJrdU025738; Mon, 1 Oct 2012 12:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349119199; bh=smM120F0XSIlgz9eRVNEGCWDHF4eyESYwzDDHF5QQ4A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Mb653YkMuHIqXcuO3W8riotUNUhscZ53ST6cnPd+0oh/ZXvH/tjOg1u5I4gPX69x1 kKN1sSiCt3hNMy67tm6QT2WYbsA4yNKvE1IIPdu5n92oEk/BbwqVjeOQ6u8owPI47r tPtYoNu1voeo5PlPDKOyqpRkomkJVZ9Wz86+JRe8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349119199; i=@resistor.net; bh=smM120F0XSIlgz9eRVNEGCWDHF4eyESYwzDDHF5QQ4A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2BrNeAi9YoLBcFWrT1ltCnmj4s0+++q7AAlP5MiaAaY66wsZPDzld1Te0YAtCc+Hn g55/20v6Bs88ZhBuGBXPw6WDrWzydcY4hbwDsg1azMVf11JnxaWIitBprnTzd1Dt5I NcdTEVr4kCpZFUycel1RiL0TV1flarBzg/U446i4= Message-Id: <6.2.5.6.2.20121001114245.0a490458@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 01 Oct 2012 12:03:37 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <50694C10.4050508@gmail.com> References: <50161436.8080900@bbiw.net> <50694C10.4050508@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 03 Oct 2012 01:19:43 -0700 Cc: dime mailing list , Dave Crocker , draft-ietf-dime-rfc4005bis.all@tools.ietf.org Subject: Re: [Dime] [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 19:20:08 -0000 Hello, [I removed iesg@ from the Cc] At 00:53 01-10-2012, Glen Zorn wrote: > >> 4.2.9. Reply-Message AVP > >> > >> The Reply-Message AVP (AVP Code 18) is of type UTF8String and > >> contains text that MAY be displayed to the user. When used in an > >> AA- > > > > Since I doubt that this specification is intended to cover user > > interface design -- and hope that it is not -- I think that the > > normative, semantic point in specification terms is that the strings > > MUST be created with the intent of displaying them to humans. That > > is, these are human-consumable strings, not (necessarily) > > computer-consumable. The Gen-ART review ( http://www.ietf.org/mail-archive/web/ietf/current/msg75004.html ) mentioned that "every use of UTF8String in this draft needs to be checked, and most of them are likely to need some attention". In case it is useful to anyone "UTF8String" is mentioned in draft-ietf-dime-rfc3588bis-33. Regards, -sm From jouni.nospam@gmail.com Wed Oct 3 01:43:43 2012 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 0EF9021F8489 for ; Wed, 3 Oct 2012 01:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ4j9NHQPDuh for ; Wed, 3 Oct 2012 01:43:42 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE4CF21F84A1 for ; Wed, 3 Oct 2012 01:43:41 -0700 (PDT) Received: by weyu46 with SMTP id u46so4561105wey.31 for ; Wed, 03 Oct 2012 01:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gn5oVaMU+cJhk+CuFDplXRVKxXwfBiYmPcU/69/PKCs=; b=xtwv3UvzxBAVV46M3sp4MyhRMbFsq/9na93kGaT5eOusL4eXm1wi9O9j2LY8qCQLxq DZzjfOuR03U9nn5od475CK3gwtZGN22qZvzRZoadIsr8ErNq3dnyi+FLBNaYoLhDaj7p vB4YW/E8i5PyptvDAiadksw45gDdj47w2IxrZyQJq80qbZF8HhM33pjIyIALqZBePuNx 1V1jpme7G5DrptDiNjvdHf9qPN06k7MglEisZcqeo1UD3+3m7lF65vI7P9CQKTrETCZI Dgrk8tEBSF9TLuVCGdu4n6lLgktjFyv2tl8r6fVG1rsJNB+ngo1Qukh0l1xBFya8Szc5 OY3A== Received: by 10.180.76.69 with SMTP id i5mr3335773wiw.9.1349253820845; Wed, 03 Oct 2012 01:43:40 -0700 (PDT) Received: from ?IPv6:2001:6e8:2100:100:223:32ff:fec9:7938? ([2001:6e8:2100:100:223:32ff:fec9:7938]) by mx.google.com with ESMTPS id hv8sm30147221wib.0.2012.10.03.01.43.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Oct 2012 01:43:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <1836CE1BA4F81F46921CA0334F7E4274583132FE03@HE113456.emea1.cds.t-internal.com> Date: Wed, 3 Oct 2012 11:43:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3C908D20-2417-42B4-876A-C1743BA1F94F@gmail.com> References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5066EA99.3020801@gmail.com> <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> <50684D98.8010400@cs.tcd.ie> <1836CE1BA4F81F46921CA0334F7E4274583132FE03@HE113456.emea1.cds.t-internal.com> To: X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, Stefan.Schroeder06@telekom.de, dime@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 08:43:43 -0000 On Oct 2, 2012, at 1:40 PM, = wrote: > Hello all > a question for me is also what exactly do we mean by: >=20 >> "MUST NOT be sent via intermediate nodes unless there is end-to-end=20= >> security between the originator and recipient " >=20 > Which kind of e2e security? There is no such thing in Diameter right = now, or did I miss something? There is no such thing.. But we have the lack of it reflected in our = charter. Two meetings ago we had some discussion around the topic during the WG = meeting. > We can only do e2e security by hop-by-hop security (IPsec or TLS), if = there is NO intermediate (Diameter) node. > So, either we have e2e security, then there is no intermediate node - = or we have intermediate nodes, then there can't be e2e security.=20 As for now, you can go around this for coming applications by = application specific means; like defining AVPs that inherently only carry encrypted payload etc. - Jouni >=20 >=20 > Best regards > Dieter Jacobsohn >=20 >=20 > Deutsche Telekom AG > Group Technology > Dieter Jacobsohn > Landgrabenweg 151, 53227 Bonn > +49 228 936-18445 (Tel.) > +49 391 5801 46624 (Fax) > +49 171 2088 710 (Mobil) > E-Mail: dieter.jacobsohn@telekom.de > www.telekom.com =20 >=20 > Erleben, was verbindet. =20 >=20 > Deutsche Telekom AG > Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender) > Vorstand: Ren=E9 Obermann (Vorsitzender), > Dr. Manfred Balz, Reinhard Clemens, Niek Jan van Damme, > Timotheus H=F6ttges, Claudia Nemat, Prof. Dr. Marion Schick > Handelsregister: Amtsgericht Bonn HRB 6794 > Sitz der Gesellschaft Bonn > USt-IdNr. DE 123475223 >=20 > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht = jede E-Mail drucken.=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From abooth@pt.com Thu Oct 4 11:27:37 2012 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 A00C821F867C for ; Thu, 4 Oct 2012 11:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_BAD_LINEBREAK=0.5, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qESPqk09GzXg for ; Thu, 4 Oct 2012 11:27:37 -0700 (PDT) Received: from ottgw.pt.com (ottgw.pt.com [209.217.107.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3550621F8648 for ; Thu, 4 Oct 2012 11:27:36 -0700 (PDT) Received: from notes4.pt.com (notes4.corp.pt.com [10.81.15.15]) by ottgw.pt.com (Postfix) with ESMTP id 384D042534 for ; Thu, 4 Oct 2012 13:52:59 -0400 (EDT) X-Disclaimed: 1 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Andrew Booth To: dime@ietf.org Message-ID: Date: Thu, 4 Oct 2012 14:27:34 -0400 X-Mailer: Lotus Domino Web Server Release 8.5.3 September 15, 2011 X-MIMETrack: Serialize by Notes Server on notes4/PTI(Release 8.5.3|September 15, 2011) at 10/04/2012 02:27:34 PM, Serialize complete at 10/04/2012 02:27:34 PM, Itemize by Notes Server on notes4/PTI(Release 8.5.3|September 15, 2011) at 10/04/2012 02:27:34 PM, Serialize by Router on notes4/PTI(Release 8.5.3|September 15, 2011) at 10/04/2012 02:27:34 PM Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Subject: [Dime] Questions on 3588bis election text X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2012 18:27:37 -0000 Hi,

It seems to me that the election resolution text in secti= on 5.6.4 of draft-ietf-dime-rfc3588bis-34.txt is not backward compatible wi= th RFC3588, is this correct?
My understanding is that IF a diameter node= that implements 3588 is communicating with one that implements 3588bis AND= at least one of the Diameter IDs contains capital letters in the wrong pla= ces, then the two nodes could have different views on which node wins the e= lection, possibly resulting in 0 or 2 connections between the nodes.
Could this lead to reconnect loops where both sides reconnect after Tc and= then both continue to close the connection?
=0D
Am I misunderstandin= g something?  Or is this not an issue for other reasons?

Thanks= for any info,
Andrew
= From jouni.nospam@gmail.com Thu Oct 4 13:46:04 2012 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 D54E121F8543 for ; Thu, 4 Oct 2012 13:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1WCfdl1ITau for ; Thu, 4 Oct 2012 13:46:04 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3A321F853F for ; Thu, 4 Oct 2012 13:46:04 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1103702wib.13 for ; Thu, 04 Oct 2012 13:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=xVSzNFEILaHT0IOJF+pzDSyuu2jvofTkIpM1OLv5XLc=; b=h1dEz+18KlPxzCEdyJFXLQESp6yo6K6l/FV1Pw3kwx/JjLvxc1yUR4+TK9JCCD9uJ2 pNmSsMHaj0Jj7hQ5JMRtut1WdnH7SbhCvtIi6IfpKlWDW7KaowC9w3vIRYuDW2gGhRRe WDpG9NEkTHdWZA/4RT8lgm4XPmKIq6DylfilS3zMHdCuxfsvQUJ2BlrJBx6wQ825O3fX FdIniR4/FC7lArtbwocKLVnizzfPihP0/iqQHlasj61sT+kWWWfWfSXvrTIty4J4Wsm6 WTcWwyYQ2dG5Szjo8GH55n69/k/ViQk4MEv+vVfVT9fGBooEV7B/8hu3JT4/26d3MW0F 5hbQ== Received: by 10.180.87.230 with SMTP id bb6mr23050680wib.6.1349383563145; Thu, 04 Oct 2012 13:46:03 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id gm7sm16739836wib.10.2012.10.04.13.46.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 13:46:02 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 4 Oct 2012 23:45:59 +0300 Message-Id: <18B3378F-8296-4A85-9963-E74FACF25D13@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Dime WG meeting in Atlanta X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2012 20:46:04 -0000 Folks, We have been scheduled a 2h slot (object to change the date & time) dime Session 1 (2:00:00) Monday, Afternoon Session I 1300-1500 Room Name: Room 209 If you feel like presenting something, send the co-chair a mail with the topic, estimated airtime and why you think it needs to get a slot. - Jouni From adam@nostrum.com Thu Oct 4 14:58:00 2012 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 5EA9E21F865D for ; Thu, 4 Oct 2012 14:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiGMV2B9N-RW for ; Thu, 4 Oct 2012 14:57:58 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E03AA21F8611 for ; Thu, 4 Oct 2012 14:57:57 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q94Lvuks090586 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 4 Oct 2012 16:57:57 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <506E0664.3010509@nostrum.com> Date: Thu, 04 Oct 2012 16:57:56 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "DIME (Diameter Maintenance and Extensions) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [Dime] Diameter Overload Mechanism Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2012 21:58:00 -0000 Based on the requirements document that was discussed in Paris (and subsequently on the mailing list), I have put together a proposal for a mechanism that is intended to satisfy the majority of those requirements: http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-00 This document still has a number of (clearly marked) open issues, and I'm very open to changing just about every aspect of what is proposed. If anyone has additional mechanism ideas in mind, I'm more than happy to incorporate them into the proposal (or otherwise merge such ideas together) and/or work towards complementary overload management approaches. Please look over the document and provide comments. I hope to discuss this proposal in Atlanta next month. If we get enough discussion before the -01 draft deadline, I'd like to issue a second version incorporating that early feedback. Thanks! /a From jouni.nospam@gmail.com Thu Oct 4 16:39:38 2012 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 C02A221F8682 for ; Thu, 4 Oct 2012 16:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCLlQRl2tzXE for ; Thu, 4 Oct 2012 16:39:38 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02D6021F8686 for ; Thu, 4 Oct 2012 16:39:37 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so637857wgb.13 for ; Thu, 04 Oct 2012 16:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=Y25nu8cmD8NapgQk+Zc8go/qZKcL2D4hvhDZ0Wtb3IE=; b=JCUNe+9Gam5rOSZEJLblkozalqZmnCwnzPLn4fOAL058auMojEbs0pNs0Gh2wDjNiM JrLgGEyj/b+FIPa1cCknQPwJzBMOgKymMuBRVaaAqTgeVXO2SIrfWH1cvINzpW/oEgyo v0GrlyZzhwRle5aG2MazLGpSW2pWkvcE1ot1XNyAM94VbLNZQbBwkNtZVEwRhxSkqrNl UBh+qRxV25/obfkE8N0wjm1hI8CCj83qUm/tFgg34MSbXNv5J5slQQ3oxJRYsO8wG6h3 pJ9uBxgIm7yvq5dA+L/Dfn9DJq9RBtlwJoIsg92fYvV0ncSqDVpp7OBMahwNh3t3DJDM 05Qg== Received: by 10.180.79.103 with SMTP id i7mr16271387wix.13.1349393977191; Thu, 04 Oct 2012 16:39:37 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id dt9sm32538705wib.1.2012.10.04.16.39.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 16:39:36 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 02:39:32 +0300 References: <20121003123338.29397.81894.idtracker@ietfa.amsl.com> To: dime@ietf.org Message-Id: <424FE5AC-CBAD-4DDD-B6D6-D4337E31A017@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] Fwd: New Version Notification for draft-korhonen-dime-ovl-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2012 23:39:38 -0000 FYI Begin forwarded message: > A new version of I-D, draft-korhonen-dime-ovl-00.txt > has been successfully submitted by Jouni Korhonen and posted to the > IETF repository. >=20 > Filename: draft-korhonen-dime-ovl > Revision: 00 > Title: Diameter Overload Control Application > Creation date: 2012-10-03 > WG ID: Individual Submission > Number of pages: 23 > URL: = http://www.ietf.org/internet-drafts/draft-korhonen-dime-ovl-00.txt > Status: = http://datatracker.ietf.org/doc/draft-korhonen-dime-ovl > Htmlized: http://tools.ietf.org/html/draft-korhonen-dime-ovl-00 >=20 >=20 > Abstract: > This specification documents a Diameter Overload Control Application > (DOCA), which uses the normal Diameter application approach for the > capability negotiation, propagation and management of Diameter > overload control information between Diameter nodes. >=20 > Requirements >=20 From glenzorn@gmail.com Sat Oct 6 20:13:25 2012 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 51B3E21F83EF for ; Sat, 6 Oct 2012 20:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qpsfequOcBQ for ; Sat, 6 Oct 2012 20:13:24 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF3921F8484 for ; Sat, 6 Oct 2012 20:13:24 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so971424dan.31 for ; Sat, 06 Oct 2012 20:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZL1dzDEqnH2v+lhpoF7CFHDsEEfVG0c+BD4DBhSWmB0=; b=MGKX2y9RGkChm4x7ROMpWxiZc688k0BNf075tzL1xCoG6rWziJYgF/m7yAEAujIsc+ vcA+vcQouSMfIpypxb5KbI9J+fyzfjt2QOVMFneHl9tl7UxcYbeRxKGfsDV+SqmSZtdd 3kZm5JCee9lH+bK6kHu0cOoqC/b0Btg70y9O2rx6y4N5G3nntqzi2e+LDYYcph2OtvMh YTfzp0CHQtvtOUZjfntdvS4uYNhoAAHgYuCuJUoB5/W+s+8snEt0vJSgq5WWLXv9GZmS dAquDta14ynIzxCr0CUMXrayZCgO8wCt6TLwX4fVEeWl+ed2gOVhq/CYrYMVJ0ztsB+E /0Lg== Received: by 10.68.235.71 with SMTP id uk7mr42824072pbc.10.1349579604217; Sat, 06 Oct 2012 20:13:24 -0700 (PDT) Received: from [192.168.0.102] (ppp-115-87-90-243.revip4.asianet.co.th. [115.87.90.243]) by mx.google.com with ESMTPS id jw14sm8489599pbb.36.2012.10.06.20.13.22 (version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 20:13:23 -0700 (PDT) Message-ID: <5070F350.1010000@gmail.com> Date: Sun, 07 Oct 2012 10:13:20 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Booth References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Questions on 3588bis election text X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 03:13:25 -0000 On 10/05/2012 01:27 AM, Andrew Booth wrote: > Hi, > > It seems to me that the election resolution text in section 5.6.4 of > draft-ietf-dime-rfc3588bis-34.txt is not backward compatible with > RFC3588, is this correct? No. > My understanding is that IF a diameter node that implements 3588 is > communicating with one that implements 3588bis AND at least one of the > Diameter IDs contains capital letters in the wrong places, then the > two nodes could have different views on which node wins the election, > possibly resulting in 0 or 2 connections between the nodes. > > Could this lead to reconnect loops where both sides reconnect after Tc > and then both continue to close the connection? > > Am I misunderstanding something? Or is this not an issue for other > reasons? RFC 1035 says "Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical." Since the DiameterIdentity type was defined in RFC 3588 as FQDN, case-sensitivity wasn't an issue; the revision is just more specific about that than the original. > > Thanks for any info, > Andrew > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Sat Oct 6 23:48:59 2012 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 480A721F8472; Sat, 6 Oct 2012 23:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NEgDXuHfMMt; Sat, 6 Oct 2012 23:48:58 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFF121F844F; Sat, 6 Oct 2012 23:48:58 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3190266pbb.31 for ; Sat, 06 Oct 2012 23:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C9SNFUuwPj5ePLgyvbx0YQpxcdo+mXJPaBv8vXcdLY4=; b=nvdt4E/YfTrBUkYxmgCLszGiTtpGAa+kesEFALNW/zf2eKjW7ff4ud/VDlJaiicPVT EamNvk4a0Iup/DSLCHfzYbA9frK0+T0w4j9N1ReLVx7/44r7GJm+XqyU1AJsNhSaGU51 F62WqiuIW0nxmgAhV2EHH6zoD2uWXQbTORV+VHsz1Zlz5tMDOkt+jV5aEyt1mQ3+EiMn dUe3nUeGL/AXqZGEqc75a60fThwgYY8Bo4zhqz0ow7gYPXyJCl+Oy/fg0sR+CIBTTW38 vrJGbN3HlDw2Lb1B6LzA9GWMNtb+YzD0S5RyG8yeb7oChZQX9cnm9kKaoLjzNr4KM4aX e7ew== Received: by 10.68.242.9 with SMTP id wm9mr43292570pbc.62.1349592537886; Sat, 06 Oct 2012 23:48:57 -0700 (PDT) Received: from [192.168.0.102] (ppp-115-87-90-243.revip4.asianet.co.th. [115.87.90.243]) by mx.google.com with ESMTPS id nd6sm5168011pbc.68.2012.10.06.23.48.54 (version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 23:48:57 -0700 (PDT) Message-ID: <507125D5.4050304@gmail.com> Date: Sun, 07 Oct 2012 13:48:53 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <50161436.8080900@bbiw.net> <50694C10.4050508@gmail.com> <5069C58D.1090200@dcrocker.net> In-Reply-To: <5069C58D.1090200@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dave Crocker , draft-ietf-dime-rfc4005bis.all@tools.ietf.org, apps-discuss@ietf.org, dime mailing list , iesg Subject: Re: [Dime] [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 06:48:59 -0000 On 10/01/2012 11:32 PM, Dave Crocker wrote: > Glen, et al, > > > On 10/1/2012 12:53 AM, Glen Zorn wrote: >> On 07/30/2012 11:57 AM, Dave Crocker wrote: >>>> 1. Introduction >>>> >>>> This document describes the Diameter protocol application used >>>> for AAA in the Network Access Server (NAS) environment. When >>>> combined with the Diameter Base protocol >>>> [I-D.ietf-dime-rfc3588bis], Transport Profile [RFC3539], and >>>> EAP [RFC4072] specifications, this specification satisfies the >>>> NAS-related requirements defined in Aboba, et al. [RFC2989] and >>>> Beadles & Mitton [RFC3169]. >>> >>> This assertion raises a dilemma: The cited documents are >>> extensive and the topic(s?) complex. There is no way to know what >>> details are being referred to, to evaluate the assertion. >> >> If there were only specific details that were relevant, only >> specific sections of the document would be cited. To evaluate the >> assertion read the cited documents. All of them. To understand >> this document, read and understand the normative references. All >> of them. > > Then that is what should be said in the specification. > > When citing references, it is typical (and I believe essential) to > have the citation text be specific about what it being used from the > cited document. > > If what is being used is 'everything', then that's what is said. > Explicitly. Language along the lines of "the current specification > requires completely familiarity with: cite1, cite2, ... is typical. I've read a fair number of RFCs (though not all of them, by any means) but I do not recall ever having encountered that language. > > >> My understanding, as expressed above, is that in order for a reader >> to expect to understand an RFC, they must first have read and >> understood the normative references. Is that incorrect? > > It depends upon what is being drawn from the references, and it is > the job of the referring text to explain its use of the reference. > > It also is not typical to require the reader to check the references > section to find out what is normative and what isn't. That's why we > have normative vocabulary. > > By requiring the reader to flip back and forth to the references > section, to find out what is normative and what isn't, the > specification is made markedly more cumbersome to use. Having ascertained what the normative references are, having read and understood them, why would one need to flip back and forth? > > >>> In general, this document's frequent use of "AVP" appears to be >>> an oddly syntactic focus. Typical specifications refer to >>> attributes, without such frequent, explicit reference to the form >>> of their having values. On its own, this point could seem like >>> quibbling, but it's part of the reaction I had when reading the >>> document, that is seemed less accessible than one would wish for >>> a new reader. >> >> This document is not intended to function as a primer on Diameter, >> AAA, or network access systems. > > Except that the document does provide /some/ primer material: > > The Diameter base protocol provides the following facilities: ... all > data delivered by the protocol is in the form of an AVP > > > Documents need to define their normative context. There is benefit > in making different documents minimize that context. Obviously > documents that extend a service must rely on the foundation of that > service, but the specification of an extension can be made more or > less complicated by the way divide-and-conquor writing is done. Sorry, you've lost me. > > >> The centrality of AVPs to the operation of the Diameter protocol >> might explain the focus of this draft upon them. > > My point was not that the use of attributes was unusual, but that the > terminologic focus on what is essentially a syntactic aspect of the > construct is unusual and, in my view, overly detailed. It's a bit > like spelling out 'period' at the end of every sentence in a > document. Distracting and unnecessary. > > And again, the term isn't defined in this document, in spite of there > being a Terminology section. Again, the term is defined in RFC 3588. > > >>> >>> >>>> by common usage. These are session identification, >>>> authentication, authorization, tunneling, and accounting. The >>>> authorization AVPs are further broken down by service type. >>> >>> This document appears to require deep knowledge of The Diameter >>> Base Protocol. In reality, I don't think this document can be >>> meaningfully read without that knowledge. So this document >>> should say that. (The language in the first paragraph of the >>> Intro doesn't actually say it.) >> >> One more time: read the normative references. Understand them. >> All of them. > > Once again: say that. have the text cite them as musts for > background and familiarity. OK, let's try a thought experiment: suppose that I had included a (redundant) sentence like "The reader is assumed to have read and understood all of the documents listed as normative references." in the Abstract (& maybe, just to double-down on redundancy, in the Introduction, too). Would you have actually done that as part of your review? > > >>>> 1.6. Accounting Model >>>> >>>> It is RECOMMENDED that the coupled accounting model (Section >>>> 9.3 of [I-D.ietf-dime-rfc3588bis]) be used with this >>>> application; therefore, the value of the Acct-Application-Id >>>> AVP in the Accounting-Request (Section 3.10) and >>>> Accounting-Answer (Section 3.9) messages SHOULD be set to one >>>> (1). >>> >>> All of the values in those two sections (except the "271") are >>> symbolic. As such, setting a value to "1" has no obvious >>> meaning. >>> >>> I assume that the issue would be fixed by using symbolic values >>> here? >> >> Or by reading RFC 3588. > > Which part? The part that is, in this case, specifically referenced: Section 9.3, reproduced below. 9.3. Accounting Application Extension and Requirements Each Diameter application (e.g., NASREQ, Mobile IP) SHOULD define its service-specific AVPs that MUST be present in the Accounting-Request message in a section titled "Accounting AVPs". The application MUST assume that the AVPs described in this document will be present in all Accounting messages, so only their respective service-specific AVPs need to be defined in that section. Applications have the option of using one or both of the following accounting application extension models: Split Accounting Service The accounting message will carry the Application Id of the Diameter base accounting application (see Section 2.4). Accounting messages may be routed to Diameter nodes other than the corresponding Diameter application. These nodes might be centralized accounting servers that provide accounting service for multiple different Diameter applications. These nodes MUST advertise the Diameter base accounting Application Id during capabilities exchange. Coupled Accounting Service The accounting message will carry the Application Id of the application that is using it. The application itself will process the received accounting records or forward them to an accounting server. There is no accounting application advertisement required during capabilities exchange, and the accounting messages will be routed the same way as any of the other application messages. In cases where an application does not define its own accounting service, it is preferred that the split accounting model be used. Since the recommendation is to use the coupled accounting model, the value of the Acct-Application-Id AVP should be set to the NASREQ Application Id (1). > in my review I tried to make clear that I actually had > looked in RFC 3588 to resolve questions about the text I was > reviewing. Had that succeeded I would have made more specific > suggestions for resolving specific issues. > > So, for the current case, the word 'symbolic' appears in RFC 3588 > exactly one time, for icmptypes types, very deep in Section 4.3. I > did not find it at all helpful for resolving the point I raised here > in the review. > > > Just to check, it appears the response to the review ended with this > item. Yes, it was frankly very difficult to find anything that wasn't covered by either RTFRFC or a stylistic quibble. I gave up. > > d/ From glenzorn@gmail.com Sun Oct 7 00:28:20 2012 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 859F921F84EC; Sun, 7 Oct 2012 00:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJeOIyN2wjX8; Sun, 7 Oct 2012 00:28:19 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38A9F21F84EA; Sun, 7 Oct 2012 00:28:19 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3203714pbb.31 for ; Sun, 07 Oct 2012 00:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Xa6g5o0xcjFHO82Ht242m0ngBDIZSArp/jH6CIuiQ6A=; b=WQYq2mEvCOMWxbDQO3asOtatYVP9P3lw6+8kbX6o064bJzsDjVqQZZNXnEkKazhXKH i7ifP2wxhaK1wErNv3SV5xxpRB6QVsvHgrSMCfAKipZiEs0ww9ogmEZnMcdGXuavobpQ q4FrgiuL7FkqXq6Hc126Ro7tOiVsIU2jGPQTJRp81EOkP1RVDSvZjUw36Q4YE9aMzOQM tEREvFP/ZquvStaBwOaSM9XXmV3PwOiFxJrrxHFT/5sXcSLRi+Xs6oz/ymekMXSCWpEm urdxlG1jEOB++nm6OXkeBHd9tgRFqz47iAJamydyfJaBQIXQNehyETOtWaGIkva4iMBA 2kqg== Received: by 10.68.234.7 with SMTP id ua7mr44345460pbc.91.1349594898753; Sun, 07 Oct 2012 00:28:18 -0700 (PDT) Received: from [192.168.0.102] (ppp-115-87-90-243.revip4.asianet.co.th. [115.87.90.243]) by mx.google.com with ESMTPS id oi2sm7531203pbb.62.2012.10.07.00.28.15 (version=SSLv3 cipher=OTHER); Sun, 07 Oct 2012 00:28:18 -0700 (PDT) Message-ID: <50712F0A.1050309@gmail.com> Date: Sun, 07 Oct 2012 14:28:10 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ietf@ietf.org" , "draft-ietf-dime-rfc4005bis@tools.ietf.org" , "gen-art@ietf.org" , "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 07:28:20 -0000 On 09/18/2012 06:53 AM, Black, David wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call > comments you may receive. > > Document: draft-ietf-dime-rfc4005bis-11 Reviewer: David L. Black > Review Date: September 17, 2012 IETF LC End Date: September 18, 2012 > IESG Telechat date: (if known) > > Summary: > > This draft is on the right track but has open issues, described in > the review. > > This draft is part of a set of drafts that updates the DIAMETER > protocol; this draft specifies the application of DIAMETER to AAA for > network access. The draft is heavily based on RFC 4005, which it > obsoletes, and requires significant DIAMETER familiarity (including > familiarity with its companion drafts, starting with the rfc3588bis > draft) for complete understanding. > > The draft is in good shape and reads well. I found one major open > issue, a few minor issues, and several nits. > > Major issues: > > This draft makes significant use of UTF-8 in its formats (some > subsections of sections 4.2, 4.4 and 4.5) for strings that are > intended to be compared for equality or processed by protocol > participants, but does not contain considerations for Unicode > processing that are sufficient to support this usage. Examples of > UTF-8 usage in this draft include: > > - 4.2.5 and 4.2.6: The NAS server may perform authorization based on > the Called-Station-Id and Calling-Station-Id AVPs under some > circumstances. - 4.4.3: The Callback-Id AVP is intended to be > interpreted by the NAS. > > All use of UTF-8 in this draft relies upon the specification of the > UTF8String format in the rfc3588bis draft. That specification is > insufficient to support the usage in the above examples, and there > are no Unicode considerations in this draft. Even binary comparison > of Unicode strings for equality generally requires specification of > string preparation (e.g., normalization) in order for string > comparison to work as expected. > > The variety of Unicode strings in this draft makes it important to > lay out the Unicode requirements and considerations for each AVP. I > see at least 5 classes of possible Unicode > requirements/considerations: > > 1) String preparation so that tests for equality work as expected. > This may suffice for the Called-Station-ID AVP (4.2.5) and > Calling-Station-ID AVP (4.2.6) if the internal structure of those > strings is not used in authorization. Both those AVPs are specified to contain ASCII encoded as UTF-8. Is string preparation necessary in that case? > 2) Detailed string format for a > string that is processed by a protocol participant, e.g., the > Callback-ID AVP (4.4.3). That format is unknown in this case. ... > 5) Statement that the string contains an FQDN, as stated for one case of > the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is > incomplete, as it needs to be accompanied by a normative reference to > a document that specifies the format of internationalized domain > names, and probably needs to also state which types of labels (e.g., > A-label, U-label) are allowed. > > Every use of UTF8String in this draft needs to be checked, and most > of them are likely to need some attention. The ongoing work in the > precis WG may help with some of this, and I would suggest talking to > the APP ADs, especially Pete Resnick (hi Pete) before embarking on > significant work in this area in order to avoid wasted or duplicated > efforts. OK, this last one bothers me a lot: you /seem /to be suggesting that we hold up this draft to wait for the result of a WG which has yet to publish a problem statement. I'm sure that that is not the case, but it sure sounds like it. > > Minor Issues: > > [1] End of Section 2 on p.8: > > As a result, service cannot be started as a result of a response to > an authorization-only request without introducing a significant > security vulnerability. > > Please explain what to do about this - a simple rewrite with a > "SHOULD NOT" would suffice, e.g.: > > As a result, service SHOULD NOT be started as a result of a response > to an authorization-only request because that may introduce a > significant security vulnerability. The text in question is descriptive, not prescriptive.at said, however, I think that it's not really clear. I think that it should say something like "As a result, a new session cannot be started as a result of a response to an authorization-only request without introducing a significant security vulnerability." > > This should also be noted in the Security Considerations section. > > [2] In the message formats in Section 3, QoS-Filter-Rule is > inconsistently capitalized. OK, thanks. > Also the use of QoSFilterRule as the > format for the QoS-Filter-Rule AVP in Section 4.1.1 is potentially > confusing. Please add a sentence in 4.1.1 to say that QoSFilterRule > is the format for the QoS-Filter-Rule AVP. > > [3] Section 4.2.1. In this and the other AVP Flag Rules tables, > please explain what the values in the MUST and MUST NOT columns > mean. > > [4] Based on this text in 4.4.9: > > The use of this AVP is NOT RECOMMENDED; the AVPs defined by > Korhonen, et al. [RFC5777] SHOULD be used instead. > > I would have expected RFC5777 to be a Normative Reference, not an > Informative Reference. I don't care particularly, but I don't think that it's really necessary to understand RFC 5777 to understand this document. > > Nits/editorial comments: > > After the command table in Section 3 and other similar tables, please > add a sentence to say that the -Request and -Answer commands in each > similarly-named command pair are distinguished by the value of the > 'R' bit in the Command Flags field of the command. This is already > stated in the command definitions, but the sentence should be added > after the table for clarity because each command pair shares a > Command Code. > > idnits 2.12.13 found a few potential nits: > > == There are 7 instances of lines with non-RFC5735-compliant IPv4 > addresses in the document. If these are example addresses, they > should be changed. > > That can probably be ignored, as these instances are likely generated > by text such as cross-references to Section 4.4.10.1 > > == Missing Reference: 'BASE' is mentioned on line 219, but not > defined > > That's definitely a problem. Was [I-D.ietf-dime-rfc3588bis] > intended? No. The passage in question is a verbatim quote from RFC 4005. > > -- Possible downref: Non-RFC (?) normative reference: ref. > 'ANITypes' > > That reference would be: > > [ANITypes] NANPA Number Resource Info, "ANI Assignments", > ani_ii_assignments.html>. > > Is that reference sufficiently stable (e.g., IANA-class or better > management)? Yes, I think so. > My guess is that it is sufficiently stable, but I'm not > the expert. > > -- Obsolete informational reference (is this intentional?): RFC 1334 > (Obsoleted by RFC 1994) > > That reference may be intentional, Yes. ... From dhc@dcrocker.net Sun Oct 7 07:32:50 2012 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 210DF21F86D8; Sun, 7 Oct 2012 07:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK5lj0OVRsOR; Sun, 7 Oct 2012 07:32:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B62A121F86D6; Sun, 7 Oct 2012 07:32:48 -0700 (PDT) Received: from [192.168.1.6] (adsl-67-127-59-48.dsl.pltn13.pacbell.net [67.127.59.48]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q97EWgwL032054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 7 Oct 2012 07:32:42 -0700 Message-ID: <5071928A.9010408@dcrocker.net> Date: Sun, 07 Oct 2012 07:32:42 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Glen Zorn References: <50161436.8080900@bbiw.net> <50694C10.4050508@gmail.com> <5069C58D.1090200@dcrocker.net> <507125D5.4050304@gmail.com> In-Reply-To: <507125D5.4050304@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 07 Oct 2012 07:32:45 -0700 (PDT) Cc: apps-discuss@ietf.org, dime mailing list , dcrocker@bbiw.net, draft-ietf-dime-rfc4005bis.all@tools.ietf.org, iesg Subject: Re: [Dime] [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 14:32:50 -0000 On 10/6/2012 11:48 PM, Glen Zorn wrote: > On 10/01/2012 11:32 PM, Dave Crocker wrote: > > When citing references, it is typical (and I believe essential) to > > have the citation text be specific about what it being used from the > > cited document. > > > > If what is being used is 'everything', then that's what is said. > > Explicitly. Language along the lines of "the current specification > > requires completely familiarity with: cite1, cite2, ... is typical. > > I've read a fair number of RFCs (though not all of them, by any means) > but I do not recall ever having encountered that language. I don't either. Specs usually describe the prior normative knowledge that is required. It's not typical to require as much as this one, such as taking knowledge of specialized terminology as a given, to the point of not declaring it explicitly. > > It also is not typical to require the reader to check the references > > section to find out what is normative and what isn't. That's why we > > have normative vocabulary. > > > > By requiring the reader to flip back and forth to the references > > section, to find out what is normative and what isn't, the > > specification is made markedly more cumbersome to use. > > Having ascertained what the normative references are, having read and > understood them, why would one need to flip back and forth? The flaw in the question is the "having ascertained". The usual form of citations is to the specific text that is used at a particular point. When an attorney cites a law, they don't simply say "Federal Code" or "California Code". They cite the specific sub-section. We try to do that for technical specifications, too. > > Documents need to define their normative context. There is benefit > > in making different documents minimize that context. Obviously > > documents that extend a service must rely on the foundation of that > > service, but the specification of an extension can be made more or > > less complicated by the way divide-and-conquor writing is done. > > Sorry, you've lost me. I was suggesting benefit in modularization with clean, limited, explicitly-defined interfaces, for specifications as well as software. > >> The centrality of AVPs to the operation of the Diameter protocol > >> might explain the focus of this draft upon them. > > > > My point was not that the use of attributes was unusual, but that the > > terminologic focus on what is essentially a syntactic aspect of the > > construct is unusual and, in my view, overly detailed. It's a bit > > like spelling out 'period' at the end of every sentence in a > > document. Distracting and unnecessary. > > > > And again, the term isn't defined in this document, in spite of there > > being a Terminology section. > > Again, the term is defined in RFC 3588. Again, the reader of the document doesn't have an explicit way to know that, since this is a specialized term and its importation from 3588 isn't declared. Specifications that have a default source for definitions usually state that explicitly. > >> One more time: read the normative references. Understand them. > >> All of them. > > > > Once again: say that. have the text cite them as musts for > > background and familiarity. > > OK, let's try a thought experiment: suppose that I had included a > (redundant) sentence like "The reader is assumed to have read and > understood all of the documents listed as normative references." in the > Abstract (& maybe, just to double-down on redundancy, in the > Introduction, too). Would you have actually done that as part of your > review? I did. Note, for example, that I made a point of citing some omissions in the current document that are not satisfied by knowledge of the underlying documents. > >>>> 1.6. Accounting Model > >>>> > >>>> It is RECOMMENDED that the coupled accounting model (Section > >>>> 9.3 of [I-D.ietf-dime-rfc3588bis]) be used with this > >>>> application; therefore, the value of the Acct-Application-Id > >>>> AVP in the Accounting-Request (Section 3.10) and > >>>> Accounting-Answer (Section 3.9) messages SHOULD be set to one > >>>> (1). > >>> > >>> All of the values in those two sections (except the "271") are > >>> symbolic. As such, setting a value to "1" has no obvious > >>> meaning. > >>> > >>> I assume that the issue would be fixed by using symbolic values > >>> here? > >> > >> Or by reading RFC 3588. > > > > Which part? > > The part that is, in this case, specifically referenced: Section 9.3, > reproduced below. > > 9.3. Accounting Application Extension and Requirements ... > Since the recommendation is to use the coupled accounting model, the > value of the Acct-Application-Id AVP should be set to the NASREQ > Application Id (1). I assume this is the specific text that you are referring to. In other words, the current draft is redundantly specifying normative detail, after already 'recommending' a controlling normative source. This is a good way to encourage divergent normative detail, over time. That is, the text after te semi-colon should be dropped. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba.mailing.lists@gmail.com Mon Oct 8 10:16:53 2012 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 A95A221F87E8; Mon, 8 Oct 2012 10:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJAnkpc3SQYu; Mon, 8 Oct 2012 10:16:53 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40321F87E4; Mon, 8 Oct 2012 10:16:52 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2672668lam.31 for ; Mon, 08 Oct 2012 10:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DvWnnNe9gwL58ZzSLvx2fDmeW+DHgNZyJ/zBR0qrcC4=; b=QrXTvh35QLhsYKEBrjTZh4RDJzid44fLvgjKFa34yj45VcCiCeXDkbuSUiFg2mLJCk OQ5GFGmeG4PScRu/C8O8eHvqmOPg/WgIbQtGZxiXCn2dao6DRu6RXM22WUE49aoS/3qK 3289cay5RWysjlh7EPRbWalnELv1VDJrauDsqIKCZzeqKkfDghrPkOVgHkXkNSlCs2bs 6FEXGo0piv0Ck4XFtmYrgpKaAwsMYpE0A2Qrc/v1LTQvkC/TceSp7xkfRowLT5ibibHp eGhux1LMDU3XPWQhE3OfOuRgzX52KESDck9k9ZuIuLasTNlMF1WVFp77/IyXzcw4SSKe mjTQ== MIME-Version: 1.0 Received: by 10.112.101.133 with SMTP id fg5mr2771608lbb.3.1349716611100; Mon, 08 Oct 2012 10:16:51 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.150.194 with HTTP; Mon, 8 Oct 2012 10:16:50 -0700 (PDT) In-Reply-To: <50712F0A.1050309@gmail.com> References: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> <50712F0A.1050309@gmail.com> Date: Mon, 8 Oct 2012 13:16:50 -0400 X-Google-Sender-Auth: kuSWlw21NSFpLbLwLkm8lk1x1sk Message-ID: From: Barry Leiba To: Glen Zorn , precis-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "ietf@ietf.org" , "gen-art@ietf.org" , "draft-ietf-dime-rfc4005bis@tools.ietf.org" , "dime@ietf.org" , "Black, David" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2012 17:16:53 -0000 >> 5) Statement that the string contains an FQDN, as stated for one case of >> the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is >> incomplete, as it needs to be accompanied by a normative reference to >> a document that specifies the format of internationalized domain >> names, and probably needs to also state which types of labels (e.g., >> A-label, U-label) are allowed. >> >> Every use of UTF8String in this draft needs to be checked, and most >> of them are likely to need some attention. The ongoing work in the >> precis WG may help with some of this, and I would suggest talking to >> the APP ADs, especially Pete Resnick (hi Pete) before embarking on >> significant work in this area in order to avoid wasted or duplicated >> efforts. > > OK, this last one bothers me a lot: you /seem /to be suggesting that we hold > up this draft to wait for the result of a WG which has yet to publish a > problem statement. I'm sure that that is not the case, but it sure sounds > like it. David can clarify if I'm wrong, but that's not what it sounds like to me. What it sounds like he's suggesting is that you talk with the precis people to see if things are OK, or if there's anything you should be doing differently. I'm adding the precis chairs to this message, and asking them to respond to this point. A tangential point, while I'm here: >> [4] Based on this text in 4.4.9: >> The use of this AVP is NOT RECOMMENDED; the AVPs defined by >> Korhonen, et al. [RFC5777] SHOULD be used instead. >> >> I would have expected RFC5777 to be a Normative Reference, not an >> Informative Reference. > > I don't care particularly, but I don't think that it's really necessary to > understand RFC 5777 to understand this document. It would seem odd, in general, if something that's a "MUST implement" or "SHOULD implement" weren't a normative reference. But I haven't (yet) looked at this particular case to see. Barry From dimeg@intracom.gr Mon Oct 8 16:02:24 2012 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 A78EE1F0417 for ; Mon, 8 Oct 2012 16:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVMutRuPEE65 for ; Mon, 8 Oct 2012 16:02:24 -0700 (PDT) Received: from extmail.intranet.gr (extmail.intranet.gr [192.92.155.11]) by ietfa.amsl.com (Postfix) with ESMTP id A0C5721F84C5 for ; Mon, 8 Oct 2012 16:02:23 -0700 (PDT) Received: from mailserv.intranet.gr (mailserv.intranet.GR [146.124.14.106]) by extmail.intranet.gr (8.14.5/8.14.5) with ESMTP id q98N2A0Z016473 for ; Tue, 9 Oct 2012 02:02:16 +0300 (EEST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id q98N2Arf002337 for ; Tue, 9 Oct 2012 02:02:10 +0300 (EEST) Received: from webmail.intracom-telecom.com (cricket-in.intranet.gr [146.124.112.130]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id q98N27wR002328 for ; Tue, 9 Oct 2012 02:02:08 +0300 (EEST) Received: from 146.124.112.65 (SquirrelMail authenticated user dimeg) by cricketb2b.intranet.gr with HTTP; Tue, 9 Oct 2012 01:58:13 +0300 (EEST) Message-ID: <61256.146.124.112.65.1349737093.squirrel@cricketb2b.intranet.gr> Date: Tue, 9 Oct 2012 01:58:13 +0300 (EEST) From: "Gerasimos Dimitriadis" To: dime@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-7 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [Dime] Failed-AVP and structural validity X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2012 23:05:57 -0000 Hi all, I'd like to ask a couple of questions regarding the encoding of the Failed-AVP AVP, in case of invalid AVP lengths. Actually, both questions stem from the same root, which is: How hard should the encoder of the Failed-AVP try, so that the structure of the Failed-AVP is valid? The RFC 3588 bis document states that when a Grouped AVP has an invalid AVP length, "the grouped AVP header with an empty payload would be sufficient to indicate the offending AVP". In such a case, does the grouped AVP header length need to be adjusted so that a valid structure is maintained, or should the offending AVP header be copied as-is from the original octet stream? A similar question is how to handle cases where the AVP length is below a minimum or exceeds the message length. After appending to the header a number of zero octets as payload, should the AVP header length be accordingly adjusted? The dilemma I am facing now is the one below: By reading the RFC, I tend to believe that such adjustments are not required (especially since they would hinder pinpointing the offending AVP). On the other hand, I don't feel very confident and fear that maybe this way an error is not just reported, but rather a wholy faulty message is generated back. Since the definition of the Fauly-AVP is: ::= < AVP Header: 279 > 1* {AVP} it doesn't seem that unreasonable to have a Failed-AVP that is structurally sound. Because of all the above, I would really appreciate your feedback on this matter. Thank you very much in advance and Best Regards, Gerasimos From david.black@emc.com Mon Oct 8 13:11:56 2012 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 A918E21F87F9; Mon, 8 Oct 2012 13:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x26clcZ4oPbd; Mon, 8 Oct 2012 13:11:56 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BA61821F8702; Mon, 8 Oct 2012 13:11:55 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q98KBlHj021251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Oct 2012 16:11:48 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 8 Oct 2012 16:11:43 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q98KBeoH030012; Mon, 8 Oct 2012 16:11:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Mon, 8 Oct 2012 16:11:41 -0400 From: "Black, David" To: Barry Leiba , Glen Zorn , "precis-chairs@tools.ietf.org" Date: Mon, 8 Oct 2012 16:11:39 -0400 Thread-Topic: Gen-ART review of draft-ietf-dime-rfc4005bis-11 Thread-Index: Ac2leMQ+3QDh/2XtR/iDfUkrQqimgwAFfE4Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DF11C12@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> <50712F0A.1050309@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Mon, 08 Oct 2012 22:33:57 -0700 Cc: "dime-chairs@tools.ietf.org" , "gen-art@ietf.org" , "draft-ietf-dime-rfc4005bis@tools.ietf.org" , "dime@ietf.org" , "Black, David" , "ietf@ietf.org" Subject: Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2012 20:11:56 -0000 Barry, > >> 5) Statement that the string contains an FQDN, as stated for one case = of > >> the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is > >> incomplete, as it needs to be accompanied by a normative reference to > >> a document that specifies the format of internationalized domain > >> names, and probably needs to also state which types of labels (e.g., > >> A-label, U-label) are allowed. > >> > >> Every use of UTF8String in this draft needs to be checked, and most > >> of them are likely to need some attention. The ongoing work in the > >> precis WG may help with some of this, and I would suggest talking to > >> the APP ADs, especially Pete Resnick (hi Pete) before embarking on > >> significant work in this area in order to avoid wasted or duplicated > >> efforts. > > > > OK, this last one bothers me a lot: you /seem /to be suggesting that we= hold > > up this draft to wait for the result of a WG which has yet to publish a > > problem statement. I'm sure that that is not the case, but it sure sou= nds > > like it. >=20 > David can clarify if I'm wrong, but that's not what it sounds like to > me. What it sounds like he's suggesting is that you talk with the > precis people to see if things are OK, or if there's anything you > should be doing differently. I'm adding the precis chairs to this > message, and asking them to respond to this point. It's somewhere in between, as things are definitely *not* OK at the moment, but my reason for suggesting a discussion with the pr=E9cis folks is to tak= e advantage of their insights and work to date. If I thought this draft need= ed to wait for the output of the pr=E9cis WG, I would have indicated which pr= =E9cis draft ought to be a normative reference (and I did not do that). Whether that's a good idea will only be clear after every use of UTF8String is chec= ked. FWIW, the FQDN situation is worked out, start with a normative reference to RFC 5890, which includes the specification of the various label types. > A tangential point, while I'm here: >=20 > >> [4] Based on this text in 4.4.9: > >> The use of this AVP is NOT RECOMMENDED; the AVPs defined by > >> Korhonen, et al. [RFC5777] SHOULD be used instead. > >> > >> I would have expected RFC5777 to be a Normative Reference, not an > >> Informative Reference. > > > > I don't care particularly, but I don't think that it's really necessary= to > > understand RFC 5777 to understand this document. >=20 > It would seem odd, in general, if something that's a "MUST implement" > or "SHOULD implement" weren't a normative reference. But I haven't > (yet) looked at this particular case to see. My expectation is the same - if [RFCxxxx] is specified as "MUST implement" or "SHOULD implement", then I usually expect that RFC to be a normative reference. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Mon Oct 8 13:53:17 2012 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 EBEA011E80F1; Mon, 8 Oct 2012 13:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPELdoa54pNm; Mon, 8 Oct 2012 13:53:16 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AF71A11E80F0; Mon, 8 Oct 2012 13:53:16 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q98KrEHS006683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Oct 2012 16:53:14 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 8 Oct 2012 16:52:59 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q98KqwFY017595; Mon, 8 Oct 2012 16:52:58 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Mon, 8 Oct 2012 16:52:58 -0400 From: "Black, David" To: Glen Zorn Date: Mon, 8 Oct 2012 16:52:56 -0400 Thread-Topic: Gen-ART review of draft-ietf-dime-rfc4005bis-11 Thread-Index: Ac2kXoeQSUAX8En/RPGw5bTX7IkshwBMzE7Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DF11C25@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> <50712F0A.1050309@gmail.com> In-Reply-To: <50712F0A.1050309@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Mon, 08 Oct 2012 22:33:57 -0700 Cc: "ietf@ietf.org" , "draft-ietf-dime-rfc4005bis@tools.ietf.org" , "gen-art@ietf.org" , "dime@ietf.org" , "Black, David" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2012 20:53:18 -0000 Glen, Picking up the topics that weren't in Barry's email ... > > 1) String preparation so that tests for equality work as expected. > > This may suffice for the Called-Station-ID AVP (4.2.5) and > > Calling-Station-ID AVP (4.2.6) if the internal structure of those > > strings is not used in authorization. >=20 > Both those AVPs are specified to contain ASCII encoded as UTF-8. Is > string preparation necessary in that case? Not in the full glory that is needed for serious usage of UTF-8, but it looks like the language in the draft should be tightened. At a minimum, a "MUST" is in order to require use of 7-bit ASCII encoded as UTF-8. Among the reasons for such a requirement is to prohibit the various ISO/IEC 8859-* character sets (a/k/a Latin-*), which are 8-bit ASCII and not distinguishable from each other on the wire without an additional character set tag of some form. I would also suggest forbidding control characters (e.g., require displayable 7-bit ASCII characters) and saying something about case handling, starting with whether the strings are case sensitive or case insensitive. Case sensitivity is simpler to specify, but may not yield intuitive and/or expected results. If the strings are case insensitive, text should be added to say whether the strings are case-normalized on the wire and/or whether the recipient is expected to implement case- insensitive string comparison. > > 2) Detailed string format for a > > string that is processed by a protocol participant, e.g., the > > Callback-ID AVP (4.4.3). >=20 > That format is unknown in this case. Please explain how that's supposed to result in interoperable processing by the "protocol participant". > > [1] End of Section 2 on p.8: > > > > As a result, service cannot be started as a result of a response to > > an authorization-only request without introducing a significant > > security vulnerability. > > > > Please explain what to do about this - a simple rewrite with a > > "SHOULD NOT" would suffice, e.g.: > > > > As a result, service SHOULD NOT be started as a result of a response > > to an authorization-only request because that may introduce a > > significant security vulnerability. >=20 > The text in question is descriptive, not prescriptive. That said, however= , > I think that it's not really clear. I think that it should say > something like "As a result, a new session cannot be started as a result > of a response to an authorization-only request without introducing a > significant security vulnerability." >=20 > > > > This should also be noted in the Security Considerations section. The rewrite helps, and make sure to add text about this in the Security Considerations section. > > =3D=3D Missing Reference: 'BASE' is mentioned on line 219, but not > > defined > > > > That's definitely a problem. Was [I-D.ietf-dime-rfc3588bis] > > intended? >=20 > No. The passage in question is a verbatim quote from RFC 4005. Ok, just fix this so idnits can find something else to complain about :-). Thanks, --David > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@gmail.com] > Sent: Sunday, October 07, 2012 3:28 AM > To: Black, David > Cc: glenzorn@gmail.com; lionel.morand@orange.com; gen-art@ietf.org; dime- > chairs@tools.ietf.org; draft-ietf-dime-rfc4005bis@tools.ietf.org; > ietf@ietf.org; dime@ietf.org; Benoit Claise > Subject: Re: Gen-ART review of draft-ietf-dime-rfc4005bis-11 >=20 > On 09/18/2012 06:53 AM, Black, David wrote: >=20 > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > . > > > > Please resolve these comments along with any other Last Call > > comments you may receive. > > > > Document: draft-ietf-dime-rfc4005bis-11 Reviewer: David L. Black > > Review Date: September 17, 2012 IETF LC End Date: September 18, 2012 > > IESG Telechat date: (if known) > > > > Summary: > > > > This draft is on the right track but has open issues, described in > > the review. > > > > This draft is part of a set of drafts that updates the DIAMETER > > protocol; this draft specifies the application of DIAMETER to AAA for > > network access. The draft is heavily based on RFC 4005, which it > > obsoletes, and requires significant DIAMETER familiarity (including > > familiarity with its companion drafts, starting with the rfc3588bis > > draft) for complete understanding. > > > > The draft is in good shape and reads well. I found one major open > > issue, a few minor issues, and several nits. > > > > Major issues: > > > > This draft makes significant use of UTF-8 in its formats (some > > subsections of sections 4.2, 4.4 and 4.5) for strings that are > > intended to be compared for equality or processed by protocol > > participants, but does not contain considerations for Unicode > > processing that are sufficient to support this usage. Examples of > > UTF-8 usage in this draft include: > > > > - 4.2.5 and 4.2.6: The NAS server may perform authorization based on > > the Called-Station-Id and Calling-Station-Id AVPs under some > > circumstances. - 4.4.3: The Callback-Id AVP is intended to be > > interpreted by the NAS. > > > > All use of UTF-8 in this draft relies upon the specification of the > > UTF8String format in the rfc3588bis draft. That specification is > > insufficient to support the usage in the above examples, and there > > are no Unicode considerations in this draft. Even binary comparison > > of Unicode strings for equality generally requires specification of > > string preparation (e.g., normalization) in order for string > > comparison to work as expected. > > > > The variety of Unicode strings in this draft makes it important to > > lay out the Unicode requirements and considerations for each AVP. I > > see at least 5 classes of possible Unicode > > requirements/considerations: > > > > 1) String preparation so that tests for equality work as expected. > > This may suffice for the Called-Station-ID AVP (4.2.5) and > > Calling-Station-ID AVP (4.2.6) if the internal structure of those > > strings is not used in authorization. >=20 > Both those AVPs are specified to contain ASCII encoded as UTF-8. Is > string preparation necessary in that case? >=20 > > 2) Detailed string format for a > > string that is processed by a protocol participant, e.g., the > > Callback-ID AVP (4.4.3). >=20 > That format is unknown in this case. > ... > > 5) Statement that the string contains an FQDN, as stated for one case = of > > the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is > > incomplete, as it needs to be accompanied by a normative reference to > > a document that specifies the format of internationalized domain > > names, and probably needs to also state which types of labels (e.g., > > A-label, U-label) are allowed. > > > > Every use of UTF8String in this draft needs to be checked, and most > > of them are likely to need some attention. The ongoing work in the > > precis WG may help with some of this, and I would suggest talking to > > the APP ADs, especially Pete Resnick (hi Pete) before embarking on > > significant work in this area in order to avoid wasted or duplicated > > efforts. >=20 > OK, this last one bothers me a lot: you /seem /to be suggesting that we > hold up this draft to wait for the result of a WG which has yet to > publish a problem statement. I'm sure that that is not the case, but it > sure sounds like it. >=20 > > > > Minor Issues: > > > > [1] End of Section 2 on p.8: > > > > As a result, service cannot be started as a result of a response to > > an authorization-only request without introducing a significant > > security vulnerability. > > > > Please explain what to do about this - a simple rewrite with a > > "SHOULD NOT" would suffice, e.g.: > > > > As a result, service SHOULD NOT be started as a result of a response > > to an authorization-only request because that may introduce a > > significant security vulnerability. >=20 > The text in question is descriptive, not prescriptive.at said, however, > I think that it's not really clear. I think that it should say > something like "As a result, a new session cannot be started as a result > of a response to an authorization-only request without introducing a > significant security vulnerability." >=20 > > > > This should also be noted in the Security Considerations section. > > > > [2] In the message formats in Section 3, QoS-Filter-Rule is > > inconsistently capitalized. >=20 > OK, thanks. >=20 > > Also the use of QoSFilterRule as the > > format for the QoS-Filter-Rule AVP in Section 4.1.1 is potentially > > confusing. Please add a sentence in 4.1.1 to say that QoSFilterRule > > is the format for the QoS-Filter-Rule AVP. > > > > [3] Section 4.2.1. In this and the other AVP Flag Rules tables, > > please explain what the values in the MUST and MUST NOT columns > > mean. > > > > [4] Based on this text in 4.4.9: > > > > The use of this AVP is NOT RECOMMENDED; the AVPs defined by > > Korhonen, et al. [RFC5777] SHOULD be used instead. > > > > I would have expected RFC5777 to be a Normative Reference, not an > > Informative Reference. >=20 > I don't care particularly, but I don't think that it's really necessary > to understand RFC 5777 to understand this document. >=20 > > > > Nits/editorial comments: > > > > After the command table in Section 3 and other similar tables, please > > add a sentence to say that the -Request and -Answer commands in each > > similarly-named command pair are distinguished by the value of the > > 'R' bit in the Command Flags field of the command. This is already > > stated in the command definitions, but the sentence should be added > > after the table for clarity because each command pair shares a > > Command Code. > > > > idnits 2.12.13 found a few potential nits: > > > > =3D=3D There are 7 instances of lines with non-RFC5735-compliant IPv4 > > addresses in the document. If these are example addresses, they > > should be changed. > > > > That can probably be ignored, as these instances are likely generated > > by text such as cross-references to Section 4.4.10.1 > > > > =3D=3D Missing Reference: 'BASE' is mentioned on line 219, but not > > defined > > > > That's definitely a problem. Was [I-D.ietf-dime-rfc3588bis] > > intended? >=20 > No. The passage in question is a verbatim quote from RFC 4005. >=20 > > > > -- Possible downref: Non-RFC (?) normative reference: ref. > > 'ANITypes' > > > > That reference would be: > > > > [ANITypes] NANPA Number Resource Info, "ANI Assignments", > > > ani_ii_assignments.html>. > > > > Is that reference sufficiently stable (e.g., IANA-class or better > > management)? >=20 > Yes, I think so. >=20 > > My guess is that it is sufficiently stable, but I'm not > > the expert. > > > > -- Obsolete informational reference (is this intentional?): RFC 1334 > > (Obsoleted by RFC 1994) > > > > That reference may be intentional, >=20 > Yes. >=20 > ... From ben@nostrum.com Fri Oct 12 14:31:50 2012 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 22ACE21F8749 for ; Fri, 12 Oct 2012 14:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isbzPro-G6WT for ; Fri, 12 Oct 2012 14:31:49 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 81FEB21F86A8 for ; Fri, 12 Oct 2012 14:31:43 -0700 (PDT) Received: from [172.20.10.2] (mobile-166-147-066-241.mycingular.net [166.147.66.241]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9CLVf3e042823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Oct 2012 16:31:42 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <23BF52E0-3F6A-4873-89A5-09D91E5D1C08@nostrum.com> Date: Fri, 12 Oct 2012 16:31:20 -0500 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 166.147.66.241 is authenticated by a trusted mechanism) Subject: [Dime] 3588bis question: DIAMETER_INVALID_BIT_IN_HEADER X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2012 21:31:50 -0000 Hi, I notice that 3588bis changed in the description of = DIAMETER_INVALID_BIT_IN_HEADER to the following: > This error is returned when a reserved bit in the Diameter header > is set to one (1) or the bits in the Diameter header are set > incorrectly. >=20 Wouldn't the usage in the first clause violate this normative statement = in section 3? > These flag bits are reserved for future use, and MUST be set to > zero, and ignored by the receiver. =20 Thanks! Ben.= From jouni.nospam@gmail.com Wed Oct 17 00:23:32 2012 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 E973921F851B for ; Wed, 17 Oct 2012 00:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmvDKWLWiiY8 for ; Wed, 17 Oct 2012 00:23:32 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 129D021F8518 for ; Wed, 17 Oct 2012 00:23:31 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so4194229eek.31 for ; Wed, 17 Oct 2012 00:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5puupinwKrzeBNF7GBm5peSPPaBo+LbkKkOzvvYSsBs=; b=Gj8B+6GjF93XXPmWpKPTgrTwcuY4fZlFXez+ggsj01FrpRfINAXXcIFufhoq8dt7Hx PXf7TdXyFcuTB21jd8dK+XM8DmtQS2DI5Ml0cSFsrmLSLUpYkf5kDnqtC4SW5KA5tgL4 4CaAN3xUgvgMfZHpQS+13uqIRLdn23Ff+51yAe/CwLTvuSYPuB9+2kDTYzdgkK3XaB5p C7t4O8m5nPaeTNGXATmn53sV6dR5ACB9Fp23O0zN3ohBOgX3G9smr4BrB8ek4m7KzQnH rKsR7lzz5ZxzNZvtJ8bYfB5q1vQe3ULJO5M3VUQchwKc+TCS5iZiWWP/HN6bELmPwD/B htXw== Received: by 10.14.199.132 with SMTP id x4mr25411565een.37.1350458610987; Wed, 17 Oct 2012 00:23:30 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id 7sm33477130eeg.5.2012.10.17.00.23.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Oct 2012 00:23:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <18B3378F-8296-4A85-9963-E74FACF25D13@gmail.com> Date: Wed, 17 Oct 2012 10:23:18 +0300 Content-Transfer-Encoding: 7bit Message-Id: <2C7E4F72-A26B-486A-9FD2-857131246EB2@gmail.com> References: <18B3378F-8296-4A85-9963-E74FACF25D13@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] Dime WG meeting in Atlanta X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 07:23:33 -0000 FYI - just a reminder. On Oct 4, 2012, at 11:45 PM, jouni korhonen wrote: > Folks, > > We have been scheduled a 2h slot (object to change the date & time) > > dime Session 1 (2:00:00) > Monday, Afternoon Session I 1300-1500 > Room Name: Room 209 > > > If you feel like presenting something, send the co-chair a mail with the > topic, estimated airtime and why you think it needs to get a slot. > > - Jouni From internet-drafts@ietf.org Sun Oct 21 15:36:28 2012 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 9180721F8A22; Sun, 21 Oct 2012 15:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEogeKtkv9q1; Sun, 21 Oct 2012 15:36:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0E621F88F3; Sun, 21 Oct 2012 15:36:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121021223628.25188.48084.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 15:36:28 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 22:36:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-16.txt Pages : 30 Date : 2012-10-21 Abstract: The Diameter Base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend the Diameter base protocol. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lionel.morand@orange.com Sun Oct 21 15:43:48 2012 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 128E621F8917 for ; Sun, 21 Oct 2012 15:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq1fdDWui0DI for ; Sun, 21 Oct 2012 15:43:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id CF49321F8928 for ; Sun, 21 Oct 2012 15:43:46 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5B03218C225; Mon, 22 Oct 2012 00:43:45 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 404D535C048; Mon, 22 Oct 2012 00:43:45 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 22 Oct 2012 00:43:44 +0200 From: To: "dime@ietf.org" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-app-design-guide-16.txt Thread-Index: AQHNr9yFcUzourmsJ0CRListzUAyV5fEWdJQ Date: Sun, 21 Oct 2012 22:43:43 +0000 Message-ID: <22330_1350859425_50847AA1_22330_11416_1_6B7134B31289DC4FAF731D844122B36E07DF55@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20121021223628.25188.48084.idtracker@ietfa.amsl.com> In-Reply-To: <20121021223628.25188.48084.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.21.193350 Subject: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 22:43:48 -0000 Hi, This version takes into account the comments received after the detailed re= view of Jean and Ben during the WGLC. Modifications are mainly editorial and some clarifications have been added,= especially on the use of E2E capabilities exchange AVPs. No further comment was received. I think that this document can be moved to IETF LC for publication. Regards, Lionel=20 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de i= nternet-drafts@ietf.org Envoy=E9=A0: lundi 22 octobre 2012 00:36 =C0=A0: i-d-announce@ietf.org Cc=A0: dime@ietf.org Objet=A0: [Dime] I-D Action: draft-ietf-dime-app-design-guide-16.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-16.txt Pages : 30 Date : 2012-10-21 Abstract: The Diameter Base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend the Diameter base protocol. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-16 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From alper.yegin@yegin.org Mon Oct 22 03:07:09 2012 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 F3E6021F8B03; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+Y3biSGU7iN; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7300621F89EC; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LyEBR-1TKh2J2VdN-015PtV; Mon, 22 Oct 2012 06:07:04 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 22 Oct 2012 13:06:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:jhPbu8Oj6KWdzEYlfaIoDuhMQrjQ4xqCIECf2LoJGHC +j92+N5fqRsq9PwkP2R9BgB9MBkY/UfKFRuAWYkQHPPxCQBeux S/qbKOoJfCbin68fVU9oj2GlNVMFL+D0SvKVJXAzb3RlCdqhwy fzyLvZDYVdO0j1hqlpBclxtSAmdQp+O/UMIYrpKIDgxrxmGR3Y 4hWfzq3YQkSaJkp5Hu/Lbed6cvNnKqApL5QFmiKdJMQbA/ad7Q gAZsTueGuzReLWEFUG5SjkgM2kA+oUGY/QoLLwm9HrrldUEc3A 0o+jMZC3e2bi2PNp7gdd2zr+CQtCanhM8XAoHhZaeJCD8ttiu+ sgIPEUJADxvn0dVl+3gxk0aJv2ewI3Sega2F2dfNss8V/mMZX2 wqfjjYMqw6qjw== Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, "Zhangdacheng \(Dacheng\)" , dime@ietf.org, eap@frascone.com Subject: [Dime] Tweaking EAP (RFC 3748) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2012 10:07:09 -0000 On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> Hi Sam, Please also share this discussion with EAP WG and = EMU > Alper> WG mailing lists. That's where the EAP expertise is and they > Alper> should chime in, given that you are proposing to modify EAP > Alper> applicability statement. >=20 > The eap applicability statement update is a charter item of > ABFAB. We've agreed it will be last called in EMU. > Since it's a work item of abfab, it should be discussed on that list. > You're certainly free to let people know that the discussion if taking > place, although we've done that several times before. Sam, The type of changes you are talking about are well beyond the = "applicability statement changes" that ABFAB is chartered to make. Now you are discussing how EAP can be executed in a client-driven style = (as opposed to network driven), how server-initiated EAP = re-authentication may not be supported, how authorization parameters = (especially the session lifetime) is not set by the AAA server.=20 We need EAP and AAA expertise to get involved in the discussion. Not = only when ABFAB WG thinks it is done, but especially from the get go. This, IMHO, is re-engineering EAP and associated AAA procedures. Alper From hartmans@painless-security.com Mon Oct 22 05:51:02 2012 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 38F0821F8A87; Mon, 22 Oct 2012 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.909 X-Spam-Level: X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[AWL=3.508, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrcmBfjH27p0; Mon, 22 Oct 2012 05:51:01 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29921F8842; Mon, 22 Oct 2012 05:51:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1A7632026C; Mon, 22 Oct 2012 08:50:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B5CB4AD5; Mon, 22 Oct 2012 08:50:56 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> Date: Mon, 22 Oct 2012 08:50:56 -0400 In-Reply-To: <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> (Alper Yegin's message of "Mon, 22 Oct 2012 13:06:40 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 22 Oct 2012 05:57:02 -0700 Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, "Zhangdacheng \(Dacheng\)" , dime@ietf.org, eap@frascone.com Subject: Re: [Dime] Tweaking EAP (RFC 3748) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2012 12:51:02 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >>>>>> "Alper" == Alper Yegin writes: >> Alper> Hi Sam, Please also share this discussion with EAP WG and EMU Alper> WG mailing lists. That's where the EAP expertise is and they Alper> should chime in, given that you are proposing to modify EAP Alper> applicability statement. >> >> The eap applicability statement update is a charter item of >> ABFAB. We've agreed it will be last called in EMU. Since it's a >> work item of abfab, it should be discussed on that list. You're >> certainly free to let people know that the discussion if taking >> place, although we've done that several times before. Alper> Sam, Alper> The type of changes you are talking about are well beyond the Alper> "applicability statement changes" that ABFAB is chartered to Alper> make. First, I definitely encourage you to involve anyone in any IETF WG discussion you believe will help form a better consensus. So, absolutely, encourage people who you believe should join the discussion to do so. I am a bit confused by your message, because I'm not discussing changing EAP, only discussing how some issues that seem relatively likely to come up will influence applying EAP authentication to application authentication. My intent is to document existing, potentially hard to understand aspects of EAP so that people can better apply EAP to their applications. Thanks, --Sam From internet-drafts@ietf.org Mon Oct 22 07:34:22 2012 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 9D97C21F8980; Mon, 22 Oct 2012 07:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3BptjefHg9C; Mon, 22 Oct 2012 07:34:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D5621F898B; Mon, 22 Oct 2012 07:34:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022143421.8302.86211.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 07:34:21 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-erp-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2012 14:34:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Support for the EAP Re-authentication Protocol = (ERP) Author(s) : Julien Bournelle Lionel Morand Sebastien Decugis Qin Wu Glen Zorn Filename : draft-ietf-dime-erp-13.txt Pages : 16 Date : 2012-10-22 Abstract: The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-erp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-erp-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-erp-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 08:01:05 2012 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 23DAB21F8C2C; Mon, 22 Oct 2012 08:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTehzsYDq+m0; Mon, 22 Oct 2012 08:01:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895ED21F8C24; Mon, 22 Oct 2012 08:01:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022150104.31151.34736.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 08:01:04 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-erp-14.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2012 15:01:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Support for the EAP Re-authentication Protocol = (ERP) Author(s) : Julien Bournelle Lionel Morand Sebastien Decugis Qin Wu Glen Zorn Filename : draft-ietf-dime-erp-14.txt Pages : 16 Date : 2012-10-22 Abstract: The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-erp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-erp-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-erp-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adam@nostrum.com Mon Oct 22 14:52:39 2012 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 C586011E80AD for ; Mon, 22 Oct 2012 14:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1c3zQsVwbHh for ; Mon, 22 Oct 2012 14:52:37 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0321F88BE for ; Mon, 22 Oct 2012 14:52:31 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9MLqSMe090667 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 22 Oct 2012 16:52:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5085C01C.4000900@nostrum.com> Date: Mon, 22 Oct 2012 16:52:28 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "DIME (Diameter Maintenance and Extensions) WG" References: <20121022214256.15618.66760.idtracker@ietfa.amsl.com> In-Reply-To: <20121022214256.15618.66760.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121022214256.15618.66760.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070302010909070507030404" Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2012 21:52:39 -0000 This is a multi-part message in MIME format. --------------070302010909070507030404 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DIME working group: I have submitted a new version of the Diameter Overload document, based on early feedback on the -00 version. Please use the "Diff" link, below, for a comprehensive accounting of differences. At a high level, the main changes are: - Only one scope (Host) is mandatory any longer. Others are "SHOULD-level." - Scope negotiation has been replaced by supported scope announcement. This allows for asymmetric scopes in a connection. - "Host" scope has been renamed "Destination Host" scope to clarify that it does not refer to the sending host. - A new "Appendix D" has been added to discuss some of the design tradeoffs currently present in the document. I plan to discuss this -01 version during the upcoming meeting in Atlanta. Thanks! /a -------- Original Message -------- Subject: New Version Notification for draft-roach-dime-overload-ctrl-01.txt Date: Mon, 22 Oct 2012 14:42:56 -0700 From: internet-drafts@ietf.org To: adam@nostrum.com A new version of I-D, draft-roach-dime-overload-ctrl-01.txt has been successfully submitted by Adam Roach and posted to the IETF repository. Filename: draft-roach-dime-overload-ctrl Revision: 01 Title: A Mechanism for Diameter Overload Control Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 38 URL: http://www.ietf.org/internet-drafts/draft-roach-dime-overload-ctrl-01.txt Status: http://datatracker.ietf.org/doc/draft-roach-dime-overload-ctrl Htmlized: http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-roach-dime-overload-ctrl-01 Abstract: When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce or stop sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages. This document proposes a concrete, application-independent mechanism to address the challenge of communicating load and overload state among Diameter peers, and specifies an algorithm for load abatement to address such overload conditions as they occur. The load abatement algorithm is extensible, allowing for future documents to define additional load abatement approaches. The IETF Secretariat --------------070302010909070507030404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit DIME working group:

I have submitted a new version of the Diameter Overload document, based on early feedback on the -00 version. Please use the "Diff" link, below, for a comprehensive accounting of differences. At a high level, the main changes are:

- Only one scope (Host) is mandatory any longer. Others are "SHOULD-level."
- Scope negotiation has been replaced by supported scope announcement. This allows for asymmetric scopes in a connection.
- "Host" scope has been renamed "Destination Host" scope to clarify that it does not refer to the sending host.
- A new "Appendix D" has been added to discuss some of the design tradeoffs currently present in the document.

I plan to discuss this -01 version during the upcoming meeting in Atlanta.

Thanks!

/a


-------- Original Message --------
Subject: New Version Notification for draft-roach-dime-overload-ctrl-01.txt
Date: Mon, 22 Oct 2012 14:42:56 -0700
From: internet-drafts@ietf.org
To: adam@nostrum.com 


A new version of I-D, draft-roach-dime-overload-ctrl-01.txt
has been successfully submitted by Adam Roach and posted to the
IETF repository.

Filename:	 draft-roach-dime-overload-ctrl
Revision:	 01
Title:		 A Mechanism for Diameter Overload Control
Creation date:	 2012-10-22
WG ID:		 Individual Submission
Number of pages: 38
URL:             http://www.ietf.org/internet-drafts/draft-roach-dime-overload-ctrl-01.txt
Status:          http://datatracker.ietf.org/doc/draft-roach-dime-overload-ctrl
Htmlized:        http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-roach-dime-overload-ctrl-01

Abstract:
   When a Diameter server or agent becomes overloaded, it needs to be
   able to gracefully reduce its load, typically by informing clients to
   reduce or stop sending traffic for some period of time.  Otherwise,
   it must continue to expend resources parsing and responding to
   Diameter messages.

   This document proposes a concrete, application-independent mechanism
   to address the challenge of communicating load and overload state
   among Diameter peers, and specifies an algorithm for load abatement
   to address such overload conditions as they occur.  The load
   abatement algorithm is extensible, allowing for future documents to
   define additional load abatement approaches.

                                                                                  


The IETF Secretariat



--------------070302010909070507030404-- From alper.yegin@yegin.org Tue Oct 23 01:09:16 2012 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 65D0321F8464; Tue, 23 Oct 2012 01:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leU1FS7HICmv; Tue, 23 Oct 2012 01:09:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4975921F84B1; Tue, 23 Oct 2012 01:09:14 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MKHde-1TOvdh1gIA-0025Fn; Tue, 23 Oct 2012 04:08:33 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Tue, 23 Oct 2012 11:08:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <47A4DA97-971F-4292-98D7-FF28A9CAB88C@yegin.org> References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:8yeC5v3uIkV11ucL5pEiYfjPbV6/f2fypAHjb2NVST0 geVIFTCbBDuhj83eim+SDdQjIgI0l/jpj11Txyi29qmH2IUgE+ dFVlITB/0YnWBWB1ka7vA9+M/gOi51biZf7CMVDx5AXttz193s j+M+9Ttd4QzlsiXuaHFWoeZUFCYHqkeaW3paXuHGFsVW5invpU GkzPw2V1niY2lJDeiEEXXoMIWHk84gdMioEHMcQYBomxXdj9zV Fv/Ea24uMFyXjYRBZSSiGi8cCGkt+ZuCvod+HoW8/I8qWzDlTe xCbNdLp8OOj8Fu7dbI16+NOLK9FcA+c5LEU5kj1rh48NcMUz/7 lDU8dcAf0b1s6PzeC+mOfIhDo8hV7D0stM/pJmxK8gHmyFbtFG SRXPZ2frzcwHw== Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, "Zhangdacheng \(Dacheng\)" , dime@ietf.org, eap@frascone.com Subject: Re: [Dime] [radext] Tweaking EAP (RFC 3748) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2012 08:09:16 -0000 >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >=20 >>>>>>> "Alper" =3D=3D Alper Yegin writes: >>>=20 > Alper> Hi Sam, Please also share this discussion with EAP WG and = EMU > Alper> WG mailing lists. That's where the EAP expertise is and they > Alper> should chime in, given that you are proposing to modify EAP > Alper> applicability statement. >>>=20 >>> The eap applicability statement update is a charter item of >>> ABFAB. We've agreed it will be last called in EMU. Since it's a >>> work item of abfab, it should be discussed on that list. You're >>> certainly free to let people know that the discussion if taking >>> place, although we've done that several times before. >=20 > Alper> Sam, >=20 > Alper> The type of changes you are talking about are well beyond = the > Alper> "applicability statement changes" that ABFAB is chartered to > Alper> make. =20 >=20 > First, I definitely encourage you to involve anyone in any IETF WG > discussion you believe will help form a better consensus. > So, absolutely, encourage people who you believe should join the > discussion to do so. >=20 Good. Please remember to keep these groups updated as you progress the = discussion. > I am a bit confused by your message, because I'm not discussing = changing > EAP, only discussing how some issues that seem relatively likely to = come > up will influence applying EAP authentication to application > authentication. I captured the issues you are raising as below: > how EAP can be executed in a client-driven style (as opposed to = network driven), how server-initiated EAP re-authentication may not be = supported, how authorization parameters (especially the session = lifetime) is not set by the AAA server.=20 These have potential impact on the EAP layer, and EAP lower-layer (both = the EAP peer to EAP Authenticator leg, and the EAP Authenticator to EAP = Authentication Server leg [a.k.a, the AAA protocol]). We need to fully = understand the implications. These are not mere "applicability" issues.=20= The ABFAB applicability update in my understanding is nothing more than = removing the somewhat artificial constraints in RFC 3748 that was = blocking the use of EAP for anything other than network access = authentication. The types of issues you are discussing now are well = beyond that. > My intent is to document existing, potentially hard to understand > aspects of EAP so that people can better apply EAP to their > applications. >=20 Alper > Thanks, >=20 > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Tue Oct 23 03:20:16 2012 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 3C8EB21F86B3 for ; Tue, 23 Oct 2012 03:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYdPW-pcfTYS for ; Tue, 23 Oct 2012 03:20:15 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 482DD21F86B1 for ; Tue, 23 Oct 2012 03:20:15 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2234628wey.31 for ; Tue, 23 Oct 2012 03:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=3QGP5guiR5YT15m+6Mfxnr3dST/na3yl90j9Zq/ssKw=; b=KPfnP24969FzceMejqWotZKPDzW5t5fssVxb63r6tTNzeGAKAl44WeCP0RZ4LrmTE2 koMW7ViHAB7F6BvY6j8cdfGQ/dbqZ4yPl51m0pKChuBHH89hsfSPugN3kVjDuszTCGOm mKKTpHN/7WEIilEZIV6gqkDCyeiVz/mIIkw0uJJpnLbTFBfD3Srp1xhhB/+LYL/rr4ma yg+Xec4Bs9birAc0EO8pnBeM5hDNLyozUPK1tdZQWfdhtYMFEYaXTQ8plyau0h2/OyK0 d4MG/tA9M48OaUwyUh41bj2I2JYcJbt7PGpoOedz+gkNcqfwvOa3Cng5QjS3KW/qt8lm Hkgg== Received: by 10.180.84.202 with SMTP id b10mr27952741wiz.13.1350987614475; Tue, 23 Oct 2012 03:20:14 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id gg4sm27085466wib.6.2012.10.23.03.20.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 03:20:13 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 23 Oct 2012 13:20:10 +0300 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Preliminary draft agenda.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2012 10:20:16 -0000 Folks, Below is a very drafty draft agenda for the Dime meeting in Atlanta. We encourage people to read the documents on both "main topics": Diameter overload control and e2e security. Both are now getting hot topics among our customer SDOs.. - Jouni & Lionel ----- DIME WG IETF 85: 120 min total Chairs o Agenda and WG update 15 min Diameter overload control: Eric McMurry o draft-ietf-dime-overload-reqs 15 min Adam Roach o draft-roach-dime-overload-ctrl 30 min Jouni Korhonen o draft-korhonen-dime-ovl 20 min Buffer for discussion 15 min Diameter e2e security: Jouni Korhonen o draft-korhonen-dime-e2e-security 15 min Buffer for discussion 10 min From ben@nostrum.com Tue Oct 23 07:01:45 2012 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 6FDBD11E80A6 for ; Tue, 23 Oct 2012 07:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8OYtAeN-Opq for ; Tue, 23 Oct 2012 07:01:44 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B700C11E80BA for ; Tue, 23 Oct 2012 07:01:44 -0700 (PDT) Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9NE1c2N097959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Oct 2012 09:01:39 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Tue, 23 Oct 2012 09:01:39 -0500 Content-Transfer-Encoding: 7bit Message-Id: <349791D5-EC6A-42ED-BBBA-C35EBCD4586B@nostrum.com> References: To: jouni korhonen X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Preliminary draft agenda.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2012 14:01:45 -0000 Looks good to me! Thanks! Ben. On Oct 23, 2012, at 5:20 AM, jouni korhonen wrote: > Folks, > > Below is a very drafty draft agenda for the Dime meeting in Atlanta. We > encourage people to read the documents on both "main topics": Diameter > overload control and e2e security. Both are now getting hot topics among > our customer SDOs.. > > - Jouni & Lionel > > ----- > > DIME WG IETF 85: 120 min total > > Chairs > o Agenda and WG update 15 min > > Diameter overload control: > > Eric McMurry > o draft-ietf-dime-overload-reqs 15 min > > Adam Roach > o draft-roach-dime-overload-ctrl 30 min > > Jouni Korhonen > o draft-korhonen-dime-ovl 20 min > > Buffer for discussion 15 min > > Diameter e2e security: > > Jouni Korhonen > o draft-korhonen-dime-e2e-security 15 min > > Buffer for discussion 10 min > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From wwwrun@rfc-editor.org Thu Oct 25 10:36:14 2012 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 CD62521F88AE; Thu, 25 Oct 2012 10:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.964 X-Spam-Level: X-Spam-Status: No, score=-101.964 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ3M8oW-uo5N; Thu, 25 Oct 2012 10:36:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0F821F889E; Thu, 25 Oct 2012 10:36:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8F91E72E038; Thu, 25 Oct 2012 10:30:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121025173027.8F91E72E038@rfc-editor.org> Date: Thu, 25 Oct 2012 10:30:27 -0700 (PDT) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 6733 on Diameter Base Protocol X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2012 17:36:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6733 Title: Diameter Base Protocol Author: V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Status: Standards Track Stream: IETF Date: October 2012 Mailbox: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com Pages: 152 Characters: 343760 Obsoletes: RFC3588, RFC5719 I-D Tag: draft-ietf-dime-rfc3588bis-33.txt URL: http://www.rfc-editor.org/rfc/rfc6733.txt The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK] This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Oct 25 10:36:26 2012 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 E403421F890D; Thu, 25 Oct 2012 10:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.967 X-Spam-Level: X-Spam-Status: No, score=-101.967 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaQtcuA5Zq2O; Thu, 25 Oct 2012 10:36:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8852821F89B2; Thu, 25 Oct 2012 10:36:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1A669B1E005; Thu, 25 Oct 2012 10:30:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121025173040.1A669B1E005@rfc-editor.org> Date: Thu, 25 Oct 2012 10:30:40 -0700 (PDT) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 6734 on Diameter Attribute-Value Pairs for Cryptographic Key Transport X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2012 17:36:27 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6734 Title: Diameter Attribute-Value Pairs for Cryptographic Key Transport Author: G. Zorn, Q. Wu, V. Cakulev Status: Standards Track Stream: IETF Date: October 2012 Mailbox: glenzorn@gmail.com, sunseawq@huawei.com, violeta.cakulev@alcatel-lucent.com Pages: 7 Characters: 12643 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-local-keytran-14.txt URL: http://www.rfc-editor.org/rfc/rfc6734.txt Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. [STANDARDS-TRACK] This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Oct 25 10:36:53 2012 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 F1FCF21F89DA; Thu, 25 Oct 2012 10:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.971 X-Spam-Level: X-Spam-Status: No, score=-101.971 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJj7Z20PtVMK; Thu, 25 Oct 2012 10:36:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 03AD721F89BD; Thu, 25 Oct 2012 10:36:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 10A34B1E00D; Thu, 25 Oct 2012 10:31:01 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121025173101.10A34B1E00D@rfc-editor.org> Date: Thu, 25 Oct 2012 10:31:01 -0700 (PDT) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 6736 on Diameter Network Address and Port Translation Control Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2012 17:36:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6736 Title: Diameter Network Address and Port Translation Control Application Author: F. Brockners, S. Bhandari, V. Singh, V. Fajardo Status: Standards Track Stream: IETF Date: October 2012 Mailbox: fbrockne@cisco.com, shwethab@cisco.com, vaneeta.singh@gmail.com, vf0213@gmail.com Pages: 58 Characters: 138288 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-nat-control-17.txt URL: http://www.rfc-editor.org/rfc/rfc6736.txt This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK] This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Oct 25 10:36:54 2012 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 F1B9121F89D8; Thu, 25 Oct 2012 10:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.969 X-Spam-Level: X-Spam-Status: No, score=-101.969 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aewf3TqTOKeX; Thu, 25 Oct 2012 10:36:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DE95221F89CB; Thu, 25 Oct 2012 10:36:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4576CB1E007; Thu, 25 Oct 2012 10:30:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121025173052.4576CB1E007@rfc-editor.org> Date: Thu, 25 Oct 2012 10:30:52 -0700 (PDT) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 6735 on Diameter Priority Attribute-Value Pairs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2012 17:36:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6735 Title: Diameter Priority Attribute-Value Pairs Author: K. Carlberg, Ed., T. Taylor Status: Standards Track Stream: IETF Date: October 2012 Mailbox: carlberg@g11.org.uk, tom.taylor.stds@gmail.com Pages: 10 Characters: 21793 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-priority-avps-06.txt URL: http://www.rfc-editor.org/rfc/rfc6735.txt This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. [STANDARDS-TRACK] This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Oct 25 10:36:57 2012 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 CEEBA21F89D1; Thu, 25 Oct 2012 10:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.972 X-Spam-Level: X-Spam-Status: No, score=-101.972 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcIdZ+yZvBEE; Thu, 25 Oct 2012 10:36:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 40F5F21F89CE; Thu, 25 Oct 2012 10:36:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B7F0572E038; Thu, 25 Oct 2012 10:31:10 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121025173110.B7F0572E038@rfc-editor.org> Date: Thu, 25 Oct 2012 10:31:10 -0700 (PDT) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 6737 on The Diameter Capabilities Update Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2012 17:36:58 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6737 Title: The Diameter Capabilities Update Application Author: K. Jiao, G. Zorn Status: Standards Track Stream: IETF Date: October 2012 Mailbox: kangjiao@huawei.com, gwz@net-zen.net Pages: 6 Characters: 12380 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-capablities-update-07.txt URL: http://www.rfc-editor.org/rfc/rfc6737.txt This document defines a new Diameter application and associated Command Codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. [STANDARDS-TRACK] This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Oct 25 10:37:07 2012 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 B31C621F8A15; Thu, 25 Oct 2012 10:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.918 X-Spam-Level: X-Spam-Status: No, score=-100.918 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILJWZ4HHNTzX; Thu, 25 Oct 2012 10:37:07 -0700 (PDT) Received: from rfc-editor.org (unknown [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7D321F88E8; Thu, 25 Oct 2012 10:37:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D02EE72E041; Thu, 25 Oct 2012 10:31:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121025173120.D02EE72E041@rfc-editor.org> Date: Thu, 25 Oct 2012 10:31:20 -0700 (PDT) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 6738 on Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2012 17:37:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6738 Title: Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers Author: V. Cakulev, A. Lior, S. Mizikovsky Status: Standards Track Stream: IETF Date: October 2012 Mailbox: violeta.cakulev@alcatel-lucent.com, avi.ietf@lior.org, Simon.Mizikovsky@alcatel-lucent.com Pages: 17 Characters: 35536 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-ikev2-psk-diameter-11.txt URL: http://www.rfc-editor.org/rfc/rfc6738.txt The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec Security Associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and Shared Key (SK). Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2. This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK. [STANDARDS-TRACK] This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jouni.nospam@gmail.com Thu Oct 25 10:51:21 2012 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 017A821F8998 for ; Thu, 25 Oct 2012 10:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eL1iLEw6FH9 for ; Thu, 25 Oct 2012 10:51:18 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4D521F8994 for ; Thu, 25 Oct 2012 10:51:18 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1113425wey.31 for ; Thu, 25 Oct 2012 10:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=s2QxCGv2BLQtNdkNIG5CEvomIanOm1gjHBINDMeLR+M=; b=s4c/wZOvARTiRmJ9+RawD66HXU7HUNWJLZlcv4W3vC3FYO45obov9uBGtfc2qne17Q 3cJmMQqsfZSTj/pu9J0tzf1otBLUHXbThCC1t2uCarKrpxTsqTLO3qu4Kvdc05ZGS845 sSr63IFT2yZWikBSx+AOI+FUSxGezCY0+i2lZshGtdyn/ldBVFUKLIN9xTGXwSle1Njw Q5kJ5mlKFyam7+k3RFuOcm3T5ecoOqA5b3riqKwOXUJSSPD/2cf12UI4eizxZ16C1AIY 4rB+hY0QwsjW54Z8Rs8r50rLlfZPkD4RjxgpSU8lnppm5vyXc/P4cACOOa8JzheBkclZ BsQw== Received: by 10.181.11.167 with SMTP id ej7mr15502315wid.11.1351187477285; Thu, 25 Oct 2012 10:51:17 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id gm7sm12416449wib.10.2012.10.25.10.51.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 10:51:14 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Oct 2012 20:51:09 +0300 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] Few new RFCs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2012 17:51:21 -0000 Folks, We have six new RFCs! Thanks everyone for their efforts! Especially thanks to Glen for pushing Base Protocol update RFC6733 to completion. http://www.rfc-editor.org/rfc/rfc6733.txt http://www.rfc-editor.org/rfc/rfc6734.txt http://www.rfc-editor.org/rfc/rfc6735.txt http://www.rfc-editor.org/rfc/rfc6736.txt http://www.rfc-editor.org/rfc/rfc6737.txt http://www.rfc-editor.org/rfc/rfc6738.txt - Jouni & Lionel From bclaise@cisco.com Fri Oct 26 05:04:07 2012 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 5407221F8421 for ; Fri, 26 Oct 2012 05:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.018 X-Spam-Level: X-Spam-Status: No, score=-9.018 tagged_above=-999 required=5 tests=[AWL=1.582, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsSenn0HJhIO for ; Fri, 26 Oct 2012 05:04:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D8C6321F84D9 for ; Fri, 26 Oct 2012 05:04:05 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9QC44xg021799; Fri, 26 Oct 2012 14:04:04 +0200 (CEST) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9QC4327004229; Fri, 26 Oct 2012 14:04:03 +0200 (CEST) Message-ID: <508A7C33.8050800@cisco.com> Date: Fri, 26 Oct 2012 14:04:03 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jouni korhonen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Few new RFCs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2012 12:04:07 -0000 Great! That news made my day. Thanks to all who have involved in this important effort. Regards, Benoit > Folks, > > We have six new RFCs! Thanks everyone for their efforts! Especially > thanks to Glen for pushing Base Protocol update RFC6733 to completion. > > http://www.rfc-editor.org/rfc/rfc6733.txt > http://www.rfc-editor.org/rfc/rfc6734.txt > http://www.rfc-editor.org/rfc/rfc6735.txt > http://www.rfc-editor.org/rfc/rfc6736.txt > http://www.rfc-editor.org/rfc/rfc6737.txt > http://www.rfc-editor.org/rfc/rfc6738.txt > > > - Jouni & Lionel > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From ecnoel@research.att.com Fri Oct 26 06:48:49 2012 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 AD60121F85B4 for ; Fri, 26 Oct 2012 06:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhiMamWtH-vj for ; Fri, 26 Oct 2012 06:48:48 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4478521F85B3 for ; Fri, 26 Oct 2012 06:48:48 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id CCC441201D5; Fri, 26 Oct 2012 09:48:45 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 0A8BBE3823; Fri, 26 Oct 2012 09:44:51 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Fri, 26 Oct 2012 09:47:32 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Adam Roach' , "DIME (Diameter Maintenance and Extensions) WG" Date: Fri, 26 Oct 2012 09:47:28 -0400 Thread-Topic: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.txt Thread-Index: Ac2wn3anN92JVn6tQySbMd4s0VqiSACTvDag Message-ID: <5EBD159DE88147488A3B1590E0900184031C9979F6A9@njfpsrvexg2.research.att.com> References: <20121022214256.15618.66760.idtracker@ietfa.amsl.com> <5085C01C.4000900@nostrum.com> In-Reply-To: <5085C01C.4000900@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5EBD159DE88147488A3B1590E0900184031C9979F6A9njfpsrvexg2_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 26 Oct 2012 06:49:34 -0700 Subject: Re: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2012 13:48:49 -0000 --_000_5EBD159DE88147488A3B1590E0900184031C9979F6A9njfpsrvexg2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRhbSwNCg0KUGxlYXNlIGZpbmQgYmVsb3cgYSBmZXcgY29tbWVudHMgb24gZHJhZnQtcm9hY2gt ZGltZS1vdmVybG9hZC1jdHJsLTAxLnR4dDoNCg0KLSBTZWN0aW9uIDMuMi4xLCA0dGggcGFyYWdy YXBoOg0K4oCcVGhlIHNlbmRpbmcgbm9kZSB0aGVuIHNlbmRzLCBkcm9wcywgcXVldWVzLCBvciBv dGhlcndpc2XigKbigJ0gIFF1ZXVlaW5nIG9mIHJlcXVlc3RzIGJ5IGNsaWVudHMgd2hpbGUgYSBz ZXJ2ZXIgaXMgaW4gb3ZlcmxvYWQgaXMgcHJvYmFibHkgbm90IGEgZ29vZCBvcHRpb24gYXMgaXQg Y291bGQgbGlrZWx5IHJlc3VsdCBpbiBvc2NpbGxhdGlvbnMgYW5kL29yIHN0YWxlZCByZXF1ZXN0 cy4gIEkgd291bGQgcmVjb21tZW5kIGV4Y2x1ZGluZyB0aGUgcXVldWVpbmcgb3B0aW9uLg0KDQot IFNlY3Rpb24gMy4yLjM6DQpGb3IgdGhlIGNhc2UgYSBjbGllbnQgaXMgbmV2ZXIgZXhwZWN0ZWQg dG8gcmVjZWl2ZSByZXF1ZXN0cyBmcm9tIGl0cyBzZXJ2ZXIsIGluY2x1ZGluZyBMb2FkLUluZm8g QVZQIGluIHRoZSBvdXRnb2luZyByZXF1ZXN0IGRvZXMgbm90IHNlZW0gdG8gaGF2ZSBhbnkgdmFs dWUuIE1vcmVvdmVyLCBpbiBzaXR1YXRpb25zIHdoZXJlIGEgc2VydmVyIGlzIGluIG92ZXJsb2Fk LCBjbGllbnRzIHNob3VsZCBub3QgaW5jbHVkZSBMb2FkLUluZm8gQVZQIGluIHRoZWlyIHJlcXVl c3RzIHNvIGFzIHRvIG1pbmltaXplIG92ZXJoZWFkIG9uIHRoZSBvdmVybG9hZGVkIHNlcnZlci4N Cg0KLSBTZWN0aW9uIDMuNi4xOg0K4oCc4oCmd2hpY2ggZG9lcyBub3QgY29ycmVzcG9uZCB0byBh biBleGlzdGluZyBEaWFtZXRlciBjb25zdHJ1Y3TigKbigJ0gSG93IGRvZXMgYSBEaWFtZXRlciBj b25zdHJ1Y3QgZGlmZmVyIGZyb20gdGhlIG92ZXJsb2FkIHNjb3BlIGRlZmluZWQgaW4gc2VjdGlv biAyPyBJcyB0aGF0IGlkZW50aWNhbD8NCg0KLSBTZWN0aW9uIDQuMiwgcHNldWRvLWNvZGUsIGNh c2Ugb3V0Ym91bmQgcmVxdWVzdDoNCuKAnERldGVybWluZSBpZiBzZXJ2ZXIgd2FudHMgdG8gZW50 ZXIgaW4gb3ZlcmxvYWQgb3IgaXMgaW4gb3ZlcmxvYWTigJ0gSG93IHdvdWxkIGEgcmVxdWVzdCBz ZW5kZXIgZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IGEgc2VydmVyIHdhbnRzIHRvIGVudGVyIGlu IG92ZXJsb2FkPyBGcm9tIHRoZSBMb2FkLUluZm8gQVZQcyBzZW50IGJ5IHNlcnZlcnMsIHRoZSBy ZXF1ZXN0IHNlbmRlciBjYW4gb25seSBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdGhlIHNlcnZl ciBpcyBpbiBvdmVybG9hZCwgbm90IHRoZSBzZXJ2ZXIgb3ZlcmxvYWQgaW50ZW50LiBQbGVhc2Ug Y2xhcmlmeS4NCg0KLSBTZWN0aW9uIDQuMiwgcHNldWRvLWNvZGUsIGNhc2UgaW5ib3VuZCByZXF1 ZXN0Og0KV2hlbiBhIHNlcnZlciBpbiBvdmVybG9hZCByZWNlaXZlcyByZXF1ZXN0cyBmcm9tIGNv bXBsaWFudCBjbGllbnRzLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBzZXJ2ZXIgc3RpbGwgbmVl ZHMgdG8gcmVqZWN0IHNvbWUgb2YgdGhlc2UgcmVxdWVzdHMgYmFzZWQgaXRzIGludGVybmFsIHBy b3RlY3RpdmUgbWVjaGFuaXNtcy4gIFRoaXMgY291bGQgY29ycmVzcG9uZCB0byB0aGUgc2l0dWF0 aW9uIHdoZXJlIGEgc3VkZGVuIGluY3JlYXNlIGluIG9mZmVyZWQgbG9hZCwgZmlsdGVyZWQgYnkg Y2xpZW50cyBhdCB0aGUgY3VycmVudCBPdmVybG9hZC1NZXRyaWMgQVZQIChsb3NzKSwgZXhjZWVk cyB0aGUgc2VydmVyIGludGVybmFsIHByb3RlY3RpdmUgbWVjaGFuaXNtcyB1bnRpbCB0aGUgc2Vy dmVyIHJlZnJlc2hlcyB0aGUgT3ZlcmxvYWQtTWV0cmljIEFWUC4NCkkgYXNzdW1lIHRoaXMgY2Fz ZSBpcyBhY2NvdW50ZWQgZm9yIGluIHRoZSBmdW5jdGlvbiDigJxwcm9jZXNzX21zZ+KAnS4gU2hv dWxkIHRoaXMgYmUgbWVudGlvbmVkIGFueXdoZXJlIGluIHRoZSBjb250cmlidXRpb24gb3IgaXMg dGhhdCB0b28gb2J2aW91cz8NCg0KLSBTZWN0aW9uIDguMjoNCkluIHRoZSByZWZlcmVuY2VzLCBw bGVhc2UgYWRkIOKAnGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC0wMy50eHTi gJ0uIFRoYXQgY29udHJpYnV0aW9uIHByb3Bvc2VzIGEgcmF0ZSBjb250cm9sIGFsZ29yaXRobSBh cyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgbG9zcyBjb250cm9sIGFsZ29yaXRobSB3aXRoaW4gU0lQ IGNvbnRleHQuDQoNClR5cG9zOg0KDQotICBTZWN0aW9uIDMuMi4xLCA1dGggcGFyYWdyYXBoOg0K 4oCcVGhlIGF1dGhvcnPigKYu4oCdIHNpbmNlIG9ubHkgb25lIGF1dGhvciwgcHJvYmFibHkgYmV0 dGVyIHRvIGJlIHNpbmd1bGFyLg0KDQotIFNlY3Rpb24gMy4yLjQ6DQrigJxBIG5vZGUgdGhhdCBy ZWNlaXZlcyBhIGFuc3dlcuKApuKAnSByZXBsYWNlIOKAnGEg4oCcd2l0aCDigJxhbuKAnQ0KDQot IFNlY3Rpb24gMy4zLCAybmQgcGFyYWdyYXBoOg0K4oCc4oCmcmVmbGVjdGluZyB0aGUgYSBBZ2Vu dOKAmXMgb3ZlcmxvYWTigKbigJ0gcmVwbGFjZSDigJxh4oCdIHdpdGgg4oCcYW7igJ0NCg0KVGhh bmtzLA0KDQpFcmljIE5vZWwNCkFUJlQgTGFicywgSW5jLg0KUmV0aGluayBQb3NzaWJsZQ0KDQpO ZXR3b3JrIERlc2lnbiBhbmQgUGVyZm9ybWFuY2UgQW5hbHlzaXMNCjIwMCBTb3V0aCBMYXVyZWwg QXZlbnVlLCBENS0zRDE5DQpNaWRkbGV0b3duLCBOSiAwNzc0OA0KUDogNzMyLjQyMC40MTc0DQpl Y25vZWxAYXR0LmNvbTxtYWlsdG86anNtaXRoQGF0dC5jb20+DQoNCkZyb206IGRpbWUtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFk YW0gUm9hY2gNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxMiA1OjUyIFBNDQpUbzogRElN RSAoRGlhbWV0ZXIgTWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMpIFdHDQpTdWJqZWN0OiBbRGlt ZV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yb2FjaC1kaW1lLW92ZXJsb2Fk LWN0cmwtMDEudHh0DQoNCkRJTUUgd29ya2luZyBncm91cDoNCg0KSSBoYXZlIHN1Ym1pdHRlZCBh IG5ldyB2ZXJzaW9uIG9mIHRoZSBEaWFtZXRlciBPdmVybG9hZCBkb2N1bWVudCwgYmFzZWQgb24g ZWFybHkgZmVlZGJhY2sgb24gdGhlIC0wMCB2ZXJzaW9uLiBQbGVhc2UgdXNlIHRoZSAiRGlmZiIg bGluaywgYmVsb3csIGZvciBhIGNvbXByZWhlbnNpdmUgYWNjb3VudGluZyBvZiBkaWZmZXJlbmNl cy4gQXQgYSBoaWdoIGxldmVsLCB0aGUgbWFpbiBjaGFuZ2VzIGFyZToNCg0KLSBPbmx5IG9uZSBz Y29wZSAoSG9zdCkgaXMgbWFuZGF0b3J5IGFueSBsb25nZXIuIE90aGVycyBhcmUgIlNIT1VMRC1s ZXZlbC4iDQotIFNjb3BlIG5lZ290aWF0aW9uIGhhcyBiZWVuIHJlcGxhY2VkIGJ5IHN1cHBvcnRl ZCBzY29wZSBhbm5vdW5jZW1lbnQuIFRoaXMgYWxsb3dzIGZvciBhc3ltbWV0cmljIHNjb3BlcyBp biBhIGNvbm5lY3Rpb24uDQotICJIb3N0IiBzY29wZSBoYXMgYmVlbiByZW5hbWVkICJEZXN0aW5h dGlvbiBIb3N0IiBzY29wZSB0byBjbGFyaWZ5IHRoYXQgaXQgZG9lcyBub3QgcmVmZXIgdG8gdGhl IHNlbmRpbmcgaG9zdC4NCi0gQSBuZXcgIkFwcGVuZGl4IEQiIGhhcyBiZWVuIGFkZGVkIHRvIGRp c2N1c3Mgc29tZSBvZiB0aGUgZGVzaWduIHRyYWRlb2ZmcyBjdXJyZW50bHkgcHJlc2VudCBpbiB0 aGUgZG9jdW1lbnQuDQoNCkkgcGxhbiB0byBkaXNjdXNzIHRoaXMgLTAxIHZlcnNpb24gZHVyaW5n IHRoZSB1cGNvbWluZyBtZWV0aW5nIGluIEF0bGFudGEuDQoNClRoYW5rcyENCg0KL2ENCg0KDQot LS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJvYWNoLWRpbWUtb3ZlcmxvYWQtY3RybC0wMS50eHQN Cg0KRGF0ZToNCg0KTW9uLCAyMiBPY3QgMjAxMiAxNDo0Mjo1NiAtMDcwMA0KDQpGcm9tOg0KDQpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4N Cg0KVG86DQoNCmFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+DQoNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcm9hY2gtZGltZS1vdmVybG9hZC1jdHJsLTAx LnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFkYW0gUm9hY2ggYW5k IHBvc3RlZCB0byB0aGUNCg0KSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KRmlsZW5hbWU6ICAgICAg IGRyYWZ0LXJvYWNoLWRpbWUtb3ZlcmxvYWQtY3RybA0KDQpSZXZpc2lvbjogICAgICAgMDENCg0K VGl0bGU6ICAgICAgICAgIEEgTWVjaGFuaXNtIGZvciBEaWFtZXRlciBPdmVybG9hZCBDb250cm9s DQoNCkNyZWF0aW9uIGRhdGU6ICAyMDEyLTEwLTIyDQoNCldHIElEOiAgICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCg0KTnVtYmVyIG9mIHBhZ2VzOiAzOA0KDQpVUkw6ICAgICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJvYWNoLWRpbWUtb3Zl cmxvYWQtY3RybC0wMS50eHQNCg0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXJvYWNoLWRpbWUtb3ZlcmxvYWQtY3RybA0KDQpIdG1saXplZDog ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJvYWNoLWRpbWUtb3Zlcmxv YWQtY3RybC0wMQ0KDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LXJvYWNoLWRpbWUtb3ZlcmxvYWQtY3RybC0wMQ0KDQoNCg0KQWJzdHJhY3Q6 DQoNCiAgIFdoZW4gYSBEaWFtZXRlciBzZXJ2ZXIgb3IgYWdlbnQgYmVjb21lcyBvdmVybG9hZGVk LCBpdCBuZWVkcyB0byBiZQ0KDQogICBhYmxlIHRvIGdyYWNlZnVsbHkgcmVkdWNlIGl0cyBsb2Fk LCB0eXBpY2FsbHkgYnkgaW5mb3JtaW5nIGNsaWVudHMgdG8NCg0KICAgcmVkdWNlIG9yIHN0b3Ag c2VuZGluZyB0cmFmZmljIGZvciBzb21lIHBlcmlvZCBvZiB0aW1lLiAgT3RoZXJ3aXNlLA0KDQog ICBpdCBtdXN0IGNvbnRpbnVlIHRvIGV4cGVuZCByZXNvdXJjZXMgcGFyc2luZyBhbmQgcmVzcG9u ZGluZyB0bw0KDQogICBEaWFtZXRlciBtZXNzYWdlcy4NCg0KDQoNCiAgIFRoaXMgZG9jdW1lbnQg cHJvcG9zZXMgYSBjb25jcmV0ZSwgYXBwbGljYXRpb24taW5kZXBlbmRlbnQgbWVjaGFuaXNtDQoN CiAgIHRvIGFkZHJlc3MgdGhlIGNoYWxsZW5nZSBvZiBjb21tdW5pY2F0aW5nIGxvYWQgYW5kIG92 ZXJsb2FkIHN0YXRlDQoNCiAgIGFtb25nIERpYW1ldGVyIHBlZXJzLCBhbmQgc3BlY2lmaWVzIGFu IGFsZ29yaXRobSBmb3IgbG9hZCBhYmF0ZW1lbnQNCg0KICAgdG8gYWRkcmVzcyBzdWNoIG92ZXJs b2FkIGNvbmRpdGlvbnMgYXMgdGhleSBvY2N1ci4gIFRoZSBsb2FkDQoNCiAgIGFiYXRlbWVudCBh bGdvcml0aG0gaXMgZXh0ZW5zaWJsZSwgYWxsb3dpbmcgZm9yIGZ1dHVyZSBkb2N1bWVudHMgdG8N Cg0KICAgZGVmaW5lIGFkZGl0aW9uYWwgbG9hZCBhYmF0ZW1lbnQgYXBwcm9hY2hlcy4NCg0KDQoN Cg0KDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCg== --_000_5EBD159DE88147488A3B1590E0900184031C9979F6A9njfpsrvexg2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29u c29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjI1MDY2MTg0Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTAzMDE2Mjk3MiAxNTg3ODI1NTQ4IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsN Cgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoyMjYwMzc2Mjc7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00MTc0NTk0 MzQgLTExMDMwODIyMzYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30N CkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1s aXN0LWlkOjE1ODExMzUyMTQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE2Mjg0MDA1NCAtMTg3NTEzNzQ4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwy OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNzc3NTUyNTA1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDE2MjkwOTUwIC0xMTI4MjI0MjAyIDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwz OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9d2hpdGUgbGFuZz1FTi1VUyBsaW5r PWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFkYW0sPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QbGVh c2UgZmluZCBiZWxvdyBhIGZldyBjb21tZW50cyBvbiBkcmFmdC1yb2FjaC1kaW1lLW92ZXJsb2Fk LWN0cmwtMDEudHh0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LSBTZWN0aW9uIDMuMi4xLCA0dGggcGFy YWdyYXBoOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz7igJxUaGUgc2VuZGluZyBub2RlIHRoZW4gc2VuZHMsIGRyb3BzLCBxdWV1 ZXMsIG9yIG90aGVyd2lzZeKApuKAnSDCoFF1ZXVlaW5nIG9mIHJlcXVlc3RzIGJ5IGNsaWVudHMg d2hpbGUgYSBzZXJ2ZXIgaXMgaW4gb3ZlcmxvYWQgaXMgcHJvYmFibHkgbm90IGEgZ29vZCBvcHRp b24gYXMgaXQgY291bGQgbGlrZWx5IHJlc3VsdCBpbiBvc2NpbGxhdGlvbnMgYW5kL29yIHN0YWxl ZCByZXF1ZXN0cy4gwqBJIHdvdWxkIHJlY29tbWVuZCBleGNsdWRpbmcgdGhlIHF1ZXVlaW5nIG9w dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gU2VjdGlvbiAzLjIuMzogPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkZvciB0aGUg Y2FzZSBhIGNsaWVudCBpcyBuZXZlciBleHBlY3RlZCB0byByZWNlaXZlIHJlcXVlc3RzIGZyb20g aXRzIHNlcnZlciwgaW5jbHVkaW5nIExvYWQtSW5mbyBBVlAgaW4gdGhlIG91dGdvaW5nIHJlcXVl c3QgZG9lcyBub3Qgc2VlbSB0byBoYXZlIGFueSB2YWx1ZS4gTW9yZW92ZXIsIGluIHNpdHVhdGlv bnMgd2hlcmUgYSBzZXJ2ZXIgaXMgaW4gb3ZlcmxvYWQsIGNsaWVudHMgc2hvdWxkIG5vdCBpbmNs dWRlIExvYWQtSW5mbyBBVlAgaW4gdGhlaXIgcmVxdWVzdHMgc28gYXMgdG8gbWluaW1pemUgb3Zl cmhlYWQgb24gdGhlIG92ZXJsb2FkZWQgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LSBTZWN0 aW9uIDMuNi4xOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+4oCc4oCmd2hpY2ggZG9lcyBub3QgY29ycmVzcG9uZCB0byBhbiBl eGlzdGluZyBEaWFtZXRlciBjb25zdHJ1Y3TigKbigJ0gSG93IGRvZXMgYSBEaWFtZXRlciBjb25z dHJ1Y3QgZGlmZmVyIGZyb20gdGhlIG92ZXJsb2FkIHNjb3BlIGRlZmluZWQgaW4gc2VjdGlvbiAy PyBJcyB0aGF0IGlkZW50aWNhbD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gU2VjdGlvbiA0LjIsIHBz ZXVkby1jb2RlLCBjYXNlIG91dGJvdW5kIHJlcXVlc3Q6PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKAnERldGVybWluZSBpZiBz ZXJ2ZXIgd2FudHMgdG8gZW50ZXIgaW4gb3ZlcmxvYWQgb3IgaXMgaW4gb3ZlcmxvYWTigJ0gSG93 IHdvdWxkIGEgcmVxdWVzdCBzZW5kZXIgZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IGEgc2VydmVy IHdhbnRzIHRvIGVudGVyIGluIG92ZXJsb2FkPyBGcm9tIHRoZSBMb2FkLUluZm8gQVZQcyBzZW50 IGJ5IHNlcnZlcnMsIHRoZSByZXF1ZXN0IHNlbmRlciBjYW4gb25seSBkZXRlcm1pbmUgd2hldGhl ciBvciBub3QgdGhlIHNlcnZlciBpcyBpbiBvdmVybG9hZCwgbm90IHRoZSBzZXJ2ZXIgb3Zlcmxv YWQgaW50ZW50LiBQbGVhc2UgY2xhcmlmeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gU2VjdGlvbiA0 LjIsIHBzZXVkby1jb2RlLCBjYXNlIGluYm91bmQgcmVxdWVzdDogPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldoZW4gYSBzZXJ2 ZXIgaW4gb3ZlcmxvYWQgcmVjZWl2ZXMgcmVxdWVzdHMgZnJvbSBjb21wbGlhbnQgY2xpZW50cywg aXQgaXMgcG9zc2libGUgdGhhdCB0aGUgc2VydmVyIHN0aWxsIG5lZWRzIHRvIHJlamVjdCBzb21l IG9mIHRoZXNlIHJlcXVlc3RzIGJhc2VkIGl0cyBpbnRlcm5hbCBwcm90ZWN0aXZlIG1lY2hhbmlz bXMuIMKgVGhpcyBjb3VsZCBjb3JyZXNwb25kIHRvIHRoZSBzaXR1YXRpb24gd2hlcmUgYSBzdWRk ZW4gaW5jcmVhc2UgaW4gb2ZmZXJlZCBsb2FkLCBmaWx0ZXJlZCBieSBjbGllbnRzIGF0IHRoZSBj dXJyZW50IE92ZXJsb2FkLU1ldHJpYyBBVlAgKGxvc3MpLCBleGNlZWRzIHRoZSBzZXJ2ZXIgaW50 ZXJuYWwgcHJvdGVjdGl2ZSBtZWNoYW5pc21zIHVudGlsIHRoZSBzZXJ2ZXIgcmVmcmVzaGVzIHRo ZSBPdmVybG9hZC1NZXRyaWMgQVZQLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBhc3N1bWUgdGhpcyBjYXNlIGlzIGFjY291 bnRlZCBmb3IgaW4gdGhlIGZ1bmN0aW9uIOKAnHByb2Nlc3NfbXNn4oCdLiBTaG91bGQgdGhpcyBi ZSBtZW50aW9uZWQgYW55d2hlcmUgaW4gdGhlIGNvbnRyaWJ1dGlvbiBvciBpcyB0aGF0IHRvbyBv YnZpb3VzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LSBTZWN0aW9uIDguMjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW4gdGhlIHJl ZmVyZW5jZXMsIHBsZWFzZSBhZGQg4oCcZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250 cm9sLTAzLnR4dOKAnS4gVGhhdCBjb250cmlidXRpb24gcHJvcG9zZXMgYSByYXRlIGNvbnRyb2wg YWxnb3JpdGhtIGFzIGFuIGFsdGVybmF0aXZlIHRvIHRoZSBsb3NzIGNvbnRyb2wgYWxnb3JpdGht IHdpdGhpbiBTSVAgY29udGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlR5cG9zOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+LcKgIFNlY3Rpb24gMy4yLjEsIDV0aCBwYXJhZ3JhcGg6PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKAnFRoZSBh dXRob3Jz4oCmLuKAnSBzaW5jZSBvbmx5IG9uZSBhdXRob3IsIHByb2JhYmx5IGJldHRlciB0byBi ZSBzaW5ndWxhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gU2VjdGlvbiAzLjIuNDogPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKA nEEgbm9kZSB0aGF0IHJlY2VpdmVzIGEgYW5zd2Vy4oCm4oCdIHJlcGxhY2Ug4oCcYSDigJx3aXRo IOKAnGFu4oCdPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tIFNlY3Rpb24gMy4zLCAybmQgcGFyYWdyYXBo OiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+4oCc4oCmcmVmbGVjdGluZyB0aGUgYSBBZ2VudOKAmXMgb3ZlcmxvYWTigKbigJ0g cmVwbGFjZSDigJxh4oCdIHdpdGgg4oCcYW7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5z LXNlcmlmIjtjb2xvcjojRjQ3QjIwJz5FcmljIE5vZWw8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2 NjYnPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtj b2xvcjojNjY2NjY2Jz5BVCZhbXA7VCBMYWJzLCBJbmMuPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzY2NjY2Nic+IDxicj48L3NwYW4+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMEIwRTAnPlJldGhpbmsgUG9z c2libGU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzAwQjBFMCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVy ZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPk5ldHdvcmsgRGVzaWduIGFuZCBQZXJm b3JtYW5jZSBBbmFseXNpczxicj4yMDAgU291dGggTGF1cmVsIEF2ZW51ZSwgRDUtM0QxOTxicj5N aWRkbGV0b3duLCBOSiAwNzc0ODxicj5QOiA3MzIuNDIwLjQxNzQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PGEgaHJlZj0ibWFp bHRvOmpzbWl0aEBhdHQuY29tIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPmVjbm9lbEBhdHQuY29tPC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xv cjp3aW5kb3d0ZXh0Jz4gZGltZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGltZS1ib3VuY2Vz QGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkFkYW0gUm9hY2g8YnI+PGI+U2VudDo8L2I+ IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxMiA1OjUyIFBNPGJyPjxiPlRvOjwvYj4gRElNRSAoRGlh bWV0ZXIgTWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMpIFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBb RGltZV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yb2FjaC1kaW1lLW92ZXJs b2FkLWN0cmwtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+RElNRSB3 b3JraW5nIGdyb3VwOjxicj48YnI+SSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRo ZSBEaWFtZXRlciBPdmVybG9hZCBkb2N1bWVudCwgYmFzZWQgb24gZWFybHkgZmVlZGJhY2sgb24g dGhlIC0wMCB2ZXJzaW9uLiBQbGVhc2UgdXNlIHRoZSAmcXVvdDtEaWZmJnF1b3Q7IGxpbmssIGJl bG93LCBmb3IgYSBjb21wcmVoZW5zaXZlIGFjY291bnRpbmcgb2YgZGlmZmVyZW5jZXMuIEF0IGEg aGlnaCBsZXZlbCwgdGhlIG1haW4gY2hhbmdlcyBhcmU6PGJyPjxicj4tIE9ubHkgb25lIHNjb3Bl IChIb3N0KSBpcyBtYW5kYXRvcnkgYW55IGxvbmdlci4gT3RoZXJzIGFyZSAmcXVvdDtTSE9VTEQt bGV2ZWwuJnF1b3Q7PGJyPi0gU2NvcGUgbmVnb3RpYXRpb24gaGFzIGJlZW4gcmVwbGFjZWQgYnkg c3VwcG9ydGVkIHNjb3BlIGFubm91bmNlbWVudC4gVGhpcyBhbGxvd3MgZm9yIGFzeW1tZXRyaWMg c2NvcGVzIGluIGEgY29ubmVjdGlvbi48YnI+LSAmcXVvdDtIb3N0JnF1b3Q7IHNjb3BlIGhhcyBi ZWVuIHJlbmFtZWQgJnF1b3Q7RGVzdGluYXRpb24gSG9zdCZxdW90OyBzY29wZSB0byBjbGFyaWZ5 IHRoYXQgaXQgZG9lcyBub3QgcmVmZXIgdG8gdGhlIHNlbmRpbmcgaG9zdC48YnI+LSBBIG5ldyAm cXVvdDtBcHBlbmRpeCBEJnF1b3Q7IGhhcyBiZWVuIGFkZGVkIHRvIGRpc2N1c3Mgc29tZSBvZiB0 aGUgZGVzaWduIHRyYWRlb2ZmcyBjdXJyZW50bHkgcHJlc2VudCBpbiB0aGUgZG9jdW1lbnQuPGJy Pjxicj5JIHBsYW4gdG8gZGlzY3VzcyB0aGlzIC0wMSB2ZXJzaW9uIGR1cmluZyB0aGUgdXBjb21p bmcgbWVldGluZyBpbiBBdGxhbnRhLjxicj48YnI+VGhhbmtzITxicj48YnI+L2E8bzpwPjwvbzpw PjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0tLS0gPG86cD48L286cD48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxl IGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MD48dHI+PHRkIG5vd3JhcCB2YWxp Z249dG9wIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFs IGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48Yj5TdWJqZWN0OiA8bzpwPjwv bzpwPjwvYj48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBj bGFzcz1Nc29Ob3JtYWw+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yb2FjaC1k aW1lLW92ZXJsb2FkLWN0cmwtMDEudHh0PG86cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQg bm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFz cz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPkRhdGU6 IDxvOnA+PC9vOnA+PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAw aW4nPjxwIGNsYXNzPU1zb05vcm1hbD5Nb24sIDIyIE9jdCAyMDEyIDE0OjQyOjU2IC0wNzAwPG86 cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3Bh ZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5 bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPkZyb206IDxvOnA+PC9vOnA+PC9iPjwvcD48L3RkPjx0 ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48YSBo cmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8L2E+PG86cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQgbm93cmFwIHZhbGlnbj10 b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgYWxp Z249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPlRvOiA8bzpwPjwvbzpwPjwvYj48 L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29O b3JtYWw+PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFkYW1Abm9zdHJ1bS5jb208 L2E+PG86cD48L286cD48L3A+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PHByZT5BIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcm9hY2gtZGltZS1vdmVybG9hZC1jdHJsLTAxLnR4dDxv OnA+PC9vOnA+PC9wcmU+PHByZT5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFk YW0gUm9hY2ggYW5kIHBvc3RlZCB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPjxwcmU+SUVURiByZXBv c2l0b3J5LjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+ RmlsZW5hbWU6wqDCoMKgwqDCoCAgZHJhZnQtcm9hY2gtZGltZS1vdmVybG9hZC1jdHJsPG86cD48 L286cD48L3ByZT48cHJlPlJldmlzaW9uOsKgwqDCoMKgwqAgIDAxPG86cD48L286cD48L3ByZT48 cHJlPlRpdGxlOsKgwqDCoMKgwqDCoMKgwqAgIEEgTWVjaGFuaXNtIGZvciBEaWFtZXRlciBPdmVy bG9hZCBDb250cm9sPG86cD48L286cD48L3ByZT48cHJlPkNyZWF0aW9uIGRhdGU6ICAyMDEyLTEw LTIyPG86cD48L286cD48L3ByZT48cHJlPldHIElEOsKgwqDCoMKgwqDCoMKgwqAgIEluZGl2aWR1 YWwgU3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wcmU+PHByZT5OdW1iZXIgb2YgcGFnZXM6IDM4PG86 cD48L286cD48L3ByZT48cHJlPlVSTDrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcm9hY2gtZGltZS1vdmVy bG9hZC1jdHJsLTAxLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtcm9hY2gtZGltZS1vdmVybG9hZC1jdHJsLTAxLnR4dDwvYT48bzpwPjwvbzpwPjwvcHJlPjxw cmU+U3RhdHVzOsKgwqDCoMKgwqDCoMKgwqDCoCA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXJvYWNoLWRpbWUtb3ZlcmxvYWQtY3RybCI+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yb2FjaC1kaW1lLW92ZXJsb2FkLWN0cmw8L2E+PG86 cD48L286cD48L3ByZT48cHJlPkh0bWxpemVkOsKgwqDCoMKgwqDCoMKgIDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJvYWNoLWRpbWUtb3ZlcmxvYWQtY3RybC0wMSI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcm9hY2gtZGltZS1vdmVybG9hZC1jdHJs LTAxPC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT5EaWZmOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcm9hY2gtZGlt ZS1vdmVybG9hZC1jdHJsLTAxIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1yb2FjaC1kaW1lLW92ZXJsb2FkLWN0cmwtMDE8L2E+PG86cD48L286cD48L3ByZT48cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ wqDCoCBXaGVuIGEgRGlhbWV0ZXIgc2VydmVyIG9yIGFnZW50IGJlY29tZXMgb3ZlcmxvYWRlZCwg aXQgbmVlZHMgdG8gYmU8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBhYmxlIHRvIGdyYWNlZnVs bHkgcmVkdWNlIGl0cyBsb2FkLCB0eXBpY2FsbHkgYnkgaW5mb3JtaW5nIGNsaWVudHMgdG88bzpw PjwvbzpwPjwvcHJlPjxwcmU+wqDCoCByZWR1Y2Ugb3Igc3RvcCBzZW5kaW5nIHRyYWZmaWMgZm9y IHNvbWUgcGVyaW9kIG9mIHRpbWUuwqAgT3RoZXJ3aXNlLDxvOnA+PC9vOnA+PC9wcmU+PHByZT7C oMKgIGl0IG11c3QgY29udGludWUgdG8gZXhwZW5kIHJlc291cmNlcyBwYXJzaW5nIGFuZCByZXNw b25kaW5nIHRvPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgRGlhbWV0ZXIgbWVzc2FnZXMuPG86 cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT7CoMKgIFRoaXMg ZG9jdW1lbnQgcHJvcG9zZXMgYSBjb25jcmV0ZSwgYXBwbGljYXRpb24taW5kZXBlbmRlbnQgbWVj aGFuaXNtPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgdG8gYWRkcmVzcyB0aGUgY2hhbGxlbmdl IG9mIGNvbW11bmljYXRpbmcgbG9hZCBhbmQgb3ZlcmxvYWQgc3RhdGU8bzpwPjwvbzpwPjwvcHJl PjxwcmU+wqDCoCBhbW9uZyBEaWFtZXRlciBwZWVycywgYW5kIHNwZWNpZmllcyBhbiBhbGdvcml0 aG0gZm9yIGxvYWQgYWJhdGVtZW50PG86cD48L286cD48L3ByZT48cHJlPsKgwqAgdG8gYWRkcmVz cyBzdWNoIG92ZXJsb2FkIGNvbmRpdGlvbnMgYXMgdGhleSBvY2N1ci7CoCBUaGUgbG9hZDxvOnA+ PC9vOnA+PC9wcmU+PHByZT7CoMKgIGFiYXRlbWVudCBhbGdvcml0aG0gaXMgZXh0ZW5zaWJsZSwg YWxsb3dpbmcgZm9yIGZ1dHVyZSBkb2N1bWVudHMgdG88bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDC oCBkZWZpbmUgYWRkaXRpb25hbCBsb2FkIGFiYXRlbWVudCBhcHByb2FjaGVzLjxvOnA+PC9vOnA+ PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPlRoZSBJ RVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_5EBD159DE88147488A3B1590E0900184031C9979F6A9njfpsrvexg2_-- From jouni.nospam@gmail.com Mon Oct 29 12:34:15 2012 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 A6EBD21F86CA for ; Mon, 29 Oct 2012 12:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk+igMgxDRYr for ; Mon, 29 Oct 2012 12:34:13 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C723921F86C7 for ; Mon, 29 Oct 2012 12:34:08 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so2635398eek.31 for ; Mon, 29 Oct 2012 12:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=AgTadBGbeupciJ9uHz07thQkKt063YRW1FgrVtlKxTs=; b=mV5yjx95EdBGE8P/PJCEyDw31R6F4oyXxkqUJoe4t0t2lO8fPlEom9tNuyipaBKElW u+fpBQBtUIFAUeRDSDD4eyMDbONLE/K1o4EfWbio+wNIVuP7Od2Kila727lWbK8CzIWJ UAoyQitZkJQDyrwveIcgvJhF9qlyHy9EwT+Rcg/HIJCKdfOkL+5aA1mX7oARVuLf1OIv Og2LIN35CB0NwJ6RJA+IeULp+W5+CIY+6no1cLiruBZhvf5anRtDhIuau83StoTA9vHn HUObAOFYeM9rVV24KVcBMimx5eGTrzp7WYY2YaX4vPVZVd1fW0CBAwtvwAkY3Ld0qY2K XnDQ== Received: by 10.14.205.3 with SMTP id i3mr64455042eeo.18.1351539248012; Mon, 29 Oct 2012 12:34:08 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id i1sm24620338eeo.8.2012.10.29.12.34.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 12:34:06 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 29 Oct 2012 21:34:03 +0200 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Atlanta WG meeting presentations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2012 19:34:15 -0000 Folks, Those who have an agenda slot, send your presentation by Sunday morning. - Jouni & Lionel From adam@nostrum.com Mon Oct 29 15:27:58 2012 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 D2BE621F8551 for ; Mon, 29 Oct 2012 15:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoQ8FTbibwRU for ; Mon, 29 Oct 2012 15:27:57 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 46A3121F8516 for ; Mon, 29 Oct 2012 15:27:57 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9TMRtCk090655 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 29 Oct 2012 17:27:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <508F02ED.9050700@nostrum.com> Date: Mon, 29 Oct 2012 17:27:57 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "NOEL, ERIC C (ERIC C)" References: <20121022214256.15618.66760.idtracker@ietfa.amsl.com> <5085C01C.4000900@nostrum.com> <5EBD159DE88147488A3B1590E0900184031C9979F6A9@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E0900184031C9979F6A9@njfpsrvexg2.research.att.com> Content-Type: multipart/alternative; boundary="------------020502000507030303090102" Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "DIME \(Diameter Maintenance and Extensions\) WG" Subject: Re: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2012 22:27:59 -0000 This is a multi-part message in MIME format. --------------020502000507030303090102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/26/12 8:47 AM, NOEL, ERIC C (ERIC C) wrote: > > Adam, > > Please find below a few comments on draft-roach-dime-overload-ctrl-01.txt: > Thanks for the review! > - Section 3.2.1, 4th paragraph: > > “The sending node then sends, drops, queues, or otherwise…” Queueing > of requests by clients while a server is in overload is probably not a > good option as it could likely result in oscillations and/or staled > requests. I would recommend excluding the queueing option. > That sounds reasonable; I've removed it from my -02 draft. > - Section 3.2.3: > > For the case a client is never expected to receive requests from its > server, including Load-Info AVP in the outgoing request does not seem > to have any value. > That does seem reasonable. I'll put it on the slides for Atlanta to see if anyone objects to removing the requirement in such a case. > Moreover, in situations where a server is in overload, clients should > not include Load-Info AVP in their requests so as to minimize overhead > on the overloaded server. > I'm not sure I agree -- in high traffic situations, it doesn't seem unreasonable that you would have multiple nodes getting busy simultaneously. It would seem dangerous to disable the client's ability to signal overload in the case that the server it is communicating with is overloaded. Keep in mind that the server doesn't actually need to process each and every Load-Info AVP it receives, as long as the 'O'verload bit is clear -- which means that the overhead you're talking about is extremely minimal (limited to stripping off an AVP when messages arrive). > - Section 3.6.1: > > “…which does not correspond to an existing Diameter construct…” How > does a Diameter construct differ from the overload scope defined in > section 2? Is that identical? > I meant "construct" as in the plain English meaning of that noun. You can substitute "thing" if you'd like, but that didn't seem appropriate for the tone of the document. Each of the scopes is a Diameter thing: a thing defined within the Diameter specification itself. There might be some things that we've missed, or that will be defined in the future, that are candidates for becoming scopes in future overload-related specifications. So, to answer your question directly: each of the overload scopes in section 2 corresponds to a Diameter thing (construct), but there might be things -- either now or at some point in the future -- that are not covered by those scopes. > - Section 4.2, pseudo-code, case outbound request: > > “Determine if server wants to enter in overload or is in overload” How > would a request sender determine whether or not a server wants to > enter in overload? From the Load-Info AVPs sent by servers, the > request sender can only determine whether or not the server is in > overload, not the server overload intent. Please clarify. > The comment comes directly from the SOC document, so I'd have to check with Vijay to be certain; however, my interpretation is "check the context, which will contain overload information gleaned from the immediately preceding message (server wants to enter overload) or a prior message for which the period of validity is still in effect (server is in overload)." If you think there is a clearer way to say this, I'd be happy to see a concrete proposal. > - Section 4.2, pseudo-code, case inbound request: > > When a server in overload receives requests from compliant clients, it > is possible that the server still needs to reject some of these > requests based its internal protective mechanisms. This could > correspond to the situation where a sudden increase in offered load, > filtered by clients at the current Overload-Metric AVP (loss), exceeds > the server internal protective mechanisms until the server refreshes > the Overload-Metric AVP. > > I assume this case is accounted for in the function “process_msg”. > Should this be mentioned anywhere in the contribution or is that too > obvious? > I believe that such rejections would generally be encompassed in "process_msg." I'm not sure the pseudocode needs to change, but it's probably worthwhile to add text to add text to 3.2.2.1 indicating that message recipients might need to reject messages from compliant hosts in the case that their load it too high despite use of the mechanism: In some circumstances, request recipients can become sufficiently overloaded that even those messages received from complaint clients can overwhelm its processing capabilities. Under such circumstances, nodes MAY begin treating a subset of such requests as if they were received from noncompliant peers (as explained in the following section). > - Section 8.2: > > In the references, please add > “draft-ietf-soc-overload-rate-control-03.txt”. That contribution > proposes a rate control algorithm as an alternative to the loss > control algorithm within SIP context. > Sure. > > Typos: > > - Section 3.2.1, 5th paragraph: > > “The authors….” since only one author, probably better to be singular. > This was just a bit of forward-leaning on my part, as I expect to have one or more co-authors prior to the document being final. > - Section 3.2.4: > > “A node that receives a answer…” replace “a “with “an” > Thanks. > - Section 3.3, 2nd paragraph: > > “…reflecting the a Agent’s overload…” replace “a” with “an” > Fixed. Thank you. /a --------------020502000507030303090102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 10/26/12 8:47 AM, NOEL, ERIC C (ERIC C) wrote:

Adam,

 

Please find below a few comments on draft-roach-dime-overload-ctrl-01.txt:


Thanks for the review!

 - Section 3.2.1, 4th paragraph:

“The sending node then sends, drops, queues, or otherwise…”  Queueing of requests by clients while a server is in overload is probably not a good option as it could likely result in oscillations and/or staled requests.  I would recommend excluding the queueing option.


That sounds reasonable; I've removed it from my -02 draft.

- Section 3.2.3:

For the case a client is never expected to receive requests from its server, including Load-Info AVP in the outgoing request does not seem to have any value.


That does seem reasonable. I'll put it on the slides for Atlanta to see if anyone objects to removing the requirement in such a case.

Moreover, in situations where a server is in overload, clients should not include Load-Info AVP in their requests so as to minimize overhead on the overloaded server.


I'm not sure I agree -- in high traffic situations, it doesn't seem unreasonable that you would have multiple nodes getting busy simultaneously. It would seem dangerous to disable the client's ability to signal overload in the case that the server it is communicating with is overloaded.

Keep in mind that the server doesn't actually need to process each and every Load-Info AVP it receives, as long as the 'O'verload bit is clear -- which means that the overhead you're talking about is extremely minimal (limited to stripping off an AVP when messages arrive).

- Section 3.6.1:

“…which does not correspond to an existing Diameter construct…” How does a Diameter construct differ from the overload scope defined in section 2? Is that identical?


I meant "construct" as in the plain English meaning of that noun. You can substitute "thing" if you'd like, but that didn't seem appropriate for the tone of the document.

Each of the scopes is a Diameter thing: a thing defined within the Diameter specification itself. There might be some things that we've missed, or that will be defined in the future, that are candidates for becoming scopes in future overload-related specifications. So, to answer your question directly: each of the overload scopes in section 2 corresponds to a Diameter thing (construct), but there might be things -- either now or at some point in the future -- that are not covered by those scopes.

- Section 4.2, pseudo-code, case outbound request:

“Determine if server wants to enter in overload or is in overload” How would a request sender determine whether or not a server wants to enter in overload? From the Load-Info AVPs sent by servers, the request sender can only determine whether or not the server is in overload, not the server overload intent. Please clarify.


The comment comes directly from the SOC document, so I'd have to check with Vijay to be certain; however, my interpretation is "check the context, which will contain overload information gleaned from the immediately preceding message (server wants to enter overload) or a prior message for which the period of validity is still in effect (server is in overload)." If you think there is a clearer way to say this, I'd be happy to see a concrete proposal.

- Section 4.2, pseudo-code, case inbound request:

When a server in overload receives requests from compliant clients, it is possible that the server still needs to reject some of these requests based its internal protective mechanisms.  This could correspond to the situation where a sudden increase in offered load, filtered by clients at the current Overload-Metric AVP (loss), exceeds the server internal protective mechanisms until the server refreshes the Overload-Metric AVP.

I assume this case is accounted for in the function “process_msg”. Should this be mentioned anywhere in the contribution or is that too obvious?


I believe that such rejections would generally be encompassed in "process_msg." I'm not sure the pseudocode needs to change, but it's probably worthwhile to add text to add text to 3.2.2.1 indicating that message recipients might need to reject messages from compliant hosts in the case that their load it too high despite use of the mechanism:

              In some circumstances, request recipients can
              become sufficiently overloaded that even those
              messages received from complaint clients can
              overwhelm its processing capabilities. Under
              such circumstances, nodes MAY begin treating
              a subset of such requests as if they were
              received from noncompliant peers (as explained
              in the following section).


- Section 8.2:

In the references, please add “draft-ietf-soc-overload-rate-control-03.txt”. That contribution proposes a rate control algorithm as an alternative to the loss control algorithm within SIP context.


Sure.


Typos:

 

-  Section 3.2.1, 5th paragraph:

“The authors….” since only one author, probably better to be singular.


This was just a bit of forward-leaning on my part, as I expect to have one or more co-authors prior to the document being final.

- Section 3.2.4:

“A node that receives a answer…” replace “a “with “an”


Thanks.

 

- Section 3.3, 2nd paragraph:

“…reflecting the a Agent’s overload…” replace “a” with “an”

 


Fixed. Thank you.

/a
--------------020502000507030303090102-- From jgunn6@csc.com Tue Oct 30 08:32:49 2012 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 30A8021F84D2; Tue, 30 Oct 2012 08:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWafPahaBJVQ; Tue, 30 Oct 2012 08:32:48 -0700 (PDT) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0877121F84B5; Tue, 30 Oct 2012 08:32:47 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-170.messagelabs.com!1351611166!20969278!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15426 invoked from network); 30 Oct 2012 15:32:47 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Oct 2012 15:32:47 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9UFWV5L029194; Tue, 30 Oct 2012 11:32:45 -0400 In-Reply-To: <5085C01C.4000900@nostrum.com> References: <20121022214256.15618.66760.idtracker@ietfa.amsl.com> <5085C01C.4000900@nostrum.com> To: Adam Roach MIME-Version: 1.0 X-KeepSent: 439D4C6E:6F69E9BF-85257AA7:00522C82; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Tue, 30 Oct 2012 11:32:39 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 10/30/2012 11:28:21 AM, Serialize complete at 10/30/2012 11:28:21 AM Content-Type: multipart/alternative; boundary="=_alternative 0055649085257AA7_=" Cc: dime-bounces@ietf.org, "DIME \(Diameter Maintenance and Extensions\) WG" Subject: Re: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2012 15:32:49 -0000 This is a multipart message in MIME format. --=_alternative 0055649085257AA7_= Content-Type: text/plain; charset="US-ASCII" First, I have to say that, while I am very familiar with the SIP Overload Control work, I am not as familiar with Diameter, so forgive me if some of my comments are simply reflections of that ignorance. You say here "- Only one scope (Host) is mandatory any longer. Others are "SHOULD-level." ... - "Host" scope has been renamed "Destination Host" scope to clarify that it does not refer to the sending host." But the text of draft-roach-dime-overload-ctrl-01 says " Destination-Host: This scope, which nodes SHOULD implement, pertains to all transactions that have a Destination-Host AVP matching the indicated value. Host: This scope, which nodes SHOULD implement, pertains to all transactions sent directly to the host matching the indicated value. Connection: This scope, which nodes MUST implement, pertains to all transactions sent on the same TCP connection or SCTP association. This scope has no details indicating which connection or association it applies to; instead, the recipient of an indication of "Connection" scope is to use the connection or association on which the message was received as the indicated connection or association. In other words, any use of Connection scope applies to "this connection." " I read that as "Connection" scope is mandatory and both "Destination-Host" and "Host" are at the "SHOULD-level" I don't have a preference, I am just confused. Second comment, in 2.2 on combining Scopes, you say " o If a transaction falls within more than one scope, the "most overloaded" scope is used for traffic shaping." If one scope is using the loss algorithm and is asking for a 10% reduction, and the other scope uses the rate algorithm, and is asking for a max of 100 messages per second, which is "more overloaded"? Even if one is asking for 10% reduction and the other is asking for 15% reduction, the one asking for 15% isn't necessarily "more overloaded", it may just have a more aggressive approach to overload control. It seems to me it makes more sense to say something like o If a transaction falls within more than one scope, the scope which will result in the greatest traffic reduction is used for traffic shaping. Janet From: Adam Roach To: "DIME (Diameter Maintenance and Extensions) WG" Date: 10/22/2012 05:52 PM Subject: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.txt Sent by: dime-bounces@ietf.org DIME working group: I have submitted a new version of the Diameter Overload document, based on early feedback on the -00 version. Please use the "Diff" link, below, for a comprehensive accounting of differences. At a high level, the main changes are: - Only one scope (Host) is mandatory any longer. Others are "SHOULD-level." - Scope negotiation has been replaced by supported scope announcement. This allows for asymmetric scopes in a connection. - "Host" scope has been renamed "Destination Host" scope to clarify that it does not refer to the sending host. - A new "Appendix D" has been added to discuss some of the design tradeoffs currently present in the document. I plan to discuss this -01 version during the upcoming meeting in Atlanta. Thanks! /a -------- Original Message -------- Subject: New Version Notification for draft-roach-dime-overload-ctrl-01.txt Date: Mon, 22 Oct 2012 14:42:56 -0700 From: internet-drafts@ietf.org To: adam@nostrum.com A new version of I-D, draft-roach-dime-overload-ctrl-01.txt has been successfully submitted by Adam Roach and posted to the IETF repository. Filename: draft-roach-dime-overload-ctrl Revision: 01 Title: A Mechanism for Diameter Overload Control Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 38 URL: http://www.ietf.org/internet-drafts/draft-roach-dime-overload-ctrl-01.txt Status: http://datatracker.ietf.org/doc/draft-roach-dime-overload-ctrl Htmlized: http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-roach-dime-overload-ctrl-01 Abstract: When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce or stop sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages. This document proposes a concrete, application-independent mechanism to address the challenge of communicating load and overload state among Diameter peers, and specifies an algorithm for load abatement to address such overload conditions as they occur. The load abatement algorithm is extensible, allowing for future documents to define additional load abatement approaches. The IETF Secretariat _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --=_alternative 0055649085257AA7_= Content-Type: text/html; charset="US-ASCII"
First, I have to say that, while I am very familiar with the SIP Overload Control work, I am not as familiar with Diameter, so forgive me if some of my comments are simply reflections of that ignorance.

You say here
 "- Only one scope (Host) is mandatory any longer. Others are "SHOULD-level."
...
- "Host" scope has been renamed "Destination Host" scope to clarify that it does not refer to the sending host."

But the text of  draft-roach-dime-overload-ctrl-01 says
"
   Destination-Host:  This scope, which nodes SHOULD implement, pertains
         to all transactions that have a Destination-Host AVP matching
         the indicated value.
 Host: This scope, which nodes SHOULD implement, pertains to all
         transactions sent directly to the host matching the indicated
         value.
   Connection:  This scope, which nodes MUST implement, pertains to all
         transactions sent on the same TCP connection or SCTP
         association.  This scope has no details indicating which
         connection or association it applies to; instead, the recipient
         of an indication of "Connection" scope is to use the connection
         or association on which the message was received as the
         indicated connection or association.  In other words, any use
         of Connection scope applies to "this connection." "

I read that as "Connection" scope is mandatory and both "Destination-Host" and  "Host" are at the "SHOULD-level"

I don't have a preference, I am just confused.

Second comment, in 2.2 on combining Scopes, you say
"   o  If a transaction falls within more than one scope, the "most
      overloaded" scope is used for traffic shaping."

If one scope is using the loss algorithm and is asking for a 10% reduction, and the other scope uses the rate algorithm, and is asking for a max of 100 messages per second, which is "more overloaded"?

Even if one is asking for 10% reduction and the other is asking for 15% reduction, the one asking for 15% isn't necessarily "more overloaded", it may just have a more aggressive  approach to overload control.

It seems to me it makes more sense to say something like
   o  If a transaction falls within more than one scope, the scope which will result in the greatest traffic reduction  is used for traffic shaping.

Janet

 



From:        Adam Roach <adam@nostrum.com>
To:        "DIME (Diameter Maintenance and Extensions) WG" <dime@ietf.org>
Date:        10/22/2012 05:52 PM
Subject:        [Dime] New Version Notification for        draft-roach-dime-overload-ctrl-01.txt
Sent by:        dime-bounces@ietf.org



DIME working group:

I have submitted a new version of the Diameter Overload document, based on early feedback on the -00 version. Please use the "Diff" link, below, for a comprehensive accounting of differences. At a high level, the main changes are:

- Only one scope (Host) is mandatory any longer. Others are "SHOULD-level."
- Scope negotiation has been replaced by supported scope announcement. This allows for asymmetric scopes in a connection.
- "Host" scope has been renamed "Destination Host" scope to clarify that it does not refer to the sending host.
- A new "Appendix D" has been added to discuss some of the design tradeoffs currently present in the document.

I plan to discuss this -01 version during the upcoming meeting in Atlanta.

Thanks!

/a


-------- Original Message --------
Subject:
New Version Notification for draft-roach-dime-overload-ctrl-01.txt
Date:
Mon, 22 Oct 2012 14:42:56 -0700
From:
internet-drafts@ietf.org
To:
adam@nostrum.com
A new version of I-D, draft-roach-dime-overload-ctrl-01.txt
has been successfully submitted by Adam Roach and posted to the
IETF repository.

Filename:                  draft-roach-dime-overload-ctrl
Revision:                  01
Title:                                   A Mechanism for Diameter Overload Control
Creation date:                  2012-10-22
WG ID:                                   Individual Submission
Number of pages: 38
URL:             http://www.ietf.org/internet-drafts/draft-roach-dime-overload-ctrl-01.txt
Status:          http://datatracker.ietf.org/doc/draft-roach-dime-overload-ctrl
Htmlized:        http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-roach-dime-overload-ctrl-01

Abstract:
  When a Diameter server or agent becomes overloaded, it needs to be
  able to gracefully reduce its load, typically by informing clients to
  reduce or stop sending traffic for some period of time.  Otherwise,
  it must continue to expend resources parsing and responding to
  Diameter messages.

  This document proposes a concrete, application-independent mechanism
  to address the challenge of communicating load and overload state
  among Diameter peers, and specifies an algorithm for load abatement
  to address such overload conditions as they occur.  The load
  abatement algorithm is extensible, allowing for future documents to
  define additional load abatement approaches.

                                                                                 


The IETF Secretariat


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--=_alternative 0055649085257AA7_=-- From emcmurry@computer.org Tue Oct 30 14:08:58 2012 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 4B4D221F85AB for ; Tue, 30 Oct 2012 14:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaTwm8gp8U1W for ; Tue, 30 Oct 2012 14:08:56 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id B972B21F84E9 for ; Tue, 30 Oct 2012 14:08:55 -0700 (PDT) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TTJ3O-0009Oc-Hh; Tue, 30 Oct 2012 21:08:54 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 057667FC864; Tue, 30 Oct 2012 16:08:53 -0500 (CDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19mYULKRM5SkzJrdaPITmwWkyYX8DH/2X4= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5V8JuvZLNk5; Tue, 30 Oct 2012 16:08:52 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 7415A7FC850; Tue, 30 Oct 2012 16:08:52 -0500 (CDT) From: Eric McMurry Content-Type: multipart/alternative; boundary="Apple-Mail=_C764B48F-3F48-43DE-96BF-B4CE417AE953" Message-Id: <9BE16775-D5D4-4822-B5E3-68C9912F428D@computer.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Tue, 30 Oct 2012 16:08:51 -0500 References: <709FF87F-1E3E-4117-A848-18E927AB898B@tekelec.com> To: "dime@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2012 21:08:58 -0000 --Apple-Mail=_C764B48F-3F48-43DE-96BF-B4CE417AE953 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Janet Gunn has been kind enough to provide comments on the diameter = overload control requirements. My responses are inline. Thanks Janet! Begin forwarded message: >=20 > On Oct 29, 2012, at 19:20 , Janet P Gunn wrote: >=20 > Eric, here are the rest of my comments. They are just kind of jotted = down rather than being properly organized.=20 >=20 >=20 > Global editorial- change =93an network=94 to =93a network=94=20 fixed. thanks >=20 > Sec 2.2 4th para. Editorial=20 > =93If one server notifies=20 > the agent that it has become overloaded, the notification should = not=20 > be passed back to the client in a way where the client could=20 > mistakenly perceive the agent itself as being overloaded.=94=20 > Replace =93where=94 by =93that=94=20 >=20 got it. > Sec 2.3 Interconnect=20 >=20 > This section appears to talk about =93server to server=94. The rest = of the document is about client to/from server. Does it matter?=20 >=20 >=20 the servers on either end are likely proxies that are acting as both = clients and servers and this use case is a bit different from the = others. I could use element in place of server, but that would be more = inconsistent I think. > paragraph after fig 7 (and elsewhere) Editorial=20 > Replace =93different than=94 with =93different from=94.=20 ack. >=20 > In=20 > =93which limits how overload and loading information can be=20 > sent.=93=20 > change=94 how=94 to =93which=92 (or =93how much=94)=20 good catch. > In=20 > =93=85the network operators may not want the=20 > interconnect to use overload or loading information intended to = pass=20 > through the interconnect even if the elements in the interconnect=20= > network do support diameter overload control.=94=20 > Should that be =93not intended to pass=94?=20 how about: the network operators may not want the interconnect to use overload or loading information = intended to to be conveyed to elements outside of the interconnect = network, even if the elements in the interconnect network do support = diameter overload control is that more clear? >=20 > 3 existing mechanisms=20 > In this section you talk about =93peers=94 instead of clients and = servers. Which is it? (to me, clients/servers are not =93peers)=20 Diameter has applications that are bidirectional, which makes this a bit = tricky. We used the term "peer", which shows up throughout the = document, generally to mean another element that is participating in a = Diameter connection. That could be a client or a server (or both) in = any given case. >=20 > 4. issues with current mechanisms=20 > What is the antecedent for =93This=94 in the second sentence?=20 how about this inadequacy instead of just this? This inadequacy may, in turn, contribute...... >=20 > 5.1=20 > Second para Editorial=20 > Change=20 > =93did not have an equivalent load control mechanism which is provided=20= > in the more traditional SS7 elements in GSM=94=20 > to=20 > =93did not have an equivalent load control mechanism to the ones = provided=20 > in the more traditional SS7 elements in GSM=94=20 got it. >=20 > third para=20 > =93Smartphones contribute much more heavily to. ..=94=20 > More heavily than what? GSM?=20 non-smart phones. clarified that. >=20 > Last set of bullets=20 > =93 o first by generating excessive signaling load towards the HLR = that=20 > is ten times that from a non-smartphone,=94=20 > Always/every time? On average? At worst?=20 good question. Ben, do you remember where this came from originally? >=20 > 5.2=20 > What about the scenario of the registration storm when a power outage = (or node failure ) ends, and the node is trying to get started?=20 yes, that is mentioned in the study. I'll mention it here also. >=20 > Last para=20 > =93While this study is concerned with=85=94=20 >=20 > What is =93this study=94? This ID? The technical report mentioned 4 = paragraphs earlier? Need to make antecedent clear.=20 >=20 > Sec 6=20 >=20 >=20 > I am having difficulty with Req 8. There are two quote different = things, and they are not directly related.=20 >=20 > 1- The mechanism MUST allow nodes to shed load without = introducing oscillations.=20 > To me, this is covered by Req 7. =93Not inducing oscillations=94 is = one of the things covered by =93stable=94 . You could add the = reference to oscillations to the text in Req 7 for additional clarity.=20= >=20 > 2- Avoiding stale information.=20 > This is important, but it has little, if anything, to do with = avoiding oscillations=20 > I=92d let it stand alone=20 > =93nodes MUST be able to=20 > distinguish current overload information from outdated or = out of order=20 > information, and to make decisions using the most = currently=20 > available information.=94=20 >=20 okay > I am not sure that I understand what you are looking for in Req 14.=20 >=20 > =93=20 > REQ 14: Some scenarios that result in overload involve a rapid=20 > increase of traffic with little time between normal levels=20= > and overload inducing levels. The mechanism SHOULD = provide=20 > for increased feedback when traffic levels increase. The=20= > mechanism MUST NOT do this in such a way that it increases=20= > the number of messages while at high loads.=94=20 >=20 > If you have a sudden increase in load, you need a very RAPID feedback = on the load changes, but I don=92t see that you need INCREASED feedback. = In fact =93increased feedback=94 , by itself, would seem to violate REQ = 13, not introducing additional work.=20 >=20 > It is fine to take advantage of an increased message rate if it = exists. But I do not think it is a good idea to REQUIRE an increased = rate.=20 > I also don=92t think it Is a good idea to write the requirements so = that only solutions that =93piggyback=94 on existing messages can be = considered.=20 I agree. 13 covers the last part of that req and rapid would be a more = precise term. So it becomes: Some scenarios that result in overload involve a rapid increase of traffic with little time between normal levels and overload = inducing levels. The mechanism SHOULD provide for rapid feedback when traffic levels increase. Ben, does this sound reasonable to you? >=20 > Req 17 says=20 > =93 In a mixed environment with nodes that support the overload=20 > control mechanism and that do not, the mechanism MUST NOT=20= > result in less useful throughput than would have resulted = if=20 > it were not present. It SHOULD result in less severe=20 > congestion in this environment.=94=20 > I find this confusing.=20 > =85 less useful throughput than would have resulted if WHAT were = not present? The nonconforming nodes? The mechanism?=20 > =85 Less severe congestion than WHAT? Without the nonconforming nodes? = Without the mechanism?=20 >=20 > Perhaps=20 > =93 In a mixed environment with nodes that support the overload=20 > control mechanism and that do not, the mechanism MUST=20 > result in more useful throughput than in an environment = with no overload control.=94=20 I can change it to a positive statement and replace the last pronoun. I = think the "or equal to" part of the requirement should not be removed = though. How about: In a mixed environment with nodes that support the overload control mechanism and that do not, the mechanism MUST result in at = least as much useful throughput as would have resulted if the mechanism = were not present. >=20 >=20 > Req 25=20 > =93 The mechanism MUST provide a mechanism for indicating load=20 > levels even when not in an overloaded condition, to assist=20= > nodes making decisions to prevent overload conditions from=20= > occurring.=94=20 > I don=92t think that this is needed, given that Req 22 says that = =93Overload is not a binary state.=94 The only difference between = =93preventing overload conditions form occurring=94 and =93degrees of = overload=94 what you define as overload. Maybe you should fold some of = this text into Req 22 to make it clearer.=20 22 covers signaling of overload. 25 is for signaling load, when not = overloaded. >=20 > Req 27=20 >=20 > Add =93not throttled=94=20 > REQ 27: The mechanism MUST NOT prevent a node from prioritizing=20 > requests based on any local policy, so that certain = requests=20 > are given preferential treatment, given additional=20 > retransmission, not throttled, or processed ahead of = others.=20 okay >=20 >=20 > Req 34=20 > =93 The mechanism MUST provide a method for extending the=20 > information communicated and the algorithms used for=20 > overload control.=94=20 >=20 > This is the first mention of such algorithms. I think you need = something earlier about supporting multiple algorithms, before you add a = requirement about extending algorithms.=20 >=20 This probably could use some mention in the front matter. > There are several requirements in the SIP Overload document that do = not seem to have parallels in this document (but I may have missed = them). Most of them seem as if they would be relevant to DIME.=20 >=20 > SIP REQ 6: When overload is signaled by means of a specific message, = the=20 > message must clearly indicate that it is being sent because of=20= > overload, as opposed to other, non overload-based failure=20 > conditions. This requirement is meant to avoid some of the=20 > problems that have arisen from the reuse of the 503 response = code=20 > for multiple purposes. Of course, overload is also signaled by=20= > lack of response to requests. This requirement applies only to=20= > explicit overload signals.=20 REQ 20: Any explicit overload indication MUST distinguish between actual overload, as opposed to other, non-overload related failures. >=20 > SIP REQ 8: The mechanism shall ensure that, when a request was not=20= > processed successfully due to overload (or failure) of a=20 > downstream element, the request will not be retried on another=20= > element that is also overloaded or whose status is unknown. = This=20 > requirement derives from REQ 1.=20 REQ 23: The mechanism MUST enable a supporting node to minimize the chance that retries due to an overloaded or failed node result in additional traffic to other overloaded nodes, or cause additional nodes to become overloaded. Moreover, the mechanism SHOULD provide unambiguous directions to clients on when they should retry a request and when they should not considering the various causes of overload such as avalanche restart. >=20 > SIP REQ 9: That a request has been rejected from an overloaded = element=20 > shall not unduly restrict the ability of that request to be=20 > submitted to and processed by an element that is not overloaded.=20= > This requirement derives from REQ 1=20 REQ 24: The mechanism MUST provide sufficient information to enable a load balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them. >=20 > SIP REQ 10: The mechanism should support servers that receive = requests=20 > from a large number of different upstream elements, where the = set=20 > of upstream elements is not enumerable. (May not be relevant to = Diameter)=20 >=20 > SIP REQ 11: The mechanism should support servers that receive = requests=20 > from a finite set of upstream elements, where the set of = upstream=20 > elements is enumerable.=20 REQ 11: The overload mechanism MUST be scalable. That is, it MUST be able to operate in different sized networks. >=20 > SIP REQ 16: The mechanism should attempt to minimize the overhead = of the=20 > overload control messaging.=20 REQ 13: The mechanism MUST NOT introduce substantial additional work for node in an overloaded state. For example, a requirement for an overloaded node to send overload information every time it received a new request would introduce substantial work. Existing messaging is likely to have the characteristic of increasing as an overload condition approaches, allowing for the possibility of increased feedback for information piggybacked on it. >=20 > SIP REQ 23: It must be possible for the overload mechanism to work = in=20 > cases where there is a load balancer in front of a farm of=20 > proxies.=20 >=20 REQ 24: The mechanism MUST provide sufficient information to enable a load balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them. > Janet=20 >=20 >=20 >=20 > This is a PRIVATE message. If you are not the intended recipient, = please delete without copying and kindly advise us by e-mail of the = mistake in delivery. NOTE: Regardless of content, this e-mail shall not = operate to bind CSC to any order or other contract unless pursuant to = explicit written agreement or government initiative expressly permitting = the use of e-mail for such purpose.=20 >=20 --Apple-Mail=_C764B48F-3F48-43DE-96BF-B4CE417AE953 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Janet = Gunn has been kind enough to provide comments on the diameter overload = control requirements.  My responses  are = inline.

Thanks = Janet!



Begin forwarded = message:


On Oct 29, 2012, at 19:20 , = Janet P Gunn <jgunn6@csc.com> = wrote:

Eric, here are the = rest of my comments.  They are just kind of jotted down rather than being properly = organized.


Global editorial- change =93an = network=94 to =93a network=94

fixed. =  thanks


Sec 2.2 4th para. = Editorial
=93If one server notifies
   the agent that it has = become overloaded, the notification should not
   be passed back to the = client in a way where the client could
   mistakenly perceive = the agent itself as being overloaded.=94
Replace =93where=94 by = =93that=94


got it.

Sec 2.3   = Interconnect

This section appears to talk about = =93server to server=94.  The rest of the document is about client to/from = server.  Does it matter?



the servers on either end are = likely proxies that are acting as both clients and servers and this use = case is a bit different from the others.  I could use element in = place of server, but that would be more inconsistent I = think.

paragraph after fig 7 (and elsewhere) Editorial
Replace =93different than=94 with = =93different from=94.

ack.


In
=93which limits how overload and = loading information can be
   sent.=93
change=94 how=94 to =93which=92 = (or =93how much=94)

good catch.

In
 =93=85the network operators = may not want the
   interconnect to use = overload or loading information intended to pass
   through the = interconnect even if the elements in the interconnect
   network do support = diameter overload control.=94
Should that be =93not intended to = pass=94?

how = about:

the network operators may = not
         want the interconnect to = use overload or loading information intended
    =      to to be conveyed to elements outside of the = interconnect network,
         even = if the elements in the interconnect network do support = diameter
         overload = control

is that more = clear?


3 existing mechanisms
In this section you talk about = =93peers=94 instead of clients and servers.  Which is it? (to me, = clients/servers are not =93peers)

Diameter has applications that are = bidirectional, which makes this a bit tricky.  We used the term = "peer", which shows up throughout the document, generally to mean = another element that is participating in a Diameter connection. =  That could be a client or a server (or both) in any given = case.


4. issues with current = mechanisms
What is the antecedent for =93This=94= in the second sentence?

how about this inadequacy instead = of just this?
This inadequacy may, in turn, = contribute......


5.1
Second para Editorial
Change
=93did not have an equivalent load = control mechanism which is provided
   in the more = traditional SS7 elements in GSM=94
to
=93did not have an equivalent load = control mechanism to the ones provided
   in the more = traditional SS7 elements in GSM=94

got it.


third para
=93Smartphones contribute much = more heavily to. ..=94
More heavily than what? = GSM?

non-smart phones.  clarified = that.


Last set of bullets
=93   o  first by = generating excessive signaling load towards the HLR that
      is ten times = that from a non-smartphone,=94
Always/every time? On average? At = worst?

good question.  Ben, do you = remember where this came from originally?


5.2
What about the scenario of the = registration storm when a power outage (or node failure ) ends, and the node is = trying to get started?

yes, that is mentioned in the = study.  I'll mention it here also.


Last para
=93While this study is concerned = with=85=94

What is =93this study=94? =  This ID? The technical report mentioned 4 paragraphs earlier?  Need to make  antecedent clear.

Sec 6


I am having difficulty with Req 8. =  There are two quote different things, and they are not directly = related.

1-        The mechanism MUST allow nodes to shed load without introducing = oscillations.
To me, this is covered by Req 7. =  =93Not inducing oscillations=94 is one of the things covered by  =93stable=94= .  You could add the reference to oscillations to the text in Req 7 for additional clarity.

2-       =  Avoiding stale information.
 This is important, but it = has little, if anything, to do with avoiding oscillations
 I=92d let it stand = alone
=93nodes MUST be able to
          =   distinguish current overload information from outdated or out of = order
          =   information, and to make decisions using the most currently
          =   available information.=94
=

okay


I am not sure that I = understand what you are looking for in Req 14.

=93
   REQ 14:  Some = scenarios that result in overload involve a rapid
          =   increase of traffic with little time between normal levels
          =   and overload inducing levels.  The mechanism SHOULD provide
          =   for increased feedback when traffic levels increase.  The
          =   mechanism MUST NOT do this in such a way that it increases
          =   the number of messages while at high loads.=94

If you have a sudden increase in = load, you need a very RAPID feedback on the load changes, but I don=92t see = that you need INCREASED feedback. In fact =93increased feedback=94 , by = itself, would seem to violate REQ 13, not introducing additional work.

It is fine to take advantage of an = increased message rate if it exists.  But I do not think it is a good idea to REQUIRE an increased rate.
I also don=92t think it Is a good = idea to write the requirements so that only solutions that =93piggyback=94 on = existing messages can be considered.

I agree.  13 covers the last = part of that req and rapid would be a more precise term.  So it = becomes:

Some scenarios that result in = overload involve a rapid increase of
      =     traffic with little time between normal levels and = overload inducing
          levels. = The mechanism SHOULD provide for rapid feedback when
  =         traffic levels = increase.


Ben, does this sound = reasonable to you?



Req 17 says
=93    In a mixed = environment with nodes that support the overload
          =   control mechanism and that do not, the mechanism MUST NOT
          =   result in less useful throughput than would have resulted if
          =   it were not present.  It SHOULD result in less severe
          =   congestion in this environment.=94
I find this confusing.
 =85  less useful = throughput than would have resulted if  WHAT were not present? The nonconforming = nodes?  The mechanism?
=85 Less severe congestion than = WHAT? Without the nonconforming nodes?  Without the mechanism?

Perhaps
=93    In a mixed = environment with nodes that support the overload
          =   control mechanism and that do not, the mechanism MUST
          =   result in more  useful throughput than in an environment with no = overload control.=94

I can change it to a positive = statement and replace the last pronoun.  I think the "or equal to" = part of the requirement should not be removed though.  How = about:

In a mixed environment with nodes = that support the overload control
        =   mechanism and that do not, the mechanism MUST result in at least = as
          much useful throughput = as would have resulted if the mechanism were
    =       not present.



Req 25
=93  The mechanism MUST = provide a mechanism for indicating load
          =   levels even when not in an overloaded condition, to assist
          =   nodes making decisions to prevent overload conditions from
          =   occurring.=94
I don=92t think that this is = needed, given that  Req 22 says that =93Overload is not a binary state.=94 The = only difference between =93preventing overload conditions form occurring=94 = and =93degrees of overload=94 what you define as overload.  Maybe you = should fold some of this text into Req 22 to make it clearer.

22 covers signaling of overload. =  25 is for signaling load, when not = overloaded.


Req 27

Add =93not throttled=94
   REQ 27:  The = mechanism MUST NOT prevent a node from prioritizing
          =   requests based on any local policy, so that certain requests
          =   are given preferential treatment, given additional
          =   retransmission, not throttled,  or processed ahead of = others.

okay



Req 34
=93 The mechanism MUST provide a = method for extending the
          =   information communicated and the algorithms used for
          =   overload control.=94

This is the first mention of such = algorithms.  I think you need something earlier about supporting multiple = algorithms, before you add a requirement about extending algorithms.


This probably could use some = mention in the front matter.

There are several requirements in the SIP Overload document that do not seem to have parallels in this document = (but I may have missed them).  Most of them seem as if they would be = relevant to DIME.

SIP  REQ 6:  When = overload is signaled by means of a specific message, the
      message must = clearly indicate that it is being sent because of
      overload, as = opposed to other, non overload-based failure
      conditions. =  This requirement is meant to avoid some of the
      problems that = have arisen from the reuse of the 503 response code
      for multiple = purposes.  Of course, overload is also signaled by
      lack of = response to requests.  This requirement applies only to
      explicit = overload signals.

REQ 20:  Any explicit = overload indication MUST distinguish between
    =         actual overload, as opposed to other, = non-overload related
            = failures.



SIP   REQ 8:  The = mechanism shall ensure that, when a request was not
      processed = successfully due to overload (or failure) of a
      downstream = element, the request will not be retried on another
      element that = is also overloaded or whose status is unknown.  This
      requirement = derives from REQ 1.

REQ 23:  The mechanism = MUST enable a supporting node to minimize the
    =         chance that retries due to an overloaded or = failed node
            result = in additional traffic to other overloaded nodes, or
  =           cause additional nodes to become = overloaded.  Moreover, the
        =     mechanism SHOULD provide unambiguous directions to = clients
            on when they = should retry a request and when they should not
    =         considering the various causes of overload = such as avalanche
            = restart.


SIP  REQ 9:  That a = request has been rejected from an overloaded element
      shall not = unduly restrict the ability of that request to be
      submitted to = and processed by an element that is not overloaded.
      This = requirement derives from REQ 1

REQ 24:  The mechanism = MUST provide sufficient information to enable
    =         a load balancing node to divert messages = that are rejected
            or = otherwise throttled by an overloaded upstream node to
  =           other upstream nodes that are the = most likely to have
            = sufficient capacity to process them.


SIP   REQ 10:  The = mechanism should support servers that receive requests
      from a large = number of different upstream elements, where the set
      of upstream = elements is not enumerable. (May not be relevant to Diameter)

SIP   REQ 11:  The = mechanism should support servers that receive requests
      from a finite = set of upstream elements, where the set of upstream
      elements is = enumerable.

REQ 11:  The overload = mechanism MUST be scalable.  That is, it MUST
  =           be able to operate in different sized = networks.



SIP    REQ 16:  The = mechanism should attempt to minimize the overhead of the
      overload = control messaging.

REQ 13:  The mechanism = MUST NOT introduce substantial additional work
    =         for node in an overloaded state.  For = example, a requirement
          =   for an overloaded node to send overload information = every
            time it = received a new request would introduce substantial
  =           work.  Existing messaging is = likely to have the
            = characteristic of increasing as an overload condition
  =           approaches, allowing for the = possibility of increased
          =   feedback for information piggybacked on = it.


SIP   REQ 23:  It must = be possible for the overload mechanism to work in
      cases where = there is a load balancer in front of a farm of
      = proxies.


REQ 24:  The mechanism = MUST provide sufficient information to enable
    =         a load balancing node to divert messages = that are rejected
            or = otherwise throttled by an overloaded upstream node to
  =           other upstream nodes that are the = most likely to have
            = sufficient capacity to process = them.


Janet



This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit = written agreement or government initiative expressly permitting the use of = e-mail for such purpose.


= --Apple-Mail=_C764B48F-3F48-43DE-96BF-B4CE417AE953-- From ben@nostrum.com Tue Oct 30 14:20:12 2012 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 B39F321F85E6 for ; Tue, 30 Oct 2012 14:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngln2He8MJfN for ; Tue, 30 Oct 2012 14:20:12 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8D721F85E1 for ; Tue, 30 Oct 2012 14:20:12 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9ULJY8f032041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2012 16:19:34 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <9BE16775-D5D4-4822-B5E3-68C9912F428D@computer.org> Date: Tue, 30 Oct 2012 16:19:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1B1C90C6-405D-438C-9889-777400B50C79@nostrum.com> References: <709FF87F-1E3E-4117-A848-18E927AB898B@tekelec.com> <9BE16775-D5D4-4822-B5E3-68C9912F428D@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2012 21:20:12 -0000 Hi, replying to the items where you mentioned my name: On Oct 30, 2012, at 2:50 PM, Eric McMurry = wrote: [...] >>=20 >> Last set of bullets=20 >> =93 o first by generating excessive signaling load towards the HLR = that=20 >> is ten times that from a non-smartphone,=94=20 >> Always/every time? On average? At worst?=20 >=20 > good question. Ben, do you remember where this came from originally? >=20 That came from discussions with Martin, and his presentation in = Vancouver. I suspect the 10x part was somewhat rhetorical, so it might = make more sense to say "many times" or even "substantially more". IIRC, = this referred to devices that hunt between the 3G and 2G mobile = networks. While I guess the device doesn't have to be a smart-phone to = do that, in practice those were the devices that did. I suspect newer = LTE devices that handle voice by switching back to 3G may cause similar = issues.=20 =20 Maybe it would be less hyperbolic to say something to the effect of = "newer classes of mobile devices [may/often] create substantially higher = signaling loads"? [...] >> REQ 14: Some scenarios that result in overload involve a rapid=20 >> increase of traffic with little time between normal levels=20= >> and overload inducing levels. The mechanism SHOULD = provide=20 >> for increased feedback when traffic levels increase. The=20= >> mechanism MUST NOT do this in such a way that it increases=20= >> the number of messages while at high loads.=94=20 >>=20 >> If you have a sudden increase in load, you need a very RAPID feedback = on the load changes, but I don=92t see that you need INCREASED feedback. = In fact =93increased feedback=94 , by itself, would seem to violate REQ = 13, not introducing additional work.=20 >>=20 >> It is fine to take advantage of an increased message rate if it = exists. But I do not think it is a good idea to REQUIRE an increased = rate.=20 >> I also don=92t think it Is a good idea to write the requirements so = that only solutions that =93piggyback=94 on existing messages can be = considered.=20 >=20 > I agree. 13 covers the last part of that req and rapid would be a = more precise term. So it becomes: >=20 > Some scenarios that result in overload involve a rapid increase of > traffic with little time between normal levels and overload = inducing > levels. The mechanism SHOULD provide for rapid feedback when > traffic levels increase. >=20 >=20 > Ben, does this sound reasonable to you? >=20 In principle, yes, although I worry that we will get wrapped around the = meaning of rapid. Can we say "sufficiently rapid that [something]"? Thanks! Ben.= From jgunn6@csc.com Tue Oct 30 14:31:48 2012 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 01D8121F8549 for ; Tue, 30 Oct 2012 14:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50DZLRyv2t4g for ; Tue, 30 Oct 2012 14:31:47 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by ietfa.amsl.com (Postfix) with ESMTP id F177821F8529 for ; Tue, 30 Oct 2012 14:31:46 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-171.messagelabs.com!1351632703!31465712!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10405 invoked from network); 30 Oct 2012 21:31:44 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-9.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Oct 2012 21:31:44 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9ULVhVK006522; Tue, 30 Oct 2012 17:31:43 -0400 In-Reply-To: <9BE16775-D5D4-4822-B5E3-68C9912F428D@computer.org> References: <709FF87F-1E3E-4117-A848-18E927AB898B@tekelec.com> <9BE16775-D5D4-4822-B5E3-68C9912F428D@computer.org> To: Eric McMurry MIME-Version: 1.0 X-KeepSent: C6847915:171AD35F-85257AA7:0075BDFA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Tue, 30 Oct 2012 17:31:41 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 10/30/2012 05:27:18 PM, Serialize complete at 10/30/2012 05:27:18 PM Content-Type: multipart/alternative; boundary="=_alternative 0076426885257AA7_=" Cc: "dime@ietf.org" Subject: Re: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2012 21:31:48 -0000 This is a multipart message in MIME format. --=_alternative 0076426885257AA7_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 TXkgZnVydGhlciBjb21tZW50cyBpbiBsaW5lDQoNCg0KDQpJbiANCiDigJzigKZ0aGUgbmV0d29y ayBvcGVyYXRvcnMgbWF5IG5vdCB3YW50IHRoZSANCiAgIGludGVyY29ubmVjdCB0byB1c2Ugb3Zl cmxvYWQgb3IgbG9hZGluZyBpbmZvcm1hdGlvbiBpbnRlbmRlZCB0byBwYXNzIA0KICAgdGhyb3Vn aCB0aGUgaW50ZXJjb25uZWN0IGV2ZW4gaWYgdGhlIGVsZW1lbnRzIGluIHRoZSBpbnRlcmNvbm5l Y3QgDQogICBuZXR3b3JrIGRvIHN1cHBvcnQgZGlhbWV0ZXIgb3ZlcmxvYWQgY29udHJvbC7igJ0g DQpTaG91bGQgdGhhdCBiZSDigJxub3QgaW50ZW5kZWQgdG8gcGFzc+KAnT8gDQoNCmhvdyBhYm91 dDoNCg0KdGhlIG5ldHdvcmsgb3BlcmF0b3JzIG1heSBub3QNCiAgICAgICAgIHdhbnQgdGhlIGlu dGVyY29ubmVjdCB0byB1c2Ugb3ZlcmxvYWQgb3IgbG9hZGluZyBpbmZvcm1hdGlvbiANCmludGVu ZGVkDQogICAgICAgICB0byB0byBiZSBjb252ZXllZCB0byBlbGVtZW50cyBvdXRzaWRlIG9mIHRo ZSBpbnRlcmNvbm5lY3QgDQpuZXR3b3JrLA0KICAgICAgICAgZXZlbiBpZiB0aGUgZWxlbWVudHMg aW4gdGhlIGludGVyY29ubmVjdCBuZXR3b3JrIGRvIHN1cHBvcnQgDQpkaWFtZXRlcg0KICAgICAg ICAgb3ZlcmxvYWQgY29udHJvbA0KDQppcyB0aGF0IG1vcmUgY2xlYXI/DQoNCjxKUEc+ICBJIGRv bid0IHRoaW5rIHRoYXQgaGVscHMgIEl0IHN0aWxsIHNlZW1zIGNvbnRyYWRpY3RvcnkgLSAgIm1h eSBub3QgDQp3YW50IC4uLiB0byB1c2UgLi4uaW5mb3JtYXRpb24gIGludGVuZGVkIHRvIGJlIGNv bnZleWVkIHRvIGVsZW1lbnRzIA0Kb3V0c2lkZS4uLiINCkl0IHNlZW1zIHRoYXQgImluZm9ybWF0 aW9uICBpbnRlbmRlZCB0byBiZSBjb252ZXllZCB0byBlbGVtZW50cyBvdXRzaWRlIA0KLi4uIiBp cyBFWEFDVExZICAoYW5kIG9ubHkpIHdoYXQgeW91IERPICBXQU5UIHRoZSBpbnRlcmNvbm5lY3Qg dG8gdXNlLg0KDQouLi4NCg0KDQpMYXN0IHBhcmEgDQrigJxXaGlsZSB0aGlzIHN0dWR5IGlzIGNv bmNlcm5lZCB3aXRo4oCm4oCdIA0KDQpXaGF0IGlzIOKAnHRoaXMgc3R1ZHnigJ0/ICBUaGlzIElE PyBUaGUgdGVjaG5pY2FsIHJlcG9ydCBtZW50aW9uZWQgNCANCnBhcmFncmFwaHMgZWFybGllcj8g IE5lZWQgdG8gbWFrZSAgYW50ZWNlZGVudCBjbGVhci4gDQoNCi4uLg0KDQpSZXEgMjUgDQrigJwg IFRoZSBtZWNoYW5pc20gTVVTVCBwcm92aWRlIGEgbWVjaGFuaXNtIGZvciBpbmRpY2F0aW5nIGxv YWQgDQogICAgICAgICAgICBsZXZlbHMgZXZlbiB3aGVuIG5vdCBpbiBhbiBvdmVybG9hZGVkIGNv bmRpdGlvbiwgdG8gYXNzaXN0IA0KICAgICAgICAgICAgbm9kZXMgbWFraW5nIGRlY2lzaW9ucyB0 byBwcmV2ZW50IG92ZXJsb2FkIGNvbmRpdGlvbnMgZnJvbSANCiAgICAgICAgICAgIG9jY3Vycmlu Zy7igJ0gDQpJIGRvbuKAmXQgdGhpbmsgdGhhdCB0aGlzIGlzIG5lZWRlZCwgZ2l2ZW4gdGhhdCAg UmVxIDIyIHNheXMgdGhhdCDigJxPdmVybG9hZCANCmlzIG5vdCBhIGJpbmFyeSBzdGF0ZS7igJ0g VGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIOKAnHByZXZlbnRpbmcgb3ZlcmxvYWQgDQpjb25k aXRpb25zIGZvcm0gb2NjdXJyaW5n4oCdIGFuZCDigJxkZWdyZWVzIG9mIG92ZXJsb2Fk4oCdIHdo YXQgeW91IGRlZmluZSBhcyANCm92ZXJsb2FkLiAgTWF5YmUgeW91IHNob3VsZCBmb2xkIHNvbWUg b2YgdGhpcyB0ZXh0IGludG8gUmVxIDIyIHRvIG1ha2UgaXQgDQpjbGVhcmVyLiANCg0KMjIgY292 ZXJzIHNpZ25hbGluZyBvZiBvdmVybG9hZC4gIDI1IGlzIGZvciBzaWduYWxpbmcgbG9hZCwgd2hl biBub3QgDQpvdmVybG9hZGVkLg0KDQo8SlBHPiBPSywgYnV0IGl0IHNlZW1zIHRvIG1lIHRoYXQg dGhlIGRpc3RpbmN0aW9uIHNob3VsZCBiZSBiZXR3ZWVuDQpBLSAgICJJbmRpY2F0aW5nIHRoYXQg SSB3YW50IHRoZSBvdGhlciBlbmQgdG8gZG8gc29tZXRoaW5nIHRvIHJlZHVjZSB0aGUgDQp0cmFm ZmljIGl0IGVuZHMgdG8gbWUgIiAod2hpY2ggY291bGQgYmUgImFwcHJvYWNoaW5nIG92ZXJsb2Fk IiBvciAiYWxyZWFkeSANCmluIG92ZXJsb2FkKQ0KYW5kDQpCLSAiSW5kaWNhdGluZyB0aGF0IEkg c3VwcG9ydCBPdmVybG9hZCBjb250cm9sLCBidXQgSSBkb24ndCBuZWVkIHRoZSBvdGhlciANCmVu ZCB0byBkbyBhbnl0aGluZyBhYm91dCBpdCBhdCB0aGUgbW9tZW50LiINCg0KcmF0aGVyIHRoYW4g YmV0d2VlbiAgImxvYWQgd2hlbiBvdmVybG9hZGVkICIgYW5kICJsb2FkIHdoZW4gbm90IA0Kb3Zl cmxvYWRlZCINCg0KRnVydGhlcm1vcmUsIEkgZG8gbm90IHRoaW5rIHRoZXJlIGlzIGEgbG90IG9m IHZhbHVlIChmb3Igb3ZlcmxvYWQgY29udHJvbCkgDQppbiAiaW5kaWNhdGluZyBsb2FkIGxldmVs cyIuIChJdCBtaWdodCBiZSB2YWx1YWJsZSBmb3IgbG9hZC1iYWxhbmNpbmcuKSANCkZvciBvdmVy bG9hZCBjb250cm9sLCB0aGUgdmFsdWUgaXMgaW4gdGVsbGluZyB0aGUgb3RoZXIgZW5kIHRoYXQg dGhleSBuZWVkIA0KdG8gcmVkdWNlIHRoZWlyIHRyYWZmaWMgdG8gbWUgKGFuZCBob3cgbXVjaCku DQoNCg0KLi4uDQoNCg0KDQoNCg0KVGhlcmUgYXJlIHNldmVyYWwgcmVxdWlyZW1lbnRzIGluIHRo ZSBTSVAgT3ZlcmxvYWQgZG9jdW1lbnQgdGhhdCBkbyBub3QgDQpzZWVtIHRvIGhhdmUgcGFyYWxs ZWxzIGluIHRoaXMgZG9jdW1lbnQgKGJ1dCBJIG1heSBoYXZlIG1pc3NlZCB0aGVtKS4gTW9zdCAN Cm9mIHRoZW0gc2VlbSBhcyBpZiB0aGV5IHdvdWxkIGJlIHJlbGV2YW50IHRvIERJTUUuIA0KDQpP SyBvbiBtb3N0IG9mIHRoZW0tIG15IGJyYWluIHdhcyBnb2luZyBpbiBjaXJjbGVzIHRyeWluZyB0 byBnbyBiYWNrIGFuZCANCmZvcnRoIGJldHdlZW4gdGhlIGRvY3MuDQoNCi4uLg0KDQoNCg0KU0lQ ICAgUkVRIDEwOiAgVGhlIG1lY2hhbmlzbSBzaG91bGQgc3VwcG9ydCBzZXJ2ZXJzIHRoYXQgcmVj ZWl2ZSByZXF1ZXN0cyANCiAgICAgIGZyb20gYSBsYXJnZSBudW1iZXIgb2YgZGlmZmVyZW50IHVw c3RyZWFtIGVsZW1lbnRzLCB3aGVyZSB0aGUgc2V0IA0KICAgICAgb2YgdXBzdHJlYW0gZWxlbWVu dHMgaXMgbm90IGVudW1lcmFibGUuIChNYXkgbm90IGJlIHJlbGV2YW50IHRvIA0KRGlhbWV0ZXIp IA0KDQpTSVAgICBSRVEgMTE6ICBUaGUgbWVjaGFuaXNtIHNob3VsZCBzdXBwb3J0IHNlcnZlcnMg dGhhdCByZWNlaXZlIHJlcXVlc3RzIA0KICAgICAgZnJvbSBhIGZpbml0ZSBzZXQgb2YgdXBzdHJl YW0gZWxlbWVudHMsIHdoZXJlIHRoZSBzZXQgb2YgdXBzdHJlYW0gDQogICAgICBlbGVtZW50cyBp cyBlbnVtZXJhYmxlLiANCg0KUkVRIDExOiAgVGhlIG92ZXJsb2FkIG1lY2hhbmlzbSBNVVNUIGJl IHNjYWxhYmxlLiAgVGhhdCBpcywgaXQgTVVTVA0KICAgICAgICAgICAgYmUgYWJsZSB0byBvcGVy YXRlIGluIGRpZmZlcmVudCBzaXplZCBuZXR3b3Jrcy4NCg0KPEpQRz4gVGhlIGRpc3RpbmN0aW9u ICBoZXJlIGlzIG5vdCB0aGUgU0laRSBvZiB0aGUgbmV0d29yay4gIEl0IGlzIHdoZXRoZXIgDQp5 b3Uga25vdywgYWhlYWQgb2YgdGltZSwgIndobyIgeW91ciB1cHN0cmVhbSAoZG93bnN0cmVhbSBm b3IgRGlhbWV0ZXIpIA0Kbm9kZXMgYXJlLiAgSSB0aGluayB0aGlzIHJlbGF0ZXMgdG8geW91ciAi UGVlciBkaXNjb3ZlcnkiIG1lY2hhbmlzbS4gIFNvIEkgDQp0aGluayBpdCBpcyBjb3ZlcmVkIGJ5 IHlvdXIgUkVRIDUNCg0KDQoNClNJUCAgICBSRVEgMTY6ICBUaGUgbWVjaGFuaXNtIHNob3VsZCBh dHRlbXB0IHRvIG1pbmltaXplIHRoZSBvdmVyaGVhZCBvZiANCnRoZSANCiAgICAgIG92ZXJsb2Fk IGNvbnRyb2wgbWVzc2FnaW5nLiANCg0KUkVRIDEzOiAgVGhlIG1lY2hhbmlzbSBNVVNUIE5PVCBp bnRyb2R1Y2Ugc3Vic3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrDQogICAgICAgICAgICBmb3Igbm9k ZSBpbiBhbiBvdmVybG9hZGVkIHN0YXRlLiAgRm9yIGV4YW1wbGUsIGEgcmVxdWlyZW1lbnQNCiAg ICAgICAgICAgIGZvciBhbiBvdmVybG9hZGVkIG5vZGUgdG8gc2VuZCBvdmVybG9hZCBpbmZvcm1h dGlvbiBldmVyeQ0KICAgICAgICAgICAgdGltZSBpdCByZWNlaXZlZCBhIG5ldyByZXF1ZXN0IHdv dWxkIGludHJvZHVjZSBzdWJzdGFudGlhbA0KICAgICAgICAgICAgd29yay4gIEV4aXN0aW5nIG1l c3NhZ2luZyBpcyBsaWtlbHkgdG8gaGF2ZSB0aGUNCiAgICAgICAgICAgIGNoYXJhY3RlcmlzdGlj IG9mIGluY3JlYXNpbmcgYXMgYW4gb3ZlcmxvYWQgY29uZGl0aW9uDQogICAgICAgICAgICBhcHBy b2FjaGVzLCBhbGxvd2luZyBmb3IgdGhlIHBvc3NpYmlsaXR5IG9mIGluY3JlYXNlZA0KICAgICAg ICAgICAgZmVlZGJhY2sgZm9yIGluZm9ybWF0aW9uIHBpZ2d5YmFja2VkIG9uIGl0Lg0KDQo8SlBH PiBJIGd1ZXNzIEkgc2VlIGEgZGlzdGluY3Rpb24gYmV0d2VlbiAgIm1pbmltaXppbmcgdGhlIG92 ZXJoZWFkIiBhbmQgDQoiTk9UIGludHJvZHVjaW5nIHN1YnN0YW50aWFsIG92ZXJoZWFkIiwgYW5k IEkgbGlrZSAibWluaW1pemluZyIgYmV0dGVyLiANCkJ1dCBpdCBpcyBub3QgYSBiaWcgZGVhbC4N CkphbmV0DQoNCg0KDQoNCg0K --=_alternative 0076426885257AA7_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk15IGZ1cnRoZXIgY29tbWVudHMgaW4gbGlu ZTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+SW48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPjxicj4NCiDigJzigKZ0aGUgbmV0d29yayBvcGVyYXRvcnMgbWF5IG5vdCB3YW50IHRoZTwv Zm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KICZuYnNwOyBpbnRlcmNvbm5lY3QgdG8gdXNlIG92ZXJsb2FkIG9yIGxvYWRpbmcgaW5mb3Jt YXRpb24gaW50ZW5kZWQgdG8NCnBhc3M8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCiAmbmJzcDsgdGhyb3VnaCB0aGUgaW50ZXJjb25u ZWN0IGV2ZW4gaWYgdGhlIGVsZW1lbnRzIGluIHRoZSBpbnRlcmNvbm5lY3Q8L2ZvbnQ+PGZvbnQg c2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQogJm5ic3A7 IG5ldHdvcmsgZG8gc3VwcG9ydCBkaWFtZXRlciBvdmVybG9hZCBjb250cm9sLuKAnTwvZm9udD48 Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NClNo b3VsZCB0aGF0IGJlIOKAnG5vdCBpbnRlbmRlZCB0byBwYXNz4oCdPzwvZm9udD48Zm9udCBzaXpl PTM+IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+aG93IGFib3V0OjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTM+dGhlIG5ldHdvcmsgb3BlcmF0b3JzIG1heSBub3Q8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3YW50 IHRoZSBpbnRlcmNvbm5lY3QNCnRvIHVzZSBvdmVybG9hZCBvciBsb2FkaW5nIGluZm9ybWF0aW9u IGludGVuZGVkPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7dG8gdG8gYmUgY29udmV5ZWQgdG8NCmVsZW1lbnRzIG91dHNpZGUgb2YgdGhl IGludGVyY29ubmVjdCBuZXR3b3JrLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V2ZW4gaWYgdGhlIGVsZW1lbnRzDQppbiB0aGUgaW50 ZXJjb25uZWN0IG5ldHdvcmsgZG8gc3VwcG9ydCBkaWFtZXRlcjwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO292ZXJsb2FkIGNvbnRyb2w8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPmlzIHRoYXQgbW9yZSBjbGVhcj88L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPiZsdDtKUEcmZ3Q7ICZuYnNwO0kgZG9uJ3QgdGhpbmsg dGhhdCBoZWxwcyAmbmJzcDtJdCBzdGlsbA0Kc2VlbXMgY29udHJhZGljdG9yeSAtICZuYnNwOyZx dW90O21heSBub3Qgd2FudCAuLi4gdG8gdXNlIC4uLmluZm9ybWF0aW9uDQombmJzcDtpbnRlbmRl ZCB0byBiZSBjb252ZXllZCB0byBlbGVtZW50cyBvdXRzaWRlLi4uJnF1b3Q7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz5JdCBzZWVtcyB0aGF0ICZxdW90O2luZm9ybWF0aW9uICZuYnNwO2ludGVu ZGVkIHRvIGJlIGNvbnZleWVkDQp0byBlbGVtZW50cyBvdXRzaWRlIC4uLiZxdW90OyBpcyBFWEFD VExZICZuYnNwOyhhbmQgb25seSkgd2hhdCB5b3UgRE8gJm5ic3A7V0FOVA0KdGhlIGludGVyY29u bmVjdCB0byB1c2UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij4uLi48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4N Ckxhc3QgcGFyYTwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+PGJyPg0K4oCcV2hpbGUgdGhpcyBzdHVkeSBpcyBjb25jZXJuZWQgd2l0aOKApuKA nTwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+PGJyPg0KV2hhdCBpcyDigJx0aGlzIHN0dWR54oCdPyAmbmJzcDtUaGlzIElEPyBUaGUg dGVjaG5pY2FsIHJlcG9ydCBtZW50aW9uZWQgNA0KcGFyYWdyYXBocyBlYXJsaWVyPyAmbmJzcDtO ZWVkIHRvIG1ha2UgJm5ic3A7YW50ZWNlZGVudCBjbGVhci48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0K PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0zPi4uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KUmVxIDI1PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj48YnI+DQrigJwgJm5ic3A7VGhlIG1lY2hhbmlzbSBNVVNUIHByb3ZpZGUgYSBtZWNo YW5pc20gZm9yIGluZGljYXRpbmcgbG9hZDwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2xldmVscyBldmVuIHdoZW4gbm90IGluIGFuIG92ZXJsb2FkZWQNCmNv bmRpdGlvbiwgdG8gYXNzaXN0PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtub2RlcyBtYWtpbmcgZGVjaXNpb25zIHRvIHByZXZlbnQNCm92ZXJsb2FkIGNvbmRp dGlvbnMgZnJvbTwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 b2NjdXJyaW5nLuKAnTwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNhbGlicmkiPjxicj4NCkkgZG9u4oCZdCB0aGluayB0aGF0IHRoaXMgaXMgbmVlZGVkLCBn aXZlbiB0aGF0ICZuYnNwO1JlcSAyMiBzYXlzIHRoYXQg4oCcT3ZlcmxvYWQNCmlzIG5vdCBhIGJp bmFyeSBzdGF0ZS7igJ0gVGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIOKAnHByZXZlbnRpbmcg b3ZlcmxvYWQNCmNvbmRpdGlvbnMgZm9ybSBvY2N1cnJpbmfigJ0gYW5kIOKAnGRlZ3JlZXMgb2Yg b3ZlcmxvYWTigJ0gd2hhdCB5b3UgZGVmaW5lDQphcyBvdmVybG9hZC4gJm5ic3A7TWF5YmUgeW91 IHNob3VsZCBmb2xkIHNvbWUgb2YgdGhpcyB0ZXh0IGludG8gUmVxIDIyDQp0byBtYWtlIGl0IGNs ZWFyZXIuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mz4yMiBjb3ZlcnMgc2lnbmFsaW5nIG9mIG92ZXJsb2FkLiAmbmJzcDsyNSBpcyBmb3Igc2lnbmFs aW5nDQpsb2FkLCB3aGVuIG5vdCBvdmVybG9hZGVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTM+Jmx0O0pQRyZndDsgT0ssIGJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBkaXN0aW5j dGlvbg0Kc2hvdWxkIGJlIGJldHdlZW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkEtICZuYnNw OyAmcXVvdDtJbmRpY2F0aW5nIHRoYXQgSSB3YW50IHRoZSBvdGhlciBlbmQgdG8NCmRvIHNvbWV0 aGluZyB0byByZWR1Y2UgdGhlIHRyYWZmaWMgaXQgZW5kcyB0byBtZSAmcXVvdDsgKHdoaWNoIGNv dWxkIGJlDQomcXVvdDthcHByb2FjaGluZyBvdmVybG9hZCZxdW90OyBvciAmcXVvdDthbHJlYWR5 IGluIG92ZXJsb2FkKTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+YW5kPC9mb250Pg0KPGJyPjxm b250IHNpemU9Mz5CLSAmcXVvdDtJbmRpY2F0aW5nIHRoYXQgSSBzdXBwb3J0IE92ZXJsb2FkIGNv bnRyb2wsIGJ1dA0KSSBkb24ndCBuZWVkIHRoZSBvdGhlciBlbmQgdG8gZG8gYW55dGhpbmcgYWJv dXQgaXQgYXQgdGhlIG1vbWVudC4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z PnJhdGhlciB0aGFuIGJldHdlZW4gJm5ic3A7JnF1b3Q7bG9hZCB3aGVuIG92ZXJsb2FkZWQgJnF1 b3Q7DQphbmQgJnF1b3Q7bG9hZCB3aGVuIG5vdCBvdmVybG9hZGVkJnF1b3Q7PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9Mz5GdXJ0aGVybW9yZSwgSSBkbyBub3QgdGhpbmsgdGhlcmUgaXMg YSBsb3Qgb2YgdmFsdWUgKGZvcg0Kb3ZlcmxvYWQgY29udHJvbCkgaW4gJnF1b3Q7aW5kaWNhdGlu ZyBsb2FkIGxldmVscyZxdW90Oy4gKEl0IG1pZ2h0IGJlIHZhbHVhYmxlDQpmb3IgbG9hZC1iYWxh bmNpbmcuKSBGb3Igb3ZlcmxvYWQgY29udHJvbCwgdGhlIHZhbHVlIGlzIGluIHRlbGxpbmcgdGhl DQpvdGhlciBlbmQgdGhhdCB0aGV5IG5lZWQgdG8gcmVkdWNlIHRoZWlyIHRyYWZmaWMgdG8gbWUg KGFuZCBob3cgbXVjaCkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPi4uLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTM+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQo8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRoZXJlIGFyZSBz ZXZlcmFsIHJlcXVpcmVtZW50cyBpbiB0aGUgU0lQDQpPdmVybG9hZCBkb2N1bWVudCB0aGF0IGRv IG5vdCBzZWVtIHRvIGhhdmUgcGFyYWxsZWxzIGluIHRoaXMgZG9jdW1lbnQgKGJ1dA0KSSBtYXkg aGF2ZSBtaXNzZWQgdGhlbSkuICZuYnNwO01vc3Qgb2YgdGhlbSBzZWVtIGFzIGlmIHRoZXkgd291 bGQgYmUgcmVsZXZhbnQNCnRvIERJTUUuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9Mz5PSyBvbiBtb3N0IG9mIHRoZW0tIG15IGJyYWluIHdhcyBnb2lu ZyBpbiBjaXJjbGVzIHRyeWluZw0KdG8gZ28gYmFjayBhbmQgZm9ydGggYmV0d2VlbiB0aGUgZG9j cy48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCi4uLjwvZm9u dD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KU0lQ ICZuYnNwOyBSRVEgMTA6ICZuYnNwO1RoZSBtZWNoYW5pc20gc2hvdWxkIHN1cHBvcnQgc2VydmVy cyB0aGF0IHJlY2VpdmUNCnJlcXVlc3RzPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDtmcm9tIGEg bGFyZ2UgbnVtYmVyIG9mIGRpZmZlcmVudCB1cHN0cmVhbSBlbGVtZW50cywNCndoZXJlIHRoZSBz ZXQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki Pjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO29mIHVwc3RyZWFtIGVsZW1lbnRzIGlzIG5vdCBl bnVtZXJhYmxlLiAoTWF5IG5vdCBiZQ0KcmVsZXZhbnQgdG8gRGlhbWV0ZXIpPC9mb250Pjxmb250 IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQpT SVAgJm5ic3A7IFJFUSAxMTogJm5ic3A7VGhlIG1lY2hhbmlzbSBzaG91bGQgc3VwcG9ydCBzZXJ2 ZXJzIHRoYXQgcmVjZWl2ZQ0KcmVxdWVzdHM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2Zyb20g YSBmaW5pdGUgc2V0IG9mIHVwc3RyZWFtIGVsZW1lbnRzLCB3aGVyZSB0aGUNCnNldCBvZiB1cHN0 cmVhbTwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ZWxlbWVudHMgaXMgZW51bWVyYWJsZS48L2Zv bnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlJFUSAxMTog Jm5ic3A7VGhlIG92ZXJsb2FkIG1lY2hhbmlzbSBNVVNUIGJlIHNjYWxhYmxlLg0KJm5ic3A7VGhh dCBpcywgaXQgTVVTVDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmUgYWJsZSB0byBvcGVyYXRlDQppbiBkaWZmZXJlbnQg c2l6ZWQgbmV0d29ya3MuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz4mbHQ7SlBHJmd0 OyBUaGUgZGlzdGluY3Rpb24gJm5ic3A7aGVyZSBpcyBub3QgdGhlIFNJWkUNCm9mIHRoZSBuZXR3 b3JrLiAmbmJzcDtJdCBpcyB3aGV0aGVyIHlvdSBrbm93LCBhaGVhZCBvZiB0aW1lLCAmcXVvdDt3 aG8mcXVvdDsNCnlvdXIgdXBzdHJlYW0gKGRvd25zdHJlYW0gZm9yIERpYW1ldGVyKSAmbmJzcDtu b2RlcyBhcmUuICZuYnNwO0kgdGhpbmsNCnRoaXMgcmVsYXRlcyB0byB5b3VyICZxdW90O1BlZXIg ZGlzY292ZXJ5JnF1b3Q7IG1lY2hhbmlzbS4gJm5ic3A7U28gSSB0aGluaw0KaXQgaXMgY292ZXJl ZCBieSB5b3VyIFJFUSA1PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj48YnI+DQpTSVAgJm5ic3A7ICZuYnNwO1JFUSAxNjogJm5ic3A7VGhlIG1lY2hh bmlzbSBzaG91bGQgYXR0ZW1wdCB0byBtaW5pbWl6ZQ0KdGhlIG92ZXJoZWFkIG9mIHRoZTwvZm9u dD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3ZlcmxvYWQgY29udHJvbCBtZXNzYWdpbmcuPC9mb250Pjxm b250IHNpemU9Mz4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5SRVEgMTM6ICZuYnNw O1RoZSBtZWNoYW5pc20gTVVTVCBOT1QgaW50cm9kdWNlIHN1YnN0YW50aWFsDQphZGRpdGlvbmFs IHdvcms8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGZvciBub2RlIGluDQphbiBvdmVybG9hZGVkIHN0YXRlLiAmbmJzcDtG b3IgZXhhbXBsZSwgYSByZXF1aXJlbWVudDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9yIGFuIG92ZXJsb2FkZWQNCm5v ZGUgdG8gc2VuZCBvdmVybG9hZCBpbmZvcm1hdGlvbiBldmVyeTwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGltZSBpdCBy ZWNlaXZlZA0KYSBuZXcgcmVxdWVzdCB3b3VsZCBpbnRyb2R1Y2Ugc3Vic3RhbnRpYWw8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHdvcmsuICZuYnNwO0V4aXN0aW5nDQptZXNzYWdpbmcgaXMgbGlrZWx5IHRvIGhhdmUgdGhl PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBjaGFyYWN0ZXJpc3RpYw0Kb2YgaW5jcmVhc2luZyBhcyBhbiBvdmVybG9hZCBj b25kaXRpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGFwcHJvYWNoZXMsDQphbGxvd2luZyBmb3IgdGhlIHBvc3NpYmls aXR5IG9mIGluY3JlYXNlZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZmVlZGJhY2sgZm9yDQppbmZvcm1hdGlvbiBwaWdn eWJhY2tlZCBvbiBpdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPiZsdDtKUEcmZ3Q7 IEkgZ3Vlc3MgSSBzZWUgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuICZuYnNwOyZxdW90O21pbmltaXpp bmcNCnRoZSBvdmVyaGVhZCZxdW90OyBhbmQgJnF1b3Q7Tk9UIGludHJvZHVjaW5nIHN1YnN0YW50 aWFsIG92ZXJoZWFkJnF1b3Q7LA0KYW5kIEkgbGlrZSAmcXVvdDttaW5pbWl6aW5nJnF1b3Q7IGJl dHRlci4gJm5ic3A7QnV0IGl0IGlzIG5vdCBhIGJpZyBkZWFsLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+SmFuZXQ8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki Pjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K PC9mb250Pg0K --=_alternative 0076426885257AA7_=-- From emcmurry@computer.org Tue Oct 30 16:19:44 2012 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 3EEEC21F85AC for ; Tue, 30 Oct 2012 16:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM+IAfkQAAiO for ; Tue, 30 Oct 2012 16:19:43 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id A62FA21F8594 for ; Tue, 30 Oct 2012 16:19:42 -0700 (PDT) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TTL5x-000HY2-Oe; Tue, 30 Oct 2012 23:19:42 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id E46817FE57C; Tue, 30 Oct 2012 18:19:39 -0500 (CDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19NilTTXUzM04VY3xTce5oUjTIanEFXfrE= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPrCMpGaFmpg; Tue, 30 Oct 2012 18:19:39 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id CF3777FE568; Tue, 30 Oct 2012 18:19:39 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5B10409F-C7B1-40E5-AE4D-FDAC96BDD4C2" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: Date: Tue, 30 Oct 2012 18:19:39 -0500 Message-Id: <29B2DD63-402F-4C6C-A8C6-14DDDD9A8EDB@computer.org> References: <709FF87F-1E3E-4117-A848-18E927AB898B@tekelec.com> <9BE16775-D5D4-4822-B5E3-68C9912F428D@computer.org> To: Janet P Gunn X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2012 23:19:44 -0000 --Apple-Mail=_5B10409F-C7B1-40E5-AE4D-FDAC96BDD4C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Janet. comments inline. On Oct 30, 2012, at 16:31 , Janet P Gunn wrote: > My further comments in line=20 >=20 >=20 >=20 > In=20 > =93=85the network operators may not want the=20 > interconnect to use overload or loading information intended to pass=20= > through the interconnect even if the elements in the interconnect=20 > network do support diameter overload control.=94=20 > Should that be =93not intended to pass=94?=20 >=20 > how about:=20 >=20 > the network operators may not=20 > want the interconnect to use overload or loading information = intended=20 > to to be conveyed to elements outside of the interconnect = network,=20 > even if the elements in the interconnect network do support = diameter=20 > overload control=20 >=20 > is that more clear?=20 >=20 > I don't think that helps It still seems contradictory - "may = not want ... to use ...information intended to be conveyed to elements = outside..."=20 > It seems that "information intended to be conveyed to elements = outside ..." is EXACTLY (and only) what you DO WANT the interconnect = to use.=20 well, information, and overload or loading information are not the = same thing. Taking the qualifiers off changes the meaning. Even so, = the text is apparently still not working. How about: the network operators may not=20 want the interconnect to use or act on overload or loading = information intended=20 for consumption by elements outside of the interconnect = network,=20 even if the elements in the interconnect network do support = diameter=20 overload control=20 >=20 > ... >=20 >=20 > Last para=20 > =93While this study is concerned with=85=94=20 >=20 > What is =93this study=94? This ID? The technical report mentioned 4 = paragraphs earlier? Need to make antecedent clear.=20 >=20 > ...=20 >=20 > Req 25=20 > =93 The mechanism MUST provide a mechanism for indicating load=20 > levels even when not in an overloaded condition, to assist=20= > nodes making decisions to prevent overload conditions from=20= > occurring.=94=20 > I don=92t think that this is needed, given that Req 22 says that = =93Overload is not a binary state.=94 The only difference between = =93preventing overload conditions form occurring=94 and =93degrees of = overload=94 what you define as overload. Maybe you should fold some of = this text into Req 22 to make it clearer.=20 >=20 > 22 covers signaling of overload. 25 is for signaling load, when not = overloaded.=20 >=20 > OK, but it seems to me that the distinction should be between=20 > A- "Indicating that I want the other end to do something to reduce = the traffic it ends to me " (which could be "approaching overload" or = "already in overload)=20 > and=20 > B- "Indicating that I support Overload control, but I don't need the = other end to do anything about it at the moment."=20 >=20 > rather than between "load when overloaded " and "load when not = overloaded"=20 >=20 > Furthermore, I do not think there is a lot of value (for overload = control) in "indicating load levels". (It might be valuable for = load-balancing.) For overload control, the value is in telling the other = end that they need to reduce their traffic to me (and how much).=20 one of the primary goals of this is to give diameter nodes the = ability to avoid overload when possible. That can not be accomplished = by signaling the degree of overload once it has already occurred. = Signaling the degree of overload once it has occurred does help to = mitigate the results of the overload though, which is another goal. The = thinking was that these goals result in separate requirements and are = not really the same thing. That said, there is nothing stopping a = mechanism from signaling the degree of overload and non-overloaded load = level in the same way, depending on how the mechanism chooses to deal = with actual overload. >=20 >=20 > ...=20 >=20 >=20 >=20 >=20 >=20 > There are several requirements in the SIP Overload document that do = not seem to have parallels in this document (but I may have missed = them). Most of them seem as if they would be relevant to DIME.=20 >=20 > OK on most of them- my brain was going in circles trying to go back = and forth between the docs. I fully understand. I had to go back and dig a bit to refresh my = memory on those :-) >=20 > ...=20 >=20 >=20 >=20 > SIP REQ 10: The mechanism should support servers that receive = requests=20 > from a large number of different upstream elements, where the set=20= > of upstream elements is not enumerable. (May not be relevant to = Diameter)=20 >=20 > SIP REQ 11: The mechanism should support servers that receive = requests=20 > from a finite set of upstream elements, where the set of upstream=20= > elements is enumerable.=20 >=20 > REQ 11: The overload mechanism MUST be scalable. That is, it MUST=20 > be able to operate in different sized networks.=20 >=20 > The distinction here is not the SIZE of the network. It is = whether you know, ahead of time, "who" your upstream (downstream for = Diameter) nodes are. I think this relates to your "Peer discovery" = mechanism. So I think it is covered by your REQ 5=20 >=20 >=20 >=20 > SIP REQ 16: The mechanism should attempt to minimize the overhead = of the=20 > overload control messaging.=20 >=20 > REQ 13: The mechanism MUST NOT introduce substantial additional work=20= > for node in an overloaded state. For example, a = requirement=20 > for an overloaded node to send overload information every=20= > time it received a new request would introduce substantial=20= > work. Existing messaging is likely to have the=20 > characteristic of increasing as an overload condition=20 > approaches, allowing for the possibility of increased=20 > feedback for information piggybacked on it.=20 >=20 > I guess I see a distinction between "minimizing the overhead" = and "NOT introducing substantial overhead", and I like "minimizing" = better. But it is not a big deal.=20 I generally agree with you and think minimizing is a good goal, but = I'm thinking not introducing substantial overhead is a bit easier to = test as a requirement. > Janet=20 >=20 >=20 >=20 >=20 --Apple-Mail=_5B10409F-C7B1-40E5-AE4D-FDAC96BDD4C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 jgunn6@csc.com> wrote:

My further comments in line



In =
=93=85the network operators may not want the =
  interconnect to use overload or loading information intended to pass
=   through the interconnect even if the elements in the = interconnect
  network do support diameter overload control.=94
Should that be =93not intended to pass=94? =

how about:

the network operators may not
         want the = interconnect to use overload or loading information intended
         to to be conveyed = to elements outside of the interconnect network,
         even if the = elements in the interconnect network do support diameter
         overload = control

is that more clear?

<JPG>  I don't think that helps  It = still seems contradictory -  "may not want ... to use ...information  intended to be conveyed to elements outside..."
It seems that "information  intended to be = conveyed to elements outside ..." is EXACTLY  (and only) what you DO =  WANT the interconnect to use.

<em> well, information, and = overload or loading information are not the same thing.  Taking the = qualifiers off changes the meaning.  Even so, the text is = apparently still not working.  How = about:


the = network operators may not 
    =      want the interconnect to use or act on overload or = loading information intended 
  =        for consumption by elements outside of the = interconnect network, 
    =      even if the elements in the interconnect network do = support diameter 
      =    overload = control 




...

Last para
=93While this study is concerned with=85=94

What is =93this study=94?  This ID? The technical report mentioned = 4 paragraphs earlier?  Need to make  antecedent = clear.

...

Req 25
=93  The mechanism MUST provide a mechanism for indicating = load
           levels even when not in an = overloaded condition, to assist
           nodes making decisions to = prevent overload conditions from
           occurring.=94
I don=92t think that this is needed, given that  Req 22 says that = =93Overload is not a binary state.=94 The only difference between =93preventing = overload conditions form occurring=94 and =93degrees of overload=94 what you = define as overload.  Maybe you should fold some of this text into Req 22 to make it clearer.

22 covers signaling of overload.  25 is for = signaling load, when not overloaded.

<JPG> OK, but it seems to me that the = distinction should be between
A-   "Indicating that I want the other end to do something to reduce the traffic it ends to me " (which could be "approaching overload" or "already in overload)
and
B- "Indicating that I support Overload control, but I don't need the other end to do anything about it at the = moment."

rather than between  "load when overloaded " and "load when not overloaded"

Furthermore, I do not think there is a lot of value = (for overload control) in "indicating load levels". (It might be valuable for load-balancing.) For overload control, the value is in telling the other end that they need to reduce their traffic to me (and how = much).

<em>  one of the primary = goals of this is to give diameter nodes the ability to avoid overload = when possible.  That can not be accomplished by signaling the = degree of overload once it has already occurred.  Signaling the = degree of overload once it has occurred does help to mitigate the = results of the overload though, which is another goal.  The = thinking was that these goals result in separate requirements and are = not really the same thing.  That said, there is nothing stopping a = mechanism from signaling the degree of overload and non-overloaded load = level in the same way, depending on how the mechanism chooses to deal = with actual overload.



...





There are several requirements in = the SIP Overload document that do not seem to have parallels in this document = (but I may have missed them).  Most of them seem as if they would be = relevant to DIME.

OK on most of them- my brain was going in circles = trying to go back and forth between the = docs.

<em>  I = fully understand.  I had to go back and dig a bit to refresh my = memory on those :-)


...



SIP   REQ 10:  The mechanism should support servers that = receive requests
     from a large number of different upstream elements, where the set
     of upstream elements is not enumerable. (May not be relevant to Diameter)

SIP   REQ 11:  The mechanism should support servers that = receive requests
     from a finite set of upstream elements, where the set of upstream
     elements is enumerable. =

REQ 11:  The overload mechanism MUST be = scalable.  That is, it MUST
            be able = to operate in different sized networks.

<JPG> The distinction  here is not the = SIZE of the network.  It is whether you know, ahead of time, "who" your upstream (downstream for Diameter)  nodes are.  I think this relates to your "Peer discovery" mechanism.  So I think it is covered by your REQ 5



SIP    REQ 16:  The mechanism should attempt to minimize the overhead of the
     overload control messaging. =

REQ 13:  The mechanism MUST NOT introduce = substantial additional work
            for node = in an overloaded state.  For example, a requirement
            for an = overloaded node to send overload information every
            time it = received a new request would introduce substantial
            work. =  Existing messaging is likely to have the
            = characteristic of increasing as an overload condition
            = approaches, allowing for the possibility of increased
            feedback = for information piggybacked on it.

<JPG> I guess I see a distinction between =  "minimizing the overhead" and "NOT introducing substantial overhead", and I like "minimizing" better.  But it is not a big deal.

<em> I generally agree with = you and think minimizing is a good goal, but I'm thinking not = introducing substantial overhead is a bit easier to test as a = requirement.


Janet





= --Apple-Mail=_5B10409F-C7B1-40E5-AE4D-FDAC96BDD4C2--