INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the December 1, 2005 IESG Teleconference
This agenda was generated at 17:59:34 EDT, November 30, 2005
ATTENDEES
---------------------------------
Brian Carpenter / IBM
Michelle Cotton / ICANN (IANA)
Leslie Daigle / IAB
Marshall Eubanks / MultiCast
Bill Fenner / AT&T
Ted Hardie / Qualcomm, Inc.
Sam Hartman / MIT
Scott Hollenbeck / Verisign
Russ Housley / Vigil Security, LLC
David Kessens / Nokia
Allison Mankin / Shinkuro, Inc.
Dave Meyer / Cisco/University of Oregon (IAB Liaison)
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / RFC Editor
Dinara Suleymanova / IETF Secretariat
Mark Townsley / Cisco
Amy Vezza / IETF Secretariat
Margaret Wasserman / ThingMagic
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
---------------------------------
Barbara Fuller / IETF Secretariat
Ray Pelletier / IASA
Barbara Roseman / ICANN (IANA)
Nicholas Staff / IndyMac Bank
1. Administrivia
1.1 Roll Call
1.2 Bash the Agenda
1.3 Approval of the Minutes
1.4 Review of Action Items
1.5 Review of Projects
http://www.unreason.com/jfp/iesg-projects
2. Protocol Actions
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-mpls-lsp-ping-10.txt
Detecting MPLS Data Plane Failures (Proposed Standard) - 1 of 19
Note: ITU requires an RFC number by December 12th.
Token: Alex Zinin
Alex Zinin : As long as I have comments on email, we don't need to discuss this
here.
Mark Townsley had already sent his comments, Sam Hartman and Margaret Wasserman
promised to send theirs as soon as they could.
o Four-document ballot: - 2 of 19
- draft-ietf-dnsext-dhcid-rr-10.txt
A DNS RR for Encoding DHCP Information (DHCID RR) (Proposed Standard)
- draft-ietf-dhc-fqdn-option-11.txt
The DHCP Client FQDN Option (Proposed Standard)
Note: Note: 3 related DDNS documents need to be reconciled. See email to
dhcwg list on 2003-06-05.
- draft-ietf-dhc-ddns-resolution-10.txt
Resolution of FQDN Conflicts among DHCP Clients (Proposed Standard)
Note: 11/21/05: Check for last minute IETF LC comments before
telechat.
- draft-ietf-dhc-dhcpv6-fqdn-03.txt
The DHCPv6 Client FQDN Option (Proposed Standard)
Token: Margaret Wasserman
Margaret Wasserman reported that she had tried to remove this item from the
agenda as there were late last call comments.
o draft-ietf-ips-fcip-mib-09.txt
Definitions of Managed Objects for FCIP (Proposed Standard) - 3 of 19
Note: PROTO shepherd black_david@emc.com
Token: Allison Mankin
There being no objections, the document was approved with RFC Editor notes.
o draft-ietf-idr-rfc2858bis-07.txt
Multiprotocol Extensions for BGP-4 (Draft Standard) - 4 of 19
Token: Bill Fenner
Bill Fenner reported that he was holding a Discuss on this document on behalf on IANA, and
that it needed to go into AD followup.
o draft-ietf-rmonmib-rmon2-v2-05.txt
Remote Network Monitoring Management Information Base Version 2 (Draft
Standard) - 5 of 19
Token: Bert Wijnen
Allison Mankin asked if there was a normative reference regarding how MIB's are
advanced. She suggested a note saying that the IESG is following its own BCP on
how you advance MIBs.
Bert Wijnen promised to check on this before the end of the call.
o draft-ietf-mip4-dynamic-assignment-06.txt
Mobile IPv4 Dynamic Home Agent Assignment (Proposed Standard) - 6 of 19
Token: Margaret Wasserman
This document was placed into AD followup.
o draft-ietf-sigtran-rfc3332bis-05.txt
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation
Layer (M3UA) (Proposed Standard) - 7 of 19
Token: Jon Peterson
There were two discusses on this document; Jon Peterson reported that they
should be pretty simple to resolve, and requested that it be put into AD
followup.
o draft-ietf-mpls-ecmp-bcp-02.txt
Avoiding Equal Cost Multipath Treatment in MPLS Networks (BCP) - 8 of 19
Token: Alex Zinin
Alex Zinin : All the discusses are very similar. They are based on the premise
that the draft is trying to reserve IP version 0. The document is saying that
this [searching on the first nibble of the IP version field] is the behavior
the the applications have decided to do.
Margaret Wasserman: It should say that explicitly - I don't yield that we are
never going to call future versions of IP 0 or 1.
They should allocate a number.
Brian Carpenter : I think that this is a constructive thing to do.
Margaret : I think that we should reserve zero.
Alex : I think that we can just say, don't do ECMP if it is 0 or 1.
Bill Fenner : This is a behavior that we don't want to encourage in the first
place.
Brian : This is a case where the exact text matters.
Alex : This is for people who are doing a hack.
Allison : This is a brittle, pragmatic, not-future proof. It can just be a note
at the beginning.
Bill Fenner : As soon as we define IP Version 1...
Allison : Future proof means that you designed it to work in unexpected
environments.
Alex : I think that it can include a note.
Bill Fenner [from jabber] : If we make it clear that we are talking about a
deployed mechanism that we don't think is a good idea, I don't mind giving
people advice on how to avoid damage from it. I don't think that we should
write a BCP that tells people that ECMP based on the first nibble of the packet
is going to work as long as you follow a few simple rules.
The document was placed in AD Followup.
o draft-ietf-mip4-faerr-02.txt
Foreign Agent Error Extension for Mobile IPv4 (Proposed Standard) - 9 of 19
Token: Margaret Wasserman
Amy : The only discuss is yours
Margaret Wasserman reported that she was holding a Discuss for Michelle Cotton,
who promised to get back to her with details the same day.
o draft-ietf-simple-cipid-06.txt
CIPID: Contact Information in Presence Information Data Format (Proposed
Standard) - 10 of 19
Token: Ted Hardie
Ted Hardie requested that the document go into AD followup.
o draft-ietf-simple-rpid-09.txt
RPID: Rich Presence Extensions to the Presence Information Data Format
(PIDF) (Proposed Standard) - 11 of 19
Note: The proto write-up (available in tracker comment log) discusses why
this document was not combined with cipid and future, despite them being
interconnected. Rough consensus for this approach does. seem evident.
Token: Ted Hardie
There was one discuss on the document.
Ted Hardie : Hopefully, we can clear it up quickly.
This is really here because this is what IM systems out there in the wild right
now.
People need to express things in AOL and Microsoft's systems. There was
extensive WG discussion on this.
Let's take this to AD followup.
o draft-ietf-simple-future-04.txt
Timed Presence Extensions to the Presence Information Data Format (PIDF) to
Indicate Status Information for Past and Future Time Intervals (Proposed
Standard) - 12 of 19
Token: Ted Hardie
Allison Mankin and Mark Townsley complained that their positions had not been
recorded on this document.
There being no discusses once this was cleared up, Ted Hardie requested that it
be placed in approved, write-up needed status.
o draft-ietf-imss-ip-over-fibre-channel-03.txt
Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel (Proposed
Standard) - 13 of 19
Note: Requesting expedited RFC-Editor processing for this document. T11
needs an RFC-number by Jan 20th so they can reference it in their document
to be approved . in the week after Jan 20th.
Token: Bert Wijnen
Margaret Wasserman reported that this document needs expedited processing.
There being no objections, Amy Vezza requested that Bert open an expedited
handling ticket.
o draft-ietf-dhc-dhcpv6-remoteid-00.txt
DHCPv6 Relay Agent Remote ID Option (Proposed Standard) - 14 of 19
Token: Margaret Wasserman
There was extended discussion of this document.
Dave Kessens : The real question is what are we standardizing in this document.
I don't see what gets standardized - I don't see how you get any
interoperability from this.
The next document does a similar thing.
Bill Fenner : These are options already defined in DHCP v4, and these documents
are defining the same things in v6. Are we saying things are OK in v4 but not
v6 ? That's obnoxious.
Brian : The statement about globally unique may mean just within a DHCP domain.
Allison : They cut out all of the security considerations that were in the v4
version
The v4 version came out in March of 2005.
Margaret : I don't know if I like the original text, but I like having the v6
options map one to one to the v4 ones.
This document and the next one were placed in AD followup.
o draft-ietf-dhc-dhcpv6-subid-00.txt
DHCPv6 Relay Agent Subscriber-ID Option (Proposed Standard) - 15 of 19
Token: Margaret Wasserman
Margaret : Put this in AD followup.
o draft-ietf-enum-iris-ereg-02.txt
An ENUM Registry Type for the Internet Registry Information Service
(Proposed Standard) - 16 of 19
Note: Finishes Last Call on October 27. On IESG agenda, however LC
comments urged and will be heeded.
Token: Allison Mankin
Brian Carpenter said that he had a number of editorial corrections that weren't
worth a Discuss. Allison reported that they were all now included now, so the
document was approved.
o draft-ietf-isis-wg-mib-24.txt
Management Information Base for IS-IS (Proposed Standard) - 17 of 19
Token: Alex Zinin
Alex : Let's move on - AD followup.
o draft-ietf-simple-presence-data-model-06.txt
A Data Model for Presence (Proposed Standard) - 18 of 19
Note: Much of the language here reflects long discussion and compromise.Â
Please recognize that when suggesting wordsmithing changes.
Token: Ted Hardie
Amy Vezza : This was deferred.
o Two-document ballot: - 19 of 19
- draft-ietf-kitten-gssapi-prf-07.txt
A PRF API extension for the GSS-API (Proposed Standard)
Note: proto shepherd: jaltman@columbia.edu
- draft-ietf-kitten-krb5-gssapi-prf-04.txt
A PRF for the Kerberos V GSS-API Mechanism (Proposed Standard)
Token: Sam Hartman
Sam Hartman : We will have to add a textual citation to the references we have.
Amy Vezza : So this has been approved with an RFC Editor note.
2.1.2 Returning Item
o draft-ietf-mmusic-sdp-new-25.txt
SDP: Session Description Protocol (Proposed Standard) - 1 of 3
Note: Ancient returning item: no longer has enough ballot positions to
advance. Mercy for these poor souls, new reviewers!
Token: Jon Peterson
There was a discussion of the historic nature of the ability to specify cryptographic keys using the k= directive.
Jon Peterson : Russ, do you think that there isn't enough barbed wire around
this, saying not to use it ?
Russ Housley : We keep seeing documents that use it.
Jon: It says right up front that it shouldn't get used and is not recommend.
Russ : That isn't how I read it.
Jon : I am concerned that your new paragraphs might legitimize this.
Brian Carpenter : Spencer Dawkins gave this a detailed review and came up with
a number of editorial corrections.
Jon : Let's put it in AD followup.
o draft-ietf-lemonade-mms-mapping-06.txt
Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail
(Proposed Standard) - 2 of 3
Note: This is returning post-appeal processing by the WG and post
replacement IETF Last Call. If we can complete this on 12/1, it will
likely be referenced by OMA (currently the text is copied)
Token: Ted Hardie
There was a question as to whether or not the ballot had been cleared for this
document.
Apparently it had not been, so Amy Vezza asked for objections; there being
none, the document was approved.
o draft-ietf-dhc-dna-ipv4-17.txt
Detecting Network Attachment in IPv4 (DNAv4) (Proposed Standard) - 3 of 3
Note: This document has changed substantially since the IESG reviewed
version -12 based on post-LC comments. Back for a re-review before sending
to the RFC Editor.
Token: Margaret Wasserman
There were no objections stated.
2.2 Individual Submissions
2.2.1 New Item
o draft-rja-ripv2-auth-03.txt
RIPv2 Cryptographic Authentication (Proposed Standard) - 1 of 1
Token: Russ Housley
Brian Carpenter : How long has this document been in preparation ?
Russ : Draft 00 is August 2004
Brian : So it's not ancient history.
[IM] : I would like to know how many people use the keyed MD5 option with RIP.
Bill Fenner : I am familiar with oneRIP deployment, and that didn't do any
authentication.
Alex Zinin : How do people feel about the second part of my discuss.
Brian : That second comment sounds like it's worth discussing with the authors.
Dave Kessens : This is a really specific protocol that isn't used that much.
This document should have come up with a move of RIP to historic.
Russ : This goes to revised ID needed.
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-grow-bgp-med-considerations-04.txt
BGP MED Considerations (Informational) - 1 of 4
Note: Note: Dave Meyer is the protoshepherd
Token: David Kessens
David Kessens reported that this document will need an RFC Editor note as there
are a few minor comments. Brian Carpenter said that he read the document
closely and concluded that it was operational guidance, which Bill Fenner
agreed with. David Kessens concluded that the document was approved, point
raised, write-up needed.
o Two-document ballot: - 2 of 4
- draft-ietf-mpls-oam-requirements-06.txt
OAM Requirements for MPLS Networks (Informational)
Note: ITU requires an RFC number by December 12th.
- draft-ietf-mpls-oam-frmwk-03.txt
A Framework for MPLS Operations and Management (OAM) (Informational)
Token: Alex Zinin
There were 4 discusses on these documents, and some confusion as to whether or
not everyone had received the most recent revised version, 8, of the
requirements document.
Mark Townsley said that his comments were on version 8, that they were arguably
editorial, and he complained in general about the readability of the document.
Alex Zinin requested that the document go into Revised ID needed status.
o draft-ietf-mpls-p2mp-sig-requirement-03.txt
Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs
(Informational) - 3 of 4
Token: Alex Zinin
Alex Zinin requested that the document go into AD followup; Brian Carpenter
pointed out that the comments were primarily Harald Alvestrand's, and requested
that he [Brian] be copied on any email about this.
o draft-ietf-nemo-home-network-models-05.txt
NEMO Home Network models (Informational) - 4 of 4
Token: Margaret Wasserman
Bert Wijnen reported that his Discuss was a document clarity issue, and
Margaret therefor requested that the document be placed in AD followup.
3.1.2 Returning Item
o draft-ietf-dnsop-ipv6-dns-issues-12.txt
Operational Considerations and Issues with IPv6 DNS (Informational) - 1 of 1
Note: To check (for the second time) on the status of the resolution of
Thomas Narten/Margaret Wasserman's DISCUSS..
Token: David Kessens
David Kessens reported that Pekka Savola had been diligent in trying to fix the
problems with the document.
Margaret Wasserman : These all from Thomas's original discuss. The wording
about critical data has to be fixed.
David Kessens : Pekka has sent an email and didn't get any responses.
Margaret : I don't have the whole thread.
Brian Carpenter : I would advise putting Margaret on the thread.
David : So, revised ID needed.
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-krovetz-umac-07.txt
UMAC: Message Authentication Code using Universal Hashing (Informational) -
1 of 1
Token: Russ Housley
Russ requested that this document be placed into AD Followup.
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
o draft-glenn-mo-aggr-mib-07.txt
The Managed Object Aggregation MIB (Informational) - 1 of 1
Token: Bert Wijnen
Bert Wijnen reported that there was a discrepancy between an experimental MIB
module and an informational RFC. Bert said that he would prepare an RFC
Editor note about the discrepancy with advice on what to do.
Bill Fenner pointed out at this point that Aaron from the RFC Editor had asked if all Updates or Obsoletes metadata could be in the announcement message, for any document.
3.3.2 Returning Item
NONE
3.3.3 For Action
o draft-manning-opcode-discover-02.txt
DISCOVER: Supporting Multicast DNS Queries (Experimental) - 1 of 1
Note: Note: Submitted to RFC Editor, being treated as an ISR.
Token: Margaret Wasserman
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Multiprotocol Label Switching (mpls) - 1 of 1
Token: Alex Zinin
Alex Zinin reported that the new charter adds a couple of milestones; the work
is already going on and the new mechanisms are needed.
There were no objections.
4.2.2 Proposed for Approval
o Mobility for IPv4 (mip4) - 1 of 3
Token: Margaret Wasserman
Margaret Wasserman reported that there was new text which people hadn't seen,
and requested that it be moved to the agenda for the next call.
o Telephone Number Mapping (enum) - 2 of 3
Token: Allison Mankin
Allison Mankin reported that the changes are reasonably significant. They have
taken on ENUM, which was originally conceived as a service for a end user to
translate between an end user and a URI for VOIP. The service providers
realized that they could use this for routing, so the change is that the IETF
is giving them the charter to do this in a very careful way.
Brian Carpenter : Will this cause IETF ITU-T interactions ?
Allison : We have a diplomatic tie with them for ENUM.
Brian : I was thinking more technically - will we have to interact with the
operator databases ?
Allison : The people doing this understand the PSTN world - it's not clear that
the ITU has done protocols for their databases - I think that they are
proprietary.
There is a carrier wide consensus to do this properly with ENUM.
There is a lot of liaison and relationship between the SDO's on this.
The real question is ITU forging ahead on things that doesn't look anything
like DNS. Someone should figure out what they think they are doing on that
stuff.
Also, the participants may find that our publication process is too slow.
The re-chartering had no objections, and so was approved for external review.
o Softwires (softwire) - 3 of 3
Token: Mark Townsley
Mark Townsley reported that this was not a rechartering, but the actual
chartering.
Brian Carpenter reminded the IESG that when they met in Vancouver, they
approved it at the first breakfast.
There being no objections, it was approved formally.
5. IAB News We can use
Dave Meyer reported that the IAB had published draft-iab-ieee-802-rel-05.txt, and
will soon publish the idn 00 document. Also, there will probably be another
IPv6 Shim 6 Bof at the next Apricot meeting, in Perth.
Margaret Wasserman brought up the issue of load balancing in Shim6.
Margaret Wasserman : I was wondering if we should do some thing about it, or
decide that this is not a Shim6 requirement.
Dave Kessens : I think that the Shim6 WG has decided not to do this.
Margaret : I don't think that they can do that.
Dave Kessens : This is not a requirement, it's a goal
Margaret : It's a major requirement. It's about whether we have our act
together.
Leslie : I think that it's not the case that the IAB plans to come to Perth
with the same presentation as before.
Margaret : I think that we should be responsive to the previous discussion.
We have to figure out how to get the Shim6 group to address it.
Brian : I think it's an issue of communicating that they are aware of it. This
has been left out of the base protocol deliberately.
Dave Kessens : If you put too many requirements, you want make any progress.
Margaret : I think that the operators tried to tell us that without load
balancing they will not adopt it.
Dave Kessens : This solution is not for the big ISP's. It's for smaller guys.
Margaret : Then why are we going to Nanog and Apricot ?
Leslie : We are looking to collect more data.
6. Management Issue
6.1 application/xenc+xml (Scott Hollenbeck)
Scott Hollenbeck reported that this was a request from W3C to register a media
type.
There being no objections, so the request was approved.
Scott said that he would send a request to the Secretariat for a note to IANA.
6.2 Removal of OPES WG Work Items (Ted Hardie)
Ted Hardie : This is a rechartering item - they are removing the action items
that
relate to an OPES specific rules language. Other languages already do this
well, and there are solutions that are unlikely to adopt a rules language if it
were developed.
If this gets approved, the next thing is an actual rechartering - in HTTP, they
described from the beginning that they weren't going to have a rules language.
The request was approved, and Ted Hardie promised to come back with the actual
rechartering.
6.3 expedited rfc-editor process for mpls documents (Alex Zinin)
Alex Zinin : We have the 3 documents, which we haven't finished discussing.
Brian Carpenter : If those issues get resolved does anyone have any problems
with expediting this ?
Joyce Reynolds: This is cutting it very, very close to the holiday season for
the RFC Editor.
Bill Fenner : There were apparently a bunch of communications failures - we
didn't realize these documents had these deadlines until quite recently. This
is a real exception.
Joyce : Fully understood.
Dave Kessens : I have the concern that we are more and more work for other
constituencies.
Allison : Probably the entire RFC editor this month is probably expedited
documents.
Brian : Is this going to be covered in TechSpec ?
Allison : This is covered in detailed in TechSpec. I am writing a proposal for
permanent ID issuance at the time of approval and elimination of fast-tracking.
Leslie : TechSpec is moving forward.
7. Agenda Working Group News
[Each AD is questioned in turn, with the response after the "?"]
Brian ? No.
Bill ? No
Ted ? No
Sam ? You should expect a Syslog charter really soon. It will be fun. KINK
should appear next time.
Scott ? No
Russ ? You should expect the DKIM charter for the next agenda
David K ? There is a bit of an issue with the Manning draft. Margaret is the
shepherd.
As an informational it is OK, as standards track it would have issues.
Bill : I think it would be reasonable to create a path in the IETF where these
could get published.
Allison ? No
Mark ? PWE3 rechartering coming up.
Margaret ? In Vancouver we talked about shutting down DNSEXT. If you know things
it should do, speak up.
Bert ? The AAA WG has been discussing a new WG charter
(namely Diameter Maintenance and Extensions) and it will probably
show up on IESG agenda soon.
Alex : No
[Meeting ended at 2:00 PM EST]
------------------------------------------------------------------------------