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

["Black, David" <[e-mail]>]

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.

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.)
> >>
> >