On Dec 20, 2019, at 01:47, Benjamin Kaduk wrote:
>
>> The statement above
>>
>> When omitted, they are logically
>> assumed to be the transport protocol destination address and port
>> respectively. Explicit Uri-Host and Uri-Port Options are
>> typically used when an
Thanks Magnus.
> The EST-coaps client MUST support
> Block1 only if it sends EST-coaps requests with an IP packet size
> that exceeds the Path MTU.
>
> I think the requirement for when Block1 is required to be supported in the
> above sentence is unclear. Is the intention to say: An EST-coaps
Hi Alissa,
Thank you for the feedback.
> "It is also RECOMMENDED that the Implicit Trust Anchor database used
> for EST server authentication is carefully managed to reduce the
> chance of a third-party CA with poor certification practices
> jeopardizing authentication."
>
> This strikes me
On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-ace-coap-est-17: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and
On Wed, Dec 18, 2019 at 03:47:04PM +, Cigdem Sengul wrote:
> Dear Francesca,
>
> Thank you for your responses to my comments.
> My comments are inline.
>
> >
> >
> > In the following, I list a few things reading the draft made me think,
> > especially in its applicability to MQTT:
> >
> >
Hi, Ludwig.Thanks for the prompt response.Regarding he major issue, I
understand what the intention of the split was, but as far as early
implementations are concerned, there is no such thing as a 'minimal breakage';
unless there is some cunning mechanism in the basic ace-oauth-authz protocol,
Magnus Westerlund has entered the following ballot position for
draft-ietf-ace-coap-est-17: 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.)
Please refer to
