Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft

[Fernando Gont <[e-mail]>]

On 23/7/19 12:07, Lorenzo Colitti wrote:
> On Tue, Jul 23, 2019 at 5:07 AM Fernando Gont <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     My understanding is that, if anything, it is the relevant working groups
>     that maintain and accept/reject errata, rather than their authors alone.
>     (In fact, at the point the corresponding RFCs (at internet-draft stage)
>     became wg items, they became adopted by the relevant wgs). That's why
>     draft-ietf documents reflect the opinion of the relevant wg, rather than
>     that of the authors.
> 
> The assertion from Warren was that an erratum would not be approved
> because such an erratum would be clearly changing the intent of the
> original document, making it say the opposite of what it used to say.

So... is this kind of a polite way of saying that we have to ignore the
charter because 6man would not agree to work on a document that is meant
to address what is deemed as a real world problem?

If so, rather than circumvent the charters, whichever wg is relevant
(6man in this case), should do what must be done.


FWIW, I had a similar feeling with addressing the slaac-renum problem,
which does have an operational workaround (deployment advice and
tweaking protocol knobs), but that would also benefit from protocol
updates (not necessarily all the ones we proposed).



>     If a protocol needs to be updated, so be it. But that, I understand, is
>     what 6man is for. I can see myself reasons for wanting to do it in
>     v6ops. But unless I'm missing something, that's the charter of 6man,
>     rather than of v6ops.
> 
> 
> And it is in the charter of v6ops to suggest those modifications:
> 
> ======
> 1. Solicit input from network operators and users to identify
> operational issues with IPv6 networks, and determine solutions or
> workarounds to those issues.
> ...
> IPv6 operational and deployment issues with specific protocols [...]
> are the primary responsibility of
> the groups or areas responsible for those protocols [...]
> However, the v6ops Working Group may provide input to
> those areas/groups, as needed, and cooperate with those areas/groups in
> reviewing solutions to IPv6 operational and deployment problems.
> ======
> 
> This is an operational issue in IPv6-only networks, and this draft is
> about determining a solution and providing 6man with input on how to
> resolve it in the protocol.

While skimming the doc, it would seem to me that the document aims at
updating the protocol spec (even when it's "Informational"), rather than
providing input to 6man.

If the problem is seen as a real problem (I'm not taking a position in
that respect), this document should be std track, update the ND spec,
and be done in 6man. (And yes, 6man should address protocol problems,
rather than being guardians that prevent folks from solving them).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492