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

["Bradner, Scott" <[e-mail]>]

looks right to me

Scott

On Mar 22, 2012, at 7:53 PM, Bob Briscoe wrote:

> 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.
> ====================================================================
> 
> 
> 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