Subject: [Tsvwg] Capacity-admitted traffic

From: Fred Baker <[email-masked]>
Date: Fri, 22 Feb 2008 20:20:58 -0800

Please find an updated document at

     ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted- 
realtime-dscp-04.txt
     ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted- 
realtime-dscp-diffs.txt
     ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted- 
realtime-dscp.xml

If it is OK with you, I will post Sunday night Taiwan time. If you  
have additional text issues, please send text.

Following that posting, I again request the opening of a WGLC, so  
that we can get a better review and I can clean up whatever might  
remain.

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 23 Feb 2008 11:30:31 +0100

Fred Baker skrev:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted-realtime-dscp-04.txt 
> 
>     
> ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted-realtime-dscp-diffs.txt 
> 
>     
> ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted-realtime-dscp.xml 
> 
> 
> If it is OK with you, I will post Sunday night Taiwan time. If you have 
> additional text issues, please send text.

I still think that this document must be targeting proposed standard 
rather than BCP to register the DSCP.

Section 2.2:
This sentence is strange, extra "the"?

"The central the notion is that when the capacity available for a set of 
variable rate sessions has been	overbooked, traffic may be randomly 
dropped from lower precedence sessions to allow a higher precedence 
session in."

> 
> Following that posting, I again request the opening of a WGLC, so that 
> we can get a better review and I can clean up whatever might remain.

Yes, as soon as we resolved the status and what code-point to use I 
think that is very reasonable.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Sat, 23 Feb 2008 16:55:55 -0800

On Feb 23, 2008, at 2:30 AM, Magnus Westerlund wrote:

>> realtime-dscp-04.txt     ftp://ftpeng.cisco.com/fred/tsvwg/draft- 
>> ietf-tsvwg-admitted-realtime-dscp-diffs.txt     ftp:// 
>> ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted-realtime- 
>> dscp.xml If it is OK with you, I will post Sunday night Taiwan  
>> time. If you have additional text issues, please send text.
>
> I still think that this document must be targeting proposed  
> standard rather than BCP to register the DSCP.

let me ask a question. The Proposed/Draft/Full Standard sequence is  
designed for protocols, while the BCP status is designed for policy  
statements and such. When we designed PPP or OSPF, the expectation  
was that in the course of testing implementations, we would discover  
errors in the documentation or in the protocols and need to update  
them. We expected that implementors would get together to test, and  
that one would be able to report on such tests as was done in RFC  
1246. On the basis of such tests, the protocol would be deemed well- 
enough described and designed that it could be frozen, and that  
independent implementations could be built from the specification.

This document describes a lot, but it *does* exactly one thing. It  
asks IANA for a number. It suggests what that number should be, and  
it gives advice to operators on what is expected when that number is  
used, but at the end of the day, it asks IANA for a number.

If this is made "proposed standard", by what process does it advance  
to "draft standard"?

> "The central the notion is that when the capacity available for a  
> set of variable rate sessions has been	overbooked, traffic may be  
> randomly dropped from lower precedence sessions to allow a higher  
> precedence session in."

ack

> think that is very reasonable.

At your request, I have changed the suggestion to 101100.

I have made a few other changes, all editorial. The diffs remain in  
the same place, but the -04 draft is posted. I'm looking for a WGLC.

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 24 Feb 2008 17:53:19 +0100

Fred Baker skrev:
> statements and such. When we designed PPP or OSPF, the expectation was 
> that in the course of testing implementations, we would discover errors 
> in the documentation or in the protocols and need to update them. We 
> expected that implementors would get together to test, and that one 
> would be able to report on such tests as was done in RFC 1246. On the 
> basis of such tests, the protocol would be deemed well-enough described 
> and designed that it could be frozen, and that independent 
> implementations could be built from the specification.
> 
> This document describes a lot, but it *does* exactly one thing. It asks 
> IANA for a number. It suggests what that number should be, and it gives 
> advice to operators on what is expected when that number is used, but at 
> the end of the day, it asks IANA for a number.
> 
> If this is made "proposed standard", by what process does it advance to 
> "draft standard"?

My main issue with having this as an BCP is that it can't register the 
code-point in that case. That requires standards action as defined by 
RFC 2434.

Also, the description of what the DSCP means is to me a standards 
specification rather than just a best current practice.

I agree that it is hard to test that this mature, other in the sense 
that we can progress it because it is deployed and work. But I don't 
want to get to deep into discussion around the shortcomings of RFC 2026.

> I have made a few other changes, all editorial. The diffs remain in the 
> same place, but the -04 draft is posted. I'm looking for a WGLC.

Okay, but we need to sort out the intended status before a WGLC.

Cheers

Magnus Westerlund

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Feb 2008 03:55:13 +0800

You ARE aware that a BCP is a standard?

OK, I'll make a trade with you. I'll change this to read "proposed  
standard" if you will change RFC 4594 and RFC 5127 to Proposed  
Standard. Then some day I'll figure out how one goes about doing the  
process it takes to move all three to Draft Standard.

Fred

http://www.ietf.org/rfc/rfc4594.txt
4594 Configuration Guidelines for DiffServ Service Classes. J.
      Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044  
bytes)
      (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc5127.txt
5127 Aggregation of DiffServ Service Classes. K. Chan, J. Babiarz, F.
      Baker. February 2008. (Format: TXT=43751 bytes) (Status:
      INFORMATIONAL)

On Feb 25, 2008, at 12:53 AM, Magnus Westerlund wrote:

>> let me ask a question. The Proposed/Draft/Full Standard sequence  
>> is designed for protocols, while the BCP status is designed for  
>> policy statements and such. When we designed PPP or OSPF, the  
>> expectation was that in the course of testing implementations, we  
>> would discover errors in the documentation or in the protocols and  
>> need to update them. We expected that implementors would get  
>> together to test, and that one would be able to report on such  
>> tests as was done in RFC 1246. On the basis of such tests, the  
>> protocol would be deemed well-enough described and designed that  
>> it could be frozen, and that independent implementations could be  
>> built from the specification.
>> asks IANA for a number. It suggests what that number should be,  
>> and it gives advice to operators on what is expected when that  
>> number is used, but at the end of the day, it asks IANA for a number.
>> If this is made "proposed standard", by what process does it  
>> advance to "draft standard"?
>
> My main issue with having this as an BCP is that it can't register  
> the code-point in that case. That requires standards action as  
> defined by RFC 2434.
>
> I agree that it is hard to test that this mature, other in the  
> sense that we can progress it because it is deployed and work. But  
> I don't want to get to deep into discussion around the shortcomings  
> of RFC 2026.
>
>
>>>> Following that posting, I again request the opening of a WGLC,  
>>>> so that we can get a better review and I can clean up whatever  
>>>> might remain.
>>>
>>> Yes, as soon as we resolved the status and what code-point to use  
>>> I think that is very reasonable.
>> I have made a few other changes, all editorial. The diffs remain  
>> in the same place, but the -04 draft is posted. I'm looking for a  
>> WGLC.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Feb 2008 11:56:28 +0100

Hi Fred

> You ARE aware that a BCP is a standard?

Yes, but it isn't Standards Track, and doesn't result in Standard Tracks 
  RFC's which is what RFC 2434 requires for the Standards Action policy, 
which is what has been defined for the DSCP registry.

> standard" if you will change RFC 4594 and RFC 5127 to Proposed Standard. 
> Then some day I'll figure out how one goes about doing the process it 
> takes to move all three to Draft Standard.
> 

I think we can take this discussion in the context as test cases for any 
updates to RFC 2026. I do not think that informational is the right 
category for these diffserv documents.

Cheers

Magnus Westerlund