Subject: [Iasa20] RFC7500-bis -- was Consolidated Update Draft vs. Individual Drafts

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 10 Dec 2018 20:14:13 +0000

I received some off-list feedback that it may not make sense to lump RFC 7500 into the consolidated update – because RFC 7500 is an IAB document.  If it was to be included in the consolidated document, then the approval process could be unclear as it would need both IESG and IAB approval.

Based on this, what does the WG think? It seems it may mean we extract RFC 7500 out of the consolidated draft.

Thanks
Jason

From: "Livingood, Jason" <[email-masked]>
Date: Monday, December 10, 2018 at 12:01 PM
To: "[email-masked]" <[email-masked]>
Subject: Consolidated Update Draft vs. Individual Drafts

As you have certainly noticed, we have gotten varying feedback over time from the WG, the RFC editor, and some in the broader IETF community about whether to update individual drafts, to have a consolidated update draft, or a mix of the two approaches – or even to file errata. It seems the clearest path forward now is to employ a mix of the two approaches, with the recent consolidated update draft (https://datatracker.ietf.org/doc/draft-ietf-iasa2-consolidated-upd/) addressing a great many of these. But that won’t work in all cases so we will still have some individual drafts, as the circumstances and extent of updates necessary dictate.

As noted in the header of draft-ietf-iasa2-consolidated-upd, it would:
Update – RFC 2028, RFC 2418, RFC 3005, RFC 3710, RFC 5377 (see separate email in a moment), RFC 6702, RFC 7500
Obsolete – RFC 3716, RFC 3929, RFC 4633

Since no one can ever be 100% certain this will be acceptable with the IESG, general IETF community, and RFC Editor, last week we asked that some individual documents that would have addressed RFCs above be updated to reflect the change in reference from the structure I-D to RFC4071-bis. Our thinking was that this was a hedge against any possibility that we had challenges with the consolidated draft, so that we had a backup document plan at the ready just in case.

We appreciate the work of those volunteer document editors that assisted with the documents now covered by the consolidated update! And should some or all of these later be found to need individual updates, we’ll be prepared and can react quickly.

Regards
Jason

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Dec 2018 10:33:00 +1300

> I received some off-list feedback that it may not make sense to lump RFC 7500 into the consolidated update – because RFC 7500 is an IAB document.  If it was to be included in the consolidated docum…

True, but we've done that in the past with a few documents. I don't really see why it would cause a delay as long as the IESG and IAB approvals proceed in parallel.

   Brian

> *From: *"Livingood, Jason" <[email-masked]>
> *Date: *Monday, December 10, 2018 at 12:01 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Consolidated Update Draft vs. Individual Drafts
> 
>  
> 
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Dec 2018 16:43:14 -0500

> On Dec 10, 2018, at 4:33 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Mixing the approval process and for documents in the IAB stream and the IETF stream seems like a complication that we do not need.

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Dec 2018 10:53:44 +1300

> Mixing the approval process and for documents in the IAB stream and the IETF stream seems like a complication that we do not need.

Adding an additional RFC for the sake of a single short updating paragraph also seems like a complication that we do not need.

   Brian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Dec 2018 08:32:00 -0800

Howdy,

On Mon, Dec 10, 2018 at 1:53 PM Brian E Carpenter <
[email-masked]> wrote:

> >>> I received some off-list feedback that it may not make sense to lump
> RFC 7500 into the consolidated update – because RFC 7500 is an IAB
> document.  If it was to be included in the consolidated document, then the
> approval process could be unclear as it would need both IESG and IAB
> approval.
> >>
> >> True, but we've done that in the past with a few documents. I don't
> really see why it would cause a delay as long as the IESG and IAB approvals
> proceed in parallel.
> >
> > Mixing the approval process and for documents in the IAB stream and the
> IETF stream seems like a complication that we do not need.
>
> Adding an additional RFC for the sake of a single short updating paragraph
> also seems like a complication that we do not need.
>
> Brian, if Russ is volunteering to write the IAB-stream update, I think the
IAB can process it very quickly.  I don't think, in other words, it is a
complication, just something to get done.  While it is a short paragraph:

   For protocol parameters [RFC6220
<https://tools.ietf.org/html/rfc6220>], the general oversight of the
IANA
   function is performed by the IAB as a chartered responsibility from
   [RFC2850 <https://tools.ietf.org/html/rfc2850>].  In addition, the
IETF Administrative Oversight Committee
   (IAOC), a body responsible for IETF administrative and financial
   matters [BCP101 <https://tools.ietf.org/html/rfc7500#ref-BCP101>],
maintains an SLA with the current registry
   operator, the Internet Corporation for Assigned names and Numbers
   (ICANN), thereby specifying the operational requirements with respect
   to the coordination, maintenance, and publication of the protocol
   parameter registries.  Both the IAB and the IAOC are accountable to
   the larger Internet community and are being held accountable through
   the IETF Nomcom process [BCP10
<https://tools.ietf.org/html/rfc7500#ref-BCP10>].

it probably is worth the tracking, because it describes who will maintain
the SLA and thus the coordination, maintenance, and publication of the
registries.

Russ, is your hand up?

Ted

---

From: S Moonesamy <[email-masked]>
Date: Mon, 10 Dec 2018 21:37:24 -0800

Hello,
At 01:43 PM 10-12-2018, Russ Housley wrote:
>Mixing the approval process and for documents in the IAB stream and 
>the IETF stream seems like a complication that we do not need.

Yes.

The IETF created another legal entity, i.e. there are now two legal 
entities.  What does the working group intend to do about the third 
paragraph of Section 3.4?

Regards,
S. Moonesamy

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Dec 2018 14:53:24 -0500

https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7500-bis/

Russ

> On Dec 11, 2018, at 11:32 AM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> On Mon, Dec 10, 2018 at 1:53 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> >> On Dec 10, 2018, at 4:33 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> Brian, if Russ is volunteering to write the IAB-stream update, I think the IAB can process it very quickly.  I don't think, in other words, it is a complication, just something to get done.  While it is a short paragraph:
> 
>    For protocol parameters [RFC6220 <https://tools.ietf.org/html/rfc6220>], the general oversight of the IANA
>    [RFC2850 <https://tools.ietf.org/html/rfc2850>].  In addition, the IETF Administrative Oversight Committee
>    matters [BCP101 <https://tools.ietf.org/html/rfc7500#ref-BCP101>], maintains an SLA with the current registry
>    the IETF Nomcom process [BCP10 <https://tools.ietf.org/html/rfc7500#ref-BCP10>].
> it probably is worth the tracking, because it describes who will maintain the SLA and thus the coordination, maintenance, and publication of the registries.  
> 
> Russ, is your hand up?
> 
> Ted
>  
>    Brian
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/iasa20 <https://www.ietf.org/mailman/listinfo/iasa20>

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 11 Dec 2018 16:05:38 -0500

> On Dec 11, 2018, at 2:53 PM, Russ Housley <[email-masked]> wrote:
> 
> https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7500-bis/ <https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7500-bis/>
Publishing this document in the IAB stream, separately from the consolidated update document, seems like the simplest path here.

Alissa

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Dec 2018 13:09:57 -0800

On Tue, Dec 11, 2018 at 1:05 PM Alissa Cooper <[email-masked]> wrote:

> Publishing this document in the IAB stream, separately from the
> consolidated update document, seems like the simplest path here.
>
> Alissa
>
>

Sorry for losing track that this was already done and needed to be undone
to shift theories; in light of it, though, I think this is clearly the
easier way to proceed.

Just my two cents, though,

Ted

>> Adding an additional RFC for the sake of a single short updating
>> paragraph also seems like a complication that we do not need.
>>
>> Brian, if Russ is volunteering to write the IAB-stream update, I think
> the IAB can process it very quickly.  I don't think, in other words, it is
> a complication, just something to get done.  While it is a short paragraph:
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 12 Dec 2018 14:13:42 +0000

Thanks for all the list feedback! As a result, the WG will proceed with RFC7500-bis as a separate draft as originally planned and remove mention of 7500 from the consolidated update draft.

Jason

From: "Livingood, Jason" <[email-masked]>
Date: Monday, December 10, 2018 at 3:14 PM
To: "[email-masked]" <[email-masked]>
Subject: RFC7500-bis -- was Consolidated Update Draft vs. Individual Drafts

Thanks
Jason

Regards
Jason