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

[Bob Briscoe <[e-mail]>]

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