Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes

From: [email-masked]
Date: Mon, 10 Apr 2006 08:13:19 -0400

> I have also NOT seen any disagreement with anyone with the 
> comments that I have provided.
>  
> So, I think that my comments must be accepted.

For the record, with respect to:

> >>>  3.      Similar is the case should be for the DiffServ network. 

I disagree.  For reasons previously discussed on the mailing list and
resolved with the draft authors, a second token bucket is *required*
for full diffserv support, as otherwise AF cannot be signaled.  I
believe the requirement for this second token bucket is specific to
diffserv, necessary for full diffserv support, and that both those
conclusions remain true even though RMD does not need the second
token bucket.  The latter is because RMD is actually signaling a
subset of diffserv, as was pointed out at the meeting and on the list.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 10 Apr 2006 10:06:25 -0400

Hi, Hannes:

It is highly appreciated by all that you are so keen to resolve all the
technical comments.

Kindly see inline [RRR].

Best regards,

Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, April 10, 2006 7:03 AM
To: Roy, Radhika R.
Cc: [email-masked]; [email-masked]
Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes

Hi Roy,

if your review comments are not discussed on the mailing list then it 

does not mean that they must be accepted. You know the IETF process: 

rough consensus (and running code).

Regarding to your comments:

 > 1.      To clarify priority levels: What does it mean it mean? Is it for

 > media? Is it for call (e.g., SIP)? Or, is it for something?

I guess in our discussions we concluded that the priority level does not 

  relate to a SIP call itself (since these priority levels have e2e 

semantic). As such, the priority levels have the same semantic as those 

defined for RSVP.

It might not hurt to add a few lines to the draft to reflect past 

discussions regarding this subject. In fact I was also confused about 

this issue in the past...

[RRR] Yes, this is another BIG issue for us to resolve. It may be right that
we may follow the RSVP path for resolving the priority issues. However, the
RSVP priority levels are not sufficient to resolve the priority levels of
different media knowing the call level priority.

[RRR] The same issue has also been discussed in SIP, SIPPING, and other WGs.
SIP/SIPPING WG was silent about this. I believe that MMUSIC, AVT, and other
WGs that deal with similar issues also did not resolve this.

[RRR] My take will be to suggest as follows: A sub-field may also used
within the call-level priority to have option for different media level
priorities once it is decided to accept the call based on its own priority
level. Let us discuss more on this.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 10 Apr 2006 10:12:19 -0400

Hi, David:

Yes, I agree with you. However, we are talking about different topics, and I
have provided the details in response to Hannes emails. Kindly see those.

Your help will be appreciated to resolve those technical issues.

Best regards,

Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, April 10, 2006 8:13 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes

Thanks,

--David