ipv6@conference.ietf.jabber.com - 2003/03/17


[05:32] %% Isomer has arrived.
[06:51] %% Isomer has left.
[10:24] %% psykopat has arrived.
[10:24] %% psykopat has left.
[14:56] %% Isomer has arrived.
[15:45] %% takamiya has arrived.
[15:45] %% takamiya has left.
[20:25] %% fsolensky has arrived.
[20:26] %% fsolensky has left.
[20:44] %% venaas has arrived.
[20:45] %% take-s has arrived.
[20:53] %% mrose has arrived.
[21:12] %% smb has arrived.
[21:12] %% smb has left.
[21:12] %% smb has arrived.
[21:14] %% smb has left.
[21:20] %% leslie has arrived.
[21:24] %% ggm has arrived.
[21:24] <ggm> do we have a scribe?
[21:25] <ggm> prefix delegation requirements
how to do delegations to customers automatically eg on ADSL/cable

document improvements, re-edited

[21:25] %% nakamura has arrived.
[21:25] <ggm> Q. wording in document. discusses PPP and CHAP do we want L2 info in document or remove?
[21:25] <ggm> (chair)
[21:25] %% takamiyama has arrived.
[21:26] <ggm> (floor) want something more generic
[21:26] <ggm> dave meyer. remove text, replace with 'mechanism must also work on links shared to multiple customers'
[21:27] <ggm> ptopt is subset of shared link ?
[21:27] <ggm> dave meyer is a subset, don't know if it needs to be distinguished
[21:27] <ggm> requirements for PPP, language is ok, 'if there is L2 mechanism then use it' I can live with.
[21:28] <ggm> don't phrase anything about prioritization
[21:28] <ggm> (chair) do people believe specific wording in PPP/CHAP should go? then I will ask, if Daves thing about L2 auth should be included or removed.
[21:28] <ggm> so. call on PPP/CHAP to stay
[21:28] <ggm> removed.. <hands>
[21:29] <ggm> now L2 auth mechanism
[21:29] <ggm> include L2 mechanisms <hands>
[21:29] <ggm> remove L2 <no hands>
[21:29] <ggm> have consensus PPP/CHAP goes, L2 auth stays
[21:29] <ggm> other issues?
[21:29] %% fsolensky has arrived.
[21:29] <ggm> other issue, to add reqts has to work on shared links.
[21:30] <ggm> there must exist a solution (huitema)
[21:30] <ggm> do we need a soln on shared links for prefix delegation? or a solution only viable on ptopt?
[21:30] <ggm> (chair) phrase this carefully, think, don;t just say yes for yes sake
[21:31] <ggm> need soln works on shared links
[21:31] <ggm> (sorry, people don't name themselves I can't identify cept wher I know the voice)
[21:31] <ggm> why a problem to have this?
[21:31] <ggm> (chair) don't add requirements you don't need
[21:32] <ggm> sometimes use PPPoE on shared links. this is virtual ptotpt from ISP PoV. so need mechanism on shared media
[21:33] <ggm> will need this
[21:33] <ggm> (chair) process mode: do we add a requirement to support mechanism on shared links? yes or no.
[21:33] <ggm> may be more than one solution, but need at least one that does.
[21:34] <ggm> (chair) so. do we NEED A SOLUTION that works on shared links, yes or no
[21:34] <ggm> <humour>
[21:34] <ggm> (chair) check process. be anal. <more humour>
[21:34] <ggm> do we need a prefix delegation that works on shared links. <hands> no hands down.
[21:34] <ggm> so we have consensus (chair)
[21:35] <ggm> next item coming up. DHCPv6 PD status
[21:35] <ggm> updates to draft, bake-off at TAHI #4, connectathon 2003
[21:36] <ggm> passed V6 WG and DHC WG last call
[21:36] <ggm> last call comments fed back
[21:36] <ggm> issues from pekka.
[21:36] <ggm> T1/T2 timer issues
[21:36] <ggm> why IAID?
[21:36] <ggm> preferred/valid default lifetimes
[21:37] <ggm> rebind/confirm behaviour(s)
[21:37] <ggm> [ is this ok? anybody care? anybody prefer I stop? -ggm ]
[21:37] <mrose> i'm watching
[21:38] <ggm> ready for IESG last call.
[21:38] <Isomer> yeah, I'm watching too
[21:38] <fsolensky> doing fine thx
[21:38] * Isomer thanks ggm for the great running commentary
[21:38] <ggm> (chair) any final comments?
[21:38] %% perry has arrived.
[21:38] <ggm> next..
[21:39] <ggm> bob hinden no slides, proxy RA solution to solve problem
[21:39] <ggm> whats missing is proxy RA internet draft, have last multilink subnet draft, but much larger scope. if we make progress, need volunteer to work on draft to extract stuff from multilink subnet and propose to wg
[21:39] <ggm> wont make progress without a draft
[21:40] <ggm> comments. dave meyer volunteers
[21:40] %% take-s has left.
[21:40] <ggm> huitema. happy dave does the job.
[21:40] %% take-s has arrived.
[21:40] <ggm> but there is a point, want to excise a proxy mechanism from another draft, however there is a rational
[21:40] <ggm> problem stacking gateways. buy home router to DSL
[21:41] <ggm> home router is not wireless router. plug to that wireless, into hub make NAT to NAT. can do site config in home but is not good.
[21:41] <ggm> people could reprogram, dtrt. makers want single config to work.
[21:41] <ggm> one of the purposes in RA proxy is to have stacks of routers without config. but need a BIT more than RA proxy
[21:41] <ggm> bottom line: there is a need for multilink subnet
[21:42] <ggm> hinden ok
[21:42] <ggm> but need to discuss where to do. not here. organize BoF., dave to work draft
[21:42] <ggm> dave meyer so to be clear
[21:42] <ggm> need some feedback from anybody about the proxy mechanism, if it meets requirements
[21:42] <ggm> otherwise will do my best to put insolution. mail me.
[21:43] <ggm> <unknown> pretty clear it doesnt meet requirements. can only do /64s.
[21:43] <ggm> probably very link type specific. its a hack. but can be useful
[21:43] <ggm> hindern. scenario christien (huitema) also probably doesnt cut it sometimes
[21:43] <ggm> meyer. RA proxy can mean at least 3 different things
[21:44] <ggm> thats why I solicit input on what it means
[21:44] <ggm> (chair) as you work on this
[21:44] <ggm> work towards something which is the requirements <humour>
[21:44] <ggm> NEXT: IPv6 Mibs. Marg. Wasserman
[21:45] <ggm> quick. not a lot to say. (chair) is wasserman
[21:45] <ggm> enhanced IP mib, new V6 features, 3 other mibs.
[21:45] %% leslie has left.
[21:45] %% leslie has arrived.
[21:45] %% leslie has left.
[21:45] <ggm> how to detect MIB updates timestamp row/count issue
[21:45] <ggm> resolution: timestamp in some tables, no row counters
[21:46] <ggm> other issue conformance/compliance for older objects
[21:46] <ggm> request to add this
[21:46] <ggm> leaning towards NOT adding it
[21:46] <ggm> want input from room
[21:46] <ggm> comments?
[21:46] <ggm> Sean.
[21:46] <ggm> no.
[21:47] <ggm> read mib? (few hands)
[21:47] <ggm> care if we publish? (few more hands)
[21:47] <ggm> chair exhorts floor to read drafts
[21:48] <ggm> forrwarding table MIB status.
[21:48] <ggm> issues raised in WG last call
[21:48] <ggm> DSCP as an index.
[21:48] %% kapi has arrived.
[21:48] <ggm> need for Read Only compliance
[21:48] <ggm> unneccessary MIB edits
[21:48] <ggm> issues to be addressed in new draft after SF
[21:49] <ggm> input requested
[21:49] %% kapi has left.
[21:50] <ggm> TCP MIB status
[21:51] <ggm> additional stats moved to TCP-ESTATS-MIB
[21:51] <ggm> issue how to inc. there
[21:51] <ggm> reeady for WG last call?
[21:51] <ggm> chair berates the floor again about this. need for interaction.
[21:51] <ggm> meyer. read it. its ready for last call.
[21:52] <ggm> UDP MIB status
[21:52] <ggm> not been updated to align with minimal changes plan
[21:52] <ggm> EDITOR needed.
[21:52] %% akato has arrived.
[21:52] <ggm> chair calls for MIB editor
[21:53] <ggm> MIBS done. questions
[21:53] <ggm> <unknown> put to OPS area for review before last call?
[21:53] <ggm> (chair) sort of like it when its done. then respond. some are on team anyway.
[21:54] <ggm> [ I *think* flexible address assignment is next -ggm]
[21:54] <ggm> Brian Carpenter
[21:54] <ggm> why nobody reads mibs
[21:54] <ggm> want to say about forwarding MIB DSCP issue. wasn't aware. will read, need to find the issue. nothin in archive. take offline
[21:54] <ggm> please forward info to me
[21:54] <ggm> meyer. 15 second summary of issue
[21:55] <ggm> issue is that previous version had ToS byte as index.
[21:55] <ggm> DSCP doesnt work same way.
[21:55] <ggm> conflict between instrumenting on ToS point, how do you word whrn its DSCP
[21:55] <ggm> Carpenter not forbidden to use DSCP that way, not intended thats all,. will look at it, propose solution to match diffsrv
[21:56] %% sakai has arrived.
[21:56] <ggm> (chair) want more capable forwarding MIB. comments seen on list not being ignored
[21:56] <ggm> have consensus we don't want to do routing table NG MIB. not on charter. other comments?
[21:57] <ggm> Leslie Daigle on IAB appeal on NOW
[21:57] <ggm> set stage for the issue
[21:57] <ggm> everyone knows document. addr-arch-v3-11.txt
[21:58] <ggm> confusion about what the IAB was or wasn't saying. what I want to go over tonight
[21:58] <ggm> recognize this group put a lot of work into revising previous doc. important
[21:58] <ggm> went through appeal process as effectively/efficiently as possible.
[21:58] <ggm> responses to response indicate there was confusion
[21:59] <ggm> IAB does not say this doc should not be published
[21:59] <ggm> does not say doc should not be published as Proposed Standard
[21:59] <ggm> IAB recommends publishing as PS
[21:59] <ggm> the IAB repsonse does not provide directives to WG or IESG. not the IABs mandate
[21:59] <ggm> what it does say is
[21:59] <ggm> this instance of the document is not clear enough to be published as Draft Standard
[22:00] <ggm> clarity needed in order to ensure the impl. developed from the spec will be interoperable
[22:00] <ggm> IAB is not challenging anything in the IPv5 addr. arch. in this response
[22:00] <ggm> IAB annulled the IESG decision to move doc to DS
[22:01] <ggm> future version will go through normal IETF process, may go to DS.
[22:01] <ggm> IAB provides recommendations for fixes
[22:01] <ggm> what the IAB anticipates
[22:01] <ggm> expect to see IESG/IPV6 WG think about the recomms for clarification, and determine how the wG wants to
[22:01] <ggm> produce a new version
[22:01] %% jishac has arrived.
[22:02] <ggm> IAB can discuss the meat of the recommendations. not to get into challenge-response mode to the IEAG space
[22:02] <ggm> all further discussion in the WG.
[22:02] <ggm> q?
[22:02] <ggm> no further discussion.
[22:02] <ggm> (chair) where we stand on understanding this appeal.
[22:02] <ggm> how many read response? (heaps of hands)
[22:02] <ggm> we are going to figure out what we want to change, and have to change to resubmit
[22:03] <ggm> not right this minute
[22:03] <ggm> give people some time to think about it.
[22:03] <ggm> on thus, walk through several issues.
[22:03] %% leslie has arrived.
[22:03] <ggm> eg conclusions, recommendations. walk through those different things, figure out hwo the working group wants to respond
[22:03] <ggm> we don't need to write a response.
[22:03] <ggm> we figure out how we want to change the doc to make it better, based on IAB inputs.
[22:04] <ggm> any questions for leslie? on process? not on technical issues.
[22:04] <ggm> nothing.
[22:04] <ggm> bob hinden shows IPv6 temperature.
[22:05] <ggm> steve bellovin next
[22:05] <ggm> access control prefix issues
[22:06] <ggm> explicit prefix provides more flexibility than from site-local. without complexity
[22:06] <ggm> format slide. new option access control prefix option.
[22:07] <ggm> has type/length/prefix ID/len
[22:07] <ggm> valid lifetime (set to zero to remove)
[22:07] <ggm> then prefix
[22:07] <ggm> node rules
[22:07] <ggm> may be configured to use Access control prefix
[22:07] <ggm> devices MUST NOT send packets to other prefixes
[22:07] <ggm> packets from other prefixes MUST be dropped
[22:07] <ggm> link local packets and DAD packets MUST be acceptable
[22:08] <ggm> Access control prefixes are per-interface
[22:08] <ggm> router rules
[22:08] <ggm> routers MAY send this option
[22:08] <ggm> multipe access prefixes MAY be announced but SHOULD beconsisent except during deliberate exchange
[22:09] <ggm> routers SHOULD notice and log inconsistencies in announcements from other routers
[22:09] %% fsolensky has left.
[22:10] <ggm> draft comparison with ZIlls
[22:10] <ggm> similar in intent
[22:10] <ggm> zill allocates flag. and field
[22:10] <ggm> control is by matching prefix/length rather than ID
[22:10] <ggm> are there interactions between different users?
[22:10] <ggm> what is preferred lifetime for access control?
[22:11] <ggm> how does it interact with router renumbering?
[22:11] <ggm> risks
[22:11] <ggm> caveats
[22:11] <ggm> not strong access control
[22:11] %% leslie has left.
[22:11] <ggm> on link attackers can forge prefixes
[22:11] <ggm> on site attackers can abuse privs
[22:11] <ggm> etc. but low cost method
[22:11] <ggm> huitema
[22:12] <ggm> conclusions slide, says this isn't a security mechanism. but this is true for both drafts. thats why zill kept his simple
[22:12] %% sukanta has arrived.
[22:12] <ggm> quick & dirty mechanism. just as good as a firewall.
[22:12] <ggm> bellovin
[22:13] <ggm> I have no objection to his syntax. I can interact with it. there are no bad interactions.
[22:13] <ggm> I specified the rules a bit more tightly
[22:13] <ggm> huitema should explore interactions
[22:13] <ggm> ties config of addresses to quality issues like lifetime, its a good thing.
[22:13] <ggm> <other> have to wonder, do we want to buld into arch, security domains and network topology co-incide?
[22:13] <ggm> its an over-used concept.
[22:14] <ggm> bellovin don't want to do it at all! but people say its a benefit of site-local
[22:14] <ggm> <other> site local has no redeeming features but I have the same problems with this idea.
[22:14] <ggm> bellovin this is an idea, a better way than site local, doesnt drag in the complexity
[22:14] <ggm> <other> can agree its marginal improvement
[22:14] <ggm> market out there believe addresses have security meaning, if not given will complain
[22:14] <ggm> no good technical justification
[22:15] <ggm> bellovin my lightbulbs don't have Secure key entry. need to be redesigned
[22:15] <ggm> perry
[22:15] <ggm> beauty of proposal is it moves things out of site local. (I think this was humour)
[22:15] <ggm> bellovin. if you want this for security, its better than site local
[22:15] <ggm> dave meyer. different topic.
[22:16] <ggm> prefix length problem is same in zills draft and your draft
[22:16] <ggm> having it in same place makes it easier to compare. but same issue can arise
[22:16] <ggm> bellovin absolutely. two length fields in same message. confusing!
[22:16] <ggm> meyer but less confusing than two prefix len msgs in two different things
[22:16] <ggm> tony li
[22:17] <ggm> site locals intentionally ambiguous. this isn't
[22:17] <ggm> margaret. this can be nested.
[22:17] <ggm> tony. made statements MUST not send.
[22:17] <ggm> so if configured to use, must not use another prefix.
[22:17] <ggm> but, I also want to speak globally.
[22:17] <ggm> but I committed to talking to you.
[22:17] <ggm> bellovin I don't agree there is a problem here.
[22:18] <ggm> tony re-read. to hear the thing, I have to follow rules. this limits me
[22:18] <ggm> bellovin. will work on this, reword if need be. I don't think this is that bad
[22:18] <ggm> don't get DNS issues for instance.
[22:18] <ggm> wasserman. <other> like to argue point with tony li.
[22:19] <ggm> sorry. I mean hain. tony hain.
[22:19] <ggm> I think
[22:19] %% mrose has left.
[22:19] <ggm> missed speaker.
[22:19] <ggm> mayer. take offline. I agree with tony. middle two bullets worded too strongly
[22:20] <ggm> huitema. same point.
[22:20] <ggm> provide information to hosts. if it comes from <that prefix> assume its a good guy.
[22:20] <ggm> Margaret (chair) had to reschedule Steve to today, to fit in. will also discuss in general site-local discussion
[22:21] <ggm> NEXT TOPIC
[22:21] <ggm> node requirements, john loughney, nokia
[22:22] <ggm> close open issues, go to last call
[22:22] <ggm> editorial nits
[22:22] <ggm> DHCP support
[22:22] <ggm> privacy extensions
[22:22] <ggm> mobile IP
[22:22] <ggm> security
[22:22] <ggm> DHCP should or may? comments that MAY to weak, SHOULD too strong.
[22:23] <ggm> wording recommendations SHOULD stateful address unless stateless clearly suitable in context
[22:23] <ggm> <floor> but this assumes a use-case. a task specific device? I don't understand this idea
[22:24] %% rafdalb has arrived.
[22:24] <ggm> I don't think DHCP address autoconf will be very useful
[22:24] %% brunod has arrived.
[22:24] <ggm> I think its a MAY for address config. but for other things, DHCP is modular, you can do DNS discovery for instance.
[22:24] <ggm> doesn't need to be a SHOULD
[22:24] <ggm> Dave Meyer. rephrase qn to ralf,.
[22:25] <ggm> was presentation on stateless DNS discovery. still interest in DHCP wg to push?
[22:25] <ggm> really two Qs. may make should/may arg easier.
[22:26] <ggm> DHCP used as the bit in the RA used for addressing, DHCP used as other stateful config.
[22:26] <ggm> follow M and O bit.
[22:26] <ggm> Ralf responds
[22:27] <ggm> jim. this is a MUST. not a SHOULD. the M bit will be set. you as an O can ignore.
[22:27] <ggm> customers who today have stateful env. are not in the process of deploying IPV6 moving stateless
[22:28] <ggm> it will happen for 3GPP. not boeing, not ford, not manufacturing. not just wireless customers or desktop
[22:28] <ggm> the reason we won the arg 10 years ago, to have stateful paradigm, is because of those customers
[22:28] <ggm> john
[22:28] <ggm> we tried for text to cover this
[22:28] <ggm> jim
[22:29] <ggm> problem I have with ths, having implemented 1122 and 1123, what happens in eng. is the trade-off. you go down the MUST/SHOULD/MAY
[22:29] <ggm> if you have a MAY for something which is declared to be set in 2461/2462. there is a faction who want only stateless. this is not the backdoor
[22:29] <ggm> to get this
[22:29] <ggm> huitema
[22:29] <ggm> we clearly disagree
[22:29] <ggm> there is no question everybody everyone must support statefull. interop requirements drive this.
[22:30] <ggm> once you have interop, then the MUST become MAY and market forces decide
[22:30] <ggm> jim. my nodes boot into link local, this is stateful
[22:30] <ggm> the next phase, is to select the non-link-local address. I do not agree stateful or stateless is a given. its a choice.
[22:30] <ggm> huitema SHOULD is not a choice. unless you have a reason, don't do it. your arg is market driven. then MAY is enough
[22:30] <ggm> jim
[22:30] <ggm> don't agree with premise that stateless was the default
[22:31] <ggm> not the default and I never agreed ...
[22:31] <perry> I think that we MUST agree on whether we SHOULD use MAY
[22:31] <ggm> john. lets settle down
[22:31] <perry> or is that we MAY agree on whether we SHOULD.
[22:31] <ggm> ROb austien. I am closer to jim than huitema. but ..
[22:31] <ggm> sorry. lost the plot
[22:32] <ggm> [ sorry. I mean sorry, I lost the plot ]
[22:32] <ggm> hinden
[22:32] <Isomer> [ np :) ]
[22:32] <ggm> just to speak from floor, personal opinion is, I'd hate to see people build things in env. where this is not needed
[22:32] <ggm> have to do functionality they don't need. would hope we can find wording which can handle this and avoid non-compliance issues
[22:33] <ggm> perry. given how should and may are, its increadible how much time we are spending on this. we are being precise on how vague we want to be
[22:33] <ggm> in the end it wont matter. we can pick either and it will all be fine.
[22:33] <ggm> john. want to refer to chair.
[22:33] %% Cuchulain has arrived.
[22:33] <ggm> do we do a hum now, or ?
[22:34] <ggm> [why cant these people use mikes (sigh)]
[22:34] <ggm> <floor> I was one of the people who did this first time round, I dont have problems with text on slide
[22:35] <ggm> meyer text may not be strict enough.
[22:35] <ggm> i may vote no if its not clarified for some things
[22:35] <ggm> hinden
[22:35] <ggm> margeret raises another qn. proposals to split into address and non-address part.
[22:36] <ggm> have to ask the qn twice.
[22:36] <ggm> see if consensus to split between address and non-address?
[22:36] %% Cuchulain has left.
[22:36] <ggm> <floor> take to list, issue discuss and bring back to IETF later in the week? too much
[22:36] <ggm> john best to take to list?
[22:36] <ggm> jim returns to mike
[22:37] <ggm> john. I will work up text, take 5 min thus, put to email list
[22:37] <ggm> hinden put to list, tomorrow. get opinions
[22:37] <ggm> jim leaves microphone
[22:37] <ggm> new topics in this thing
[22:37] <ggm> privacy extensions for address config. RFC3041.
[22:38] <ggm> text to note some apps break using 3041 addressing
[22:38] <ggm> alain. DNS issues
[22:38] <ggm> names may or may not resolve. this breaks apps.
[22:39] <ggm> mostly in reverse path, with random address generation. if app relies on this then it breaks
[22:39] <ggm> <other> some apps need stable addresses. conflict with privacy. can have non-stable when don';t want to expose
[22:39] <perry> btw... dunno if everyone knows it, but the word for "issue which is meaningless but hotly debated" is "bikeshed", as in "What color do we paint the bikeshed"
[22:39] <ggm> so its just that 3041 is not appropriate for some uses
[22:40] <ggm> [hey, if this is *meaningless* then I can get eliza to do my record keeping for me ... -ggm]
[22:40] <ggm> <other> doesn't say anything about when this should be used.
[22:40] <perry> I didn't say this particular one was meaningless. :)
[22:40] <perry> just mentioning in general. we all know "Rathole" but I've found few know "bikeshed"
[22:41] <ggm> [ sorry. also lost it again. email called me -ggm]
[22:42] <ggm> can't advise per-node. have to advise per-app.
[22:42] <ggm> hinden: any objections to that text?
[22:42] <ggm> next. mobile IP
[22:42] <ggm> in IESG review.
[22:42] <ggm> texts to support mobile IP updated in this revision
[22:44] <ggm> perry. this v6 mobile router should be a v6 router, and do what v6 routers do. this seems strange.
[22:44] <ggm> can see intent. should is wierd.
[22:44] <ggm> wasserman. I thought it said all V6 routers should support mobile V6 requirements.
[22:44] <ggm> perry suggests since we can't agree what it means, we can't say its right yet.
[22:45] <ggm> clarify intention
[22:46] <Isomer> [ power outage -- bbl ]
[22:46] %% Isomer has left.
[22:46] <ggm> meyer need security in mobile V6. is that it?
[22:46] <ggm> john. so, I need to fix final sentence, then update it.
[22:46] <ggm> last bit
[22:46] <ggm> Security
[22:47] <ggm> still qns.
[22:47] <ggm> what level of security to document?
[22:47] %% sukanta has left.
[22:48] %% take-s has left.
[22:49] <ggm> margaret wasserman: if we need documents, we can have them written. we can decouple things
[22:49] <ggm> take offline
[22:50] <ggm> john. propose holding off on security section, update rest of doc, see if its ready for wg last call outside of the security stuff
[22:52] <ggm> do we need to specify/recommend security better? 'use IPSEC' is not good enough. is there a text we should be looking for? how do we capture this concern? nobody suggested any good text. happy to have discussions
[22:52] <ggm> hinden
[22:52] <ggm> leaning to defer until something comes out of security area
[22:52] <ggm> long time ago, when we did this stuff in V6 early days, the intent was good, but it seems where we are now
[22:52] %% take-s has arrived.
[22:53] <ggm> ipsec is not useful in every device, appliance that is web managed wants SSL, or with CLI wants SSH, requiring IPSEC doesn't make sense
[22:53] <ggm> need to think about this broadly. beyond scope to put in here now.
[22:54] <ggm> jim. this is sillyness.
[22:54] <ggm> I accepted IPSEC at the time.
[22:54] %% brunod has left.
[22:55] <ggm> secure the IP layer, then continue to secure other layers. get multi-layer security.
[22:55] <ggm> the idea was to develop a secure mechanism as a frontline defence. IPSEC is a must.
[22:55] <ggm> if we want to change that, go back into security,. not in this spec
[22:56] <ggm> [ ggm has to leave to go to WG for 10pm. will be around for another 10-15 min -ggm]
[22:58] <ggm> <other> lack of anything to replace IPSEC in this context.
[22:58] <ggm> Jim
[22:58] <ggm> to chairs. and ADs
[22:58] <ggm> when we first started this, it was 3GPP requirements. I am wondering if what we need to do here, is take the devices and
[22:58] <ggm> have requirements for device-types. servers, routers, faxes, printers. each one could then specify a device specific standard. could
[22:59] <ggm> then say WHY not do MUST. more palatable.
[22:59] <ggm> margaret
[22:59] <ggm> the idea was this was minimal requirements ALL devices need. other road is hundreds of documents
[22:59] <ggm> jim then its an editing job. take the MUSTS and look at them.
[22:59] <ggm>
[23:00] <ggm> <other> another way is based on service. remote serial vs etc etc etc. then a security recommendation
[23:00] <ggm> jim oracle will have different requirements to what we're focussed on. definately different to 802.11
[23:00] <ggm> margaret. we scoped this work NOT to modify the existing documents. if they need to be updated we'll do that in those documents not in this process
[23:00] %% jishac has left.
[23:01] <ggm> jim then I will do another edit. look for things not a MUST which was, is that fair? If I find one, it has to be fixed right?
[23:01] <ggm> Margaret. depends.
[23:01] <ggm> jim we have a MUST implement IPSEC.
[23:01] <ggm> margaret some are less clear
[23:01] <ggm> jim. I'll find the MUSTS and refer back
[23:03] %% sakai has left.
[23:03] <ggm> too many categories of devices to be clarified at device level
[23:07] <ggm> [ ggm has to bow out now. sorry. -ggm]
[23:07] %% ggm has left.
[23:07] %% venaas has left.
[23:07] %% venaas has arrived.
[23:07] %% venaas has left.
[23:08] %% take-s has left.
[23:10] %% takamiyama has left.
[23:12] %% rafdalb has left.
[23:17] %% akato has left.
[23:19] %% nakamura has left.
[23:40] %% perry has left.

ipv6@conference.ietf.jabber.com - 2003/03/20


[08:46] %% logger has arrived.
[09:55] %% carlalf has arrived.
[10:09] %% ekr has arrived.
[10:21] %% mrose has arrived.
[10:21] %% avri has arrived.
[10:22] %% brabson has arrived.
[10:22] %% rafdalb has arrived.
[10:24] %% behcets has arrived.
[10:25] %% brunod has arrived.
[10:25] %% sakai has arrived.
[10:26] %% sakai has left.
[10:27] %% mattz has arrived.
[10:29] %% resnick has arrived.
[10:30] %% _ruffi_ has arrived.
[10:30] <resnick> Anyone actually in the IPv6 room?
[10:31] %% mdf has arrived.
[10:31] <mrose> nope. i'm in defcon
[10:31] %% NedFreed has arrived.
[10:32] <NedFreed> Pete and I are both in asrg
[10:32] <mrose> lucky *you*
[10:32] <carlalf> · DHCPv6 DNS Resolver Configuration option, Ralph Doms

Two options
o Carry a list of IPv6 address
o Last Call IPv6 and dnsext WG
o Some comments though
§ DNS servers? (name servers)
§ Carry IPv4 addresses?
o Domain search list
o List of domain names to append fir resolution
o Passed dhc, IPv6 and dnsext WG last Call
· DHCPv6 is proposed Standard
· Implementation at TAHI connection
· Used with stateless DHCP for DNS configuration
o Two message exchange
o Lightweight implementation
o Document in
draft-droms-dhcpv6-stateless-guide-01.txt
[10:34] %% rafdalb has left.
[10:35] %% rafdalb has arrived.
[10:45] <carlalf> · IPv6 over fiber channel Review Request Claudio DeSanti
o Work in ANSI T101?
· Comment:
o Margaret Wasserman :
It is not on our charter to accept new drafts. It has to be discussed with AD and may be individual draft.
o Tomas Narten:
It is more productive and make it as individual submission, needs some review from the group

[10:46] %% kmurchison has arrived.
[10:46] <mdf> ANSI T11
[10:46] <mdf> (not T101)
[10:46] <carlalf> thanks MDF
[10:47] %% kurtis has arrived.
[10:51] <ekr> where is the address architecture on the agenda?
[10:51] <mdf> now
[10:51] <ekr> thnak,
[10:51] %% _ruffi_ has left.
[10:52] <mdf> you want i try to relay the discussion?
[10:53] <carlalf> Yes, go a head
[10:53] %% leslie has arrived.
[10:53] %% grimmo has arrived.
[10:53] <mdf> current discussion concerns 'is /64 a hard boundary?'
[10:56] %% grimmo has left.
[10:56] %% grimmo has arrived.
[11:02] <mdf> wg disagrees about merit or otherwise of /64 hard boundary - clarifying text to be produced for discussion on ml
[11:03] <mdf> document uses 'global scope' to mean IIDs created from eui-64 addresses with 'u' bit set to Universal
[11:03] <mdf> possible change is to modify document to use term 'universal scope' to match IEEE terminology
[11:03] <mdf> jim kempf - this is good idea
[11:03] %% kmurchison has left.
[11:04] <mdf> erik nordmark - supports this idea
[11:05] <mdf> 'u' bit interoperability
[11:05] <mdf> interop requirements are not clear
[11:06] <mdf> how to make it clear that there is no requirement to test that interfaces id's with this bit set are unique?
[11:07] %% ogud has arrived.
[11:07] <mdf> michel py - as there is no practical use of this bit, it is a placeholder
[11:07] <mdf> keith moore - hosts should not assume that addresses with 'u' bit set are unique
[11:09] <mdf> proposal is to draft text to clarify that 'u' does not indicate global uniqueness properties
[11:09] <mdf> iab recommendations:
[11:09] <mdf> publish at PS
[11:11] %% _ruffi_ has arrived.
[11:18] %% sleinen has arrived.
[11:24] %% ogud has left.
[11:27] %% Eliot has arrived.
[11:28] %% Eliot has left.
[11:55] %% hta has arrived.
[12:01] %% brabson has left.
[12:02] %% carlalf has left.
[12:03] %% rafdalb has left.
[12:09] %% paf has arrived.
[12:12] %% dcrocker has arrived.
[12:12] %% grimmo has left.
[12:13] %% dcrocker has left.
[12:13] %% _ruffi_ has left.
[12:16] %% sleinen has left.
[12:18] %% SRuffino has arrived.
[12:18] %% SRuffino has left.
[12:25] %% dcrocker has arrived.
[12:29] %% paf has left.
[12:30] %% resnick has left.
[12:31] %% mrose has left.
[12:32] %% Eliot has arrived.
[12:38] %% leslie has left.
[12:41] %% ole has arrived.
[12:42] %% ole has left.
[12:42] %% Eliot has left.
[12:43] %% SRuffino has arrived.
[12:44] %% brunod has left.
[12:44] %% SRuffino has left.
[12:44] %% NedFreed has left.
[12:47] %% mdf has left.
[12:47] %% ekr has left.
[12:49] %% hta has left.
[12:52] %% mattz has left.
[12:55] %% mark.ellison has arrived.
[12:55] %% mark.ellison has left.
[12:55] %% avri has left.
[12:58] %% kurtis has left.
[12:58] %% behcets has left.
[13:07] %% dcrocker has left.