IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2008-05-22.
Narrative scribe: Spencer Dawkins
- John Leslie, Russ Housley
- Roll Call
- Bash the Agenda
- Approval of the Minutes of the past telechat
- May 8 minutes--- approved with no discussion
- May 8 narrative minutes--- were approved based on changes
posted into jabber room.
- Review of Action Items from last Telechat
- Cullen to draft IESG statement on errata - Russ says: done
because we've sent the draft out for comments, figuring out what the
comments mean is a retreat topic (which Cullen will lead).
2 Protocol Actions
2.1 WG submission
2.1.1 - New Items
- TCP Friendly Rate Control (TFRC): Protocol Specification
Token: Lars Eggert Note: Document shepherd: Gorry Fairhurst (firstname.lastname@example.org).
- Russ Housley: Discuss [2008-05-21]: should be summary of the
changes since RFC 3448
- Tim Polk: Comment [2008-05-22]: I support Russ's discuss on
the importance of a change summary.
- Lars - what do you want in example?
- Tim - hoping for security considerations of what we've
learned - text hasn't changed at all. Appropriate to update? Did anyone
think about this (because the security considerations were fine in RFC
3448)? Comfortable with this if you're comfortable.
- Lars - I'm comfortable - document should be approved.
- Multiple Signatures in S/MIME (Proposed Standard)
Token: Tim Polk
- Jari Arkko: Comment [2008-05-22]: Consider writing this as
"If either SignerInfo object is missing, the relaying party ..."
- Pasi Eronen: Comment [2008-05-22]: I'd suggest doing some
editorial work especially in Section 3, 4.6, 5.
wouldn't hurt to say how the OIDs have been assigned
- Dan Romascanu: Comment [2008-05-19]: Discussion section
Table of Contents needs to be removed.
- Document was approved with no discussion.
- Tim - want to make sure Pasi and Jari comments are addressed
- approved waiting for writeup, and I'll send text.
- MPLS Multicast Encapsulations (Proposed Standard)
Token: Ross Callon
- Lisa Dusseault: Comment [2008-05-06]: Both codepoints can
now carry both types of traffic.
- Pasi Eronen: Comment [2008-05-22]: upstream-label and
multicast-encaps drafts are very difficult to understand without each
- Russ Housley: Comment [2008-05-06]: Vijay Gurbani concerns
have not been addressed.
- Dan Romascanu: Discuss [2008-05-21]: incompatible changes on
the wire including usage of semantics of Ethernet codepoints values
without obsoleting RFC3032 and RFC4023?
- Ross - document says "updates" - think this is the right
approach because it doesn't replace the entire previous documents.
- Dan - change that bothers me is protocol on the wire. This
is breaking a precedent, would have two different RFCs that say
different things about the same codepoint on the wire. Haven't seen us
do this before, would like to avoid going there. Author/working group
chair explanations were not convincing to me - may be true but
conflicting codepoints as "update" seems too much.
- Ross - document doesn't copy what's in the other document.
Do we have to copy over the rest of the text? "Obsoletes one section of
a previous document"?
- Russ - you can say "updates by replacing these sections".
- Loa - changes the previous document on how codepoints are
handled, and that's what it says.
- Dan - wanted to discuss, will not stand in the way of
approval, but would like change pointed out in Introduction section,
with specific sections, etc. on codepoints issue.
- Ross - abstract is one sentence - add "more precisely, this
document replaces specific sections of those two documents"?
- Dan - yes, would like to see in Introduction as well.
- Loa - first sections actually says "replaces text on these
codepoints" - think text is already there.
- Dan - won't stand in the way. This also applies to Eastlake
document on Ethernet code points being used in IETF documents, need to
make a mention there as well. I'll clear my DISCUSS, but not completely
convinced this is the right way to make the change.
- Ross - need to check Lisa's wording anyway, will follow up.
Can also look at Russ's comments?
- Russ - my comment's not blocking, do the right thing.
- Ross - so approved, point raised, writeup needed.
- Specification for the Derivation of Root Keys from an Extended
Master Session Key (EMSK) (Proposed Standard)
Token: Tim Polk Note:
proto shepherd is Charles Clancy
- Jari Arkko: Discuss [2008-05-08]:
separate default KDF would lead to severe interoperability
do not believe it is correct for this document to make statement about
the free use of the MSK
would much rather see a limited number of experimental labels created,
and have RFC Required IANA rule for any other usage
applicability note needs expansion
- Tim - start with Jari's DISCUSS - authors are amenable. Have
you thought about contributed text?
- Jari - yes, but have been very busy (not even able to respond
- Tim - I like that plan. Authors also make me think we'll be
able to take care of your issues.
- Jari - think e-mail from authors is all good, but haven't
had time to pay much attention.
- Tim - Ross - you're correct about not applicable for
multicast services. Incorporate into applicability statement or make a
- Ross - either way is fine.
- Jari - Isn't multicast a subcase of applicability statement?
- Tim - I think so - add to same section? so people won't miss
- Ross - perfectly sensible (just didn't see the section).
- Tim - needed to be clearer anyway. Will ask Jari and
Pasi to make first pass, then bring you in.
- Tim - Pasi probably right about draft-18
- Pasi - need reference to EAP session ID to implement this.
- Tim - agree. Clearly revised ID needed.
- Path Computation Element (PCE) Communication Protocol (PCEP)
Token: Ross Callon
- Lars Eggert: Discuss [2008-05-20]: suggestions on improving
the keepalive mechanism
Why is a system port (0-1023) required?
issues with the continued use of TCP-MD5
Comment [2008-05-20]: suggested changes to 12 sections
- Pasi Eronen: Discuss [2008-05-22]:
it was concluded that BCP107 applies. This is not reflected in the
There is no mandatory-to-implement security mechanism
using TCP-MD5 for a *new* protocol would seem to require a particularly
Comment [2008-05-22]: numbering of bits is inconsistent
- Russ Housley: Discuss [2008-05-21]: IANA is waiting for the
confirm that they have identified the actions correctly, and clarify
whether specific values are reserved
- Chris Newman: Discuss [2008-05-22]: Please provide a
reference that defines the formal language
- Tim Polk: Discuss [2008-05-21]: Olafur Godmundson's comment
on ietf discuss has not been answered
Discuss discuss: I would like to understand the migration strategy for
introduction of new features
Comment [2008-05-21]: I support Lars discuss with respect to preference
of draft-ietf-tcpm-tcp-auth-opt over TCP MD5.
text suggestions for 7.4.1, 7.5, 4.2.1
- Magnus Westerlund: Discuss [2008-05-22]:
how to trigger a protocol error condition
how messages must be processed in relation to each other.
how to increment SID
- Ross - too many DISCUSSes to resolve today. Need to go back
to authors. Revised ID needed.
- Pasi - mine was pretty big. Thought consensus that manual
key management isn't going to fly for this one, but didn't participate
in previous discussions (these were Sam's discusses).
- Ross - don't think multicast is needed for automated key
- Pasi - having a hard time with manual key management for a
new protocol. Discovery procedure won't go well if you have manual
- Ross - but will probably configure same key on all routers
and PCE server.
- Pasi - but specification says may have a large number of PCEs
- not just primary and backup.
- Ross - so you're suggesting automated key management for
- Pasi - for TCP-MD5, even if you configure for every router,
you have to configure for every IP address. We have a BCP that says not
OK to use TCP-MD5 even if we are using it on BGP.
- Ross - previous version has been deployed. Work to fix
TCP-MD5 is already in progress but document won't be out for a while.
What do you suggest we say instead?
- Pasi - Sam suggested reasonable solution but required change
to discovery procedures (would also discover security capabilities -
public keys, names, etc.)
- Ross - don't understand what's wrong with updated TCP-MD5.
- Pasi - have to know which peers are using TCP-MD5 and which
- Ross - but people are going to configure same key for entire
- Pasi - but you have to configure IP address for every router
you're going to use this with.
- Russ - true for TCP-MD5, not for TCP-AO
- Ross - will be revised ID needed, and will discuss at retreat
- LDP extension for Inter-Area LSP (Proposed Standard)
Token: Ross Callon
- Lars Eggert: Comment [2008-05-08]: [empty]
- Pasi Eronen: Comment [2008-05-08]: nits From Shawn Emery's
- Tim Polk: Comment [2008-05-07]: note by Shawn Emery
- Dan Romascanu: Comment [2008-05-21]: suggest that
appropriate wording about future work on [need to add new management
objects] is added to Section 5.
- David Ward: Discuss [2008-05-05]:
draft doesn't solve the problem it set out to solve
clear drawback is the change to BGP NH validation
DISCUSS DISCUSS: recommend we convene a discussion of MPLS savvy folks
and work through the possible solutions
- Ross - clear that I need to go offline with Dave - want to
have Mark involved?
- Mark - yes, please.
- Loa - me also.
- Russ - AD followup
- A Backward Recursive PCE-based Computation (BRPC) Procedure To
Compute Shortest Constrained Inter-domain Traffic Engineering Label
Switched Paths (Proposed Standard)
Token: Ross Callon
- Lars Eggert: Comment [2008-05-20]: Ballot Writeup in the
tracker shouldn't contain the PROTO write-up
- Approved with no discussion of the document.
- Russ - I have an objection to the writeup... just delete
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
- Internet Message Format (Draft Standard)
Token: Lisa Dusseault
- Cullen Jennings: Discuss [2008-05-21]: where is the interop
- Lisa - interop report - isn't one. Protocol has already gone
to full standard without one.
- Cullen - but 2822 is back to being proposed standard.
- Lisa - not sure it was the right decision, but went back to
draft when 2821 went to draft.
- Magnus - maybe you get interoperability, but that's not
- Russ - what features got added?
- Chris - no major features added - adding syntax, new ABNF
format, but this is almost all tightening.
- Russ - the fact that features are being removed, not added,
is what convinced me to clear my DISCUSS position.
- Cullen - if argument is "we only have less things"...
- Chris - wanted to vet documents instead of cycling at full
standard. People are using the documents now. Cycling at proposed was
right decision, but we shouldn't set a lot of hoops for advancement.
- Cullen - let me look at changes from 822 and do the right
thing. Difference between me and Lisa - main features vs all features?
- Lisa - no, I also think it needs to be all features are
- Cullen - just need to look at the deltas. I misunderstood
Lisa's position from her e-mail.
- Lisa - other discuss is Magnus - technical issue on ABNF -
did Magnus hear from Tony or Pete? Can follow up on this offline.
Please put into AD followup.
2.2.2 Returning Items
3 Document Actions
3.1 WG Submissions
3.1.1 New Items
- IPv6 Unicast Address Assignment Considerations (Informational)
Token: Ron Bonica
- Jari Arkko: Discuss [2008-05-22]: two small corrections
Comment [2008-05-22]: multihoming references don't seem adequate.
- Lisa Dusseault: Comment [2008-05-06]: a bunch of nits, I
liked the doc itself
- Pasi Eronen: Discuss [2008-05-22]: having trouble
understanding why Sections 3.1 and 3.3 exist.
Section 6 should say that using subnet prefixes other than /64 breaks
- Russ Housley: Discuss [2008-05-06]: changes were agreed
based on SecDir Review. No updated version since that discussion.
- Tim Polk: Comment [2008-05-07]: useful suggestions in GenArt
Review; all changes proposed appear well founded
- Dan Romascanu: Discuss [2008-05-21]: WG summary needs some
Comment [2008-05-21]: 3 wording changes
- Mark Townsley: Discuss [2008-05-15]: another possible reason
for choosing a subnet prefix...
- Ron - DISCUSSes are understandable - revised ID needed.
- Dan - my DISCUSS is about the writeup - please revise that,
3.1.2 Returning Items
3.2 Individual Submissions via AD
3.2.1 New Items
- SAVA Testbed and Experiences to Date (Experimental)
Token: Jari Arkko
- Jari Arkko: Discuss [2008-05-22]: to ensure that Pekka
Savola's comments are addressed.
- Lars Eggert: Comment [2008-05-20]: hoped to see some hard
- Russ Housley: Comment [2008-05-19]: Please remove references
from the abstract
Section 1: s/accomplishedaccurately/accomplished accurately/
Section 5.2 details needed about key management and the cryptographic
algorithm are needed for that work to go forward. Perhaps that is left
to a future document.
- Dan Romascanu: Comment [2008-05-21]: suggest a change in the
title of the document; something like 'A SAVA Testbed and Deployment
- Jari - Pekka Savola was unhappy about responses to his Last
Call comments, want to make sure they are addressed.
- Dan - think my suggested title change will be helpful.
- Jari - your comment and Russ's comment will be dealt with.
- Jari - will go to AD followup.
3.2.2 Returning Items
3.3 Independent Submissions via RFC Editor
3.3.1 New Items
3.3.2 Returning Items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
- Source Address Validation Improvements (savi)
- Mark - did Jari see my last e-mail?
- Jari - Mark suggesting wise to expand scope into networks
like DSL, better to do this work in IETF than DSL Forum.
- Mark - if you base SAVI on IPv4 source guard work, IPv6
definitions include same mechanisms. DSL Forum doesn't have IPv6
expertise to do that work, would be nice if SAVI did it. DSL Forum was
fine with SAVI doing that. Some discussion about what DSLAM and BRAS
have to do, but there was a sigh of relief when I said IETF would be
working on them.
- Jari - also intertwined with how DSL Forum designs their
- Mark - access network might be a LAN (depending on how you
define "access network").
- Jari - text in charter does acknowledge this as possible.
Think it's good for SAVI to start with LAN model (without DSL
- Mark - would be OK with me. If you can bring into scope
without derailing everything, you'll have enough contributors.
- Jari - sequencing the work so it won't be derailed.
- Ross - is this more complex?
- Mark - agree that principles of a LAN are well understood,
but principles of access network with upstream/downstream are trickier.
- Jari - fine with adding this and making sure people aren't
confused about the basic stuff.
- Russ - suggest approved, point raised, writeup needed.
- Jari - agree, and I also need chairs. I have one strong
- Russ - can charter with just one chair.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
- EAP Method Update (emu)
- Pasi - got e-mail, seems kind of editorial, should be simple
to change and we're' going for external review.
- Jari - was difficult to understand
- Pasi - wording was mostly from previous charter
- Russ - which was hard fought...
- Jari - especially about channel bindings.
- Russ - suggest approved point raised, writeup needed?
- approved for
external review pending Pasi's edits dealing with Jari's concerns.
4.2.2 Proposed for Approval
- RADIUS EXTensions (radext)
- Approved with no discussion on the call.
- Dan - one word I need to take out (suggested by Magnus) -
will send updated version with one less word, in a few minutes.
- Mobility EXTensions for IPv6 (mext)
- Approved with no discussion on the call - with no edits.
5. IAB News We can use
- we started to plan the IETF week
IAB plenary on Wednesday
we plan to let the architecture discussion from the IAB¨retreat have an
impact on IAB agenda.
- Suggested topics for plenary: UTC: User Traffic
SIDR: Secure Intra Domain Routing
P2P: Decentralized Architecture
PF: (Personal) Firewalls: cost an benefits
IP: Evolution of IP
- review of the IRTF anti-spam research group -
- Bert Wijnen resigns as liaison to the IETF liaison
to the IEEE802.1, we have started the process to appoint a new liaison.
We have a candidate ...
6. Management Issues
- Request to approve an additional port numbers experts (Michelle
- Michelle - we have three names, Allison Mankin has agreed,
we just need IESG approval. (Allison is looking for one more person as
- Approved on the call.
- Lars - has time delay for port registration requests gone up?
- Michelle - yes, these three people will be getting us back to
normal processing time.
7. Agenda Working Group News
- Jari Arkko (Internet)--- Multicast Mobility guys will send in a
request for BOF.
- Ron Bonica (O & M)---
- Ross Callon (Routing)---
- Lisa Dusseault (Applications)---
- Lars Eggert (Transport)---PCN sent mail to SG11 on their
interest in using PCN in RACF architecture - mostly a formality. IPPM
reaching end of charter, proposing work that's pretty different from
current charter, so making them have a BOF on rechartering to get more
attention in the room.
- Pasi Eronen (Security)---
- Russ Housley (General)---
- Cullen Jennings (RAI)--- GeoPriv looking at lots of potential
working group documents in their workshop.
- Chris Newman (Applications)---
- Jon Peterson (RAI)--- beating people up for lunch money at the
- Tim Polk (Security)---
- Dan Romascanu (O & M)---
- Mark Townsley (Internet)--- new DNSEXT chair (Andrew Sullivan)
and they will have an interim meeting
- Dave Ward (Routing)---
- Magnus Westerlund (Transport)--- new working group chair in NSIS