On 20/06/2018 09:50, Toerless Eckert wrote:
> Brian, Michael: For the purpose of BRSKI the only relevant aspect of the
> ANI is that it is assumed to be a system that support BRSKI and ACP,
> and then the document starts to define a bunch of requirements against
> BRSKI, which instead of saying
Brian, Michael: For the purpose of BRSKI the only relevant aspect of the
ANI is that it is assumed to be a system that support BRSKI and ACP,
and then the document starts to define a bunch of requirements against
BRSKI, which instead of saying ANI could equally say "BRSKI devices that
also support
On 20/06/2018 03:38, Michael Richardson wrote:
> On 31/05/18 04:23 PM, Brian E Carpenter wrote:
>> On 01/06/2018 07:31, Michael Richardson wrote:
>>>
>>> Toerless Eckert wrote:
>>> > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote:
>>> >> > I would prefer to have the
On 31/05/18 04:23 PM, Brian E Carpenter wrote:
On 01/06/2018 07:31, Michael Richardson wrote:
Toerless Eckert wrote:
> On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote:
>> > I would prefer to have the simple definition "ANI == systems that
support
>> > both
Brian E Carpenter wrote:
>> > An RFC specifying that would therefore have to declare itself to be
>> > an update of GRASP. I don't think this is a big deal. It would become
>>
>> I think that you mean, update of BRSKI rather than "update of GRASP".
> Possibly both, because
On 01/06/2018 07:35, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > 1. The GRASP specification of 4.1.1 should only describe what is
> required
> > and valid for the standard of GRASP objective, which is the TCP proxy.
>
> > Appendix C proxy option is not full/formally
On 01/06/2018 07:31, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote:
> >> > I would prefer to have the simple definition "ANI == systems that
> support
> >> > both BRSKI and ACP" in the doc itself. Threre
Toerless Eckert wrote:
> 1. The GRASP specification of 4.1.1 should only describe what is required
> and valid for the standard of GRASP objective, which is the TCP proxy.
> Appendix C proxy option is not full/formally worked out, thats why
> its in an appendix. If the authors
Toerless Eckert wrote:
> On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote:
>> > I would prefer to have the simple definition "ANI == systems that
support
>> > both BRSKI and ACP" in the doc itself. Threre is really no single
authoritative
>> > normative
On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote:
> > I would prefer to have the simple definition "ANI == systems that
> support
> > both BRSKI and ACP" in the doc itself. Threre is really no single
> authoritative
> > normative document for ANI, so it should
Brian E Carpenter wrote:
> On 31/05/2018 13:53, Toerless Eckert wrote:
> ...
>> 4.1.1:
>>
>>> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6
>>
>> The way i see it, the normative approach with TCP circuit proxy would
>> always only have TCP, right,
Toerless Eckert wrote:
>> > f) IMPORTANT: Please add/define the term "ANI"
>>
>> > ANI - "Autonomic Network Infrastructure". Systems that support both
BRSKI and
>> > Autonomic Control plane - ACP
([I-D.ietf-anima-autonomic-control-plane]). ANI
>> > systems (pledges,
On 31/05/2018 13:53, Toerless Eckert wrote:
> 4.1.1:
>
>> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6
>
> The way i see it, the normative approach with TCP circuit proxy would
> always only have TCP, right, e.g.: the line should say
>
> transport-proto = IPPROTO_TCP ; Not
13 matches
Mail list logo
