Sheng, unless I have misunderstood Brian rather thoroughly, the port
numbers in the proposal are TCP or UDP port numbers. They are not some
other number / name space. The point is to be able to leverage the
kernel demuxing which relies on those port numbers to get traffic to
multiple user spac
I believe your description, and that of others as to what we "intend",
does not line up with the definition you quote.
The text says that an ASA "implements an autonomic function." That
seems to say that I sould expect an autonomic function to be implemented
by an ASA, thus implying a 1-1 rel
/ASA.
Please see sections 3+.
Feedback on the text is most welcome as this will be presented at
IETF96/Berlin.
Best regards, Laurent.
On 11/07/2016 14:55, Joel M. Halpern wrote:
I believe your description, and that of others as to what we "intend",
does not line up with the definition
It strikes me that if we wish to allow for inter-domain communication
using GRASP, in conjunction with intra-domain usage, then the security
considerations are more complex than noted so far.
I think this can be addressed by writing security considerations text
that explicitly talks about the
COuld any of the folks involved with low power answer one question this
note suggests?
As I understqnd it, low power devices are usually viewed as having
limited capabilities.
Thus, I would normally expect to see their autonomic functions handled
by a proxy, much as a COAP gateway provides con
Connectivity Foundation is also using CoAP across a wide range of
platform capabilities.
On 8/3/2016 10:14 AM, Joel M. Halpern wrote:
COuld any of the folks involved with low power answer one question
this note suggests?
As I understqnd it, low power devices are usually viewed as having
limited
The question that occurs to me is whether the pre-ACP discovery phase
needs privacy protection.
The answer is not obvious, since the scope is limited (where DNS queries
can go arbitrary distances across the net.)
Yours,
Joel
On 3/11/17 2:20 PM, Brian E Carpenter wrote:
On 12/03/2017 08:08,
Claiming that ACP is not a normative reference for GRASP, since GRASP is
to run on ACP, seems a stretch.
Yes, if there is a library or API to call, that masks the knowledge.
But that could be said of a lot of normative references.
Put differently, it has seemed to me that I need to understand a
If, as he says, that is the best current practice then lets go for it.
Joel
On 5/28/17 9:38 PM, Brian E Carpenter wrote:
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
Given our experience with file transfers, several things seem to be
called for:
1) There should be a mechanism for the sender to initiate. Several of
the use cases you cite are such that the sender would better than the
receiver when it is a good time to send the data.
2) I realize that it
able to perform the transfers.
This does edge into the argument about how much size and work it would
be to just use the code for an existing protocol.
Yours,
Joel
On 9/12/17 12:56 AM, Brian E Carpenter wrote:
Hi Joel, thanks for the rapid comments. More in-line:
On 12/09/2017 15:17, Joel M
Comments in line. Areas of clear agreement elided.
On 5/7/18 3:30 PM, Toerless Eckert wrote:
Joel,
Sorry for the late reply. Bufferbloat.
Okay. Thank you for addressing a number of the points effectively.
Let's see if we can solve the remaining items.
The definition of data-plane se
Trimmed.
Top posting for clarity. Mostly, agreement.
On the MTI Security, I will leave it to the relevant ADs to decide if
they find what is in there sufficient.
On the identifier vs locator, I think the way you are using the terms is
confusing. But it is not worth continued argumentation.So
hone
Original message From: Toerless Eckert Date: 5/14/18 05:04
(GMT-05:00) To: "Joel M. Halpern" Cc: rtg-...@ietf.org,
draft-ietf-anima-autonomic-control-plane@ietf.org, i...@ietf.org, anima@ietf.org Subject: Re:
[Anima] Rtgdir telechat review of
dr
Even if the WG concluded it did not want to address some of the issues
from by Routing Directorate review, I would have expected a revision to
address the lesser issues that had been agreed to, before the IESG could
vote on the document.
Yours,
Joel
On 5/18/18 4:24 PM, Brian E Carpenter wrote
Thank you for all your work on this.
While I still find the presence of the address allocation mechanism
strange to find in this document, I can live with it. So with this
complaint done, I will shut up about it already.
Aside from some items noted below, this seems to be in good shape.
Mod
autonomic-control-plane-16.txt
Cheers
Toerless
On Thu, Jun 07, 2018 at 05:09:37PM -0400, Joel M. Halpern wrote:
Thank you for all your work on this.
While I still find the presence of the address allocation mechanism strange
to find in this document, I can live with it.
So with this complain
I await Michael's comments. A few in line responses (marked
where I think I may have been misunderstood. I have trimmed the rest.
As noted in the elided text, these are all concerned with clarity.
Yours,
Joel
On 8/10/18 1:10 AM, Toerless Eckert wrote:
On Thu, Aug 09, 2018 at 06:00:39P
er we reference them, or
whether those references are normative. No mater how much we wish
otherwise :-)
On 8/10/18 12:12 PM, Toerless Eckert wrote:
On Fri, Aug 10, 2018 at 10:12:37AM -0400, Joel M. Halpern wrote:
Imho, the reference model text is correct. Just like in the non-autonomic
Thank you Michael.
Seems that we are good.
Yours,
Joel
On 8/17/18 10:36 AM, Michael Richardson wrote:
Joel Halpern wrote:
> Does section 3.3.2 intend to mandate that devices have persistent
> storage for the LDevID? Or is it trying to say that on power cycle it
> stays in En
That answer seems to imply that if the MASA is down before I try to
transfer my device, and if the MASA is still down when the recipient
tries to get my device working, it won't work.
Which seems to mean that once a MASA goes down permanently, any new can
not get a device reliant on that MASA
Off-list:
It sounds from you rnote like either:
1) Anima admission process is seriously underspecified in a way that
affects itneroperability, or
2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and
advanced (if desired) by some other working group.
I doubt either is your inte
I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a
critical aspect of whether the BRSKI work is acceptable.
I have assumed that what we needed is the ability for a buyer, who has
physical possession of the device, and possibly some simple
ian E Carpenter wrote:
On 15-Jul-19 16:45, Joel M. Halpern wrote:
I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a
critical aspect of whether the BRSKI work is acceptable.
I have assumed that what we needed is the ability for a buyer, who has
phy
19 09:42, Joel M. Halpern wrote:
I would probably go a step further than Adam. Protecting the device so
a thief can not use it in the thiefs' own network seems to me to be
something that we should not be trying to achieve. An active non-goal.
It is not our problem. And trying to achieve
I can't tell from this whether you agree that it is reasonable to put in
some mechanism to address this issue?
Yours,
Joel
On 7/16/2019 9:40 AM, Eliot Lear wrote:
Hi Joel,
On 16 Jul 2019, at 14:59, Joel Halpern Direct
wrote:
I am having trouble connecting your reply with my request.
Let
Thank you Michael. I saw the proposed change in section 9. I wonder if
that is hiding the MUST, since the mechanisms are in section 7...
Having said that, I can live with it as you have proposed.
Yours,
Joel
On 7/16/2019 3:47 PM, Michael Richardson wrote:
Joel Halpern Direct wrote:
>
Brian Carpenter
On 17-Jul-19 01:57, Joel M. Halpern wrote:
I can't tell from this whether you agree that it is reasonable to put in
some mechanism to address this issue?
Yours,
Joel
On 7/16/2019 9:40 AM, Eliot Lear wrote:
Hi Joel,
On 16 Jul 2019, at 14:59, Joel Halpern Direct
wr
All three of those sound like improvements.
WHichever one you and the working group pick would clearly help.
Thank you,
Joel
On 7/17/2019 5:13 PM, Michael Richardson wrote:
Joel M. Halpern wrote:
> Thank you Michael. I saw the proposed change in section 9. I wonder
> if t
Thanks Brian. Given the amount of text below, I am going to top-post.
On the Zone IDs, personally, I would remove all of the text about
non-zero ZoneIDs, and replace it with a simple statement that it is
expected to be used for future work on aggregatable addressing to
improve scaling.
On L
would be fine
with that. It is clearly supplementary. I am just trying to avoid
confusion if we choose to describe it.
Yours,
Joel
On 4/10/2020 5:27 PM, Michael Richardson wrote:
Joel M. Halpern wrote:
> On Loopback, I understand your frustration with the lack of a g
I suspect that for most GRASP purposes, even if there is a layer 2
network between the parties, we are not much worried about how LAG
handles GRASP packets? If we care about that, then the source port
should be randomized between flows, and stable for sequences of related
messages.
Yours,
/2020 10:54 PM, Michael Richardson wrote:
Joel M. Halpern wrote:
> I suspect that for most GRASP purposes, even if there is a layer 2
network
> between the parties, we are not much worried about how LAG handles GRASP
> packets? If we care about that, then the source port
My apologies for the delay in responding to these comments.
The changes seem to nicely address all of my comments. I hope that I
will recall this well enough to avoid introducing triple-jeopardy by
accident. (Having said that, it appears that my pushing on some of
these issues a second time c
34 matches
Mail list logo
