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

["Georgios Karagiannis" <[e-mail]>]

Dear Michael,

Thank you very much!
I will incorporate your comments!

Best regards,
Georgios


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Michael Menth
> Sent: woensdag 2 november 2011 13:24
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [PCN] 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?
> 
> The following two comments may need consent:
> 
> > * 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
> 
> Am 01.11.2011 21:09, schrieb Pasi Sarolahti:
> > 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 [e-mail] 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
> >
> 
> --
> 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: [phone]
> fax: [phone]
> mailto:[e-mail]
> http://kn.inf.uni-tuebingen.de