[homenet] draft-lepape-6man-prefix-metadata-00

[Michael Richardson <[e-mail]>]

I think that this draft is useful land should be adopted.

I think that application writers will be much happier asking for prefix
colours than properties, if there is a clear set of default colours.
I am concerned that there is an attempt to be too indirect, the way that
DiffServ tried with DSCP, and yet nearly only code point is really supported
for EF on real networks, so the point where application writers tend to
embed it, at least at the documentation layer.

section 3.3 talks about:

   Once an application has determined the appropriate property **and** color
   for its use it has to communicate with the network stack to select

and I thought up to this point that one could select by colour, or by
property.  While it's true that the host interface is host specific, for this
to work, someone needs to publish a reference implementation for Android/Java
and Linux/C/Python...

Suggesting three different userspace/kernel methods isn't going to help get
applications written. APIs matter here.  Being able to set a default colour
for a process (and it's children!!) is probably the initial killer interface,
because I can now do something like:
        low-latency-colour skype &
where the command "low-latency-colour" sets the default colour and then
invokes another command.

3.5 I believe that local scoping of prefix color is going to be useless.
The prefix colour is a proxy for which ISP/servie, so making it ISP scoped
makes it useless for the application.

Instead, I suggest that the prefix colour either be a global IANA registry
(DS PHB may already be the right thing...),or make it a uuid.  Then T-mobile
can embed their network prefix colour for video in the video player app that
they want to shove into my phone...

--
Michael Richardson <[e-mail]>, Sandelman Software Works