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

From: "Bradner, Scott" <[email-masked]>
Date: Tue, 20 Mar 2012 16:37:01 +0000

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" <[email-masked]>

From: Bob Briscoe <[email-masked]>

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: <[email-masked]>

To: <[email-masked]>,

<[email-masked]>, <[email-masked]>,

<[email-masked]>, <[email-masked]>

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

Diff from previous version:

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

---

From: <[email-masked]>
Date: Tue, 20 Mar 2012 16:46:19 +0000

Seems good to me. I like the inclusion of material previously in both the edge behaviour docs

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bradner, Scott
Sent: 20 March 2012 16:37
To: [email-masked]
Subject: [PCN] lets try again - a chair asking this time

Scott

Scott O Bradner

Begin forwarded message:

Date: Mon, 12 Mar 2012 03:30:11 +0000
To: "PCN IETF list" <[email-masked]<mailto:[email-masked]>>
From: Bob Briscoe <[email-masked]<mailto:[email-masked]>>
Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt

PCN folks,

[...]

In the

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

From: <[email-masked]<mailto:[email-masked]>>
To: <[email-masked]<mailto:[email-masked]>>,
        <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>,
        <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Date: Sun, 11 Mar 2012 17:52:23 -0700
Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt

IETF Secretariat.

---

From: Toby Moncaster <[email-masked]>
Date: Tue, 20 Mar 2012 16:46:50 +0000

I certainly think this is now in good shape to progress (but as I'm an author my opinion may be biased).

Toby

On 20 Mar 2012, at 16:37, "Bradner, Scott" <[email-masked]> wrote:

> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Tue, 20 Mar 2012 19:25:14 +0000

Hi all,

I think that the changes satisfy nicely the comments of Adrian!

Best regards,

Georgios

________________________________
Van: [email-masked] [[email-masked]] namens [email-masked] [[email-masked]]
Verzonden: dinsdag 20 maart 2012 17:46
Aan: [email-masked]; [email-masked]
Onderwerp: Re: [PCN] lets try again - a chair asking this time

Scott

Scott O Bradner

Begin forwarded message:

PCN folks,

[...]

In the

the DSCP to zero.

Bob

IETF Secretariat.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Mar 2012 16:40:04 -0500

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, [email-masked] wrote:
>Content-Language: nl-NL
>Content-Type: multipart/alternative;
> 
>boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C150D7EXMBX04adutwent_"
>
>Hi all,
>
>
>
>----------
>Van: [email-masked] [[email-masked]] namens 
>[email-masked] [[email-masked]]
>To: "PCN IETF list" <<mailto:[email-masked]>[email-masked]>
>From: Bob Briscoe <<mailto:[email-masked]>[email-masked]>
>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:
>
>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.
>From: <<mailto:[email-masked]>[email-masked]>
>To: <<mailto:[email-masked]>[email-masked]>,
> 
><<mailto:[email-masked]>[email-masked]>, 
><<mailto:[email-masked]>[email-masked]>,
>         <<mailto:[email-masked]>[email-masked]>, 
> <<mailto:[email-masked]>[email-masked]>
><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 
>
>
>
><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.
>
>

---

From: Michael Menth <[email-masked]>
Date: Tue, 20 Mar 2012 22:48:28 +0100

Same holds for me.

Michael

Am 20.03.2012 17:46, schrieb Toby Moncaster:
> On 20 Mar 2012, at 16:37, "Bradner, Scott" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>> *
>>> *
>>>> To: "PCN IETF list" <[email-masked] <mailto:[email-masked]>>
>>>> From: Bob Briscoe <[email-masked] <mailto:[email-masked]>>
>>>> <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 
>>>> >
>>>>
>>>>
>>>>
>>>> Bob
>>>>
>>>>> From: <[email-masked] <mailto:[email-masked]>>
>>>>> To: <[email-masked] <mailto:[email-masked]>>,
>>>>> <[email-masked] 
>>>>> <mailto:[email-masked]>>, 
>>>>> <[email-masked] <mailto:[email-masked]>>,
>>>>> <[email-masked] <mailto:[email-masked]>>, 
>>>>> <[email-masked] <mailto:[email-masked]>>
>> [email-masked] <mailto:[email-masked]>

-- 
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: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: <[email-masked]>
Date: Wed, 21 Mar 2012 09:07:51 +0100

Hi Scott,

the passage you quote should result from a misconfiguration or an attack.

      Treatment of non-PCN-packets confused with a PCN-packet
      due to DSCP/ECN codepoinzt setting:
      ...
      In the absence of any operator-specific
      configuration for this case, by
      default an implementation SHOULD re-mark
      the DSCP to zero.
      ...
      Clearing the ECN field is not an appropriate
      policing action, because a network node ought not to interfere
      with an e2e signal.  Even if such packets seem like an attack,
      drop would be overkill, because such an attack can be neutralised
      by just re-marking the DSCP.  And DSCP re-marking in the network
      is legitimate, because the DSCP is not considered an e2e signal.

What's done here is remarking of a flow with a DSCP that has been
agreed between two parties. On a consumer UNI, this may be an attack,
on an NNI, this could indicate a misconfiguration. In the latter case,
a management alert seems reasonable. Text to that may be added.

I further quote the PCN architecture, which is informational, on the
Ingress Node behaviour:

      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.)  Similarly,
      police packets that are part of a previously admitted flow, to
      check that the flow keeps to the agreed rate or flowspec (eg, see
      [RFC1633] for a microflow and its NSIS equivalent).

This isn't in line with the proposed 3-in-1 (standards track) behaviour.
Does this require an "Errata" atatement for RFC5559 (I'm not an expert on
editing RFCs and may be wrong here)?

Regards,

Ruediger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bradner, Scott
Sent: Tuesday, March 20, 2012 5:37 PM
To: [email-masked]
Subject: [PCN] lets try again - a chair asking this time

Scott

Scott O Bradner

Begin forwarded message:

                PCN folks,

                [...]
                In the

                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 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1>  >

                Bob

                        IETF Secretariat.

---

From: <[email-masked]>
Date: Wed, 21 Mar 2012 11:20:28 +0000

Good spot!

To me, either drop or re-mark to Best effort seem ok. I can see bob's argument that it is nicer internet behaviour to treat as best effort than to drop.
Adding a mgt alert seems very good.
Since it does indeed differ from pcn architecture, i guess it needs a statement in the 'header' "Modifies 5559" and something in the Intro (?) that states which para of 5559 is modified in what way. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 21 March 2012 08:08
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] lets try again - a chair asking this time

Hi Scott,

Regards,

Ruediger

Scott

Scott O Bradner

Begin forwarded message:

                PCN folks,

                [...]
                In the

                Bob

                        IETF Secretariat.

---

From: <[email-masked]>
Date: Wed, 21 Mar 2012 11:24:48 +0000

To add to your nit, I think it may be helpful to add something like

"(by default 000000 indicates the best-effort forwarding behaviour)"

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: 20 March 2012 21:40
To: [email-masked]; Eardley,PL,Philip,DUB8 R; [email-masked]; [email-masked]
Subject: Re: [PCN] lets try again - a chair asking this time

or even

or even

or even

instead of just

?

James

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 22 Mar 2012 19:35:12 +0000

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

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 22 Mar 2012 20:20:19 +0000

Ruediger,

[Scott, a question for you at the end]

At 08:07 21/03/2012, [email-masked] wrote:
>on an NNI, this could indicate a misconfiguration.

Yes, when I realised this could be a mistake or an attack, I realised 
remarking the DSCP was the right approach to recommend, because it 
allows the operator to control this as part of their general DSCP 
re-marking policy.

BTW, the default of "re-mark to zero", was merely so /implementers/ 
have a default. It's not intended to be the recommended policy for operators.

>In the latter case,

Good catch. In fact, an alert for an attack is also worth suggesting. 
I suggest the following text after "...re-mark the DSCP to zero (000000)."

"Whichever policing action is chosen, the PCN-ingress-node SHOULD log 
the event and MAY also raise an alarm. Alarms SHOULD be rate-limited 
so that the anomalous packets will not amplify into a flood of alarm messages."

>This isn't in line with the proposed 3-in-1 (standards track) behaviour.

You're right. When we wrote this point in the architecture I think we 
were only thinking about blocked flows. I don't think that text was 
intended to catch packets that had never even asked to be admitted 
(i.e. mistakes or attacks).

>editing RFCs and may be wrong here)?

You're right that something needs doing about this statement in the 
architecture. We could say in 3-in-1 that it updates RFC5559. That 
would require an extra section in 3-in-1 saying exactly which part of 
the architecture it updates.

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?

Bob

>                 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:
>
>                 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 
> <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1>  >
>
>
>
>                 Bob
>

---

From: "Bradner, Scott" <[email-masked]>
Date: Thu, 22 Mar 2012 20:35:04 +0000

On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote:

> 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:
> "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

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 22 Mar 2012 23:53:54 +0000

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:

> > 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:
> might be different from the intended consensus when the document 
> was approved should be either Hold for Document Update or Rejected. 
> > 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

---

From: "Bradner, Scott" <[email-masked]>
Date: Fri, 23 Mar 2012 00:01:12 +0000

looks right to me

Scott

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

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

---

From: Michael Menth <[email-masked]>
Date: Fri, 23 Mar 2012 10:24:27 +0100

Hi Bob,

Am 23.03.2012 00:53, schrieb Bob Briscoe:
> 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

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

---

From: <[email-masked]>
Date: Fri, 23 Mar 2012 11:05:15 +0100

Bob,

thanks, your proposal on log and alert (and the proposed erratum)
work well with me.

Regards,

Ruediger

-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]]
Sent: Thursday, March 22, 2012 9:20 PM
To: Geib, Rüdiger; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] lets try again - a chair asking this time

Ruediger,

Scott, can you advise?

Bob

---

From: <[email-masked]>
Date: Fri, 23 Mar 2012 10:15:23 +0000

Sounds good to me

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 23 March 2012 10:05
To: Briscoe,RJ,Bob,DUB8 R
Cc: [email-masked]
Subject: Re: [PCN] lets try again - a chair asking this time

Bob,

Regards,

Ruediger

-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]]
Sent: Thursday, March 22, 2012 9:20 PM
To: Geib, Rüdiger; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] lets try again - a chair asking this time

Ruediger,

Scott, can you advise?

Bob

---

From: Toby Moncaster <[email-masked]>
Date: Fri, 23 Mar 2012 10:29:21 +0000

+1

---

From: <[email-masked]>
Date: Fri, 23 Mar 2012 10:30:19 +0000

+1

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Toby Moncaster
> Sent: vrijdag 23 maart 2012 11:29
> To: [email-masked]
> Cc: [email-masked]
> > thanks, your proposal on log and alert (and the proposed erratum) work
> > well with me.
> >
> > Regards,
> >
> > Ruediger
> >
> >> Does this require an "Errata" atatement for RFC5559 (I'm not an
> >> expert on editing RFCs and may be wrong here)?
> >
> > 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:
> > "Changes that modify the working of a protocol to something that might
> > be different from the intended consensus when the document was
> > 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?
> >
> >
> > Bob
> >
> >
> >> Regards,
> >>
> >> Ruediger
> >>
> >> being the most comprehensive and useful), we've posted a new version
> >> of the PCN 3-in-1 encoding.
> >>
> >> 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.
> >>
> >>                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

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 23 Mar 2012 19:29:31 +0000

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:

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:
>>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.
>
>blocking imply dropping instead of remarking the DSCP? I find the 
>text clearer without the parentheses. Re-marking the DSCP must imply 
>>> > I prefer your erratum suggestion because it flags the problem 
>>> in the doc that now needs clarifying, so it's more likely to be 
>>> > "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. "
>>> >
>>> 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
>>

---

From: Michael Menth <[email-masked]>
Date: Fri, 23 Mar 2012 21:36:07 +0100

That's fine with me.

Michael

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 23 Mar 2012 20:55:46 +0000

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:
>>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 
>>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,...'
>>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
>>
>>
>>>>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.
>>>>
>>>>parenthesis, otherwise the two contradict. The first sentence as 
>>>>it stands could be interpreted to mean that dropping is the only 
>>>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
>>>
>>>
>>>>> 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:
>>>>> 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. "
>>>>> >
>>>>> 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