Summary: Has enough positions to pass.
Nit: model vs module. While there are no strict requirements for terminology, it appears that dominant term used in YANG documents is model and not module. The reasoning would be that model defines a module and the logic description of it, while module is strictly a formal YANG code. Nit: s/rate-lmite/rate limit uint8 max-softwires-per-subscriber: Is the storage space large enough here? RFC 7785 recommends 1, but it does not appear to set upper limit. If practical deployment scenarios will be an order of magnitude lower than 255 then likely it is not a problem. date-and-time last-address-change: Is the granularity of yang:date-and-time enough for this use?
This is well-written overall, but I was confused by the RFC editor note after the abstract. I assume you mean for these updates to be done on matching text throughout the document, but I originally read it to mean update the text in the note itself, which is labeled for deletion.
How are "upstream" and "downstream" identified? (Each term appears only once, so perhaps it is better to just expand at each usage.)
I guess there is also an dscp type in rfc6991 that could be used...?
Thanks to everyone who worked on this document. I really appreciate how well-explained the fields added by this module are, both in section 2 and in the module itself. Please expand "PCP" on first use.