Subject: [Gen-art] A *new* batch of IETF LC reviews - Jan 17th, 2006

From: "Mary Barnes" <[email-masked]>
Date: Tue, 17 Jan 2006 18:24:53 -0600

Here's the latest round of LC assignments:

http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

Thanks,
Mary.

--------------------------- 
Reviewer: Elwyn Davies

- 'L2VPN Extensions for L2TP '
   <draft-ietf-l2tpext-l2vpn-06.txt> as a Proposed Standard

IETF LC ends on 2006-01-23.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2vpn-06.txt

--------------------------- 
Reviewer: Harald Alvestrand

- 'Sieve Extension: Relational Tests '
   <draft-ietf-sieve-3431bis-04.txt> as a Proposed Standard

IETF LC ends on 2006-01-26.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-3431bis-04.txt

--------------------------- 
Reviewer: Joel Halpern

- 'A Resource Reservation Protocol Extension for the Reduction of
Bandwidth of 
   a Reservation Flow '
   <draft-ietf-tsvwg-rsvp-bw-reduction-01.txt> as a Proposed Standard

IETF LC ends on 2006-01-26.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-bw-reduction-0
1.txt

--------------------------- 
Reviewer: Michael Patton

- 'Kerberos Cryptosystem Negotiation Extension '
   <draft-zhu-kerb-enctype-nego-04.txt> as a Proposed Standard

IETF LC ends on 2006-01-27.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-zhu-kerb-enctype-nego-04.txt

--------------------------- 
Reviewer: David Black

- 'Media Type Registration for SMPTE Material Exchange Format (MXF) '
   <draft-edwards-mime-mxf-01.txt> as an Informational RFC

IETF LC ends on 2006-02-07.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-edwards-mime-mxf-01.txt

--------------------------- 

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 21 Jan 2006 22:53:57 -0500

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

This document is ready for publication as a proposed standard.

One minor  (but complicated) question does occur to me reading this 
document.  There are also two nits that should be considered when and if 
there is a need to revise this document.

The minor question is about the possible ill effects of support for this 
extensions.
Suppose that all relevant routers support this extension.
Suppose that there is a router with 40 units of reservation capacity, and 
two low priority flows each of 20 units.
A new high priority request comes in requesting 20 units of capacity.
Without this mechanism, there is no choice.  One of the two low priority 
reservations would be thrown out.
With this extension, the router might decide to ask both existing 
reservations to reduce themselves to 10 units.
If the router could know that the flows could be throttled, this would 
probably be the right thing to do.
However, if the flows can not be throttled, I think this will instead 
result in both flows being thrown off, and then a race to reestablish the 
flows.  Thus, instead of disrupting one flow, two flows will be hurt for a 
time.
I am not sure that is actually what this does.
Even if I am correct, that is not a reason to refrain from publishing 
this.  However, it would suggest a note of caution.

Nit:  In the example in section 3, it is confusing to use Flow A, Flow B 
and Aggregate A (Of Flows 1-5) and Aggregate B (Of flows A-E).  Couldn't 
the aggregates be X and Y (or I and J, or...)
Nit: In the example description in section 3.1, it would be helpful if the 
description of the 880k "offered" said "offered load".  I was confused and 
thought it might mean offered capacity which would be completely backwards.

Yours,
Joel M. Halpern

At 07:24 PM 1/17/2006, Mary Barnes wrote:
>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-bw-reduction-01.txt

---

From: Scott W Brim <[email-masked]>
Date: Mon, 23 Jan 2006 18:33:52 +0100

Looks okay to me --> no obj.

I do wonder about the use of "roadmap".  To me the term means a guide
to where we are going, not to where we are.  For this I would use the
name "overview" or "RFC guide".  I can't fault him, though, since
Brian himself has draft-carpenter-procdoc-roadmap-*.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Jan 2006 15:07:55 +0100

> Brian himself has draft-carpenter-procdoc-roadmap-*.

Which I will probably change in the document itself, since its purpose
seems to be drifting towards "user guide".

Being picky, "roadmap" generally suggest where we *want* to go, not where
we're actually going :-)

    Brian