Hi Rich, I believe the “obsoleting” path is a better choice here. In general, the “Updates” field can be interpreted in different ways, while “Obsoletes” is straightforward. In addition, 6125 does not have other documents updating it, so that information would not be lost by obsoleting it. Just be mindful of the risk of re-discussing old points not in scope of the current I-D, as Michael says.
Francesca From: "Salz, Rich" <[email protected]> Date: Friday, 21 May 2021 at 18:27 To: Spencer Dawkins at IETF <[email protected]>, Michael Richardson <[email protected]>, Francesca Palombini <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san Francesca do you have any guidance? No rush, I have a month to publish another draft :) From: Spencer IETF <[email protected]> Date: Saturday, May 15, 2021 at 6:50 PM To: Michael Richardson <[email protected]> Cc: Rich Salz <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san For what it's worth, On Fri, May 14, 2021 at 1:52 PM Michael Richardson <[email protected]<mailto:mcr%[email protected]>> wrote: Salz, Rich <[email protected]<mailto:[email protected]>> wrote: > That is great to hear, thanks for the careful analysis. >> Some nits: > All look like good things to do, I'll make a PR soonish. > What do you think of just rewriting this to completely replace 6125, > rather than trying to be a "diff RFC"? If you mean, rfc6125bis, then it seems like it would risk opening wounds. But, wholesale, "replace section X with ...." might be useful. I'd absolutely run this past the responsible AD. The IESG's view of patch RFCs versus diff RFCs varies over time, and I discovered late in my third term that the IESG didn't have a common understanding of what we should do in this case - and embarrassingly, I was in the rough. Datatracker references on request, or you can trust me on this one ... Best, Spencer
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
