On Aug 7, 2018, at 9:26 AM, Fernando Gont<[email protected]> wrote:
Hello, Gorry,
On 08/07/2018 05:26 PM, Gorry Fairhurst wrote:
To me, this topic is tricky to position, and there are still multiple
parts across the two documents.
One way could be to agree the properties of different address types on
scope and stability, devoid of API and Application-considerations - I
at the moment don't currently understand this enough to say if this is a
new statement about the network layer or is restating what has been said
before, so to me at least this seems to need network-layer clue. I see
there may be a network layer security concern that may drive some
considerations (seems more like that part is in
draft-gont-taps-address-analysis)
For the most part, address types are specified, but there's not much
guidance on how to use them. Depending on the perspective, I guess one
might argue that guidance should come from internet area (6man for the
ipv6 specific case, and intarea for ipv4... or even both).
From another POV, this sees to be related with TAPs. If you hve an api,
there's not much you will be able to do (at least in a proper way :-) ),
without appropriate guidance.
To answer the immediate question: I think this doesn't look like TAPS
should adopt that document. If this ID needs transport clue and spans
multiple transport protocols, that could be reviewed by TSVWG if this
had already strong support elsewhere?
There is a mention of an API and usage concern. I haven't worked out if
that is transport guidance,
That's mostly a problem statement: we don't have appropriate APIs to
fully leverage IPv6 addressing.
[....]
Possibly there is also a need for a new API, and if that needs the IETF
to do new work, then to me that does look a lot like source address
selection in TAPS. There could be useful input here to a few paras in
the TAPS architecture. It's not clear to me that would require a new
draft though in TAPS to achieve this.
Could you please rovide a reference to the document so that I can take a
look and review?
