Subject: [Dime] Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt

From: Satendra <[email-masked]>
Date: Wed, 20 Dec 2006 19:01:08 +0530

Hi Victor,

1) "Because A2 can advertise that it supports the same application as B2
and has a realm route to B2 ... example is a proxy. We can add a
sentence to that effect if it clarifies this."

A1 from the advertisement can just find out that A2 supports the said
application but can't figure out that A2 is a proxy. Does this mean that
A1 should sent out the message to any peer supporting that application
hoping that it is a proxy ? 

2) I am ok with the idea adding a negative test case for TLS.

Regards,
Satendra

-------- Original Message --------
From: Victor Fajardo <[email-masked]>
To: Satendra <[email-masked]>
Cc: [email-masked], G Nadaf Liyaqatali-a21917 <[email-masked]>
Subject: Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt
Date: Tue, 19 Dec 2006 10:43:13 -0500

Hi Satendra,

Comments inline:

>> o Positive test for establishment of connection advertising the relay
>> app in auth app id, acct app id & VSA.
>>   
>>     
>
> is'nt this already covered ?
>
> Satendra>> Not really, test case does not mention in what avp's relay app id should be accepted.
>   

ok.

>   
>> 5) Section 3.1.1.3: We can use the text in errata draft to specify the 
>> peer behaviour when a DPR is received.
>>   
>>     
>
> Since the errata is still a draft ... I'm not sure if most existing 
> implementation already follows it.
>
> Satendra>> I believe the text in the errata draft is just a clarification 
>            and the behavior can be tested.
>   

... in this specific case, it may not be just a clarification since it 
pertains to re-connection behavior. since it's still a draft we may want 
to be careful on what we mandate.

>   
>> 6) Section 3.1.1.2: 
>> a) The two test cases can be combined to one 
>>    test case.
>>    "Positive test for establishment of connection between 
>>     two peers, one having higher identity than the other.  
>>     Vendor A having a higher identity than vendor B.
>>     Vendor A and vendor B initiate connection, verify that
>>     vendor A initiated connected is closed at both the ends."
>>
>> b) One more test case can be added to verify the behaviour
>>    of TLS in the election scenario.
>>    "Positive test for establishment of connection with TLS between 
>>    two peers,with election scenario, as mentioned above.
>>    vendor B will initiate TLS handshake on vendor B initiated
>>    transport connection."
>>   
>>     
>
> not sure what you mean. My understanding is TLS handshake is independent 
> of election ... is there a specific need to integrate the test ?
>
> Satendra>> The intent was to test who initiates the hand shake, anyway 
>            this case can be left out.
>   

I was thinking that instead of tying it to election, we can simply 
revive your original proposal on capabilities negotiation but in a more 
general tone. i.e. add:

"Negative test case for TLS handshake failure. In the case where the
negotiated Inband-Security involves subsequent TLS negotiation, participants
can simulate a TLS handshake failure (i.e. via invalid certificates, 
TLS/SSL
version mis-match etc) that must result in the peers being disconnected."

what do you think ?

>   
>> 10) Section 3.1.2.1: "Positive test for multi-hop request forwarding.": 
>> A2 should be relay, otherwise A1 will not send the request to it, since
>> neither the dest host or the realm matches. Note that this message has
>> dest host avp. Hence A1 cannot do realm routing.
>> Also, B1 should also be a relay. 
>>   
>>     
>
> mmm... we have two(2) items here.
>
> 1. A2 does not necessarily need to be a relay. We can add either A2 and 
> B1 are relay or has a realm route to B2. We need to give participants 
> flexibility since they might want to test routing functionality that is 
> interesting to them. Mandating one configuration over another may not be 
> helpful.
> 2. Having a dest-host does not automatically preclude that your not 
> going to do realm routing.
>
> Satendra>> Why should peer A1 send out message to A2 when destination is realm B , 
>            and A2 has not advertised itself as a relay ? 
>   

Because A2 can advertise that it supports the same application as B2 and 
has a realm route to B2 ... example is a proxy. We can add a sentence to 
that effect if it clarifies this.

regards,
victor

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 20 Dec 2006 09:31:55 -0500

Hi Satendra,
> hoping that it is a proxy ? 

A1 does'nt care whether A2 is a proxy or not but obviously the 
originator of the message (A1) should have a realm route to realm B via 
A2 :) ... otherwise realm routing would not work even if A2 was 
advertising itself as a relay.

> 2) I am ok with the idea adding a negative test case for TLS.

ok

regards,
victor