Authenticated Chunks for Stream Control Transmission Protocol (SCTP)
   (Proposed Standard) - 3 of 8
   Token: Magnus Westerlund

Bill entered NO-OBJ.

Don't need to discuss DISCUSSes today. Jari's comment is important - raised issue of key management. Got a response about TLS, but this isn't defined anywhere. Is there anything in progress that will help with this?

Magnus - is in pipe, or should be in pipe.

Jari - is that a key management problem, or management of shared secrets? TLS would solve practical problem.

Bill - is security document about when key management is required here? it should be.

Cullen - missed this - doesn't protect against on-path unless you have shared keys, which is ridiculous for most applications.

Brian - Jari needs to decide if this is a DISCUSS pretty quickly - before version 08.

Russ - I chose not to block on RFC 4107 because shared secret isn't required for many of the applications and manual keying would cover most of the rest. As long as there is a key ID, adding key management is straightforward..

Jari - Based on Russ's response I do not think I need to enter a DISCUSS.

 o draft-ietf-l2tpext-failover-12.txt
   Fail Over extensions for L2TP "failover" (Proposed Standard) - 4 of 8
   Token: Mark Townsley

Bill entered NO-OBJ. This draft goes into AD Followup.

Russ - will Jari's DISCUSS need a new ID?

Jari - don't know, Mark didn't know the answer but said he would find out.

Cullen - can I DEFER?

Russ - go AD followup, so we can resolve in less than two weeks.

Brian - AD followup will hold the draft where we want it.

 o draft-ietf-mipshop-cga-cba-03.txt
   Enhanced Route Optimization for Mobile IPv6 (Proposed Standard) - 5 of 8
   Token: Mark Townsley

Bill and Russ entered NO-OBJ.

Has enough votes to move forward, will go Point Raised so Mark can tell us if the notes are correct, etc.

 o draft-ietf-pwe3-wildcard-pw-type-02.txt
   Wildcard Pseudowire Type (Proposed Standard) - 6 of 8
   Token: Mark Townsley

Bill entered NO-OBJ.

Also has enough votes to move forward. Again, will go Point Raised so Mark can tell us if the notes are correct, etc.

 o draft-ietf-lemonade-deployments-05.txt
   Deployment Considerations for lemonade-compliant Mobile Email (BCP) - 7 of 8
   Token: Ted Hardie

Bill entered NO-OBJ.

Ted - need to DISCUSS here.

(Scribe requested to stop recording at this point)

Document goes into AD followup.

 o draft-ietf-smime-cms-mult-sign-03.txt
   Cryptographic Message Syntax (CMS) Multiple Signer Clarification (Proposed Standard) - 8 of 8
   Token: Sam Hartman

Bill and Jon entered NO-OBJ.

Document is approved.

Brian - is there any reason to expect an RFC Editor note?

Russ - there's not a single comment.

Brian - then we can let this one go!

2.1.2 Returning Item
NONE

2.2 Individual Submissions
2.2.1 New Item
 o draft-heard-rfc4181-update-00.txt
   RFC 4181 Update to Recognize the IETF Trust (BCP) - 1 of 1
   Token: Dan Romascanu

Bill entered NO-OBJ.

Document is approved.

Brian - very straightforward - we can let this one go as well, right? (no objections raised).

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
       Reviews should focus on these questions: "Is this document a reasonable
       contribution to the area of Internet engineering which it covers? If
       not, what changes would make it so?"

3.1.1 New Item
 o draft-ietf-mpls-iana-rsvp-session-flags-00.txt
   Codepoint Registry for The Flags Field in the Resource Reservation Protocol
   Traffic Engineering (RSVP-TE) Session Attribute Object (Informational) - 1 of 2
   Token: Bill Fenner

Document was approved with no objections and no notes.

 o draft-ietf-mip6-dsmip-problem-03.txt
   Problem Statement: Dual Stack Mobility (Informational) - 2 of 2
   Note: PROTO shepherd is Basavaraj Patil
<basavaraj.patil@nokia.com>.
   NOTE: There are significant RFC Editor notes!
   Token: Jari Arkko

Jari - Brian DISCUSSed the issue that the document adds significant complexity. I share Brian's concern, and this was discussed when working group was charterered for the work. Point was made that that this might encourage IPv6 deployment to avoid that complexity.

Brian - this path forward gives us two solutions to the same problem, and both would have to be supported by anyone who roams.

Ross - a permanent thing, probably.

Brian - hard to get rid of.

Ross - hard to avoid this given the state of the world.

Brian - should we be improving the world? Don't want to just block this document.

Jari - probably have to wait a little bit to approve this document anyway. This document didn't go for IETF Last Call - we could ask for more input from the community.

Brian - seems very appropriate. Thomas Narten also sent in comments (late). It's not the document that's to blame here, can go forward with suggested text changes.

Jari - so, revised ID needed and doesn't go for IETF Last Call at this time.

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD
       Reviews should focus on these questions: "Is this document a reasonable
       contribution to the area of Internet engineering which it covers? If
       not, what changes would make it so?"

3.2.1 New Item
 o draft-kalin-geant-urn-namespace-01.txt
   A URN Namespace for GEANT (Informational) - 1 of 2
   Note: Sent to URN-NID list for review in November of 2006
   Token: Ted Hardie

Ted - just put in an RFC Editor Note - could people look at it and go on?

Brian - why a non-standard definition of lexical equivalence?

Ted - they picked the definition they wanted, why challenge that?

Brian - I wonder if they thought it through. But I can clear.

Bill cleared DISCUSS, too.

Document was approved for publication with no objections.

 o draft-saintandre-xmpp-urn-02.txt
   A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) (Informational) - 2 of 2
   Note: Sent to URN-NID list in November of 2006
   Token: Ted Hardie

Ted holding a DISCUSS for changes that have already been made to the working copy. Revised ID Needed and it can go forward when the DISCUSS is cleared.

3.2.2 Returning Item
NONE
3.3 Independent Submissions Via RFC Editor
       The IESG will use RFC 3932 responses: 1) The IESG has not
       found any conflict between this document and IETF work; 2) The
       IESG thinks that this work is related to IETF work done in WG
       <X>, but this does not prevent publishing; 3) The IESG thinks
       that publication is harmful to work in WG <X> and recommends
       not publishing at this time; 4) The IESG thinks that this
       document violates the IETF procedures for <X> and should
       therefore not be published without IETF review and IESG
       approval; 5) The IESG thinks that this document extends an
       IETF protocol in a way that requires IETF review and should
       therefore not be published without IETF review and IESG approval.


       Other matters may be recorded in comments to be passed on
       to the RFC Editor as community review of the document.


3.3.1 New Item
 o draft-nagami-mip6-nemo-multihome-fixed-network-03.txt
   Multi-homing for small scale fixed network Using Mobile IP and NEMO (Experimental) - 1 of 1
   Token: Jari Arkko

Ted - is this getting deployed anywhere?

Jari - no information.

Brian - thought I'd seen a note that it was deployed.

Ross - document claimed at least testing in a lab.

Jari - value of that statement can be questioned, of course, but this is discussing the use of protocols, not doing anything new.

Ted - not suggesting that we block this, just asking for information when I send my note to the RFC Editor.

Ross - this seems related to RAM and might be useful.

Jari - chairs of both working groups not happy that they hadn't been consulted, but that's life.

Brian - that's what the 3932 procedure allows.

The conclusion is that there is no problem for this draft to go forward.

3.3.2 Returning Item
 o draft-joslin-config-schema-17.txt
   A Configuration Profile Schema for LDAP-based agents (Informational) - 1 of 1
   Note: Proposed for response 2, note 2 of RFC 3932
   Token: Ted Hardie

Ted will send text for IESG Note, based on Note 2.

Russ - can put this in the write-up.

(and Ted did so, during the call).

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
   NONE
4.1.2 Proposed for Approval
 o Media Server Control (mediactrl) - 1 of 2
   Token: Cullen Jennings

Any objection to creation?

Russ - sent a comment about liaison stuff.

Cullen - need to delete that, we've gotten other comments about things that need to be fixed. We'll fix them and fix the milestones. How do people want to handle this?

Brian - are you sure that they won't need normative reference to framework document?

Cullen - definitely viewing framework as boxes and arrows description, with no normative text. Protocol spec would be normative and standalone.

David - milestones were most important for me. Could be clearer that "examine" means "propose changes", not doing it themselves. Don't see any major problems, can probably agree to disagree about scalability, we could talk about that forever.

Cullen - "approved, point raised, writeup needed?" Don't know the process here...

David - please don't bring back!

Brian - we'll trust you to do the right thing ("approved waiting new version of text").

 o Pre-Congestion Notification (pcn) - 2 of 2
   Token: Lars Eggert

David - have objection but should be an ABSTAIN, not a DISCUSS. Happy to discuss it, of course. Not convinced this will really help anything or fix any problems we have.

Lars - if you have a network with inelastic traffic and it approaches congestion, or there's a routing change, the flows don't react to packet loss. This working group group will define how to transport congestion information to a boundary, so the other flows don't continue to impact everything.

Brian - someone has to try this.

David - research, stay experimental for Internet scale.

Lars  - couldn't deploy this on a wide scale with current charter. There are problems with large areas, interaction with non-PCN networks...

Magnus - You need a mechanism that uses the PCN information that can affect the flow..

Brian - if you're ignoring David's ABSTAIN, there's a danger that these people will think they can break ECN architecture, etc.

Lars - need to say something about ECN and about Diff-Serv.

Brian - "all the nodes trust each other" - Sam would be upset by this assumption.

Lars - but they trust each other for routing information.

Brian - but that's not BCP 61.

Magnus - need to remind people that they do need a security story, but administrative domains can count.

Russ - "trust each other for <blank>", not blanket trust. That would help.

David - did Dan ask for management work on this?

Dan - yes, as part of the existing documents proposal, but working group could decide for a separate document - as long as it's not ignored or lost.

Brian - want to run the revised version past us?

Lars - yes.

David - my abstain is a warning that they'd better not break the Internet, or there will be issues when the documents need to be approved by the IESG..

Brian - need this back on the agenda? Can approve, pending new charter text. (no objections)

Lars - have chairs if this is confirmed.

Brian - good news.

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
   NONE
4.2.2 Proposed for Approval
 o Network Mobility (nemo) - 1 of 2
   Token: Jari Arkko

Jari - need to discuss David's comments. Mail to IETF went out a day or two ago, so we do have some time (wasn't planning to ask for approval today). Didn't fully agree that there's no demand or requirement for this work. There's real demand from at least one area.

David - can abstain, but still have issues. IETF is not a research lab for vendors.

Brian - there are at least couple of vendors in the aircraft space... is the NASA comment valid?

Jari - Bill Ivancic has been working in this area for years, and what he is saying is that the IETF is giving the airline industry a chance to do something, and that they need to deliver or else the IETF will not look at this problem later. This is good news from our perspective, they understand the situation.

David - still have issues. "Address" isn't "IP address" - ambiguous. Please be clearer about scope of technologies for the charter - whether satellites are in scope, etc.

Jari - main thing is that tunnel overhead doubles RTT.

David - communication through the ground is much faster, and this affects the solutions you look at.

Jari - problem isn't really tunneling on the ground, it's backhauling for unnecessary round trips.

Brian - Africa doesn't have ground links, anyway, so you're going to end up with satellite hops in addition.

David - all this can be engineered. My point is that aviation should be an example case, not the only one.

Brian - Jari just has to bear this in mind for the next version.

Jari - home agent on wrong continent is the real problem.

David - this happens in the non-moving case, too. Question is whether you need protocol work. Doing this for re-charter is best approach. Do others agree?

Jari - this is going to go forward for aviation, could recharter for other two environments.

David - not convinced the other two environments should even be in the charter.

Will return for March 8th telechat.

 o SIP for Instant Messaging and Presence Leveraging Extensions (simple) - 2 of 2
   Token: Jon Peterson

Any objections? None noted, so recharter is approved, pending an edit from Jon.

5. IAB News We can use

Loa - one basic item, agenda for plenary in Prague.

Working on discussion on internationalization. Format may be two presentations plus panel discussion, but still discussing.

Will do normal IAB Update and open mike.

Brian - reached conclusion on NomCom slate?

Loa - yes, we have (can't tell you anything, of course).

Brian - NomCom now contacts nominees to see if they are still OK.

Loa - had quite a bit of action with NomCom this year, way more than previous year.

Cullen - looks like IAB has sent confirmation to NomCom.

Brian - has ISOC board confirmed IAB?

Cullen - have voted to confirm, but haven't been officially notified. Probably a week from finalizing.

Bill - "only a week late, so the second week is OK..."

6. Management Issue

6.1. Downref to IS-IS documents (Bill)

Bill - This comes down to timing, maybe we can agree on a plan for my successor.

Bill - Looking at several IS-IS documents in my queue with references from other working groups. Would like to get them on the standards track. IS-IS is unique, defined by another SDO, so very delicate what we do on standards track. Alex had an agreement for IP-only documents, but some documents haven't been moved. Would have been standards-track, except for our agreement with ISO. Shouldn't be blocking new standards-track documents that refer to old IS-IS documents, or we'll never get everything on the standards track. Would like to publish these documents on standards-track without waiting for other documents to be published.

Ross - long list, hard to get out at one time.

Bill - want to find a different way forward. These documents would be published as Informational just to publish, then republish... silly. We have a 3967 hammer. This isn't a nail or a screw. One option is "call this out at Last Call time", or using Klensin downref (and calling out at Last Call). Klensin document seems contradictory on the critical point. Think this combination is the best way forward.

Brian - makes sense to me. Although we have a habit of using the tool for Last Calls, nothing prevents us from doing one manually and covering a lot of these documents in one Last Call.

No one on the call had any objections to Bill's proposal.

 6.2 Expert for RFC4236 [IANA #62135] (Michelle Cotton)

Ross - think RFC number is wrong (OPES?)

Bill - it's actually RFC 4326 - ULE.

Cullen - one candidate would be chair and document author. A lot of hats to wear at once, but does anyone have a better choice?

Brian - put on action list with Mark as stuckee...

 6.3 Approve ion-procdocs (Brian Carpenter)

Brian - at least one comment from someone, don't think I got any other comments. Anyone want to raise a late comment? (No voices) Will make proposed change ("obvious clarification") and post it.

 6.4 Registry for compression hints (Michelle)

Michelle - have been talking with Steve Casner, he suggested procedures. Can I get IESG confirmation, or do we need to do anything more?

Magnus - Reasonable to go to RFC required, since routers need to understand the different hints. It can't be proprietary hints.

Bill - standards required? This is a 2434 word. IETF Consensus would be fine with me, too.

Brian - standards action could be over the top for this.

Magnus - will make this IETF consensus.

Brian - need to make sure this still exists in 2434bis (it does, with a different name - "IETF review").

Michelle - for old RFCs with no procedures, can IESG just make these decisions, or involve the community? We'll have more of these come up.

Brian - believe this is in scope for IESG to decide, since we're not changing procedures.

6.5 ID Formatting (Bill)

Question when working on tool for submitting ID - is having a publication date on the first page a requirement? It's not listed as a requirement - expires date is, but not publication date.

Bill - asked Michael to scan the directory to see if there are drafts with no dates.

Russ - make this a requirement and be done with it.

Brian - if we're in prior art discussions, a date would be a really good thing.

Bill - do we have consensus for requiring a date?

Ted - how free are you going to be on the rules for date formats?  Everyone has a date, but there are lots of formats.

Jari - do we have an operational need for this information?

Bill - people who mirror the directory don't get the metadata - could insert the metadata, that would be one way

Jari - don't go there (inserting in PDF, etc)

Cullen - IPR discussion is clearly compelling.

Bill - defer this to the mailing list so we can resolve this.

Magnus - really good to have a date when submitted for IPR.

Jari - question is whether we require it.

Brian - 4228 makes the assumption that we can extract a date from the draft. Bill, please send a note about this to the list.

7. Agenda Working Group News

Jari Arkko - conference call with WiMAX Forum about liaison statement, speeding up on NetLMM and MIP6. Monami6 is working on adding a filter to Mobile IPv6. The discussion was lifted out of the WG because some of us feel a more generic approach than something tied to Mobile IPv6 is in order. Ongoing discussion in the int-area list, please join.

Ross Callon - first draft of MPLS security framework, will be looking for security advisor

- Russ - people who are interested aren't funded - we know it's a need, haven't been able to fill it yet.

Ted Hardie - informal feedback on legg documents from ITU-T - "we don't think there's a constituency for this, and if there was, we'd want it". Unless Sam has an opinion, this will be Experimental until a constuency appears.

- Brian - Independent submission to RFC Editor?

- Russ - not good since we've been through IETF last call.

- Brian - looks like's it's gotten little review.

- Ted - think that people who understand it think somewhere between "mostly harmless" and "possibly useful". Not clear whether the category of people who can use this will grow.

- Ted - OPES-SMTP and 2518bis are coming out of working groups that will die if we approve the documents - please fix, don't try to discuss with dying working group.

- Cullen - as chair, think that if we lose context in Ted's head the documents will fail.

Magnus Westerlund - NSIS is making progress. Whole NAT traversal grand plan doesn't seem to be happening (ICE/STUN/TURN space) according to proposed schedule..

- Cullen - this set of documents is extremely complex and gets a lot of new reviewers every new version. The editor is producing an incredible number of drafts for the coming IETF - need to work on growing authors in RAI. Chairs are trying to drive this work forward but documents still have a ways to go. Hope we're finished by this IETF but expect between Prague and Chicago is realistic.

- Magnus - At least there are no lack of reviewers.

- Cullen - no lack of work on these documents! Document authors are aware these documents are highest priority.