e like),
Once we specify byte-by-byte comparison, do we need to worry about
this in a protocol document? If someone is silly enough to
specify an objective called 'example.org:Недостаточно握 déjà vu
' do we care, in the protocol design?
Personal opinion: we don't need to say an
On 10/03/2017 05:53, Barry Leiba wrote:
>> > Personal opinion: encryption should be a MUST.
>>
>> I believe that we will have situations where we have a secured ACP into a NOC
>> (to an edge router or VM hypervisor), and then we will have some unencrypted,
>> but secured links to platforms in t
Hi,
This version tries to address numerous IETF Last Call comments,
including a lot of editorial changes including clarifications
and minor reorganization. The real technical changes are these:
Protocol change: Specify that an objective with no initial value
should have its value field set to C
Hi,
We have made a few small updates to make the text more precise.
We believe this should be ready for WG Last Call as Informational.
Regards
Brian + co-authors
On 10/03/2017 15:54, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> dir
On 10/03/2017 22:39, Michael H. Behringer wrote:
> On 09/03/2017 20:37, Brian E Carpenter wrote:
>> On 10/03/2017 05:53, Barry Leiba wrote:
>>>> > Personal opinion: encryption should be a MUST.
>>>>
>>>> I believe that we will have situati
On 12/03/2017 08:08, Michael Richardson wrote:
>
> I haven't read the document yet, just the abstract.
>
> I am not suggesting it, just relaying that this privacy issue seems to be
> something others have recognized as a concern.
Do you see it as a concern inside the ACP? I would have thought no
On 14/03/2017 08:26, Michael Richardson wrote:
>
> Michael H. Behringer wrote:
> > The configuration of the device is outside scope, I think! If a config
> > change removes the last ACP tunnel (for example), then it's that
> > removal that changes the state in the AN machine.
>
> I l
I've been tracking this a bit. Their main focus is on a YANG
interface between the NOC and the IPAM system. It's thanks to
me that the C stands for Coordinated instead of Centralized.
I believe that our prefix management use case is part of
the back end for this rather than competition, but we sho
egards
Brian
On 21/03/2017 10:50, Brian E Carpenter wrote:
> I've been tracking this a bit. Their main focus is on a YANG
> interface between the NOC and the IPAM system. It's thanks to
> me that the C stands for Coordinated instead of Centralized.
>
> I believe that ou
Hi,
> 5. Proxy Discovery Protocol Details
...
> proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address,
>transport-proto, port-number ] ]
If that's a GRASP objective, it needs to include the loop-count and flags
fields.
Also, I thought it was officia
Hi,
We will discuss the GRASP API
(https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago.
One related topic is how to map this API into C, which is perhaps the most
fundamental mapping.
People with more C coding experience than me: please look at the attached
header file. All k
On 24/03/2017 04:43, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > Hi,
>
> > We will discuss the GRASP API
> > (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago.
>
> > One related topic is how to map t
On 25/03/2017 07:46, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> >> Brian E Carpenter wrote: > Hi,
> >>
> >> > We will discuss the GRASP API >
> >> (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chica
On 25/03/2017 11:46, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > It doesn't deal well with flexible types either, a dangerous luxury in
> > Python that I've got very fond of. But it seems to me that if a GRASP
> > core implementation
So, are you going to stop changing the names now? Because each
time you change them, I have to update draft-carpenter-anima-ani-objectives
but more seriously my demo code too...
Join Router is wrong. It forwards messages not packets. Maybe its next
name should be Join Middlebox, but I'm happy with
Hi,
To follow up the Unicode issue mentioned today, I propose
to add the following paragraph to the section "3.10.3. General
Considerations for Objective Options" in draft-ietf-anima-grasp.
Any comments from the WG? It would be nice to publish this
while we are in Chicago:
Names are expressed as
In the hackathon, the prototype GRASP implementation in Python 3 was
successfully tested on several Linux machines and a Windows host,
provided by collaborators (Michael Richardson, William Atwood, Jéferson
Campos Nobre) and myself. We also demonstrated the emulations of prefix
assignment and sec
OK, I'll front-post.
Where you want to plug in an ASA (autonomic service agent) is anywhere
you want plug in some intelligence to govern an automatic process.
Intelligence, for example, to figure out what to do if the user side
asks for a /48 and the ISP offers a /60. So the ASA might negotiate
a
One more thing from our tests this week.
We noticed when testing at busy times that link-local multicasts
were often dropped. We would see quite long gaps when discovery
and flooding simply did not occur. Suspecting that the wireless
network was limiting the rate of multicasts, I cheated for a
few
On 30/03/2017 09:16, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > Where you want to plug in an ASA (autonomic service agent) is anywhere
> > you want plug in some intelligence to govern an automatic process.
> > Intelligence, for example, to figu
On 30/03/2017 09:52, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > with the Python implementation was not possible. I also learned the
> > hard way that the Python code throws an exception on a badly
> > malformed Discovery packet (will fix!).
On 30/03/2017 10:04, Juliusz Chroboczek wrote:
>> There's already a thing called an HNCP agent. Why couldn't
>> it be enhanced to negotiate with an upstream ASA for resources?
>
> Could you please clarify what you mean by "negotiate"? Current HNCP
> implementations are provided with a bunch of Ex
On 30/03/2017 11:14, Mark Townsley (townsley) wrote:
>
>> On Mar 29, 2017, at 10:04 AM, Michael Richardson
>> wrote:
>>
>>
>> This discussion started in a private thread, so I'll try to bring people
>> up-to-date by repeating and moving around text.
>>
>> The ANIMA GRASP reference problem Autono
On 30/03/2017 10:38, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> >> I just don't see the point of the ASA here.
>
> > There's already a thing called an HNCP agent. Why couldn't
> > it be enhanced to negotiate with an upstream
On 31/03/2017 03:50, Ted Lemon wrote:
> On Mar 30, 2017, at 9:45 AM, Michael Richardson wrote:
>> It would hand out space via HNCP, and if it ran out of space, get more.
>
> This can also be done with DHCP.
Indeed. I'm not trying to force the Anima approach, just pointing out that
it will be ava
This version has updates that are supposed to close the open issues discussed
on Monday:
Encryption changed to a MUST implement.
Pointed to guidance on UTF-8 names.
Over to the WG Chairs and AD for the next step.
Regards
Brian, Bing, Carsten
On 31/03/2017 08:16, internet-dra...@ietf.
On 07/04/2017 07:05, Toerless Eckert wrote:
> Thanks Michael
>
> A) One aside question for curiosity. The doc is stating :
>
> ...IPv6 architecture as outlined in [RFC2460]. Extensions may not be added
> or removed
> except by the sender or the receiver
>
> Is this actually stated anywhere i
Comment at the end..
On 07/04/2017 09:31, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> >> Unless RPL for the ACP or any future ACP mechanism do require
> reception and processing
> >> of IPv6-in-IPv6 packets, ACP routers SHOULD filter/drop IPv6
On 14/04/2017 04:36, Michael Richardson wrote:
...
> I also think we could in light of rfc2460bis renegotiation, argue for
> insertion of RPI header by the ACP without IPIP encapsulation :-)
I wouldn't bet on that for a few more weeks yet. We do have a couple of
mitigations however:
1) Since the
d ANIMA wish that ROLL
> publishes that doc?
>
> Take care,
>
> Pascal
>
>> Le 13 avr. 2017 à 23:31, Brian E Carpenter a
>> écrit :
>>
>>> On 14/04/2017 04:36, Michael Richardson wrote:
>>> ...
>>> I also think we could in lig
We have an early assignment from IANA for the GRASP port: 7017.
I've updated the code at https://www.cs.auckland.ac.nz/~brian/graspy/grasp.py
We're still waiting for the LL multicast address assignments.
Regards
Brian
___
Anima mailing list
Anima@
(IETF list removed from CCs. Nothing secret here, it just seems
unnecessary to fill several thousand inboxes with this...)
Thanks for the review, Martin. Responses below:
On 02/05/2017 14:39, Martin Thomson wrote:
> Reviewer: Martin Thomson
> Review result: Not Ready
>
> This document describes
at
is the only exposure, and nobody knows a way round it.
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.2.2
After that, all the nodes in the ACP are authenticated.
>
> On 3 May 2017 at 07:06, Brian E Carpenter wrote:
>> (IETF list removed from CCs. Nothing secret he
While responding to Martin Thomson's GRASP review, I had another
look at the ACP draft.
What it says about multicast during ACP creation is fine.
However, I'm still not finding a clear statement that the ACP,
viewed as a VRF instance, will correctly forward GRASP link local
multicasts to all othe
gotiation during a multicast discovery because it lacks any form
> of protection.
>
> On 3 May 2017 at 11:58, Brian E Carpenter wrote:
>> I must say I hadn't thought of RTT as an issue, because we tend to assume
>> that the timescale for an autonomic action will be far greate
On 04/05/2017 00:51, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > One more thing from our tests this week.
>
> > We noticed when testing at busy times that link-local multicasts
> > were often dropped. We would see quite long gaps when dis
Hi,
Before we move the prefix management draft forward, I've been enhancing
the corresponding demonstration ASA to be more realistic. The new version
isn't quite ready for public release yet, but I have made it capable
of dynamically assigning prefixes of any reasonable length on demand
(the previ
Hi,
I've uploaded a new improved version of my demo code for
draft-ietf-anima-prefix-management.
It can be found at https://www.cs.auckland.ac.nz/~brian/graspy/pfxm2.py, but I
advise reading the implementation notes first:
https://www.cs.auckland.ac.nz/~brian/graspy/pfxm2.pdf .
There's also a
On 08/05/2017 14:41, Spencer Dawkins wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-anima-grasp-11: No Objection
...
> In this text,
>
>T6. The protocol must be capable of supporting multiple
> simultaneous
>operations with one or more peers, especiall
Just one point while working on the text:
On 03/05/2017 14:32, Martin Thomson wrote:
...
> On 3 May 2017 at 11:58, Brian E Carpenter wrote:
>> I must say I hadn't thought of RTT as an issue, because we tend to assume
>> that the timescale for an autonomic action will be fa
On 03/05/2017 13:58, Brian E Carpenter wrote:
> On 03/05/2017 12:47, Martin Thomson wrote:
...
>>> The main references for external security are
>>> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra
>>> https://tools.ietf.org/html/draft-ietf
Spencer,
On 10/05/2017 05:13, Spencer Dawkins at IETF wrote:
The bits where we can simply do what you suggest
> Grrr, but please see below.
>
>>
>>>
>>> I'm really confused by this text.
>>>
>>>Nevertheless, when running within a secure ACP on reliable
>>>infrastructure, UDP MAY be use
> > is the definition I am familair with for a normative reference.
>
> > And making it normative couples the publication in the right order.
> Which
> > seems a good indiciation fo teh relationship.
>
> > Yours,
> > Joel
>
>
On 11/05/2017 09:18, Martin Thomson wrote:
> On 11 May 2017 at 05:25, Michael Richardson wrote:
>> GRASP does not stand alone.
>
>
> I have to assess the document on its own merits. As already
> established, there are no normative dependencies on any sort of key
> management.
>
> That this wor
I noticed that the references in the ACP draft are not separated
into Normative and Informative as required.
I think that at least the following should be normative:
[I-D.ietf-anima-bootstrapping-keyinfra]
[I-D.ietf-anima-grasp]
[RFC4193]
[RFC5280]
[RFC5952]
[RFC6347]
[RFC6550]
[RFC6552]
[RFC7676
I have two questions about draft-ietf-anima-prefix-management-03
before we move it forward. As a reminder, the main GRASP objective is
defined like this:
objective = ["PrefixManager", objective-flags, loop-count,
[PD-support, length, ?prefix]]
loop-count = 0..255
ns at IETF wrote:
> Hi, Brian,
>
> On Tue, May 9, 2017 at 9:49 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> Spencer,
>> On 10/05/2017 05:13, Spencer Dawkins at IETF wrote:
>>
>> The bits where we can simply do what you suggest
>
On 18/05/2017 06:04, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > We need to resolve this issue quickly, to get a new draft out in the
> next
> > few days, before the IESG meeting next week.
>
> > So, since I haven't seen any opinio
Hi,
This version is intended to deal with the IESG comments and late reviews so far.
The changes are:
Clarified that GRASP runs in a single addressing realm
Improved wording about FQDN resolution, clarified that URI usage is out of
scope.
Clarified description of negotiation timeout.
Noted
Hi,
This is embarrassing since the GRASP draft is already with the IESG,
but better now than later.
Bill Atwood has been testing the GRASP prototype on a larger setup
than previously, and this has just thrown up an issue in discovery
relaying. (We tried to do this test at the IETF98 hackathon, bu
Hi Alexy,
All your DISCUSS comments are valid and easy to fix. Unfortunately I'm
on personal travel this week so can't update until next week.
Assuming we need a new version, we will of course also review your and
other's COMMENT comments.
Specifically,
> uri-locator = [O_URI_LOCATOR, text
Just cherry-picking a COMMENT point that does need some thinking:
> The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but
> no way to register additional values with IANA. This does not seem
> future-proof.
This is a tricky point. The values are of course already IANA values fr
Again cherry-picking in line, as I'm on vacation travel this week:
On 23/05/2017 13:25, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-anima-grasp-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addr
On 23/05/2017 21:06, Alexey Melnikov wrote:
> Hi Brian,
>
>> On 23 May 2017, at 04:57, Brian E Carpenter
>> wrote:
>>
>> Just cherry-picking a COMMENT point that does need some thinking:
>>
>>> The CBOR definition has constants for IP_PROTO_TCP
On 24/05/2017 03:19, Mirja Kühlewind wrote:
...
> --
> DISCUSS:
> --
>
> 1) Use of transport protocols is not sufficiently defined
At this point I think we are o
Martin,
Thanks for the thorough review. First reactions:
On 23/05/2017 21:05, Martin Stiemerling wrote:
> Hi all,
>
> Please find below my review of draft-ietf-anima-grasp-11.
> The comments below are about -11 of the draft, as I did work on this
> version and did unfortunately not have time to
On 25/05/2017 05:35, Adam Roach wrote:
> On 5/24/17 12:07 PM, Michael Richardson wrote:
>> Adam Roach wrote:
>> > My strong recommendation here would be to define a new GRASP protocol
>> > numbers registry, state that any values in the GRASP registry that
>> > correspond to a protoc
On 25/05/2017 04:52, Michael Richardson wrote:
> Mirja Kühlewind wrote:
> > a TCP connection for the discovery response and require that all other
> > messages to be sent over TCP (also removing any option to use any other
> > reliable transport because TCP seems to be the right choice
On 25/05/2017 08:38, Adam Roach wrote:
> On 5/24/17 2:47 PM, Brian E Carpenter wrote:
>> On 25/05/2017 05:35, Adam Roach wrote:
>>> On 5/24/17 12:07 PM, Michael Richardson wrote:
>>>> Adam Roach wrote:
>>>> > My strong recommendation here
On 26/05/2017 03:34, Adam Roach wrote:
> On 5/25/17 08:58, Michael Richardson wrote:
>> There was a further locator that I tried to create, see:
>>
>> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.2
>
>
> Yes, the fact that we're already seeing this fi
On 26/05/2017 07:37, Michael Richardson wrote:
>
> Joe Touch wrote:
> > Version support is recommended by IANA (see RFC7506, Sec 7.5).
>
> > Extensibility is a separate issue and doesn't replace the benefit of
> > version support.
>
> > The goal is to avoid needing to assign a n
Warren,
Will fix all of those.
As for "as robust as possible", you are correct that it's an empty
phrase. I will change it to "it is essential that every implementation
continues to operate in adverse conditions." While I agree that this
should apply to everything, even the British Airways checki
Hi,
I have started the process of going through IESG comments on the GRASP draft.
Where something is editorial or obviously non-controversial, I will not
ask for input. But I do need input on some things, and here is the first.
Please answer quickly; no answer will be taken to mean that you don't
Alexey,
Skipping your DISCUSSes, which are easy to fix:
> --
> COMMENT:
> --
>
> As a general comment, the document has several SHOULD/MUST level
> requirements
On 23/05/2017 10:40, Adam Roach wrote:
...
> --
> COMMENT:
> --
>
> The document includes a couple of instances of "reasonable" in normative
> statements (e.g., "
On 23/05/2017 10:40, Adam Roach wrote:
...
> The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but
> no way to register additional values with IANA. This does not seem
> future-proof.
Adam is correct. The current values (6 and 17) are of course values from
https://www.iana.org/a
On 23/05/2017 13:25, Ben Campbell wrote:
...
> -7, Grasp Message and Options table: Why "Standards Action"? Would you
> expect some harm to be done if this were only Spec Required?
Personal opinion: I see potential for harm. I could imagine that if
GRASP is a success, then with experience we might
On 23/05/2017 13:25, Ben Campbell wrote:
...
> - Is section 2 [Requirements] expected to be useful to implementers once this
> is> published as an RFC? Unless there's a reason otherwise, I would suggest
> moving this to an appendix, or even removing it entirely. As it is, you
> have to wade throug
Comments on some more of Ben's comments:
On 23/05/2017 13:25, Ben Campbell wrote:
...
> - 3.10.5: "SHOULD NOT be used in
>unmanaged networks such as home networks."
> Why not MUST?
Yes, that is more logical.
>
> -5, Privacy and Confidentiality: Did people consider IP Addresses and
> other po
On 30/05/2017 08:24, Alexey Melnikov wrote:
> Hi Brian,
>
> On 29 May 2017, at 02:57, Brian E Carpenter
> wrote:
>
>>> 3.5.4.3. Discovery Procedures
>>>
>>> In 6th para:
>>>
>>> The cache mechanism MUST include a lifetime for ea
On 30/05/2017 06:49, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > I have started the process of going through IESG comments on the GRASP
> > draft. Where something is editorial or obviously non-controversial, I
> > will not ask for input. But
Responding to Mirja's comments (her DISCUSS points were
already discussed in other messages):
On 24/05/2017 03:19, Mirja Kühlewind wrote:
> --
> COMMENT:
> --
>
On 24/05/2017 08:12, Deborah Brungard wrote:
...
> --
> COMMENT:
> --
>
> The comparison text to routing protocols is outdated as ignores TE
> which can support a
Eric,
On 25/05/2017 14:32, Eric Rescorla wrote:
...
> --
> DISCUSS:
> --
>
> ISSUE 1
> The security situation here is pretty unspecified here, in at least two
>
Right. I believe that the -12 draft already covers most of Martin Thomson's
points, other than what we are still discussing with Eric. Martin Stiemerling's
points need to fixed in the future -13 draft.
Regards
Brian
On 31/05/2017 00:52, Eric Rescorla wrote:
> Yes. Thanks.
>
> -Ekr
>
>
> On
On 31/05/2017 05:02, Michael Richardson wrote:
>
> Eric Rescorla wrote:
> > It's the job of this group of specifications to provide a complete
> > security story, so it must either be here or it must be in some other
> > document which is normatively referenced from here and which the
On 31/05/2017 05:11, Michael Richardson wrote:
>
>ekr> 2. I didn't find the security model very clear. As I understand
>ekr> things, basically anyone on the network who has ACP credentials is
>ekr> trusted to engage in negotiation with you, so, for instance, if you
>ekr> want to ge
On 31/05/2017 08:47, Eric Rescorla wrote:
> On Tue, May 30, 2017 at 1:37 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> On 31/05/2017 05:02, Michael Richardson wrote:
>>>
>>> Eric Rescorla wrote:
>>> > It's the j
On some other points that are dangling after previous messages:
On 31/05/2017 00:29, Eric Rescorla wrote:
> On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> Eric,
>>
>> On 25/0
Now getting to Eric's COMMENTs:
On 25/05/2017 14:32, Eric Rescorla wrote:
...
> --
> COMMENT:
> --
>
>
> S 3.5.4.3.
>After a GRASP device successfully disco
On 31/05/2017 11:30, Eric Rescorla wrote:
> On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> On some other points that are dangling after previous messages:
>>
>> On 31/05/2017 00:29, Eric Rescorla wrote:
>>>
On 31/05/2017 14:17, Eric Rescorla wrote:
> On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> Now getting to Eric's COMMENTs:
>>
>> On
On 01/06/2017 08:36, Ben Campbell wrote:
> Hi, thanks for the responses. Further comments below. I deleted sections
> that seem resolved.
>
> Thanks!
>
> Ben.
>
>> On May 28, 2017, at 11:16 PM, Brian E Carpenter
>> wrote:
>>
>> Comments on some m
Eric,
On 01/06/2017 09:09, Eric Rescorla wrote:
>
>
> On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter
> mailto:brian.e.carpen...@gmail.com>> wrote:
>
> On 31/05/2017 14:17, Eric Rescorla wrote:
> > On Tue, May 30, 2017 at 6:32 PM, Brian E Carp
On 01/06/2017 00:59, Eric Rescorla wrote:
>
>
> On Tue, May 30, 2017 at 6:59 PM, Brian E Carpenter
> mailto:brian.e.carpen...@gmail.com>> wrote:
>
> On 31/05/2017 11:30, Eric Rescorla wrote:
> > On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter <
&g
On 31/05/2017 04:37, Michael Richardson wrote:
> Brian E Carpenter wrote:
>
> >> Brian E Carpenter wrote: > I have
> >> started the process of going through IESG comments on the GRASP >
> >> draft. Where something is editorial or obviously n
We can do that, when we need it. To get the draft out of the door, I'll do what
was previously suggested:
> Proposal: Note in the text that the current values are taken from the
> existing Protocol Numbers registry. Also note that if values are required
> in future that are not in that registry, a
On 30/05/2017 06:51, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> >> -7, Grasp Message and Options table: Why "Standards Action"? Would you
> >> expect some harm to be done if this were only Spec Required?
>
> > Personal opinion
On 29/05/2017 16:02, Brian E Carpenter wrote:
> On 23/05/2017 13:25, Ben Campbell wrote:
> ...
>> - Is section 2 [Requirements] expected to be useful to implementers once
>> this is> published as an RFC? Unless there's a reason otherwise, I would
>> suggest
>&g
On 03/06/2017 01:22, Toerless Eckert wrote:
> Dear authors:
>
> some comments/questions/suggestions for GRASP:
>
> P1: 3.8.4:
> " In a more complex implementation, the GRASP discovery mechanism will find,
> for each interface, a dynamic port that it can bind to for both UDP and TCP
> before
On 05/06/2017 02:54, Toerless Eckert wrote:
> On Sat, Jun 03, 2017 at 01:28:03PM +1200, Brian E Carpenter wrote:
>> On 03/06/2017 01:22, Toerless Eckert wrote:
>>> Dear authors:
>>>
>>> P1: 3.8.4:
>>> " In a more complex implementation, the GRASP d
This version includes a second round of responses to IESG comments.
We may not be done yet, but please check the diffs. Here are the main changes:
Removed all mention of TLS, including SONN, since it was under-
specified.
Clarified other text about trust and security model.
Banned R
On 06/06/2017 11:41, Max Pritikin (pritikin) wrote:
>
>> On Jun 5, 2017, at 4:22 PM, Brian E Carpenter
>> wrote:
>>
>> This version includes a second round of responses to IESG comments.
>>
>> We may not be done yet, but please check the diffs. Here are th
t; O_IPV4_TE_LOCATOR, O_IPV6_TE_LOCATOR and O_FQDN_TE_LOCATOR (TE = Transport
> Endpoint).
I agree that there's a difference of nature between them and a URI (I =
Identifier)
but I don't think renaming really helps. What I have put in the -13 draft is
Alexey's suggestion but w
> peers.
> GRASP does not need to know the addresses of neighbors because it addresses
> neighbors via link-local multicast (M_DISCOVERY and M_FLOOD).
>
> The section 2.5.2 about constrained instances :
>
> With my proposed text qove IMHO you would not need any additional te
On 07/06/2017 12:11, Toerless Eckert wrote:
> [darn, second mail header typo on my side. sorry.]
>
> Dear authors
>
> Some feedback for the PD draft:
>
> 1. Relationship to DHCPv6 PD:
>
> The note in 4.3 makes it sound as if there is a concern by the authors that
> this proposal
> could potent
Just on one rather general point:
> If we try to find a good place outside the main GRASP spec for this type of
> explanatory text, which draft could that be ?
I think we may need a GRASP implementer's guide. Whether it should
be an RFC or a wiki page is a separate question.
I also guess we will
On 07/06/2017 04:09, Toerless Eckert wrote:
> On Mon, Jun 05, 2017 at 10:56:07AM +1200, Brian E Carpenter wrote:
>>> IMHO, the discover multicast message needs to have another message element
>>> which is the
>>> port number to reply to. Thats assuming the reply i
On 08/06/2017 07:24, Toerless Eckert wrote:
...
>> I agree with Brian's suggestion about deleting the PD issue from this
>> document.
>>
>> It is a realization problem and deleting it will not cause too much
>> misunderstanding.
>
> Instead of deletion it might be more helpful to write te
Mainly agreed, but see in line..
On 08/06/2017 08:55, Toerless Eckert wrote:
> On Wed, Jun 07, 2017 at 12:38:42PM +1200, Brian E Carpenter wrote:
>> EKR didn't like the loose mention of TLS. It would be perfectly
>> fine to revive SONN in the ACP draft or even in a separate
&g
301 - 400 of 837 matches
Mail list logo
