Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05

Few minor comments:

Table 1 has
>EXP(01)*
>Valid* [in IN EXP(01) OUT PM(11) box]
> * This SHOULD cause an alarm to be raised at a higher layer. The
       packet MUST be treated as if it carried the NM codepoint.

I think your comment ["*This SHOULD.."] really only applies to the "EXP(01)*" - ie if the codepoint in is EXP(01) then raise an alarm as this shouldn't happen.

Both the "Valid" boxes in this row could have a comment:
** these transitions MAY be allowed be some future experimental extensions to the baseline encoding. However a PCN-node that hasn't be upgraded (ie is still doing baseline) mustn't block this so it MUST treat this transition as valid; it MAY also raise an alarm. 
[Not sure " MAY also raise an alarm" is needed, since alarm already raised since EXP(01) is the codepoint in]

> alarm to be raised at a higher layer
is 'higher layer' right? how about "management alarm"?

> A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
   packets it forwards out of the PCN-domain.  The only exception to
   this is if the PCN-egress-node is certain that revealing other
   codepoints outside the PCN-domain won't contravene the guidance given
   in [RFC4774].
I wonder if this needs a bit more explanation about how to do this, or where to find more guidance?

4.3.1
Co-existence of PCN and not-PCN traffic
I wonder if it's worth adding pointer to S3.5 rfc5559 (or draft-ietf-pcn-marking-behaviour Section B.1) which says
>> It is not advised to have competing-non-PCN-traffic but, if there
      is such traffic, there needs to be a mechanism to limit it.
      "Competing-non-PCN-traffic" means traffic that shares a link with
      PCN-traffic and competes for its forwarding bandwidth.  Hence,
      more competing-non-PCN-traffic results in poorer QoS for PCN.
      Further, the unpredictable amount of competing-non-PCN-traffic
      makes the PCN mechanisms less accurate and so reduces PCN's
      ability to protect the QoS of admitted PCN-flows.

5
> The 11 codepoint in the ECN field MUST indicate PCN-marked (though
      this does not exclude the 01 Experimental codepoint from carrying
      the same meaning).
I think better would be " Experimental codepoint from also indicating PCN-marking" [it would indicate a 2nd level of pcn-marking, which you could say is not the "same" meaning]

A.1
The approach & wording is basically good.
>In PCN-domains with uniformly high link rates, the
   appropriate DSCPs would currently be those for the Real Time Traffic
   Class [RFC5127].  To be clear the PCN Working Group recommends using
   admission control for the following service classes:

   o  Telephony (EF)

   o  Real-time interactive (CS4)

   o  Broadcast Video (CS3)

   o  Multimedia Conferencing (AF4)

I think "sufficient aggregation" would be better than "uniformly high link rates" [similarly, "sufficiently" not "highly" in the next para]
" Real Time Traffic Class" - 5127 calls it Treatment Aggregate, at least in Fig 2
you might want to say why CS5 is excluded from pcn (all the other dscps in the RT treatement aggregate are included]
rfc4594 needed as a ref somewhere here as that defines these dscps

Typos etc
Abstract
>This document specifies how such marks are to be encoded
delete 'to be'

4.0 >implementiors

4.2
> There are a number of factors that
   were considered before choosing to set 10
could have a new paragraph before this

4.3.0 
> Thirdly PCN
   should be seen as being essentially a marking behaviour similar to
   ECN but intended for inelastic traffic.  
Re-phrase : Thirdly PCN is not a scheduling behaviour -- rather it should be seen as being essentially a marking behaviour similar to ECN but intended for inelastic traffic.

6
> in decapsulation
'upon' better?

6
> If an
   operator wishes to allow ECN to exist end-to-end they must ensure
   there are no tunnel end-points within the PCN-domain to prevent any
   risk of PCN-markings being exposed to endpoints.
Earlier in the paragraph you talk about a tunnel across the pcn-domain - then there might be another tunnel wholly within the pcn-domain, and this would be ok. (I know what you mean - perhaps slight re-ordering of the para would do the trick)

A.1
>PCn region
PCN-domain

Thanks
phil

{ -----Original Message-----
{ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of
{ toby.moncaster@bt.com
{ Sent: 20 August 2009 16:19
{ To: pcn@ietf.org; lars.eggert@nokia.com
{ Subject: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-
{ encoding-05
{ 
{ I hope this accurately reflects the ML discussions over the past few days?
{ I have also corrected all the nits and hopefully haven't left any spelling
{ mistakes or typos...
{ 
{ Toby
{ 
{ ____________________________________________________________________
{ Toby Moncaster, <toby.moncaster@bt.com> Networks Research Centre, BT
{ B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170
{ 
{ 
{ 
{ -----Original Message-----
{ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
{ Sent: 20 August 2009 16:17
{ To: Moncaster,T,Toby,DER3 R
{ Cc: Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de
{ Subject: New Version Notification for draft-ietf-pcn-baseline-encoding-05
{ 
{ 
{ A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has been
{ successfuly submitted by T Moncaster and posted to the IETF repository.
{ 
{ Filename:	 draft-ietf-pcn-baseline-encoding
{ Revision:	 05
{ Title:		 Baseline Encoding and Transport of Pre-Congestion
{ Information
{ Creation_date:	 2009-08-20
{ WG ID:		 pcn
{ Number_of_pages: 14
{ 
{ Abstract:
{ The objective of Pre-Congestion Notification (PCN) is to protect the
{ quality of service (QoS) of inelastic flows within a Diffserv domain.
{ The overall rate of the PCN-traffic is metered on every link in the
{ PCN-domain, and PCN-packets are appropriately marked when certain
{ configured rates are exceeded.  The level of marking allows the
{ boundary nodes to make decisions about whether to admit or block a
{ new flow request, and (in abnormal circumstances) whether to
{ terminate some of the existing flows, thereby protecting the QoS of
{ previously admitted flows.  This document specifies how such marks
{ are to be encoded into the IP header by re-using the Explicit
{ Congestion Notification (ECN) codepoints within this controlled
{ domain.  The baseline encoding described here provides for only two
{ PCN encoding states, Not-marked and PCN-marked.
{ 
{ 
{ 
{ The IETF Secretariat.
{ 
{ 
{ _______________________________________________
{ PCN mailing list
{ PCN@ietf.org
{ https://www.ietf.org/mailman/listinfo/pcn