Agreeing with Joel about the process although not necessarily
about the conclusion (i.e., I may be in the rough part of that
rough consenus), let me make what I hope is a constructive
suggestion.
Almost no decision make in the IETF, especially not procedural
ones, can ever bind the IETF forever. There is always, in
principle, the possibility of a new document and a new consensus
that changes a prior decision.
If people think a decision like this was wrong, and specifically
wrong because there were important issues raised (or otherwise
evident) that the IESG did not properly conside, that is part of
what we have an appeals mechanism for (no matter how poorly the
term describes the intent of the mechanism).
If the appeal window has passed (or an appeal is inappropriate
for some reason) and someone still thinks this is worth going
through again, then create and post a new I-D that carefully
explains what you think is wrong with the decision, what
alternatives you think would be better and why, and why it is
appropriate at this time and why (the latter because those who
believe the decision was correct will certainly argue that it
would be a better use of everyone's time to let the RFCs be
published and some months or years of experience accumulated
with them before coming back to the question).
Or, if the real issue is whether the IETF should be eating its
own dogfood and how stringently under various circumstances,
write an I-D about that and about the circumstances and see if
you can get it through the system, updating these other
documents and practices as needed. Don't expect the IESG to
take that issue up spontaneously: not only has it be raised
several times before (about other matters) and gotten nowhere,
but I think there is a strong argument that taking it up in the
context of this particular decision without strong community
input that identifies new issues would possibly be improper.
Either way, with an i-D posted that would define the problem as
you see it and suggests remedies, we would have something to
discuss (or reject), not just what Joel describes (AFAICT,
correctly) as re-raising and rehashing the issues.
Disclaimer: speaking only for myself and my opinions; YMMD.
john
--On Sunday, April 19, 2020 12:38 -0400 "Joel M. Halpern"
<jmh@xxxxxxxxxxxxxxx> wrote:
> This was discussed in the working group.
> For folks who did not participate in the working group, the
> right time to raise this was during the IETF LC. Which did
> occur. And was publicized the same way all IETF decisions are
> publicized.
>
> The IESG leadership concluded (as far as I could tell
> correctly) that there was IETF rough consensus for the two
> documents from the working group.
> Those documents are now on the RFC Editor queue.
>
> Yes, some people disagree. That happens. That is why we have
> a rough consensus process.
>
> I do not think it is or should be incumbent on the
> participants to rehash the issues because the issue has been
> re-raised.
>
> Yours,
> Joel
>
> On 4/19/2020 12:19 PM, Fernando Frediani wrote:
>> Hello Carsten
>> Thanks for your input.
>>
>> Don't you think that not choosing the default choice is just
>> a question of adaptation ? The additional learning is
>> expected and a normal thing I would say.
>>
>> I guess that putting the fact IPv6 has not been enabled to a
>> particular SaaS as something small should not be the case,
>> not for IETF. Perhaps for a private company it could be the
>> case, but IETF should stand to values and also have focus on
>> giving the example, otherwise why put all the effort in
>> standardize something ?
>> Has anyone done any type of assessment of how much would
>> possible be lost by directing people to use other tools
>> versus how much is lost over the years by people and
>> companies looking that not even IETF is concerned about
>> favoring products with IPv6 ?
>>
>> Otherwise we will spend another 20 years asking people to
>> adopt IPv6 and having to deal with the growing issues
>> related to legacy IPv4.
>>
>> Best regards
>> Fernando
>>
>> On 19/04/2020 13:03, Carsten Bormann wrote:
>>> On 2020-04-19, at 17:53, Fernando Frediani
>>> <fhfrediani@xxxxxxxxx> wrote:
>>>> Can we start with:
>>>> https://datatracker.ietf.org/wg/git/about/ ? What type of
>>>> unique thing GitHub has that justifies continuing using it
>>>> in detriment to other SaaS that already have full IPv6
>>>> support ?
>>> Github has an audience that nobody else has.
>>>
>>> If the objective of the github repo is to open communication
>>> lines to actual developers; these are overwhelmingly on
>>> github; using another service just misses the mark.
>>>
>>> For other projects, gitlab etc. work well, too, but do
>>> require some additional learning for people who work on
>>> more than one project at the time. There is no
>>> institutional bias against those services; I have
>>> participated in IETF-related projects both on gitlab and on
>>> bitbucket (even with, shudder, mercurial). It's just not
>>> the default choice.
>>>
>>> Note that we are not talking about a company that routinely
>>> engages in criminal behavior (you know who I'm talking
>>> about; do not discuss this here as it is off-topic), but a
>>> service that merely hasn't got around to enabling IPv6.
>>> This is ugly, but not the original sin.
>>>
>>> Grüße, Carsten
>>>
>>
>
