Subject: [Dime] Review of draft-ietf-dime-app-design-guide-02.txt

From: Alexis Hildebrandt <[email-masked]>
Date: Mon, 30 Jul 2007 17:34:16 +0200

Dear all,
please find attached the patch of an editorial review of
draft-ietf-dime-app-design-guide-02.txt.  The reviewed document, the
attached patch, as well as the rfcdiff is also available at:
http://www.surryhill.net/ietf/dime/

Note, that some corrections suggested in the review are merely
stylistic to improve readability from my point of view.

Victor: In case the draft is also available in rfc2629 format I'd
gladly provide patches containing the suggestions for the XML.

Best regards, Alexis.
-- 
Alexis Hildebrandt, Software Development
Voice: +49 30 590080-1172
 
Netzwert AG, An den Treptowers 1, 12435 Berlin, Germany
Fax: +49.30.5900800700, http://www.netzwert.ag
Vorstand: Ralf U. Holighaus, Ralf Moritz
Aufsichtsrat: Clemens Schrimpe (Vorsitzender)
Steuernr.: 37/491/20570 Ust-IdNr.: DE 813 06 78 94
Sitz: Berlin Handelsregister: Amtsgericht Charlottenburg HRB 72960
--- draft-ietf-dime-app-design-guide-02.txt	2007-07-27 12:56:30.368692000 +0200
+++ draft-ietf-dime-app-design-guide-02-reviewed.txt	2007-07-30 15:32:51.706292255 +0200
@@ -81,7 +81,7 @@
      5.1.  Rules in Allocating new Command Codes  . . . . . . . . . . 10
      5.2.  Justifying the Allocation of Application-Id  . . . . . . . 11
      5.3.  Use of Application-Id in a Message . . . . . . . . . . . . 11
-     5.4.  Application Specific Session Statemachine  . . . . . . . . 11
+     5.4.  Application Specific Session State Machine . . . . . . . . 11
      5.5.  End-to-End Applications Capabilities Exchange  . . . . . . 12
    6.  Other Design Considerations  . . . . . . . . . . . . . . . . . 12
      6.1.  Diameter Accounting Support  . . . . . . . . . . . . . . . 12
@@ -125,20 +125,20 @@
    2.  A new Diameter application is being defined by reusing an
        existing application.
 
-   3.  A completely new application is being defined that has no
+   3.  An entirely new application is being defined that has no
        dependencies to any existing applications.
 
    4.  A new generic functionality is being defined that can be reused
        across different applications.
 
-   All of these choices are design decisions that can done by any
+   All of these choices are design decisions that can be done by any
    combination of reusing existing or defining new commands, AVPs or AVP
    values.  The objective of this document is the following:
 
    o  Clarify updated Diameter extensibility rules in the Diameter Base
-      Protocol.
+      protocol.
 
-   o  Clarify usage of certain Diameter functionality which are not
+   o  Clarify usage of certain Diameter functionality which is not
       explicitly described in the Diameter Base specification.
 
    o  Discuss design choices and provide guidelines when defining
@@ -147,11 +147,11 @@
    o  Present tradeoffs of design choices.
 
    These guidelines are necessary since the existing rules do not cover
-   the ambiguity that exist when some of the design choices overlap.  A
+   the ambiguity that exists when some of the design choices overlap.  A
    typical example would be deciding between item one(1) and two(2)
    above when an application designer requires a new application
    functionality which has many things in common with an existing
-   application.  Certain ambiguous aspects of such cases was not
+   application.  Certain ambiguous aspects of such cases were not
    foreseen in the existing extensibility rules; i.e., use of optional
    AVPs to differentiate new functionality in the old application versus
    defining a new application and importing the existing set of
@@ -170,10 +170,10 @@

    to create a new application would result in the allocation of a new
-   application ID which often times is foreseen as cumbersome by
-   application designers because of the lengthy process.  Designers
-   therefore tend to circumvent the better approach leading to many
-   compromises in the design that eventually lead to interoperability
+   application ID which is often considered as cumbersome by
+   application designers because of the lengthy process involved.
+   Designers therefore tend to evade the better approach leading to many
+   compromises in the design that will eventually lead to interoperability
    issues (See Section 5.1).
 
    The basic issue is that the rules defined in the Diameter Base
@@ -183,7 +183,7 @@
    no clear answer on whether to even define a new application or not.
    At worst, some existing Diameter applications that had purposely been
    derived from another existing application resulted in some in-
-   appropriate design decision where both the existing application and
+   appropriate design decision where both the existing applications and
    the derived applications are no longer interoperable under certain
    conditions.  Note that it is not always possible to offer a complete
    and concise answer to certain design choices but at the least, this
@@ -201,7 +201,7 @@
    protocol is a two-layer protocol.  The lower layer is mainly
    responsible for managing connections between neighboring peers and
    for message routing.  The upper layer is where the Diameter
-   applications reside.  This model is inline with a Diameter node
+   applications reside.  This model is in line with a Diameter node
    having an application layer and a peer-to-peer delivery layer.  The
    Diameter Base protocol document completely defines the architecture
    and behavior of the message delivery layer and then provides the
@@ -225,39 +225,39 @@
 Internet-Draft   Diameter Applications Design Guidelines       July 2007

-   of an existing Diameter applications.  This section discusses the
+   of an existing Diameter application.  This section discusses the
    rules on how such reuse can be done.
 
-   When reusing existing applications, the requirements of the new
-   applications are typically not completely unique and there are
-   existing application's that can be reused to solve some or all of the
-   application requirements.  Therefore, there is a greater likelihood
+   When reusing existing applications, the requirements for the new
+   application are typically not completely unique and there are
+   existing applications that can be reused to solve some or all of the
+   application's requirements.  Thus, there is a greater likelihood
    of ambiguity on how much of the existing application can be reused,
    to what extent and what the implications for both the new and
-   existing application.  To broadly categorize, the rules for reusing
+   existing application are.  To broadly categorize, the rules for reusing
    existing applications can be either:
 
    1.  Minimal - which typically means adding optional AVPs to existing
        commands.
 
    2.  Invasive - where addition or deletion of commands and/or AVPs,
-       and/or AVP values.
+       and/or AVP values is necessary.

    Because it can fundamentally change the application, the latter
    approach has strict repercussions.  Specifically, it would result in
    the definition of a new application and therefore allocation of a new
    application ID is required.  Discussion about the specific Diameter
-   Base protocol rules associated with this approach are covered
+   Base protocol rules associated with this approach are covered in
    subsequent sections.
 
    The former approach, although simple, has pitfalls.  The problems
    arise when there is a tendency by applications designers to keep
-   adding optional AVPs to existing command so they can circumvent the
+   adding optional AVPs to existing commands so they can circumvent the
    rules associated with the latter approach.  Specifically, some
-   designers want to circumvent the standardization process associated
+   designers merely want to avoid the standardization process associated
    with these rules and not necessarily the rules themselves.  The
-   pitfalls associated with this approach is described further in
+   pitfalls associated with this approach are described further in
    Section 4.2.1.  Additionally, if designers choose this approach, all
    of the functionality of the existing application will be inherited
    even if the new usage has no intent of using some of the existing
@@ -267,7 +267,7 @@
 
    This section discusses the reuse of existing applications by adding
    and/or deleting commands from the application.  This scenario is
-   categorize as "Invasive" in Section 4 and would always result in the
+   categorized as "Invasive" in Section 4 and would always result in the
    creation of new applications when the rules are applied.

@@ -284,17 +284,17 @@
 4.1.1.  Adding a new command
 
    The rules are strict in this case.  Adding a command to an
-   application is not allowed and doing so will force a definition of a
+   application is not allowed and doing so will force the definition of a
    new application.  However, if this is the intent, then the new
    application can be created by defining a new command for an existing
    application or importing an existing command from another application
    so as to inherit some or all of the functionality of that
    application.  In the former case, the decision is straight forward
-   since this is typically a result of adding new functionality that
+   since this is typically the result of adding new functionality that
    does not yet exist.  See Section 5.1 for rules on how to allocate new
    command codes for new applications.  The latter case would result in
    a new application but it has a more subtle issue such as deciding
-   whether importing of commands and functionality is really better than
+   whether importing commands and functionality is really better than
    simply using the existing application as it is in conjunction with
    any new application.
 
@@ -303,7 +303,7 @@
    during the design phase; one model would reuse existing Diameter EAP
    application combined with a new Diameter MIPv6 application to form a
    complete authentication and authorization scheme and another would be
-   to reuse Diameter EAP like commands within the new Diameter MIPv6
+   to reuse Diameter EAP-like commands within the new Diameter MIPv6
    application to accomplish the same result.  In this case, the latter
    model was chosen which would permit the reuse of commands and/or AVPs
    from one application to another.  Other applications such as Diameter
@@ -317,17 +317,17 @@
    o  Can the new functionality be fulfilled by creating a new
       application independent from the existing applications ?  In this
       case, a deployment architecture could be designed such that both
-      old and new application can work independent of but cooperating
-      with each other.
+      the old and new application can work independently while still
+      cooperating with each other.
 
-   o  Can the existing application be reused as is without fundamental
+   o  Can an existing application be reused as is without fundamental
       changes; i.e. a non-mandatory optional AVP is sufficient to
       indicate support for new optional functionality if any.  There are
       pitfalls to this as well.  See Section 4.2.1
 
    o  Care should be taken to avoid a liberal method of importing many
       commands that results in a monolithic and hard to manage
-      application which supports many different functionality.
+      application which supports a lot of different functionality.

@@ -337,33 +337,34 @@
 Internet-Draft   Diameter Applications Design Guidelines       July 2007

-   o  Will the new feature or functionality refers only to semantic or
-      statemachine changes in the application requiring extra message
+   o  Will the new feature or functionality refer only to semantic or
+      state machine changes in the application requiring extra message
       round-trips ?  In such cases, definition of new commands may not
-      be necessary and use of existing commands maybe sufficient.
+      be necessary and use of existing commands might be sufficient.
+
    o  Reuse of existing applications would result in a distributed
       environment which may not be conducive to certain requirements of
       the applications; i.e. security and or deployment difficulties -
       because of Diameter routing, messages for different applications
       providing service to the same user may end up in different servers
-      would then need to be co-related.  This could mean extra signaling
+      would then need to be co-related.  This could imply extra signaling
       between application servers.  A typical example would be the
       initial proposal for Diameter MIPv6 split scenario (see [2]) where
-      authorization and authentication is separated.
+      authorization and authentication are separated.
 
    Note that accounting commands normally require special treatment and
    would not necessarily fall into this category.  See Section 6.1.
 
 4.1.2.  Deleting a command
 
-   Although this is not typical, deleting an command from an existing
+   Although this is not typical, deleting a command from an existing
    application is fundamentally changing the application.  In general,
-   the implications of this approach is the same as Section 4.1.1
+   the implications of this approach are the same as in Section 4.1.1
    regardless of whether new commands will also be added to the
    resulting application.  In general, it is unusual to delete an
-   existing command from an existing for the sake of deleting it or the
-   functionality it represents.  This design decision would normally be
-   an indication of a flawed designed.  An exception might be if the
+   existing command from an existing application for the sake of deleting it
+   or the functionality it represents.  This design decision would normally be
+   an indication of a flawed design.  An exception might be if the
    intent of the deletion is to create a newer version of the same
    application which is somehow simpler than the previous version.  In
    that case, the considerations in Section 6.3 should apply instead.
@@ -374,16 +375,17 @@
    Specifically, it discusses rules in adding and/or deleting AVPs from
    an existing command of an existing application.  Unlike Section 4.1,
    the cases in this section may not necessarily result in the creation
-   of new application(s).  In some cases, there are a lot of ambiguity.
-   So design considerations have been outline to ease the decision
+   of new application(s).  In some cases, there is a lot of ambiguity.
+   So design considerations have been outlined to ease the decision
    making process.
 
 4.2.1.  Adding AVPs to a command
 
    Based on the rules in [1], AVPs that are added to an existing command
    can be categorized into:
+
    o  Mandatory to understand AVPs.  As defined in [1], these are AVPs
-      which has their M-bit flag set which means Diameter nodes that
+      that have their M-bit flag set which means a Diameter node that
       receives these AVPs has to understand not only their values but

@@ -394,12 +396,13 @@

       their semantics and usage as well.  This is regardless of whether
-      these AVPs are required or optional to appear in the command; as
-      specified by the commands ABNF.
-   o  Non-mandatory AVPs that are also optional in the commands ABNF.
+      these AVPs are required or optional within the command; as
+      specified by the command's ABNF.
 
-   The rules are strict in the case where the AVPs to be added is
-   mandatory.  A mandatory cannot be added to or deleted from an
+   o  Non-mandatory AVPs that are also optional in the command's ABNF.
+
+   The rules are strict in the case where the AVPs to be added are
+   mandatory.  A mandatory AVP cannot be added to or deleted from an
    existing command. [1] states that doing so would require the
    definition of a new application.  This falls into the "Invasive"
    category described in Section 4.  Despite the clarity of the rule,
@@ -407,9 +410,9 @@
    added should be mandatory to begin with.  There are several questions
    that application designers should contemplate when trying to decide:
 
-   o  Does the AVPs change the state machine of the application ?
+   o  Does the AVP change the state machine of the application ?
 
-   o  Would the presence of the AVPs cause additional message round-
+   o  Would the presence of the AVP cause additional message round-
       trips; effectively changing the state machine of the application ?
 
    o  Will the AVP be used to fulfill new required functionality ?
@@ -421,18 +424,18 @@
       application related information as well as be used to indicate
       that the message is for a new application ?
 
-   If one or more of the above conditions are true, the AVP is consider
+   If one or more of the above conditions are true, the AVP is considered
    mandatory.  These questions are not comprehensive in any way but in
    all cases the semantics of the application must change to justify the
    use of mandatory AVPs.
 
-   The rules are less restrictive when adding Non-mandatory, optional
+   The rules are less restrictive when adding non-mandatory, optional
    AVPs.  This falls into the "Minimal" category described in Section 4.
    However, care should also be taken when opting for optional AVPs
    instead of mandatory AVPs simply to avoid the process of creating a
-   new applications.  Optional AVPs that answers any of the questions
-   above also have consequences.  Some of the issues associated with
-   using optional AVPs are:
+   new application.  Optional AVPs that answer any of the questions
+   above affirmatively also have consequences.  Some of the issues
+   associated with using optional AVPs are:
 
    o  Use of optional AVPs with intersecting meaning; one AVP has
       partially the same usage and/or meaning as another AVP.  The
@@ -462,7 +465,7 @@
    Although this scenario is not as common, the deletion of AVPs from a
    command ABNF is significant when trying to extend an existing
    application.  Deletion can again be categorized between mandatory and
-   non-mandatory optional AVPs described in Section 4.2.1.
+   non-mandatory, optional AVPs as described in Section 4.2.1.
 
    In the unlikely event that an application designer would require that
    mandatory AVPs must be deleted then it constitutes a fundamental
@@ -471,23 +474,23 @@
    application since it dictates changes in the behavior and semantics
    of an application.
 
-   Instead of deleting commands, a better alternative would be to define
+   Instead of deleting AVPs, a better alternative would be to define
    a new command that would represent the new behavior.  Reusing the
    same command code for different use cases can lead to more confusion
-   since the command will have different semantics depending on usage.
-   This is especially true to base protocol commands (session related
+   since the command will have different semantics depending on its usage.
+   This is especially true for base protocol commands (session related
    commands, ASR/ASA, STR/STA, RAR/RAA defined in [1]) where they are
    being used by many different applications.
 
    The deletion of an optional AVP may not necessarily indicate
-   allocation of a new application.  Deletion of non-mandatory optional
-   AVPs with a zero(0) minimum occurrence in the commands ABNF would not
+   allocation of a new application.  Deletion of non-mandatory, optional
+   AVPs with a zero(0) minimum occurrence in the command's ABNF would not
    require a new application.  In the case where an optional AVP has a
-   minimum occurrence of at least one(1) in the commands ABNF, then
+   minimum occurrence of at least one(1) in the command's ABNF, then
    deletion of the AVP would effectively change the behavior of the
    application.  It would be similar to the deletion of mandatory AVPs.
    Such cases are highly dubious to begin with since those AVPs already
-   exhibits properties of mandatory AVPs.  Extra consideration should be
+   exhibit properties of mandatory AVPs.  Additional consideration should be
    given as to why it was not defined as mandatory in the first place
    and that decision may have to be corrected as well.
 
@@ -508,20 +511,20 @@
 4.3.  Reusing Existing AVPs
 
    This section deals with even more granularity than Section 4.1 and
-   Section 4.2.  Specifically, it discusses rules in adding, deleting or
+   Section 4.2.  Specifically, it discusses rules for adding, deleting or
    modifying the specified values of an AVP.  The rules state that
    modifying the value of an AVP is allowed only if it does not change
-   the semantics of the AVP and the application using it.  Otherwise,
-   the change can be consider "Invasive" as described in Section 4 and
-   require definition of a new application.  Note that designers should
+   the semantics of the AVP and the applications using it.  Otherwise,
+   the change can be considered "Invasive" as described in Section 4 and
+   requires definition of a new application.  Note that designers should
    consider Section 5.2 when contemplating on these types of changes.
 
    Typically, the data types of the AVPs in question are scalar in
-   nature and each ordinal value represent a specific semantic behavior
-   of the application.  An example is CC-Request-Type AVP of [4].
+   nature and each ordinal value represents a specific semantic behavior
+   of the application.  An example is the CC-Request-Type AVP of [4].
    Adding, deleting or modifying known values of this AVP can modify the
    behavior of the application itself.  Additionally, the mandatory and
-   optional AVPs rules are inherited from Section 4.2.  So this affects
+   optional AVP rules are inherited from Section 4.2.  So this affects
    the decision for defining new applications as well.

@@ -530,19 +533,19 @@
    The general theme of Diameter extensibility is to reuse commands,
    AVPs and AVP values as much as possible.  However, some of the
    extensibility rules described in the previous section also apply to
-   scenarios where a designer is trying to define a completely new
+   scenarios where a designer is trying to define an entirely new
    Diameter application.
 
    This section discusses the case where new applications have
-   requirements that cannot be filled by existing applications and would
-   require definition of completely new commands, AVPs and/or AVP
+   requirements that cannot be fulfilled by existing applications and
+   would require definition of whole new commands, AVPs and/or AVP
    values.  Typically, there is little ambiguity about the decision to
    create these types of applications.  Some examples are the interfaces
    defined for the IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([5] and
    [6]), Sh ([7] and [8]) etc.
 
    Application design should also follow the theme of Diameter
-   extensibility which in this case may mean importing of existing AVPs
+   extensibility which in this case may mean importing existing AVPs
    and AVP values for any newly defined commands.  In certain cases
    where accounting will be used, the models described in Section 6.1
    should also be considered.  Though some decisions may be clear,
@@ -563,15 +566,15 @@
 
    Hopefully this will lessen the tendency to circumvent this process.
    The core rules for this process will be introduced in rfc3588bis and
-   full description will be added in this section in the next rev of
+   a full description will be added in this section in the next rev of
    this document]
 
 5.2.  Justifying the Allocation of Application-Id
 
    Application designers should avoid justifying the allocation of an
    application ID for each new functionality or any change that is made
-   to an existing application.  Proliferation of application ID can lead
-   to confusion and an in-efficient use of the application ID
+   to an existing application.  Proliferation of application IDs can lead
+   to confusion and an inefficient use of the application ID
    namespaces.  Application designers should always use Section 4 as a
    basis for justifying allocation of a new application ID.
 
@@ -593,18 +596,18 @@
    its meaning and usage should be segregated only within the
    application.
 
-5.4.  Application Specific Session Statemachine
+5.4.  Application Specific Session State Machine
 
-   Section 8 of [1] provides session statemachines for authentication,
+   Section 8 of [1] provides session state machines for authentication,
    authorization and accounting (AAA) services.  When a new application
    is being defined that cannot clearly be categorized into any of these
    services it is recommended that the application itself defines its
-   own session statemachine.  The existing session statemachines defined
-   by [1] is not intended for general use beyond AAA services therefore
+   own session state machine.  The existing session state machines defined
+   by [1] are not intended for general use beyond AAA services therefore
    any behavior not covered by that category would not fit well.
-   Support for server initiated request is a clear example where an
-   application specific session statemachine would be needed; i.e.  Rw
-   interface for ITU-T push model.
+   Support for server initiated requests is a clear example where an
+   application specific session state machine would be needed; i.e.  Rw
+   interface for the ITU-T push model.

@@ -619,31 +622,31 @@
 
 5.5.  End-to-End Applications Capabilities Exchange
 
-   It is also possible that applications can use a type of optional
+   It is also possible that applications can use some sort of optional
    capabilities exchange AVPs as a way to convey support for specific
    application features.  These AVPs are exchanged on an end-to-end
-   basis and known only by the application supporting them.  The use of
+   basis and known only by the applications supporting them.  The use of
    such AVPs must obviously be limited to convey functionality of the
    applications itself.  Examples of this can be found in [2] and [3].
 
    This method can be used to resolve some of the problems described in
    Section 6.3 and Section 6.2.  It is also useful in providing some
    restrictions and/or guidelines on the how the other functionality
-   related AVPs can be include in a command to avoid issues described in
-   Section 4.2.1.  Such end-to-end capabilities AVPs can aid in the
-   following cases:
+   related AVPs can be included in a command to avoid issues described in
+   Section 4.2.1.  Such end-to-end capabilities exchange AVPs can aid in
+   the following cases:
 
    o  Formalizing the way new functionality is added to existing
       applications by announcing support for it.  This makes determining
-      support for one or more specific functionality less ambiguous.
+      support for one or more specific functional features less ambiguous.
 
    o  Provide a way to further negotiate capabilities if allowed by the
       applications.
 
-   o  Applications that do not understand the capabilities AVP can
-      safely ignore it upon receipt.  In such case, senders of the AVP
+   o  Applications that do not understand the capabilities exchange AVPs can
+      safely ignore them upon receipt.  In such case, senders of the AVPs
       can also safely assume the receiving end-point does not support
-      any functionality carried by the AVP if it is not present in
+      any functionality carried by the AVPs if they are not present in
       subsequent responses.
 
    Note that this list is not meant to be comprehensive.
@@ -659,8 +662,8 @@
    Accounting can be treated as an auxiliary application which is used
    in support of other applications.  In most cases, accounting support
    is required when defining new applications.  However, the lack of
-   clarity in the base protocol document has prevented easy use the base
-   accounting messages (ACR/ACA).  This document provides two(2)
+   clarity in the base protocol document has prevented easy use of the
+   base accounting messages (ACR/ACA).  This document provides two(2)
    possible models for using accounting:

@@ -685,10 +688,10 @@
       accounting server.  A split accounting model is a good design
       choice when:
 
-      *  The application itself will not define its own unique
+      o  The application itself will not define its own unique
          accounting commands.
 
-      *  The overall system architecture permits the use of centralized
+      o  The overall system architecture permits the use of centralized
          accounting for one or more Diameter applications.
 
       From a Diameter architecture perspective, this model should be the
@@ -702,20 +705,20 @@
 
       In this model, the accounting messages will use the application ID
       of the application using the accounting service.  The design
-      implication for this is that the accounting messages is tightly
+      implication for this is that the accounting messages are tightly
       coupled with the application itself; meaning that accounting
       messages will be routed like any other application messages.  It
       would then be the responsibility of the application server
-      (application entity receiving the ACR message) to send the
+      (application entity receiving the ACR messages) to send the
       accounting records carried by the accounting messages to the
       proper accounting server.  The application server is also
       responsible for formulating a proper response (ACA).  A coupled
       accounting model is a good design choice when:
 
-      *  The system architecture or deployment will not provide an
+      o  The system architecture or deployment will not provide an
          accounting server that supports Diameter.
 
-      *  The system architecture or deployment requires that the
+      o  The system architecture or deployment requires that the
          accounting service for the specific application should be
          handled by the application itself.
 
@@ -729,9 +732,9 @@
 Internet-Draft   Diameter Applications Design Guidelines       July 2007

-      *  The application server is provisioned to use a different
+      o  The application server is provisioned to use a different
          protocol to access the accounting server; i.e., via LDAP, XML
-         etc.  This includes attempting to supporting older accounting
+         etc.  This includes attempting to support older accounting
          systems that are not Diameter aware.
 
       In all cases above, there will generally be no direct Diameter
@@ -745,7 +748,7 @@
    specific accounting records.
 
    Additionally, the application ID in the message header and
-   Accounting-Application-Id AVP are populated depending on the
+   Acct-Application-Id AVP are populated depending on the
    accounting model used for a specific application, as described in
    [1].  Therefore, application designers have to specify the accounting
    model used to guarantee proper routing of accounting requests.
@@ -766,7 +769,7 @@
 
    o  Backward compatibility: Dealing with existing applications that do
       not understand the new extension.  Designers also have to make
-      sure that new extensions do not break expected message delivery
+      sure that new extensions do not break the expected message delivery
       layer behavior.
 
    o  Forward compatibility: Making sure that the design will not
@@ -800,7 +803,7 @@
 6.3.  Updating an existing Application
 
    An application that is being upgraded must follow the same rules
-   mentioned Section 4.  Even if the new version is fundamentally the
+   mentioned in Section 4.  Even if the new version is fundamentally the
    same application, allocation of a new application ID is possible if
    it meets those criteria.
 
@@ -808,12 +811,12 @@
    this approach is chosen, it is recommended that the optional AVP is
    used specifically to indicate version information only and nothing
    else.  Additionally, the use of too many optional AVPs to carry
-   application enhancements should be avoided since such approach has a
+   application enhancements should be avoided since such an approach has a
    tendency to become unmanageable and introduce interoperability
    issues.  These pitfalls are discussed in Section 4.2.1
 
    For the same reason, care should be taken in attempting to justify
-   allocation of new application ID for every change.  The pitfalls of
+   allocation of a new application ID for every change.  The pitfalls of
    this approach is discussed in Section 5.3.
 
    Acceptable techniques can be used to provide feature upgrades to
@@ -850,7 +853,7 @@
 
    o  Application design should consider some form of redundancy.
       Session state information is the primary data necessary for
-      backup/recovering endpoints to continue processing for an
+      backup/recovering endpoints to continue processing of an
       previously existing session.  Carrying enough information in the
       messages to reconstruct session state facilitates redundant
       implementations and is highly recommended.
@@ -858,18 +861,19 @@
    o  Application design should segregate message delivery layer
       processing from application level processing.  An example is the
       use of timers to detect lack of a response for a previously sent
-      requests.  Although the Diameter base protocol defines a watchdog
+      request.  Although the Diameter Base protocol defines a watchdog
       timer Tw, its use on application level is discouraged since Tw is
       a hop-by-hop timer and it would not be relevant for end-to-end
       message delivery error detection.  In such a case, it is
       recommended that applications should define their own set of
-      timers for such purpose.
+      timers for such a purpose.
+
    o  Applications should specify AVPs which could be used to further
-      aid in duplication detection.  In some cases, when extending an
+      aid in duplicate detection.  In some cases, when extending an
       application, existing AVPs can be reused to provide additional
-      duplication detection indicators; i.e., combination of Session-Id
+      duplicate detection indicators; i.e., combination of Session-Id
       and CC-Request-Number AVPs in the Diameter Credit Control
-      application [4].  In cases where the extensions needs to define
+      application [4].  In cases where the extensions need to define
       new AVPs, it is recommended that the new AVPs be used only for
       this purpose.
 
@@ -881,9 +885,9 @@
 
 8.  Security Considerations
 
-   This document does provides guidelines and considerations for
-   extending Diameter and Diameter applications.  It does not define nor
-   address security related protocols or schemes.
+   This document provides guidelines and considerations for
+   extending Diameter and Diameter applications.  It neither defines
+   nor addresses security related protocols or schemes.

 9.  Acknowledgments
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 30 Jul 2007 15:23:03 -0400

Hi Alexis,

Thanks for the review. I'm also waiting on reviews from others. 
Hopefully, we can get a better looking material in the next rev.

regards,
victor

> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>