On 12/1/16 4:59 PM, Black, David wrote:
>> But "poor" is a judgment call, so Stephen has a point. s/poor/unusual/
>> would be factual.
> Sure, or something like "has not been widely deployed in practice."
The fact that it is in practice unworkable is trivially defensible. It
in fact does not work, My signals are not you signals, and I never
agreed to prioritize your traffic over mine, I don't control the
networks over which my packets flow, Encapsulation makes them invisible
even when I do, the bits are mutable and therefore are recycled, and so
on, it's turtles all the way down.
> Thanks, --David
>
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: Thursday, December 01, 2016 2:54 PM
>> To: Black, David; Stephen Farrell; The IESG
>> Cc: gorry@erg.abdn.ac.uk; tsvwg-chairs@ietf.org; draft-ietf-tsvwg-diffserv-
>> intercon@ietf.org; tsvwg@ietf.org
>> Subject: Re: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-diffserv-
>> intercon-12: (with COMMENT)
>>
>> 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:stephen.farrell@cs.tcd.ie]
>>>> Sent: Thursday, December 01, 2016 10:32 AM
>>>> To: Black, David; The IESG
>>>> Cc: gorry@erg.abdn.ac.uk; tsvwg-chairs@ietf.org; draft-ietf-tsvwg-diffserv-
>>>> intercon@ietf.org; tsvwg@ietf.org
>>>> 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:stephen.farrell@cs.tcd.ie]
>>>>>> Sent: Thursday, December 01, 2016 8:59 AM
>>>>>> To: The IESG
>>>>>> Cc: draft-ietf-tsvwg-diffserv-intercon@ietf.org; Gorry Fairhurst; tsvwg-
>>>>>> chairs@ietf.org; gorry@erg.abdn.ac.uk; tsvwg@ietf.org
>>>>>> 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.)
>>>>>>