Re: [Ace] Gen-ART Last Call review of draft-ietf-ace-extend-dtls-authorize-05

[Paul Kyzivat <[e-mail]>]

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 <[e-mail]>
> *Date: *Friday, 20 January 2023 at 18:32
> *To: *[e-mail] 
> <[e-mail]>
> *Cc: *General Area Review Team <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>
> *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.
>