Subject: [PCN] tsv-dir review for draft-ietf-pcn-encoding-comparison-06

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 1 Nov 2011 22:09:11 +0200

Hello,

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.

Summary: This draft is ready for publication as an Informational RFC (but see the editorial suggestions below)

Detailed comments:

* Introduction, para 4: "...design and applicability of PCN-based AC and FT." -- AC and FT have not been described (this is only done later, in the next section)

* Sec. 2.2.1, para 3: "If the proportion of re-marked (ThM- and ETM-) PCN traffic is larger than a CLE-limit..." -- CLE-limit is not introduced. It would be good to shortly describe it here, even if it is specified in another PCN document.

* Sec. 3.2.2, title: "Tunneling Rules for the Handling of the DSCP" -- the wording of the title feels inconvenient. For example, would "Tunneling rules for DSCP" be any better (or not)?

* end of sec 3.2.3: "Therefore, option (1) is selected." -- selected for what?

* Sec 3.3 -- it might be useful to shortly tell why it is ok to redefine ECN bits.

* Sec. 4, para 1: "PCN semantics apply only to one or at most two specific DSCPs, and therefore ECN semantics do not apply to them" -- this sentence is a bit difficult to parse. Could it be reworded somehow? The point is to say that ECN semantics do not apply to PCN DSCPs, or what?

* Figure 7 -- Are the PCN-n and PCN-m codepoints specified somewhere? If so, add a reference.

* Sec 4.1, para 2: "The 10-codepoint is reserved for experimental purposes" -- this is not consistent with table 7, where EXP is on 01 - column.

- Pasi

---

From: Michael Menth <[email-masked]>
Date: Wed, 02 Nov 2011 13:24:03 +0100

Hi Georgios,

I went over the doc and suggested changes to address the review 
comments. You find my rewording in the attached pdf. You should have the 
pen, can you please integrate my comments in the doc and possibly 
resubmit it?

> * Sec 3.3 -- it might be useful to shortly tell why it is ok to redefine ECN bits.
Actually, a whole section of the draft is devoted to that issue (3.3.4). But its position was quite late. I rearranged that text to be 3.3.2, right after the review of the ECN field, to make it more visible.

> * Figure 7 -- Are the PCN-n and PCN-m codepoints specified somewhere? If so, add a reference.
I suggest: PCN-n, PCN-m under the DSCP column denotes PCN-compatible DSCPs which may be chosen by the network operator.

Best wishes,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: <[email-masked]>
Date: Wed, 2 Nov 2011 12:57:44 +0000

Wfm
Thanks
phil

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 02 November 2011 12:24
To: [email-masked]
Cc: [email-masked]
Subject: Re: tsv-dir review for draft-ietf-pcn-encoding-comparison-06

Hi Georgios,

I went over the doc and suggested changes to address the review comments. You find my rewording in the attached pdf. You should have the pen, can you please integrate my comments in the doc and possibly resubmit it?

Best wishes,

     Michael

Am 01.11.2011 21:09, schrieb Pasi Sarolahti:
> Summary: This draft is ready for publication as an Informational RFC 
> (but see the editorial suggestions below)
>
>
> Detailed comments:
>
> * Introduction, para 4: "...design and applicability of PCN-based AC 
> and FT." -- AC and FT have not been described (this is only done 
> later, in the next section)
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 4 Nov 2011 12:01:50 +0100

Dear Michael,

Thank you very much!
I will incorporate your comments!

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Menth
> Sent: woensdag 2 november 2011 13:24
> Subject: Re: [PCN] tsv-dir review for
draft-ietf-pcn-encoding-comparison-06
> pen, can you please integrate my comments in the doc and possibly resubmit
> it?
> 
> Actually, a whole section of the draft is devoted to that issue (3.3.4).
But its
> position was quite late. I rearranged that text to be 3.3.2, right after
the
> review of the ECN field, to make it more visible.
> 
> I suggest: PCN-n, PCN-m under the DSCP column denotes PCN-compatible
> DSCPs which may be chosen by the network operator.
> 
> 
> Best wishes,
> 
>      Michael
> 
> > I've reviewed this document as part of the transport area directorate's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
document's
> authors for their information and to allow them to address any issues
raised.
> The authors should consider this review together with any other last-call
> comments they receive. Please always CC [email-masked] if you reply to
or
> forward this review.
> > * Sec. 2.2.1, para 3: "If the proportion of re-marked (ThM- and ETM-)
PCN
> traffic is larger than a CLE-limit..." -- CLE-limit is not introduced. It
would be
> good to shortly describe it here, even if it is specified in another PCN
> document.
> >
> > * Sec. 3.2.2, title: "Tunneling Rules for the Handling of the DSCP" --
the
> wording of the title feels inconvenient. For example, would "Tunneling
rules
> for DSCP" be any better (or not)?
> >
> > * Sec. 4, para 1: "PCN semantics apply only to one or at most two
specific
> DSCPs, and therefore ECN semantics do not apply to them" -- this sentence
is
> a bit difficult to parse. Could it be reworded somehow? The point is to
say
> that ECN semantics do not apply to PCN DSCPs, or what?
> >
> > * Sec 4.1, para 2: "The 10-codepoint is reserved for experimental
purposes"
> -- this is not consistent with table 7, where EXP is on 01 - column.
> >
> > - Pasi
> >
> 
> --

---

From: <[email-masked]>
Date: Sat, 5 Nov 2011 08:02:28 +0000

Hi Pasi,

Thanks for the comments!
We are working them out!

Best regards,
Georgios

________________________________________
Van: [email-masked] [[email-masked]] namens Pasi Sarolahti [[email-masked]]
Verzonden: dinsdag 1 november 2011 21:09
Aan: [email-masked]; [email-masked]
CC: [email-masked]; TSV Dir
Onderwerp: [PCN] tsv-dir review for draft-ietf-pcn-encoding-comparison-06

Hello,

Detailed comments:

- Pasi

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

---

From: Tom Taylor <[email-masked]>
Date: Thu, 10 Nov 2011 19:39:26 -0500

There are further instances of "10 codepoint is experimental" in 
sections 4.2 and 4.5.

On 02/11/2011 8:24 AM, Michael Menth wrote:
> But its position was quite late. I rearranged that text to be 3.3.2,
> right after the review of the ECN field, to make it more visible.
>
>> I've reviewed this document as part of the transport area
>> directorate's ongoing effort to review key IETF documents. These
>> comments were written primarily for the transport area directors, but
>> are copied to the document's authors for their information and to
>> allow them to address any issues raised. The authors should consider
>> this review together with any other last-call comments they receive.
>> Please always CC [email-masked] if you reply to or forward this review.
>>
>> PCN traffic is larger than a CLE-limit..." -- CLE-limit is not
>> introduced. It would be good to shortly describe it here, even if it
>> is specified in another PCN document.
>>
>> the wording of the title feels inconvenient. For example, would
>> "Tunneling rules for DSCP" be any better (or not)?
>>
>> specific DSCPs, and therefore ECN semantics do not apply to them" --
>> this sentence is a bit difficult to parse. Could it be reworded
>> somehow? The point is to say that ECN semantics do not apply to PCN
>> DSCPs, or what?
>>
>> purposes" -- this is not consistent with table 7, where EXP is on 01 -
>> column.
>>
>> - Pasi
>>
>
>
>