Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

[<toby.moncaster at bt.com>]

Hi Lars,

Sorry not to get back to you earlier - been busy at work so this went on
a back-burner for a few days. 

The original intention of having registration was to avoid confusion
during any early experimental adoption of PCN however that could be done
purely unofficially by having a list of DSCPs on the IETF wiki and just
politely asking developers to consult it and add any new ones they are
using. But there will need in future to be a process to formally
register certain standards (pool 1) DSCPs as PCN-compatible since this
effectively replaces ECN as the default  behaviour for such DSCPs. So my
suggestion is:

Change the IANA section to say something along the following lines (I
will get IANA assistance with crafting exact text):

"IANA will be asked to set up a registry of PCN-compatible Diffserv
codepoints. The decision as to whether to enable PCN for a given pool 1
codepoint must be made by the appropriate IETF Transport Area Working
Group (TSVWG?) which will then request IANA to add this to the
registry."

Clarify at start of A.1 that the decision of which DSCPs to apply PCN to
has to be made by TSVWG and is separate to this document which just
defines the process and the encoding.

Change the last sentence of A.1 to "IANA will maintain a list of
PCN-compatible Diffserv Codepoints."

Would this cover things appropriately? I did wonder about asking IANA to
maintain the experimental registry but I am not sure if they are able to
do that sort of thing? If so the following could be added to the IANA
section:

"During the early stages of adoption it is envisaged that PCN will be
used experimentally using pool 2 or 3 DSCPs (experimental or local use).
Whilst these DSCPs are not controlled by IANA normally, a request will
be made to maintain a list of PCN experiments along with the DSCPs these
experiments are using."

Once I get the nod from WG I will release a new version of the I-D with
these updates...

Toby

> -----Original Message-----
> From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
> Lars Eggert
> Sent: 14 August 2009 12:27
> To: pcn at ietf.org
> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
> 
> 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 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/
> >
> > <smime.p7s><ATT00001.txt>