From dime-bounces@ietf.org Sat Aug 2 04:56:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D45B3A67F6; Sat, 2 Aug 2008 04:56:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7003A67F6 for ; Sat, 2 Aug 2008 04:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5PJDM7rtnUD for ; Sat, 2 Aug 2008 04:56:19 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 751303A686A for ; Sat, 2 Aug 2008 04:56:17 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 13:56:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 2 Aug 2008 13:56:34 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605C12B76@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on Diameter Guidelines draft Thread-Index: Acj0ls/PWs5dEwdZRTeDZU6QbImIhA== From: To: X-OriginalArrivalTime: 02 Aug 2008 11:56:35.0589 (UTC) FILETIME=[D03B7B50:01C8F496] Subject: [Dime] comments on Diameter Guidelines draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1708103755==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1708103755== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F496.D0B3B3DB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F496.D0B3B3DB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable here is my review of the last version of the guidelines documents. A mix between editorial nits and proposal for enhancements/clarification. =20 BR, =20 Lionel =20 ************************************** [LM] Beginning of the review. [end] 1. Introduction The Diameter Base protocol document defines rules on how one would extend Diameter (see Section 1.2 of [1]). In the context of this document, extending Diameter means one of the following: 1. A new functionality is being added to an existing Diameter application without defining a new application. 2. A new Diameter application is being defined by reusing an existing application. [LM] instead of "reusing", I would say "by extending an existing application". [end] 3. A completely new application is being defined that has nothing in common with 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 combination of reusing existing or defining new commands, AVPs or AVP values. Protocol designers do, however, not have total freedom when making their design. A number of rules defined in [1] place constraints on when an extension demands a new Diameter Application to be defined or a new Command Code to be registered. The objective of this document is the following: o Clarify updated Diameter extensibility rules in the Diameter Base Protocol. o Clarify usage of certain Diameter functionality which are not explicitly described in the Diameter Base specification. [LM] "functionality" --> "functionalities [end] o Discuss design choices and provide guidelines when defining applications. o Present tradeoffs of design choices. [skip] 3. Overview [skip] When reusing existing applications, the requirements of the new applications are typically not completely unique and hence a lot can be re-used from existing specifications. Therefore, there is a greater likelihood of ambiguity on how much of the existing application can be reused and what would be the implications for both the new and existing application. To broadly categorize, the rules for reusing existing applications can fall into two categories, as listed below. Minor Extension: This, for example, is the case when optional AVPs are being defined. In general, this includes everything that is not covered by the next category. The standardization effort will be fairly small. Major Extension: Such an extension requires the definition of a new Diameter application. The rules outlined in Section 1.2 of [1] indicate when an extension is significant enough to require a new Command Code to be registered and when new Diameter applications have to be defined. Typically, these extensions require a longer standardization effort, a little bit depending on the depending on the degree of re-use, since additional aspects have to be taken into consideration. [LM] "significant enough" and "little bit" should be prohibited in a specification documentation. But I think that there is already a comment on this. [LM] I don't see how is used the wording "standardization effort". The same "effort" will be needed in case of vendor-specific extension (e.g. SDO specific extensions or vendor-specific extensions). Could it be replaced by "specification effort"? [end] The subsequent sections provide discussions about the specific Diameter Base protocol rules. 4. Adding a new command The rules are strict in this case. Adding a command to an application requires a new Diameter application to be defined.l [LM] remove "l" after "defined." [end] [LM] could we add that: "This falls into the "Major Extensions" category."? 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. =20 [LM] For this part of the text, I would propose to clarify the text as follow: "Adding a new command to an application means either defining a new command for an existing application or importing an existing command from another application, the new application inheriting then some or all of the functionality of the existing application" [end] In the former case, the decision is straightforward since this is typically a result of adding new functionality that does not yet exist. 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 simply using the existing application as it is in conjunction with any new application. In general, it is difficult to come to a hard guideline, and so a case by case study of each application requirement should be applied. [LM] proposed text, for seek of clarity: "In the former case, the decision to create an new application is straightforward since this is typically a result of adding a new functionality that does not exist yet. For the latter, the decision will depend on whether importing the command in a new application is more suitable than simply using the existing application as it is in conjunction with any other application (a new one or an existing one). Therefore, a case by case study of each application requirement should be applied. [end] Before adding or importing a command, application designers should consider the following: 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. [LM] remove reference to "deployment architecture" out of scope here. Just say: "In this case, both old and new applications..." with "s" at the end of applications [end] o Can the existing application be reused as is without fundamental changes; e.g., a non-mandatory optional AVP is sufficient to indicate support for new optional functionality, if any. [LM] "Can the existing application be reused as is without fundamental changes" --> Can the existing application be reused without major extensions requiring the definition of a new application, e.g. new funtionality introduced by the creation of an new optinal AVP." [end] 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 functionalities. [LM] proposed text: "Care should be taken to avoid a liberal method of importing existing commands in the same new application that would result in a monolithic and complex application supporting many different functionalities" [end] 5. Deleting a Command Although this is not typical, deleting an command from an existing application is fundamentally changing the application. In general, the implications of this approach are the same as Section 4 regardless of whether new commands will also be added to the resulting application. [LM] What is the meaning of "In general" in the last sentence? Removing of any command must result in the creation of a new application, isn't it? I would just say: "Removing a command to an application requires a new Diameter application to be defined. [end] In general, it is unusual to delete an 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. 6. Reusing Existing Commands This section discusses rules in adding and/or deleting AVPs from an existing command of an existing application. The cases described in this section may not necessarily result in the creation of new applications. 6.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 with the M-bit flag set, which means that a Diameter node receiving these AVPs has to understand not only their values but their semantics. This is regardless of whether these AVPs are required or optional to appear in the command; as specified by the commands ABNF. [LM] should we add that an AVP not understood will cause a failure in the message handling? It's for me the main difference between mandatory and optional AVP i.e. Optional AVP can be ignored without causing a failure. [end] [LM] use "," instead of ";" in the last sentance [end] o Optional AVPs [LM] text describing optional AVP is missing. Please cf. 3588bis and Diameterextensibility text. [end] 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 with defining a new Diameter application. [1] states that doing so would require the definition of a new application. This falls into the "Major Extensions" category. Despite the clarity of the rule, ambiguity still arises when trying to decide whether a new AVP being added should be mandatory to begin with. There are several questions that application designers should contemplate when trying to decide: [LM] just clarify that the following list is not exhaustive but illustrative. o Is it necessary for the receiving side to be able to process and understand the AVP and its content (rather than just writing it's content into to a file)? [LM] need for a separated line [end] [LM] I would use "required" instead "necessary" [end] o Do the AVPs change the state machine of the application ? o Would the presence of the new AVPs (or the newly specified value contained in an existing AVP) lead to a different number of roundtrips; effectively changing the state machine of the application? [LM] use "," instead of ";" [end] o Would the AVP be used to differentiate between old and new versions of the same application whereby the two versions are not backward compatible? o Will it have duality in meaning; i.e., be used to carry application related information as well as be used to indicate that the message is for a new application? [LM] remove the ";" [end] When one of the above questions can be answered with 'yes' then the M-bit has to be set. [LM] I would add an extra text that would introduce the second set of questions, to make clearer that we are know considering use of optional AVP. [end] o Use of optional AVPs with intersecting meaning; one AVP has partially the same usage and meaning as another AVP. The presence of both can lead to confusion. o An optional AVPs with dual purpose; i.e.; to carry applications data as well as to indicate support for one or more features. This has a tendency to introduce interpretation issues. o Adding one or more optional AVPs and indicating (usually within descriptive text for the command) that at least one of them has to be present in the command. This essentially circumventing the ABNF and is equivalent to adding a mandatory AVPs to the command. All of these practices generally result in interoperability problems so they should be avoided as much as possible. [LM] The conclusion being that a mandatory AVP is required, isn't it? [end] 6.2. Deleting AVPs from a Command Although this scenario is not as common, the deletion of AVPs from a command ABNF is significant when trying to extend an existing application. [LM] strange to see in the same sentance "deletion" and "to extend an existing application". Instead of "extend", I would use "modify" [end] When deleting an AVP from a Command the following cases need to be differentiated: [LM] bullet point style missing below [end] An AVP that is indicated as {} in the ABNF in the Command (with the M-bit set) In this case the new Command Code and subsequently a new Diameter application has to be specified. [next bullet point] An AVP that is indicated as {} in the ABNF in the Command (without the M-bit set) In this case the new Command Code and subsequently a new Diameter application has to be specified. [LM] the two above cases are exactly the same. It would maybe better to have only one bullet point, i.e. "An AVP that is indicated as {} in the ABNF in the Command (with or without the M-bit set)" [end] [LM] Am I wrong if i say that the following case is missing and should be inserted before the "{}" case? "An AVP that is indicated as <> in the ABNF in the Command (with or without the M-bit set) In this case the new Command Code and subsequently a new Diameter application has to be specified." [end] [next bullet point] An AVP that is indicated as [] in the ABNF in the Command (with the M-bit set) No new Command Code has to be specified but the definition of a new Diameter application is required. [next bullet point] An AVP that is indicated as [] in the ABNF in the Command (without the M-bit set) In this case the AVP can be deleted without consequences. If possible application designers should attempt the reuse the Command ABNF without modification and simply ignore (but not delete) any optional AVP that will not be used. This is to maintain compatibility with existing applications that will not know about the new functionality as well as maintain the integrity of existing dictionaries. 7. Reusing Existing AVPs This section discusses rules in adding, deleting or modifying the specified values of an AVP. When reusing AVPs in a new application, the AVP flag setting, such as the mandatory flag ('M'-bit), has to be re-evaluated for a new Diameter application and, if necessary, even for every Command within the application. In general, for AVPs defined outside of the base protocol, its mandatory characteristics is tied to its role within an application and Command. [LM] "characteristic is" or "characteristics are" [end] 8. Rules for new Applications 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 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 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 ([2] and [3]), Sh ([4] and [5]) etc. [LM] remove ";" in the last sentance. [end] Application design should also follow the theme of Diameter [LM] I think that it is "Application designers" instead of "Application design" [end] extensibility which in this case means to import existing AVPs and AVP values for any newly defined commands. In certain cases where accounting will be used, the models described in Section 10 should also be considered. Though some decisions may be clear, designers should also consider certain aspects of defining a new application. Some of these are described in following sections. [LM] "some of these aspects" or "some of them" instead of "some of these". [end] 8.1. Use of Application-Id in a Message [skip] 8.2. Application Specific Session Statemachine [LM] "State machine" instead of "statemachine". Apply also to the text below [end] =20 Section 8 of [1] provides session statemachines 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 define its own session statemachine. The existing session statemachines defined by [1] is not intended for general use beyond AAA services, therefore [LM] "state machines... are" instead of "statemachines... is" [end] =20 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, for example, the Rw interface for ITU-T push model. 9. End-to-End Applications Capabilities Exchange It is also possible that applications can use optional AVPs to exchange application specific capabilities and features. These AVPs are exchanged on an end-to-end basis. Examples of this can be found in [6] and [7]. The end-to-end capabilities AVPs can aid in the following cases: o Formalizing the way new functionality is added to existing applications by announcing support for it. o Applications that do not understand these AVP can discard it upon receipt. In such case, senders of the AVP can also safely assume the receiving end-point does not support any functionality carried by the AVP if it is not present in subsequent responses. o Useful in cases where deployment choices are offered and the generic design can be made available for a number of applications. [LM] inserte separation line [end] Note that this list is not meant to be comprehensive. 10. Diameter Accounting Support [skip] 11. Generic Diameter Extensions [skip] In most cases, these optional AVPs piggybacked by applications would be defined as a Grouped AVP and it would encapsulate all the functionality of the generic extension. In practice, it is not uncommon that the Grouped AVP will encapsulate an existing AVP that has previously been defined as mandatory ('M'-bit set); e.g., 3GPP IMS Cx / Dx interfaces ([2] and [3]). [LM] remove the ";" in the last sentance. [end] [LM] End of the rewiew [end] =20 =20 ------_=_NextPart_001_01C8F496.D0B3B3DB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
here = is my review of=20 the last version of the guidelines documents.
A mix = between=20 editorial nits and proposal for = enhancements/clarification.
 
BR,
 
Lionel
 
**************************************<= /FONT>
[LM] Beginning of the review. [end]

1.  Introduction

   The Diameter Base protocol document defines rules on how one would
   extend Diameter (see Section 1.2 of [1]).  In the context of this
   document, extending Diameter means one of the following:

   1.  A new functionality is being added to an existing Diameter
       application without defining a new application.

   2.  A new Diameter application is being defined by reusing an
       existing application.

[LM] instead of "reusing", I would say "by extending an existing =
application". [end]

   3.  A completely new application is being defined that has nothing in
       common with 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
   combination of reusing existing or defining new commands, AVPs or AVP
   values.  Protocol designers do, however, not have total freedom when
   making their design.  A number of rules defined in [1] place
   constraints on when an extension demands a new Diameter Application
   to be defined or a new Command Code to be registered.  The objective
   of this document is the following:

   o  Clarify updated Diameter extensibility rules in the Diameter Base
      Protocol.

   o  Clarify usage of certain Diameter functionality which are not
      explicitly described in the Diameter Base specification.

[LM] "functionality" --> "functionalities [end]

   o  Discuss design choices and provide guidelines when defining
      applications.

   o  Present tradeoffs of design choices.

[skip]

3.  Overview

[skip]

   When reusing existing applications, the requirements of the new
   applications are typically not completely unique and hence a lot can
   be re-used from existing specifications.  Therefore, there is a
   greater likelihood of ambiguity on how much of the existing
   application can be reused and what would be the implications for both
   the new and existing application.  To broadly categorize, the rules
   for reusing existing applications can fall into two categories, as
   listed below.

   Minor Extension:  This, for example, is the case when optional AVPs
      are being defined.  In general, this includes everything that is
      not covered by the next category.  The standardization effort will
      be fairly small.

   Major Extension:  Such an extension requires the definition of a new
      Diameter application.  The rules outlined in Section 1.2 of [1]
      indicate when an extension is significant enough to require a new
      Command Code to be registered and when new Diameter applications
      have to be defined.  Typically, these extensions require a longer
      standardization effort, a little bit depending on the depending on
      the degree of re-use, since additional aspects have to be taken
      into consideration.

[LM] "significant enough" and "little bit" should be prohibited in a =
specification documentation. But I think that there is already a comment =
on this.
[LM] I don't see how is used the wording "standardization effort". The =
same "effort" will be needed in case of vendor-specific extension (e.g. =
SDO specific extensions or vendor-specific extensions). Could it be =
replaced by "specification effort"? [end]

   The subsequent sections provide discussions about the specific
   Diameter Base protocol rules.


4.  Adding a new command

   The rules are strict in this case.  Adding a command to an
   application requires a new Diameter application to be defined.l

[LM] remove "l" after "defined." [end]
[LM] could we add that: "This falls into the "Major Extensions" =
category."?

   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. =20

[LM] For this part of the text, I would propose to clarify the text as =
follow:

"Adding a new command to an application means either defining a new =
command for an existing application or importing an existing command =
from another application, the new application inheriting then some or =
all of the functionality of the existing application" [end]

   In the
   former case, the decision is straightforward since this is typically
   a result of adding new functionality that does not yet exist.  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 simply using the existing
   application as it is in conjunction with any new application.

   In general, it is difficult to come to a hard guideline, and so a
   case by case study of each application requirement should be applied.

[LM] proposed text, for seek of clarity:

"In the former case, the decision to create an new application is =
straightforward since this is typically a result of adding a new =
functionality that does not exist yet. For the latter, the decision will =
depend on whether importing the command in a new application is more =
suitable than simply using the existing application as it is in =
conjunction with any other application (a new one or an existing one). =
Therefore, a case by case study of each application requirement should =
be applied. [end]

   Before adding or importing a command, application designers should
   consider the following:

   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.

[LM] remove reference to "deployment architecture" out of scope here. =
Just say: "In this case, both old and new applications..." with "s" at =
the end of applications [end]

   o  Can the existing application be reused as is without fundamental
      changes; e.g., a non-mandatory optional AVP is sufficient to
      indicate support for new optional functionality, if any.

[LM] "Can the existing application be reused as is without fundamental =
changes" --> Can the existing application be reused without major =
extensions requiring the definition of a new application, e.g. new =
funtionality introduced by the creation of an new optinal AVP." [end]

   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 functionalities.

[LM] proposed text:

"Care should be taken to avoid a liberal method of importing existing =
commands in the same new application that would result in a monolithic =
and complex application supporting many different functionalities" [end]


5.  Deleting a Command

   Although this is not typical, deleting an command from an existing
   application is fundamentally changing the application.  In general,
   the implications of this approach are the same as Section 4
   regardless of whether new commands will also be added to the
   resulting application.

[LM] What is the meaning of "In general" in the last sentence? Removing =
of any command must result in the creation of a new application, isn't =
it? I would just say: "Removing a command to an application requires a =
new Diameter application to be defined. [end]

  In general, it is unusual to delete an
   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.


6.  Reusing Existing Commands

   This section discusses rules in adding and/or deleting AVPs from an
   existing command of an existing application.  The cases described in
   this section may not necessarily result in the creation of new
   applications.

6.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
      with the M-bit flag set, which means that a Diameter node
      receiving these AVPs has to understand not only their values but
      their semantics.  This is regardless of whether these AVPs are
      required or optional to appear in the command; as specified by the
      commands ABNF.

[LM] should we add that an AVP not understood will cause a failure in =
the message handling? It's for me the main difference between mandatory =
and optional AVP i.e. Optional AVP can be ignored without causing a =
failure. [end]
[LM] use "," instead of ";" in the last sentance [end]

   o  Optional AVPs

[LM] text describing optional AVP is missing. Please cf. 3588bis and =
Diameterextensibility text. [end]

   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 with defining a new Diameter application. [1] states
   that doing so would require the definition of a new application.
   This falls into the "Major Extensions" category.  Despite the clarity
   of the rule, ambiguity still arises when trying to decide whether a
   new AVP being added should be mandatory to begin with.  There are
   several questions that application designers should contemplate when
   trying to decide:

[LM] just clarify that the following list is not exhaustive but =
illustrative.

   o  Is it necessary for the receiving side to be able to process and
      understand the AVP and its content (rather than just writing it's
      content into to a file)?

[LM] need for a separated line [end]
[LM] I would use "required" instead "necessary" [end]

   o  Do the AVPs change the state machine of the application ?

   o  Would the presence of the new AVPs (or the newly specified value
      contained in an existing AVP) lead to a different number of
      roundtrips; effectively changing the state machine of the
      application?

[LM] use "," instead of ";" [end]

   o  Would the AVP be used to differentiate between old and new
      versions of the same application whereby the two versions are not
      backward compatible?

   o  Will it have duality in meaning; i.e., be used to carry
      application related information as well as be used to indicate
      that the message is for a new application?

[LM] remove the ";" [end]

   When one of the above questions can be answered with 'yes' then the
   M-bit has to be set.

[LM] I would add an extra text that would introduce the second set of =
questions, to make clearer that we are know considering use of optional =
AVP. [end]

   o  Use of optional AVPs with intersecting meaning; one AVP has
      partially the same usage and meaning as another AVP.  The presence
      of both can lead to confusion.

   o  An optional AVPs with dual purpose; i.e.; to carry applications
      data as well as to indicate support for one or more features.
      This has a tendency to introduce interpretation issues.

   o  Adding one or more optional AVPs and indicating (usually within
      descriptive text for the command) that at least one of them has to
      be present in the command.  This essentially circumventing the
      ABNF and is equivalent to adding a mandatory AVPs to the command.

   All of these practices generally result in interoperability problems
   so they should be avoided as much as possible.

[LM] The conclusion being that a mandatory AVP is required, isn't it? =
[end]

6.2.  Deleting AVPs from a Command

   Although this scenario is not as common, the deletion of AVPs from a
   command ABNF is significant when trying to extend an existing
   application.

[LM] strange to see in the same sentance "deletion" and "to extend an =
existing application". Instead of "extend", I would use "modify" [end]

   When deleting an AVP from a Command the following cases need to be
   differentiated:

[LM] bullet point style missing below [end]

   An AVP that is indicated as {} in the ABNF in the Command (with the
   M-bit set)

      In this case the new Command Code and subsequently a new Diameter
      application has to be specified.

[next bullet point]
   An AVP that is indicated as {} in the ABNF in the Command (without
   the M-bit set)

      In this case the new Command Code and subsequently a new Diameter
      application has to be specified.

[LM] the two above cases are exactly the same. It would maybe better to =
have only one bullet point, i.e. "An AVP that is indicated as {} in the =
ABNF in the Command (with or without the M-bit set)" [end]

[LM] Am I wrong if i say that the following case is missing and should =
be inserted before the "{}" case?
  "An AVP that is indicated as <> in the ABNF in the Command (with =
or without the
   M-bit set)

      In this case the new Command Code and subsequently a new Diameter
      application has to be specified." [end]

[next bullet point]
   An AVP that is indicated as [] in the ABNF in the Command (with the
   M-bit set)

      No new Command Code has to be specified but the definition of a
      new Diameter application is required.

[next bullet point]
   An AVP that is indicated as [] in the ABNF in the Command (without
   the M-bit set)

      In this case the AVP can be deleted without consequences.

   If possible application designers should attempt the reuse the
   Command ABNF without modification and simply ignore (but not delete)
   any optional AVP that will not be used.  This is to maintain
   compatibility with existing applications that will not know about the
   new functionality as well as maintain the integrity of existing
   dictionaries.


7.  Reusing Existing AVPs

   This section discusses rules in adding, deleting or modifying the
   specified values of an AVP.

   When reusing AVPs in a new application, the AVP flag setting, such as
   the mandatory flag ('M'-bit), has to be re-evaluated for a new
   Diameter application and, if necessary, even for every Command within
   the application.  In general, for AVPs defined outside of the base
   protocol, its mandatory characteristics is tied to its role within an
   application and Command.

[LM] "characteristic is" or "characteristics are" [end]


8.  Rules for new Applications

   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
   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
   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 ([2] and
   [3]), Sh ([4] and [5]) etc.

[LM] remove ";" in the last sentance. [end]

   Application design should also follow the theme of Diameter

[LM] I think that it is "Application designers" instead of "Application =
design" [end]

   extensibility which in this case means to import existing AVPs and
   AVP values for any newly defined commands.  In certain cases where
   accounting will be used, the models described in Section 10 should
   also be considered.  Though some decisions may be clear, designers
   should also consider certain aspects of defining a new application.
   Some of these are described in following sections.

[LM] "some of these aspects" or "some of them" instead of "some of =
these". [end]

8.1.  Use of Application-Id in a Message

[skip]

8.2.  Application Specific Session Statemachine

[LM] "State machine" instead of "statemachine". Apply also to the text =
below [end]
  =20
   Section 8 of [1] provides session statemachines 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 define its own
   session statemachine.  The existing session statemachines defined by
   [1] is not intended for general use beyond AAA services, therefore

[LM] "state machines... are" instead of "statemachines... is" [end]
=20
   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, for
   example, the Rw interface for ITU-T push model.


9.  End-to-End Applications Capabilities Exchange

   It is also possible that applications can use optional AVPs to
   exchange application specific capabilities and features.  These AVPs
   are exchanged on an end-to-end basis.  Examples of this can be found
   in [6] and [7].

   The end-to-end capabilities AVPs can aid in the following cases:

   o  Formalizing the way new functionality is added to existing
      applications by announcing support for it.

   o  Applications that do not understand these AVP can discard it upon
      receipt.  In such case, senders of the AVP can also safely assume
      the receiving end-point does not support any functionality carried
      by the AVP if it is not present in subsequent responses.

   o  Useful in cases where deployment choices are offered and the
      generic design can be made available for a number of applications.

[LM] inserte separation line [end]

Note that this list is not meant to be comprehensive.


10.  Diameter Accounting Support

[skip]

11.  Generic Diameter Extensions

[skip]

   In most cases, these optional AVPs piggybacked by applications would
   be defined as a Grouped AVP and it would encapsulate all the
   functionality of the generic extension.  In practice, it is not
   uncommon that the Grouped AVP will encapsulate an existing AVP that
   has previously been defined as mandatory ('M'-bit set); e.g., 3GPP
   IMS Cx / Dx interfaces ([2] and [3]).

[LM] remove the ";" in the last sentance. [end]

[LM] End of the rewiew [end]
 
 
------_=_NextPart_001_01C8F496.D0B3B3DB-- --===============1708103755== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1708103755==-- From dime-bounces@ietf.org Sat Aug 2 06:52:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2A03A68A7; Sat, 2 Aug 2008 06:52:16 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C843A68FF for ; Sat, 2 Aug 2008 06:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqH4Wx1-ltbJ for ; Sat, 2 Aug 2008 06:52:13 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 00B0D3A688C for ; Sat, 2 Aug 2008 06:52:12 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 15:52:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 2 Aug 2008 15:52:27 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605C12B77@ftrdmel2> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D45C7@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3588bis - ABNF & M-bit flag for AVP Thread-Index: Acjw7YjStKteo9ySRC6BxaiSo240IgDtAeqQ References: <033458F56EC2A64E8D2D7B759FA3E7E7012D45C7@sonusmail04.sonusnet.com> From: To: X-OriginalArrivalTime: 02 Aug 2008 13:52:28.0324 (UTC) FILETIME=[0062A640:01C8F4A7] Subject: [Dime] 3588bis - ABNF & M-bit flag for AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi All, We had several discussions on the link between ABNF specifications and the related M-bit setting for fixed, required and optional AVPs. We concluded that both notions were decoupled and this is documented in 3588bis draft in the section 1.2.4. However, I think that it could be useful to provide further clarifications on this topic in order to help application designers in their specification. This could be done the 3588bis or in the guideline document (no preference). My proposal would be to add that, normally, fixed and required AVPs in the command code and Grouped AVP ABNF specifications should have the M-bit set, as these AVPs will always appear in the command or the grouped AVP. However, we may have some use cases in which fixed or required AVPs need not to be understand by all the Diameter peers (e.g. fixed AVP only useful for intermadiate nodes). In such cases, a fixed or required AVP in ABNF may have the M-bit flag cleared. Any opinion on this proposal? BR, Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 3 09:45:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598323A691A; Sun, 3 Aug 2008 09:45:01 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8763A68A2 for ; Sun, 3 Aug 2008 09:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6CDFkcI3BbL for ; Sun, 3 Aug 2008 09:44:59 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 176243A691A for ; Sun, 3 Aug 2008 09:44:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id A72CBA8065 for ; Sun, 3 Aug 2008 12:45:21 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04505-10 for ; Sun, 3 Aug 2008 12:45:18 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Sun, 3 Aug 2008 12:45:18 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Aug 2008 12:45:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Aug 2008 22:15:15 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C146AB7@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3588bis - ABNF & M-bit flag for AVP Thread-Index: Acjw7YjStKteo9ySRC6BxaiSo240IgDtAeqQADluBeY= References: <033458F56EC2A64E8D2D7B759FA3E7E7012D45C7@sonusmail04.sonusnet.com> <7DBAFEC6A76F3E42817DF1EBE64CB02605C12B77@ftrdmel2> From: "Sarkar, Biplab" To: , X-OriginalArrivalTime: 03 Aug 2008 16:45:18.0746 (UTC) FILETIME=[500D37A0:01C8F588] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] 3588bis - ABNF & M-bit flag for AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi All, I think its a good suggestion. I think an AVP is termed as mandatory with its association to the command. So the relationship AVP->Cmd needs an attribute about their occurrence and interpretation. And also there should be some way to say that an AVP can't be in a particular command AVP !-> Cmd. So the current approach to associate the M-bit to the AVP needs some change. Thanks & Regards Biplab -----Original Message----- From: dime-bounces@ietf.org on behalf of lionel.morand@orange-ftgroup.com Sent: Sat 8/2/2008 7:22 PM To: dime@ietf.org Subject: [Dime] 3588bis - ABNF & M-bit flag for AVP Hi All, We had several discussions on the link between ABNF specifications and the related M-bit setting for fixed, required and optional AVPs. We concluded that both notions were decoupled and this is documented in 3588bis draft in the section 1.2.4. However, I think that it could be useful to provide further clarifications on this topic in order to help application designers in their specification. This could be done the 3588bis or in the guideline document (no preference). My proposal would be to add that, normally, fixed and required AVPs in the command code and Grouped AVP ABNF specifications should have the M-bit set, as these AVPs will always appear in the command or the grouped AVP. However, we may have some use cases in which fixed or required AVPs need not to be understand by all the Diameter peers (e.g. fixed AVP only useful for intermadiate nodes). In such cases, a fixed or required AVP in ABNF may have the M-bit flag cleared. Any opinion on this proposal? BR, Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 6 02:10:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD283A6ACE; Wed, 6 Aug 2008 02:10:02 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34A83A6A15 for ; Wed, 6 Aug 2008 02:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0CN2-cdmwPI for ; Wed, 6 Aug 2008 02:09:59 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id DA5BF28C0FC for ; Wed, 6 Aug 2008 02:09:30 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id m769A026023084 for ; Wed, 6 Aug 2008 18:10:00 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m769A0Tf022305 for ; Wed, 6 Aug 2008 18:10:00 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m769A0Mi022302 for ; Wed, 6 Aug 2008 18:10:00 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 82A146E92 for ; Wed, 6 Aug 2008 18:10:00 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail2.nict.go.jp (Postfix) with ESMTP id 640926E79 for ; Wed, 6 Aug 2008 18:10:00 +0900 (JST) Message-ID: <48996A44.7000608@nict.go.jp> Date: Wed, 06 Aug 2008 18:09:24 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Subject: [Dime] Failback first message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, In the failback mechanism of Diameter, it is unclear from the specification what must be the first message exchanged with the re-opened peer. The detail of the problem follow: - From RFC3539 (Transport Profile) that defines the algorithm of failover/failback detection: "If the connection is successfully opened, then the watchdog message is sent. Once three watchdog messages have been sent and responded to, the connection is returned to service, and transactions are once again sent over it." - From the Diameter draft, in section 5.6 (Peer State Machine): " A CER message is always sent on the initiating connection immediately after the connection request is successfully completed." Furthermore, the same draft claims that: "This state machine is closely coupled with the state machine described in [RFC3539 ], which is used to open, close, failover, probe, and reopen transport connections." but the states from that RFC are not represented in the peer state machine (suspect, closed, reopen), leading to my confusion... Can someone tell me what is supposed to happen after a transport connection has been shut down because of failure, and then re-established? And what about interaction with TLS? Thank in advance for any information... Sebastien. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 6 08:42:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C3828C3AF; Wed, 6 Aug 2008 08:42:43 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E76B53A6AE8; Wed, 6 Aug 2008 08:42:39 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080806154239.E76B53A6AE8@core3.amsl.com> Date: Wed, 6 Aug 2008 08:42:39 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] Last Call: draft-ietf-dime-diameter-api (The Diameter API) to Informational RFC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'The Diameter API ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-08-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14521&rfc_flag=0 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 7 03:38:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ACA83A6B23; Thu, 7 Aug 2008 03:38:07 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A663A6B23 for ; Thu, 7 Aug 2008 03:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[AWL=-3.437, BAYES_00=-2.599, FRT_PROFIT2=10.357, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZizo1Ud0mTe for ; Thu, 7 Aug 2008 03:38:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E819B3A6A18 for ; Thu, 7 Aug 2008 03:38:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m77AccwX010693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Aug 2008 12:38:38 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m77Acbv3018088 for ; Thu, 7 Aug 2008 12:38:38 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 12:38:38 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 12:38:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 13:37:58 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-korhonen-dime-pmip6-03.txt Thread-Index: Acj4eaiG9YMPTYCERouPYKcXMzjY6Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 07 Aug 2008 10:38:38.0072 (UTC) FILETIME=[C047C780:01C8F879] Subject: [Dime] Review of draft-korhonen-dime-pmip6-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org A few review comments. In the abstract you write: " Rather than defining a completely new set of attributes or a new Diameter application this specification leverages the work that has already been done for the Mobile IPv6 bootstrapping. " This sentence is somewhat misleading since you define a Diameter application. Figure 1 is helpful but I think you could point out that you are actually describing two different "interfaces" in this document. I initially did not got that point since you referred also to the Diameter Mobile IPv6 boostrapping work where we separated them into 2 documents. Hence, I would enhance the figure with something like: +--------+ | HAAA & | Diameter +-----+ | Policy |<--(1)--->| LMA | | Profile| +-----+ +--------+ | <--- LMA-Address ^ | | // \\ +---|------------- //---\\----------------+ ( | IPv4/IPv6 // \\ Proxy Mobile IPv6 ( | Network // \\ ) +---|-----------//---------\\-------------+ | // \\ Diameter // <- Tunnel1 \\ <- Tunnel2 (2) // \\ | |- MAG-Address1 |- MAG-Address2 | +----+ +----+ +---->|MAG1| |MAG2| +----+ +----+ | | | | [MN1] [MN2] Legend: (1): LMA <-> HAAA interaction is described in Section 6 (2): MAG <-> HAAA interaction is described in Section 5 * I was also lacking sementic of the PMIP6-DHCP-Address AVP a bit. How does the information flow look like? * MIP6-Agent-Info AVP The description currently does not provide enough information why this AVP is needed. What happens when an entity receives this AVP? Why would one send it? I also wonder whether it wouldn't make sense to create a new AVP if the semantic is sufficiently different. * MAG-to-HAAA: You might want to make it explicit in the text that you do not define a new Diameter application for this interface. The LMA to HAAA section starts very similar but defines a new Diameter application. Both sections say "This document re-uses the Diameter NASREQ [6] and the EAP [7] applications". While this is correct the outcome is very different. I would also shorten the subject header a bit. Something like "MAG-to-HAAA Interface" and "LMA-to-HAAA Inferface" should be sufficient. The following text seems a bit fuzzy to me: " The Diameter response messages MAY contain Framed-IPv6-Prefix and/or Framed-IPv4-Address AVPs. For example a local Diameter proxy MAY add those in order to advertise locally available prefixes and addresses as well [16]. It is also possible that PMIPv6 mobility support is not allowed for a subscription. In this case, a MAG may still provide normal IP connectivity to the MN using, for example, local address pools. " What is the semantic of the Framed-IPv6-Prefix in relationship to the other addresses being defined in this document? * LMA-to-MAG The text at the beginning of the sentence is repeated again in Section 6.2. You write: " The identity SHOULD be the same as used on the MAG to HAAA interface, but in a case those identities differ the HAAA MUST have a mechanism of mapping the MN identity used on the MAG to HAAA interface to the identity used on the LMA to HAAA interface. " In what cases are they different? You write: " If the PBU contains the MN interface identifier option, the Calling- Station-Id AVP SHOULD be included in the request message containing the received interface identifier. Furthermore, if the PBU contains the Service Selection mobility option [18], the Called-Station-Id AVP SHOULD be included in the request message containing the received service identifier. " Why do you overload the Called-Station-Id? Are those the only two cases, i.e., is it MUST contain either interface id or service identifier? In the introduction you say that this is only used for authorization, see: " A new Diameter application is needed for the LMA to HAAA interface when authorizing Proxy Binding Updates and subscriber's mobility service session. " Does this mean that you set the request to 'authorize-only'? * AVP Occurrence Table section I would define separate AVP flag tables for the two interfaces and for the commands. For example, in Section 6.2 you define this new application; do you expect certain AVPs to be understood by the receiving end? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 8 16:32:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DBF3A6924; Fri, 8 Aug 2008 16:32:20 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C988E3A6924 for ; Fri, 8 Aug 2008 16:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.108 X-Spam-Level: **** X-Spam-Status: No, score=4.108 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PROFIT2=10.357, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3Nbq0KA55yD for ; Fri, 8 Aug 2008 16:32:18 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 4B88A3A683A for ; Fri, 8 Aug 2008 16:32:17 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 01:32:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 9 Aug 2008 01:32:14 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D5C4@SEHAN021MB.tcad.telia.se> In-Reply-To: <3E2C3D74-A80F-46FF-9BB8-042B2CF6F1D1@iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-korhonen-dime-pmip6-03.txt Thread-Index: Acj5ragvbyiUXTHTRtC7GYv3U1t7dwAACwvQ References: <129C432B-7E81-45F2-9AEA-60631858073A@iki.fi> <3E2C3D74-A80F-46FF-9BB8-042B2CF6F1D1@iki.fi> From: To: X-OriginalArrivalTime: 08 Aug 2008 23:32:14.0291 (UTC) FILETIME=[FCEA7A30:01C8F9AE] Subject: Re: [Dime] Review of draft-korhonen-dime-pmip6-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org It seems this never reached the Dime mailing list for some reason.. resending it. Cheers, JOuni ------- From: Jouni Korhonen Date: August 8, 2008 10:26:49 AM GMT+03:00 To: "Tschofenig, Hannes (NSN - FI/Espoo)" hannes.tschofenig@nsn.com> Cc: Subject: Re: [Dime] Review of draft-korhonen-dime-pmip6-03.txt Hi Hannes, Thanks for a review. See some replies inline. On Aug 7, 2008, at 1:37 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > A few review comments. > > In the abstract you write: > > " > Rather than defining a completely new set of > attributes or a new Diameter application this specification > leverages > the work that has already been done for the Mobile IPv6 > bootstrapping. > " > > This sentence is somewhat misleading since you define a Diameter > application. Ok. Actually we got two interfaces (as you note later). The other defines an application and the other one does not. I need to clarify the text above. > Figure 1 is helpful but I think you could point out that you are > actually describing two different "interfaces" in this document. I > initially did not got that point since you referred also to the > Diameter Mobile IPv6 boostrapping work where we separated them into 2 > documents. > > Hence, I would enhance the figure with something like: > > > +--------+ > | HAAA & | Diameter +-----+ > | Policy |<--(1)--->| LMA | > | Profile| +-----+ > +--------+ | <--- LMA-Address > ^ | > | // \\ > +---|------------- //---\\----------------+ > ( | IPv4/IPv6 // \\ Proxy Mobile IPv6 > ( | Network // \\ ) > +---|-----------//---------\\-------------+ > | // \\ > Diameter // <- Tunnel1 \\ <- Tunnel2 > (2) // \\ > | |- MAG-Address1 |- MAG-Address2 > | +----+ +----+ > +---->|MAG1| |MAG2| > +----+ +----+ > | | > | | > [MN1] [MN2] > > > Legend: > > (1): LMA <-> HAAA interaction is described > in Section 6 > (2): MAG <-> HAAA interaction is described > in Section 5 OK. > * I was also lacking sementic of the PMIP6-DHCP-Address AVP a bit. > How does the information flow look like? The AAA may return a DHCP (4 or 6) server address to the MAG. THis would be useful in deployments where the MAG implements a DHCP Relay. So the MAG receives the DHCP Server address over the MAG-AAA interface, and uses the server address for *this* subscriber/realm when relaying DHCP requests. > * MIP6-Agent-Info AVP > > The description currently does not provide enough information why > this > AVP is needed. > What happens when an entity receives this AVP? > Why would one send it? This is one way of doing dynamic LMA discovery. So the AAA knows which LMA to assign for the authenticating subscriber. MAG uses it to figure out the LMA where to send subsequent PBUs.. > I also wonder whether it wouldn't make sense to create a new AVP > if the > semantic is sufficiently different. The behavior from AAA interface point of view is equivalent to integrated bootstrapping.. just that the HA/LMA information is not passed to the MN but used by MAG. I agree we should define new AVPs inside the MIP6-Agent-Info dedicated for the LMA address. We have talked this offline with some folks. > * MAG-to-HAAA: > > You might want to make it explicit in the text that you do not > define a > new Diameter application for this interface. The LMA to HAAA section > starts very similar but defines a new OK. > Diameter application. Both sections say "This document re-uses the > Diameter NASREQ [6] and the EAP [7] > applications". While this is correct the outcome is very different. > > I would also shorten the subject header a bit. Something like > "MAG-to-HAAA Interface" and "LMA-to-HAAA Inferface" should be > sufficient. OK. > The following text seems a bit fuzzy to me: > > " > The Diameter response messages MAY contain Framed-IPv6-Prefix > and/or > Framed-IPv4-Address AVPs. For example a local Diameter proxy > MAY add > those in order to advertise locally available prefixes and > addresses > as well [16]. It is also possible that PMIPv6 mobility support is > not allowed for a subscription. In this case, a MAG may still > provide normal IP connectivity to the MN using, for example, local > address pools. > " > > What is the semantic of the Framed-IPv6-Prefix in relationship to the > other > addresses being defined in this document? I am not sure if this is valid anymore but the originally the reason was the following: It was discussed whether it would make sense to allow PMIP-based mobility for some prefixes and for some not. So the prefixes with mobility would be signaled using PMIP specific AVPs where as prefixes without mobility would use Framed-IPv6-Prefix AVPs. MAG/NAS could then treat prefixes differently (note that how the MN would know the difference is not solved yet.. there has been RA/RS based proposals around). > * LMA-to-MAG > > The text at the beginning of the sentence is repeated again in > Section > 6.2. > > > You write: > > " > The identity SHOULD be the same as > used on the MAG to HAAA interface, but in a case those identities > differ the HAAA MUST have a mechanism of mapping the MN > identity used > on the MAG to HAAA interface to the identity used on the LMA to > HAAA > interface. > " > > In what cases are they different? One example.. the MN authenticates (over the MAG-AAA interface) using some EAP-method that provides identity hiding. So the identity the MAG/NAS puts into the User-Name AVP for the access authentication could be then different from what gets used in a PBU as the MN-ID. The LMA would use the identity taken from the PBU MN-ID when communicating with the AAA over the LMA-AAA interface. So the identities could potentially be different and the AAA must be able to map them as one internally in that case. If some deployment uses the same identity in all cases & places, fine.. but that must not restrict the flexibility of the AAA interfaces. > > You write: > " > If the PBU contains the MN interface identifier option, the > Calling- > Station-Id AVP SHOULD be included in the request message > containing > the received interface identifier. Furthermore, if the PBU > contains > the Service Selection mobility option [18], the Called-Station- > Id AVP > SHOULD be included in the request message containing the received > service identifier. > " > > Why do you overload the Called-Station-Id? > Are those the only two cases, i.e., is it MUST contain either > interface > id or service identifier? Oops. Yes. Good catch. For the services we should use the same AVP that is now defined for the mip6-split document (i.e. the Service- Selection AVP). > > In the introduction you say that this is only used for authorization, > see: > " > A new Diameter application is needed for the LMA to HAAA interface > when authorizing Proxy Binding Updates and subscriber's mobility > service session. > " > > Does this mean that you set the request to 'authorize-only'? Yes. Good catch again. > * AVP Occurrence Table section > > I would define separate AVP flag tables for the two interfaces and > for > the commands. > > For example, in Section 6.2 you define this new application; do you > expect certain AVPs to be understood by the receiving end? > Yeah. These tables need work. Cheers, Jouni > Ciao > Hannes > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 13 04:15:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26F473A6B4B; Wed, 13 Aug 2008 04:15:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F473A6BA1 for ; Wed, 13 Aug 2008 04:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmalEFBncFrC for ; Wed, 13 Aug 2008 04:15:25 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id BC8233A6B02 for ; Wed, 13 Aug 2008 04:15:24 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 90712AF039 for ; Wed, 13 Aug 2008 13:15:02 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 7642EAF036 for ; Wed, 13 Aug 2008 13:15:02 +0200 (CEST) Message-ID: <48A2C236.9040300@restena.lu> Date: Wed, 13 Aug 2008 13:15:02 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20071114) MIME-Version: 1.0 To: dime@ietf.org X-Virus-Scanned: ClamAV Subject: [Dime] review of draft-korhonen-dime-nai-routing-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, 2. Terminology --------------------- The definition of NAI could use a reference to RFC4282. The definition of NAP is quite ambiguous ("entity which owns the = network" - this even applies to the physical person Stefan Winter, since = I own a network at home and I am an entity) . Later in the text I = figured that it is the first-hop Diameter server (right?), taking access = requests from NASes, and either handling them itself or = routing/forwarding them according to realms. 3. Prob Overview ------------------------ First bullet: " The update would be done by intermediating Diameter agents that participate= to realm based request routing. Specifically, this would concern Diameter proxies." It would concern ONLY proxies, right? Relays, Redirectors and translation a= gents should not mess with the User-Name AVP in this context. So, I'd sugge= st to remove the general mention of agents in the first sentence and make c= lear that it only concerns proxy agents. 4.1 Enhanced Request Routing solution ------------------------------------- RFC4282 makes clear that the presence of a ! in the user name part does not= necessarily mean that the username is decorated (since a ! can also be "ju= st" part of a username, with no special decoration meaning). Which I find v= ery uneasy in RFC4282, as it opens room for speculation on how a node shoul= d determine if the username it got should be treated as decorated or not. This room for speculation makes this draft harder to handle. Section 4.1 is= silent in how exactly to determine whether a User-Name AVP is decorated. T= hat being said, once the fact is determined, the three bullets make a reaso= nable alogrithm IMHO. So maybe the algorithm should be preceded with a look= up (see below). The last bullet should read though:"... using the normal re= quest routing _or request forwarding_ rules as defined ..." since the last = hop before the home realm will by definition do realm forwarding, not routi= ng, since that peer will be directly connected. 4.1 Figure 2 ------------ When 2) is reached, the conversion of the next hop cannot happen completely= automatically because the possible meaninglessness of ! needs to be taken = into account. Furthermore, RFC4282 states that "the interpretation of the u= sername is up to an agreement between the identified user and the realm giv= en after the @" The decision path for Realm-Z when receiving the request ne= eds to be: - incoming User-Name =3D realm-X!realm-H!username@realm-Z - decide: is there an agreement between username and me that I should treat= ! in the local part as special character? * Yes: continue as in the depicted flow * No: treat as local request where the user's name spans the entire "real= m-X!realm-H!username" Needless to say that it is rather difficult for the server for realm-Z to h= ave an agreement with a roaming user from realm-H (since the two have no di= rect relation to each other, other than that a Diameter routing path betwee= n Z and H exists). As a sidenote, the possible meaninglessness of ! in RFC4= 282 makes life more complicated than I'd like to. 4.2 Backwards Compatibility --------------------------- The decision to not recommend implementation in existing Apps takes out a l= ot of value from this draft. One of its primary uses would be NASREQ, for e= xample. The mechanisms in this document have such a wide-reaching use that = I would much rather recommend to put it into 3588bis and require it also fo= r existing Apps. Also the two statements "RECOMMENDED... only applied for new applications" = and "MAY also in existing applications" (paraphrased) is contradicting. It = is either not recommended to retrofit it into existing apps, or it is compl= etely optional. Greetings, Stefan Winter P.S.: I foolishly agreed to make another review, one of the QoS documents. = I don't quite remember which of the three, and the minutes aren't out yet. = Can someone remind me of my duties? -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 13 06:19:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7F53A69E7; Wed, 13 Aug 2008 06:19:55 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2C93A6990 for ; Wed, 13 Aug 2008 06:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=5.178, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10-nK45zRyqE for ; Wed, 13 Aug 2008 06:19:52 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 7E5053A68C4 for ; Wed, 13 Aug 2008 06:19:49 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 15:19:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 15:19:37 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D62B@SEHAN021MB.tcad.telia.se> In-Reply-To: <48A2C236.9040300@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] review of draft-korhonen-dime-nai-routing-00 Thread-Index: Acj9NiDnkFH9s3guQWelSWyi+26FpwAAI5tA References: <48A2C236.9040300@restena.lu> From: To: , X-OriginalArrivalTime: 13 Aug 2008 13:19:35.0078 (UTC) FILETIME=[3AC87460:01C8FD47] Subject: Re: [Dime] review of draft-korhonen-dime-nai-routing-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Stefan, Thanks for the review! See some comments inline. > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On = > Behalf Of Stefan Winter > Sent: 13. elokuuta 2008 14:15 > To: dime@ietf.org > Subject: [Dime] review of draft-korhonen-dime-nai-routing-00 > = > = > Hello, > = > 2. Terminology > --------------------- > The definition of NAI could use a reference to RFC4282. Ups. OK. > The definition of NAP is quite ambiguous ("entity which owns the = > network" - this even applies to the physical person Stefan = > Winter, since = > I own a network at home and I am an entity) . Later in the text I = It could be you.. assuming you manage and have access to AAA roaming infra from you NAS etc. > figured that it is the first-hop Diameter server (right?), = > taking access = > requests from NASes, and either handling them itself or = > routing/forwarding them according to realms. It could be like this. A NAP may though also own & manage only access points and NASes . > 3. Prob Overview > ------------------------ > = > First bullet: " > = > The update would be done by intermediating Diameter agents = > that participate to > realm based request routing. Specifically, this would concern > Diameter proxies." > = > It would concern ONLY proxies, right? Relays, Redirectors and = > translation agents should not mess with the User-Name AVP in = > this context. So, I'd suggest to remove the general mention = > of agents in the first sentence and make clear that it only = > concerns proxy agents. Currently, the text applies only to proxies. The unpublished first version of the I-D also covered relays. We still play with the idea of relays as some of us feel that the I-D should also cover them. If we end up with proxies only, the text should be more precise then as you noted. > 4.1 Enhanced Request Routing solution > ------------------------------------- > = > RFC4282 makes clear that the presence of a ! in the user name = > part does not necessarily mean that the username is decorated = > (since a ! can also be "just" part of a username, with no = > special decoration meaning). Which I find very uneasy in = > RFC4282, as it opens room for speculation on how a node = > should determine if the username it got should be treated as = > decorated or not. One more reason for this I-D.. and the fact that we propose using NAI decoration only when new applications are defined. > This room for speculation makes this draft harder to handle. = > Section 4.1 is silent in how exactly to determine whether a = > User-Name AVP is decorated. That being said, once the fact is = Section 4.2 recommends that NAI decoration is only applied to new applications. This way the application definition can explicitly state that within the application NAI decoration must be supported. I don't think we have a better way to determine whether NAI is decorated or not. > determined, the three bullets make a reasonable alogrithm = > IMHO. So maybe the algorithm should be preceded with a lookup = > (see below). The last bullet should read though:"... using = > the normal request routing _or request forwarding_ rules as = > defined ..." since the last hop before the home realm will by = > definition do realm forwarding, not routing, since that peer = > will be directly connected. Ok. > = > 4.1 Figure 2 > ------------ > = > When 2) is reached, the conversion of the next hop cannot = > happen completely automatically because the possible = > meaninglessness of ! needs to be taken into account. = See above on this. > Furthermore, RFC4282 states that "the interpretation of the = > username is up to an agreement between the identified user = > and the realm given after the @" The decision path for = > Realm-Z when receiving the request needs to be: > = > - incoming User-Name =3D realm-X!realm-H!username@realm-Z > - decide: is there an agreement between username and me that = > I should treat ! in the local part as special character? > * Yes: continue as in the depicted flow > * No: treat as local request where the user's name spans = > the entire "realm-X!realm-H!username" Well.. The NAS is supposed to know this by configuration. E.g. if the NAS were to use EAP application, there is no quarantee of the interpretation of '!'. On the other hand, if the NAS were to use EAP-With-Steroids application, which knows about decoration, the interpretation of '!' is quaranteed. I will clarify this. > Needless to say that it is rather difficult for the server = > for realm-Z to have an agreement with a roaming user from = > realm-H (since the two have no direct relation to each other, = > other than that a Diameter routing path between Z and H = Why not? Such roaming arrangements are already valid. > exists). As a sidenote, the possible meaninglessness of ! in = > RFC4282 makes life more complicated than I'd like to. In a commercial world.. when someone joins to a certain roaming consortium they need to accept and adhere to certain rules and guidelines. If the roaming consortium mandates support for NAI decoration, there is no room for misinterpretations. > 4.2 Backwards Compatibility > --------------------------- > The decision to not recommend implementation in existing Apps = > takes out a lot of value from this draft. One of its primary = > uses would be NASREQ, for example. The mechanisms in this = > document have such a wide-reaching use that I would much = > rather recommend to put it into 3588bis and require it also = > for existing Apps. You don't just gain backwards compatibility with existing implementations.. if those application won't change their existing code. A simple way to migrate from NASREQ is for example to define a NASREQv2 application, which is identical to RFC4005 except that it refers to this I-D on User-Name part etc. > Also the two statements "RECOMMENDED... only applied for new = > applications" and "MAY also in existing applications" = > (paraphrased) is contradicting. It is either not recommended = > to retrofit it into existing apps, or it is completely optional. Hmm.. agree. I would appreciate better way to express the following: For new applications it is recommended to implement this I-D to quarantee support for NAI decoration. IMHO, we cannot mandate it for every new application. Also there are existing specifications that simply mandate support for NAI decoration for existing EAP and NASREQ applications but are applicable _only_ for a certain well defined system within certain releases of that same system.. ;) Cheers, Jouni > = > Greetings, > = > Stefan Winter > = > P.S.: I foolishly agreed to make another review, one of the = > QoS documents. I don't quite remember which of the three, and = > the minutes aren't out yet. Can someone remind me of my duties? > = > = > -- = > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = > Nationale et de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > = > Tel: +352 424409 1 > Fax: +352 422473 > = > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 13 22:24:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981A63A68B9; Wed, 13 Aug 2008 22:24:16 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8133B3A67F3 for ; Wed, 13 Aug 2008 22:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.66 X-Spam-Level: X-Spam-Status: No, score=-3.66 tagged_above=-999 required=5 tests=[AWL=2.589, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce--9DqH3MOc for ; Wed, 13 Aug 2008 22:24:14 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 112E73A68B9 for ; Wed, 13 Aug 2008 22:24:13 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 07:24:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 07:24:10 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D631@SEHAN021MB.tcad.telia.se> In-Reply-To: <489F4445.3000304@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-korhonen-dime-pmip6-03.txt Thread-Index: Acj7IP9RrubrBCAOQfSHg5hCrcwVKQCRPo7g References: <129C432B-7E81-45F2-9AEA-60631858073A@iki.fi> <3E2C3D74-A80F-46FF-9BB8-042B2CF6F1D1@iki.fi> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D5C4@SEHAN021MB.tcad.telia.se> <489F4445.3000304@gmx.net> From: To: X-OriginalArrivalTime: 14 Aug 2008 05:24:10.0650 (UTC) FILETIME=[FB4FE7A0:01C8FDCD] Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-korhonen-dime-pmip6-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, Further replies inline. I cut those parts away we already resolved. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: 10. elokuuta 2008 22:41 > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: dime@ietf.org > Subject: Re: [Dime] Review of draft-korhonen-dime-pmip6-03.txt [snip] > >> * I was also lacking sementic of the PMIP6-DHCP-Address AVP a bit. > >> How does the information flow look like? > >> > > > > The AAA may return a DHCP (4 or 6) server address to the MAG. THis > > would be useful in deployments where the MAG implements a > DHCP Relay. > > So the MAG receives the DHCP Server address over the MAG-AAA > > interface, > > and uses the server address for *this* subscriber/realm > when relaying > > DHCP requests. > > > I am just wondering why the AAA server controls which DHCP server is > contacted by the DHCP relay. > Have you checked with the DHC folks to see what they think > about this idea? It is for centralizing the configuration. Say, my MAGs serve +50 realms and each of those would have a different DHCP server. Now if I need to make any change to server addressing (renumber existing, add a new one or a remove one) I would need to configure all MAGs one by one. We already do the same centralized management for LMAs and HAs. > >> * MIP6-Agent-Info AVP > >> > >> The description currently does not provide enough information why > >> this > >> AVP is needed. > >> What happens when an entity receives this AVP? > >> Why would one send it? > >> > > > > This is one way of doing dynamic LMA discovery. So the AAA > knows which > > LMA to assign for the authenticating subscriber. MAG uses > > it to figure > > out the LMA where to send subsequent PBUs.. > > > > > Maybe we could provide this additional piece of information in the > document. Ack. [snip] > >> The following text seems a bit fuzzy to me: > >> > >> " > >> The Diameter response messages MAY contain Framed-IPv6-Prefix > >> and/or > >> Framed-IPv4-Address AVPs. For example a local Diameter proxy > >> MAY add > >> those in order to advertise locally available prefixes and > >> addresses > >> as well [16]. It is also possible that PMIPv6 mobility > support is > >> not allowed for a subscription. In this case, a MAG may still > >> provide normal IP connectivity to the MN using, for > example, local > >> address pools. > >> " > >> > >> What is the semantic of the Framed-IPv6-Prefix in > relationship to the > >> other > >> addresses being defined in this document? > >> > > > > I am not sure if this is valid anymore but the originally > the reason > > was the following: > > > > It was discussed whether it would make sense to allow PMIP-based > > mobility > > for some prefixes and for some not. So the prefixes with mobility > > would be > > signaled using PMIP specific AVPs where as prefixes without > > mobility would > > use Framed-IPv6-Prefix AVPs. MAG/NAS could then treat prefixes > > differently > > (note that how the MN would know the difference is not > solved yet.. > > there > > has been RA/RS based proposals around). > > > > > So, has the discussion concluded already? > Where are these discussions taking place? There was some discussion and I-Ds in NetLMM and later in the unofficial NetExt bar BoF. > >> * LMA-to-MAG > >> > >> The text at the beginning of the sentence is repeated again in > >> Section > >> 6.2. > >> > >> > >> You write: > >> > >> " > >> The identity SHOULD be the same as > >> used on the MAG to HAAA interface, but in a case those > identities > >> differ the HAAA MUST have a mechanism of mapping the MN > >> identity used > >> on the MAG to HAAA interface to the identity used on > the LMA to > >> HAAA > >> interface. > >> " > >> > >> In what cases are they different? > >> > > > > One example.. the MN authenticates (over the MAG-AAA > interface) using > > some EAP-method that provides identity hiding. So the identity the > > MAG/NAS puts into the User-Name AVP for the access authentication > > could be then different from what gets used in a PBU as the MN-ID. > > The LMA would use the identity taken from the PBU MN-ID when > > communicating > > with the AAA over the LMA-AAA interface. So the identities could > > potentially > > be different and the AAA must be able to map them as one > internally > > in that > > case. If some deployment uses the same identity in all > cases & places, > > fine.. but that must not restrict the flexibility of the AAA > > interfaces. > > > > That's an interesting issue with respect to security. Could you enlighten me what issue? > I have not followed the security discussions in NETLMM > regarding PMIPv6 > but I recall that there was once a discussion whether the > security for > the PMIPv6 signaling is based on a MN-basis (similar to MIPv6) or > independent of the user. > > What is the discussion status? I think what I had above is on slightly different topic. The security in RFC5213 is between MAG and LMA, not per MN. If that is what you are asking.. [snap] Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 14 05:53:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575C53A6DAD; Thu, 14 Aug 2008 05:53:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CC43A6D19 for ; Thu, 14 Aug 2008 05:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+GmEkp0n7js for ; Thu, 14 Aug 2008 05:53:43 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 1E1623A6DB7 for ; Thu, 14 Aug 2008 05:53:43 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id DEDF3B8B2F; Thu, 14 Aug 2008 14:53:03 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id D001DB8B2C; Thu, 14 Aug 2008 14:53:03 +0200 (CEST) Message-ID: <48A42AAF.2050402@restena.lu> Date: Thu, 14 Aug 2008 14:53:03 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20071114) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <48A2C236.9040300@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D62B@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D62B@SEHAN021MB.tcad.telia.se> X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] review of draft-korhonen-dime-nai-routing-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, >> The definition of NAP is quite ambiguous ("entity which owns the = >> network" - this even applies to the physical person Stefan = >> Winter, since = >> I own a network at home and I am an entity) . Later in the text I = >> = > > It could be you.. assuming you manage and have access to > AAA roaming infra from you NAS etc. > = Hm. The NAPs in this document need to perform AVP re-writing and talk = on-the-wire to Diameter servers. I usually don't do this personally, but = have computing devices to do that for me. Maybe narrowing down "entity" = to "a computing device which is authoritative for AAA message exchanges = in the network" might do? >> figured that it is the first-hop Diameter server (right?), = >> taking access = >> requests from NASes, and either handling them itself or = >> routing/forwarding them according to realms. >> = > > It could be like this. A NAP may though also own & manage > only access points and NASes . > = But still it would need to *do* something with the Diameter messages = which are originated from these access points and other NASes. That = makes the thing a Diameter agent (not necessarily a full-blown server, = admitted). > Section 4.2 recommends that NAI decoration is only applied > to new applications. This way the application definition can > explicitly state that within the application NAI decoration > must be supported. I don't think we have a better way to > determine whether NAI is decorated or not. > = A new Diameter application doesn't fully solve this problem, because it = is an adminitrative one. You can require NASREQv2 to support NAI = decorations, but you could still encounter a roaming partner who chooses = to have exclamation marks in his usernames and who *doesn't want to* = have these treated as decorated. I admit that in certain locked-down = roaming consortia, this is probably not an issue :-) > Well.. The NAS is supposed to know this by configuration. E.g. > if the NAS were to use EAP application, there is no quarantee > of the interpretation of '!'. On the other hand, if the NAS > were to use EAP-With-Steroids application, which knows about > decoration, the interpretation of '!' is quaranteed. > > I will clarify this. > = In the general case, no, see above. You can require support, but you can = not assume that "the world at large" opts in to restrict itself to only = use exclamation marks for decoration purposes. Unless a imaginary = NASREQv2 spec would *forbid the use of exclamation marks* unless used = for NAI decoration. Is that a road you want to go down? Then, yes, we = are safe, but existing deployments which use ! might be disgruntled. >> Needless to say that it is rather difficult for the server = >> for realm-Z to have an agreement with a roaming user from = >> realm-H (since the two have no direct relation to each other, = >> other than that a Diameter routing path between Z and H = >> = > > Why not? Such roaming arrangements are already valid. > = Any single one of the NAPs must know of all realms that are potentially = reachable (the entire federation) and whether or not each of those uses = ! as decoration or as part of the username. Again, I admit that in, say, = the 3GPP world, this is trivially a No-Op because ! don't show up as = normal parts of the user name. But there may be others. > In a commercial world.. when someone joins to a certain roaming > consortium they need to accept and adhere to certain rules and > guidelines. If the roaming consortium mandates support for NAI > decoration, there is no room for misinterpretations. > = Yes. That makes deployment easy in that particular roaming consortium. > A simple way to migrate from NASREQ is for example to > define a NASREQv2 application, which is identical to > RFC4005 except that it refers to this I-D on User-Name > part etc. > = Are you willing to update all Diameter App RFCs to get this one thing in? >> Also the two statements "RECOMMENDED... only applied for new = >> applications" and "MAY also in existing applications" = >> (paraphrased) is contradicting. It is either not recommended = >> to retrofit it into existing apps, or it is completely optional. >> = > > Hmm.. agree. I would appreciate better way to express the following: > > For new applications it is recommended to implement this I-D > to quarantee support for NAI decoration. IMHO, we cannot mandate it > for every new application. Also there are existing specifications > that simply mandate support for NAI decoration for existing EAP and > NASREQ applications but are applicable _only_ for a certain well > defined system within certain releases of that same system.. ;) Understood. Well, this one could be resolved rather simple: Just leave = the MAY sentence out. The text says RECOMMENDED only for new apps - = which is equivalent to saying NOT RECOMMENDED for existing apps. Looking = up "NOT RECOMMENDED" in RFC2119: " ...mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label." Which is pretty much exactly you expressed above. :-) Greetings, Stefan -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 14 06:19:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4C53A6DD3; Thu, 14 Aug 2008 06:19:58 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16EB3A6DD2 for ; Thu, 14 Aug 2008 06:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[AWL=1.426, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5Zn65RcqZaD for ; Thu, 14 Aug 2008 06:19:56 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 01EBD3A6D10 for ; Thu, 14 Aug 2008 06:19:55 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 15:19:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 15:19:46 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D64F@SEHAN021MB.tcad.telia.se> In-Reply-To: <48A42AAF.2050402@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] review of draft-korhonen-dime-nai-routing-00 Thread-Index: Acj+DLMekf24vBObRMOtn60xHjOTlwAAQ6vg References: <48A2C236.9040300@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D62B@SEHAN021MB.tcad.telia.se> <48A42AAF.2050402@restena.lu> From: To: X-OriginalArrivalTime: 14 Aug 2008 13:19:47.0539 (UTC) FILETIME=[6C9F9A30:01C8FE10] Cc: dime@ietf.org Subject: Re: [Dime] review of draft-korhonen-dime-nai-routing-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Stefan, See some comments inline. > -----Original Message----- > From: Stefan Winter [mailto:stefan.winter@restena.lu] = > Sent: 14. elokuuta 2008 15:53 > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: dime@ietf.org > Subject: Re: [Dime] review of draft-korhonen-dime-nai-routing-00 > = > = > Hi, > = > >> The definition of NAP is quite ambiguous ("entity which owns the = > >> network" - this even applies to the physical person Stefan = > >> Winter, since = > >> I own a network at home and I am an entity) . Later in the text I = > >> = > > > > It could be you.. assuming you manage and have access to > > AAA roaming infra from you NAS etc. > > = > = > Hm. The NAPs in this document need to perform AVP re-writing and talk = > on-the-wire to Diameter servers. I usually don't do this = Hmm.. can you give an example? > personally, but = > have computing devices to do that for me. Maybe narrowing = > down "entity" = > to "a computing device which is authoritative for AAA message = > exchanges = > in the network" might do? Otherwise OK but don'y like the "computing device". > >> figured that it is the first-hop Diameter server (right?), = > >> taking access = > >> requests from NASes, and either handling them itself or = > >> routing/forwarding them according to realms. > >> = > > > > It could be like this. A NAP may though also own & manage > > only access points and NASes . > > = > = > But still it would need to *do* something with the Diameter messages = > which are originated from these access points and other NASes. That = > makes the thing a Diameter agent (not necessarily a = > full-blown server, = > admitted). > = > > Section 4.2 recommends that NAI decoration is only applied > > to new applications. This way the application definition can > > explicitly state that within the application NAI decoration > > must be supported. I don't think we have a better way to > > determine whether NAI is decorated or not. > > = > = > A new Diameter application doesn't fully solve this problem, = > because it = > is an adminitrative one. You can require NASREQv2 to support NAI = > decorations, but you could still encounter a roaming partner = > who chooses = > to have exclamation marks in his usernames and who *doesn't want to* = > have these treated as decorated. I admit that in certain locked-down = > roaming consortia, this is probably not an issue :-) These things don't get deployed in wild. And if the imaginary NASREQv2 would mandate something, deviating from it would be a violation of the application specification. It would be spottet latest during the interop.. of some (roaming) consortia. > > Well.. The NAS is supposed to know this by configuration. E.g. > > if the NAS were to use EAP application, there is no quarantee > > of the interpretation of '!'. On the other hand, if the NAS > > were to use EAP-With-Steroids application, which knows about > > decoration, the interpretation of '!' is quaranteed. > > > > I will clarify this. > > = > = > In the general case, no, see above. You can require support, = > but you can = > not assume that "the world at large" opts in to restrict = > itself to only = > use exclamation marks for decoration purposes. Unless a imaginary = > NASREQv2 spec would *forbid the use of exclamation marks* unless used = > for NAI decoration. Is that a road you want to go down? Then, yes, we = > are safe, but existing deployments which use ! might be disgruntled. If the nai-routing I-D mandates a certain behavior and interpretation of NAIs, then new applications that claim compliance with nai-routing I-D must simply have an uniform interpretation of what is inside the NAI. = > >> Needless to say that it is rather difficult for the server = > >> for realm-Z to have an agreement with a roaming user from = > >> realm-H (since the two have no direct relation to each other, = > >> other than that a Diameter routing path between Z and H = > >> = > > > > Why not? Such roaming arrangements are already valid. > > = > = > Any single one of the NAPs must know of all realms that are = > potentially = > reachable (the entire federation) and whether or not each of = This is a separate issue, which is out of scope of this I-D. > those uses = > ! as decoration or as part of the username. Again, I admit = > that in, say, = > the 3GPP world, this is trivially a No-Op because ! don't show up as = > normal parts of the user name. But there may be others. > = > > In a commercial world.. when someone joins to a certain roaming > > consortium they need to accept and adhere to certain rules and > > guidelines. If the roaming consortium mandates support for NAI > > decoration, there is no room for misinterpretations. > > = > = > Yes. That makes deployment easy in that particular roaming consortium. > = > > A simple way to migrate from NASREQ is for example to > > define a NASREQv2 application, which is identical to > > RFC4005 except that it refers to this I-D on User-Name > > part etc. > > = > = > Are you willing to update all Diameter App RFCs to get this = > one thing in? Why would I need to update existing applications specifications. The imaginary NASREQv2 would be a new standalone application and require a new RFC. The implementation would just be 99% identical with RFC4005. No need to touch legacy. > >> Also the two statements "RECOMMENDED... only applied for new = > >> applications" and "MAY also in existing applications" = > >> (paraphrased) is contradicting. It is either not recommended = > >> to retrofit it into existing apps, or it is completely optional. > >> = > > > > Hmm.. agree. I would appreciate better way to express the following: > > > > For new applications it is recommended to implement this I-D > > to quarantee support for NAI decoration. IMHO, we cannot mandate it > > for every new application. Also there are existing specifications > > that simply mandate support for NAI decoration for existing EAP and > > NASREQ applications but are applicable _only_ for a certain well > > defined system within certain releases of that same system.. ;) > = > Understood. Well, this one could be resolved rather simple: = > Just leave = > the MAY sentence out. The text says RECOMMENDED only for new apps - = > which is equivalent to saying NOT RECOMMENDED for existing = > apps. Looking = > up "NOT RECOMMENDED" in RFC2119: > = > " ...mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label." > = > Which is pretty much exactly you expressed above. :-) Thanks! Cheers, Jouni > = > Greetings, > = > Stefan > = > -- = > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = > Nationale et de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > = > Tel: +352 424409 1 > Fax: +352 422473 > = > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 14 06:49:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE413A6C72; Thu, 14 Aug 2008 06:49:50 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8368C3A68A3 for ; Thu, 14 Aug 2008 06:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXATGArGkQYI for ; Thu, 14 Aug 2008 06:49:47 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 801F83A6C72 for ; Thu, 14 Aug 2008 06:49:47 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id D2B93B8B2F; Thu, 14 Aug 2008 15:48:53 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id C3C87B8B2C; Thu, 14 Aug 2008 15:48:53 +0200 (CEST) Message-ID: <48A437C5.3070409@restena.lu> Date: Thu, 14 Aug 2008 15:48:53 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20071114) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com, dime@ietf.org References: <48A2C236.9040300@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D62B@SEHAN021MB.tcad.telia.se> <48A42AAF.2050402@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D64F@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D64F@SEHAN021MB.tcad.telia.se> X-Virus-Scanned: ClamAV Subject: Re: [Dime] review of draft-korhonen-dime-nai-routing-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, > Hmm.. can you give an example? > = Like, taking EAP-Identity out of a 802.1X exchange and re-packaging it = into a Diameter request and sending it to a Diameter server. >> personally, but = >> have computing devices to do that for me. Maybe narrowing = >> down "entity" = >> to "a computing device which is authoritative for AAA message = >> exchanges = >> in the network" might do? >> = > > Otherwise OK but don'y like the "computing device". > = I would settle for just "device" :-) > These things don't get deployed in wild. And if the imaginary NASREQv2 > would mandate something, deviating from it would be a violation of the > application specification. It would be spottet latest during the > interop.. of some (roaming) consortia. > = Okay. > If the nai-routing I-D mandates a certain behavior and interpretation of > NAIs, then new applications that claim compliance with nai-routing I-D mu= st > simply have an uniform interpretation of what is inside the NAI. = > = Does the NAI I-D currently mandate that all occurence of ! MUST be = considered a NAI decoration? I haven't seen that yet... Adding that = requirement would clear a lot of things up! > This is a separate issue, which is out of scope of this I-D. > = The MUST above would also make this here more clear, because then the = ambiguity of the role of ! would be gone. > Why would I need to update existing applications specifications. > The imaginary NASREQv2 would be a new standalone application and > require a new RFC. The implementation would just be 99% identical > with RFC4005. No need to touch legacy. > = I meant update as in RFC[NASREQv2] formally updates (IETF-Style) = RFC4005. Or even obsoletes. Or do you mean the two (NASREQ, NASREQv2) = should co-exist besides each other? Something like a "fork" as you would = call it in software engineering? Greetings, Stefan -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Aug 16 00:17:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F753A6938; Sat, 16 Aug 2008 00:17:05 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AF33A677E for ; Sat, 16 Aug 2008 00:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2g6ojLL2zcb for ; Sat, 16 Aug 2008 00:17:04 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id 44C983A6938 for ; Sat, 16 Aug 2008 00:16:47 -0700 (PDT) Received: from [88.112.204.82] (a88-112-204-82.elisa-laajakaista.fi [88.112.204.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 1A7D6139932 for ; Sat, 16 Aug 2008 10:16:49 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <6289DF1F-0952-4D9E-AE45-FB5EBFB3A685@iki.fi> To: dime@ietf.org From: Jouni Korhonen Date: Sat, 16 Aug 2008 10:16:29 +0300 X-Mailer: Apple Mail (2.753.1) Subject: [Dime] test - plz ignore X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org just a test. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Aug 16 01:46:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31C028C12B; Sat, 16 Aug 2008 01:46:37 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3E93A680A for ; Sat, 16 Aug 2008 01:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOZoDjJudjq5 for ; Sat, 16 Aug 2008 01:46:34 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id 9B8FB3A6A18 for ; Sat, 16 Aug 2008 01:46:33 -0700 (PDT) Received: from [88.112.204.82] (a88-112-204-82.elisa-laajakaista.fi [88.112.204.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 308941396B7 for ; Sat, 16 Aug 2008 11:46:34 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: To: dime@ietf.org From: Jouni Korhonen Date: Sat, 16 Aug 2008 11:46:13 +0300 X-Mailer: Apple Mail (2.753.1) Subject: [Dime] review of draft-dondeti-dime-erp-diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Here's my initial review of this draft. Disclaimer: I do not claim having thorough expertise in Hokey's ERP protocol (honestly, I was too lazy to read those with a magnifying glass ;) so some of my issues may fall into the category of not understanding all fine details of ERP protocol. My comments are marked with [JiK]. Cheers, Jouni Abstract An EAP extension, called "EAP Re-authentication Protocol (ERP)", has been specified that supports an EAP method-independent protocol for efficient re-authentication between the peer and the server through an authenticator. This document specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP Initiate and EAP Finish messages specified in the ERP specification. AVPs for request and delivery of Domain Specific Root Keys from the AAA/EAP server to the ER server are also specified. Additionally, this document also specifies Diameter processing rules relevant to ERP. [JiK] I rather keep acronyms out of abstract. 1. Introduction RFC 4072 [1] specifies a Diameter application that carries EAP packets between a Diameter client and the Diameter Server/EAP server. [2] defines the EAP Re-authentication Protocol to allow faster re- authentication of a previously authenticated peer. In ERP, a peer [JiK] Expand EAP, ERP on the first use authenticates to the network by proving possession of key material derived during a previous EAP exchange. For this purpose, an Extended Master Session Key (EMSK) based re-authentication key hierarchy has been defined [5]. ERP may be executed between the ER peer and an ER server in the peer's home domain or the local domain [JiK] Expand ER on the first use visited by the peer. In the latter case, a Domain Specific Root Key (DSRK), derived from the EMSK, is provided to the local domain ER server. The peer and the local server subsequently use the re- authentication key hierarchy from the DSRK to authenticate and derive authenticator specific keys within that domain. To accomplish the reauthentication functionality, ERP defines two new EAP codes - EAP Initiate and EAP Finish. This document specifies the reuse of Diameter EAP application to carry these new EAP messages. The DSRK can be obtained as part of the regular EAP exchange or as part of an ERP bootstrapping exchange. The local ER server requesting the DSRK needs to be in the path of the EAP or ERP bootstrapping exchange in order to request and obtain the DSRK. This document also specifies how the DSRK is transported to the local ER server using Diameter. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. This document uses terminology defined in [6], [5], [2], and [1]. [JiK] Abbreviations etc section would be nice.. we seem to have a bunch of them here. 3. Assumptions This document defines additional optional AVPs for usage with the Diameter EAP application. Routing of these messages is therefore provided via the Diameter Application Identifier (among other elements), as specified by the Diameter Base protocol [4]. Based on the deployment of ERP, a local Diameter server (the same entity serves as a Diameter proxy during the full EAP authentication) may play the role of the ER server for future re-authentication attempts. As such, the local Diameter server requesting the DSRK needs to be in [JiK] s/server/agent Reading the ERP draft it is stated that the ER server and the AAA agend may be co-located. It is not mandated.. this draft on the other hand indicates clearly (i.e. "needs") co-location. I would state this design choice here in more detail. the path of the current EAP exchange between the peer and the EAP server and also along in the future. The Diameter client is furthermore assumed to be able to route the re-authentication messages to the ER server. [JiK] This routing assumption of certain Diameter nodes being on the same path that got established during the initial request route is not trivial. There has been few I-D on this explicit routing topic in Dime. Currently we do not have a standardized solution that would support the routing assumption this I-D has. I would suggest stating a bit more here about the routing assumption like domain specific means must be used to ensure more fine grained routing of subsequent messages. 4. Diameter Support for ERP 4.1. Protocol Overview Diameter may be used to transport ERP messages between the NAS (authenticator) and an authentication server (ER server). In ERP, the peer sends an EAP Initiate Reauth message to the ER [JiK] EAP-Initiate/Re-auth as such notation is used in [2]. Check all occurrences server via the authenticator. Alternatively, the NAS may send an EAP Initiate Reauth-Start message to the peer to trigger the start of [JiK] Re-Auth-Start ERP; the peer then responds with an EAP Initiate Reauth message to the NAS. The general guidelines for encapsulating EAP messages in Diameter from RFC 4072 [1] apply to the new EAP messages defined for ERP as well. The EAP Initiate Reauth message is encapsulated in an EAP- Payload AVP of a Diameter EAP-Request message by the NAS and sent to the Diameter server. The NAS MUST copy the contents of the value field of the 'rIKName as NAI' TLV or the peer-id TLV (when the former' [JiK] When looking at ERP draft, it does not use a notion "rIKName as NAI". I would strongly recommend aligning the terminology. I guess this tries to mean rIKName-NAI, which then is actually carried inside the keyName-NAI TLV, right? So would this rather be rephrased as: "The NAS MUST copy the contents of the value field of the rKeyName-NAI TLV of the EAP Initiate Reauth message into a User-Name AVP of the Diameter EAP-Request. The rKeyName-NAI TLV contain either the rIKName-NAI or peer-id (when the former is not present). " The ER server processes the EAP Initiate Reauth message in accordance with [2], and if that is successful, it responds with an EAP Finish Reauth message indicating a success ('R' flag set to 0). The [JiK] EAP-Finish/Re-auth as such notation is used in [2]. Check all occurrences Diameter server MUST encapsulate the EAP Finish Reauth message with the R flag set to zero in an EAP-Payload AVP attribute of a Diameter EAP-Answer message. An EAP-Master-Session-Key AVP included in the Diameter EAP-Answer contains the Re-authentication Master Session Key (rMSK). The Diameter Result Code, if any, SHOULD be a success Result Code. If the processing of the EAP Initiate Reauth message resulted in a failure, the Diameter server MUST encapsulate an EAP Finish Reauth message indicating failure ('R' flag set to 1) in an EAP-Payload AVP of a Diameter EAP-Answer message. The Diameter Result Code, if any, SHOULD be a failure Result Code. Whether an EAP Finish Reauth message is sent at all is specified in [2]. 4.2. DSRK Request and Delivery A local ER server, collocated with a Diameter proxy in the peer's visited domain, may request a DSRK from the EAP server, either in the initial EAP exchange (implicit bootstrapping) or in an ERP bootstrapping exchange (explicit bootstrapping). It does this by including the EAP-DSRK-Request AVP in the Diameter EAP-Response message. The EAP-DSRK-Request AVP contains the domain or server identity required to derive the DSRK. An EAP server MAY send the DSRK when it receives a valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP. An ER server MUST send the DSRK (or send a failure result) when it receives a valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP along with a valid EAP Initiate Re-auth packet with the bootstrapping flag turned on. If an EAP-DSRK-Request AVP is included in any other Diameter EAP-Request message, the Diameter server MUST reply with a [JiK] What is "other Diameter EAP-Request message"? Just above it is said that an EAP-Request message contains an EAP-DSRK-Request AVP. Please clarify what messages are meant (I know that this is defined more clearly in the Hokey ERP draft). failure result. An EAP-DSRK AVP MUST be used to send a DSRK; an EAP- DSRK-Name AVP MUST be used to send the DSRK's keyname; and an EAP- DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. 5. Command Codes This document re-uses the EAP application commands [1]: Command-Name Abbrev. Code Reference Application Diameter-EAP-Request DER 268 RFC 4072 EAP Diameter-EAP-Answer DEA 268 RFC 4072 EAP Figure 1: ERP Command Codes Re-Auth-Request (RAR) may trigger ERP. Session-Termination-Request (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR), Abort-Session-Answer (ASA), Accounting- Request (ACR), and Accounting-Answer (ACA) commands are used together with Diameter ERP, they follow the rules in the Diameter EAP application [1] and the Diameter Base specification [4]. The accounting commands use the Application Identifier value of 3 (Diameter Base Accounting); the others use 0 (Diameter Common Messages). 5.1. Diameter-EAP-Request (DER) The Diameter-EAP-Request (DER) message [1], indicated by the Command- Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by the NAS to the Diameter server to initiate a network access authentication and authorization procedure. The DEA message format is the same as defined in [1] with an addition [JiK] s/DEA/DER of optional EAP Re-authentication Protocol (ERP) AVPs. The addition of the EAP-DSRK-Request AVP to the Diameter-EAP-Request message indicates that an ERP server is present and willing to participate in [JiK] rather local ER server (more aligned with [2]). Also I would make it clear in the case of a local ER server the Diameter client that originates this DER message does not include the EAP-DSRK-Request AVP but the local ER server in path, in a Diameter proxy role, adds this AVP in the DER message... right? It is mentioned in section 4.2 but then this ABNF is expressed as from client point of view. the ERP protocol for this session. Furthermore, the EAP-DSRK- Request AVP provides identity information about the domain of the ERP server. ::= < Diameter Header: 268, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ EAP-DSRK-Request ] [ User-Name ] [ Destination-Host ] ... * [ AVP ] 5.2. Diameter-EAP-Answer (DEA) The Diameter-EAP-Answer (DEA) message defined in [1], indicated by the Command-Code field set to 268 and 'R' bit cleared in the Command Flags field, is sent in response to the Diameter-EAP-Request message (DER). The DEA message format is the same as defined in [1] with an addition of optional EAP Re-authentication Protocol (ERP) AVPs. The addition of the EAP-DSRK, EAP-DSRK-Name and the EAP-DSRK-Lifetime AVP to the Diameter-EAP-Answer message indicates that an Diameter / ER server is able to provide ERP support for this session and delivers keying material, lifetime and a key name. Dondeti Expires January 15, 2009 [Page 6] Internet-Draft Diameter Support for ERP July 2008 ::= < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ EAP-DSRK ] [ EAP-DSRK-Name ] [ EAP-DSRK-Lifetime ] [ User-Name ] ... * [ AVP ] 6. Attribute Value Pair Definitions 6.1. EAP-DSRK-Request AVP The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. This AVP fulfills two purposes: First, it indicates that a ER server is [JiK] local ER server? located in the local domain that is willing to play the role of an ER server for a particular session. Second, it conveys information about the domain and ER server identity to the Diameter/EAP server. [JiK] What happens if Diameter server does not understand this AVP but still returns OK for the full EAP authentication? Some text would be nice for the Diameter client & local ER server (i.e. Diameter proxy) behavior in this case. 6.2. EAP-DSRK AVP The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. The Domain Specific Root Key (DSRK) is carried in this payload. 6.3. EAP-DSRK-Name AVP The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This AVP contains the name of the DSRK key that is later used during the re-authentication exchange to select the correct DSRK. [JiK] if this is a plain text name, use UTF8String. Otherwise OctetString is OK. AFter reading a bit of the ERP draft it says there that the 64 bits username part of the NAI is encoded in hexadecimal. In 5.3.2 of ERP draft it is says the username takes up to 128 octets and in 5.3.3 it is though said the username takes up to 16 octets. So I am a bit confused what the username part actually keeps inside in this AVP and how it is encoded. 6.4. EAP-DSRK-Lifetime AVP The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and contains the DSRK lifetime in seconds. [JiK] Is zero (0) an allowed value? 7. AVP Occurrence Table The following table lists the AVPs that may optionally be present in the DER and DEA commands [1]. +---------------+ | Command-Code | +-+-----+-----+-+ Attribute Name | DER | DEA | -------------------------------|-----+-----+ EAP-DSRK-Request | 0-1 | 0 | EAP-DSRK | 0 | 0-1 | EAP-DSRK-Name | 0 | 0-1 | EAP-DSRK-Lifetime | 0 | 0-1 | +-----+-----+ Figure 2: DER and DEA Commands AVP Table When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name and the EAP-DSRK-Lifetime MUST also be present. [JiK] "MUST".. assuming the Diameter server understands these ERP AVPs. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 17 11:32:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B05E3A6848; Sun, 17 Aug 2008 11:32:46 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76DC83A6CF1 for ; Sun, 17 Aug 2008 11:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yhf7hAE3vMm8 for ; Sun, 17 Aug 2008 11:32:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 42F7F3A6848 for ; Sun, 17 Aug 2008 11:32:43 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2008 18:32:49 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp056) with SMTP; 17 Aug 2008 20:32:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+IdxcCpP2IUwqcB6hV7nXIc7EdFzRsXd0EwpkGNp m/JXP0m9P97Lb7 Message-ID: <48A86ED2.7070009@gmx.net> Date: Sun, 17 Aug 2008 21:32:50 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Subject: [Dime] MIP6 RADIUS and Diameter MIPv6 Split Draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, Avi gave a presentation about the MIP6 RADIUS draft http://www3.ietf.org/proceedings/08jul/slides/mext-9.ppt and the MIP6 RADIUS draft http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-05.txt is the RADIUS counterpart of our Diameter Mobility documents: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-10.txt and http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-09.txt Now, here is the important part. As part of the work on the draft, the feedback Avi got during the presentation and offlist comments from Pasi and Jari there are some concerns about the security properties provided by the following two mechanisms: * IKEv2 with PSKs * IKEv2 with CERTs To briefly summarize the problems (also described in the slide set) there are the following issues: * Having the AAA deliver a PSK key to the HA without the AAA performing authentication introduces security vulnerabilities. The discussed possible solutions where the AAA could authenticate the PSK are somewhat "clunky" since IKEv2 was never meant to be used in such a way. * Similar problems arise with IKEv2 and Certificates where the AAA server is used to just authorize without getting involved in the authentication procedure itself. In an offline discussion between Jari, Pasi, Avi, and Jouni the idea came up to drop these two mechanisms from the MIP6 RADIUS document and consequently also from the Diameter MIPv6 Split draft. Is this a bad thing? I don't think so. Currently, we don't know anyone who would be using them. Hence, there are somewhat "theoretical" at the moment. We could specify them once deployments would be asking for them. Who has objections against dropping the above-described mechanisms from the Diameter MIPv6 Split draft? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 18 06:44:38 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE51B3A6CB5; Mon, 18 Aug 2008 06:44:38 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D6B3A6C9D for ; Mon, 18 Aug 2008 06:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThPLi0DZO-rf for ; Mon, 18 Aug 2008 06:44:32 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 116DA3A6CE6 for ; Mon, 18 Aug 2008 06:44:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 8D62C90012 for ; Mon, 18 Aug 2008 09:44:33 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28221-17 for ; Mon, 18 Aug 2008 09:44:29 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 18 Aug 2008 09:44:29 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 09:44:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 19:14:25 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C066F2D8E@exchindia3.starentnetworks.com> In-Reply-To: <48A86ED2.7070009@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query on Auth APPID Negotiation Thread-Index: AckAl7QhDD+v0lOMQ2er911I5DKFHQAoDyMA From: "Shastry, Shankarananda" To: X-OriginalArrivalTime: 18 Aug 2008 13:44:29.0623 (UTC) FILETIME=[89AAAC70:01C90138] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: "Ganesan, Eshwar" , "Sahoo, Yogamaya" Subject: [Dime] Query on Auth APPID Negotiation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org All, I have a query in the AUTH APPID that can be sent by the Client based on the CER/CEA negotiation. Scenario: Client Supports AUTH-APPID: 4,5,16777248 Server Supports AUTH-APPID: 5 Query: Should the client send messages other than Auth-APPID 5 to server? I don't see any mention of this in RFC 3588. Any help in this is appreciated. Regards Shankar _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 18 06:57:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D41C28C120; Mon, 18 Aug 2008 06:57:18 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFD63A6A72 for ; Mon, 18 Aug 2008 06:57:16 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGaW1n4vV2uV for ; Mon, 18 Aug 2008 06:57:15 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id BB7D73A68E5 for ; Mon, 18 Aug 2008 06:57:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id E509890019 for ; Mon, 18 Aug 2008 09:56:26 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29506-19 for ; Mon, 18 Aug 2008 09:56:24 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 18 Aug 2008 09:56:24 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 09:56:24 -0400 Received: from [10.6.7.67] ([10.6.7.67]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 19:26:20 +0530 From: Sarkar Biplab To: "Shastry, Shankarananda" In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C066F2D8E@exchindia3.starentnetworks.com> References: <69FADB84C90B1248A7DE59422771FA0C066F2D8E@exchindia3.starentnetworks.com> Date: Mon, 18 Aug 2008 19:26:20 +0530 Message-Id: <1219067780.1479.6.camel@INDBNG1172.bng.ind.starentnetworks.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 18 Aug 2008 13:56:20.0760 (UTC) FILETIME=[31899180:01C9013A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: "Sahoo, Yogamaya" , "Ganesan, Eshwar" , dime@ietf.org Subject: Re: [Dime] Query on Auth APPID Negotiation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2000726028==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============2000726028== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tb0YKYAYB8Np9fVeMY/s" --=-tb0YKYAYB8Np9fVeMY/s Content-Type: multipart/alternative; boundary="=-yIHBvHv5hWYxJ+QKm7hs" --=-yIHBvHv5hWYxJ+QKm7hs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Shankar, I think the number of AUTH-ID entries in the CEA should be "less-than-or-equal-to" the number of AUTH-ID entries in CER.=20 The following statement seems to capture this idea. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC 3588[5.3] =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The receiver only issues commands to its peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D So depending up on who has sent the CER the parameters will vary but the resultant values (minimal-set) should be same. Thanks & Regards, Biplab On Mon, 2008-08-18 at 19:14 +0530, Shastry, Shankarananda wrote: > All, >=20 > I have a query in the AUTH APPID that can be sent by the Client based on > the CER/CEA negotiation. >=20 > Scenario:=20 >=20 > Client Supports AUTH-APPID: 4,5,16777248 > Server Supports AUTH-APPID: 5 >=20 > Query:=20 >=20 > Should the client send messages other than Auth-APPID 5 to server? I > don't see any mention of this in RFC 3588. Any help in this is > appreciated. >=20 >=20 > Regards > Shankar >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=-yIHBvHv5hWYxJ+QKm7hs Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Shankar,

I think the number of AUTH-ID entries in the CEA should be "less-than-= or-equal-to" the number of AUTH-ID entries in CER.
The following statement  seems to capture this idea.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC 3588[5.3] =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
   The receiver only issues commands to its peers that have adver= tised
   support for the Diameter application that defines the command.=   A
   Diameter node MUST cache the supported applications in order t= o
   ensure that unrecognized commands and/or AVPs are not unnecess= arily
   sent to a peer.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

So depending up on who has sent the CER the parameters will vary but the re= sultant values (minimal-set) should be same.

Thanks & Regards,
Biplab

On Mon, 2008-08-18 at 19:14 +0530, Shastry, Shankarananda wrote: 
All,

I have a query in the AUTH APPID that can be sent by the Client based on
the CER/CEA negotiation.

Scenario:=20

Client Supports AUTH-APPID: 4,5,16777248
Server Supports AUTH-APPID: 5

Query:=20

Should the client send messages other than Auth-APPID 5 to server? I
don't see any mention of this in RFC 3588. Any help in this is
appreciated.


Regards
Shankar

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org=
/mailman/listinfo/dime
--=-yIHBvHv5hWYxJ+QKm7hs-- --=-tb0YKYAYB8Np9fVeMY/s Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIqX+E3rQBTW1UPu4RAh2MAJ9EDeMRrSSWGMvU4gbKdm9N0O9TEACfadU2 nHtyLMpzv1dOT82nzp/FQYY= =kbzs -----END PGP SIGNATURE----- --=-tb0YKYAYB8Np9fVeMY/s-- --===============2000726028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2000726028==-- From dime-bounces@ietf.org Mon Aug 18 07:10:42 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C6D3A6CF4; Mon, 18 Aug 2008 07:10:42 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6923A6CE6 for ; Mon, 18 Aug 2008 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2NC5iNX-xuH for ; Mon, 18 Aug 2008 07:10:40 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 37CDF3A6CF4 for ; Mon, 18 Aug 2008 07:10:40 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 3408AB8B2F; Mon, 18 Aug 2008 15:57:55 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 24060B8B2D; Mon, 18 Aug 2008 15:57:55 +0200 (CEST) Message-ID: <48A97FE2.6010204@restena.lu> Date: Mon, 18 Aug 2008 15:57:54 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20071114) MIME-Version: 1.0 To: jouni.korhonen@iki.fi References: <48A2C236.9040300@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D62B@SEHAN021MB.tcad.telia.se> <48A42AAF.2050402@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D64F@SEHAN021MB.tcad.telia.se> <48A437C5.3070409@restena.lu> <48A48460.4020908@kolumbus.fi> In-Reply-To: <48A48460.4020908@kolumbus.fi> X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] review of draft-korhonen-dime-nai-routing-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, >> Like, taking EAP-Identity out of a 802.1X exchange and re-packaging = >> it into a Diameter request and sending it to a Diameter server. > > Ah ok. I though this is business as usual. Is there any specific issue > with it? No, other than that it performs operations that in the AAA world are = usually performed by a NAS. Hence my suggestion below: > Hmm.. I'll try to come up with a better description of NAP. I am not > happy with the "device" either ;) My suggestion is to forget about the word NAP and replace it by NAS. = Rationale: the draft's core point is to describe how to re-write = decorations until the home realm is reached. The entity NAP which is = introduced in the draft is not essential to this process. In fact, it = just ships Diameter messages to the realm server and that *server* is = the one needing to do re-writing. Looking at the Problem Description again, the word NAS is used nowhere, = but is constantly replaced with NAPs. Now given that NAS is a more = common term in RADIUS and Diameter, while NAP isn't, and that the entity = described as NAP does essentially the same things as usually a NAS does, = why not just say NAS. In fact, there are multiple occurences where you = write NAP/NAS, giving a hint that the two are indeed interchangeable. Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 18 07:38:04 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0583A6BB4; Mon, 18 Aug 2008 07:38:04 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68923A6BB4 for ; Mon, 18 Aug 2008 07:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.325 X-Spam-Level: *** X-Spam-Status: No, score=3.325 tagged_above=-999 required=5 tests=[AWL=-4.124, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nC-caY8SX+L for ; Mon, 18 Aug 2008 07:38:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2B9C33A688C for ; Mon, 18 Aug 2008 07:38:02 -0700 (PDT) Received: (qmail invoked by alias); 18 Aug 2008 14:38:07 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp063) with SMTP; 18 Aug 2008 16:38:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19L8/8hukBLE1pZK8WHAKttj0/rQfhNFKg3psoW/+ n5a250I7VJTQ0A Message-ID: <48A98951.7000308@gmx.net> Date: Mon, 18 Aug 2008 17:38:09 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: dime@ietf.org Content-Type: multipart/mixed; boundary="------------060705060909040207010704" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 Subject: [Dime] =?gb2312?b?W0Z3ZDogW0Z3ZDogtPC4tDogIHJlc3VibWlzc2lvbiBk?= =?gb2312?b?cmFmdCBmb3IgY2FwYWJpbGl0aWVzLXVwZGF0ZS1wcm9wb2JsZW0gc3RhdG1l?= =?gb2312?b?bnRdXQ==?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --------------060705060909040207010704 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit This mail never made it to the list... -------- Original Message -------- Subject: [Fwd: ´ð¸´: [Dime] resubmission draft for capabilities-update-propoblem statment] Date: Mon, 18 Aug 2008 10:35:03 -0400 From: Victor Fajardo To: Hannes Tschofenig --------------060705060909040207010704 Content-Type: message/rfc822; name="=?GB2312?B?tPC4tDogW0RpbWVdIHJlc3VibWlzc2lvbiBkcmFmdCBmb3IgY2FwYWJpbGl0aWU=?==?GB2312?B?cy11cGRhdGUtcHJvcG9ibGVtIHN0YXRtZW50?=" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename*0*=GB2312''%B4%F0%B8%B4%3A%20%5B%44%69%6D%65%5D%20%72%65%73%75%62; filename*1*=%6D%69%73%73%69%6F%6E%20%64%72%61%66%74%20%66%6F%72%20%63%61; filename*2*=%70%61%62%69%6C%69%74%69%65%73%2D%75%70%64%61%74%65%2D%70%72; filename*3*=%6F%70%6F%62%6C%65%6D%20%73%74%61%74%6D%65%6E%74 X-Account-Key: account5 Return-Path: Received: from mail75.messagelabs.com (mail75.messagelabs.com [216.82.250.3]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with SMTP id m6V8tZKN064423 for ; Thu, 31 Jul 2008 04:55:36 -0400 (EDT) (envelope-from shan.mingjun@huawei.com) X-VirusChecked: Checked X-Env-Sender: shan.mingjun@huawei.com X-Msg-Ref: server-5.tower-75.messagelabs.com!1217494529!85434167!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [119.145.14.64] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_MATCH_4 Received: (qmail 3446 invoked from network); 31 Jul 2008 08:55:34 -0000 Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com) (119.145.14.64) by server-5.tower-75.messagelabs.com with SMTP; 31 Jul 2008 08:55:34 -0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4V00NMZ4Q94R@szxga01-in.huawei.com> for vfajardo@tari.toshiba.com; Thu, 31 Jul 2008 16:54:09 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4V001V34Q9W1@szxga01-in.huawei.com> for vfajardo@tari.toshiba.com; Thu, 31 Jul 2008 16:54:09 +0800 (CST) Received: from jys3105109974f ([130.129.20.132]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4V00KVJ4PT0A@szxml01-in.huawei.com>; Thu, 31 Jul 2008 16:54:09 +0800 (CST) Date: Thu, 31 Jul 2008 16:53:25 +0800 From: shan Subject: =?gb2312?B?tPC4tDogW0RpbWVdIHJlc3VibWlzc2lvbiBkcmFmdCBmb3IgY2FwYQ==?= =?gb2312?B?YmlsaXRpZXMtdXBkYXRlLXByb3BvYmxlbSBzdGF0bWVudA==?= In-reply-to: <48903518.9050501@tari.toshiba.com> To: "'Victor Fajardo'" Cc: dime@ietf.org Message-id: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Thread-index: AcjyJyBS+lM7BkowR22EPd3n4W97WQAwrXDQ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by toshi17.tari.toshiba.com id m6V8tZKN064423 Hi Victor Thanks for your comments! Just as a fundamental idea, it's not recommended for a node to perform the same processing twice upon the peer's capabilities change, esp. for the primary protocol. That's a reason to have a clearer view on this, to avoid magnifying the 'bug' unlimited. Taking into your comments, and what we had in the F2F meeting, let's come up a new revision, esp. with the backward compatibility late. Thanks! Best regards, Mingjun -----ÓʼþÔ­¼þ----- ·¢¼þÈË: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] ·¢ËÍʱ¼ä: 2008Äê7ÔÂ30ÈÕ 17:32 ÊÕ¼þÈË: shan ³­ËÍ: dime@ietf.org Ö÷Ìâ: Re: [Dime] resubmission draft for capabilities-update-propoblem statment Hi Shan, Thanks for describing the problem with the CER/CEA exchange in the open state. I think we maybe able to solve the issue described in this draft without introducing a new non-backward compatible CEA ABNF. From my understanding (which maybe incorrect), the key to the optimization described in your draft is to ignore the peer capabilities contained in the CEA in the OPEN state (both scenario 1 and 2 in your draft). If this is true, then the current bis document already supports this because it states in Sec 5.3: "The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include all of its supported applications as a hint to the receiver regarding all of its application capabilities." In this case, we are not mandating that the CEA receiver processes the received peer capabilities. In some sense, I do think that text in 5.3 is hard to read and this maybe why we end up with these types of discussions. So, for me, we may need to cleanup the text in 5.3 to simply the description of what is actually happening. With regards to this particular issue, we can even relax the CEA processing even more by changing it to MAY instead of SHOULD. regards, victor > Hi all > > > > The following is the re-submission of the draft for capabilities update > problem! Since there is some problem with the previous submission. > > The content is same! > > > > http://www.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update- > problem-statement-00.txt > > > > The link in the agenda for the meeting this afternoon hence could be kindly > replaced by this one. > > Your comments welcome! > > > > Regards, > > Mingjun > > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------060705060909040207010704 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --------------060705060909040207010704-- From dime-bounces@ietf.org Mon Aug 18 07:41:22 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C99C28C189; Mon, 18 Aug 2008 07:41:22 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A955928C17B for ; Mon, 18 Aug 2008 07:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2azXeH-b7sR for ; Mon, 18 Aug 2008 07:41:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B7C8728C180 for ; Mon, 18 Aug 2008 07:41:19 -0700 (PDT) Received: (qmail invoked by alias); 18 Aug 2008 14:41:25 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp046) with SMTP; 18 Aug 2008 16:41:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+LAAcYuDSLdA56Lx7+fUqeSwxsaAPEMTkv2hUWqZ t2vwTC6Nc5ZLkK Message-ID: <48A98A18.2070206@gmx.net> Date: Mon, 18 Aug 2008 17:41:28 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.88 Subject: [Dime] Mailing list problems? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Some mails did not appear on the list. I wonder whether other folks experienced similar problems. Please drop me a mail. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 18 09:37:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD2C3A6B44; Mon, 18 Aug 2008 09:37:17 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC9E3A6B44 for ; Mon, 18 Aug 2008 09:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnZtpa1dDSE2 for ; Mon, 18 Aug 2008 09:37:16 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 492933A685F for ; Mon, 18 Aug 2008 09:37:16 -0700 (PDT) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7IEkpXA031923 for ; Mon, 18 Aug 2008 10:46:51 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48A98B58.9050008@tari.toshiba.com> Date: Mon, 18 Aug 2008 10:46:48 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: dime@ietf.org Subject: [Dime] Test email .. pls ignore X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 18 09:37:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939B228C152; Mon, 18 Aug 2008 09:37:18 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72AA728C152 for ; Mon, 18 Aug 2008 09:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdERuvXCibif for ; Mon, 18 Aug 2008 09:37:17 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id D47463A67E6 for ; Mon, 18 Aug 2008 09:37:16 -0700 (PDT) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7IF1CBY031981 for ; Mon, 18 Aug 2008 11:01:12 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48A98EB5.1010801@tari.toshiba.com> Date: Mon, 18 Aug 2008 11:01:09 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: dime@ietf.org Subject: [Dime] Test email .. pls ignore X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 18 09:37:19 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C174A28C1A9; Mon, 18 Aug 2008 09:37:19 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482703A67E6 for ; Mon, 18 Aug 2008 09:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.048 X-Spam-Level: * X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[AWL=-3.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnlAL8kBKwnn for ; Mon, 18 Aug 2008 09:37:17 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 6889D3A6CDC for ; Mon, 18 Aug 2008 09:37:17 -0700 (PDT) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7IEH1Ci031819; Mon, 18 Aug 2008 10:17:01 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48A98459.1050807@tari.toshiba.com> Date: Mon, 18 Aug 2008 10:16:57 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: shan References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> In-Reply-To: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> Cc: dime@ietf.org Subject: Re: [Dime] =?gb2312?b?tPC4tDogIHJlc3VibWlzc2lvbiBkcmFmdCBmb3IgY2Fw?= =?gb2312?b?YWJpbGl0aWVzLXVwZGF0ZS1wcm9wb2JsZW0gc3RhdG1lbnQ=?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Shan, > Thanks for your comments! > Just as a fundamental idea, it's not recommended for a node to perform the > same processing twice upon the peer's capabilities change, esp. for the > primary protocol. That's a reason to have a clearer view on this, to avoid > magnifying the 'bug' unlimited. > Ok. > Taking into your comments, and what we had in the F2F meeting, let's come up > a new revision, esp. with the backward compatibility late. Thanks! > Did you have the chance to reviewed my suggestion below ? > Thanks for describing the problem with the CER/CEA exchange in the open > state. I think we maybe able to solve the issue described in this draft > without introducing a new non-backward compatible CEA ABNF. From my > understanding (which maybe incorrect), the key to the optimization > described in your draft is to ignore the peer capabilities contained in > the CEA in the OPEN state (both scenario 1 and 2 in your draft). If this > is true, then the current bis document already supports this because it > states in Sec 5.3: > > "The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include > all of its supported applications as a hint to the receiver regarding > all of its application capabilities." > > In this case, we are not mandating that the CEA receiver processes the > received peer capabilities. In some sense, I do think that text in 5.3 > is hard to read and this maybe why we end up with these types of > discussions. So, for me, we may need to cleanup the text in 5.3 to > simply the description of what is actually happening. With regards to > this particular issue, we can even relax the CEA processing even more by > changing it to MAY instead of SHOULD. > -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 18 22:17:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15AD3A6885; Mon, 18 Aug 2008 22:17:10 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49933A677C for ; Mon, 18 Aug 2008 22:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY79xy8M2kXj for ; Mon, 18 Aug 2008 22:17:07 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id CA6943A68C6 for ; Mon, 18 Aug 2008 22:16:41 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m7J5EBrv001344 for ; Tue, 19 Aug 2008 10:44:11 +0530 Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m7J5E7Yh001268 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 19 Aug 2008 10:44:09 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Tue, 19 Aug 2008 10:46:28 +0530 From: Ankit Kumar Sharma To: "bsarkar@starentnetworks.com" , "Shastry, Shankarananda" Date: Tue, 19 Aug 2008 10:46:26 +0530 Thread-Topic: [Dime] Query on Auth APPID Negotiation Thread-Index: AckBfWGNeqLZ+ioOSNaDMyrSVCh0VAAPEhaQ Message-ID: References: <69FADB84C90B1248A7DE59422771FA0C066F2D8E@exchindia3.starentnetworks.com> <1219067780.1479.6.camel@INDBNG1172.bng.ind.starentnetworks.com> In-Reply-To: <1219067780.1479.6.camel@INDBNG1172.bng.ind.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" , "Ganesan, Eshwar" , "Sahoo, Yogamaya" , "ankisharma@gmail.com" Subject: Re: [Dime] Query on Auth APPID Negotiation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1092843303==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1092843303== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_ED9A1B511A7D7F4A94367476325160580BD6378021GUREXMB01ASIA_" --_000_ED9A1B511A7D7F4A94367476325160580BD6378021GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shankar, In addition to what Mr. Biplab has quoted, please look at the last paragrap= h of section 5.3 of RFC 3588: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With the exception of the Capabilities-Exchange-Request message, a message of type Request that includes the Auth-Application-Id or Acct-Application-Id AVPs, or a message with an application-specific command code, MAY only be forwarded to a host that has explicitly advertised support for the application (or has advertised the Relay Application Identifier). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Cheers, Ankit Kumar Sharma ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Sar= kar Biplab Sent: Monday, August 18, 2008 7:26 PM To: Shastry, Shankarananda Cc: Sahoo, Yogamaya; Ganesan, Eshwar; dime@ietf.org Subject: Re: [Dime] Query on Auth APPID Negotiation Hi Shankar, I think the number of AUTH-ID entries in the CEA should be "less-than-or-eq= ual-to" the number of AUTH-ID entries in CER. The following statement seems to capture this idea. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC 3588[5.3] =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The receiver only issues commands to its peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D So depending up on who has sent the CER the parameters will vary but the re= sultant values (minimal-set) should be same. Thanks & Regards, Biplab On Mon, 2008-08-18 at 19:14 +0530, Shastry, Shankarananda wrote: All, I have a query in the AUTH APPID that can be sent by the Client based on the CER/CEA negotiation. Scenario: Client Supports AUTH-APPID: 4,5,16777248 Server Supports AUTH-APPID: 5 Query: Should the client send messages other than Auth-APPID 5 to server? I don't see any mention of this in RFC 3588. Any help in this is appreciated. Regards Shankar _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility forloss or damage arising from the use of th= e information transmitted by this email including damage from virus." --_000_ED9A1B511A7D7F4A94367476325160580BD6378021GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shankar,

 

In addition to what Mr. Biplab has quoted, please look at the last = paragraph of section 5.3 of RFC 3588:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   With the exception of the Capabilities-Exchange-Reques= t message, a

   message of type Request that includes the Auth-Applica= tion-Id or

   Acct-Application-Id AVPs, or a message with an applica= tion-specific

   command code, MAY only be forwarded to a host that has= explicitly

   advertised support for the application (or has adverti= sed the Relay

   Application Identifier).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Cheers,

Ankit Kumar Sharma=

 

From: dime= -bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Sarkar Biplab
Sent: Monday, August 18, 200= 8 7:26 PM
To: Shastry, Shankarananda Cc: Sahoo, Yogamaya; Ganesan= , Eshwar; dime@ietf.org
Subject: Re: [Dime] Query on= Auth APPID Negotiation

 

Hi Shankar,

I think the number of AUTH-ID entries in the CEA should be "less-than-= or-equal-to" the number of AUTH-ID entries in CER.
The following statement  seems to capture this idea.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC 3588[5.3] =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   The receiver only issues commands to it= s peers that have advertised
   support for the Diameter application that defines the command.=   A
   Diameter node MUST cache the supported applications in order t= o
   ensure that unrecognized commands and/or AVPs are not unnecess= arily
   sent to a peer.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

So depending up on who has sent the CER the parameters will vary but the re= sultant values (minimal-set) should be same.

Thanks & Regards,
Biplab

On Mon, 2008-08-18 at 19:14 +0530, Shastry, Shankarananda wrote: <= /o:p>

 
All,
 
I have a query in the AUTH APPID that can be sent by the Client based on
the CER/CEA negotiation.
 
Scenario: 
 
Client Supports AUTH-APPID: 4,5,16777248
Server Supports AUTH-APPID: 5
 
Query: 
 
Should the client send messages other than Auth-APPID 5 to server? I<=
/o:p>
don't see any mention of this in RFC 3588. Any help in this is<=
/span>
appreciated.
 
 
Regards
Shankar
 
_______________________________________________

DiME mailing list


DiME@ietf.org


https://www.ietf.or=
g/mailman/listinfo/dime

"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity forloss or damage arising from the use of the information transmitted b= y this email including damage from virus."
 --_000_ED9A1B511A7D7F4A94367476325160580BD6378021GUREXMB01ASIA_-- --===============1092843303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1092843303==-- From dime-bounces@ietf.org Tue Aug 19 00:30:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E261D3A689E; Tue, 19 Aug 2008 00:30:14 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1393A689E for ; Tue, 19 Aug 2008 00:30:13 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mUUu+9SXac2 for ; Tue, 19 Aug 2008 00:30:07 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id AB9D83A67E1 for ; Tue, 19 Aug 2008 00:30:07 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1956233rvf.49 for ; Tue, 19 Aug 2008 00:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=0FBdIQqeUdCEefaAR8tROZIT1wpCAAj+pT/PmUvpwSo=; b=JJ72xPtzR5fVmHjUBPZZwcB4+1CkG2SfMtfNHfhxthDC1+50IDyx1TfQ8mh/msRSVM /y3FODtMP4v5ttcnlwL+x2y+fXuIkT74ZKmP08O6YSftNvGhZK4sy8nEtKpC4ENASRw4 ROE4+qmv4+EsbyKBvIZhWnOhfXgLm45Ge3bCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=cizTDUCWXwQcwE4nkqR2xOX+1xYn9Ve6DO65zjIJe8JnHOciWyAWVv1ByX2EIyFBYT W1wJMxnshKdVLX1lF9neYFAPdWaFO+2YZ/gqaT3SHDnFuzJhM2MugnUbTc3FPUmCFNHN nAFUORxSAkbbzr1iVEX+KU7BQEvAUl+4DClC8= Received: by 10.140.126.14 with SMTP id y14mr3883295rvc.96.1219130993671; Tue, 19 Aug 2008 00:29:53 -0700 (PDT) Received: by 10.141.68.16 with HTTP; Tue, 19 Aug 2008 00:29:53 -0700 (PDT) Message-ID: <65a1b9120808190029o591c46c7y23479fa2dc53784f@mail.gmail.com> Date: Tue, 19 Aug 2008 12:59:53 +0530 From: "DHIRANANDA SENAPATI" To: "Shastry, Shankarananda" In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C066F2D8E@exchindia3.starentnetworks.com> MIME-Version: 1.0 References: <48A86ED2.7070009@gmx.net> <69FADB84C90B1248A7DE59422771FA0C066F2D8E@exchindia3.starentnetworks.com> Cc: "Sahoo, Yogamaya" , "Ganesan, Eshwar" , dime@ietf.org Subject: Re: [Dime] Query on Auth APPID Negotiation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0300775812==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0300775812== Content-Type: multipart/alternative; boundary="----=_Part_2968_25664926.1219130993631" ------=_Part_2968_25664926.1219130993631 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Shankar, Please look at the 2nd paragraph of section 5.3. Capabilities Exchange of RFC 3588: ************************* The receiver only issues commands to its peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer. ************************* Regards, Dhirananda On Mon, Aug 18, 2008 at 7:14 PM, Shastry, Shankarananda < shshastry@starentnetworks.com> wrote: > All, > > I have a query in the AUTH APPID that can be sent by the Client based on > the CER/CEA negotiation. > > Scenario: > > Client Supports AUTH-APPID: 4,5,16777248 > Server Supports AUTH-APPID: 5 > > Query: > > Should the client send messages other than Auth-APPID 5 to server? I > don't see any mention of this in RFC 3588. Any help in this is > appreciated. > > > Regards > Shankar > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ------=_Part_2968_25664926.1219130993631 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


Hi Shankar,

Please look at the 2nd paragraph of section 5.3. Capabilities Exchange of RFC 3588:

*************************

The receiver only issues commands to its peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer.

*************************

Regards,
Dhirananda





On Mon, Aug 18, 2008 at 7:14 PM, Shastry, Shankarananda <shshastry@starentnetworks.com> wrote:
All,

I have a query in the AUTH APPID that can be sent by the Client based on
the CER/CEA negotiation.

Scenario:

Client Supports AUTH-APPID: 4,5,16777248
Server Supports AUTH-APPID: 5

Query:

Should the client send messages other than Auth-APPID 5 to server? I
don't see any mention of this in RFC 3588. Any help in this is
appreciated.


Regards
Shankar

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

------=_Part_2968_25664926.1219130993631-- --===============0300775812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0300775812==-- From dime-bounces@ietf.org Tue Aug 19 01:09:38 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A5D3A6AD9; Tue, 19 Aug 2008 01:09:37 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA9F28C10D for ; Mon, 18 Aug 2008 23:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3gkp9UteqEy for ; Mon, 18 Aug 2008 23:35:25 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by core3.amsl.com (Postfix) with ESMTP id 6A54F28C0F3 for ; Mon, 18 Aug 2008 23:35:24 -0700 (PDT) Received: from [10.10.10.156] (unknown [195.228.239.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 791E01516B0; Tue, 19 Aug 2008 09:34:55 +0300 (EEST) Message-ID: <48AA6988.4040704@kolumbus.fi> Date: Tue, 19 Aug 2008 09:34:48 +0300 From: Jouni User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Winter References: <48A2C236.9040300@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D62B@SEHAN021MB.tcad.telia.se> <48A42AAF.2050402@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D64F@SEHAN021MB.tcad.telia.se> <48A437C5.3070409@restena.lu> <48A48460.4020908@kolumbus.fi> <48A97FE2.6010204@restena.lu> In-Reply-To: <48A97FE2.6010204@restena.lu> Cc: dime@ietf.org Subject: Re: [Dime] review of draft-korhonen-dime-nai-routing-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jouni.korhonen@iki.fi List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Stefan, Stefan Winter kirjoitti: > Hi, > >>> Like, taking EAP-Identity out of a 802.1X exchange and re-packaging >>> it into a Diameter request and sending it to a Diameter server. >> >> Ah ok. I though this is business as usual. Is there any specific issue >> with it? > > No, other than that it performs operations that in the AAA world are > usually performed by a NAS. Hence my suggestion below: > >> Hmm.. I'll try to come up with a better description of NAP. I am not >> happy with the "device" either ;) > > My suggestion is to forget about the word NAP and replace it by NAS. > Rationale: the draft's core point is to describe how to re-write > decorations until the home realm is reached. The entity NAP which is > introduced in the draft is not essential to this process. In fact, it > just ships Diameter messages to the realm server and that *server* is > the one needing to do re-writing. Right, I'll look into this. > Looking at the Problem Description again, the word NAS is used > nowhere, but is constantly replaced with NAPs. Now given that NAS is a > more common term in RADIUS and Diameter, while NAP isn't, and that the > entity described as NAP does essentially the same things as usually a > NAS does, why not just say NAS. In fact, there are multiple occurences > where you write NAP/NAS, giving a hint that the two are indeed > interchangeable. Right, you got a point there. However, in my domain of "roaming world" NAP is commonly used to describe the functional / commercial entity that operates a NAS (or a plethora of NASes) and maybe has a complex internal proxy network, hence the preference of NAP over NAS. How about: "Network Access Provider (NAP): A business entity that provides network access infrastructure to one or realms. A NAP infrastructure constitutes one or more NASes. Network Access Server (NAS): The device that peers connect to in order to obtain access to the network and is authoritative for AAA message exchanges in the NAP infrastructure. " Keep this in the terminology and then use the NAP/NAS throughout the document...? Cheers, Jouni > > Greetings, > > Stefan Winter > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 19 09:23:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF673A6BB3; Tue, 19 Aug 2008 09:23:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658093A6BB3 for ; Tue, 19 Aug 2008 09:23:44 -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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czy6B6kskbBm for ; Tue, 19 Aug 2008 09:23:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 453013A692F for ; Tue, 19 Aug 2008 09:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1219163031; x=1250699031; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hannes=20Tschofenig=20, =0D=0A=20=20=20=20=20=20=20=20"dime@ietf.org"=0D=0A=09|Date:=20Tue,=2019=20Aug=202008=2009:22:46=20 -0700|Subject:=20RE:=20[Dime]=20MIP6=20RADIUS=20and=20Dia meter=20MIPv6=20Split=20Draft|Thread-Topic:=20[Dime]=20MI P6=20RADIUS=20and=20Diameter=20MIPv6=20Split=20Draft |Thread-Index:=20AckAl63ifCP3di8MRnya1wXXySZWmQBf+trw |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3034AB55D@ NASANEXMB08.na.qualcomm.com>|References:=20<48A86ED2.7070 009@gmx.net>|In-Reply-To:=20<48A86ED2.7070009@gmx.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 200,2160,5364"=3B=20a=3D"5661851"; bh=f6YYc0IJv+iUQWw7rRYZTFZo8yRiO49WsGymOTBx0RU=; b=MGjIpUd1Jq5AxGhAf1zOl8dz+XrtIJcb5c9/8MD9F+iKZGxyIRy1ZJ3t rPBQwW5Uq0QAjJ70mXsUZPabREyI31ogFBpcSbcxaAQ4se3XjWpAWrTG8 g3VSQPa+Lqcz/dW/xafoqtFR27Mx/wqpGbLXhmWH5KryO/HOuVooCe38D Q=; X-IronPort-AV: E=McAfee;i="5200,2160,5364"; a="5661851" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2008 09:22:50 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m7JGMnuE018268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Aug 2008 09:22:50 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m7JGMnqn015502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Aug 2008 09:22:49 -0700 Received: from nasanexhub01.na.qualcomm.com (10.46.93.121) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 19 Aug 2008 09:22:49 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Tue, 19 Aug 2008 09:22:48 -0700 From: "Giaretta, Gerardo" To: Hannes Tschofenig , "dime@ietf.org" Date: Tue, 19 Aug 2008 09:22:46 -0700 Thread-Topic: [Dime] MIP6 RADIUS and Diameter MIPv6 Split Draft Thread-Index: AckAl63ifCP3di8MRnya1wXXySZWmQBf+trw Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3034AB55D@NASANEXMB08.na.qualcomm.com> References: <48A86ED2.7070009@gmx.net> In-Reply-To: <48A86ED2.7070009@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] MIP6 RADIUS and Diameter MIPv6 Split Draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, Thanks for the summary (useful as I missed the IETF meeting in Dublin). I am fine with your proposal of dropping PSKs and CERTs support from the drafts. Ciao Gerardo > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Sunday, August 17, 2008 11:33 AM > To: dime@ietf.org > Subject: [Dime] MIP6 RADIUS and Diameter MIPv6 Split Draft > > Hi all, > > Avi gave a presentation about the MIP6 RADIUS draft > http://www3.ietf.org/proceedings/08jul/slides/mext-9.ppt > and the MIP6 RADIUS draft > http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-05.txt > is the RADIUS counterpart of our Diameter Mobility documents: > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-10.txt and > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-09.txt > > Now, here is the important part. > > As part of the work on the draft, the feedback Avi got during the > presentation and offlist comments from Pasi and Jari there are some > concerns about the security properties provided by the following two > mechanisms: > * IKEv2 with PSKs > * IKEv2 with CERTs > > To briefly summarize the problems (also described in the slide set) > there are the following issues: > * Having the AAA deliver a PSK key to the HA without the AAA performing > authentication introduces security vulnerabilities. The discussed > possible solutions where the AAA could authenticate the PSK are somewhat > "clunky" since IKEv2 was never meant to be used in such a way. > * Similar problems arise with IKEv2 and Certificates where the AAA > server is used to just authorize without getting involved in the > authentication procedure itself. > > In an offline discussion between Jari, Pasi, Avi, and Jouni the idea > came up to drop these two mechanisms from the MIP6 RADIUS document and > consequently also from the Diameter MIPv6 Split draft. > > Is this a bad thing? > > I don't think so. Currently, we don't know anyone who would be using > them. Hence, there are somewhat "theoretical" at the moment. > > We could specify them once deployments would be asking for them. > > Who has objections against dropping the above-described mechanisms from > the Diameter MIPv6 Split draft? > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 19 10:27:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75D5F28C16D; Tue, 19 Aug 2008 10:27:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6778828C16E for ; Tue, 19 Aug 2008 10:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEbzaNIndEVA for ; Tue, 19 Aug 2008 10:27:46 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0360B28C16D for ; Tue, 19 Aug 2008 10:27:45 -0700 (PDT) Received: (qmail invoked by alias); 19 Aug 2008 17:26:57 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp020) with SMTP; 19 Aug 2008 19:26:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18JQ/M4dBIJR9BLBsgicY3jouaNJUG2ucqOe4hIfg A+RVO9uVm9ozi1 Message-ID: <48AB0263.1040905@gmx.net> Date: Tue, 19 Aug 2008 20:26:59 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: dime@ietf.org References: <48A98A18.2070206@gmx.net> In-Reply-To: <48A98A18.2070206@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 Cc: Glen Subject: Re: [Dime] Mailing list problems? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org We figured out what the mailing list problems are. Here is a short summary provided by Glen: " The problem is not with the mailing list; rather, it is the fact that emails are coming from a host without DNS records and, therefore, is being refused by our servers, in accordance with the consensus policy the IETF follows regarding spam handling. " Thank you Glen for your help! This was the case with Victor's mails to the list and it seems that other folks in the group experience similar problems. So, please talk to your IT folks to help you with fixing the issue. Ciao Hannes Hannes Tschofenig wrote: > Some mails did not appear on the list. I wonder whether other folks > experienced similar problems. Please drop me a mail. > > Ciao > Hannes > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 20 07:03:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1A53A6BE3; Wed, 20 Aug 2008 07:03:50 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D64F28B56A for ; Wed, 20 Aug 2008 07:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=1.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSUUzwlIIJ8O for ; Wed, 20 Aug 2008 07:03:49 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 2177D3A6BE1 for ; Wed, 20 Aug 2008 07:03:49 -0700 (PDT) Received: from [127.0.0.1] (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7KE3ipf061830; Wed, 20 Aug 2008 10:03:44 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48AC2438.4040609@tari.toshiba.com> Date: Wed, 20 Aug 2008 10:03:36 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Victor Fajardo References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> <48A98459.1050807@tari.toshiba.com> In-Reply-To: <48A98459.1050807@tari.toshiba.com> Cc: dime@ietf.org Subject: Re: [Dime] =?windows-1252?q?=3F=3F=3A__resubmission_draft_for_capabil?= =?windows-1252?q?ities-update-propoblem_statment?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Shan, Here's an updated version of the "Capabilities Update" section of bis that hopefully addresses the issue you stated in your draft: "5.6.5. Capabilities Update When a Diameter node is in the OPEN state, it can notify all its peers that its capabilities has changed by sending a Capabilities- Exchange-Req (CER). The receiver(s) of CER MUST reply with a CEA as a described in Section 5.3. Peers which successfully process a received CER SHOULD update their routing tables to reflect the change. The receiver of a CEA with the Result-Code AVP set to DIAMETER_SUCCESS MAY ignore the list of supported applications contained in the CEA. This optimization prevents the receiver from having to un-necessarily update is local routing tables. The receiver of the CEA with a Result-Code AVP set to a value other than DIAMETER_SUCCESS MUST disconnect the transport layer. The Diameter node MAY attempt to reconnect if its local capabilities has changed as stated in Section 2.1. Peer capabilities update SHOULD be limited to the advertisement of a new list of supported applications and MUST not include re- negotiation of security mechanism or other capabilities. If any capabilities update occurs in a Diameter node other than a list of supported applications, the node SHOULD gracefully terminate all its peer connections and simply attempt to re-connect with a new set of capabilities. " regards, victor > >> Thanks for describing the problem with the CER/CEA exchange in the open >> state. I think we maybe able to solve the issue described in this draft >> without introducing a new non-backward compatible CEA ABNF. From my >> understanding (which maybe incorrect), the key to the optimization >> described in your draft is to ignore the peer capabilities contained in >> the CEA in the OPEN state (both scenario 1 and 2 in your draft). If this >> is true, then the current bis document already supports this because it >> states in Sec 5.3: >> >> "The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include >> all of its supported applications as a hint to the receiver regarding >> all of its application capabilities." >> >> In this case, we are not mandating that the CEA receiver processes the >> received peer capabilities. In some sense, I do think that text in 5.3 >> is hard to read and this maybe why we end up with these types of >> discussions. So, for me, we may need to cleanup the text in 5.3 to >> simply the description of what is actually happening. With regards to >> this particular issue, we can even relax the CEA processing even more by >> changing it to MAY instead of SHOULD. >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 20 07:25:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5653A6C26; Wed, 20 Aug 2008 07:25:48 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC3D3A6C26 for ; Wed, 20 Aug 2008 07:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGZgZudG53V3 for ; Wed, 20 Aug 2008 07:25:44 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 032113A6BE3 for ; Wed, 20 Aug 2008 07:25:43 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so387224rvf.49 for ; Wed, 20 Aug 2008 07:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=gaKqbAON9KnBSh6+QAsBmDmxcP6GyAz+7HOtYC7CMp4=; b=hNSfbaNRP2LRiUFdICE5b6+4g7e2J+RfqldtGNEmtxaR5p6cmmD8RBs71MGZPu7F0M /eXacMXbgEK3iX4JYYwhtKQ2vE7UU1hxAIrcf4G+zMvTsWS51j7td6X6KY2HZdE+2UlJ D1liuNyHhH8D+FqJWV4COYsJraPavj2mg1bvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=Vf9nlYGEyZ0MPefS8mvtvafWuNNIxQJ/s18i+iLKNNaalGZErSh9B2K2CXXPrnuByz v5z6AR4nSJDFzKXB0a/11bjXJM5BnfhJWVKrvzttrCVHeGdJi9lNqNwfWE1PxQNt9HX6 1660L9eXOhfI60EofrcjwlomCZyDdu4wCJ2ZM= Received: by 10.140.162.21 with SMTP id k21mr66143rve.110.1219242327604; Wed, 20 Aug 2008 07:25:27 -0700 (PDT) Received: by 10.141.35.15 with HTTP; Wed, 20 Aug 2008 07:25:27 -0700 (PDT) Message-ID: <9cf5ced20808200725m626a46bao9acfdc3cb5b1acdd@mail.gmail.com> Date: Wed, 20 Aug 2008 10:25:27 -0400 From: "David Frascone" To: "Victor Fajardo" In-Reply-To: <48AC2438.4040609@tari.toshiba.com> MIME-Version: 1.0 References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> <48A98459.1050807@tari.toshiba.com> <48AC2438.4040609@tari.toshiba.com> X-Google-Sender-Auth: 84bbe19ffa56244c Cc: dime@ietf.org Subject: Re: [Dime] ??: resubmission draft for capabilities-update-propoblem statment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0874156171==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0874156171== Content-Type: multipart/alternative; boundary="----=_Part_18181_10635293.1219242327590" ------=_Part_18181_10635293.1219242327590 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think the new text is clear, and resolves the issue. Only one comment -- should we explain *why* a peer can ignore the applications listed in a CEA? -Dave On Wed, Aug 20, 2008 at 10:03 AM, Victor Fajardo wrote: > Hi Shan, > > Here's an updated version of the "Capabilities Update" section of bis that > hopefully addresses the issue you stated in your draft: > > "5.6.5. Capabilities Update > > When a Diameter node is in the OPEN state, it can notify all its > peers that its capabilities has changed by sending a Capabilities- > Exchange-Req (CER). The receiver(s) of CER MUST reply with a CEA as > a described in Section 5.3. Peers which successfully process a > received CER SHOULD update their routing tables to reflect the > change. The receiver of a CEA with the Result-Code AVP set to > DIAMETER_SUCCESS MAY ignore the list of supported applications > contained in the CEA. This optimization prevents the receiver from > having to un-necessarily update is local routing tables. The > receiver of the CEA with a Result-Code AVP set to a value other than > DIAMETER_SUCCESS MUST disconnect the transport layer. The Diameter > node MAY attempt to reconnect if its local capabilities has changed > as stated in Section 2.1. > > Peer capabilities update SHOULD be limited to the advertisement of a > new list of supported applications and MUST not include re- > negotiation of security mechanism or other capabilities. If any > capabilities update occurs in a Diameter node other than a list of > supported applications, the node SHOULD gracefully terminate all its > peer connections and simply attempt to re-connect with a new set of > capabilities. > " > > regards, > victor > > > >> Thanks for describing the problem with the CER/CEA exchange in the open >>> state. I think we maybe able to solve the issue described in this draft >>> without introducing a new non-backward compatible CEA ABNF. From my >>> understanding (which maybe incorrect), the key to the optimization described >>> in your draft is to ignore the peer capabilities contained in the CEA in the >>> OPEN state (both scenario 1 and 2 in your draft). If this is true, then the >>> current bis document already supports this because it states in Sec 5.3: >>> >>> "The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include all >>> of its supported applications as a hint to the receiver regarding all of its >>> application capabilities." >>> >>> In this case, we are not mandating that the CEA receiver processes the >>> received peer capabilities. In some sense, I do think that text in 5.3 is >>> hard to read and this maybe why we end up with these types of discussions. >>> So, for me, we may need to cleanup the text in 5.3 to simply the description >>> of what is actually happening. With regards to this particular issue, we can >>> even relax the CEA processing even more by changing it to MAY instead of >>> SHOULD. >>> >>> >> >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ------=_Part_18181_10635293.1219242327590 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I think the new text is clear, and resolves the issue.

Only one comment -- should we explain *why* a peer can ignore the applications listed in a CEA?

-Dave

On Wed, Aug 20, 2008 at 10:03 AM, Victor Fajardo <vfajardo@tari.toshiba.com> wrote:
Hi Shan,

Here's an updated version of the "Capabilities Update" section of bis that hopefully addresses the issue you stated in your draft:

"5.6.5.  Capabilities Update

 When a Diameter node is in the OPEN state, it can notify all its
 peers that its capabilities has changed by sending a Capabilities-
 Exchange-Req (CER).  The receiver(s) of CER MUST reply with a CEA as
 a described in Section 5.3.  Peers which successfully process a
 received CER SHOULD update their routing tables to reflect the
 change.  The receiver of a CEA with the Result-Code AVP set to
 DIAMETER_SUCCESS MAY ignore the list of supported applications
 contained in the CEA.  This optimization prevents the receiver from
 having to un-necessarily update is local routing tables.  The
 receiver of the CEA with a Result-Code AVP set to a value other than
 DIAMETER_SUCCESS MUST disconnect the transport layer.  The Diameter
 node MAY attempt to reconnect if its local capabilities has changed
 as stated in Section 2.1.

 Peer capabilities update SHOULD be limited to the advertisement of a
 new list of supported applications and MUST not include re-
 negotiation of security mechanism or other capabilities.  If any
 capabilities update occurs in a Diameter node other than a list of
 supported applications, the node SHOULD gracefully terminate all its
 peer connections and simply attempt to re-connect with a new set of
 capabilities.
"

regards,
victor



Thanks for describing the problem with the CER/CEA exchange in the open state. I think we maybe able to solve the issue described in this draft without introducing a new non-backward compatible CEA ABNF. From my understanding (which maybe incorrect), the key to the optimization described in your draft is to ignore the peer capabilities contained in the CEA in the OPEN state (both scenario 1 and 2 in your draft). If this is true, then the current bis document already supports this because it states in Sec 5.3:

"The sender of the Capabilities-Exchange-Answer  (CEA) SHOULD include all of its supported applications as a hint to the receiver regarding all of its application capabilities."

In this case, we are not mandating that the CEA receiver processes the received peer capabilities. In some sense, I do think that text in 5.3 is hard to read and this maybe why we end up with these types of discussions. So, for me, we may need to cleanup the text in 5.3 to simply the description of what is actually happening. With regards to this particular issue, we can even relax the CEA processing even more by changing it to MAY instead of SHOULD.
 


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

------=_Part_18181_10635293.1219242327590-- --===============0874156171== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0874156171==-- From dime-bounces@ietf.org Wed Aug 20 07:34:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F323A6C3B; Wed, 20 Aug 2008 07:34:41 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4C328B56A for ; Wed, 20 Aug 2008 07:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCOL+HKZHaPH for ; Wed, 20 Aug 2008 07:34:28 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 88EE63A6C4A for ; Wed, 20 Aug 2008 07:34:28 -0700 (PDT) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7KEYUXN062126; Wed, 20 Aug 2008 10:34:30 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48AC2B6D.9020907@tari.toshiba.com> Date: Wed, 20 Aug 2008 10:34:21 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: David Frascone References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> <48A98459.1050807@tari.toshiba.com> <48AC2438.4040609@tari.toshiba.com> <9cf5ced20808200725m626a46bao9acfdc3cb5b1acdd@mail.gmail.com> In-Reply-To: <9cf5ced20808200725m626a46bao9acfdc3cb5b1acdd@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] ??: resubmission draft for capabilities-update-propoblem statment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi David, > I think the new text is clear, and resolves the issue. > > Only one comment -- should we explain *why* a peer can ignore the > applications listed in a CEA? > I guess we can as long as its short an concise. regards, victor > -Dave > > On Wed, Aug 20, 2008 at 10:03 AM, Victor Fajardo > wrote: > > >> Hi Shan, >> >> Here's an updated version of the "Capabilities Update" section of bis that >> hopefully addresses the issue you stated in your draft: >> >> "5.6.5. Capabilities Update >> >> When a Diameter node is in the OPEN state, it can notify all its >> peers that its capabilities has changed by sending a Capabilities- >> Exchange-Req (CER). The receiver(s) of CER MUST reply with a CEA as >> a described in Section 5.3. Peers which successfully process a >> received CER SHOULD update their routing tables to reflect the >> change. The receiver of a CEA with the Result-Code AVP set to >> DIAMETER_SUCCESS MAY ignore the list of supported applications >> contained in the CEA. This optimization prevents the receiver from >> having to un-necessarily update is local routing tables. The >> receiver of the CEA with a Result-Code AVP set to a value other than >> DIAMETER_SUCCESS MUST disconnect the transport layer. The Diameter >> node MAY attempt to reconnect if its local capabilities has changed >> as stated in Section 2.1. >> >> Peer capabilities update SHOULD be limited to the advertisement of a >> new list of supported applications and MUST not include re- >> negotiation of security mechanism or other capabilities. If any >> capabilities update occurs in a Diameter node other than a list of >> supported applications, the node SHOULD gracefully terminate all its >> peer connections and simply attempt to re-connect with a new set of >> capabilities. >> " >> >> regards, >> victor >> >> >> >> >>> Thanks for describing the problem with the CER/CEA exchange in the open >>> >>>> state. I think we maybe able to solve the issue described in this draft >>>> without introducing a new non-backward compatible CEA ABNF. From my >>>> understanding (which maybe incorrect), the key to the optimization described >>>> in your draft is to ignore the peer capabilities contained in the CEA in the >>>> OPEN state (both scenario 1 and 2 in your draft). If this is true, then the >>>> current bis document already supports this because it states in Sec 5.3: >>>> >>>> "The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include all >>>> of its supported applications as a hint to the receiver regarding all of its >>>> application capabilities." >>>> >>>> In this case, we are not mandating that the CEA receiver processes the >>>> received peer capabilities. In some sense, I do think that text in 5.3 is >>>> hard to read and this maybe why we end up with these types of discussions. >>>> So, for me, we may need to cleanup the text in 5.3 to simply the description >>>> of what is actually happening. With regards to this particular issue, we can >>>> even relax the CEA processing even more by changing it to MAY instead of >>>> SHOULD. >>>> >>>> >>>> >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 20 23:58:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E623A6AD5; Wed, 20 Aug 2008 23:58:56 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C543A69BD for ; Wed, 20 Aug 2008 23:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.608 X-Spam-Level: X-Spam-Status: No, score=-0.608 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRsD5Zb1AQxw for ; Wed, 20 Aug 2008 23:58:37 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 685E03A692B for ; Wed, 20 Aug 2008 23:58:37 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 4A042B8B32; Thu, 21 Aug 2008 08:58:22 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 3B17AB8B30; Thu, 21 Aug 2008 08:58:22 +0200 (CEST) Message-ID: <48AD120E.8060201@restena.lu> Date: Thu, 21 Aug 2008 08:58:22 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20071114) MIME-Version: 1.0 To: jouni.korhonen@iki.fi References: <48A2C236.9040300@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D62B@SEHAN021MB.tcad.telia.se> <48A42AAF.2050402@restena.lu> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D64F@SEHAN021MB.tcad.telia.se> <48A437C5.3070409@restena.lu> <48A48460.4020908@kolumbus.fi> <48A97FE2.6010204@restena.lu> <48AA6988.4040704@kolumbus.fi> In-Reply-To: <48AA6988.4040704@kolumbus.fi> X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] review of draft-korhonen-dime-nai-routing-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > Right, you got a point there. However, in my domain of "roaming world" = > NAP is commonly used to describe the functional / commercial entity > that operates a NAS (or a plethora of NASes) and maybe has a complex = > internal proxy network, hence the preference of NAP over NAS. A "NAS aggregator" maybe? Interesting. To me this reads like "Our NAPs are NASes which are more complicated and = sophisticated than most other NASes." (and I would counter that with: = but they are still some sort of NAS, so using the term NAS would cover = them nicely) > > How about: > > "Network Access Provider (NAP): > > A business entity that provides network access infrastructure to one = > or [SW: ... more ...] > realms. A NAP infrastructure constitutes one or more NASes. > > > Network Access Server (NAS): > > The device that peers connect to in order to obtain access to the > network and is authoritative for AAA message exchanges in the > NAP infrastructure. > " > > Keep this in the terminology and then use the NAP/NAS throughout the = > document...? = It's just a matter of personal taste I guess. The above looks already a = lot cleaner than before. My preference though would be to stick with = just NAS as it looks like the more general wording. Then again, I'm the = new kid in town on this mailing list so my humbleness dictates that I'll = yield and accept a rough consensus for any of these two choices :-) Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 21 02:34:39 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6B93A68D5; Thu, 21 Aug 2008 02:34:39 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2123A6AE3 for ; Thu, 21 Aug 2008 02:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpWmT1NuA8o2 for ; Thu, 21 Aug 2008 02:33:56 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id D0C363A68D5 for ; Thu, 21 Aug 2008 02:33:56 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 4xW51a00317UAYkA2xZCPK; Thu, 21 Aug 2008 09:33:12 +0000 Received: from gwzPC ([124.122.162.250]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id 4xYn1a0085QTNGU8ZxZ2ht; Thu, 21 Aug 2008 09:33:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=yXnNWKMJu3MA:10 a=kBwdzwIaoBoA:10 a=FKNkGExsWpcBHGXMS0IA:9 a=qK4TPIFrhtDR_XZS2bIA:7 a=OZFEMz_tjl4m5nzvsltPeSkMKUIA:4 a=EI1Y7BXnmVQA:10 From: "Glen Zorn" To: "'Victor Fajardo'" References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> <48A98459.1050807@tari.toshiba.com> <48AC2438.4040609@tari.toshiba.com> In-Reply-To: <48AC2438.4040609@tari.toshiba.com> Date: Thu, 21 Aug 2008 16:32:38 +0700 Message-ID: <004e01c90370$e10dfaa0$a329efe0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckCzZxDEtGO9NbgSLe6WWvu0YVR/QAoIuBg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] ??: resubmission draft for capabilities-update-propoblem statment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Victor Fajardo writes: ... > Hi Shan, > > Here's an updated version of the "Capabilities Update" section of bis > that hopefully addresses the issue you stated in your draft: > > "5.6.5. Capabilities Update > > When a Diameter node is in the OPEN state, it can notify all its > peers that its capabilities has changed by sending a Capabilities- > Exchange-Req (CER). The receiver(s) of CER MUST reply with a CEA as > a described in Section 5.3. Peers which successfully process a > received CER SHOULD update their routing tables to reflect the > change. The receiver of a CEA with the Result-Code AVP set to > DIAMETER_SUCCESS MAY ignore the list of supported applications > contained in the CEA. This optimization prevents the receiver from > having to un-necessarily update is local routing tables. The > receiver of the CEA with a Result-Code AVP set to a value other than > DIAMETER_SUCCESS MUST disconnect the transport layer. The Diameter > node MAY attempt to reconnect if its local capabilities has changed > as stated in Section 2.1. > > Peer capabilities update SHOULD be limited to the advertisement of a > new list of supported applications and MUST not include re- > negotiation of security mechanism or other capabilities. If any > capabilities update occurs in a Diameter node other than a list of > supported applications, the node SHOULD gracefully terminate all its > peer connections and simply attempt to re-connect with a new set of > capabilities. > " > Aside from the obvious fact that the initial message is not a "Capabilities-Exchange-Req" (no exchange is being requested, a change is being announced), this looks much better. The following fixes a few typos/grammatical errors: "5.6.5. Capabilities Update When a Diameter node is in the OPEN state, it can notify all its peers that the set of Diameter applications it supports has changed by sending a Capabilities- Exchange-Req (CER). The receiver of a CER MUST reply with a CEA as a described in Section 5.3. Peers which successfully process a received CER SHOULD update their routing tables to reflect the change. The receiver of a CEA with the Result-Code AVP set to DIAMETER_SUCCESS MAY ignore the list of supported applications contained in the CEA. This optimization prevents the receiver from having to unnecessarily update its local routing tables. The receiver of the CEA with a Result-Code AVP set to a value other than DIAMETER_SUCCESS MUST disconnect the transport layer. The Diameter node MAY attempt to reconnect if its local capabilities have changed as stated in Section 2.1. Peer capabilities update SHOULD be limited to the advertisement of a new list of supported applications and MUST not include re- negotiation of the security mechanism or other capabilities. If any change in capabilities occurs in a Diameter node other than a list of supported applications, the node SHOULD gracefully terminate all its peer connections and simply attempt to re-connect with a new set of capabilities. " A couple more things: in this situation, might not the MAY in "The receiver of a CEA with the Result-Code AVP set to DIAMETER_SUCCESS MAY ignore the list of supported applications contained in the CEA" better be a SHOULD, since only rarely will changes in supported applications in peers be simultaneous? Also, I'm not sure what " The Diameter node MAY attempt to reconnect if its local capabilities have changed as stated in Section 2.1." means: there are at least 2 Diameter nodes being discussed here, which one is it? ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 21 02:40:24 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413F13A6AAE; Thu, 21 Aug 2008 02:40:24 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174833A690D for ; Thu, 21 Aug 2008 02:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-tsMyBU3Ws8 for ; Thu, 21 Aug 2008 02:40:18 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 777103A68D5 for ; Thu, 21 Aug 2008 02:40:18 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id 4xdZ1a0061HpZEsA5xfF0t; Thu, 21 Aug 2008 09:39:15 +0000 Received: from gwzPC ([124.122.162.250]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id 4xen1a0035QTNGU8axf3tE; Thu, 21 Aug 2008 09:39:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=VOv44VW-dRkA:10 a=Iad5mHz1eQgA:10 a=48vgC7mUAAAA:8 a=rp6q7qDZ7pRBVzopLhoA:9 a=pBLWaw9NruMs81BkbwoA:7 a=p3AK4n6BfCBbK8qBsz0dggmun1UA:4 a=lZB815dzVvQA:10 a=EI1Y7BXnmVQA:10 From: "Glen Zorn" To: "'Victor Fajardo'" , "'David Frascone'" References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> <48A98459.1050807@tari.toshiba.com> <48AC2438.4040609@tari.toshiba.com> <9cf5ced20808200725m626a46bao9acfdc3cb5b1acdd@mail.gmail.com> <48AC2B6D.9020907@tari.toshiba.com> In-Reply-To: <48AC2B6D.9020907@tari.toshiba.com> Date: Thu, 21 Aug 2008 16:38:38 +0700 Message-ID: <004f01c90371$b8ca6730$2a5f3590$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckC0e1VKgu2nb6TRM2G6O6zzCXO3gAnwvCQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] ??: resubmission draft for capabilities-update-propoblem statment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Victor Fajardo writes: > Hi David, > > > I think the new text is clear, and resolves the issue. > > > > Only one comment -- should we explain *why* a peer can ignore the > > applications listed in a CEA? > > > > I guess we can as long as its short an concise. I think that this confusion is inherent in the overloading of the CER/CEA exchange -- we'll pay later for any false economy of words today... > > regards, > victor > > > -Dave > > > > On Wed, Aug 20, 2008 at 10:03 AM, Victor Fajardo > > wrote: > > > > > >> Hi Shan, > >> > >> Here's an updated version of the "Capabilities Update" section of > bis that > >> hopefully addresses the issue you stated in your draft: > >> > >> "5.6.5. Capabilities Update > >> > >> When a Diameter node is in the OPEN state, it can notify all its > >> peers that its capabilities has changed by sending a Capabilities- > >> Exchange-Req (CER). The receiver(s) of CER MUST reply with a CEA > as > >> a described in Section 5.3. Peers which successfully process a > >> received CER SHOULD update their routing tables to reflect the > >> change. The receiver of a CEA with the Result-Code AVP set to > >> DIAMETER_SUCCESS MAY ignore the list of supported applications > >> contained in the CEA. This optimization prevents the receiver from > >> having to un-necessarily update is local routing tables. The > >> receiver of the CEA with a Result-Code AVP set to a value other > than > >> DIAMETER_SUCCESS MUST disconnect the transport layer. The Diameter > >> node MAY attempt to reconnect if its local capabilities has changed > >> as stated in Section 2.1. > >> > >> Peer capabilities update SHOULD be limited to the advertisement of > a > >> new list of supported applications and MUST not include re- > >> negotiation of security mechanism or other capabilities. If any > >> capabilities update occurs in a Diameter node other than a list of > >> supported applications, the node SHOULD gracefully terminate all > its > >> peer connections and simply attempt to re-connect with a new set of > >> capabilities. > >> " > >> > >> regards, > >> victor > >> > >> > >> > >> > >>> Thanks for describing the problem with the CER/CEA exchange in the > open > >>> > >>>> state. I think we maybe able to solve the issue described in this > draft > >>>> without introducing a new non-backward compatible CEA ABNF. From > my > >>>> understanding (which maybe incorrect), the key to the optimization > described > >>>> in your draft is to ignore the peer capabilities contained in the > CEA in the > >>>> OPEN state (both scenario 1 and 2 in your draft). If this is true, > then the > >>>> current bis document already supports this because it states in > Sec 5.3: > >>>> > >>>> "The sender of the Capabilities-Exchange-Answer (CEA) SHOULD > include all > >>>> of its supported applications as a hint to the receiver regarding > all of its > >>>> application capabilities." > >>>> > >>>> In this case, we are not mandating that the CEA receiver processes > the > >>>> received peer capabilities. In some sense, I do think that text in > 5.3 is > >>>> hard to read and this maybe why we end up with these types of > discussions. > >>>> So, for me, we may need to cleanup the text in 5.3 to simply the > description > >>>> of what is actually happening. With regards to this particular > issue, we can > >>>> even relax the CEA processing even more by changing it to MAY > instead of > >>>> SHOULD. > >>>> > >>>> > >>>> > >>> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > >> > >> > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 21 04:04:26 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBA93A6AF4; Thu, 21 Aug 2008 04:04:26 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAE63A699A for ; Thu, 21 Aug 2008 03:58:51 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAiAGnKF1hkt for ; Thu, 21 Aug 2008 03:58:50 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 981073A67A6 for ; Thu, 21 Aug 2008 03:58:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,245,1217808000"; d="scan'208,217";a="26333132" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 21 Aug 2008 10:58:35 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7LAwZG9027194 for ; Thu, 21 Aug 2008 16:28:35 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7LAwYpk007149 for ; Thu, 21 Aug 2008 10:58:34 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:28:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Aug 2008 16:28:34 +0530 Message-ID: <2D41CB2D25A8324783DFA3E7F564FBF2072B64ED@xmb-blr-415.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Base Protocol and CC Application MIBs Thread-Index: AckCD6w94w4z1CtYS6OoG5k6iY1MOwBbPp0w From: "Subash Comerica (subashtc)" To: X-OriginalArrivalTime: 21 Aug 2008 10:58:35.0039 (UTC) FILETIME=[DB82F2F0:01C9037C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1332; t=1219316315; x=1220180315; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=subashtc@cisco.com; z=From:=20=22Subash=20Comerica=20(subashtc)=22=20 |Subject:=20Base=20Protocol=20and=20CC=20Application=20MIBs |Sender:=20; bh=FEw4Js+hhRqon6L5tjFVEsAkylZck/QlbwRvQewdBEQ=; b=J9fy9lPYEH0GJaz5cQD2ASkl5eXUXxI6/bBAH3vpvgreQ86/o5lNB4D5WU YiIrU2uRDAz56T+fryZ70RJhSKgTd4F4jevATECA0sCyyhtol6qlKo9GAlNB L+9oaeZqA5; Authentication-Results: ind-dkim-2; header.From=subashtc@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); Subject: [Dime] Base Protocol and CC Application MIBs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1253070662==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1253070662== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9037C.DB72B5BB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9037C.DB72B5BB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on Dave's request at the Ops Open Area Meeting, we would like to share with everyone that our company has implemented and deployed both the base protocol and CC application mibs.=20 They are deployed and are meeting all of our needs. =20 Thanks and Regards, Subash ------_=_NextPart_001_01C9037C.DB72B5BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
    Based on=20 Dave's request at the Ops Open Area Meeting, we would like to share with = everyone that our company has implemented and deployed both the base = protocol=20 and CC application mibs.
    They are deployed and = are=20 meeting all of our needs.
 
Thanks and=20 Regards,
Subash
------_=_NextPart_001_01C9037C.DB72B5BB-- --===============1253070662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1253070662==-- From dime-bounces@ietf.org Thu Aug 21 06:35:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EE43A67F8; Thu, 21 Aug 2008 06:35:44 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E13F3A67F8 for ; Thu, 21 Aug 2008 06:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yxIOrre2MxS for ; Thu, 21 Aug 2008 06:27:00 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 99C593A6780 for ; Thu, 21 Aug 2008 06:27:00 -0700 (PDT) Received: from [127.0.0.1] (smtp.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7LDQu5q074644; Thu, 21 Aug 2008 09:26:56 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48AD6D12.30303@tari.toshiba.com> Date: Thu, 21 Aug 2008 09:26:42 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Glen Zorn References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> <48A98459.1050807@tari.toshiba.com> <48AC2438.4040609@tari.toshiba.com> <004e01c90370$e10dfaa0$a329efe0$@net> In-Reply-To: <004e01c90370$e10dfaa0$a329efe0$@net> Cc: dime@ietf.org Subject: Re: [Dime] ??: resubmission draft for capabilities-update-propoblem statment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen, >> > > Aside from the obvious fact that the initial message is not a > "Capabilities-Exchange-Req" (no exchange is being requested, a change is > being announced), this looks much better. The following fixes a few > typos/grammatical errors: > > "5.6.5. Capabilities Update > > When a Diameter node is in the OPEN state, it can notify all its > peers that the set of Diameter applications it supports has changed by > sending a Capabilities- > Exchange-Req (CER). The receiver of a CER MUST reply with a CEA as > a described in Section 5.3. Peers which successfully process a > received CER SHOULD update their routing tables to reflect the > change. The receiver of a CEA with the Result-Code AVP set to > DIAMETER_SUCCESS MAY ignore the list of supported applications > contained in the CEA. This optimization prevents the receiver from > having to unnecessarily update its local routing tables. The > receiver of the CEA with a Result-Code AVP set to a value other than > DIAMETER_SUCCESS MUST disconnect the transport layer. The Diameter > node MAY attempt to reconnect if its local capabilities have changed > as stated in Section 2.1. > > Peer capabilities update SHOULD be limited to the advertisement of a > new list of supported applications and MUST not include re- > negotiation of the security mechanism or other capabilities. If any > change in capabilities occurs in a Diameter node other than a list of > supported applications, the node SHOULD gracefully terminate all its > peer connections and simply attempt to re-connect with a new set of > capabilities. > " > Looks good. Thanks. > A couple more things: in this situation, might not the MAY in "The receiver > of a CEA with the Result-Code AVP set to DIAMETER_SUCCESS MAY ignore the > list of supported applications contained in the CEA" better be a SHOULD, > since only rarely will changes in supported applications in peers be > simultaneous? I'm ok with that. > Also, I'm not sure what " The Diameter node MAY attempt to > reconnect if its local capabilities have changed as stated in Section 2.1." > means: there are at least 2 Diameter nodes being discussed here, which one > is it? > It is implies either nodes. In which case, how about changing the text to: "Both Diameter nodes MAY attempt to reconnect if their local capabilities have changed ...." br, -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 21 06:37:26 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738C73A6B36; Thu, 21 Aug 2008 06:37:26 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADCA3A6B28 for ; Thu, 21 Aug 2008 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdUdIq+QjoEI for ; Thu, 21 Aug 2008 06:28:42 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 3C20F3A6780 for ; Thu, 21 Aug 2008 06:28:42 -0700 (PDT) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7LDSc87074647; Thu, 21 Aug 2008 09:28:38 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48AD6D78.2040807@tari.toshiba.com> Date: Thu, 21 Aug 2008 09:28:24 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Glen Zorn References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> <48A98459.1050807@tari.toshiba.com> <48AC2438.4040609@tari.toshiba.com> <9cf5ced20808200725m626a46bao9acfdc3cb5b1acdd@mail.gmail.com> <48AC2B6D.9020907@tari.toshiba.com> <004f01c90371$b8ca6730$2a5f3590$@net> In-Reply-To: <004f01c90371$b8ca6730$2a5f3590$@net> Cc: dime@ietf.org Subject: Re: [Dime] ??: resubmission draft for capabilities-update-propoblem statment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen, >>> I think the new text is clear, and resolves the issue. >>> >>> Only one comment -- should we explain *why* a peer can ignore the >>> applications listed in a CEA? >>> >>> >> I guess we can as long as its short an concise. >> > > I think that this confusion is inherent in the overloading of the CER/CEA > exchange -- we'll pay later for any false economy of words today... > Ok. Any text you can suggest ? br, -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 21 07:25:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7D128C129; Thu, 21 Aug 2008 07:25:58 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A02D3A68BC for ; Thu, 21 Aug 2008 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=1.419, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YDi3gxMsrVU for ; Thu, 21 Aug 2008 07:10:38 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 930F33A67F4 for ; Thu, 21 Aug 2008 07:10:38 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id 4zmB1a0020x6nqcA829Zd9; Thu, 21 Aug 2008 14:09:33 +0000 Received: from gwzPC ([124.120.229.150]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id 528l1a00F3FLU388Y29BrX; Thu, 21 Aug 2008 14:09:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=yXnNWKMJu3MA:10 a=kBwdzwIaoBoA:10 a=_OLr7KRN4fRfrvNFiGsA:9 a=W1uuGXNlzLIXL9Rku4OYld_FF5sA:4 a=EI1Y7BXnmVQA:10 From: "Glen Zorn" To: "'Victor Fajardo'" References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> <48A98459.1050807@tari.toshiba.com> <48AC2438.4040609@tari.toshiba.com> <004e01c90370$e10dfaa0$a329efe0$@net> <48AD6D12.30303@tari.toshiba.com> In-Reply-To: <48AD6D12.30303@tari.toshiba.com> Date: Thu, 21 Aug 2008 21:08:34 +0700 Message-ID: <001801c90397$73b8dd90$5b2a98b0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckDkZt0HFwJIhDLTEukL8ZJ8GdGmwABVNOQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] ??: resubmission draft for capabilities-update-propoblem statment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Victor Fajardo [mailto:vfajardo@tari.toshiba.com] writes: Missed one, sorry: Change: If any change in capabilities occurs in a Diameter node other than a list of supported applications, the node SHOULD gracefully terminate all its peer connections and simply attempt to re-connect with a new set of capabilities. To: If any change in capabilities occurs in a Diameter node other than to the list of supported applications, the node SHOULD gracefully terminate all its peer connections and simply attempt to re-connect with a new set of capabilities. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 21 07:42:53 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55523A69B1; Thu, 21 Aug 2008 07:42:53 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8074E28C13E for ; Thu, 21 Aug 2008 07:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf7kV4Qds3eb for ; Thu, 21 Aug 2008 07:33:11 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id A83013A6A17 for ; Thu, 21 Aug 2008 07:33:11 -0700 (PDT) Received: from [127.0.0.1] (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7LEXAuc074852; Thu, 21 Aug 2008 10:33:10 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48AD7C99.8080803@tari.toshiba.com> Date: Thu, 21 Aug 2008 10:32:57 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Glen Zorn References: <004f01c8f2ea$e97272c0$ac378182@china.huawei.com> <48A98459.1050807@tari.toshiba.com> <48AC2438.4040609@tari.toshiba.com> <004e01c90370$e10dfaa0$a329efe0$@net> <48AD6D12.30303@tari.toshiba.com> <001801c90397$73b8dd90$5b2a98b0$@net> In-Reply-To: <001801c90397$73b8dd90$5b2a98b0$@net> Cc: dime@ietf.org Subject: Re: [Dime] ??: resubmission draft for capabilities-update-propoblem statment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Great. Thanks. > Victor Fajardo [mailto:vfajardo@tari.toshiba.com] writes: > > Missed one, sorry: > > Change: > If any change in capabilities occurs in a Diameter node other than a list of > supported applications, the node SHOULD gracefully terminate all its peer > connections and simply attempt to re-connect with a new set of capabilities. > > To: > If any change in capabilities occurs in a Diameter node other than to the > list of supported applications, the node SHOULD gracefully terminate all its > peer connections and simply attempt to re-connect with a new set of > capabilities. > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 24 03:53:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266CB3A6AC4; Sun, 24 Aug 2008 03:53:41 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B11B3A6923 for ; Sun, 24 Aug 2008 03:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.07 X-Spam-Level: X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2DGMsINBzms for ; Sun, 24 Aug 2008 03:53:38 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 55F963A6B19 for ; Sun, 24 Aug 2008 03:53:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,262,1217822400"; d="scan'208";a="119325204" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Aug 2008 06:53:36 -0400 X-IronPort-AV: E=Sophos;i="4.32,262,1217822400"; d="scan'208";a="265461277" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Aug 2008 06:53:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Aug 2008 12:53:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-dime-diameter-api-07.txt Thread-Index: AckDcVngMpQzclERSna07NeNy8nVgQCZhrCg From: "Romascanu, Dan (Dan)" To: Cc: Francis Dupont Subject: [Dime] FW: review of draft-ietf-dime-diameter-api-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Please find below the Gen-ART review for draft-ietf-dime-diameter-api-07.txt. Please address Francis comments together with the other IETF LC comments. Thanks and Regards, Dan -----Original Message----- From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] Sent: Thursday, August 21, 2008 12:35 PM To: gen-art@ietf.org Cc: pacalhou@cisco.com; dave@frascone.com; Romascanu, Dan (Dan) Subject: review of draft-ietf-dime-diameter-api-07.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-diameter-api-07.txt Reviewer: Francis Dupont Review Date: 2008-08-20 IETF LC End Date: 2008-08-08 IESG Telechat date: unknown Summary: Not Ready Comments: my main concern is the API as it is described up to section 3.7 is clearly impossible to implement so I strongly suggest to add soon (in section 2 for instance) some text explaining the document only specifies the visible/public part of some structures. Another issue is most of the "include" part is missing. Detailed comments: - 1 page 4: code need only -> code needs only - 2.2 page 6: All of the functions -> All functions ? - 2.5 page 6: a DTD described it -> a DTD describing it - 2 page 6: IMHO this is the right place to explain the structs defined in the document are the visible/public part of the real/internal structs with a reference to section 3.7 - 3.1.12 page 10: if -> when ? - 3.1.15 page 12: the header (six, four) is obviously about a previous version... - 3.1.15 page 12: IMHO you should explain why, despite the name "flags", it is right to use an enumeration here (exclusive values, etc). - 3.1.16 page 12: AAAGetDomainInterconnectType() doesn't return this type (cf. 3.4.3.7) and it is not AAAGetDomainInternconnectType() ^ - 3.2.3 page 15: this type should be opaque, i.e., the name of the fields should be private. This has two consequences: * users don't know the names so can't misuse them (they have AAAGetFirstAVP() & co) * it justifies a bit the *avpList in the next section (in place of plain avpList) BTW in a traditional double-linked list with tail pointer the tail is a ** pointer - 3.2.4 page 16: extra *Version fields (unneeded with AAA_IP_ADDR) - 3.4.3.7 page 24: type should be a AAADomainInterconnect * - 3.4.4.6 page 27: AAAGetCommandCode() must return an AAAReturnCode and the return value text be updated to the usual one - 3.4.5.4 page 29: occured -> occurred - 3.4.5.6 page 30: AAACreateAndAddAVPToList() is underspecified: * can be the avpList created when it points to NULL? (cf next section) * what is the position when the list is not empty? - 3.4.5.[67] pages 30 & 31: there is no way to free an AAA_AVP_List so what to do if something fails? Obviously there are some use restrictions so at least a reference to 3.6 is wellcome - 3.4.5.1[45] page 34 (comment): obviously AAAGet{Next,Prev}AVP() imply link fields in the real AVP struct! - 3.4.6.1 page 36: extra ipVersion field - 3.4.6.2 page 36 (comment): again the server id is an internal AAAMessage field - 3.6 page 38: (for uniformity) (char *) ourAddress -> (char *)ourAddress - 3.7 page 39: this is a key point but one has to read ~40 pages to find it. Note there are other ways to handle public/private fields in C (but no highly recommended ways): * the sub structure way (document's one) * private fields at the end of the definition with a comment explaining they are private * private fields at the end of the definition protected by a #ifdef I prefer the second one (no cast, sizeof() works but it relies on the programmer's discipline) but you should simply give the choice to implementors - 3.9 page 41: 3.1.13 specifies there can be only one first/last, for instance: AAA_APP_INSTALL_FIRST: Install this callback as the first callback in the chain. If subsequent callbacks are installed with this code, then AAA_ERR_ALREADY_REGISTERED is returned. so 3.1.13 and 3.9 are in conflict (note I prefer 3.1.13) - 7.2 page 45: where are the DIAM_AVP_* & co defined? I am afraid you have to add them... - Author's Addresses page 46: please add the Contry (USA? :-) - I'd like to have a .h in annex (note the names of the .h and of the DLL/library/... are part of the API) Regards Francis.Dupont@fdupont.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 24 22:48:11 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E531E3A688E; Sun, 24 Aug 2008 22:48:11 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC5A3A683B for ; Sun, 24 Aug 2008 22:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gudw6mz3uLV5 for ; Sun, 24 Aug 2008 22:48:09 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 559C33A688E for ; Sun, 24 Aug 2008 22:48:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7FAA8C8035 for ; Mon, 25 Aug 2008 01:48:00 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13317-20 for ; Mon, 25 Aug 2008 01:47:58 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 25 Aug 2008 01:47:58 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 01:47:04 -0400 Received: from [10.6.7.67] ([10.6.7.67]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 11:11:05 +0530 From: Sarkar Biplab To: dime Date: Mon, 25 Aug 2008 11:11:05 +0530 Message-Id: <1219642865.8316.9.camel@INDBNG1172.bng.ind.starentnetworks.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 25 Aug 2008 05:41:05.0898 (UTC) FILETIME=[2AFDB4A0:01C90675] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] ABNF X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0899091358==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0899091358== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Rw6BraCd0InFtcinN3Pj" --=-Rw6BraCd0InFtcinN3Pj Content-Type: multipart/alternative; boundary="=-Rzl5PMHltzT6XeM9kTkC" --=-Rzl5PMHltzT6XeM9kTkC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi All, I would suggest some enhancements to the ABNF representation of the diameter messages to indicate the "Mandatory Exclusion" of certain AVPs in some messages. The following type of information should be captured in the messages description ABNF. (Say by using negative "max" count ). =3D=3D=3D=3D=3D=3D=3D=3D RFC-3588 [6.2] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D - The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Any comments.. Thanks & Regards, Biplab --=-Rzl5PMHltzT6XeM9kTkC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi All,

I would suggest some enhancements to the ABNF representation of the diamete= r messages to indicate the "Mandatory Exclusion" of certain AVPs = in some messages.
The following type of information should be captured in the messages descri= ption ABNF. (Say by using negative "max" count ).

=3D=3D=3D=3D=3D=3D=3D=3D RFC-3588 [6.2] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
   -  The Destination-Host and Destination-Realm AVPs MUST N= OT be
      present in the answer message.

  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Any comments..

Thanks & Regards,
Biplab --=-Rzl5PMHltzT6XeM9kTkC-- --=-Rw6BraCd0InFtcinN3Pj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIskXx3rQBTW1UPu4RAv0EAJ9IQxT9WcnKBK/8pN+k4DOEFvsrMQCfSgFk 1tbQsU5iL3k/PtB13UAJY84= =aSbA -----END PGP SIGNATURE----- --=-Rw6BraCd0InFtcinN3Pj-- --===============0899091358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0899091358==-- From dime-bounces@ietf.org Sun Aug 24 23:49:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90FDE3A67E7; Sun, 24 Aug 2008 23:49:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5AE3A67E7 for ; Sun, 24 Aug 2008 23:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1GhgsAYtTjC for ; Sun, 24 Aug 2008 23:49:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4A9913A6949 for ; Sun, 24 Aug 2008 23:49:23 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7P6WKAt021554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 08:32:20 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7P6WJBK005109; Mon, 25 Aug 2008 08:32:19 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 08:32:20 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 08:32:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 09:32:17 +0300 Message-ID: In-Reply-To: <1219642865.8316.9.camel@INDBNG1172.bng.ind.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] ABNF Thread-Index: AckGdi5yVInWRR9aQrm7vIiZ1CIRhwABL/vA References: <1219642865.8316.9.camel@INDBNG1172.bng.ind.starentnetworks.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , "dime" X-OriginalArrivalTime: 25 Aug 2008 06:32:19.0713 (UTC) FILETIME=[5320A710:01C9067C] Subject: Re: [Dime] ABNF X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Biplab, In some sense we should focus on the stuff that has to be present in the message since with the Diameter extensibility mechanisms you cannot really tell ahead of time what other AVPs will be present in the future anyway. Hence, as a protocol designer you can really only work with the following two things: * required AVPs (in the ABNF) as information that is important for the sender to include * mandatory AVPs (the stuff with the M-bit) as information that is important for the receiver to understand. The mentioned case (pointing to Section 6.2) is, however, an interesting one since this is a rather generic statement about Diameter message processing since otherwise I would have said that one should reflect these aspects in the ABNF by defining new commands. In some sense you are asking for a more formal way to describe things that are currently presented in the text of the specification itself rather than in the ABNF. ABNF isn't all that great when it comes to conditional features (unless you define all sorts of new commands for every stuff, which isn't really practical or readable either). If we introduce new formalism into the ABNF itself then we run into a lot of problems with backward compatibilty since there are a lot of Diameter specifications out there already. Protocol designers extending Diameter could, however, experiment with better ways to capture the functionality of a specification. Maybe there are ways to capture conditional behavior a bit better; for example by using pseudocode. Ciao Hannes ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext Sarkar Biplab Sent: 25 August, 2008 08:41 To: dime Subject: [Dime] ABNF Hi All, I would suggest some enhancements to the ABNF representation of the diameter messages to indicate the "Mandatory Exclusion" of certain AVPs in some messages. The following type of information should be captured in the messages description ABNF. (Say by using negative "max" count ). ======== RFC-3588 [6.2] =================== - The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message. ================================== Any comments.. Thanks & Regards, Biplab _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 24 23:58:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC193A67E6; Sun, 24 Aug 2008 23:58:05 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37963A68AB for ; Sun, 24 Aug 2008 23:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=1.277, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtO8I12V9t+x for ; Sun, 24 Aug 2008 23:58:03 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id A812B3A65A6 for ; Sun, 24 Aug 2008 23:58:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,264,1217822400"; d="scan'208";a="140890995" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 25 Aug 2008 02:56:38 -0400 X-IronPort-AV: E=Sophos;i="4.32,264,1217822400"; d="scan'208";a="265846443" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Aug 2008 02:56:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 08:55:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt Thread-Index: AckGOS40IcZb/hrVSt+vCJWKrPRWfQARg7Og From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org DIME WG, Please take into consideration the following comment from Brian Carpenter made as part of his review for draft-sun-dime-itu-t-rw-01.txt, which is for approval on the agenda of the IESG telechat this week. Comments about Brian's observation and other comments concerning the document are welcome. Thanks and Regards, Dan -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] Sent: Monday, August 25, 2008 1:32 AM To: General Area Review Team Cc: Romascanu, Dan (Dan); draft-sun-dime-itu-t-rw@tools.ietf.org; dime-chairs@tools.ietf.org Subject: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-sun-dime-itu-t-rw-01.txt Reviewer: Brian Carpenter Review Date: 2008-08-25 IESG Telechat date: 2008-08-28 Summary: Ready Comments: No issues with this document. However, while reviewing it, I did discover that the DIAMETER community has systematically deviated from the statement in the IANA Considerations of RFC3588: "Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting." It seems that numerous allocations have in fact been made outside the scope of AAA (strictly interpreted). I suggest that draft-ietf-dime-rfc3588bis needs to discuss this rather than just leaving the "SHOULD NOT" untouched. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 24 23:58:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489AF3A6975; Sun, 24 Aug 2008 23:58:05 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9C53A65A6 for ; Sun, 24 Aug 2008 23:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRhPRAveelqw for ; Sun, 24 Aug 2008 23:58:04 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D44413A67E6 for ; Sun, 24 Aug 2008 23:58:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,264,1217822400"; d="scan'208";a="140890996" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 25 Aug 2008 02:56:39 -0400 X-IronPort-AV: E=Sophos;i="4.32,264,1217822400"; d="scan'208";a="265846445" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Aug 2008 02:56:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 08:56:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt Thread-Index: AckGOS40IcZb/hrVSt+vCJWKrPRWfQARg7Og From: "Romascanu, Dan (Dan)" To: Cc: Brian E Carpenter Subject: [Dime] FW: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org DIME WG, (also copying Brian) Please take into consideration the following comment from Brian Carpenter made as part of his review for draft-sun-dime-itu-t-rw-01.txt, which is for approval on the agenda of the IESG telechat this week. Comments about Brian's observation and other comments concerning the document are welcome. Thanks and Regards, Dan -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] Sent: Monday, August 25, 2008 1:32 AM To: General Area Review Team Cc: Romascanu, Dan (Dan); draft-sun-dime-itu-t-rw@tools.ietf.org; dime-chairs@tools.ietf.org Subject: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-sun-dime-itu-t-rw-01.txt Reviewer: Brian Carpenter Review Date: 2008-08-25 IESG Telechat date: 2008-08-28 Summary: Ready Comments: No issues with this document. However, while reviewing it, I did discover that the DIAMETER community has systematically deviated from the statement in the IANA Considerations of RFC3588: "Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting." It seems that numerous allocations have in fact been made outside the scope of AAA (strictly interpreted). I suggest that draft-ietf-dime-rfc3588bis needs to discuss this rather than just leaving the "SHOULD NOT" untouched. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 25 00:01:29 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CA83A6A24; Mon, 25 Aug 2008 00:01:29 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91173A6A24 for ; Mon, 25 Aug 2008 00:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cksloIGQD9z for ; Mon, 25 Aug 2008 00:01:27 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7382A3A69D3 for ; Mon, 25 Aug 2008 00:01:27 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7P71HEU025644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 09:01:17 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7P71GRB025933; Mon, 25 Aug 2008 09:01:17 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 09:01:12 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 09:01:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 10:01:10 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt Thread-Index: AckGOS40IcZb/hrVSt+vCJWKrPRWfQARg7OgAAA0hAA= References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 25 Aug 2008 07:01:11.0847 (UTC) FILETIME=[5B8F5370:01C90680] Subject: Re: [Dime] FW: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org There was a discussion with Brian following his review comments. Here is the link to the discussion: http://www.ietf.org/mail-archive/web/gen-art/current/msg03213.html Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Romascanu, Dan (Dan) >Sent: 25 August, 2008 09:56 >To: dime@ietf.org >Subject: [Dime] FW: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt > >DIME WG, > >Please take into consideration the following comment from >Brian Carpenter made as part of his review for >draft-sun-dime-itu-t-rw-01.txt, which is for approval on the >agenda of the IESG telechat this week. >Comments about Brian's observation and other comments >concerning the document are welcome. > >Thanks and Regards, > >Dan > > >-----Original Message----- >From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >Sent: Monday, August 25, 2008 1:32 AM >To: General Area Review Team >Cc: Romascanu, Dan (Dan); draft-sun-dime-itu-t-rw@tools.ietf.org; >dime-chairs@tools.ietf.org >Subject: Gen-ART review of draft-sun-dime-itu-t-rw-01.txt > > >I have been selected as the General Area Review Team (Gen-ART) >reviewer for this draft (for background on Gen-ART, please see >http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >Please wait for direction from your document shepherd >or AD before posting a new version of the draft. > >Document: draft-sun-dime-itu-t-rw-01.txt >Reviewer: Brian Carpenter >Review Date: 2008-08-25 >IESG Telechat date: 2008-08-28 > >Summary: Ready > >Comments: No issues with this document. However, while reviewing it, >I did discover that the DIAMETER community has systematically >deviated from the statement in the IANA Considerations of RFC3588: > > "Diameter is not intended as a general purpose protocol, and > allocations SHOULD NOT be made for purposes unrelated to > authentication, authorization or accounting." > >It seems that numerous allocations have in fact been made outside the >scope >of AAA (strictly interpreted). I suggest that >draft-ietf-dime-rfc3588bis >needs to discuss this rather than just leaving the "SHOULD NOT" >untouched. > > > > > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 26 07:57:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04B83A6ADA; Tue, 26 Aug 2008 07:57:48 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D693A6ADA for ; Tue, 26 Aug 2008 07:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qF+0zWjUIM7 for ; Tue, 26 Aug 2008 07:57:44 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id C42BB3A68DF for ; Tue, 26 Aug 2008 07:57:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,270,1217822400"; d="scan'208";a="132522004" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 26 Aug 2008 10:56:53 -0400 X-IronPort-AV: E=Sophos;i="4.32,270,1217822400"; d="scan'208";a="260075225" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 26 Aug 2008 10:56:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 16:56:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-ietf-dime-mip6-integrated-09.txt Thread-Index: AckHi/kUHwUKg114TlmodMPLK18zlQ== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD Review of draft-ietf-dime-mip6-integrated-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I have reviewed the I-D and I believe that it is in good shape, clear and well written. I have only two issues, and although at least one of them is critical and both will require I believe edits I suggest that we send this document to IETF Last Call while considering my comments together with other comments that may result from the IETF Last Call. Here are my two comments: 1. Section 7.2 includes the following: Following the policies outlined in [1] new values with a description of their semantic for usage with the MIP6-Feature-Vector AVP together with a Token will be assigned after Expert Review initiated by the O&M Area Directors in consultation with the DIME working group chairs or the working group chairs of a designated successor working group. Updates can be provided based on expert approval only. A designated expert will be appointed by the O&M Area Directors. No mechanism to mark entries as "deprecated" is envisioned. Based on expert approval it is possible to delete entries from the registry. [1] is RFC 3775 which says nothing about a registry for mobility capability, and does not recommend Expert Review policy for any other registry. The document needs to find another reference, or synchronize the policy with what is recommended in 3775. In any case, if Expert Review policy is applied, I do not see the need to involve the O&M area directors or the DIME or successors of DIME in initiating a review. As in many other cases I expect that requests will be sent to IANA for new entries in the capabilities registry, and IANA will forward them to the designated expert. Following standard procedures is always better unless there are good reasons to invent something new. 2. Section 2 mentions reference [8] as the source for the additional terms. In reality only the first four terms are borrowed from [8] (which is RFC 4640) while the rest may have different sources or are defined here. Please correct this. Thanks and Regards, Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 26 14:22:40 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F093A68EF; Tue, 26 Aug 2008 14:22:40 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA353A6817 for ; Tue, 26 Aug 2008 14:22:39 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKvjp8j9aY1p for ; Tue, 26 Aug 2008 14:22:38 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 59B363A68EF for ; Tue, 26 Aug 2008 14:22:38 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Tue, 26 Aug 2008 17:22:35 -0400 From: Mark Jones To: "dime@ietf.org" Date: Tue, 26 Aug 2008 17:22:33 -0400 Thread-Topic: Review of rfc3588-bis-11 - Part 1 Thread-Index: AckHwdq4dtl+U1T0RC+dACDZVarzKQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Dime] Review of rfc3588-bis-11 - Part 1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Here is my review of sections 1 to 5 of rfc3588bis. I'll review the remainder of the draft before the end of the week. The majority of my comments are editorial. --- 1.1. Diameter Protocol AVPs may be added arbitrarily to Diameter messages, so long as the requirements of a message's ABNF are met and the ABNF allows for it. The clause "and the ABNF allows for it" appears to be redundant. --- 1.1.3. Changes from RFC3588 s/obselete/obsolete s/fixes state machine/fixes to the state machine/ s/is now shown here/is not shown here/ --- 1.2. Approach to Extensibility s/semantic/semantics/ --- 1.2.3. Creating New Commands A new Command Code has to be allocated when new required AVPs (those indicated as {AVP}) are added, deleted or are redefined (for example by changing a required AVP into an optional one). Suggest rewording to: A new Command Code MUST be allocated when (a) new required AVPs (those indicated as {AVP}) are added or deleted, (b) new mandatory-to-understand AVPs (those with the M-bit set) are added or deleted or (c) existing AVPs are redefined (for example by changing a required AVP into an optional one). --- I suggest clarifying somewhere in this section that the IANA managed Command Code name space is flat, i.e. it is not a per-application name space. The reuse of existing commands in a new application does not free the application designer from the ABNF constraints of the original command. --- 1.2.4. Creating New Diameter Applications If the M-bit is set by the sender and the receiver does not understand the AVP or the values carried within that AVP then a failure is generated (see Section 7). Section 7 describes how receiver deals with a request containing a mandatory-to-understand AVP that it does not understand. Do we specify how a receiver deals with an answer? Terminating the session maybe not always be the desired behaviour. Should we leave it to application to specify? --- Adding an AVP with the M-bit in the MUST column of the AVP flag table to an existing Command/Application requires a new Diameter Application Id to be assigned to that Application. I understand that adding an M-bit AVP requires a new Command but that is not mentioned in this paragraph. It is then this new command that triggers the requirement for a new application. --- Remove the reference to the MAY column (assuming agreement on removal from section 4.5). --- Suggest rewording the note on M-bit setting to: Note: The M-bit setting for a given AVP is specific to an Application and each command within that Application which includes the AVP. That is, if an AVP appears in two commands for application Foo and the M-bit settings are different in each command, then there should be two AVP flag tables describing when to set the M-bit. --- The last paragraph in section 1.2.4 doesn't mention the M-bit which appears to contradict the earlier statement on setting it requiring a new application id. Suggest rewording to remove the contradiction: An implementation MAY add arbitrary optional AVPs with the M-bit cleared to a command defined in an application, including vendor-specific AVPs without needing to define a new application. This can be done if the commands ABNF allows for it. Please refer to Section 11.1.1 for details. --- 1.3. Terminology s/Session-Identifier/Session-Id/ --- 2. Protocol Overview s/support also both/support both/ --- 2.3. Diameter Application Compliance The last paragraph already appears in section 1.2.4. If it is still required here, I suggest rewording "non-mandatory AVPs" to "optional AVPs with the M-bit cleared" for consistency. --- 2.7. Routing Table Inconsistency wrt normative statements in the descriptions of Realm Name and Application Identifier fields: Realm Name is "typically used as primary key" whereas Application Identifier "MUST be used as a secondary key". Why wouldn't the Realm Name be the mandatory primary key? --- 3. Diameter Header Suggest rewording second paragraph describing Application-ID field: The value of the application-id field in the header MUST be the same as any relevant application-id AVPs contained in the message. --- 4.1. AVP Header s/ingnored/ignored/ --- Suggest rewording paragraph on 'M' bit setting to: The 'M' bit MUST be set according to the rules defined in the application specification which introduces or re-uses this AVP. Within a given application, the M-bit setting for an AVP is either defined for all command types or for each command type. --- 4.4. Grouped AVP Values However, the encapsulated AVPs with 'M' (mandatory) bit set MUST belong to the Diameter application the Grouped APV is used in. I don't understand what "belong" means in this sentence. Does it mean new AVPs that are defined in this application? s/APV/AVP/ --- 4.5. Diameter Base Protocol AVPs Strongly suggest removing the MAY column. For the confusion it has caused, it MUST die NOW. --- 5.2. Diameter Peer Discovery s/requestor/requester/ --- 5.3. Capabilities Exchange s/indentifier/identifier/ --- 5.6.5. Capabilities Update A Diameter node MUST initiate peer capabilities update by sending a Capabilities-Exchange-Req (CER) to all its peers which supports peer capabilities update and is in OPEN state. How does the Diameter node know which peers support peer capabilities update? I understood the goal of the bis was to clarify/fix existing functionality so I am surprised we are adding mandatory new functionality. I suggest removing this and instead encourage interested parties to craft a "Peer Capabilities Update" application that can be advertised by CER/CEA. --- Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 27 07:04:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FEBB28C29D; Wed, 27 Aug 2008 07:04:59 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 71C3C28C22B; Wed, 27 Aug 2008 07:04:56 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080827140456.71C3C28C22B@core3.amsl.com> Date: Wed, 27 Aug 2008 07:04:56 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] Last Call: draft-ietf-dime-mip6-integrated (Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-09-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14872&rfc_flag=0 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 27 07:16:29 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F4328C29D; Wed, 27 Aug 2008 07:16:29 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2904B3A6BFE for ; Wed, 27 Aug 2008 07:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vcb6UtQzoOVd for ; Wed, 27 Aug 2008 07:16:22 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 5A83F28C27A for ; Wed, 27 Aug 2008 07:16:21 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 16:16:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 16:16:19 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A2014@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD Review of draft-ietf-dime-mip6-integrated-09.txt Thread-Index: AckHi/kUHwUKg114TlmodMPLK18zlQAwYyPg References: From: To: , X-OriginalArrivalTime: 27 Aug 2008 14:16:23.0101 (UTC) FILETIME=[7BE7FED0:01C9084F] Subject: Re: [Dime] AD Review of draft-ietf-dime-mip6-integrated-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dan, Thank you for the review. See some replies inline. > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Romascanu, Dan (Dan) > Sent: 26. elokuuta 2008 17:57 > To: dime@ietf.org > Subject: [Dime] AD Review of draft-ietf-dime-mip6-integrated-09.txt > > > I have reviewed the I-D and I believe that it is in good shape, clear > and well written. I have only two issues, and although at least one of > them is critical and both will require I believe edits I > suggest that we > send this document to IETF Last Call while considering my comments > together with other comments that may result from the IETF Last Call. > > Here are my two comments: > > 1. Section 7.2 includes the following: > > Following the policies outlined in [1] new values with a > description > of their semantic for usage with the MIP6-Feature-Vector > AVP together > with a Token will be assigned after Expert Review initiated by the > O&M Area Directors in consultation with the DIME working > group chairs > or the working group chairs of a designated successor > working group. > Updates can be provided based on expert approval only. A > designated > expert will be appointed by the O&M Area Directors. No > mechanism to > mark entries as "deprecated" is envisioned. Based on > expert approval > it is possible to delete entries from the registry. > > [1] is RFC 3775 which says nothing about a registry for mobility > capability, and does not recommend Expert Review policy for any other > registry. The document needs to find another reference, or synchronize > the policy with what is recommended in 3775. Right. We need to fix this. I'll propose new text here shortly. > In any case, if Expert Review policy is applied, I do not see the need > to involve the O&M area directors or the DIME or successors of DIME in > initiating a review. As in many other cases I expect that Ok. > requests will > be sent to IANA for new entries in the capabilities registry, and IANA > will forward them to the designated expert. Following standard > procedures is always better unless there are good reasons to invent > something new. Right. > 2. Section 2 mentions reference [8] as the source for the additional > terms. In reality only the first four terms are borrowed from > [8] (which > is RFC 4640) while the rest may have different sources or are defined > here. Please correct this. Good catch. We'll fix this. Cheers, Jouni > Thanks and Regards, > > Dan > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 27 07:42:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557D63A6C26; Wed, 27 Aug 2008 07:42:48 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8023A6C26 for ; Wed, 27 Aug 2008 07:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.255 X-Spam-Level: ** X-Spam-Status: No, score=2.255 tagged_above=-999 required=5 tests=[AWL=4.854, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51IKWt-H401K for ; Wed, 27 Aug 2008 07:42:45 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 7D8143A67A3 for ; Wed, 27 Aug 2008 07:42:45 -0700 (PDT) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7REgiZQ005130; Wed, 27 Aug 2008 10:42:44 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48B567E1.2070101@tari.toshiba.com> Date: Wed, 27 Aug 2008 10:42:41 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Mark Jones References: In-Reply-To: Cc: "dime@ietf.org" Subject: Re: [Dime] Review of rfc3588-bis-11 - Part 1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mark, Thanks for the review. Most of the editorial stuff looks ok to me. Comments inline for the rest: > --- > > 1.2.3. Creating New Commands > > A new Command Code has to be allocated when new required AVPs (those > indicated as {AVP}) are added, deleted or are redefined (for example > by changing a required AVP into an optional one). > > Suggest rewording to: > > A new Command Code MUST be allocated when (a) new required AVPs (those indicated as {AVP}) are added or deleted, (b) new mandatory-to-understand AVPs (those with the M-bit set) are added or deleted or (c) existing AVPs are redefined (for example by changing a required AVP into an optional one). > Just for clarification. Was requirement (b) above something we agreed on in the extensibility design (I'm having problems trying to find a reference for this in the extensibility discussion) ? My understanding was that only ABNF changes and message round-trips triggers a new command code; maybe I'm wrong. Also, (b) seems to imply there is a loose association between M-bit AVPs and ABNF ... something we are trying to avoid. > --- > > I suggest clarifying somewhere in this section that the IANA managed Command Code name space is flat, i.e. it is not a per-application name space. The reuse of existing commands in a new application does not free the application designer from the ABNF constraints of the original command. > Sure. > --- > > 1.2.4. Creating New Diameter Applications > > If the M-bit is set by the sender and the > receiver does not understand the AVP or the values carried within > that AVP then a failure is generated (see Section 7). > > Section 7 describes how receiver deals with a request containing a mandatory-to-understand AVP that it does not understand. Do we specify how a receiver deals with an answer? Terminating the session maybe not always be the desired behaviour. Should we leave it to application to specify? > It is probably better to leave it up to the application to decide. In this way, we don't hinder robust error recovery schemes the application may introduce. > --- > > Adding an AVP with the M-bit in the MUST column of the AVP flag > table to an existing Command/Application requires a new Diameter > Application Id to be assigned to that Application. > > I understand that adding an M-bit AVP requires a new Command but that is not mentioned in this paragraph. It is then this new command that triggers the requirement for a new application. > See above. > --- > > Remove the reference to the MAY column (assuming agreement on removal from section 4.5). > I'm still waiting for any objections on the MAY column removal. Hannes ? > --- > > Suggest rewording the note on M-bit setting to: > > Note: The M-bit setting for a given AVP is specific to an Application and each command within that Application which includes the AVP. That is, if an AVP appears in two commands for application Foo and the M-bit settings are different in each command, then there should be two AVP flag tables describing when to set the M-bit. > Sounds good. > --- > > The last paragraph in section 1.2.4 doesn't mention the M-bit which appears to contradict the earlier statement on setting it requiring a new application id. Suggest rewording to remove the contradiction: > > An implementation MAY add arbitrary optional AVPs with the M-bit cleared > to a command defined in an application, including vendor-specific AVPs > without needing to define a new application. This can be done if the > commands ABNF allows for it. Please refer to Section 11.1.1 for > details. > Ok. > 2.3. Diameter Application Compliance > > The last paragraph already appears in section 1.2.4. If it is still required here, I suggest rewording "non-mandatory AVPs" to "optional AVPs with the M-bit cleared" for consistency. > Ok. > --- > > 2.7. Routing Table > > Inconsistency wrt normative statements in the descriptions of Realm Name and Application Identifier fields: Realm Name is "typically used as primary key" whereas Application Identifier "MUST be used as a secondary key". Why wouldn't the Realm Name be the mandatory primary key? > Good catch. > --- > > 3. Diameter Header > > Suggest rewording second paragraph describing Application-ID field: > > The value of the application-id field in the header MUST be the > same as any relevant application-id AVPs contained in the message. > > --- > Ok. > Suggest rewording paragraph on 'M' bit setting to: > > The 'M' bit MUST be set according to the rules defined in the > application specification which introduces or re-uses this AVP. > Within a given application, the M-bit setting for an AVP is either > defined for all command types or for each command type. > Ok. > 4.4. Grouped AVP Values > > However, the encapsulated AVPs with 'M' (mandatory) bit set MUST > belong to the Diameter application the Grouped APV is used in. > > I don't understand what "belong" means in this sentence. Does it mean new AVPs that are defined in this application? > I don't understand that sentence either. I suggest to remove it since if the grouped AVP with M bit is received and understood by the app then it applies that the app already understands the sematics/usage/presence of the encapsulated AVPs. > --- > > 4.5. Diameter Base Protocol AVPs > > Strongly suggest removing the MAY column. For the confusion it has caused, it MUST die NOW. > See above :):):) > --- > > 5.6.5. Capabilities Update > > A Diameter node MUST initiate peer capabilities update by sending a > Capabilities-Exchange-Req (CER) to all its peers which supports peer > capabilities update and is in OPEN state. > > How does the Diameter node know which peers support peer capabilities update? I understood the goal of the bis was to clarify/fix existing functionality so I am surprised we are adding mandatory new functionality. I suggest removing this and instead encourage interested parties to craft a "Peer Capabilities Update" application that can be advertised by CER/CEA. > The problem is actually the opposite of what you describe. The capabilities update has always been in the statemachine in RFC3588 and everybody was trying to implement it but nobody knows exactly what it was suppose to do (see notes from the very first interop). The text in 11 was proposed by implementors as an "easy" way to negotiate through issue ... if folks REALLY want to create a new capabilities update then I would agree with your suggestion with some exceptions: a) keep this current text for backward compatibility with existing implementation b) write a new extension application c) use a different command code instead of CER/CEA -- victor > --- > > Regards > Mark > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 27 11:40:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9B13A6C72; Wed, 27 Aug 2008 11:40:55 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C333A3A6C53 for ; Wed, 27 Aug 2008 11:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCGBh1refk9s for ; Wed, 27 Aug 2008 11:40:53 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id D3D403A6C72 for ; Wed, 27 Aug 2008 11:40:52 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Wed, 27 Aug 2008 14:40:50 -0400 From: Mark Jones To: "dime@ietf.org" Date: Wed, 27 Aug 2008 14:40:48 -0400 Thread-Topic: Peer Capabilities Update Thread-Index: AckIUzbIXs816IhHQqm9qa3NDad5FgABtrRQ Message-ID: References: <48B567E1.2070101@tari.toshiba.com> In-Reply-To: <48B567E1.2070101@tari.toshiba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] Peer Capabilities Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org (Message subject changed to focus discussion...) Hi Victor, Comments inline... > > 5.6.5. Capabilities Update > > > > A Diameter node MUST initiate peer capabilities update > by sending a > > Capabilities-Exchange-Req (CER) to all its peers which > supports peer > > capabilities update and is in OPEN state. > > > > How does the Diameter node know which peers support peer > capabilities update? I understood the goal of the bis was to > clarify/fix existing functionality so I am surprised we are > adding mandatory new functionality. I suggest removing this > and instead encourage interested parties to craft a "Peer > Capabilities Update" application that can be advertised by CER/CEA. > > > > The problem is actually the opposite of what you describe. The > capabilities update has always been in the statemachine in RFC3588 and > everybody was trying to implement it but nobody knows exactly what it > was suppose to do (see notes from the very first interop). The text in > 11 was proposed by implementors as an "easy" way to negotiate through > issue ... > I undestood that the capabilities update was allowed due to an oversight in the original RFC3588 state machine. Since nobody knows exactly what it was supposed to do, my guess is that the implementations out there either don't support capabilities update at all or don't support it in an interopable fashion. Given this starting point, maybe an easier way to negotiate the issue would be to remove it from the state machine in 3588bis, i.e. no CER/CEA in open state. > if folks REALLY want to create a new capabilities update then I would > agree with your suggestion with some exceptions: a) keep this current > text for backward compatibility with existing implementation > b) write a > new extension application c) use a different command code instead of > CER/CEA > I agree with (b) and (c). Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 27 12:42:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA273A6C8D; Wed, 27 Aug 2008 12:42:01 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4AB83A6C84 for ; Wed, 27 Aug 2008 12:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[AWL=2.427, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqhoUHCbV4HR for ; Wed, 27 Aug 2008 12:41:56 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 6EE503A6A17 for ; Wed, 27 Aug 2008 12:41:56 -0700 (PDT) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7RJft6g006598; Wed, 27 Aug 2008 15:41:55 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48B5AE02.7030106@tari.toshiba.com> Date: Wed, 27 Aug 2008 15:41:54 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Mark Jones References: <48B567E1.2070101@tari.toshiba.com> In-Reply-To: Cc: "dime@ietf.org" Subject: Re: [Dime] Peer Capabilities Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mark, > I undestood that the capabilities update was allowed due to an oversight in the original RFC3588 state machine. Since nobody knows exactly what it was supposed to do, my guess is that the implementations out there either don't support capabilities update at all or don't support it in an interopable fashion. Given this starting point, maybe an easier way to negotiate the issue would be to remove it from the state machine in 3588bis, i.e. no CER/CEA in open state. > I hoping bis has enough changes to justify discarding earlier agreements with early diameter adaptors/implementors; i.e. updating to bis-12 will mandate changes to the base diameter stack implementation regardless. In which case, I'm ok with removing capabilities update from this document. Any opinions ? -- victor > >> if folks REALLY want to create a new capabilities update then I would >> agree with your suggestion with some exceptions: a) keep this current >> text for backward compatibility with existing implementation >> b) write a >> new extension application c) use a different command code instead of >> CER/CEA >> >> > > I agree with (b) and (c). > > Regards > Mark > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 27 22:03:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E9A3A6932; Wed, 27 Aug 2008 22:03:13 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20E23A6952 for ; Wed, 27 Aug 2008 22:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJRKiaalVnl4 for ; Wed, 27 Aug 2008 22:03:11 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 9C96F3A6932 for ; Wed, 27 Aug 2008 22:03:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 1FD6BA8089; Thu, 28 Aug 2008 01:03:08 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02703-01; Thu, 28 Aug 2008 01:02:58 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 28 Aug 2008 01:02:58 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 01:01:06 -0400 Received: from [10.6.7.67] ([10.6.7.67]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 10:31:02 +0530 From: Sarkar Biplab To: Victor Fajardo In-Reply-To: <48B5AE02.7030106@tari.toshiba.com> References: <48B567E1.2070101@tari.toshiba.com> <48B5AE02.7030106@tari.toshiba.com> Date: Thu, 28 Aug 2008 10:31:02 +0530 Message-Id: <1219899662.8102.54.camel@INDBNG1172.bng.ind.starentnetworks.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 28 Aug 2008 05:01:02.0866 (UTC) FILETIME=[11E95F20:01C908CB] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: Mark Jones , "dime@ietf.org" Subject: Re: [Dime] Peer Capabilities Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1323272793==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1323272793== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-phb4V37W12pe0S2WX4yU" --=-phb4V37W12pe0S2WX4yU Content-Type: multipart/alternative; boundary="=-pSo2N+vR0RtTwvEtI8Cd" --=-pSo2N+vR0RtTwvEtI8Cd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi All, I think in case we change the base diameter stack implementation we might also have to change the diameter message version number. Thanks Biplab On Wed, 2008-08-27 at 15:41 -0400, Victor Fajardo wrote: > Hi Mark, >=20 > > I undestood that the capabilities update was allowed due to an oversigh= t in the original RFC3588 state machine. Since nobody knows exactly what it= was supposed to do, my guess is that the implementations out there either = don't support capabilities update at all or don't support it in an interopa= ble fashion. Given this starting point, maybe an easier way to negotiate th= e issue would be to remove it from the state machine in 3588bis, i.e. no CE= R/CEA in open state. > > =20 >=20 > I hoping bis has enough changes to justify discarding earlier agreements=20 > with early diameter adaptors/implementors; i.e. updating to bis-12 will=20 > mandate changes to the base diameter stack implementation regardless. In=20 > which case, I'm ok with removing capabilities update from this document. >=20 > Any opinions ? >=20 > -- victor >=20 > > =20 > >> if folks REALLY want to create a new capabilities update then I would > >> agree with your suggestion with some exceptions: a) keep this current > >> text for backward compatibility with existing implementation > >> b) write a > >> new extension application c) use a different command code instead of > >> CER/CEA > >> > >> =20 > > > > I agree with (b) and (c). > > > > Regards > > Mark > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > =20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=-pSo2N+vR0RtTwvEtI8Cd Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All,

I think in case we change the base diameter stack implementation we might a= lso have to change the diameter message version number.

Thanks
Biplab

On Wed, 2008-08-27 at 15:41 -0400, Victor Fajardo wrote: 
Hi Mark,

> I undestood that the capabilities update was allowed due to an oversig=
ht in the original RFC3588 state machine. Since nobody knows exactly what i=
t was supposed to do, my guess is that the implementations out there either=
 don't support capabilities update at all or don't support it in an interop=
able fashion. Given this starting point, maybe an easier way to negotiate t=
he issue would be to remove it from the state machine in 3588bis, i.e. no C=
ER/CEA in open state.
>  =20

I hoping bis has enough changes to justify discarding earlier agreements=20
with early diameter adaptors/implementors; i.e. updating to bis-12 will=20
mandate changes to the base diameter stack implementation regardless. In=20
which case, I'm ok with removing capabilities update from this document.

Any opinions ?

-- victor

>  =20
>> if folks REALLY want to create a new capabilities update then I wo=
uld
>> agree with your suggestion with some exceptions: a) keep this curr=
ent
>> text for backward compatibility with existing implementation
>> b) write a
>> new extension application c) use a different command code instead =
of
>> CER/CEA
>>
>>    =20
>
> I agree with (b) and (c).
>
> Regards
> Mark
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.iet=
f.org/mailman/listinfo/dime
>
>
>  =20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org=
/mailman/listinfo/dime
--=-pSo2N+vR0RtTwvEtI8Cd-- --=-phb4V37W12pe0S2WX4yU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBItjEO3rQBTW1UPu4RAshMAJ9cdOzC82hzeUjiag0MsvMa0VK/SwCg26NC HDqzHuk3n6ZdKsb0tZytVlE= =wSSI -----END PGP SIGNATURE----- --=-phb4V37W12pe0S2WX4yU-- --===============1323272793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1323272793==-- From dime-bounces@ietf.org Thu Aug 28 02:57:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754AF3A69D8; Thu, 28 Aug 2008 02:57:30 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CFD3A67E5 for ; Thu, 28 Aug 2008 02:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iun+-+MLfSOw for ; Thu, 28 Aug 2008 02:57:28 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 1A3553A6A65 for ; Thu, 28 Aug 2008 02:57:26 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id 7ls21a00B0mlR8UA6lx3vy; Thu, 28 Aug 2008 09:57:03 +0000 Received: from gwzPC ([124.121.211.79]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id 7lwE1a0021jLGTg8Xlwh4J; Thu, 28 Aug 2008 09:56:58 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=CDJZTlEY6oavRJqIPy0A:9 a=2p7h9lysDlhRWa0ywQkA:7 a=AsPA0qo6L4DHO7iyOjvD0cshN6EA:4 a=lZB815dzVvQA:10 a=EI1Y7BXnmVQA:10 From: "Glen Zorn" To: "'Victor Fajardo'" References: <48B567E1.2070101@tari.toshiba.com> <48B5AE02.7030106@tari.toshiba.com> In-Reply-To: <48B5AE02.7030106@tari.toshiba.com> Date: Thu, 28 Aug 2008 16:56:10 +0700 Message-ID: <007c01c908f4$5b276280$11762780$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckIfPxhtb6AtSoyTxiEUFUrHBxGWQAdr8fw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Peer Capabilities Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Victor Fajardo writes: > Hi Mark, > > > I undestood that the capabilities update was allowed due to an > oversight in the original RFC3588 state machine. Since nobody knows > exactly what it was supposed to do, my guess is that the > implementations out there either don't support capabilities update at > all or don't support it in an interopable fashion. Given this starting > point, maybe an easier way to negotiate the issue would be to remove it > from the state machine in 3588bis, i.e. no CER/CEA in open state. > > > > I hoping bis has enough changes to justify discarding earlier > agreements > with early diameter adaptors/implementors; i.e. updating to bis-12 will > mandate changes to the base diameter stack implementation regardless. Then don't we need to change the version number in the header? > In > which case, I'm ok with removing capabilities update from this > document. If capabilities update is removed, would we still have to change the version? > > Any opinions ? > > -- victor > > > > >> if folks REALLY want to create a new capabilities update then I > would > >> agree with your suggestion with some exceptions: a) keep this > current > >> text for backward compatibility with existing implementation > >> b) write a > >> new extension application c) use a different command code instead of > >> CER/CEA > >> > >> > > > > I agree with (b) and (c). > > > > Regards > > Mark > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 28 06:00:33 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3D9928C2C0; Thu, 28 Aug 2008 06:00:33 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACC928C2B4; Thu, 28 Aug 2008 06:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq0c3G8ZsZRu; Thu, 28 Aug 2008 06:00:31 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 3AF903A686B; Thu, 28 Aug 2008 06:00:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,286,1217822400"; d="scan'208";a="141422827" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 28 Aug 2008 09:00:31 -0400 X-IronPort-AV: E=Sophos;i="4.32,286,1217822400"; d="scan'208";a="261245641" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Aug 2008 09:00:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 15:00:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of dime-qos-parameters-06.txt Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3Kw== From: "Romascanu, Dan (Dan)" To: Cc: aaa-doctors@ietf.org Subject: [Dime] AD Review of dime-qos-parameters-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, This is the AD review of dime-qos-parameters-06.txt. I believe that the document needs more work before it can be sent to IETF Last Call. I am placing it in Revised ID Needed. 1. Although it is the work of the DIME Working Group, the document includes in its scope according to the Introduction section the definition of parameters that can be reused for conveying QoS information within RADIUS and Diameter. I believe that there is a need to add text that shows how specifically these parameters will be used in each of the two protocols. Is there a need for any supplementary documents to describe protocol specific mapping and IANA allocations? 2. Was the document reviewed by the RADIUS WG? 3. This document will trigger again the issue of exceeding the AAA scope of DIAMETER as described by RFC 3588, raised in a number of previous occasions, last by Brian Carpenter in his GenART review for draft-sun-dime-itu-t-rw. I suggest to put text in the Introduction section mentioning the issue of scope and referring to rfc3588bis as an Informational Reference. 4. There are several places in the document where the authors seem to write requirements about the behavior and mode of provisioning of a QoS enabled network. I do not think that an AAA parameters document is a good place for such requirements. I would strongly prefer that the document focuses on describing the QoS parameters carried by AAA protocols, and if examples of usage are left, they be marked clearly as examples. 5. Section 3.2 - Path PLR and Path PER are defined on packet basis, so the claim that they describe the desired bit error rate seems odd. 6. Same -'where the PLR is defined to be the PLR added by each such node' and 'the PER is defined to be the PER added by each such node' seem to be broken as definitions - maybe that was intended to be define is 'the Path PLR' and 'the Path PER' respectively. 7. Section 3.3 - See comment #4 - certainly RFC 2119 keywords usage seems unjustified here. 8. Section 4.1 and following - it would be good to mention that Length all over this document is expressed in 32-bit words. 9. It is not clear why there is a need to defined both TMOD-1 and TMOD-2. I suggest to add an explanation. 10. Section 4.2 - I suggest to add a normative reference to IEEE 754 when referring the first time to single-precision IEEE floating point format. It's a good moment, as the IEEE standard was updated in June 2008, after more than two decades of usage of the precedent version (but this does not affect the way it is used here as far as I can tell) 11. The first phrase in 4.3 should appear also in 4.2 as the two TMOD parameters have similar semantics. 12. Section 4.5 - there is no reference for the semantic of the Path Jitter parameter value - probably section 3.4 in RFC2215 13. I do not understand what is the reason to include Path Jitter STAT4 (Reserved). 14. Section 4.6 - I do not believe that a AAA document should include statements like 'The total PLR added across all QoS aware nodes can range as high as 10^-1.' 15. Section 4.7 - in the first phrase s/PLR/PER/ 16. Section 4.7 - I do not believe that a AAA document should include statements like 'The total PER added across all QoS aware nodes can range as high as 10^-1.' 17. Section 4.8 - I see no reason to refer here to [RFC2212] 18. Section 4.8 - s/Path PLR/Slack Term/ 19. Section 4.11 - I am not sure that quoting RFC4412 as a reference for the semantic of the parameter value is fully accurate. It may be good at most to say that what is referred here is the resource-priority policy element 20. Section 4.11 - This I-D defines similarly ALRP parameter as draft-ietf-tswg-emergency-rsvp and the two documents quote each other with the apparent intent to keep the definitions in sync. However draft-ietf-tswg-emergency-rsvp defines a policy object which is a list of ALRPs, while here there is only one instance. Why the difference? 21. Section 4.11 - if the intent is to keep the definitions here and in draft-ietf-tswg-emergency-rsvp as close as possible what are the ALRP Priority and Reserved octets positions inversed in the two definitions? 22. Section 4.12 should have a reference to the IANA registry required to be defined for this parameter in Section 6.3. 23. Section 4.12 - what is 'the QoS Desired' object defined here? 24. Section 4.12 includes text about the behavior of the network that looks mis-placed in an AAA document. 25. Section 4.13 could use a reorganization of the description. The 16-bits in the payload have different structure according to the PHB class type - they would better get one generic name and specific descriptions for the three cases covered by the object. 26. Section 4.14 - the semantic described in this section is not identical with the one in RFC 4124 which is provided as reference. 4124 says 0 is a reserved value - what semantics does it have here? It is also not clear why this parameter was defined to have an 8-bit representation 27. Section 4.15 - I strongly advice against presenting the usages of the QoS Class parameters here especially in such firm terms as here. Actually ITU-T Y.1541 Tables 2 and 3 make clear that these class usages are only guidance (classes 1 to 5) and provisional (classes 6,7). This is completely lost here. I would prefer to just provide a pointer to the ITU-T document and take out all the classes descriptions, or move them in an Appendix, with all necessary description of their guidance and provisional status. 28. Section 5 should provide a reference to the IANA registry for Enterprise Numbers 29. Section 6.4 - It is not clear why there is a need to create a registry for DSTE Class Type Parameters. If IETF WGs or individuals writing RFCs and running them through the IETF process will be allowed to add or modify values by Standards Actions, this would modify the semantics defined in Section 4.14, which does not include any mention of extensibility for these parameters. 30. Section 6.5 - It is not clear why there is a need to create a registry for Y.1541 Class Parameters. Who would take the responsibility of running the Standard Action to modify or add Object class values? In what conditions? When Y.1541 changes? In any case, this would modify the semantics defined in Section 4.14, which does not include any mention of extensibility for these parameters. 31. Section 7 - I disagree that this document does not raise any security concerns. Actually the modification or mis-configuration of the QoS parameters carries security threats similar with the configuration operations that would be performed for example in case the objects would be configured by using a protocol like SNMP. QoS degradation may lead to degradation of service that can make access to the network resources difficult or impossible, or running real-time applications impossible. We need text that explains what are the sensitive parameters, and the recommended operational and deployment measures to protect against security threats. 32. The description of the [Y.1541] and [Y/1571] references are incomplete. Thanks and Regards, Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 28 06:23:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E33D28C2C3; Thu, 28 Aug 2008 06:23:03 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5A228C2BB for ; Thu, 28 Aug 2008 06:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2KzDkh5w6fQ for ; Thu, 28 Aug 2008 06:22:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1AEFF28C2C3 for ; Thu, 28 Aug 2008 06:22:55 -0700 (PDT) Received: (qmail 27859 invoked by uid 0); 28 Aug 2008 13:22:57 -0000 Received: from 192.100.124.218 by www109.gmx.net with HTTP; Thu, 28 Aug 2008 15:22:57 +0200 (CEST) Date: Thu, 28 Aug 2008 15:22:57 +0200 From: "Hannes Tschofenig" Message-ID: <20080828132257.62270@gmx.net> MIME-Version: 1.0 To: secdir@mit.edu X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/+OlQnBP/+FvkcRX0qbDc2qyb0KZJrrhPEAsQpwE qliE+b1t3C+Cgo0y63nhgDiO4bCsfj3EfV/g== X-GMX-UID: hZSPcGUtYW0tQZcQo2dpCs58amthc1uo Cc: dime@ietf.org Subject: [Dime] SECDIR Review of draft-sun-dime-itu-t-rw-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I was involved in the work on this document as the DIME working group co-chair. We gave the ITU-T the suggestion to follow this approach of allocating Command Codes and we therefore followed an approach already exercised with http://tools.ietf.org/html/rfc5224. In the security consideration, however, I would add text that mentions the security risk of unauthorized hosts creating, modifying and removing NAT bindings, firewall rules and QoS state as it would severely impact the operational characteristics of a network. Ideas for text can be obtained from http://www.ietf.org/rfc/rfc5190.txt Additional security related info could also be copied from http://www.ietf.org/rfc/rfc3989.txt I believe that this is a fairly minor change and can be done pretty quickly. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 28 06:48:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403CC28C2DC; Thu, 28 Aug 2008 06:48:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262AF28C276 for ; Thu, 28 Aug 2008 06:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[AWL=1.618, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yBebMD+IKNN for ; Thu, 28 Aug 2008 06:48:44 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 05EC63A68D4 for ; Thu, 28 Aug 2008 06:48:43 -0700 (PDT) Received: from [127.0.0.1] (smtp.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7SDmioB010811; Thu, 28 Aug 2008 09:48:44 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48B6ACB4.6000407@tari.toshiba.com> Date: Thu, 28 Aug 2008 09:48:36 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Glen Zorn References: <48B567E1.2070101@tari.toshiba.com> <48B5AE02.7030106@tari.toshiba.com> <007c01c908f4$5b276280$11762780$@net> In-Reply-To: <007c01c908f4$5b276280$11762780$@net> Cc: dime@ietf.org Subject: Re: [Dime] Peer Capabilities Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen, > Victor Fajardo writes: > > >> Hi Mark, >> >> >>> I undestood that the capabilities update was allowed due to an >>> >> oversight in the original RFC3588 state machine. Since nobody knows >> exactly what it was supposed to do, my guess is that the >> implementations out there either don't support capabilities update at >> all or don't support it in an interopable fashion. Given this starting >> point, maybe an easier way to negotiate the issue would be to remove it >> from the state machine in 3588bis, i.e. no CER/CEA in open state. >> >> I hoping bis has enough changes to justify discarding earlier >> agreements >> with early diameter adaptors/implementors; i.e. updating to bis-12 will >> mandate changes to the base diameter stack implementation regardless. >> > > Then don't we need to change the version number in the header? > Hmm.. I think I was mistaken in that statement. So far, implementations has been able to accommodate the bis without the need to rev up the base numbers. So pls dis-regard my comments. > >> In >> which case, I'm ok with removing capabilities update from this >> document. >> > > If capabilities update is removed, would we still have to change the > version? > Good question. I'm hoping not to change the rev. In which case we may need to keep the capabilities update in the bis. Any opinions ? -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 28 06:59:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C435E28C273; Thu, 28 Aug 2008 06:59:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A38628C273 for ; Thu, 28 Aug 2008 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LCkAPb3nnke for ; Thu, 28 Aug 2008 06:59:11 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D14E63A6945 for ; Thu, 28 Aug 2008 06:59:10 -0700 (PDT) Received: (qmail 15555 invoked by uid 0); 28 Aug 2008 13:52:01 -0000 Received: from 192.100.124.218 by www114.gmx.net with HTTP; Thu, 28 Aug 2008 15:52:01 +0200 (CEST) Date: Thu, 28 Aug 2008 15:52:01 +0200 From: "Hannes Tschofenig" Message-ID: <20080828135201.62260@gmx.net> MIME-Version: 1.0 To: aaa-doctors-bounces@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+UK7MWFJCUb33+rskustCHYB4a1nSs+j+230suFY 5MTYDVr4+Un4jKgvy/bW5UiGraRy+VDYCDfg== X-GMX-UID: ztjXLDt5a0A7SZIMtzAzOJo/Njh6dM73 Cc: dime@ietf.org Subject: [Dime] Review of draft-sun-dime-itu-t-rw-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I reviewed draft-sun-dime-itu-t-rw-01 the normative reference: [Q.3303.3] ITU-T Recommendation Q.3303.3, "Resource control protocol no. 3 (rcp3): Protocol at the Rw interface between the Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE): Diameter", 2008. I think it is the right decision to define two new command codes (PIR / PIA) as it is done in [Q.3303.3]. HOWEVER, more command codes must be specified as the ABNF of existing Diameter Base Protocol and Diameter Credit Control Commands has been modified. I therefore request that [Q.3303.3] be changed in the following way since they would cause interoperability problems with existing Diameter Base Protocol and Diameter Credit Control implementations. * CCR Command The ABNF of the original CCR command is modified by removing the required Service-Context-ID AVP. * CCA Command The ABNF of the original CCA command is modified by turning the required Result-Code AVP into an optional one. * RAA Command The ABNF of the original RAA command is modified by turning the required Result-Code AVP into an optional one. * ASR Command The ABNF of the original ASR command is modified by adding the required Abort-Cause AVP. * ASA Command The ABNF of the original ASA command is modified by turning the required Result-Code AVP into an optional one. The simplest way to solve these issues is to register new command codes. Alternatively you could think about why you actually need to modify the ABNF of these commands. Another remark: A couple of tables are listed with AVP flag settings. I got the impression that these flag settings got copied from other documents. This could be a problem since the M-bit (and other flags) meaning is specific for the specific application and command. A new Diameter application/Command may require a different flag setting. I hope that the ITU-T checked this aspect since otherwise they will experience a lot of interop issues. Table 2 is missing indications about the M bit usage. Table 3 is missing indications about the P bit usage. Table 4 is missing indications about the P bit usage. A minor issue: The description about soft-state vs. hard-state was confusing since there is no Reservation-Lifetime AVP specified. Furthermore the text refers to NASREQ and the specification does not use NASREQ. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 28 06:59:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017D428C2D9; Thu, 28 Aug 2008 06:59:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DAC228C273 for ; Thu, 28 Aug 2008 06:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaZkJAVSk-nc for ; Thu, 28 Aug 2008 06:59:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 736F53A6945 for ; Thu, 28 Aug 2008 06:59:43 -0700 (PDT) Received: (qmail 442 invoked by uid 0); 28 Aug 2008 13:52:39 -0000 Received: from 192.100.124.218 by www170.gmx.net with HTTP; Thu, 28 Aug 2008 15:52:39 +0200 (CEST) Date: Thu, 28 Aug 2008 15:52:39 +0200 From: "Hannes Tschofenig" Message-ID: <20080828135239.62230@gmx.net> MIME-Version: 1.0 To: aaa-doctors@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18+trNN8pI+gtUxyeOH+Vrncha+i/onzB30BVcvVY p0zJq3R5ScePREqgnPkTkencfC4jyJGtcBLA== X-GMX-UID: lp+QYGa/Li50BttHqGpp6NdrZml1ZBgF Cc: dime@ietf.org Subject: [Dime] Review of draft-sun-dime-itu-t-rw-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I reviewed draft-sun-dime-itu-t-rw-01 the normative reference: [Q.3303.3] ITU-T Recommendation Q.3303.3, "Resource control protocol no. 3 (rcp3): Protocol at the Rw interface between the Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE): Diameter", 2008. I think it is the right decision to define two new command codes (PIR / PIA) as it is done in [Q.3303.3]. HOWEVER, more command codes must be specified as the ABNF of existing Diameter Base Protocol and Diameter Credit Control Commands has been modified. I therefore request that [Q.3303.3] be changed in the following way since they would cause interoperability problems with existing Diameter Base Protocol and Diameter Credit Control implementations. * CCR Command The ABNF of the original CCR command is modified by removing the required Service-Context-ID AVP. * CCA Command The ABNF of the original CCA command is modified by turning the required Result-Code AVP into an optional one. * RAA Command The ABNF of the original RAA command is modified by turning the required Result-Code AVP into an optional one. * ASR Command The ABNF of the original ASR command is modified by adding the required Abort-Cause AVP. * ASA Command The ABNF of the original ASA command is modified by turning the required Result-Code AVP into an optional one. The simplest way to solve these issues is to register new command codes. Alternatively you could think about why you actually need to modify the ABNF of these commands. Another remark: A couple of tables are listed with AVP flag settings. I got the impression that these flag settings got copied from other documents. This could be a problem since the M-bit (and other flags) meaning is specific for the specific application and command. A new Diameter application/Command may require a different flag setting. I hope that the ITU-T checked this aspect since otherwise they will experience a lot of interop issues. Table 2 is missing indications about the M bit usage. Table 3 is missing indications about the P bit usage. Table 4 is missing indications about the P bit usage. A minor issue: The description about soft-state vs. hard-state was confusing since there is no Reservation-Lifetime AVP specified. Furthermore the text refers to NASREQ and the specification does not use NASREQ. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 28 07:23:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52323A6862; Thu, 28 Aug 2008 07:23:28 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA69A3A680E for ; Thu, 28 Aug 2008 07:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TljscZoxcpAj for ; Thu, 28 Aug 2008 07:23:18 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id B2E363A6C86 for ; Thu, 28 Aug 2008 07:23:17 -0700 (PDT) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7SENGlp012602; Thu, 28 Aug 2008 10:23:16 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48B6B4CD.3090909@tari.toshiba.com> Date: Thu, 28 Aug 2008 10:23:09 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Victor Fajardo References: <48B567E1.2070101@tari.toshiba.com> <48B5AE02.7030106@tari.toshiba.com> <007c01c908f4$5b276280$11762780$@net> <48B6ACB4.6000407@tari.toshiba.com> In-Reply-To: <48B6ACB4.6000407@tari.toshiba.com> Cc: dime@ietf.org Subject: Re: [Dime] Peer Capabilities Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Going through some offline discussion, the consensus seems to be: a) Remove capabilities update completely from bis b) write a new extension application for capabilities update c) use new command code for (b) to negotiate the updates Any opinions/comments ? -- victor > Hi Glen, > > >> Victor Fajardo writes: >> >> >> >>> Hi Mark, >>> >>> >>> >>>> I undestood that the capabilities update was allowed due to an >>>> >>>> >>> oversight in the original RFC3588 state machine. Since nobody knows >>> exactly what it was supposed to do, my guess is that the >>> implementations out there either don't support capabilities update at >>> all or don't support it in an interopable fashion. Given this starting >>> point, maybe an easier way to negotiate the issue would be to remove it >>> from the state machine in 3588bis, i.e. no CER/CEA in open state. >>> >>> I hoping bis has enough changes to justify discarding earlier >>> agreements >>> with early diameter adaptors/implementors; i.e. updating to bis-12 will >>> mandate changes to the base diameter stack implementation regardless. >>> >>> >> Then don't we need to change the version number in the header? >> >> > > Hmm.. I think I was mistaken in that statement. So far, implementations > has been able to accommodate the bis without the need to rev up the base > numbers. So pls dis-regard my comments. > > >> >> >>> In >>> which case, I'm ok with removing capabilities update from this >>> document. >>> >>> >> If capabilities update is removed, would we still have to change the >> version? >> >> > > Good question. I'm hoping not to change the rev. In which case we may > need to keep the capabilities update in the bis. Any opinions ? > > -- victor > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 28 07:50:11 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E5C28C319; Thu, 28 Aug 2008 07:50:11 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B865F28C2FB for ; Thu, 28 Aug 2008 07:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUK5HtpCbgNg for ; Thu, 28 Aug 2008 07:50:06 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9A7E628C316 for ; Thu, 28 Aug 2008 07:50:06 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7SEngQq031816; Thu, 28 Aug 2008 09:50:03 -0500 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 17:49:55 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 09:49:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 09:50:38 -0500 Message-ID: In-Reply-To: <48B6B4CD.3090909@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Peer Capabilities Update thread-index: AckJGalLckaFyQafSPCdKiGVSCEP9AAA7Sjw References: <48B567E1.2070101@tari.toshiba.com> <48B5AE02.7030106@tari.toshiba.com> <007c01c908f4$5b276280$11762780$@net><48B6ACB4.6000407@tari.toshiba.com> <48B6B4CD.3090909@tari.toshiba.com> From: To: X-OriginalArrivalTime: 28 Aug 2008 14:49:53.0276 (UTC) FILETIME=[547A1BC0:01C9091D] X-Nokia-AV: Clean Cc: dime@ietf.org Subject: Re: [Dime] Peer Capabilities Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I agree with this. For what it is worth, this was something we discussed about 4 years ago as well, that Negotiation could be added on as an extension later. John >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Victor Fajardo >Sent: 28 August, 2008 07:23 >To: Victor Fajardo >Cc: dime@ietf.org >Subject: Re: [Dime] Peer Capabilities Update > >Hi, > >Going through some offline discussion, the consensus seems to be: > >a) Remove capabilities update completely from bis >b) write a new extension application for capabilities update >c) use new command code for (b) to negotiate the updates > >Any opinions/comments ? > >-- victor > > > > >> Hi Glen, >> >> >>> Victor Fajardo writes: >>> >>> >>> >>>> Hi Mark, >>>> >>>> >>>> >>>>> I undestood that the capabilities update was allowed due to an >>>>> >>>>> >>>> oversight in the original RFC3588 state machine. Since >nobody knows >>>> exactly what it was supposed to do, my guess is that the >>>> implementations out there either don't support capabilities update >>>> at all or don't support it in an interopable fashion. Given this >>>> starting point, maybe an easier way to negotiate the issue >would be >>>> to remove it from the state machine in 3588bis, i.e. no >CER/CEA in open state. >>>> >>>> I hoping bis has enough changes to justify discarding earlier >>>> agreements with early diameter adaptors/implementors; i.e. >updating >>>> to bis-12 will mandate changes to the base diameter stack >>>> implementation regardless. >>>> >>>> >>> Then don't we need to change the version number in the header? >>> >>> >> >> Hmm.. I think I was mistaken in that statement. So far, >> implementations has been able to accommodate the bis without >the need >> to rev up the base numbers. So pls dis-regard my comments. >> >> >>> >>> >>>> In >>>> which case, I'm ok with removing capabilities update from this >>>> document. >>>> >>>> >>> If capabilities update is removed, would we still have to >change the >>> version? >>> >>> >> >> Good question. I'm hoping not to change the rev. In which >case we may >> need to keep the capabilities update in the bis. Any opinions ? >> >> -- victor >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> >______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> >______________________________________________________________________ >> >> >> > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 28 10:38:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C72428C2A2; Thu, 28 Aug 2008 10:38:10 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442B03A6CC1 for ; Thu, 28 Aug 2008 10:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-gOGGu-U3-w for ; Thu, 28 Aug 2008 10:38:08 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 5AFF33A6CA8 for ; Thu, 28 Aug 2008 10:38:08 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 28 Aug 2008 13:38:10 -0400 From: Mark Jones To: "dime@ietf.org" Date: Thu, 28 Aug 2008 13:38:09 -0400 Thread-Topic: Review of rfc3588-bis-11 - Part 2 Thread-Index: AckJNNYwQYYJcSC0Q2ei637l/HrLvw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Dime] Review of rfc3588-bis-11 - Part 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Here is my review of sections 6 onwards. All comments are editorial except for the question about the DIAMETER_COMMAND_UNSUPPORTED description. --- 6.1.8. Redirecting requests s/againt/against/ --- 6.6. Destination-Realm AVP Second paragraph contains ambiguous "mandatory" usage: Request messages whose ABNF does not list the Destination-Realm AVP as a required AVP are inherently non-routable messages. --- 6.7.4. Proxy-State AVP Suggested rewording: The Proxy-State AVP (AVP Code 33) is of type OctetString, and contains local state information which MUST be treated as opaque data by hosts other than the one identified by the Proxy-Host AVP. --- 6.11. Vendor-Specific-Application-Id AVP s/diameter/Diameter/ --- 7. Error Handling Eighth paragraph contains ambiguous "mandatory" usage: A command is received with an AVP that is omitted, yet is required according to the command's ABNF. --- 7.1.3. Protocol Errors s/Sec 3/Section 3/ --- 7.1.5. Permanent Failures DIAMETER_COMMAND_UNSUPPORTED 5019 The description reads that this MUST be reported when a node receives an experimental command that is does not understand. Shouldn't that be any command that it does not understand? --- 8.20. Class AVP s/used to by/used by/ --- 13.1. TLS Usage s/one ore more/one or more/ s/co-related/correlated/ --- Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Aug 30 16:07:42 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A7A3A6869; Sat, 30 Aug 2008 16:07:42 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E1D3A635F for ; Sat, 30 Aug 2008 16:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.728 X-Spam-Level: X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_05=-1.11, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeIKb6selEtj for ; Sat, 30 Aug 2008 16:07:36 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 7E05D3A6869 for ; Sat, 30 Aug 2008 16:07:36 -0700 (PDT) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m7UN7bdg022785; Sat, 30 Aug 2008 19:07:38 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48B9D2B8.9080805@tari.toshiba.com> Date: Sat, 30 Aug 2008 19:07:36 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Mark Jones References: In-Reply-To: Cc: "dime@ietf.org" Subject: Re: [Dime] Review of rfc3588-bis-11 - Part 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mark, .. really appreciate the review. The editorials are good. Comment inline for the others. > --- > > 6.6. Destination-Realm AVP > > Second paragraph contains ambiguous "mandatory" usage: > > Request messages whose ABNF does not list the Destination-Realm AVP > as a required AVP are inherently non-routable messages. > How about chaging the text to: "An ABNF for a request message that includes the Destination-Realm AVP SHOULD list the Destination-Realm AVP as a required AVP (an AVP indicated as {AVP}) otherwise the message is inherently a non-routable messages." > --- > > 6.7.4. Proxy-State AVP > > Suggested rewording: > > The Proxy-State AVP (AVP Code 33) is of type OctetString, and > contains local state information which MUST be treated as opaque data > by hosts other than the one identified by the Proxy-Host AVP. > How about chaging the text to: "The Proxy-State AVP (AVP Code 33) is of type OctetString. It generally contains information related to the local state of a Diameter node. It MUST be treated as opaque data." > --- > > 7. Error Handling > > Eighth paragraph contains ambiguous "mandatory" usage: > > A command is received with an AVP that is omitted, yet is > required according to the command's ABNF. > We can change to: "A command is received that is missing AVP(s) that are defined as required in the commands ABNF; example are AVPs indicated as {AVP}." > --- > > 7.1.5. Permanent Failures > > DIAMETER_COMMAND_UNSUPPORTED 5019 > > The description reads that this MUST be reported when a node receives an experimental command that is does not understand. Shouldn't that be any command that it does not understand? > > Yes. It should be for any command it does not support. The entire description should change to: "The Request contained a Command-Code that the receiver did not recognize or doest not support." best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime