[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A personal take on WG's priorities..
On Thu, 4 Nov 2004, JORDI PALET MARTINEZ wrote:
Group 1
The most important work
- finish enterprise analysis
- finish requirement(s) for tunneling
* to be able to decide whether existing solution(s) are sufficient
and if not, get started on specifying new ones
- get started on mechanisms (somewhere else?) if needed/necessary
I will say that is not good that a new WG should take care of new mechanisms
(if they are required). This will slow down the process too much (minimum 6
months), and it not clear that we can't do that with the current charter, or
even a small modification of it.
Yes, there are challenges with spinning up a new WG, but it does not
necessarily need to take that long, and the work doesn't have to be
stalled during the time it takes to officially kick-start a WG.
Putting all the work relating to protocols certainly seems to be a
relatively easily separable piece of the current charter.
Now, if we take those items from the list which might be
protocol-related, we have:
- finish requirement(s) for tunneling
- get started on mechanisms (somewhere else?) if needed/necessary
- finish draft-ietf-v6ops-mech-v2
- adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
- draft-palet-v6ops-tun-auto-disc
- revising 6to4 spec to be clearer, etc.
- draft-palet-v6ops-solution-tun-auto-disc
- draft-palet-v6ops-auto-trans
That seems a close-to-manageable list, keeping in mind that mech-v2 is
pretty much complete in any case. That would allow v6ops WG to better
focus on non-protocol work items, also those you wanted to be
addressing.
For the rest of the items, see a possible division at the end..
Also, I think this
- draft-palet-v6ops-tun-auto-disc
belongs to what I called Group 1, and is ready to be closed. Otherwise will
be good the received inputs, objections or whatever !
I don't disagree that this is rather close to being closed, but the
question is of its urgency -- I think it'll be needed only when we
start figuring out which kind of protocols we specify, or how we
modify them. (Granted, it would be useful if there was already
consensus on that then.)
Group 2
Pretty darn important work
- the last spin at 3GPP analysis doc, updated IMS scenario
- better document the ISP's broadband transition scenarios
* draft-asadullah-v6ops-bb-deployment-scenarios-01
- finish draft-ietf-v6ops-mech-v2
* waiting for feedback from the IESG telechat..
- adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
* IESG requirement for draft-ietf-v6ops-mech-v2
- figure what to do about the NAT-PT deprecation/analysis
* draft-aoun-v6ops-natpt-deprecate
- (techno-political) document for v4 NAT users
* draft-vandevelde-v6ops-nap
- IPv6-on-by-default work, fixes need to be integrated in the IETF work
* draft-ietf-v6ops-onlinkassumption
* draft-ietf-v6ops-v6onbydefault
* etc.
I think
- draft-palet-v6ops-solution-tun-auto-disc
belongs to this group, and is 80% ready. Is very useful for the zeroconfig,
assisted tunneling, etc.
As for draft-palet-v6ops-tun-auto-disc, this seems to be needed only
after a little bit, certainly not before the requirements document is
moving forward.
Personally, I think this is very far from done. I think the approach
has serious issues relating to the need to implement a lot of
different functions. Of course, these could be worked out as a WG
item as well, but being technically sound gives more weight in the
decision for WG adoption.
I'm tempted to move all this to the Group 2 or 3, together with the
security-overview. If this work needs to specify new protocols, then I might
consider another WG (existing probably, not necessarily a new one), but I
believe it can be approached with existing protocols within IETF.
I consider security an extremely important issue for the deployment of IPv6,
as an operational issue that falls clearly in the scope of our charter.
By the way, I don't think is a question of momentum, is a question of people
reviewing, and we all know that the problem is the same with other very
important documents, which at the end pass by "no objection" despite Jim
observations ! Let's be honest with ourselves, please ! I think is very
stupid to try to convince ourselves about what is so evident. And yes is my
own fault also, I will like to do more work review more documents, but
specially the last 3-4 months has been almost impossible. Now I've plenty of
time during Xmas and will do much more.
Let me explain why I raised the need for 'momentum'. The IETF should
not (IMHO) work at protocols or approaches if there isn't sufficient
'buy-in' from the associated parties (e.g., the most important vendors
which are required to make it successful, operators willing to deploy
the stuff, enough people interested in the specification and reviewing
etc.).
We (IMHO) should not move forward and put out RFCs on something, even
if some deem that important, unless there is sufficient interest in
the work so that the work would actually be used. The result would
probably be 1) irrelevant work that no-one will use, and/or 2) badly
reviewed, technically unsound work, because there was not sufficient
attention to the work.
I think the work on distributed security is one example of this. The
work needs to get attention from the different players in the field,
most importantly the security folks (who were involved in defcon),
some vendors (like Microsoft and Cisco, who have been working on a
proprietary solution AFAIR), etc. -- this work seems best suited to a
separate mailing-list, with a BOF process, etc. A separate mailing
list seems like the only way to get focused attention on the work:
security etc. folks would find the v6ops list too noisy.
Group 6
Not sure whether it should be published as RFC, or is sufficiently relevant
- draft-chown-v6ops-campus-transition
- draft-morelli-v6ops-ipv6-ix
Not sure either, but I will say is part of the scenarios documents.
Campus transition, yes -- if Tim and others think it's worth
publishing.
IPv6-IX, not really, as that isn't the real operational model how
(IPv6) exchanges are run.
My conclusion is that we will have probably only 3 groups instead of 6,
which can proceed almost in parallel, even if takes a few extra months
(3-6), because that will be the same delay it will take creating a new WG,
or even outsourcing to existing ones.
But these categories total like 25 documents!
As Brian said, there's no chance to work on those in parallel. There
_must_ be some serialization, or forking off to separate efforts.
For example, 4-7 work items at the same time _might_ be doable, but
some would say that even that much is a lot.
....
At the start I described some potential items for "v6mechs" WG. Let's
look a bit at a possible division of the rest:
Might be doable under v6ops (the middle category docs are almost done
already, so there's only little work)
- finish enterprise analysis
- better document the ISP's broadband transition scenarios
- the last spin at 3GPP analysis doc, updated IMS scenario
- IPv6-on-by-default work, fixes need to be integrated in the IETF
- draft-ietf-v6ops-renumbering-procedure
- draft-chown-v6ops-vlan-usage
- figure what to do about the NAT-PT deprecation/analysis
- (techno-political) document for v4 NAT users
- security overview of IPv6
- draft-chown-v6ops-port-scanning-implications
Might be best to run through a separate mailing lists/BOFs process,
(possibly fold back the results to v6ops when done there):
- figuring out how to deal with Mobile IP transition issues
- distributed security stuff
- draft-chown-v6ops-renumber-thinkabout-00 (maybe)
- maybe the ipv6 flow label applicability stuff
So, provided that some work that touches multiple areas, or areas of
expertise could be run through a separate process, the load on v6ops
might become manageable, and it would be more realistic to think about
taking new _operational_ work items as well.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings