Hi Martine,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Martine Sophie Lenders
> Envoyé : mardi 30 juillet 2024 12:43
> À : c...@ietf.org; dnsop@ietf.org; BOUCADAIR Mohamed INNOV/NET
>
> Objet : Re: [core] Re: Fwd: WG Adoption Call for draft-lenders-
> core-coap-dtls-
Hi Carsten, all,
There is a mismatch between what is claimed in the abstract/into vs. core
documents. Concretely, when reading "This document specifies the usage of
Service Parameters.." or "This document specifies which information from
SvcParams ..", I thought this is a discussion about the a
Authors: Dan Wing
> Tirumaleswar Reddy
> Neil Cook
> Mohamed Boucadair
>Name:draft-ietf-dnsop-structured-dns-error-09.txt
>Pages: 23
>Dates: 2024-07-28
>
> Abstract:
>
>DNS filtering is widely deploye
Hi Gert,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Gert Doering
> Envoyé : lundi 10 juillet 2023 08:53
> À : BOUCADAIR Mohamed INNOV/NET
> Cc : Ted Lemon ; v6...@ietf.org; Xipengxiao
> ; dnsop
> Objet : Re: [v6ops] DNS64/Thread RE: [DNSOP] WG call for adoption:
> dr
Hi Ted,
(Changed the subject for convenience)
I was told that PCP was required in Matter/Thread(?). Do you know if the
discovery of the prefix is based on RFC7225? Thanks.
For your last point: problems may arise if a distinct pref64 is used by the
upstream DNS64 than the one used locally. Unle
Hi all,
> So instead of creating documents for every possible protocol that
> uses IPv4 literals, why not create one document that describes how
> to deal with IPv4 literals in existing protocols in the context of
> NAT64?
>
We do already have rfc7051 + many pref64 discovery RFCs out there. RFC7
Hi Mukund,
Many thanks for the detailed review.
We updated the spec to address many of your suggestions. We added in particular
text to explain the rationale for having c/j mandatory for IT teams and also
added text to explain why suberr is defined rather than consuming ede codes.
However, n
Hi Philip, all,
I agree about your DNS64 comments.
Actually DNS operations are not impacted at all; all what this draft is about
is related to transport. The draft is simply about an application that is
behind a NAT64 and which uses RFC6052 to build IPv4-embeded IPv6 address to
reach an upstr
Hi Matt, Di,
Thank you for the follow-up.
We released a new version that addresses both your reviews. FWIW, a diff to
track the changes can be seen at:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-structured-dns-error-03&url2=draft-ietf-dnsop-structured-dns-error-04&difftype=--ht
Hi Matt,
Thank you for the review.
Please see inline. I let my co-author further comment as appropriate.
Cheers,
Med
> -Message d'origine-
> De : Matt Brown via Datatracker
> Envoyé : vendredi 30 juin 2023 00:01
> À : dns...@ietf.org
> Cc : dnsop@ietf.org; draft-ietf-dnsop-structured-
Hi Di,
Thanks for the review.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Di Ma via Datatracker
> Envoyé : lundi 26 juin 2023 07:59
> À : dns...@ietf.org
> Cc : dnsop@ietf.org; draft-ietf-dnsop-structured-dns-
> error@ietf.org
> Objet : Dnsdir early review of dra
Hi Martine, all,
FWIW:
With regards to [1], and given that DNR was explicitly mentioned, please note
that the DNR version in the RFC Editor queue says:
The "alpn" SvcParam may not be required in contexts
such as a variant of DNS over CoAP where messages are encrypted
using
12 matches
Mail list logo
