Narrative Minutes

DRAFT Narrative Minutes for the September 6, 2007 IESG Teleconference

Narrative Scribe: Marc Blanchet <>
Edits from Magnus Westerlund and Lars Eggert.

1. Administrivia

Russ Housley: sip-answer-mode disappeared from the agenda. wonder why?

Cullen Jennings: revision got messed up not in time for the meeting. so I pushed to next meeting.

Russ Housley: addresses the DISCUSSes?

Cullen Jennings: should be, but submitted with wrong version number and got bounced.

1.1 Approval of the Minutes

Amy Vezza: minutes 23 aug, approved

Amy Vezza: no narrative minutes to be approved.

Review of Action Items

Amy Vezza: IANA action item for Cullen. Done?

Cullen Jennings: should be done by end of this meeting.


2. Protocol Actions

2.1 WG Submissions

2.1.1 New Item

o draft-ietf-mip6-cn-ipsec-05.txt - 1 of 4

Using IPsec between Mobile and Correspondent IPv6 Nodes (Proposed Standard)

Token: Jari Arkko

Jari Arkko: RFC2919 issue can not be fixed easily.

Tim Polk: looked at your response. no problems with the document. looking for specific language that says RFC3775 is mandatory. can't find it in the document.

Jari Arkko: assumption that it is implicit, but we can add it.

Tim Polk: was not clear to me. fine by me. we don't need to discuss my DISCUSS further.

Jari Arkko: Sam's DISCUSS

Sam Hartman: Am I the only one that think this document is broken? My DISCUSS is basically that the document is wrong from the ground up. Basically, IPsec does not do what this document expects IPsec to do.

Jari Arkko: document is not as bad as you think it is. problem is the document is too short. does not give details on how to run this thing, policies are, how to use IKE.

Sam Hartman: how do I know what home address is valid for a given IPsec identity?

Jari Arkko: assumption is run IKE on the home address and then you can use any address. Alternatively, have a VPN and trust the other party. I'm not personally fan of this model.

Sam Hartman: document does not say either one of these things

Jari Arkko: two things document says: show ownership of the home address and prevent flooding attack. explicitly says trust of VPN membership. in some situations, it may make sense, but not generic mechanism.

Sam Hartman: document does not say anything about the ownership of the home address.

Jari Arkko: I'm not going argue on this. Idea is not clearly described in the document.

Sam Hartman: need to discuss the updates issue?

Jari Arkko: don't care about the header. do care about any part of this as mandatory part.

Sam Hartman: 100% agree on this item.

Sam Hartman: update header to be reflected, they are changing the MUST NOT in the base spec.

Jari Arkko: agreed. nodes should not relax for this feature.

Jari Arkko: plan to go back author for each one of your DISCUSS. Others I can take care.

Sam Hartman: be aware this is a substantial discuss to resolve.

Jari Arkko: I know. revised id needed.


o draft-ietf-ccamp-inter-domain-rsvp-te-06.txt - 2 of 4

Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions (Proposed Standard)

Token: Ross Callon

Ross Callon: Russ's ones are straightforward. about comments that should be integrated. straightforward to fix.

Ross Callon: Sam proposed specific text to add. Neither I nor authors agree with security requirements in RFC4107. Automated key management won't happen, unless customers want it. customers don't want at boundaries since using static keys. within the domain, so many pairs of routers. If hacker can send packets to router in the service provider network, can do DOS attacks. Already some defences in place. Router community does not agree with RFC4107.

Sam Hartman: even if you have static keys, you want separate session keys, don't want to use long term credentials for your session trafic. 4107 says you need automated key management even if you use static keys. Same happening with new TCP md5, where pre-shared keys may be used, but automated key management is still needed. We may have discussion on RFC4107, but until that happens, it is a BCP.

Magnus Westerlund: should the BCP be changed or should the RFC be adapted for the BCP?

Ross Callon: difference of opinions: Sam and security community are right with RFC4107 and Sam note. Router community does not agree with RFC4107.

Sam Hartman: IESG note, not community note.

Ross Callon: if we state the security AD instead of IESG, then I'm fine.

Sam Hartman: I would hold my DISCUSS on that note.

Ross Callon: not sure how to resolve this. if we do put the note, the authors and router community won't agree. pushed back from the authors. they think it is wrong.

??: try a slight different note: technology does not apply for untrusted two domains, but for two domains owned by same carrier. ok for trusted partner.

Sam Hartman: if we do RCTPE in provider network today, same issue. IESG note rather than blocking the document is that there are instances that this is not true. Same issue within a domain. Issue is do we want all documents to conform to new requirements.

Ross Callon: what do we do when two parts of the IETF community disagree

Sam Hartman: if you don't agree with BCP, then discuss that BCP, instead of asking IESG to make an exception for a document.

Magnus Westerlund: I support that position.

Russ Housley: this BCP does request that you should describe when it does not apply.

Magnus Westerlund: rfc-to-be should include an applicability statement about that BCP.

Russ Housley: yes. could be in security section.

Sam Hartman: my assumption is that the RFC4107 analysis on this protocol will end up that you need automated key management. if that is not true, then I'll change my position. however, it is pretty clear for this instance.

Ross Callon: talks about N square keys, which is near the routers. domain boundary is not.

Sam Hartman: yes.

Russ Housley: basis of a discussion, but not that RFC4107 is not needed here.

Sam Hartman: going to kill you is the lifetime of the keys. between different organisations. people go and leave. brings into 4107

??: point I was trying to do. that technology will be used within an organization with two ASes.

Russ Housley: made all progress today. should have a separate discussion maybe with the authors?

Ross Callon: changing the BCP won't work. For this document, we might have the authors to put the text in the document they don't agree with. But is this going to be the way forward.

Sam Hartman: I will start blocking documents if I'm still on the IESG and documents are closed to new applications.

Ross Callon: You can't ask router vendors to spend millions for this.

Sam Hartman: maybe the IETF is the wrong forum for work that does not meet the IETF requirements

Ross Callon: maybe the IETF is the wrong forum for standardizing protocols for the Internet.

Sam Hartman: in some cases, yes.

Ross Callon: you just argueing that IETF becomes irrelevant.

Sam Hartman: if we can't convince vendors to implement core requirements like congestion control and security, then we should instead focus on areas we can.

Ross Callon: trying to produce standards of practical value in the industry. if needed, then there ought to be a way to convince the industry. if it is not needed, then there ought to be a way to convince ourselves this is not needed.

Sam Hartman: you can try to build that concensus. that means to be a community discussion.

Ross Callon: the note says the "IESG believes...". I don't think it reflects the IESG opinion as a whole.

Sam Hartman: then we don't have concensus to publish this document at this time.

Ross Callon: how are we going to fix this?

Sam Hartman: we may not have concensus to publish this document

Ross Callon: are we blocking any routing protocol document? nothing unique to this document.

Sam Hartman: certainly any routing document which is a new application.

??: attempt to find a compromise. RSVP has an integrity object. assumes MD5 authentication. does have a key id so you can rolls keys, but no neat way to do it. if we ok this document, on the basis that we started work on rolling keys with key ids in a generic way.

Sam Hartman: it is what I'm proposing

??: we could apply it to RSVP, etc... provider may choose to deploy it or not.

Sam Hartman: yes.

Sam Hartman: this is what we need to do for TCP MD5 update. this is what the IESG note is all about.

??: technology to rolling TCP, RSVP and OSPF keys.

Ross Callon: work going on with rollover keys with TCP should also be applied to RSVP keys.

??: should we go offline to write an IESG note.

Magnus Westerlund: last sentence should be changed to more general.

Jari Arkko: document is for the RSVP key.

Ross Callon: robust key management for RSVP too.

Russ Housley: done with this document.

Ross Callon: revised id needed since other DISCUSS

Russ Housley: OPS, routing, security and transport are interested to this. all paying attention on this.


o draft-ietf-manet-iana-05.txt - 3 of 4

Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group (Proposed Standard)

Token: Ross Callon

Lisa Dusseault: no position on this.

Ross Callon: clearly revised id needed. should go offline.

Russ Housley: you have a bunch of RFC-editor notes. should be incorporated in the revised id.

Jari Arkko: what is the plan?

Ross Callon: anyone manet network intend to use one routing protocol.

Lars Eggert: T-MPLS and MPLS never meet.

Ross Callon: only one routing protocol will fly.

Cullen Jennings: separate port for each protocol.

Ross Callon: Am I correct that udp ports we are ok?

Lars Eggert: if below/wkn 1024, then not that much.

Lars Eggert : about to eliminate the 1024 boundary, they could just ask for registered ports.

Ross Callon: something wrong if manet routing protocols end up more than 10.

Jari Arkko: a lot of research. would be more than 10 routing protocols. nice to share the port.

Lars Eggert: need an id in the packet to differentiate routing protocols.

Ross Callon: significant enough to go back to wg.

Cullen Jennings: twist the arms of transport guys to get ports.

Lars Eggert: you can point to me.


o draft-ietf-ipv6-ra-flags-option-01.txt - 4 of 4

IPv6 Router Advertisement Flags Option (Proposed Standard)

Token: Jari Arkko

Lisa Dusseault: no objection.

Jari Arkko: exchanged email with Mark. an RFC-editor note should address the issues. should clear.

Mark Townsley: will check editor note and let know in jabber.

Russ Housley: come back to this after Mark review.

Chris Newman: run the new text by the author on the first position to prior to any flags. requires change of the code.

Jari Arkko: yes. if Mark clear discuss, has to go back to authors for revised id, many editor notes there.

Mark Townsley: suggest wg, but up to you.

Amy Vezza: come back after Mark review.


2.2 Individual Submissions

2.2.1 New Item

o draft-salowey-tls-rfc4507bis-01.txt - 1 of 1

Transport Layer Security (TLS) Session Resumption without Server-Side State (Proposed Standard)

Token: Tim Polk

Sam Hartman: no objection

Tim Polk: went through Chris comment. don't think the wg will consider trivial change. what you are proposing will take long time to consider. should be considered for TLS v1.2, not in the context of this document. this is really a bug fix of what is out there. I understand your point, but it is a bigger issue and should be discussed in the TLS wg, not in this document.

Russ Housley: discussion on-going in the GSSAPI case.

Tim Polk: ought to be considered in TLS 1.2. not simple to do for the wg. already discussions and it is controversial.

Chris Newman: clear my discuss. wanted to raise the issue, because it merited discussion.

Tim Polk: don't want to cut discussion, should be in the wg.

Chris Newman: ok. we should delay a bug fix for that.

Amy Vezza: Chris cleared its discuss.

Tim Polk: revised id needed. Jari told about a appendix update.

Amy Vezza: approved and revised-id needed. TP to send a ticket when done.

Tim Polk: also will include rfc-editor note


2.2.2 Returning Item

o draft-duerst-archived-at-09.txt - 1 of 1

The Archived-At Message Header Field (Proposed Standard)

Token: Chris Newman

Sam Hartman: no objection.

Amy Vezza: no discusses for this document. Unless objection, then approved.

Cullen Jennings: point that this document includes real domain examples.

Chris Newman: it is an example of the use of the feature. feature is related to the infrastructure that needs to be setup. This is a case where a real server is appropriate.

Russ Housley: we should have in the minutes about the IESG recognizes this document includes examples that point to real domains rather than example domains and it is an exception.

Russ Housley: Chris to write some text in the jabber.

Amy Vezza: approved. additional notes in the official minutes.


o draft-ietf-ipv6-ra-flags-option-01.txt - 4 of 4

IPv6 Router Advertisement Flags Option (Proposed Standard)

Token: Jari Arkko

Amy Vezza: Mark has cleared its discuss. approved with point raised.

Jari Arkko: confirmation with other author. talking for new revision.


3. Document Actions

3.1 WG Submissions

3.1.1 New Item

o draft-ietf-dhc-pxelinux-02.txt - 1 of 1

Dynamic Host Configuration Protocol Options Used by PXELINUX (Informational)

Token: Jari Arkko

Amy Vezza: no discuss. unless objections, approved as Informational RFC.

Jari Arkko: point raised about too many RFC-editor notes. revised id needed

Amy Vezza: approved. send a ticket when document ready.


3.2 Individual Submissions Via AD

3.2.1 New Item

o draft-irtf-dtnrg-bundle-spec-10.txt - 1 of 1

Bundle Protocol Specification (Experimental)

Token: Russ Housley

Amy Vezza: no discuss. unless objections, approved as experimental.

Amy Vezza: see no objections. IRTF document handled differently?

Russ Housley: are in the process to create a new process. right now, as current.

Amy Vezza: approved as individual submission via AD.

Sam Hartman: via AD or via RFC-editor

Russ Housley: not sure.

Jari Arkko: eventually, comes from the IRTF.

Chris Newman: Michelle raised an issue about DTN URI.

Russ Housley: came out of Lisa's comment as well. I sent a note to fix this. Should not prohibit the publication until this happens. The RFCeditor should.

Michelle Cotton: is this an IANA action or not?

Russ Housley: not sure. Asked A to take ownership.

Michelle Cotton: will figure that out when in RFC-editor queue.


3.2.2 Returning Item

o draft-weiler-dnssec-dlv-03.txt - 1 of 1

DNSSEC Lookaside Validation (DLV) (Informational)

Token: Russ Housley

Amy Vezza: one discuss

Russ Housley: author has put forward a document that has not been posted. Russ is holding on behalf of DNS directorate and that the new document addresses their issues. would like have Russ clear and point raised.

Amy Vezza: approved.

Russ Housley: when new document posted, will send a note.


3.3 Independent Submissions Via RFC Editor

3.3.1 New Item

o draft-templin-rfc4214bis-04.txt - 1 of 1

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (Informational)

Token: Mark Townsley

Amy Vezza: many discusses

Mark Townsley: when softwire was created, blooming mechanisms. deal was only one standard published and then other mechanisms published. This document does fall under the problem statement, but does not fit necessarily the solution space. Overlapping in the solution space with softwire is arguable. This is just an update of an experimental RFC. Fine, but we do have here an experimental going to informational.

Ross Callon: why going to informational.

Mark Townsley: authors want, because implemented, deployed, experiment done. now informational.

Cullen Jennings: not the case. they want informational because experimental is not interesting to be implemented.

Jari Arkko: they want a standard

Mark Townsley: yes. they want an individual submission to be proposed standard. authors did a lot of AD shopping. End up in our plate by the RFC-editor.

Jari Arkko: good IETF fix issues to RFCs. equal opportunity for others. Are others published, same route?

Mark Townsley: all, not all. many are linguishing around. don't remember which got RFC. Teredo is one. Disallowing this is it going to disallow updates to others. don't know the answr.

??: if we publish that, what precedent are we setting? ok to publish if you deployed? ok to publish if you are published already? ok to publish if first draft was published before some date? criteria accross the board needs to be defined.

Ross Callon: is it deployed.

Mark Townsley: told it is deployed

Jari Arkko: fairly limited.

Mark Townsley: not accross the board.

Lisa Dusseault: two objections: replacing an IETF concensus document with an RFC independent submission document.

Mark Townsley: don't know the past of the experimental route.

Lisa Dusseault: I have been denied those requests. There might be some exception cases. not sure to do on this one.

Mark Townsley: how do I know what happened in the past.

Sam Hartman: need to look up the draft filename and see the tracker. looking at the index. RFC4214

Magnus Westerlund: draft-ietf-ngtrans-isatap.

Lisa Dusseault: went through IETF last call.

Mark Townsley: do we say: if it was IETF concensus document, then it can not go around through independent submission.

Ross Callon: agree with Lisa says, but do we have a rule that says it.

Sam Hartman: disagree with this. maybe you should be allowed to be published. there should be a publication path for this. If you are documenting what you did, then this is what the RFC series is for.

Mark Townsley: different since it is clarifications

Cullen Jennings: other than change in status, which we should reject. I'm missing the need for the fix.

Mark Townsley: current disagreement between authors about the need about this change.

Sam Hartman: Sandy says that RFC-editor board is the one suggesting to change the status, not the authors.

Cullen Jennings: I'm going to suggest not the change the status.

Mark Townsley: how this happen Sandy?

Sandy: document sent for review. one of the reviewers suggested to add a section saying that the experiment was done and this is the experiment results. Authors did the revision and put informational.

Mark Townsley: current version is -04.

Lisa Dusseault: fine to update an IETF concensus document through an independent submission, but not to obsolete it.

Chris Newman: obsoleting an IETF concensus document by another concensus action and the rfc-editor submission is not providing that.

Jari Arkko: Also agree with that. Side tracked. Is this harmful to the community? Considering softwire work. Main question to ask. With answer, we can give guidance to authors.

Russ Housley: we should not say that if no AD is shepherding it.

Chris Newman: my DISCUSS if RFC is published, then there should be a mechanism to update the RFC. Fine if you publish without the obsolete. Also need to care about the softwire issue.

Ross Callon: is technical change or not? does wg review technically?

Mark Townsley: two authors disagree.

??: enough ground to differ it.

??: yes.

Jari Arkko: they will be back. preferable if we state what we want to do.

Ross Callon: if document is out and technology deployed, there should be a way to update the document. we might want go to xperimental and wg last call, etc...

Mark Townsley: this document does not fall out in the IETF process and it should be.

Chris Newman: no problem if an AD is willing to shepherd it.

Cullen Jennings: three routes for documents. we allow the others to be published for what happened.

Jari Arkko: true. was under impression that ngtrans and v6ops, there was an agreement.

Mark Townsley: arrived at the end. wg was to be formed and that softwire was it. maybe there was another agreement.

Lisa Dusseault: when a document went through an IETF last call, an update to it through an independent submission, then an ietf last call is necessary.

Sam Hartman: then you need to update 3932 to do this. rathole here. Do authors really care about the obsolete header?

Jari Arkko: if we remove header, it is process-wise ok, but for the internet community, it might not be ok.

Sam Hartman: may or may not good for the internet community. but the RFC-series is there for people to send their document when IETF does not agree.

Jari Arkko: agree.

Sam Hartman: if we are not working in this space, then no issue.

Mark Townsley: but we are working in this space.

Sam Hartman: then we should wait until softwire.

Jari Arkko: should talk to authors, by asking ietf last call.

??: authors already did that with AD shopping.

Ross Callon: we should not penalise, but just say no.

Mark Townsley: agree that existing RFC should be updated. but update by small change.

Lisa Dusseault: if named different then maybe.

Mark Townsley: if we do, but some authors might disagree. Fred was pushing.

Ross Callon: I have no reason to doubt that this is not a right update. want to publish it if an AD wants to shepherd it.

Lisa Dusseault: same issue as another document. had to go through Last call.

??: find a shepherd.

Russ Housley: who is the shepherd AD is the question.

Cullen Jennings: where are the substantial changes?

Tim Polk: they need to show the experimental results are worth justifying the new update. Haven't seen anything in the diff.

Mark Townsley: same opinion than rfc-editor board

Cullen Jennings: if want to obsolete, then ietf stuff. if not obsolete, we will object from the fact that you are laying another protocol on top of existing protocol, which means a AD shepherd. Did not seen the need for the fix. If we find the need for fix, then we need justification for softwire.

Mark Townsley: reasonable. softwire is wg last call.

Chris Newman: actionable dnp or nasty iesg note and not obsoleting the previous document. want to see the text.

Russ Housley: hope to do in the mailing list.

Mark Townsley: cullen suggest discussing with the authors.

Magnus Westerlund: currently block by DISCUSS now.

Russ Housley: we have responsability to respond to RFC-editor promptly.

Cullen Jennings: we need to respond about the

Russ Housley: Sandy, can you relay this to your colleagues.

Sandy: would not object that it remains experimental. first version was not reviewed by editorial board.

Russ Housley: was done through IESG. can't imagine that we have last- called a document coming from the RFC-editor.

Ross Callon: remember that this was a ngtrans document.

Jari Arkko: quite clear that IETF last call and IESG ballot.

Sam Hartman: 4214 has the 3932 IESG note.

Russ Housley: why did we last called?

Sam Hartman: apparently, the last call was not concensus.

Jari Arkko: solves the problem.

Russ Housley: yes, it is not our document. it solves the process issue.

Mark Townsley: ok, but does not solve the softwire issue.

Lisa Dusseault: temporary ban does it apply to rfc-editor also?

Magnus Westerlund: yes,

Lisa Dusseault: go to softwire wg, I know we had an agreement to delay. do the wg agree to suspend this one?

Jari Arkko: suspend for an update?

Mark Townsley: two things make it different: RFC was published before softwire and it is just an update.

Lisa Dusseault: then if the wg does not care?

Mark Townsley: wg might say: if we publish, then mine also can be published.

Jari Arkko: but this one is already published.

Mark Townsley: if only is bug fix I'm not worried. but the overlapping is difficult to define for all other mechanisms.

Jari Arkko: yes not good route.

Russ Housley: what do you propose?

Mark Townsley: IESG thinks this is harmful to the work, however, recommends publishing if it provides critical update to RFC4214.

Cullen Jennings: we should be the judge of this fix. totally in favor of a bug fix.

Mark Townsley: I don't want to discuss the level of overlap.

Mark Townsley: but it is up to the RFC-editor to decide if it is a critical update.

Sam Hartman: I agree with Cullen that we should make that call.

Russ Housley: safest thing to do: given softwire close to finishing. note: harm the work, should not published at this time. open to publication after softwire.

Mark Townsley: same as others

Russ Housley: exactly. we are talking few weeks.

Mark Townsley: fine by that. authors will be annoyed. but that is ok.

Mark Townsley: number 3 with extra sentence:

Jari Arkko: I would not recommend publishing it. but I would let it go anyway because it is an update.

Ross Callon: is this going to have a statement about this is historic work prior to softwire.

Russ Housley: a note should say this is not a product of IETF.

Ross Callon: note says don't confuse this with softwire standard.

Lisa Dusseault: as independent submission, it will get IESG note anyway. Does anyone change its position if authors request to obsolete?

Cullen Jennings: all agree this should obsolete.

Russ Housley: approved it because it is an update. ask to be held after softwire publication.

Jari Arkko: let it go.

Ron Bonica: let it go as experimental

Dan Romascanu: let it go.

Lisa Dusseault: abstain

Sam Hartman: let it go

Cullen Jennings: strongly support MT.

Chris Newman: i'm with cullen.

Tim Polk: delay publication. ok if experimental.

Dan Romascanu: experimental

Mark Townsley: block it.

Russ Housley: 4 hold it, 2 abstain, 7 let it go.

Sam Hartman: weak let it go, fine with holding it.

Russ Housley: one discuss will give us the document back in two weeks.

Jari Arkko: let Mark decide.

Russ Housley: Mark are you willing to prepare a note to ballot it?

MT note in jabber.

Russ Housley: works for me.

??: clear my discuss.

Russ Housley: Mark put it in the tracker.

Sandy: who is going to tell us when ready.

Mark Townsley: happy to send email.

Russ Housley: we should say the IESG note.

Sam Hartman: recommend send note on 4214.

Russ Housley: appropriate.

Ross Callon: should be experimental?

Russ Housley: don't say anything on that.

Chris Newman: RFCeditor should do what they think.

Mark Townsley: agree.

Mark Townsley: once we have a standard, can we add a note pointing to the standard.



4. Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

o IPv6 Maintenance (6man) - 1 of 1

Token: Jari Arkko

Amy Vezza: any objection to the charter for external review.

Jari Arkko: I actually had an editorial note from Mark. will be sending later.


4.2 WG Rechartering

4.2.2 Proposed for Approval

o DNS Extensions (dnsext) - 1 of 1

Token: Mark Townsley

Sam Hartman: Mark, how do you respond to Ted's issue?

Russ Housley: Mark lost voice. Had the same question.

Russ Housley: Ted says there is two ways to read one of the sentences.


5. IAB News We Can Use

Olaf Kolkman: RFC-editor has published a process for errata. is on IAB. we will send message to various lists for discussing this topic.

Olaf Kolkman: discussed about the OECD meeting next year. ISOC involved in this and asked to IAB to be involved. still discussing.

Olaf Kolkman: close look at request for IANA under .arpa for dnsext document in rfc-editor queue.

??: list for rfc-editor discussion:

Olaf Kolkman: relevant to IETF, as well as independant and irtf streams.

draft: draft-rfc-editor-errata-process-00

??: OECD meeting?

Olaf Kolkman: OECD meeting is about future of internet. they have a questionnaire.

Ross Callon: have any clue of what they are going to propose.

Olaf Kolkman: will email url to


4.2.2 Proposed for Approval

o DNS Extensions (dnsext) - 1 of 1

Token: Mark Townsley

Mark Townsley: Ted is correct. wordsmiting needs to be handled offline. approving with edits?

Jari Arkko: ok for approving with your edits.

Sam Hartman: ok with review

Russ Housley: new text send. approved point raised.

Amy Vezza: charter approved pending edits from Mark.


6. Management Issues

6.1 IANA Ports allocation procedures (Cullen Jennings)

Cullen Jennings: sent 3 points, got comments from Jari. different recollection of what happens in Chicago.

Cullen Jennings: group agree?

Lars Eggert: most comments are fine. one is do we want the service names in the same registry as the port number registry. There should have been a service name registry but people use the port number registry.

Cullen Jennings: current situation is not the right way. some work involved in getting two different registries.

Lars Eggert: what do we do here? can you get a service name without a port number?

Cullen Jennings: freebsd removed the conflicts

Sam Hartman: freebsd and linux do not exactly match.

Cullen Jennings: today, if you need a service name, you must ask for a port. we should fix it at some point. silly to burning up ports. Several people have written before about this issue without success. I would like to encourage people not using this registry to use it.

Sam Hartman: strong agreement.

Lars Eggert: what is your proposal?

Cullen Jennings: enable allocating service name without port number.

Michelle Cotton: when we assign port numbers, we check exact match name conflicts and port already used.

Lars Eggert: two policies: enter service name without port number.

Michelle Cotton: not a problem now. just put blank or none.

Lars Eggert: enter service name with a special port number?

Cullen Jennings: no if we can instead put none or blank.

Michelle Cotton: what happens when we fix this with blanks? split into 2 registries?

Cullen Jennings: all proposals seen is 2 registries. yes.

Michelle Cotton: is this what we are fixing with the other document we are working on?

Lars Eggert: no, but they should not be conflicting each other.

Michelle Cotton: IANA need some guidelines about service names without port numbers.

Cullen Jennings: no change to the current process

Lars Eggert: Cullen will provide a policy for registering the service name without the port number.

Michelle Cotton: if they come back for getting a port number associated with the service name, then?

Lars Eggert: they should wait.

Michelle Cotton: as long as the instructions are clearly defined for IANA.

Michelle Cotton: we are reviewing the technical base for port number. Same for service name or ?

Cullen Jennings: need a rfc to review the whole process for registering port numbers and service names. So, same review as port number: use same policy.

Michelle Cotton: we can work on that offline, such as a new application form for service names.

Cullen Jennings: ok.

Cullen Jennings: agreement on modification on second point and work with IANA.

Amy Vezza: any record for the minutes?

Cullen Jennings: will paste in jabber.


6.2 Expert for RFC 4422 [IANA #98946] (Michelle Cotton)

Michelle Cotton: no expert assigned. not urgent. no pending request.

Sam Hartman: RFC4422 is the SASL base spec. needs an expert review. my proposal is to appoint Simon ... if IESG is fine.

Chris Newman: no objection.

Sam Hartman: will discuss with the proposed expert.


Working group news we can use

Jari Arkko: received two bof requests for vancouver: multicast mobility and ?least? future

Sam Hartman: do they believe these proposals are ready for standards track?

Jari Arkko: don't believe ready for standards track.

Sam Hartman: valid discussion if they believe it is ready for standards track.

Jari Arkko: will be discussing with the proposers.

Ron Bonica: having debate charter access SMI.

Lisa Dusseault: talking about http bof in vancouver they are making

progress on the charter.

Lars Eggert: SCTP documents are published. closing these two working groups. no bof proposal yet.

Sam Hartman: received interest for BOF: kerberos in ??? space. currently trying to see sufficient interest in the mailing list.

Cullen Jennings: no bof proposals received. trying to get some wg closing.

Dan Romascanu: closing hubmib. one bof request on netconf data modeling. possible consolidation of proposals.