Re: [Iasa20] Ballot positions on draft-ietf-iasa2-rfc7437bis

FWIW, as someone who argued for making more extensive changes in
order to clean up problems we knew about _and_ who argued for
more focus on the approach of draft-ietf-iasa2-consolidated-upd
in order to avoid issuing replacement ("X obsoletes Y")
documents when we knew there were outstanding issues with them,
I agree with Brian and Alissa.  

The time to raise the question of whether IASA2 should do a
general cleanup was back when the IASA2 WG was chartered and has
long passed.  If we are ready to reopen basic procedures or
models that are not involved with the IASA transition, something
in the POISED, POISED95 or POISSON chain, or perhaps the NEWTRK
one, might be appropriate but pretending that IASA2 is properly
organized to do that -- even with a recharter -- would, IMO, be
a considerable disservice to the community.

In a more perfect world, I strongly prefer that we not replace
documents unless we sort out all known issues with them.  For
technical specifications, the language of RFC 2026 just about
requires that.  But that isn't what the IESG (and, at least to
some extent, the community) decided to with IANA2.  Trying to
change that retroactively would be even worse.

In the interim, if clarifications that are not in scope for
IASA2 are needed, there is a relatively lightweight mechanism
that would probably be considered the only appropriate one if
these suggestions were not emerging from the IESG.   Generate an
I-D that updates whatever comes out of IASA2, get some AD to
sponsor it, push it through IETF LC, and move on.

  best,
    john

--On Saturday, July 6, 2019 08:10 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> I'm with Alissa on this. There are quite a lot of reasons why
> we might need RFC7437bisbis, some of which are much more
> serious than the various points raised by several ADs, but I
> believe we should first wrap up the changes required by the
> creation of IETF LLC.
> 
> I don't think rechartering IASA2 for this purpose would be
> appropriate at all. Starting a process that might lead to a new
> version of the POISED, POISED95 or POISSON WG would seem more
> suitable. See https://datatracker.ietf.org/wg/poisson/about/
> for example.
> 
> Regards
>    Brian Carpenter
> 
> On 06-Jul-19 06:41, Alissa Cooper wrote:
>> Dear IESG,
>> 
>> I wanted to draw your special attention to this text in
>> draft-ietf-iasa2-rfc7437bis:
>> 
>> "This revision addresses only the changes required for IASA
>> 2.0; should the community agree on other changes, they will
>>    be addressed in future documents."
>> 
>> As well as this text in the IASA2 WG charter:
>> 
>> "This working group is chartered to document the normative
>> changes to IETF administrative structures and processes
>> necessary to effectuate [the change to IASA 2.0]."
>> 
>> If the IESG is not going to allow draft-ietf-iasa2-rfc7437bis
>> or other IASA2 documents to progress unless changes unrelated
>> to IASA 2.0 are made, I think the WG needs to be rechartered.
>> The authors and the WG purposefully did not make any other
>> changes to the base documents, so making other changes as a
>> result of IESG evaluation does not seem appropriate. I think
>> the appropriate thing to do would be for ADs who want to see
>> that happen to start a thread about re-chartering on the
>> iasa20 list. (Note: this is not my preference since I suspect
>> it will delay the minimal changes related to IASA 2.0 from
>> being published for a long time, but if that's what the
>> community wants I'll support it.)
>> 
>> Thanks,
>> Alissa
>> 
>> 
>> _______________________________________________
>> iasa20 mailing list
>> iasa20@ietf.org
>> https://www.ietf.org/mailman/listinfo/iasa20
>> 
> 
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20