Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13

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

On 19/02/2016 12:53, Paul E. Jones wrote:
> Brian,
> 
>>>  I see two reasonable options:
>>>  - Use CS0 (000000) [same as DF] and indicate that this may change in the future.
>>>  - Use CS1 (001000) with all the warnings and caveats that have been discussed.
>>>   There's more at the end of Section 3 in RFC 7657 which is already cited
>>>   in the discussion after table 1, although  an additional noted
>>>   that this material is at the end of Section 3 could be useful.
>>>
>>>  Prior to Brian's comments, the draft was headed for the latter.
>>
>> If the rough consensus is to recommend 001000 that's OK. But I really think
>> we are propagating confusion by naming it CS1, because that is the name
>> of a different behaviour. It's LE (001000).
> 
> Let me preface my reply by saying that I don't want to hold up the document by asking...
> 
> James Polk was actively working on RFC 4954bis, restructuring some of the code points and groups, etc.  I know he spent a lot of
> hours thinking about what he wanted, but I don't know how far he got in writing it down.  He did publish a few drafts, but I
> suspect he had other changes that never made it into the draft.  The latest draft published was
> https://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-03.
> 
> In August 2015, Fred Baker sent a note to the list about revising 4594.  There seemed to be general agreement that it was
> starting to show signs of aging AND that it would be a lot of work.  I don't know what the thoughts were around revising it,
> whether it's entirely different or along the lines of what James had started.
> 
> But, perhaps this is just one more reason why those who are experts in this area should perhaps spend some cycles to revise that
> text?  Personally, I think there would be some benefit in having an updated spec that is standards track.

I agree, but let's keep that of the critical path for *this* draft.

I'm think about filing an erratum against RFC 3662, because it started the
confusion by falsely using the name of a PHB to refer to a codepoint value.

    Brian