The SDP (Session Description Protocol) Content Attribute (Proposed Standard) - 4 of 8
   Note: PROTO shepherd is Colin Perkins
   Token: Cullen Jennings

Bill entered NO-OBJ.

Cullen - clarifying whether this needs to be tied to specific media streams - I have examples that might be used with any media stream.

Ted - key point I was making was that it's up to the application to make sure that an association makes sense. Media features are usually negotiated on specific media types.

Bill - is a nonsense combination worse than no information?

Ted - depends on what the application does with incorrect information. Reserving a screensize for a slide that turns out to be audio would be meaningless. Initial set isn't very useful - would have pushed back harder but the extension mechanism has a low bar.  I didn't go DISCUSS because I thought the use case was very limited, but agree with DISCUSSes that this is not very useful yet.

Lars - no strong objection but think this is putting semantics on a tag that can't be enforced. Am I missing something? Could be label tag we already have is good enough.

Cullen - it's a hint. When you get two media streams and can only display one, this helps you choose.

Lars - is it up to the application or is this application-independent? Is the registry needed?

Sam - would it be harmful to have media comments in the registry? discuss the ordering issue Bill brought up (type first, then tag). Explain clearly that tags are intended to have meaning to the application and applications can't do anything without tags.

Cullen - would these three suggestions clear the DISCUSSes?

Ted - this would help the document.

Lars would clear with Sam's suggestions, but wouldn't be happy. Sent e-mail to Gonzalo, too - putting semantics on the tag is going to cause confusion in the future.

Brian - Cullen will send text - revised ID needed.

 o draft-ietf-rddp-sctp-07.txt
   Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation (Proposed Standard) - 5 of 8
   Note: PROTO Shepherd: David Black (Black_David@emc.com). Gen-ART Reviewer: Eric Gray (Eric.Gray@marconi.com)
   Token: Lars Eggert

Lars hasn't been able to look at DISCUSSes yet.

Sam - there's an RFC Editor note from David Black that would fix everything.

 o draft-ietf-tsvwg-rsvp-dste-05.txt
   Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels (Proposed    Standard) - 6 of 8
   Note: Gen-ART Reviewer: Sharon Chisholm (schishol@nortel.com)
   Token: Magnus Westerlund

No open positions and no DISCUSSes - approved with no discussion?

Magnus wants to do something with Cullen's comment - approved, point raised, writeup needed.

 o draft-ietf-dnsext-dnssec-experiments-03.txt
   DNSSEC Experiments (Proposed Standard) - 7 of 8
   Token: Mark Townsley

No open positions but a couple of DISCUSSes - need to discuss now?

Mark will work on Lars and Jari's DISCUSSes with chairs and authors.

 o draft-ietf-pwe3-sonet-13.txt
   SONET/SDH Circuit Emulation over Packet (CEP) (Proposed Standard) - 8 of 8
   Token: Mark Townsley

Ted did not state a position for this draft.

Need to discuss this now?

Brian - this is all about how you use RTP.

Mark - same issues as RFC 4553, this is the same encoding. RTP is adopted reluctantly, apparently by IESG mandate and other encodings are already defined in ITU specs, already published. Can't go back and overturn all this - too much history, too schitzophrenic. What you see in RFC 4553 is the result of the IESG and WG consensus at that time.

Magnus - this has never been anywhere near AVT for review. This is a misuse of RTP.

Mark - need to follow up on how much AVT interaction has happened - Allison was all over this from the beginning of SATOP.

Magnus - but there's never been a public call for review from AVT.

Mark - need to get to the bottom of this, but there's been a lot of water under the bridge.

Cullen - don't want to have reset with every new set of ADs. Will follow up with Allison and see what she was thinking at the time.

Mark - will let you talk to Allison so we don't attack her from all sides at once.

Russ - nothing we've talked about addresses my DISCUSS - the IPsec piece.

Sam - but is it useful to say "use IPsec" without profiling? It's worse to do have job half-way.

Mark - IP encapsulation is Informational?

Sam - no, this document explicitly describes all the encapsulations.

Brian - may need to leave for future study in this document, but then you have to do the future study - can't leave this dangling.

Mark - will discuss with authors, but will get pushback because "we're never going to use this". Need to review discussion to make progress on this.

Russ - just wanted to remind you that the DISCUSS was there...

2.1.2 Returning Item
NONE

2.2 Individual Submissions
2.2.1 New Item
 o draft-carpenter-rescind-3683-02.txt
   Progressive Posting Rights Supsensions (BCP) - 1 of 1
   Token: Sam Hartman

Brian posted in Jabber that Russ was chair for this document discussion.

Bill stated NO-OBJ.

Sam has one DISCUSS - David, how do we know we have enough consensus?

David - IETF list plus judgement call - people do reach different conclusions.

Sam - we've gotten more feedback for than against - do we have enought? Establish criteria for evaluating existing input, or get new input - these are the choices, which is it?

David - there are two parts - one part isn't controversial, major issue is that draft is trying to do two things at once.

Sam - "does two things at once" isn't valid DISCUSS

Ted - difficult to change document while you're moving a document to historic.  David is suggesting that we split the questions and do multiple consensus calls. That would give us a way forward.

Sam - completely agree with you. Need to be careful how we phrase this. Issues are related. Rescinding without restoring would be an incredibly bad idea.

Ted - but restoring without rescinding would make sense to lots of people.

Sam - will forward David's DISCUSS to IETF list, and propose two-question consensus call on IETF list.

Russ - best way to do this is by reissuing Last Call.

Sam - happy to do that, too.

Brian - not restoring, but also merging.

David - wording still needs work in this area.

Sam - not likely to push back on issues of clarity. Likely to push back on disagreeing with community consensus. One concern - do we want to agree how to evaluate the last call before we reissue it?

David - Do two Last Calls, serially?

Lisa - we can ask two questions without doing it serially.

Cullen - if the answer was yes, we need to say it was yes. If it was no, we need to know what to do.

David - I've been the rough part of rough consensus before. If there are two conversations at once, having them at all is the critical part.- Sam's call to have conversations at the same time.

Sam will give IESG day or two to see new last call text before sending it.

Sam - do we want to establish criteria before we get input?

David - we need more people expressing an opinion at all, from the general community.

Sam - we've had five or six responses in each round so far, all positive except for David. Will issue new last call with two questions (restore and rescind)? Will look at David's DISCUSS before issuing the Last Call for stuff we know we need to change. And thanks for the constructive way we've worked on this issue.

2.2.2 Returning Item
 o draft-carpenter-protocol-extensions-04.txt
   Procedures for protocol extensions and variations (BCP) - 1 of 1
   Token: Ross Callon

Document was approved with no discussion.

Chair responsibility returned to Brian Carpenter at this point.

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-dnsext-dnssec-opt-in-09.txt
   DNSSEC Opt-In (Experimental) - 1 of 6
   Token: Mark Townsley

Sam - Can we approve this one with lots of DISCUSSes on the normative dependency? Suggest approved, point raised, writeup needed.

 o draft-ietf-l3vpn-ppvpn-mcast-reqts-09.txt
   Requirements for Multicast in L3 Provider-Provisioned VPNs (Informational) - 2 of 6
   Token: Mark Townsley

Dan would like to see the edits for this document  - AD followup.

 o draft-ietf-tsvwg-quickstart-07.txt
   Quick-Start for TCP and IP (Experimental) - 3 of 6
   Note: Document Shepherd: James Polk (jmpolk@cisco.com). Gen-ART Reviewer: Francis Dupont (Francis.Dupont@fdupont.fr)
   Token: Lars Eggert

No DISCUSSes - any objections? None noted, approved with no discussion on this call.

 o draft-ietf-pwe3-cesopsn-07.txt
   Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) (Informational) - 4 of 6
   Token: Mark Townsley

Two DISCUSSes - we've already discussed the points with related documents?

Cullen - this document also says "don't use RTP", but isn't this what RTP is for?

Mark - was a discussion on this, need to review.

Sam - this doesn't fit audio/video profile that well, does it?

Magnus - not following that profile at all - should really define a new profile.

Sam - just making sure I understood, thanks.

Mark - also in AD follow-up - need to review history first.

Magnus - why Informational?

Mark - there was a war in the working group, two proposals, declared bankruptcy and went proposed standard with what they could agree on, with stuff they couldn't agree on as Informational. Trying to avoid competing proposed standards and let the market decide.

 o draft-ietf-pwe3-tdmoip-05.txt
   TDM over IP (Informational) - 5 of 6
   Token: Mark Townsley

This is also AD followup. Brian's DISCUSS is only a missing reference.

 o draft-ietf-tsvwg-vpn-signaled-preemption-01.txt
   QoS Signaling in a Nested Virtual Private Network (Informational) - 6 of 6
   Token: Magnus Westerlund

Mark - I asked VPN chairs for their opinions - that's where my DISCUSS came from. MPLS is mentioned specifically in the document, and think Fred's response says DoD-rooted part of the document is different, European sector uses public networks for this.

Ross - also agree with Mark's DISCUSS.

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-kelly-saag-des-implications-06.txt
   Security Implications of Using the Data Encryption Standard (DES) (Informational) - 1 of 1
   Token: Russ Housley

No active DISCUSSes, so approved with no discussion on this call.

3.2.2 Returning Item
NONE
3.3 Individual 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
NONE
3.3.2 Returning Item
NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
   NONE
4.1.2 Proposed for Approval
 o Network Endpoint Assessment (nea) - 1 of 2
   Token: Russ Housley

Objections to creation?

Ted - updates to charter?

The revised charter text was sent to the IESG less than one hour prior to the call.

Russ - huge amount of discussion.

Sam - also haven't had time to review.

Russ - first paragraph changed to note that there's a possibility that some vulnerabilities are not detected. Next two paragraphs are mostly new, some points are moved up. New paragraph explains what "posture" means. Added advisory mode versus mandatory mode (based on EKR's comments). Some editorials, and last paragraph before milestones is basically rewritten (about protocols, not about remediation, with both advisory and mandatory mode support). Some milestones also tweaked.

Brian - updated charter gone to mailing list?

Russ - should be happening as we speak (proposed chairs posting). Did we make Ted happy?

Ted - want to talk in two weeks. Still concerned about vendor-specific attributes - expect these will end up as mostly binary blobs, we're probably asking them to commit to doing work they don't need or want - maybe transport-only with an opaque string.

Sam - from last BOF, sense of the room that interop beyond transport is what the room really wants.

Ted - the people who were going to do the work?

Sam - at least the people who were there for chartering discussion. Need to drill down and see if people doing the work are signed up, or are just leading us along to get a charter approved.

Russ - but Ted asked on the list, and I didn't see responses that would convince me one way or the other.

Brian - meeting in San Diego?

Russ - both NEA and HOKEY are slotted, but meetings will be canceled if WG isn't chartered before San Diego.

Sam - do we want to send this modified charter out for external review?

Ted - if we're sending it to NEA, should go for external review, too.

Russ - we have time.

(some discussion about scheduling logistics here)

Sam - anything we can do to ensure that we get the information we need in two weeks?

Brian - ask specific questions about new charter - three or four questions?

Russ - think Ted's is the only open issue.

Ted - EKR also sent a long response to the IESG list.

Russ - If it only went to the IESG list, then I did not share it with the chairs as part of the comments to be addressed.  This was my oversight.

Leslie - definitely say what points are believed to be addressed.

Russ - will reply to e-mail and follow up on the External Review message with the revised charter text.

Will discuss again in two weeks.

 o Handover Keying (hokey) - 2 of 2
   Token: Russ Housley

Objections to creation of this working group?

Russ - not ready quite yet.

Sam - most complicated charter discussion ever. Worse than TRILL.

Brian - are there open issues for the charter?

Russ - people are heading into solution space. I'm sending private mail saying "stop it". Group needs two more weeks, I've taken the pen for the charter myself. Sam has proposed removing anything contentious, but I'm trying not to go there.

Sam - not sure we have a consensus here. Don't want to get to the end of the charter discussion with no plan. These people are suffering due to lack of a chair.

Russ - There are six nominees who have accepted. We don't want to have a temporary chair - it confuses people. The two BOFs had different chairs. There's a lot of interest - wish it was convergent interest.  Absolutely looking for two chairs here.

<at this point, narrative minutes recording stopped because the IESG went off to the land of personnel discussions>

Sam - can we see if we have more consensus on this version of the charter? Not sure what changes have been agreed to, and I'm probably not the only one who is uncertain.

Russ - will send Amy a fresh charter for two weeks external review.

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
 o Host Identity Protocol (hip) - 1 of 1
   Token: Mark Townsley

Any objections to changes to charter?

Mark - changes are to add NAT traversal and define an API for applications that use HIP.

Cullen - not sure what NAT traversal happens in BEHAVE versus how much in HIP. Are we changing our story on influencing NATs?

Brian - but HIP isn't deployed yet, so we're not talking about NAT support for existing protocols.

Sam - does BEHAVE want this?

Cullen - probably not, but have concerns about HIP NAT expertise at this time.

Brian - charter them to work with BEHAVE?

Mark - happy to add text about BEHAVE review, etc.

Cullen - not trying to add language about working style.

Lars - this is similar to IPsec on NATs, not like what BEHAVE is doing at all. There was a HIPRG document on NATs for HIP, but that's in the RG, in the WG.

Magnus - current charter says "current and HIP-aware NATs", broader than what we are considering now.

Mark - "need to study" in the  IRTF, but I was under impression that IETF WG was only concerned with legacy NATs and only IPsec-encapsulated HIP. Want me to talk to chairs about "HIP-aware"?

Cullen - no, that's OK. Now I know what the division between HIP and BEHAVE is supposed to be.

Lars - we're removing HIP-aware NATs because it's in the RG scope.

Magnus - I agree with Lars.

Mark - will discuss with chairs, but don't think this will be a problem because voice conversations matched the text we're looking at now.

Sam - then external review after the tweak?

Mark - does it have to go for external review? Fine with doing it, but wondered what the deal was.

Sam - is the API work completely new?

Mark - may have talked about this in the abstract previously

Sam - if so, don't think charter needs to go for external review (no change).

Mark - says application, not API - it can go out for review

4.2.2 Proposed for Approval
   NONE

5. IAB News We can use

From Leslie...

Now that the draft-ietf-grow-anycast document has passed, Leslie has put a question to the IAB to see if there is interest in pursuing discussion on the general anycast topic.

Still working on latest JFC appeal and Glassey complaint.

Documents expected out by 00 deadline - unwanted traffic workshop, document on transparency (which is part of the net neutrality discussions).

We're working on preparing the RAWS workshop for next week.

Will discuss independent submissions in e-mil, but believe Jari's document on IESG handling of individual submissions would be helpful input (and Jari agreed that it could be forwarded)

6. Management Issue

 6.1 Proposed new rules for I-D naming (Brian Carpenter)

Add historic prefix, point 3 and 4 aren't changed. Any other questions or comments?

Cullen - constructing ad hoc team IDs, makes documents look more important than they should be.

Brian - but we have been doing this for a few years, nothing new here. We're just coming up with a list for the automated submission tool.

Cullen - would like to sort out process around those teams, but it's a separable discussion.

Brian - any objections? If not, Brian will generate a ticket for the secretariat to notice. We need to announce this to the community because we are relaxing the rules on draft naming - will work on this, and new copyright text, very clearly.

 6.2 draft-iesg-sponsoring-guidelines (Jari Arkko)

Was a note, is now a draft - submit before 00 deadline?

Sam - what about ION? Now that you've converted to a draft (sorry), maybe it should be an ION?

Jari - will do discussion with draft and finish with ION.

Brian - this is all XML2RFC, so should be manageable. Silence on this by the end of the week means consent.

Cullen - think it looks good - can say this now.

 6.3 Sayre Appeal (Brian Carpenter)

If no one objects, Brian will send Amy a ticket with appeal response.

 6.4 Projected IETF stream for RFC Editor during CY 2006 (Brian Carpenter)

Large number of documents hitting the queue in 4Q07/1Q07? Braden isn't seeing the expected flood yet - same forecast?

David - if we cleared more DISCUSSes...

Brian - I'm seeing lots of Last Calls.

Ross - also lots of documents with comments out to authors, shooting for updates before IETF 67.

Sam - huge queue downstream of me, but don't know when this will release.

Jari - 18 documents between publication requested and RFC editor queue, should get at least 25 of my fifty estimated by yearend.

Brian - discuss this in two weeks, and make sure what's really maturing?

Cullen - 36 documents between publication requested and RFC editor queue.

Sam - RFC editor is insane to believe us

Brian - that's why he's asking us

David - don't want to build a backlong from us to the working groups

Brian - tell them it's 70 percent of the original estimate?

Bill to look at these queue levels? 236 documents for entire IESG (as of today)

Seven documents in AD evaluation, staying in this state too long.

David - think we are starting to build the backlog

7. Agenda Working Group News

Jari Arkko

Ross Callon

Brian Carpenter

Lisa Dusseault - ATOMPUB has revised their document and filled in a security considerations section :-), HTTP BOF hasn't had a call for participation yet and isn't on the agenda yet.

- Brian - very late to announce a BOF at this point.

- Sam - a little worried about agenda - know Russ's deconflicting hasn't happened yet.

- Lisa and Ted will talk about this offline.

Lars Eggert

Bill Fenner

Ted Hardie - LTRU has put out a draft 4645bis; it has more than 800 pages.  We need to coordinate with IANA on how to manage the set of updates it contains, as well as work out LC logistics.  The group may also use an external web site for discussion, rather than using updates to such a long draft.

Sam Hartman - SSH declared victory, INCH declared defeat, both closed

Russ Housley

Cullen Jennings - raving on IETF meeting agenda - we have a good early agenda but no one is looking at conflicts until the week before the final schedule cutoff. Need to escalate this (and Sam had suggestions about how to do this).

David Kessens - HUBMIB chair will be replaced as mutually agreed. Open OPS call for new WG chairs doesn't always happen if WG is close to closing

Jon Peterson

Dan Romascanu

Mark Townsley

Magnus Westerlund - NSIS and RMT should have new chairs announced in a week