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

[Michael Menth <[e-mail]>]

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