Subject: [PCN] comments on 3-in-1 PCN encoding

From: <[email-masked]>
Date: Mon, 26 Jul 2010 13:37:32 +0100

a few comments

terminology
you define "PCN encoding" as the process of setting the codepoints, 
- it would be better if you added 'the process of...' [similar to architecture draft definitions]
- you actually use the phrase "PCN encoding" to mean the codepoints (at least sometimes). For example in Figure 2 caption. i'm not sure whether it would be better to define it as the codepoitns rather than the process. or perhaps best, not to bother with a formal terminology definition, and just use wording similar to the baseline encoding rfc.

"This document describes an extension to the baseliens encoding that addsa third PCN marking state..." - Please use a new paragraph - as this is the crucial price of information in the intro. 

penultimate para of S1 seems unnecessary and will probably just confuse people [4 states to encode 3 pcn states]. if people are interested they can read the baseline encoding where this is all explained well.

i'm not sure that S3.1 and 3.2 add much. i think it would be better to skip straight to the stds part of the text. 

3.3 again this hides the important point with explanatory material. 
the key sentence is the last one "PCN may ony be applied in PCN-domains that comply with [ecn-tunnel] or do not use tunnellng". the point would also be useful in the Introduction, and perhaps the abstract as well.
is it appropriate to have some capital letters here? how about
PCN SHOULD be applied in PCN-domains that comply with ... and SHOULD NOT be applied otherwise
??

S5 the first bullet is incomplete. MUST change NM to TM if threshold-meter indicates +and if excess-traffic-meter does not 

S6.1 a better title would be Backwards compatibility with PCN Baseline encoding 
i wouldnt bother with the MUST here. you're really making operational suggestions, as per the following setnence where you say 'required'
the 2nd para could be safely deleted as not relevant. 
similarly in 6.2.3 i wouldn't capitalise SHOULD [especially odd, as the section begins by stating it's Informative and not normative]

thans
phil

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 26 Jul 2010 13:50:32 +0100

This sparks one quick thought inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 26 July 2010 13:38
> To: [email-masked]
> Subject: [PCN] comments on 3-in-1 PCN encoding
> 
> a few comments
> 
> terminology
> - you actually use the phrase "PCN encoding" to mean the codepoints (at
> least sometimes). For example in Figure 2 caption. i'm not sure whether
> it would be better to define it as the codepoitns rather than the
> process. or perhaps best, not to bother with a formal terminology
> definition, and just use wording similar to the baseline encoding rfc.
> 
> "This document describes an extension to the baseliens encoding that
> addsa third PCN marking state..." - Please use a new paragraph - as
> this is the crucial price of information in the intro.
> 
> penultimate para of S1 seems unnecessary and will probably just confuse
> people [4 states to encode 3 pcn states]. if people are interested they
> can read the baseline encoding where this is all explained well.
> 
> i'm not sure that S3.1 and 3.2 add much. i think it would be better to
> skip straight to the stds part of the text.
> 
> the key sentence is the last one "PCN may ony be applied in PCN-domains
> that comply with [ecn-tunnel] or do not use tunnellng". the point would
> also be useful in the Introduction, and perhaps the abstract as well.

I would be tempted to say something like "This encoding only works with
tunnels defined in [ECN-tunnel]. Therefore any tunnels deployed in a
PCN-domain using this encoding MUST comply with [ECN-tunnel]"

You can't have this as a SHOULD - quite simply this won't work with any
other type of tunnel...

And I agree, this is such a key point it needs to be in the introduction as
a minimum and possibly in the abstract even.

> 
> S5 the first bullet is incomplete. MUST change NM to TM if threshold-
> meter indicates +and if excess-traffic-meter does not
> 
> i wouldnt bother with the MUST here. you're really making operational
> suggestions, as per the following setnence where you say 'required'
> similarly in 6.2.3 i wouldn't capitalise SHOULD [especially odd, as the
> section begins by stating it's Informative and not normative]
> 
> thans
> phil
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Mon, 26 Jul 2010 14:08:32 +0100

[phil] clarify - IP tunnels.
i tend to think things that are advice are SHOULDs - "buyer beware" if you do something else. what;s clear is that current IP tunnels would break this encoding, and that it works with the [ecn-tunnel] doc; dont know about other tunnels, if indeed any exist.
anyway, i dont care much - the important thing is that the conditions under which we expect the encoding to work and not to work - these should be made very clear.

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 26 Jul 2010 14:29:33 +0100

> From: [email-masked] [mailto:[email-masked]]
> Sent: 26 July 2010 14:09
> To: [email-masked]; [email-masked]
> Subject: RE: [PCN] comments on 3-in-1 PCN encoding
> 

Good point

> i tend to think things that are advice are SHOULDs - "buyer beware" if
> you do something else. what;s clear is that current IP tunnels would
> break this encoding, and that it works with the [ecn-tunnel] doc; dont
> know about other tunnels, if indeed any exist.
> anyway, i dont care much - the important thing is that the conditions
> under which we expect the encoding to work and not to work - these
> should be made very clear.=

We certainly need to spell out exactly the effect of any non-compliant
tunnel on this encoding (namely that it can both wipe or reset the
markings).