[Last-Call] Re: draft-ietf-tsvwg-nqb-29 ietf last call Opsdir review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Giuseppe, 

Thank you very much for your review and insightful comments on the draft.  These are good suggestions. 

I kept 4.1 standalone (now as 4) since it is specifically related to Sender requirements, while section 5 covers PHB requirements, but I moved the other 4.x subsections to section 6, relabeled it as Operational Considerations and tweaked the opening text of that section accordingly. I think this does improve the readability for operators. 
  
Attached is a WIP draft 30 with this new structure. 

-Greg


On 6/17/25, 10:23 AM, "Giuseppe Fioccola via Datatracker" <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote:


Document: draft-ietf-tsvwg-nqb
Title: A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated
Services Reviewer: Giuseppe Fioccola Review result: Has Nits


This document specifies a Non-Queue-Building Per-Hop Behavior (NQB PHB) in
order to provide a separate queue for application-limited traffic microflows,
allowing to avoid the queuing delays and losses caused by other traffic. This
document has been developed primarily for access network segments and
recommends a specific DSCP to identify NQB microflows. It also updates RFC 8325.


From an OPSDIR point of view, it is good to have Section 4, 6 and 7. Even if
the information is spread among these different sections, they provide guidance
for networks that forward traffic marked with the NQB DSCP and for networks
that do not currently support the NQB PHB.


I think that the document has a clear scope and is almost ready for
publication, but I have a couple of suggestions:


- I think that section 5 on NQB PHB Requirements could be moved before section
4. Also, since section 4.1 explains NQB Sender Requirements, it can be placed
under section 5.


- To improve structure and clarity, you can probably consider to merge section
4 and section 6 since some information is shared such as the configuration
recommendations. A whole section on the Operational and Management aspects as
result of the merge would work better in my opinion.










<<< text/html; name="draft-ietf-tsvwg-nqb-30.html": Unrecognized >>>
-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux