M-ISIS: Multi Topology (MT) Routing in IS-IS (Proposed Standard) - 1 of 10
   Token: Bill Fenner

Bill - previous versions said "you can use DSCP", but that's not what it's for. Is there any standard work going on to say how operators demux overlapping address space?

Brian - any kind of packet snooping has the same problem.

Mark - like L*VPN

Bill - but that's usually interface-based. In this draft, people want to have multiple topologies with overlapping addresses, and on the same interfaces. No way a standards document is going to mention "demux on DSCP" even though that's what people are going to do.

Brian - this isn't much value, it's out of scope. "Which kludge will you use?"

Bill - but anything we do will be a kludge, and the IESG isn't going to standardize a kludge.

Mark - should be Informational.

Bill - may be possible to get people to write down thinking,...

Brian - but you don't want an informational reference to a document that hasn't been written yet, right?

Mark - everyone else says "out of scope, we'll wash our hands..."

Sam - interface-based isn't a kludge

Brian - but no one has written that up yet.

Bill - would not be bad to bring this up as RTG area working group item - it's not an IS-IS topic

Brian - a lot of documents on this agenda, guys.

Mark - going NO-OBJ,

 o draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt
   RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery (Proposed Standard) - 2 of 10
   Token: Ross Callon

No DISCUSSes, approved with no discussion on this call.

Yoshiko - for this document, IANA asked lots of questions - have IANA considerations been revised?

Michelle - can someone hold a DISCUSS for this?

Brian - we'll go "writeup needed", and this will let us figure it out.

 o draft-ietf-ccamp-gmpls-segment-recovery-03.txt
   GMPLS Based Segment Recovery (Proposed Standard) - 3 of 10
   Token: Ross Callon

No DISCUSSes, approved?

Ross - Bill has a reference update as an RFC Editor Note.

Michelle - we just got author response on IANA questions - can you hold this one just like the previous document?

Bill - we'll update the RFC Editor note and make sure IANA questions have been answered.

Brian - tracker will point back to Ross for next step.

 o draft-ietf-rddp-mpa-08.txt
   Marker PDU Aligned Framing for TCP Specification (Proposed Standard) - 4 of 10
   Note: PROTO Shepherd: David Black ( black_david@emc.com). Gen-ART Reviewer: Eric Gray (Eric.Gray@marconi.com)
   Token: Lars Eggert

No DISCUSSes - approved with no discussion on this call.

 o draft-ietf-idr-as4bytes-12.txt
   BGP Support for Four-octet AS Number Space (Proposed Standard) - 5 of 10
   Token: Bill Fenner

Brian stated NO-OBJ on the call.

Bill - There are no DISCUSSes, but a LOT of commentary. Not comfortable just approving this... What about all the 2119 language fixes that authors need to make?

David - not a DISCUSS because I don't want to block the document. More important to get it out, just that authors could have done a better job.

Sam - where are the code points defined that are required for this?

Bill - ASTRANS is already allocated, this was David's point, and it's very sensible to point that out in this in the document.

David - if authors are willing to make small changes, great, but it's important to publish. This document isn't actually WRONG, so don't want to hold it up.

Bill - will hold a DISCUSS to allow for a new ID, if that's the right way to address comments. Approving this ID makes getting a new ID work oddly.

 o draft-ietf-midcom-mib-09.txt
   Definitions of Managed Objects for Middlebox Communication (Proposed Standard) - 6 of 10
   Note: SEC-DIR Reviewer: Radia Perlman (Radia.Perlman@sun.com). WG Shephard Melinda Shore
   Token: Magnus Westerlund

Sam stated NO-OBJ because Magnus already has DISCUSS on the downref issue.

Cullen - would like to talk about this. Talking to Lars, the issue with this document is that no one intends to implement it. My concern is that we don't block other documents becoming PS, because we've already approved a PS. No problems with publishing THIS document. Experimental would also solve downrefs.

Dan - not sure I understand relation about protocol implemented or not. I have another document in the the same situation on this agenda. Does this make a difference?

Magnus - I don't think so, we've run the process in the working group and need to publish the output. We can go HISTORIC in three years.

Brian - this was a very complex decision process, but this is what the working group chose.

Cullen - but no one in the working group agrees.

Bill - maybe they thought it was the only answer the IESG would accept.

Cullen - don't go there, I don't care about publishing this, just don't want to block other things.

Sam - it is reasonable for the IESG to publish at a lower level, but I'm not saying anything about this document, and we have to use this right sparingly.

Brian - this is a MIB, not a protocol

Cullen - no, it is a protocol

Brian - but I don't see how publishing a MIB keeps us from publishing a protocol later

Bill- how serious are we about avoiding two standards-track solutions for the same problem?

Brian - that's actually a guideline, anyway (not a rule).

Sam- very uncomfortable about framework/architecture documents that are critical to understanding but published as IETF Informational documents - these documents just don't get the review that standards-track documents do. Frameworks that aren't normative references are fine at Informational.

Dan - is this saying you can write protocols based on bits without understanding requirements?

Sam - maybe we need a new document classifiication, but am sure I don't like WG INFO documents that weren't last called being normative references.

Brian - this is not a new idea.

Sam - but it's an unreasonable use of DOWNREF

Ted - we've cycled on this maybe half a dozen times, because you're talking about document that can't be advanced to DRAFT, so people say you shouldn't publish at PS, either. Sam's suggestion "Must Last Call INFORMATIONAL documents that will be normative references (e.g. architecture and framework docs)" may be good, but we can't do this ex post facto. Unless people include entire previously-published-as-INFO document as an appendix, there's no way to "Last Call" a document that's already been published.

Sam- Not what I'm saying - I'm saying this is not a reasonable downref.

Ted - but we need to get community agreement on how to handle this, and we haven't done that in the six tries I remember.

Magnus - Move requirements doc to informative, and keep the other two references at normative and do a new IETF last call.

Brian - should ask WG if these are really normative references.

Cullen - they are

Brian - very likely, but we still need to ask WG, it's their question to answer

Sam - I'll hold this DISCUSS because I feel stronger than Magnus

David - but in this case, the sponsoring AD should hold the DISCUSS because this was an oversight.

Brian - and we should talk about this in San Diego.

 o draft-ietf-pmtud-method-10.txt
   Packetization Layer Path MTU Discovery (Proposed Standard) - 7 of 10
   Note: PROTO Document Shepherd: Matt Zekauskas (matt@internet2.edu)
   Token: Lars Eggert

Do we need to DISCUSS?

Lars just saw David's DISCUSS, need to prepare.

David - do other ADs agree with my DISCUSS? It's pretty strong.

Brian - it's too long to understand.

David - I was trying to add context. Perhaps I failed.

Brian - did WG consider these issues?

David - this draft penalizes people with normal MTU sizes in favor of people with pathological MTUs - not good for routers or for Internet.

Brian - these authors are also from a very specialized corner of the Internet. WG needs to absorb this DISCUSS.

David - do other ADs have opinions?

Sam - I understand your concern, but this draft is a clear improvement and I don't see another solution.

David - OPS has suggestion to start probes at much larger value - 1500 bytes is most common case.

"1500 bytes, unless you have information about the local link" - but we don't have time to DISCUSS this further on this call.

Lars will follow up with WG chairs.

 o draft-ietf-mpls-over-l2tpv3-01.txt
   Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 (Proposed Standard) - 8 of 10
   Token: Ross Callon

Two DISCUSSes - do we need to DISCUSS?

Ross - authors need to address Gen-ART issues, but e-mail is still flying around on the other DISCUSS

Sam - most of the e-mail is talking about the need for the text, not the text itself - most of the discussion is not required to resolve DISCUSS ballot

Brian - Ted Seely says no reason to add text, but no reason not to.

Dave Meyer - Ted seemed OK about this when he and I talked this morning.

Sam - when we change ADs, we change pet peeves. Yours are different from Allison's. They are valid, they are just a surprise to the working group.

Revised ID needed...

 o draft-ietf-avt-compact-bundled-evrc-11.txt
   Enhancements to RTP Payload Formats for EVRC Family Codecs (Proposed Standard) - 9 of 10
   Note: Colin Perkins is PROTO Shepherd
   Token: Cullen Jennings

No DISCUSSes - approved with no discussion on this call.

 o draft-ietf-tls-psk-null-03.txt
   Pre-Shared Key Cipher Suites with NULL Encryption for Transport Layer Security (TLS) (Proposed Standard) - 10 of 10
   Note: PROTO Shepherd is Eric Rescorla < ekr@networkresonance.com>
   Token: Russ Housley

No DISCUSSes - approved with no discussion on this call.

2.1.2 Returning Item
 o draft-ietf-ipfix-protocol-23.txt
   Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information (Proposed Standard) - 1 of 1
   Token: Dan Romascanu

Russ declined to state a position.

Two DISCUSSes.

Dan - this is same issue as MIDCOM MIB - normative downref to informational architecture document.

Sam - could move to Informative reference, could implement this one without architecture document.

Cullen - I talked to the authors at the last IETF and they agreed that to implement SCTP-PR over DTLS, you need a document that defined more than just what's in DTLS. There is a draft that covers this, draft-tuexen-dtls-for-sctp-01, but it is still a draft.  I'm not sure they agree that meant it should be a normative reference or in fact referenced at all.

Dan - waiting from response from authors and chairs to the new version of Cullen's DISCUSS, may have another session at this IETF.

2.2 Individual Submissions
2.2.1 New Item
 o draft-orly-atommib-rfc3895bis-01.txt
   Definitions of Managed Objects for the DS1, J1, E1, DS2 and E2 Interface Types (Proposed Standard) - 1 of 2
   Token: Dan Romascanu

No DISCUSSes - document was approved with no discussion.

 o draft-legg-ldap-gser-ei-02.txt
   Encoding Instructions for the Generic String Encoding Rules (GSER) (Proposed Standard) - 2 of 2
   Token: Ted Hardie

No DISCUSSes - document was approved with no discussion.

2.2.2 Returning Item
 o draft-rja-ripv2-auth-06.txt
   RIPv2 Cryptographic Authentication (Proposed Standard) - 1 of 1
   Note: Back on the agenda to see if the latest update includes all of the points in the security considerations to clear Sam's DISCUSS position.
   Token: Russ Housley

Russ - this DISCUSS needs to go back to the working group.

Brian - did the concerns come out during last call? Why did we pick out these particular points to DISCUSS?

Sam - can't believe OPS community would buy this text.

Brian - but no last call comments about it?

Sam - trying to discuss as consensus issue, instead of a "you must be kidding" issue. If people respond "this is what we meant", that will be a surprise to me.

Russ - author is on travel this week.

2.2.3 For Action
 o draft-williams-on-channel-binding-00.txt
   On the Use of Channel Bindings to Secure Channels (Proposed Standard) - 1 of 1
   Token: Brian Carpenter

Was assigned last night, was not discussed on this call.

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-v6ops-icmpv6-filtering-recs-02.txt
   Recommendations for Filtering ICMPv6 Messages in Firewalls (Informational) - 1 of 3
   Note: PROTO shepherd: Fred Baker. . This document is a late addition to the
   agenda.. Feel free to defer if you need more time for review.
   Token: David Kessens

Two DISCUSSes - need to discuss?

David - didn't see mail last night. Is Jari's DISCUSS simple?

Jari - think so, and Sam's is related - what to do with unallocated numbers? Obvious policy is "anything you don't know, drop it" from operators, but there are two equally plausible strategies. Magnus also asked - are we talking about operator firewalls or customer firewalls?

David - just need to so some more reading.

Sam - think security overview document used similar approach successfully.

David - will look at this based on Sam's suggestion. "Revised ID Needed."

Jari - what is intention about updating reference/blocking document in RFC Editor note?

Brian - two bis drafts have been around forever, wouldn't advise blocking and waiting on them to be published.

 o draft-ietf-ltans-reqs-09.txt
   Long-Term Archive Service Requirements (Informational) - 2 of 3
   Note: PROTO Shepherd is Tobias Gondrom <tgondrom@opentext.com>
   Token: Russ Housley

One DISCUSS - Russ thanked Ted for his DISCUSS and is working with WG.

Russ will also make sure WG looks at Elwyn's comments.

 o draft-ietf-pki4ipsec-mgmt-profile-rqts-06.txt
   Requirements for an IPsec Certificate Management Profile (Informational) - 3 of 3
   Token: Russ Housley

Russ want Jari's Appendix E comment to be addressed - Approved, point raised, writeup needed.

3.1.2 Returning Item
 o draft-ietf-ipfix-architecture-12.txt
   Architecture for IP Flow Information Export (Informational) - 1 of 1
   Token: Dan Romascanu

One DISCUSS - Dan will go back to the working group and get their answer.

Russ's DISCUSS is on text that wasn't modified?

Russ - wasn't on telechat where this was discussed previously, will clear if I'm blocking inappropriately

Dan - no, protocol doc is blocked, too, no problem.

Brian - for new ADs, remember, bad manners to DISCUSS text when you review unchanged text for the second time - usually, you should have caught this the first time. Russ wasn't on first-review telechat for this document, so no criticism. Just guidance for new ADs.

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 Two-document ballot:  - 1 of 2
    - draft-martini-l2circuit-encap-mpls-12.txt
      Encapsulation Methods for Transport of Layer 2 Frames Over MPLS Networks (Historic)
    - draft-martini-l2circuit-trans-mpls-19.txt
      Transport of Layer 2 Frames Over MPLS (Historic)
   Token: Mark Townsley

Brian - we got dinged for publishing media types as Historic because they were being used. Will people involved find this perjorative?

Mark - certainly are implementations, but consensus in the community is to move to standard solution.

Brian - but do you need to make a stronger statement than Informational? The boilerplate for Informational is "not a standard of any kind"

Mark - not entirely clear when we should use Historic

Sam - IETF feedback on media types experience was asking to explain what the rationale actually is.

Mark - there was text about this in my last call.

Jari - document says "don't do this if you're implementing now"

Sam - then we're met the request for this draft.

Jari - would be good to say the same thing in the abstract - abstract is distributed more widely than the rest of the document

Mark - fine, only pushing back on changes that alter the protocol.

Approved, with an RFC Editor note for the abstract.

 o draft-goodwin-iso-urn-00.txt
   A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) (Informational) - 2 of 2
   Token: Ted Hardie

Can fix both DISCUSSes with RFC Editor notes, thanks for clear DISCUSSes.

Ted will discuss COMMENTs with authors.

3.2.2 Returning Item
 o draft-fenner-obsolete-1264-03.txt
   RFC 1264 is Obsolete (Informational) - 1 of 1
   Token: Ross Callon

No DISCUSSes - document was approved with no discussions.

Brian - you get the prize for the most "yes" votes on a document ... do we abolish 1264 immediately, or when this is published as in RFC?

Bill - this was the right thing to do, so we'll abolish 1264 immediately, and will forward this notification to RTG area when it comes out (next week).

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

Ted - where we are is still not a good place, it's better with Harald/Vidya text, but still not good. If we approve this, should be noting at least one IESG objection.

Russ - they are willing to add this text, in order to get the working group.

Ted - I'll ABSTAIN, so I won't block this action.

Sam - did you see Bernard's comments? I wish they had come much earlier - about how this is inappropriate for mobile devices, and mobile devices won't know what network they are connecting to...

Ted ...  so you can be providing posture assessments to an attacker that now knows what you are vulnerable. This makes sense in very limited environments, but if you're out in the world, you're very vulnerable. I'm only abstaining because the work is going to be done somewhere, and will be more likely to end up in inappropriate parts of the network.

Brian - the question is whether this is going to be done worse somewhere else

Ted - is group unwilling to charter for the security analysis first? Thought they were unwilling

Russ - I don't think I ever said this

Ted - that would be nice, but it's a delaying tactic at best

Russ - yes, and if work is done elsewhere while WG is working on securiity analysis, we'll be in the same place.

Sam - our mission statement is pretty clear that we aren't responsible for the entire Internet. Need to not worry about work being done worse somewhere else.

Brian - agree with you, but am concerned about press articicles about how the IETF is refusing to fix security problems

Cullen - is there no way to fix the security problems?

Ted - EKR is right. If you don't deal with lying endpoints, we end up with people trusting based on pixie dust and still not knowing what network they connect to.

Sam - AD made it very clear to the WG that they had to listen to the community.

Ted - but you can't tell the chairs that we're going to keep adding hoops for them to leap through.

Sam - is security analyisis at the front of their charter? If it is, I trust the chairs, and the AD (mumble NomCom). Just rip out the milestones until AD adds them back.

Cullen - could even have a list of "milesones to be added".

Sam - wouldn't object either way, but would be happier that way.

Russ - two items, enterprise limitation and narrowed milestones. Is that all I need to do for the announcement?

Ted - enterprise limitation is very important, and we're going to be creating a technology that is useful sometimes and dangerous other times.

Sam - question is, do we want WG to consider design features that make this easier to deploy? We have no control over how people deploy things.

Russ - I'm happy to make both changes. There has been significant discussion on enterprise limitaion, and milestone modifications are just how IESG is choosing to run the work.

Brian - anyone want to be listed as ABSTAIN?

Ted - I'd like to be listed as an ABSTAIN ... an active ABSTAIN.

WG creation approved pending edits to charter from Russ.

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

No objection on the call, creation is approved.

Russ - will send the chairs to the IESG list after the call.

Sam - this is stunning - we approved with no discussion.

Russ - the discussion will be when we post the charter with the chairs...

(discussion of selected chairs here was not minuted)

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
 o Internet Emergency Preparedness (ieprep) - 1 of 1
   Token: Jon Peterson

Sam - please send this out for external review so I can ask people to kill it - should be no surprise to anyone.

Jon - IEPREP started rechartering to work on requirements in their requirements documents, but people were concerned that scope was too big and let WG make bad decisions with no supervision. Resulting changes to charter are from negotiations with Sam. Charter is typical for RAI, showing initial submission, plus approvals, plus ... not doing protocol development as such, they can identify mechanisms without specifying them.

Brian - what does mechanism draft actually do?

Jon - it's structured as a BCP, and it's very likely this will follow the MLPP-that-works approach that was used successfully.

Brian - this is very close to operational stuff - not a criticism, just an observation.

Jon - look forward to this debate and have my own reservation, but we're in a difficult position based on the way we've treated these guys historically, with concerns about whether the work should be done under our watchful eye or sent off to some other SDO.

Ross - this is the "teenaged daughter" problem, any parent knows about that. The problem is clueless people who don't understand IP can do more damage in another forum.

Sam - but this is closer to architecture than protocol work, and we're not necessarily the best place to do architecture work. Maybe this is an opportunity for us to build bridges with ITU.

Cullen - all the participants in this work could make the work happen at ITU, if that was the right answer.

Ted - concern was that ITU work might not use the IETF building blocks...

Brian - ... or might use them inappropriately.

Dan - are they meeting in San Diego?

Jon - unlikely

Brian - but they will start to meet. This is going for wider review, and you'll see lively discussion.

Jon - that's fine. Anyone with strong views should express them.

Magnus - forward RSVP requirements to TSVWG?

Jon - does charter name TSVWG now?

Magnus - no, just a generic statement

Lars - concerned that IEPREP might think they have token for RSVP.

Jon - these guys aren't chartered to do anything on RSVP, of course.

Magnus - existing text says "provide protocol requirements to appropriate WG" - that's fine.

Brian - "good enough" to go for comments - going out for IETF review, with Jon's newest text (from today).

4.2.2 Proposed for Approval
 o Host Identity Protocol (hip) - 1 of 1
   Token: Mark Townsley

Cullen - what changed?

Mark - NAT traversal and HIP API

Brian - and formatting error in box that's not a box anymore

Mark - did change "working with legacy NATs" text from previous versions to avoid IRTF-land.

Will mark a bunch of milestones "DONE" and send recharter announcement.

5. IAB News We can use, from Dave Meyer

IAB has been mulling over architectural statement involving anycast, and preparing for IETF meeting (arranging for BOF coverage, etc.)

Reviewed IAOC RFC Editor proposal and provided input.

Continuing to discuss the current JFC Morfin appeal, and the Todd Glassey complaint re. ietf mailing list suspension.

Trying to get Routing and Addressing Workshop minutes out, planning to summarize at joint meeting in San Diego. One of the key takeaways from the workshop was a desire to put serious effort into ID/locator split, architecturally.

Related work in V6OPS on Multihoming, Fred Baker has asked for input here.

Leslie - joint lunch in San Diego, Brian's proposed agenda was just about disjoint  with Phil's, Leslie will send Brian a note about Phil's agenda and Leslie and Brian will coordinate.

Dave Meyer - could IESG name a counterpart for coordination?

Ross - thought workshop was very effective. Can coordinate with IAB.

Jari - can also help, whatever people think.

Brian - just need to work on getting the points across to people who weren't at the workshop.

6. Management Issue

None discussed on this call.

7. Agenda Working Group News

Jari Arkko - two WGs in my area are duelling (NETLMM and MIP6). NETLMM is a completely new protocol, some people saying we should use Mobile IPv6 in "proxy mode". NETLMM rough consensus was to go ahead with what they had, but they  are looking at the objections to understand them better. This will delay moving ahead with protocol for some time, but it makes no sense to delay for months -- otherwise the decision will effectively be taken by others outside the IETF.

Brian Carpenter - RFC 4748 requires a small change to IPR boilerplate, have to tell community to change boilerplate, fix XML2RFC, etc. during ID submission blackout

Lars Eggert - we just approved the last rddp document, they will consequently close soon. the ips documents are on their way, too, so the storage area in tsv
will be shrinking soon. also, bellovin has written a motivation for a tcp-md5 replacement that he'll present at tcpm, in case people want to attend (there was iesg interest in this earlier)

Sam Hartman - concerned about lack of discussion on SPKM, doesn't look like people want to solve an important problem for NFS. Otherwise, lots of work going on, and if people responded to AD comments, I'd have more documents on the telechat agendas...

Russ Housley - very close to closing PKI4IPSEC group

Dan Romascanu - closing RMONMIB, announcing today (successfully, celebrate in San Diego) Network Management Research Group last week plus follow-on discussion about next steps. Working on minutes, will forward when available.

Mark Townsley - Two working groups [L2VPN and L1VPN?] stepping on each other's charters about how we set up LSPs, will meet in San Diego to resolve. ANCP also has issues to work in San Diego.

8. ANYTHING ELSE?

* Cullen - where are we on agenda changes? Changes are happening, but were still happening Tuesday/Wednesday.

* Brian - need to have discussion with Marcia on procedures in San Diego.