Re: : [AAA] Comments on Diameter SIP application

Hi Radhika:

Thanks a lot for your comments, they are within the deadline.

See inline dscussions.

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