Hi John,
On 1/22/23 3:40 AM, John Mattsson wrote:
Hi Paul,
Thanks for you review.
I very much agree with you that this should have been part of the RFC
9202. In fact, I pointed out the need for TLS compatibility very early
in the standardization process. The situation right now is that this was
unfortunately not done, and that TLS/TCP is very much needed for the
3GPP use of RFC 9202. This should have been standardized yesterday, so
any increased delay would not be good. 3GPP is waiting for this draft. A
future update to RFC 9202 might be worth doing.
It will be for the wg, ad, and iesg to decide if compromising the
quality of the document to meet this schedule desire is an acceptable
compromise.
But it fails to dothe work of actually making those revisions. It leaves
that work to the reader. It is hard to believe that all readers will
infer the identical set of changes.
I don’t see what is missing and what would be hard to infer, and I am
not an author of RFC 9202.
There is general language that needs to be applied to many parts of
9202. I'm sure the authors this this is clear and unambiguous, but I
don't think so.
It would be more constructive if you could
provide advice on how to improve draft-ietf-ace-extend-dtls-authorize.
It could emumerate every required change to 9202. Effectively a diff,
though it needn't be formally written in the form of a diff.
But doing that is comparable in difficulty to actually creating an
rfc9202bis.
If this isn't done, and the current doc becomes a standards track rfc,
then every implementer will need to do the same work.
I suggest that this document's status be changed to an informational
I think it would be strange if DTLS transport is standards track and TLS
is informal. Also Informational is not compatible with the current IANA
actions. I would suggest not doing this.
My point is to view it as requirements work for an rfc9202bis. Such a
document, if published, would be informational. But these days it seems
that there is a trend to leave such documents as drafts rather than
progressing them to informational rfcs.
Thanks,
Paul
Cheers,
John
*From: *Paul Kyzivat <pkyzivat@xxxxxxxxxxxx>
*Date: *Friday, 20 January 2023 at 18:32
*To: *draft-ietf-ace-extend-dtls-authorize.all@xxxxxxxx
<draft-ietf-ace-extend-dtls-authorize.all@xxxxxxxx>
*Cc: *General Area Review Team <gen-art@xxxxxxxx>, last-call@xxxxxxxx
<last-call@xxxxxxxx>, ace@xxxxxxxx <ace@xxxxxxxx>
*Subject: *Gen-ART Last Call review of
draft-ietf-ace-extend-dtls-authorize-05
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
Document: draft-ietf-ace-extend-dtls-authorize-05
Reviewer: Paul Kyzivat
Review Date: 2023-01-20
IETF LC End Date: 2023-01-24
IESG Telechat date: ?
Summary:
This draft is on the right track but has open issues, described in the
review.
Issues: 1
1) ISSUE: Form and completeness of the document
This document reads as a good concept document proposing how RFC 9202
could be revised to allow use of both TLS and DTLS. But it fails to do
the work of actually making those revisions. It leaves that work to the
reader. It is hard to believe that all readers will infer the identical
set of changes.
I suggest that this document's status be changed to an informational,
and then work begin on an rfc9202bis document that incorporates the
proposed changes.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
