Hi, I'm waiting to hear from the authors/WG. Lars On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
Hi, this document is ready, except for one issue: Section 7., paragraph 1:This document makes no direct request to IANA. However thisdocumentallows for a set of Diffserv Codepoints to be assigned differentECNsemantics 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 aboutmaintaining a list again.) Which is it? If there is to be a list, youneed 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 uponNit: s/guaranteeed/guaranteed/ Section 6., paragraph 1:always copy the CE codepoint from teh outer header into the innerNit: s/teh/the/ Section 6., paragraph 2:header in decapsulation (unless the inner packet is not-ECT).If anoperator 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. ReferencesShould be updated; see idnits report. Appendix A., paragraph 2:a given PCN-domain is dependant on the nature of the trafficentering Nit: s/dependant/dependent/ <smime.p7s><ATT00001.txt>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature