Subject: [Dime] [Fwd: [Fwd: 答复: resubmission draft for capabilities-update-propoblem statment]]

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Aug 2008 17:38:09 +0300

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 <[email-masked]>
To: 	Hannes Tschofenig <[email-masked]>

Subject: 答复: [Dime] resubmission draft for capabilities-update-propoblem statment
From: shan <[email-masked]>
To: "'Victor Fajardo'" <[email-masked]>
Cc: [email-masked]
Date: Thu, 31 Jul 2008 16:53:25 +0800

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:[email-masked]] 
发送时间: 2008年7月30日 17:32
收件人: shan
抄送: [email-masked]
主题: 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>   

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