INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the September 29, 2005 IESG Teleconference This agenda was generated at 17:34:7 EDT, September 28, 2005 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda There was a new management issue from Russ about rfc3664bis. [no other new business] 1.3 Approval of the Minutes 1.4 Review of Action Items 1.5 Review of Projects http://www.unreason.com/jfp/iesg-projects Jon Peterson : We don't have an update as we have no data. If we are actually going to go public with this we need to make an effort to get timely information associated with some of these projects. I do feel strongly that before we send a public announcement we should do that. Brian Carpenter : I fully support you. I think your announcement was fine. Jon : It would be good to make another deadline, maybe for a week or so from now. I think that's the last thing before we go public. Brian : I thought that the announcement looked right on the ball. If people don't send you updates, they will get the complaints. 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-l3vpn-bgp-ipv6-07.txt BGP-MPLS IP VPN extension for IPv6 VPN (Proposed Standard) - 1 of 9 Token: Mark Townsley Ted Hardie's and Scott Hollenbeck's objections could be handled with RFC editor notes. Mark and Alex Zinin had the following discussion about Implementation Reports (IR's). Alex : The original agreement with the sub-ip working group was that we apply the routing area requirements. As you know we have had quite an experience with this WG about the detail of the spec. Given that they introduce changes to routing protocols it makes sense to apply these requirements. Mark : In principle I agree with you. My only concern is how to delicately handle this. Alex : They are in the know that this is going to happen. I have been telling them that I was going to ask for implementation reports. Mark : Are you asking for IR's with certain details ? Brian : Don't you have a routing area RFC that describes this ? Alex : Yes. Mark : There is is an issue of consistency. This issue is way bigger than this document. This is a problem that I would look back at 2547bis and the language is almost exactly in line. It's beyond the author's. It's MPLS and L3VPN, multiple working groups. [It was agreed that this document needed AD followup] o draft-ietf-ipoib-dhcp-over-infiniband-10.txt DHCP over InfiniBand (Proposed Standard) - 2 of 9 Token: Margaret Wasserman Amy Vezza : I have no open issues with this document so unless there is an objection it is approved. [IESG Member] Who-hoo o draft-ietf-idr-rfc2796bis-01.txt BGP Route Reflection - An Alternative to Full Mesh IBGP (Draft Standard) - 3 of 9 Token: Bill Fenner Brian Carpenter relayed an objection from a reviewer, who noted that the security discussion points to a document from 1998 and asked if nothing had really changed in the last 7 years. Bill Fenner said that that was correct, and that there was no over-arching document that describes the base protocol. o draft-ietf-crisp-iris-areg-12.txt IRIS - An Address Registry (areg) Type for the Internet Registry Information Service (Proposed Standard) - 4 of 9 Token: Ted Hardie There was a discussion about whether this document is obvious enough to the reader. Ted Hardie reported that the Working Group feels that the target audience understands this. Sam Hartman felt that he did not believe that the spec is written well enough to review. Brian Carpenter agreed to try and get more clarity about Harald Alvestrand's objections. o draft-ietf-l3vpn-rt-constrain-02.txt Constrained VPN Route Distribution (Proposed Standard) - 5 of 9 Token: Mark Townsley Alex Zinin had objections to the RFC 2119 language, which may require a return of the document to the working group. o Two-document ballot: - 6 of 9 - draft-ietf-sipping-reason-header-for-preemption-04.txt Extending the Session Initiation Protocol Reason Header for Preemption Events (Proposed Standard) Note: Last Call comments from the AD given in the SIP meeting: the document must be generic,. not have a implied RSVP coupling.. The document has been waiting for the heavily reviewed resource-priority header doc - draft-ietf-sip-resource-priority-10.txt Communications Resource Priority for the Session Initiation Protocol (SIP) (Proposed Standard) Note: These docs were much reviewed (by Chairs, WG and me) on architecture and details, in WG.. The reason-header update submitted for publication a long time before its companion,. but waited, and then had updates for it. Token: Allison Mankin Allison Mankin reported by jabber that she would forward the comments received and that this document needs to be in A-D followup. This was revisited once she got on the call, and Ted Hardie asked if the working group and AD had thought through the corner cases enough, and these were explained. After this discussion, the two documents were approved during the teleconference. o draft-ietf-bridge-ext-v2-07.txt Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions (Proposed Standard) - 7 of 9 Note: IETF Last Call ends 23 Sept. Token: Bert Wijnen There was no objection. o draft-ietf-ldapbis-bcp64-05.txt IANA Considerations for LDAP (BCP) - 8 of 9 Token: Ted Hardie Ted Hardie reported that this document was in AD followup. o draft-ietf-rohc-rfc3242bis-01.txt RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP (Proposed Standard) - 9 of 9 Note: PROTO Shepherd: Carsten Bormann Token: Allison Mankin Allison Mankin reported that the one Discuss on this document had been cleared with a note to the RFC Editor, and the document was approved. 2.1.2 Returning Item o draft-ietf-dhc-relay-agent-ipsec-02.txt Authentication of DHCP Relay Agent Options Using IPsec (Proposed Standard) - 1 of 2 Note: Document has been updated to address discuss comments from Russ and Bert -- on agenda to see if all issues have been resolved or if any remain. Token: Margaret Wasserman Amy : There are 2 discusses. Margaret Wasserman reported that the author was now convinced that it wasn't appropriate to use IPsec for this, so the spec was going to be withdrawn. She further reported, after a question by Brian Carpenter, that no one had commented on this on the WG email list in 2 years. Russ Housley said that if a constituency was found in support of this effort, that they would find someone in security to work on this. The document was then placed in AD followup. o draft-ietf-dhc-3315id-for-v4-05.txt Node-Specific Client Identifiers for DHCPv4 (Proposed Standard) - 2 of 2 Note: On agenda to clear David's discuss and check that IANA issues are resolved; David, section 7 was added to address your concerns. If they have not been fully addressed, can you let us know what issues remain? Token: Margaret Wasserman Michelle Cotton asked what the author's did to clear the IANA issues with the document. Margaret Wasserman reported that the IANA considerations section now says none, that the IANA should do nothing. 2.2 Individual Submissions 2.2.1 New Item o draft-gray-rfc1888bis-02.txt Internet Code Point Assignments for NSAP Addresses (Proposed Standard) - 1 of 2 Token: Margaret Wasserman The question of byte alignment was raised for this document. Margaret Wasserman reported that she wrote to Eric Gray, and he had forwarded back "all sorts of reasons why the alignment has to be the way that it is." Mark Townsley said that Eric Gray had said that alignment was not that important in modern architectures. The document was put it in A-D followup. o draft-carpenter-bcp101-update-02.txt BCP101 Update for IPR Trust (BCP) - 2 of 2 Note: IETF Last Call ends today (Sep 22nd) Token: Bert Wijnen Ted Hardie had a DISCUSS that was fixed with a revision to make a normative reference to a URL that will contain the text of the Trust. Sam Hartman asked Bert if he felt that there was a community consensus in favor of this document. Brian Carpenter stated that, while it would be embarrassing if this did not get approved, it would not be a disaster, and he didn't want people to feel that there was a necessity to approve this. Sam Hartman said that the real critical point was whether it could be approved without seeing the Trust. Bert said that he felt that there was a consensus to approve, and the document was placed into A-D follow-up. 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-opes-smtp-use-cases-03.txt OPES SMTP Use Cases (Informational) - 1 of 3 Token: Ted Hardie Ted Hardie mentioned to Sam Hartman that he expected that the Working Group would say that his issues would be dealt with in a protocol document. The document was put into new I-D needed status. o draft-ietf-secsh-publickeyfile-09.txt SSH Public Key File Format (Informational) - 2 of 3 Token: Sam Hartman Ted Hardie had an objection, as there was a discussion about whether the "key blob" could include the key certificate, but the document referenced says that the public key id or the certificate would not be included in the key fingerprint. Sam Hartman agreed that the would definitely need to be changed, and the DISCUSS was transferred over to Russ Housley. o draft-iab-ieee-802-rel-01.txt The IEEE 802/IETF Relationship (Informational) - 3 of 3 Note: This is a document produced by the IAB. Document has been reviewed by IAB. IAB now solicits review and comments from IESG. Token: Bert Wijnen There were no objections to this document. There was a discussion about who would send this to the RFC Editor; as this is an IAB document, it was agreed that this should be done by Leslie Daigle. Brian Carpenter and Bert Wijnen told Leslie Daigle that she needed to go back to the IAB and say that the IESG had evaluated the document and has no objections to the IAB publishing this document as now written. 3.1.2 Returning Item NONE [brief break at this time] 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-rharrison-lburp-04.txt LDAP Bulk Update/Replication Protocol (Informational) - 1 of 4 Token: Ted Hardie There was a DISCUSS from Russ Housley and some comments from Margaret Wasserman, and the document was put into revised ID needed status. o Three-document ballot: - 2 of 4 - draft-nguyen-ospf-lls-05.txt OSPF Link-local Signaling (Experimental) - draft-nguyen-ospf-oob-resync-05.txt OSPF Out-of-band LSDB resynchronization (Informational) - draft-nguyen-ospf-restart-05.txt OSPF Restart Signaling (Informational) Token: Bill Fenner Bert Wijnen had a DISCUSS with this document concerning extensibility; he wondered if extensions were first come first serve, and whether assignments require IETF consensus. David Kessens felt that that the text is open ended and confusing, that there were vague sections and that the text needed to be strengthened. The document was placed into AD followup. o draft-maino-fcsp-02.txt Use of IKEv2 in The Fibre Channel Security Association Management Protocol (Informational) - 3 of 4 Token: Russ Housley There were no objections, so the document was approved. o draft-smith-oma-urn-00.txt A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA) (Informational) - 4 of 4 Note: Sent to the URN-NID list on August 25th Token: Ted Hardie There were no objections, so the document was approved. 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor 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 o Widget Description Exchange Service (widex) - 1 of 2 Token: Scott Hollenbeck Margaret Wasserman noted that at the end of the document, the proposed wg chair stated that it is possible that other standards cover this. She wondered if this was just a formality paragraph, or if it truly might collide with other work done somewhere else. Scott Hollenbeck stated that this was intended for small mobile devices, and that there were groups like the W3C doing a lot of the data structure work. The charter was sent for external review. o Lightweight Reachability softWires (lrw) - 2 of 2 Token: Mark Townsley There was a comment that this working group was called both Softwires and ORW. Mark Townsley said that the name had changed a number of times, leading to confusion. David Kessens had a few problems with the charter, stating that it didn't really describe what problems it is trying to solve and who needs it, and that the scope is not clear and should be more specific about IPv4 and IPv6. Mark Townsley said that the whole area suffers from too many solutions, and that there is very clear consensus that the IETF doesn't need more. He suggested that the working group be isolated in a room and required to produce a single scoped requirements document. Brian Carpenter said that he expected some feedback on the public call, and that he thought that some some tuning was needed to deal with David's comments. Mark Townsley agreed that the problem statement needed to be honed, and David Kessens said that he thought that if the scope was limited to client-server that it would be more likely to get something useful. Mark Townsley said that the choice seemed to be keeping the effort as a BOF for sufficiently long to get a good charter, or creating the Working Group, and have it stay "in BOF mode" for a comparable length of time. Mark Townsley related comments from Pekka Savola, who is very negative about the effort. Allison Mankin suggested that the Working Group needed a firm sunset clause, saying that they would be shut at the end of the year if they didn't produce. Brian Carpenter said that the document needed to be made consistent, and it was sent on for external review. 4.1.2 Proposed for Approval o Ad-Hoc Network Autoconfiguration (autoconf) - 1 of 2 Token: Margaret Wasserman There were no objections, so the document was approved. Margaret Wasserman reported that she had received three minor typographical errors from Russ and that she would send the corrected text for publication. o Mobile Nodes and Multiple Interfaces in IPv6 (monami6) - 2 of 2 Token: Margaret Wasserman Margaret Wasserman said that this was supposed to be a small, quick, working group, to do 2 small enhancements to MIPv6. Allison Mankin suggest that this could be placed in MIP6; Margaret said that she had considered that, but that she preferred an independent working group, and that a tight rein should be kept on it. After this discussion, the Working Group was approved. 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. IAB News We can use Dave Meyer reported on the IAB multihoming session happening Tuesday at the upcoming LA NANOG, and informed the IESG that they were about to turn on the Internet architecture mailing list. Leslie Daigle said that they were looking for alternative suggestions for people to take on the role of MFA liaison. Allison Mankin said that IESG and IAB may want to readdress the IAB's question the request for liaison from the WiMAX Forum. She had a discussion with some folks during a talk she gave at Motorola and heard more about the network level scope of work of WiMAX and WiMAX's active use of IETF protocols. 6. Management Issue 6.1 Appointing RFC 3961 IANA expert (Sam Hartman) Sam Hartman said that the obvious person for this was someone who reports to him, Ken Raeburn. As there was no objection, he agreed to draft a note concerning this to IANA. 6.2 Request to remove Dean Anderson posting privileges to the IETF & dnsop mail lists (David Kessens) David Kessens said that Brian Carpenter took the first initiative there, after the request from Dave Crocker under RFC 3683. Brian Carpenter said that an AD was needed to shepherd this, and noted that Dean Anderson could continue to post for 4 weeks during the last call. David Kessens was appointed to shepherd this request. 6.3 Discuss and potentially approve RAI area (Ted Hardie) Ted Hardie stated that the final text for this had been sent to the list. Allison Mankin said that the consensus was that AVT was to be included in RAI. Brian Carpenter then called for consent in the room about adding the two AD's, and David Kessens said that he continued to have objections, which he would not restate as they were well known. [The following was received from David Kessens concerning his objections : David was not against creating a new area as such, but believes that we should deal with the larger issue of an enlarged IESG before adding more new Area Directors to the IESG. David believes that the current IESG is already too large to operate efficiently. Adding an area would grow the IESG even larger, getting ever closer to the point where more time will be spend on overhead instead fulfilling the IESG's day to day responsibilities. David felt that the IESG didn't do its managerial duties by hurrying this decision and not adequately studying possible alternatives that, among other possibilities, would have no need for additional ADs or another area, or alternatives that would add the new area but would make changes in other parts of the IESG resulting in a lower net gain of IESG members. ] Brian Carpenter then called for a yes or no role call, with results as follows : Brian Yes Bill Yes Ted Yes Sam Yes Scott Yes Russ Yes David No Allison Yes Jon Yes Mark Yes Margaret Yes Bert Yes Alex Yes Brian then stated that the consensus by IETF standards was very strong, and that he absolutely felt that there is reason to proceed, and that he took this as a decision to go forward. Allison Mankin stated that the IESG needed to think about ways to manage its work better, and Brian agreed. 6.4 RAI and message to NomCom (Brian Carpenter) Brian Carpenter described the message to the NomCom that describes what the ADs need to do for RAI. Allison Mankin suggested that the IESG needed to ask if the RAI people can start work as soon as they are ratified, not in the middle of the IETF week, and Brian said that he thought that that could be put in a followup message to the NomCom. Brian Carpenter said that the IESG needed to announce this to the IETF, and that he would work on the announcement Ted Hardie noted that the IESG has actually asked the Secretariat to schedule a joint application-transport meeting to discuss what the change means, and that that was an opportunity to discuss what the grand vision is. Brian Carpenter reminded the group that the NomCom message needed to go out by the next day; Allison Mankin offered to help with the second message, and said that it was important to let people know that the IESG did listen to them, even though the document was not changed all that much. New Business : RFC 3664bis - draft-hoffman-rfc3664bis-04.txt Russ Housely said that the problem is that there was a bake off and they found a problem. It turns out that the PRF is used two ways and the document only describes one. Russ considered fixing this in an RFC Editor note, but it's two or three paragraphs of changes and he would rather have a review. As there were no objections, the text was pulled back from the RFC editor queue, and Russ agreed to provide text to send to the RFC Editor, and to IETF-announce. 7. Agenda Working Group News [News you can use was mostly deferred] ------------------------------------------------------------------------------ [Call ended at 2:01 PM EDT]