Re: [PCN] lets try again - a chair asking this time

[<[e-mail]>]

To add to your nit, I think it may be helpful to add something like

"(by default 000000 indicates the best-effort forwarding behaviour)"


-----Original Message-----
From: James M. Polk [mailto:[e-mail]] 
Sent: 20 March 2012 21:40
To: [e-mail]; Eardley,PL,Philip,DUB8 R; [e-mail]; [e-mail]
Subject: Re: [PCN] lets try again - a chair asking this time

I know this is a nit, but shouldn't the text actually read

Option #1  "... re-mark the DSCP to 000000."

or even

Option #2  "... re-mark the DSCP to 0."

or even

Option #3  "... re-mark the DSCP to zero (000000)."

or even

Option #4  "... re-mark the DSCP to zero (0)."

instead of just

   "... re-mark the DSCP to zero."

?

I prefer Option #1, but am happy with Option #3 over the others. IMO 
this should not remain as it is.

James

At 02:25 PM 3/20/2012, [e-mail] wrote:
>Content-Language: nl-NL
>Content-Type: multipart/alternative;
> 
>boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C150D7EXMBX04adutwent_"
>
>Hi all,
>
>
>
>I think that the changes satisfy nicely the comments of Adrian!
>
>
>
>Best regards,
>
>Georgios
>
>
>
>
>
>----------
>Van: [e-mail] [[e-mail]] namens 
>[e-mail] [[e-mail]]
>Verzonden: dinsdag 20 maart 2012 17:46
>Aan: [e-mail]; [e-mail]
>Onderwerp: Re: [PCN] lets try again - a chair asking this time
>
>Seems good to me. I like the inclusion of material previously in 
>both the edge behaviour docs
>
>
>
>From: [e-mail] [mailto:[e-mail]] On Behalf 
>Of Bradner, Scott
>Sent: 20 March 2012 16:37
>To: [e-mail]
>Subject: [PCN] lets try again - a chair asking this time
>
>
>
>please let the list know what you think
>
>
>
>Scott
>
>
>
>Scott O Bradner
>
>Senior Technology Consultant
>
>
>
>Begin forwarded message:
>
>
>
>
>
>Date: Mon, 12 Mar 2012 03:30:11 +0000
>To: "PCN IETF list" <<mailto:[e-mail]>[e-mail]>
>From: Bob Briscoe <<mailto:[e-mail]>[e-mail]>
>Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt
>
>PCN folks,
>
>Following IESG review (particularly Adrian Farrel's being the most 
>comprehensive and useful), we've posted a new version of the PCN 
>3-in-1 encoding.
>
>As well as a number of editorial changes, some technical changes 
>were needed in order to satisfy Adrian's request to specify exactly 
>what an implementer has to do at the ingress to allow ECN to 
>co-exist with PCN, and what defaults should be set to.
>
>In particular, for a non-PCN packet (i.e. doesn't match any 
>flow-state) that clashes with a PCN DSCP and is ECN-capable, the 
>recommended choice of 3 is:
>
>       *  re-mark the DSCP to a DSCP that is not PCN-compatible;
>
>
>
>
>[...]
>
>In the
>
>       absence of any operator-specific
>
>configuration for this case, by
>
>       default an implementation SHOULD re-mark
>
>the DSCP to zero.
>
>
>
>
>Actually, the whole of the ingress behaviour section (5.1) has been 
>re-written, incorporating material that was previously repeated in 
>both edge-behaviours (agreed with IESG and with edge-behaviour 
>authors, of course). Altho it largely does the same thing 
>technically, it is written to cover the complete range of possible 
>scenarios, and it now gives defaults and recommended choices. I 
>don't think it's controversial, but shout if it is.
>< http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 >
>
>
>
>Bob
>
>PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09:
>
>       *  Added note about fail-safe to protect other traffic in the
>          event of tunnel misconfiguration.
>
>       *  Changed section heading to be about applicability of
>          environments to the encoding, rather than the encoding to the
>          environments.
>
>       *  Completely re-wrote PCN-ingress Node Behaviour section.
>
>       *  Changed PCN interior node to PCN-node where the term was
>          intended to include all PCN-nodes.
>
>       *  Clarified status of ECN/PCN co-existence appendix.  Removed
>          inconsistent assertion in this appendix that an admission-
>          control DSCP alone can indicate that arriving traffic is PCN-
>          traffic.
>
>       *  A few clarifying editorial amendments and updated refs.
>
>
>
>
>From: <<mailto:[e-mail]>[e-mail]>
>To: <<mailto:[e-mail]>[e-mail]>,
> 
><<mailto:[e-mail]>[e-mail]>, 
><<mailto:[e-mail]>[e-mail]>,
>         <<mailto:[e-mail]>[e-mail]>, 
> <<mailto:[e-mail]>[e-mail]>
>Date: Sun, 11 Mar 2012 17:52:23 -0700
>Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt
>
>New version (-09) has been submitted for 
>draft-ietf-pcn-3-in-1-encoding-09.txt.
><http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt>http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt 
>
>
>
>Diff from previous version:
><http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09>http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09 
>
>
>IETF Secretariat.
>
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design
>
>
>_______________________________________________
>PCN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcn