memo, 1st day AM

[Jun-ichiro itojun Hagino <itojun@iijlab.net>]

[not a official minutes]

homework (mar)
	charter - swap 6 and 7?


introduction

charter/priorities
	toplevel goals - no comment

	task 1 - solicit input from operators

	ralph: IETF only, or outside IETF?
	mar: suppose we could do outside IETF too
	hinden: seems IETF only
	mar: will see what operators will bring in
	?: who are network operators?
	mar: people deploying IPv6 in their networks - operators, not implementers, basically.  try to outreach operators
	bound: transition tools?
	mar: see later slides
	templin: "operational" - "functional" or "efficiency"
	mar: "securely" "functional enough" "efficiently enough" - is it enough?
	bound: enterprise user/operator/..., we don't know

	plans for task 1

	bound: DoD is deploying serious network.
	randy: nobody should speak for others - like vendors should not speak for enterprise.
	thomas: avoid having second party comment
	randy: speak in the first person
	huitema: comments from support guys?
	thomas: hard to draw a strict line
	mar: authoritatively on behalf of that party
	bound: example: tunnel performance issues <-> NAT
	hinden: vendors have contacts to customers.  we need to be careful not alianating vendors.  need to be clear about where the problem came from

	DNS - dnsop
	SMTP - apps area
	SIP - wrote allison about it, no response
		thomas: working with sip wg
		itojun: parser has ipv6
		alain: not optimistic, based on attending sip
		huitema: v4-v4, v6-v6 is okay, v4-v6 may not be okay so there could be transition issues

	task 2 - input to ipv6 wg
	plans for task 2 - identify open issues
	bound: network management, snmp
	itojun: i have slide
	alain: topology discovery with snmp

	task 3 - ip version independent apps
	hesham: more of educational issue, not operational
	hain: it belongs to ipv6 working group
	huitema: task 1 - look at technology, how to use (operation concern).  task 2 - how do i develop stuff (developer concern).
	plans for task 3 - phil nesser's document, 
	blanchet: no update even though sent comment
	itojun: there are books.
	itojun: traps in scoped address

	task 4 - potential security risks for ipv4/v6 networks
	huitema: top-down, bottom-up
	itojun: i have some top-down as well as bottom-up slide
	?: send bof
	thomas: yes, send has charter, ipv4 arp is not in charter, it was a bootstrap to key material.

	task 5 - viable solutions in common network types, into existing ipv4 net or new net
	huitema: remaining work from ngtrans, what to do?
	mar: ngtrans shuts down in a couple of weeks
	randy: shut down working group, mailing list kept open.
	alain: what should be move to ngtrans?
	mar: some transition tools are in v6ops charter.  scenario work might identify some tool is needed.
	hain: can we refresh ngtrans document? - yes (randy)
	templin: combine mailing list? - too hard (randy)
	bound: it's not fair to shut it down and put existing work dangling state
	mar: on hold until deployment scenario documents.
	harold: (1) re-charter or start a new group?  giving reason is good.  in order to get this meeting focused, start a new group.
	bound: need some ruleset
	randy: read the original message on v6ops opening
	hinden: (1) plan is good (2) share concerns in ngtrans - concerns with closing wg.  they will sent to somewhere else.  issue of fairness?
	thomas: agree with harold
	alain: move ngtrans to sleeping mode?
	mar: ngtrans chair and ad will discuss.

	task 6 - advance standard-track RFCs, or move it historic
		transition mech, siit, natpt, 6to4
	plan for task 6
	transition mech update underway
	dependent on task 5
	huitema: the way charter is written in a way that could piss off bound
	mar: no intention to make these 4 special, pls read task 7
	bound: how you differentiate mechanisms listed here, and others?
	
	task 7 - identify and document open operational or security issues found in 5, work to resolve it cooperatively with other wg
	as a last resort, standardize additional transition mechanisms to resolve issues
	bound: ok, looks fine.  list on task 6 are not special in technical sense
	huitema: reverse order of 7 and 6?
	alain: chater discussion, if we need to go to iesg, we need to do it
	alain: by naming 4 items, making them special
	alain: 6over4? - ipv6wg
	deering: move 6over4 to historic
	randy: to move forward, maybe good not dig into too much details.  use ngtrans mailing list to discuss new transition techs.
	bound: scenario is important.  outsiders are watching.  be careful.
	droms: open security issues - resolve in ipv6wg, or v6ops? - 
	droms: scenarios first - 
	mar: we won't hold everything, based on deployment base
	bound: how do you determine?
	?: difficult to decide which scenario makes sense, and which mechanism makes sense
	mar: iesg trusts us on judgement...
	templin: wording nit in charter.
	bound: why this time?  what's the rush?
	hain: if need to recharter, recharter.
	randy: charter has been there, why you didn't comment that time
	bound: (can't take note)
	huitema: keep work on technical tasks behind the scene...

	limits on v6ops scope
	work will be pushed to the right groups/areas
	must get the full ietf involved in ipv6
	we will cooperate with other groups, as needed

	it is NOT a primary purpose of v6ops to do any standardization work.
	other wg should work on ipv6.
	v6ops is last resort in terms of standardization work.

	priorities?
	scenario/solution for now, think about it for these 2 days

moving from "what" to "how"
	open process
	fairness
	separate process discussion and technical discussion

	submission (email, i-d)
	author refinement
	wg acceptance
		wg charter
		interest from wg
		accepted as a work item by rough consensus
		have correspondeing goals/milestons in the charter
	editor selection
	wg last call - silence is not a consent

	thomas: mobile-ip - no presentation without mailing list discussion
	harold: will send to wg chairs list
	bound: works for me

	structured discussions slides
	"sense of room slide" helps

	tools
	mailing list archives
	webpage
	alain: delivery delays