I am having trouble connecting your reply with my request.
Let's take the direct issue first, and then the analogy.
I had suggested a specific enhancement to device behavior. The response
was "but that removes the theft protection." It is that form of theft
protection that I am objecting to.
Thanks. I’ll clear my block when the 2.0.9 version gets uploaded to the
datatracker.
Alissa
> On Jul 16, 2019, at 5:30 AM, Sheng Jiang wrote:
>
> Dear Alissa,
>
> Could you check whether the latest 2.0.9 version on WiKi addresses your
> block. If not, we would like to further modify it
Hi Joel,
> On 15 Jul 2019, at 23: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
Hi Joel,
> On 16 Jul 2019, at 14:59, Joel Halpern Direct
> wrote:
>
> I am having trouble connecting your reply with my request.
> Let's take the direct issue first, and then the analogy.
>
> I had suggested a specific enhancement to device behavior. The response was
> "but that removes
Dear Alissa,
Could you check whether the latest 2.0.9 version on WiKi addresses your block.
If not, we would like to further modify it according to your new feedback. We
really would like to see progress on rechartering. Many thanks.
https://trac.ietf.org/trac/anima/wiki/Recharter2019
Dear
Hi, all,
The below is the list that the chairs received time-slot requests for the ANIMA
meetings in the coming IETF 105 next week. Could you check any items missed? If
yes, please contact the chairs by this Wednesday. Afterwards, chairs would
arrange the agenda accordingly.
Thanks and
Toerless Eckert wrote:
>> And if the consumer needs to fallback to some non-BRSKI mechanism he
>> is expected to bootstrap the device via serial console himself? Trying
>> to see if I understand the scope limitations explained in Section 9.
> Non-BRSKI operators have to
Alexey Melnikov via Datatracker wrote:
> 1) In Section 5:
>o In the language of [RFC6125] this provides for a SERIALNUM-ID
> category of identifier that can be included in a certificate and
> therefore that can also be used for matching purposes. The
> SERIALNUM-ID
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.
> On 16 Jul 2019, at 15: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?
I think I do because I proposed such a mechanism up thread.
Eliot
>
> Yours,
> Joel
>
> On 7/16/2019 9:40 AM, Eliot Lear
I suggest that EST servers are never on port 80, and are likely
on port 443, or another port.
6.1.4.1. GRASP objective for EST server
ACP nodes that are EST servers MUST announce their service via GRASP
in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp],
section 2.8.11
{I almost hit the 'n'ext key on this email when I read you had No
Objection... I wonder if the DT should link the comments in the DT
to the thread that results}
Mirja Kühlewind via Datatracker wrote:
> I agree with Alissa's discuss that the conclusion of section 10(.3)
> should be to
Thanks
Added to issues on github.
Waiting for an IESG review to come back to me then i can do the
next rev and fix this as well.
Cheers
Toerless
On Tue, Jul 16, 2019 at 12:58:20PM -0400, Michael Richardson wrote:
>
> I suggest that EST servers are never on port 80, and are likely
> on port
Ted Hardie wrote:
> Howdy,
> I would personally not suggest using IRIs here, given that the scheme
> (https) is expected to retrieve a resource at a well-known location and
> thus will always have to be mapped to a URI to do the retrieval (rather
> than used in a string
> > I would personally not suggest using IRIs here, given that the scheme
> > (https) is expected to retrieve a resource at a well-known location and
> > thus will always have to be mapped to a URI to do the retrieval (rather
> > than used in a string comparison or something
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:
>
Michael --
Thanks so much for your work on closing this issue. Assuming the rest of
the WG agrees with it, your proposed text satisfies my concern. I've
indicated two minor nits below.
On 7/16/19 12:55 PM, Michael Richardson wrote:
As specified in the ANIMA charter, this
Adam,
Not sure if you saw my reply to Alissas comments, but my biggest concern
no only to fudge more and more bits and pieces into thre tailend of this
draft (+1 to birans comment), but also to continue fudge them as protocol
extensions into the BRSKI protocol when in reality the problems we
I have responded to DISCUSSes from:
Alissa Cooper:
https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm_gPVBl5uSrU
Roman Danyli:
https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI
Alexey Melnikov
Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-19: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Not Eric, but playing that role for a bit...
On Mon, Mar 11, 2019 at 04:31:45PM +0100, Toerless Eckert wrote:
> Thanks Eric, inline
>
> This file is:
> https://github.com/anima-wg/autonomic-control-plane/blob/master/draft-ietf-anima-autonomic-control-plane/16-eric-rescorla-reply.txt
>
> The
Hi Toerless,
On Mon, Mar 11, 2019 at 04:32:14PM +0100, Toerless Eckert wrote:
> Thanks Benjamin,
>
> This file is:
> https://github.com/anima-wg/autonomic-control-plane/blob/master/draft-ietf-anima-autonomic-control-plane/16-ben-kaduk-reply.txt
>
> The following inline answers to your discuss
On 7/16/19 5:14 PM, Michael Richardson wrote:
Adam Roach:
https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA
...
This is an rfcdiff from the already-wrapped JSON to the proposed -23 that
includes all the changes from the various DISCUSSes up to now:
Adam Roach wrote:
> "HTTP", but even that may be unnecessary in this case.
> REST means... something. Exactly what depends on who you ask. In
> practice, the least controversial thing to do is avoid the term; and,
> if you're trying to describe a specific quality (e.g.,
Joel Halpern Direct wrote:
> It allows someone who
> controls their network, and who physically controls a new device, to
> put that new device in their network without asking anyone's
> permission.
Right, get your "blue cable" out, connect it to the serial console, bring up
Adam Roach wrote:
mcr> *** but manufacturers have to want to do it ***
adam> I completely agree with everything you just said, and sincerely
adam> thank you for the work you've done in this area. I think where our
adam> perspectives might diverge is our beliefs about what *we*,
Adam Roach wrote:
> On 7/15/19 3:38 PM, Brian 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
Up-levelling the topic a little bit:
It seems to me that from the amount of interest and discussion, BRSKI
is going to be quite important (or a resounding failure, in which case
this is all beside the point). Assuming it's a success, there will
inevitably be updates and enhancements.
So, I'd
With the mandates that Michael proposed adding, I can live with
advancing the document.
Yours,
Joel
On 7/16/2019 4:31 PM, Brian E Carpenter wrote:
Up-levelling the topic a little bit:
It seems to me that from the amount of interest and discussion, BRSKI
is going to be quite important (or a
Adam Roach wrote:
>> On Jul 15, 2019, at 02:39, Eliot Lear wrote:
>>
>> This give you the option for that not to be the case (people needn’t
>> worry about Siemens, Rockwell, JCI, Honeywell, or Schneider Electric
>> going out of business anytime soon, for instance
>
Hi Toerless,
> On 17 Jul 2019, at 00:03, Toerless Eckert wrote:
>
>
> Not sure yet how to best do that, hopefully something we can discuss @105.
To the general idea… it may be worth setting some time at the end of the ANIMA
WG meeting for this, or even in the onboarding/mud side meeting.
31 matches
Mail list logo
