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

[Bob Briscoe <[e-mail]>]

James,

Done (Option #3), unless my co-authors would rather choose another option.

You will have seen a manually posted 
draft-ietf-pcn-3-in-1-encoding-10 just appear (at the request of our 
AD). But we will do another rev for changes like this.


Bob

At 21:40 20/03/2012, James M. Polk wrote:
>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
>
>_______________________________________________
>PCN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design