Hi, this document is ready, except for one issue: Section 7., paragraph 1:> This document makes no direct request to IANA. However this document > allows for a set of Diffserv Codepoints to be assigned different ECN
> semantics within a controlled domain as described in [RFC4774]. A > list of such DSCPs will be maintained by the PCN working group.DISCUSS: This text isn't aligned with appendix A.1. The text here says
"the WG will maintain a list of DSCPs that are OK", while the beginning of appendix A.1 says "the WG decided to not define with which DSCPs PCN can be used" (but then the end of A.1 talks about maintaining a list again.) Which is it? If there is to be a list, you need to create an IANA registry, write management procedures for it (see RFC5226) and populate it with some initial values. (WGs are ephemeral, which is why the PCN WG can't be the maintainer of this list, IANA has to be.) If you want to leave it fully open for deployments, you need to remove this confusion from the text. Lars Nits: Section 4., paragraph 3: > to prevent future compatability issues. Nit: s/compatability/compatibility/ Section 4.2., paragraph 1: > that is guaranteeed to be copied down into the inner header upon Nit: s/guaranteeed/guaranteed/ Section 6., paragraph 1: > always copy the CE codepoint from teh outer header into the inner Nit: s/teh/the/ Section 6., paragraph 2:> header in decapsulation (unless the inner packet is not-ECT). If an
> operator it is essential that any operator wishing to allow ECN to > exist end-to-end ensures there are no tunnel end-points within the > PCN-domain. "If an operator it is essential that any operator..." - wording Section 12., paragraph 0: > 12. References Should be updated; see idnits report. Appendix A., paragraph 2:> a given PCN-domain is dependant on the nature of the traffic entering
Nit: s/dependant/dependent/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature