RE: : [AAA] Comments on Diameter SIP application

Hi, Miguel:
 
I feel that we are close as most of the things are clarified, but still we are not fine tuning our communications well due to lack of finding suitable words for remaining items. 
 
Since it was only techno-editorial, I will presume let us not go another around of clarifications.
 
Thanks a lot!
 
Best regards,
Radhika

________________________________

From: Miguel Garcia [mailto:[email protected]]
Sent: Fri 10/14/2005 2:24 AM
To: Roy, Radhika (AEAD)
Cc: [email protected]
Subject: Re: [AAA-WG]: [AAA] Comments on Diameter SIP application



Hi Radhika:

Inline discussion.

Roy, Radhika (AEAD) wrote:

> Hi, Miguel:
> 
> Thanks for the reply. Still, I like to add few more things as follows keeping the same item numbers:
>
> 1.   
>       Title: How about to suggest the name as follows?: "Diameter Session Initiation Application." Then, you can explain that it is primarily for SIP (RFCs ..), but can also be used for similar applications as indicated in the document, if applicable. Note: Still, "protocol-application" is NOT the right term.

The title of the document is, or pretends to be, "Diameter SIP
application". The only problem is that the RFC Editor does not admit
"SIP", so it has to be expanded. Once it is expanded, we can use
Diameter SIP application elsewhere, including among us.

> 2.   
>       Abstract: See item 1 as stated above.
> 3.   
>       Section 3: You can keep the paragraph if you want. It is better to add as follows: "Similarly, the Diameter application is not related to or does not require other applications."

If I write that text, indicating that Diameter SIP app. is not related
to other applications, then I invalidate the following paragraph that
describes the connection to the Diameter Credit Control application and
says that "is loosely related to the Diameter Credit Control application".

In my opinion, the current text is correct.

> 4.   
>       Figure 1: Did you also check  whether numbers like 1, 2, etc. are there in the boxes? If not, please put these.

Numbers 1 and 2 are within the box that represents "SIP server 1" amd
"SIP server 2".

> 5.   
>       Section 5.3; 3rd Para, 1st sentence (corrected) - add the words at the end of the 1st sentence " ... after selecting the address from the list supplied by the Diameter server."

If I do so, I will add some incorrect information. The previous sentence
indicates that the UAA command contains the list of capabilities that
the SIP server 2 has to have, or the URI that points to SIP server 2 if
that is already chosen. This is the text I am referring to:

    The Diameter
    server answers with a Diameter User-Authorization-Answer (UAA)
    message (step 3), which indicates a list of capabilities that SIP
    server 1 may use to select an appropriate SIP server (SIP server 2)
    and/or a SIP or SIPS URI pointing to SIP server 2.

If I add to the next sentence " ... after selecting the address from the
list supplied by the Diameter server." then I would be removing from the
scene the scenario where SIP server 2 has been already alocated, and
thus, UAA contains its SIP URI.


> 6.   
>       Section 5.3: Agreed.
> 7.   
>       Section 5.4, 9th para: You can add a global statement to clarify along the line what you have just expressed in the text. That explanation will also help a lot.

The text is already there, written in Section 3 that applies to the
whole document:

    This document provides Diameter procedures to implement certain
    required functionality when SIP is the protocol chosen to initiate
    and tear down multimedia sessions or when SIP is used for other non-
    session-related applications.  However, this document does not
    mandate any particular mapping of SIP procedures to Diameter SIP
    application procedures, nor does it mandate any particular sequence
    of events between SIP and Diameter.  This document provides useful
    examples to show the interaction between SIP and the Diameter SIP
    application in order to achieve the desired functionality.


> 8.   
>       Sections 5.5 and 5.6: No comments (It is up to you).
> 9.   
>       Section 5.10: Agreed.
>
> I appreciate your patience.

Thanks a lot,

          Miguel
>
> Best regards,
> Radhika
>
> ________________________________
>
> From: Miguel Garcia [mailto:[email protected]]
> Sent: Thu 10/13/2005 5:13 AM
> To: Roy, Radhika (AEAD)
> Cc: [email protected]
> Subject: Re: [AAA-WG]: [AAA] Comments on Diameter SIP application
>
>
>
> Hi Radhika:
>
> Thanks a lot for your comments, they are within the deadline.
>
> See inline discussions.
>
> Roy, Radhika (AEAD) wrote:
>
>
>>Hi, all:
>>
>>
>>
>>I am sorry to see that the last day for providing comments (editorial)
>>had expired on September 24, 2005. Since comments are techno-editorial,
>>probably RFC editor might see those assuming that it might be helpful.
>>
>>
>>
>>Techno-Editorial Comments on
>>http://people.nokia.net/~miguel/drafts/draft-ietf-aaa-diameter-sip-app-0
>>7-to-09-wide.html draft
>>
>>
>>
>>1.    Title: Let us modify as "Diameter SIP Application." The reason
>>as follows:
>>
>>*         The word "...protocol-application .." does NOT sound correct.
>>
>>*         Note: The word "... application-protocol .." makes sense, but
>>not the reverse one.
>
>
> I am sorry, but it is useless if I do this change, because the RFC
> Editor will expand the term before its publication. The RFC Editor does
> not allow abbreviations in the title of RFCs, other than IP, UDP, TCP.
>
>
>
>>2.    Abstract: Change "Diameter Session Initiation Protocol (SIP)
>>Application" to "Diameter SIP Application." The reason is stated in item
>>1. Note: The following sentence has already spelled "SIP" as "Session
>>Initiation Protocol."
>
>
> Same as above.
>
>
>>3.    Section 3: Remove the 3rd paragraph because it is incomplete
>>when we see the 4th paragraph and replace it with the global statement
>>as follows:
>>
>>*         "The Diameter SIP application is not related to and does not
>>require other Diameter applications."
>
>
> I disagree. This text has been there from the very beginning. The reason
> is that we always get questions about the relation of this application
> with others. The 3rd and 4th paragraphs are technically correct and try
> to clarify the relation of the Diameter SIP, so I want them to stay as
> they are.
>
>
>>4.    Figure 1: Within boxes put "SIP Server/Node" or "SIP Entity"
>>instead of only "SIP." Also put numbers like 1, 2, 3, ... etc. within
>>the boxes to be in consistent with texts written in describing Figure 1.
>
>
> Inside the boxes the text reads "SIP UA" or "SIP server", which are
> correct. The arrows that connect SIP boxes read "SIP", because it
> happens that this is the protocol that runs between those boxes. In my
> opinion, the figure is correct.
>
>
>>5.    Section 5.3: 4th Paragraph - In the end of 2nd sentence, add as
>>follows, .." with the help of Diameter server." This is due to the fact
>>that SIP server 1 cannot locate SIP server 2 all by itself unless
>>Diameter server provides the address of SIP server 2.
>
>
> I wasn't able to add this sentence in a meaninful way, so I may be
> looking at a different 4th paragrah in Section 5.3. Can you please
> indicate what should be the old and the new text, by copying the
> existing sentences (1st and 2nd) ?
>
>
>
>>6.    Section 5.3: 4th Paragraph - Clarify by adding texts that "SIP
>>server 1 needs to find SIP server 2 to route the SIP call to the
>>destination."
>
>
> Same comment as for the location, please provide an anchor of the
> existing text, I don't know where you are looking at.
>
> But anyway, I also disagere with the proposed text, because the scenario
> shows a SIP registration, meaning that there is no SIP call yet, there
> is not destination, etc.
>
>
>>7.     Section 5.4: 9th Paragraph - Clarify by adding texts "What SIP
>>server 2 does if credentials are not valid."
>
>
> You need to understand that the whole Section 5 contains a bunch of
> informative flows that helps the reader to see how SIP and Diameter
> match. It is not the goal of this specification to describe SIP, nor is
> the goal to put normative procedures to SIP and so on. So I am not going
> to consider all the different cases that are possible, including error
> scenarios such as when the credentials are invalid. I would expect the
> reader to refer to RFC 3261 or 2617 for such behavior.
>
>
>>8.    Sections 5.5 and 5.6: General comments - These sections show
>>only one SIP server in all figures where as the previous sections show
>>two SIP servers (edge, within network). Some clarifications need to be
>>added whether or not the Diameter message flows will be different if it
>>is edge SIP server or network-based SIP server.
>
>
> I think the first paragraph in Section 5.5 provides an introduction to
> the scenario, which is different from the previous scenarios where there
> are two SIP servers.
>
>     Figure 4 depicts a typical scenario where a stateless SIP proxy
>     requests authentication information and authorization to a Diameter
>     server, for the purpose of providing SIP routing services to a SIP
>     User Agent.  The SIP proxy server may be configured as an outbound
>     SIP proxy, so that all the requests initiated by the SIP UA traverse
>     the SIP proxy.  In this scenario, nonces are generated in the
>     Diameter server.
>
>
>
>
>>9.    Section 5.10: 2nd Paragraph - Make it clear that "it is an
>>'assumption' that all information/profile/data related to one user
>>remains only in 'one' Diameter server." (Note: It may or may not always
>>be true for different implementation schemes of the large-scale network
>>where Diameter servers will deal with a variety of data. For example,
>>implementation may be such that all users of all applications including
>>SIP may only contact always a "single" logical Diameter server, but all
>>diameter servers will physically distributed across the entire network
>>for providing scalability enhancing performance.)
>>
>
>
> It is already written. The first sentence of the first paragraph in 5.10
> says:
>
>     The basic architecture assumption of this document is that all the
>     data related to a user is stored in a unique Diameter server.
>
>
>>
>>Best regards,
>>
>>Radhika
>>
>>
>
>
> Regards,
>
>           Miguel
> --
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email protected]
> Nokia Research Center      Helsinki, Finland
>
>
>
>

--
Miguel A. Garcia           tel:+358-50-4804586
sip:[email protected]
Nokia Research Center      Helsinki, Finland