Re: Moving forward draft-ietf-6man-deprecate-atomfrag-generation-01 (Re: I-D Action: draft-ietf-6man-deprecate-atomfrag-generation-01.txt)

[Tore Anderson <[e-mail]>]

* "Fred Baker (fred)" <[e-mail]>

> BTW, if we rev 6145 for this, we should include your favorite rev,
> and there is an erratum to sort out. I’d like to do it all in one
> swell foop in one working group. I’ll take advice on where; the
> obvious place (behave) doesn’t exist any more.

I'll gladly roll draft-anderson-v6ops-siit-eam into a 6145bis.

Being somewhat of an IETF newbie, I don't have any strong opinions on
the venue and will follow where you lead... That said, I was faced with
the same question when determining where to submit the siit-eam stuff,
and here is my thoughts on the matter:

- When I spoke to Ole about the SIIT-DC/EAM stuff a while back I was
  told that 6man was not appropriate.

- A 6145bis is bordering on being out of scope for v6ops' charter. I
  guess it depends on whether or not you understand «specifying any
  protocols or transition mechanisms» to also mean «updating already
  specified protocols or transition mechanisms». That said, there is
  precedent for doing 6145 updates in v6ops though; cf. RFC 6791 (and
  also the soon-to-be-uploaded draft-ietf-v6ops-siit-eam). Furthermore,
  when considering that the updates is largely caused by operational
  experience, v6ops does sound like an OK fit.

- Sunset4 may be appropriate, as facilitating the disablement of IPv4
  in (parts of) the network is perhaps the most important use case for
  SIIT. However there's no fitting work item listed in the sunset4
  charter as far as I can see.

If there are other potential candidates, I'm not familiar with them.

Tore