Re: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-intercon-12: (with COMMENT)

[Brian E Carpenter <[e-mail]>]

On 02/12/2016 04:38, Black, David wrote:
> Hi Stephen,
> 
> We may be talking past each other - the "has proven to be a poor
> operational practice" statement is intended to be a "running code"
> observation that Joel (OPS AD) should be able to confirm.

As a former diffserv WG chair:

When we put that provision into the original diffserv model, we were
trying to give diffserv a chance of running end to end via ISPs that
didn't support diffserv - effectively by saying that those ISPs would
provide default service for the packets concerned. But in practice,
ISPs that have done anything at all about diffserv (i.e. have not simply
run their routers with factory defaults) have mainly *chosen* to zero
any DSCPs that they don't explicitly support, to prevent unexpected
behaviours. I don't think that statement requires consensus, because it's
a fact.

But "poor" is a judgment call, so Stephen has a point. s/poor/unusual/
would be factual.

    Brian

> 
> If you would like to see "rough consensus" on this, I may need to
> dust off my Kevlar (fire-resistant) vest ;-).
> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[e-mail]]
>> Sent: Thursday, December 01, 2016 10:32 AM
>> To: Black, David; The IESG
>> Cc: [e-mail]; [e-mail]; draft-ietf-tsvwg-diffserv-
>> [e-mail]; [e-mail]
>> Subject: Re: Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-intercon-
>> 12: (with COMMENT)
>>
>>
>> Hi David,
>>
>> On 01/12/16 15:12, Black, David wrote:
>>> Stephen,
>>>
>>> Thanks for the review and interest in this draft.
>>>
>>> Diffserv Intercon could become a standard, although I'd really like to see
>> broader operator interest before going there.
>>>
>>> On the "bad operational practice" point - the evidence is the widespread
>> operator deployment of "bleaching"
>>> DSCPs to zero at network interconnects.  We could cite RFC 7657, which
>> contains this text in Section 3.2
>>> on that point:
>>>
>>>    So, for two arbitrary network endpoints, there can be no assurance
>>>    that the DSCP set at the source endpoint will be preserved and
>>>    presented at the destination endpoint.  Rather, it is quite likely
>>>    that the DSCP will be set to zero (e.g., at the boundary of a network
>>>    operator that distrusts or does not use the DSCP field) or to a value
>>>    deemed suitable by an ingress classifier for whatever network 5-tuple
>>>    it carries.
>>>
>>> Would that help?
>>
>> Not really, but not because it's a bad thing to add:-)
>>
>> The thing I don't get is whether or not the claim in
>> the document is something that has IETF consensus or
>> not. That's because I'm ignorant about that topic, so
>> I'm just as happy to believe you when you tell me that
>> it's fine, without text changes.
>>
>> Cheers,
>> S.
>>
>>>
>>> Thanks, --David
>>>
>>>> -----Original Message-----
>>>> From: Stephen Farrell [mailto:[e-mail]]
>>>> Sent: Thursday, December 01, 2016 8:59 AM
>>>> To: The IESG
>>>> Cc: [e-mail]; Gorry Fairhurst; tsvwg-
>>>> [e-mail]; [e-mail]; [e-mail]
>>>> Subject: Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-intercon-
>> 12:
>>>> (with COMMENT)
>>>>
>>>> Stephen Farrell has entered the following ballot position for
>>>> draft-ietf-tsvwg-diffserv-intercon-12: 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-tsvwg-diffserv-intercon/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>>
>>>> - I'm puzzled by this being informational, it sure seems
>>>> like something that could/should be a standard. (I'm not
>>>> objecting, just puzzled.)
>>>>
>>>> - Section 2: For an IETF consensus document wouldn't it be
>>>> good to have some references for claims like "has proven to
>>>> be a poor operational practice"? Is that actually a
>>>> statement where we're confident of IETF consensus? (I have
>>>> no clue, I'm just checking based on the language and the
>>>> Informational RFC status.)
>>>>
>>>
>