Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pals-congcons-01: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Wed, 06 Jan 2016 17:59:11 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-pals-congcons-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pals-congcons/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Abstract --
The abstract seems to have too much detail about what the document 
concludes.  The abstract should just be a general statement of what the 
document is about -- just enough that someone can determine whether this

document is relevant.

I think I would do something like this:

NEW
   Pseudowires (PWs) have become a common mechanism for tunneling
   traffic, and may be found in unmanaged scenarios competing for
   network resources both with other PWs and with non-PW traffic, such
   as TCP/IP flows.  It is thus worthwhile specifying under what
   conditions such competition is acceptable, where the PW traffic does
   not significantly harm other traffic or contribute more than it
   should to congestion. This document makes that analysis and provides
   recommendations.
END

The rest of the detail needs to be in the document -- perhaps in the 
Introduction -- but not in the abstract.

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 7 Jan 2016 19:03:04 +0000

Barry,

While I agree with you in principle, I'm not convinced it harms to 
include conclusions in an abstract, as long the length doesn't become 
unreasonable.

I think perhaps the more important change would be to include a 
conclusions section (which is the problem with the doc that underlies 
Spencer's comment). Then I would be less worried about removing 
conclusions from the abstract - altho I still wouldn't make it a priority.

Not every RFC needs a conclusions section, esp. not protocol specs, but 
I think this one does.

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Jan 2016 06:22:10 +0800

Hi, Bob.  Yes, I think you're right about a "Conclusions" section.  As
to the Abstract, I'll leave it to y'all to decide that, and thanks for
considering my comments.

Barry

On Fri, Jan 8, 2016 at 3:03 AM, Bob Briscoe <[email-masked]> wrote:
> Barry,
>
> While I agree with you in principle, I'm not convinced it harms to include
> conclusions in an abstract, as long the length doesn't become unreasonable.
>
> I think perhaps the more important change would be to include a conclusions
> section (which is the problem with the doc that underlies Spencer's
> comment). Then I would be less worried about removing conclusions from the
> abstract - altho I still wouldn't make it a priority.
>
> Not every RFC needs a conclusions section, esp. not protocol specs, but I
> think this one does.
>
>
> Bob
>
>