Jürgen, you did a great review back in April.
We recently made a bunch of revisions to constrained-join-proxy.
In the end, we have replaced our custom "JPY" encapsulations with a CoAP
header. The cost in the end is two bytes, and the result is that it is
identical to RFC9031.
We have also
JUst my 2 cents:
The code for stateless and stateful is really small.
No need to worry about code memory requirements when saying that both
modes MUST be supported by join-proxy.
Once both modes are supported the dynamic choice becomes possibel.
Peter
Michael Richardson schreef op
Rob Wilton \(rwilton\) wrote:
> If it is okay to require that join proxies always implement the
> stateful mode, and that seems to have superior behaviour, then it there
> a reason why we want to standardize the stateless mode at all?
I think that the MUST implement both for the
: Toerless Eckert ; last-c...@ietf.org; ops-...@ietf.org;
draft-ietf-anima-constrained-join-proxy@ietf.org; anima@ietf.org; Jürgen
Schönwälder
Subject: Re: [Anima] Opsdir last call review of
draft-ietf-anima-constrained-join-proxy-09
Hi Rob,
I just added the following text
>>NEW
A Join
der Stok
Cc: Rob Wilton (rwilton) ; last-c...@ietf.org; ops-
d...@ietf.org; draft-ietf-anima-constrained-join-proxy@ietf.org;
anima@ietf.org; Jürgen Schönwälder
Subject: Re: [Anima] Opsdir last call review of
draft-ietf-anima-constrained-
join-proxy-09
Hi Rob,
We just had another meeting
;
> anima@ietf.org; Jürgen Schönwälder
> Subject: Re: [Anima] Opsdir last call review of draft-ietf-anima-constrained-
> join-proxy-09
>
> Hi Rob,
>
> We just had another meeting of the design team and feel it is necessary to do
> some
> move of text about discovery from
f.org; Jürgen
> Schönwälder
> Subject: Re: [Anima] Opsdir last call review of
> draft-ietf-anima-constrained-join-proxy-09
>
> HI Rob,
>
> thanks for the quest for clarifications.
> I want to discuss with my co-authors first, before committing to some text.
> Once the
t; From: Peter van der Stok
> > Sent: 07 June 2022 14:43
> > To: Rob Wilton (rwilton)
> > Cc: last-c...@ietf.org; ops-...@ietf.org;
> > draft-ietf-anima-constrained-join-proxy....@ietf.org; anima@ietf.org;
> > Jürgen Schönwälder
> > Subject: Re: [Anima] O
Sent: 07 June 2022 14:43
To: Rob Wilton (rwilton)
Cc: last-c...@ietf.org; ops-...@ietf.org;
draft-ietf-anima-constrained-join-proxy@ietf.org; anima@ietf.org;
Jürgen Schönwälder
Subject: Re: [Anima] Opsdir last call review of
draft-ietf-anima-constrained-join-proxy-09
HI Rob,
thanks
: [Anima] Opsdir last call review of
draft-ietf-anima-constrained-join-proxy-09
HI Rob,
thanks for the quest for clarifications.
I want to discuss with my co-authors first, before committing to some text.
Once the new text is ready, a new version will be uploaded.
greetings,
Peter
Rob Wilton
From: Peter van der Stok
Sent: 06 April 2022 08:38
To: Peter van der Stok
Cc: last-c...@ietf.org; ops-...@ietf.org;
draft-ietf-anima-constrained-join-proxy@ietf.org; anima@ietf.org
Subject: Re: [Anima] Opsdir last call review of
draft-ietf-anima-constrained-join-proxy-09
Hi Jurgen,
- Conce
so.
Thanks,
Rob
From: Peter van der Stok
Sent: 06 April 2022 08:38
To: Peter van der Stok
Cc: last-c...@ietf.org; ops-...@ietf.org;
draft-ietf-anima-constrained-join-proxy@ietf.org; anima@ietf.org
Subject: Re: [Anima] Opsdir last call review of
draft-ietf-anima-constrained-join-proxy-09
Brian E Carpenter wrote:
> (I can see some issues with that as applied in a pure mesh
> network, where we'd need a mechanism to prevent every pledge
> also becoming a join proxy.)
There is work in ROLL that deals with some of this concern.
Specifically that in constrained LLNs,
Hi Jurgen,
- Concerning the discussion on one or two options:
I just want to add that there are manufacturerer organizations l(e.g.
OCF and Thread) that specify which parts of IETF RFCs need to be present
in the devices deployed in an installation. Manufacturers respond to
these specs by
Hi Jürgen,
On 05-Apr-22 20:36, Jürgen Schönwälder wrote:
...
Pvds==>
Now I am confused. I expected you to require more text here.
Something seems to be missing in the description of the base line scenario,
and I need more info to understand what the missing pieces are.
I think it is rather
Jürgen Schönwälder wrote:
>>
>> We could add normative language for one option only. We prefer that
based on
>> use cases, an installation engineer could choose one option over the
other.
>> The simplest option is stateful which is common in today's translation
>> devices,
Reactions inline...
On Tue, Apr 05, 2022 at 10:05:16AM +0200, Peter van der Stok wrote:
>
>
> Hi Jurgen,
>
> Thanks for the review. I sympathize with your confusion issues. Many times I
> shared the same confusion on other IETF documents that I thought relevant
> for my work. IETF documents
Hi Jurgen,
Thanks for the review. I sympathize with your confusion issues. Many
times I shared the same confusion on other IETF documents that I thought
relevant for my work. IETF documents are not encouraged to rephrase
parts of other RFCs or provide large operational HOWTO considerations.
Jürgen Schönwälder via Datatracker wrote:
> Let me start with a disclaimer: I am not familiar with BRSKI and ANIMA
...
Maybe reading RFC9030 and RFC9031 is really needed, and maybe we need more
references to that kind of architecture.
Note that RFC9031 uses OSCORE with PSKs, while this
Reviewer: Jürgen Schönwälder
Review result: Serious Issues
Let me start with a disclaimer: I am not familiar with BRSKI and ANIMA
and hence I have been reading this I-D as a confused outsider and some
of my concerns may not be valid or the result of me not understanding
the relevant technologies.
20 matches
Mail list logo
