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

[Bob Briscoe <[e-mail]>]

Michael & all,

I've submitted this erratum report. It is likely to be referred to 
the PCN ML anyway.


Bob

At 20:36 23/03/2012, Michael Menth wrote:
>That's fine with me.
>
>Michael
>
>Am 23.03.2012 20:29, schrieb Bob Briscoe:
>>Michael,
>>
>>Phil Eardley has suggested this complete re-write, which solves the 
>>problem you point out, and I think makes the whole thing clearer:
>>============================================================================
>>Section 4.2 says:
>>
>>    o  Police - police, by dropping any packets received with a DSCP
>>       indicating PCN transport that do not belong to an admitted flow.
>>       (A prospective PCN-flow that is rejected could be blocked or
>>       admitted into a lower-priority behaviour aggregate.)
>>
>>It should say:
>>
>>    o  Police - drop or re-mark to a lower-priority behaviour aggregate
>>       i) packets received with a DSCP indicating PCN transport that do not
>>       belong to an admitted flow and ii) packets that are part of a flow
>>       that asked to be admitted as a PCN-flow but was rejected.
>>
>>Notes:
>>
>>In the existing text the first sentence contradicts the 
>>parenthesis. It could be interpreted to mean that dropping is the 
>>only allowed policing action, whereas the parenthesis shows that 
>>downgrading was also considered appropriate.
>>
>>Also the existing text used the term 'blocking' as a different 
>>action to 'downgrading', whereas Section 3.6 just above this text 
>>has said '"Blocking" means it is dropped or downgraded to a 
>>lower-priority behaviour aggregate,...'
>>============================================================================
>>
>>==Background==
>>In RFC5559 the term 'block' has been used to mean three different 
>>actions in two different contexts:
>>
>>1) Blocking packets:
>>"  block ECN-capable traffic that uses the same DSCP as PCN from
>>    entering the PCN-domain directly.  "Blocking" means it is dropped or
>>    downgraded to a lower-priority behaviour aggregate, or alternatively
>>    such traffic may be tunnelled through the PCN-domain"
>>
>>2a) Blocking rejected flows:
>>"    (A prospective PCN-flow that is rejected could be blocked or
>>       admitted into a lower-priority behaviour aggregate.)"
>>2b) Blocking flows
>>"   ...whether to admit or block a new flow..."
>>
>>So for packets (1), 'block' is defined to mean any of drop, 
>>downgrade or tunnel, but for rejected flows in this one case (2a) 
>>'block' is being used to only mean drop, but throughout the rest of 
>>the doc (2b) 'block' is used as just the opposite of admit, as a 
>>general term that I assume may be associated with various actions.
>>
>>
>>Bob
>>
>>
>>At 09:24 23/03/2012, Michael Menth wrote:
>>>Hi Bob,
>>>
>>>Am 23.03.2012 00:53, schrieb Bob Briscoe:
>>>>Scott,
>>>>
>>>>If an erratum is rejected, we'll have to update the architecture 
>>>>via 3-in-1.
>>>>
>>>>Therefore, we'll have to post the erratum quickly, so that we 
>>>>know whether it has been rejected or not before 3-in-1 gets thru 
>>>>the RFC-Editor.
>>>>
>>>>Here's the erratum I will post unless anyone can suggest a better way:
>>>>
>>>>====================================================================
>>>>RFC5559, "Pre-Congestion Notification (PCN) Architecture", June 2009
>>>>Source of RFC: pcn (tsv)
>>>>
>>>>Type: Technical
>>>>
>>>>Reported By: Bob Briscoe
>>>>Date Reported: 2012-03-XX
>>>>
>>>>Section 4.2 says:
>>>>
>>>>    o  Police - police, by dropping any packets received with a DSCP
>>>>       indicating PCN transport that do not belong to an admitted flow.
>>>>       (A prospective PCN-flow that is rejected could be blocked or
>>>>       admitted into a lower-priority behaviour aggregate.)
>>>>
>>>>
>>>>It should say:
>>>>
>>>>    o  Police - police, by dropping or re-marking the DSCP of any packets
>>>>       received with a DSCP indicating PCN transport that do not belong
>>>>       to an admitted flow. (A prospective PCN-flow that is rejected could
>>>>       be blocked or admitted into a lower-priority behaviour aggregate.)
>>>>
>>>>
>>>>Notes:
>>>>
>>>>The change makes the first sentence consistent with the 
>>>>parenthesis, otherwise the two contradict. The first sentence as 
>>>>it stands could be interpreted to mean that dropping is the only 
>>>>allowed policing action, whereas the parenthesis shows that 
>>>>downgrading was also considered appropriate.
>>>
>>>What does block in the parentheses mean? The same as reject? Or 
>>>does blocking imply dropping instead of remarking the DSCP? I find 
>>>the text clearer without the parentheses. Re-marking the DSCP must 
>>>imply downgrading (could be added) which does not exclude 
>>>admission into a lower-priority behavior aggregate.
>>>
>>>Regards,
>>>
>>>      Michael
>>>
>>>
>>>>====================================================================
>>>>
>>>>
>>>>Bob
>>>>
>>>>At 20:35 22/03/2012, Bradner, Scott wrote:
>>>>
>>>>>On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote:
>>>>>
>>>>> > Ruediger,
>>>>> >
>>>>> > [Scott, a question for you at the end]
>>>>> >
>>>>> >
>>>>> >
>>>>> > I prefer your erratum suggestion because it flags the problem 
>>>>> in the doc that now needs clarifying, so it's more likely to be 
>>>>> noticed by people reading the deprecated text. But we'll have 
>>>>> to see whether this would be accepted as an erratum. The 
>>>>> relevant rule is #7 here:
>>>>> > <http://www.ietf.org/iesg/statement/errata-processing.html>
>>>>> >
>>>>> > "Changes that modify the working of a protocol to something 
>>>>> that might be different from the intended consensus when the 
>>>>> document was approved should be either Hold for Document Update 
>>>>> or Rejected. Deciding between these two depends on judgment. 
>>>>> Changes that are clearly modifications to the intended 
>>>>> consensus, or involve large textual changes, should be 
>>>>> Rejected. In unclear situations, small changes can be Hold for 
>>>>> Document Update. "
>>>>> >
>>>>> > If we wrote an erratum to RFC5559, it would be legitimate, 
>>>>> because the para you have quoted has two contradictory 
>>>>> statements in it anyway. I doubt an erratum can refer to an RFC 
>>>>> published later (3-in-1), because errata are meant to correct 
>>>>> what the document should have said at the time. I think we 
>>>>> could compose an erratum that resolved the contradiction in 
>>>>> that paragraph while at the same time making it "not 
>>>>> inconsistent" with what we now want to say in 3-in-1.
>>>>> >
>>>>> > Scott, can you advise?
>>>>>
>>>>>that sounds logical
>>>>>
>>>>>Scott
>>>>
>>>>________________________________________________________________
>>>>Bob Briscoe,                                BT Innovate & Design
>>>>_______________________________________________
>>>>PCN mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/pcn
>>>
>>>--
>>>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
>>
>>________________________________________________________________
>>Bob Briscoe,                                BT Innovate & Design
>
>--
>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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design