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

[Barry Leiba <[e-mail]>]

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 <[e-mail]> 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
>
>
> 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/
>