> 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?
The GitHub for the documents is:
https://github.com/taps-api/drafts
https://taps-api.github.io/drafts/draft-ietf-taps-arch.html
https://taps-api.github.io/drafts/draft-ietf-taps-interface.html
https://taps-api.github.io/drafts/draft-ietf-taps-impl.html
I imagine that we could have a *brief* mention in the architecture, but more
importantly provide a path selection property in the Interface/API document,
with an implementation considerations section in the Implementation document.
Having an internet area draft to refer to from the API specification would be
useful.
Tommy
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [email protected]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> Taps mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
