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

[Bob Briscoe <[e-mail]>]

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


On 07/01/16 01:59, Barry Leiba wrote:
> 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.
>
>

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