IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2008-09-25. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was often uncertain who was speaking.)
Corrections from: Russ, Magnus, Jari, Dan
1 Administrivia
- Roll Call 1134 EDT Amy:
- Loa Andersson--- y
- Jari Arkko--- y
- Marc Blanchet--- n
- Ron Bonica--- y
- Ross Callon--- y
- Michelle Cotton--- y
- Lisa Dusseault--- y
- Lars Eggert--- y
- Pasi Eronen--- y
- Marshall Eubanks---
- Sandy Ginoza--- y
- Russ Housley--- y
- Cullen Jennings--- y
- Olaf Kolkman--- n
- John Leslie--- y
- Cindy Morgan--- y
- Chris Newman--- y
- Ray Pelletier---
- Jon Peterson--- regrets
- Tim Polk--- y
- Dan Romascanu--- y
- Mark Townsley--- late
- Amy Vezza--- y
- Dave Ward--- y
- Magnus Westerlund--- y
- Bash the Agenda
- no changes
- Russ: asked Ray to join at 1:30 Eastern for large interim
- Dave: I need to leave early, could move my mgmt item to next telechat
- Ron: executive session appeal text
- Magnus: STUN expert approval
- (Mark arrived)
- Amy: removed iporpr as mgmt item
- Approval of the Minutes of the past telechat
- September 11 minutes--- approved
- September 11 narrative minutes--- approved
- Review of Action Items from last Telechat
- Amy: Magnus BCP 32
Magnus: ongoing
- Amy: Dave: IANA re AS numbers
- Dave: in WG
- Jari: ongoing
2 Protocol Actions
2.1 WG submission
2.1.1 - New Items
- CAPWAP Access Controller DHCP Option (Proposed Standard)
draft-ietf-capwap-dhc-ac-option-01.txt
Token: Dan Romascanu
Extracted from Balloting:
- Jari Arkko: Comment [2008-09-25]: FYI: I have question out to my DHCP experts on why on the IPv6 side we return options without the client asking for them -- other documents have done this
differently.
- Discuss [2008-09-25]: John Brzozowski (one of the DHC WG chairs) said this:
"In short a DHCPv6 server should ONLY send options requested by the client. There was some debate about this a while back and the end result, if I recall correctly, is what I stated above. The thinking here is/was why would a server transmit an option(s) if the client has not requested it. Further, what value might there be sending an option to a client that it did not explicitly request and subsequently might not know how to parse or process."
However, also note the following excerpt from RFC3315 section 17.2.2. Creation and Transmission of Advertise Messages. This text appear in several area of RFC3315:
"The server includes options the server will return to the client in a subsequent Reply message. The information in these options may be used by the client in the selection of a server if the client receives more than one Advertise message. If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. The server must be aware of the recommendations on packet sizes and the use of fragmentation in section 5 of RFC 2460."
The above seems to clearly suggest that the server MAY legally transmit options to client(s) that were not specifically requested in the ORO.
My advice is to require the DHCPv6 clients in this case to add the requested option to the DHCPv6 ORO.
Telechat:
- Amy: one discuss
- Dan: Jari, this was reviewed, all groups in agreement. 3315 does allow sending options
- Jari: same server serving other devices... unnecessary info; we should ask the authors
- Dan: AD followup, maybe add explanation
- ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (Proposed Standard)
draft-ietf-ccamp-isis-interas-te-extension-04.txt
Token: Ross Callon
Extracted from Balloting:
- Pasi Eronen: Comment [2008-09-25]: It would be good to have the usual pointer in Security Considerations: "For a discussion of general security considerations for IS-IS see
[RFC3567bis]" (or something like that)
- Tim Polk: Discuss [2008-09-25]: This is a discuss discuss.
This document permits a subset of sub-TLVs from RFC 3784 and [ISSI-TE-V3] "and other documents" to appear in the new top-level TLV "Inter-AS Reachability TLV" (Type 141).
The subset is specified implicitly ("sub-TLVs ... for describing the TE link"). The only explicit linkage will be that in the IANA registry, where the sub-TLV will be marked as "May be present on TLV 141".
As a non-routing area reader, I think this is a bit confusing. We will have sub-TLVs that may appear in this new TLV, but no RFC anywhere will specify the linkage. I would have felt more comfortable if we included the initial list of "May be present on TLV 141" in this document. Did this bother anyone else?
Telechat:
- Amy: a discuss
- Ross: briefly; Pasi's requested comment is in a RFCed note, IANA question also; Tim, have to look in registry anyway
- Tim: WG must know some it applies to, this is obvious place to put such a list
- Ross: close to IANA question, which should be in initial version of registry
- Tim: will hold DISCUSS for IANA, updating right now, sending to authors
- Ross: AD followup
- RPCSEC_GSS Version 2 (Proposed Standard)
draft-ietf-nfsv4-rpcsec-gss-v2-05.txt
Token: Lars Eggert Note: Document Shepherd: Spencer Shepler (spencer.shepler@gmail.com)
Extracted from Balloting:
- Pasi Eronen: Discuss [2008-09-25]:
Since GSS-API already supports channel bindings (with some GSS-API mechanisms), it seems we end up with three different ways to do channel bindings in RPCSEC_GSS... The document probably should describe why the existing GSS-API layer channel bindings are not sufficient and give some guidance about their use
I think the document would also be improved by explicitly noting that a channel (e.g., IPsec or TLS) can have multiple channel bindings with different prefixes (e.g., for TLS we currently have two), and describing how the initiator picks which of them to use (and how this interacts with RGSS2_BIND_CHAN_PREF_NOTSUPP).
- Chris Newman: Comment [2008-09-22]:
Section 3.3, second bullet: I suggest you also reference the IANA registry "Hash Function Textual Names" to help find new hash functions as they're defined.
General Concern: A test vector or two would greatly improve this document.
- Magnus Westerlund: Comment [2008-09-23]: There are no reference to XDR in the first occurrence in section 1.
- Tim Polk: Comment [2008-09-25]: I support Pasi's discuss. I have no other objections to the document.
- Dan Romascanu: Discuss [2008-09-24]: I do not get a clear understanding from the document about the relation with RFC 2203. From what I get in section 4 the two versions of the protocol can coexist on the wire and a mechanism to negotiate the versions is in place. From the introductory sections I get that the reasons and advantages of using version 2 are limited to specific cases where low level hardware encryption is in place, or to avoid redundancy if encryption takes place at lower layer. What is the operational recommendation for deployment then - always upgrade or only in
specific use cases?
Should not the document header mention Update RFC2203 - when approved?
Comment [2008-09-24]: The acrnym GSS is never expanded in the document. I suggest to expand it at the first occurence in the Abstract or Introduction section.
- Magnus Westerlund: Comment [2008-09-23]: There are no reference to XDR in the first occurrence in section 1.
Telechat:
- Amy: couple of discusses
- Lars: authors need to explain new way; AD-followup
- Mobility Services Framework Design (MSFD) (Proposed Standard)
draft-ietf-mipshop-mstp-solution-06.txt
Token: Jari Arkko
Extracted from Balloting:
- Lars Eggert: Discuss [2008-09-25]: I refreshed my memory on the previous discussion between transport folks and MIPSHOP, and this is a significant edit of my earlier discuss and comment text.
The use of both UDP and TCP by MIH is OK, but I'd like to see stronger text that recommends or even requires which protocol should be used for which messages (namely, UDP for ES/CS messages that are guaranteed to be < 512 bytes and TCP for all IS messages).
I also have a discuss-discuss, It seems that SCTP (esp. partial reliability SCTP) would be the ideal transport for MIH, given that it was designed especially for telephony-like signaling. The document doesn't even mention SCTP as an option. Has the WG considered SCTP and if yes, why wasn't it chosen?
Comment [2008-09-25]:
Section 6.1., paragraph 4: The only delay with TCP (assuming Nagle is turned off) is the connection setup delay
Section 6.2., paragraph 1: TCP backs off if there is packet loss, and yes, performance may degrade. But UDP is no magic bullet, either - delivery over UDP is unlikely to be more timely than with TCP.
Section 6.3., paragraph 3: UDP will only be faster if much more aggressive timers are used here, which is problematic. I'd like to request that the text around what timers values are permissible be tightened using 2119 language.
Section 6., paragraph 1: Given the reliability requirements, shouldn't this text REQUIRE MIH ACKs with UDP and say they MUST NOT be used with TCP?
Section 6.3., paragraph 2: See above, I think your reliability requirements make this a MUST.
Section 6.1., paragraph 5: The PUSH bit is not under the control of an application that uses TCP. I believe you mean that the Nagle algorithm (RFC896) should be disabled.
Section 6.2., paragraph 3: "If MIHF knows the RTT, the rate can be based upon this" How?
Section 6.3., paragraph 1: "For TCP, the retransmission timeout is adjusted according to the measured RTT. However due to the exponential backoff mechanism, the delay associated with retransmission timeouts may increase significantly with increased packet loss." And that is a *feature* - it's why Internet congestion control works.
- Pasi Eronen: Discuss [2008-09-25]: It's not really possible to review this in meaningful sense without reading 802.21 itself (which I haven't done yet), but I have the following concerns
that I'd like to discuss:
In Section 2, the definitions of "MoSh", "MoSv", and "MoS3" seem inconsistent (MoSV is defined as "anything that isn't a MoSh", and
The document assumes that NAI can be used to identify a MIHF endpoint; but usually NAI identifies a user account which can be used simultaneously on multiple hosts (each of which would be a separate MIHF endpoint). How does this work?
It seems that both MIH-over-TLS-over-TCP and MIH-over-TCP use the same port number (likewise for DTLS/UDP case) -- how does the recipient distinguish which is being used? Perhaps the MIH protocol has functionality like "STARTTLS"? (if so, it should be briefly described here)
The examples use real domain names (which are owned by someone). I'd suggest changing to RFC 2606 names (example.com etc.), unless there are really good reasons not to do so.
- Russ Housley: Discuss [2008-09-24]: David Black did a Gen-ART Review during Last Call. I have not seen a response to his review. I am especially concerned about two issues raised in this review.
First, Section 6.3 says: "The default number of retransmissions is set to 2 and retransmissions are controlled by a timer with a default value of 10s." Those values appear to be reasonable. Please say that they SHOULD be used, possibly with some qualification involving network-specific characteristics.
Second, IS messages are the primary source of large messages, and IS messages do not have tight latency requirements. So, David asks if it is appropriate to say that TCP SHOULD be used for IS messages.
Comment [2008-09-24]: David Black did a Gen-ART Review during Last Call. Please respond to the concerns raised in this review.
- Cullen Jennings: Discuss [2008-09-24]: The document seems to recommend a 24 hour keep alive timer for TCP connections. Most NATs and middle boxes I have seen need something more like 2 hours, however the underlying OS TCP stacks typically do this without people being aware of it. Could the authors have a look and check the document says what they want. I'm OK with 24 hours if that is what people really meant but it surprises me.
- Tim Polk: Discuss [2008-09-25]:
Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and MoS3. However, I was surprised to find that these terms never appear in the remainder of the document. That is, the transport options in section 6, transport flows in section 7, and security considerations in section 8 only refer to MoS in general. I would think that the source of my mobility services would impact the selection of a transport, and would have security implications. (I don't think it impacts the flow, though. Is that correct?)
Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer messages which has impacts MIH message Size in 6.1 and rate in 6.2) ?
- Magnus Westerlund: Discuss [2008-09-23]:
Section 6.3: I am deeply worried over this retransmission scheme. Due to the bad performance I think people will change the retransmission number to a higher value and
reduce the timer to a much smaller value. In which case the lack of exponential back-off can have bad effects on the network.
I haven't looked at the MIH layer and what functions it provide. To give good performance I hope there is the following facilities available:
- sequence number for duplication and reordering detection
- possibility to timestamp or at least measure the RTT reasonably
I know too little about your requirement and capability to give really good recommendations. However, instead of reinventing the wheel why not always use TCP?
Section 6.4: If the TCP connection goes through a NAT box also that is subject to binding loss. However, the timeouots are much more reasonable. However, issues with NAT traversal using UDP are documented in [I-D.ietf-tsvwg-udp-guidelines]. If the MN has to send keep-alive messages to keep the binding open for MoS -> MN traffic you are going to have to send a lot of traffic.
I am fumbling in the dark here a bit as I don't understand which usage requirements you have, and how the the deployment model looks and between which nodes you really expect NATs to appear.
Comment [2008-09-23]:
Section 6. I assume there is retransmission functionality for non-reliable transports,
those really SHOULD NOT be used when sending over reliable transports.
Section 6.1: Considering NAT traversal and performance implications I think recommending against usage of IP fragmentation is the right one. But that is not knowing which facilities MIH
layer fragmentation provides. Can you please clarify this.
Telechat:
- Amy: open pos: Ron pass, Lisa pass, Mark not-yet; quite a number of discusses
- Jari: Lars, now OK to have both TCP and UDP
- Russ: I'm holding discuss; I'll clear and you hold
- Jari: authors explained why SCTP isn't an option: SCTP not widely enough implemented
- Lars: requires extensive (kernal-level) changes anyway: why not add SCTP; I won't block on this
- Jari: Pasi:
- Pasi: updated, same port number worries me, should explain how to distinguish
- Jari: I should push for more detail on TLS
- Pasi: seems to rely on point-to-point links already sufficiently secure
- Jari: Cullen; likely a mistake
- Tim: surprised not to see anything about ripple effects, e.g. tunnels; wanted to be sure people have thought about it; willing to move to Comment
- Jari: Magnus
- Magnus: don't know performance requirements; hard to believe TCP isn't actually faster; worried folks will diddle timers in search of performance
- Lars?: tacking reliability onto UDP really doesn't work: UDP OK in packet loss OK
- Jari: revised-ID needed
2.1.2 Returning Items
- Generalized MANET Packet/Message Format (Proposed Standard)
draft-ietf-manet-packetbb-15.txt
Token: Ross Callon
Extracted from Balloting:
- Ron Bonica: Comment [2008-09-24]: I support Lars' comment about multiplexing, but don't think that it is a big enough issue to motivate an abstention. The multiplexing strategy described in
Appendix A makes the MANET difficult to implement, but I don't think that it does any real harm to the Internet.
- Lars Eggert: Comment [2008-09-23]:
I still disagree with the design philosophy behind this packet format, but since this isn't actionable this late in the game, I'll abstain.
I also don't believe the multiplexing and demultiplexing approach in Appendix A is fully thought through, especially in light of the IANA actions for MANET. If
all MANET daemons on one node share a port, and if packets destined to that port can contain messages that need to be delivered to different routing daemons (and some that need to be delivered to multiple daemons), who performs this demultiplexing and how?
- Chris Newman: Comment [2008-03-12]:
If msg-hop-count is missing, should it be added if the message is forwarded?
it would be good to collect or summarize requirements like this into a separate section listing requirements for consumers of the format.
should state the title of the IANA registry, for example: "MANET Message Types".
You might want to apply equivalent rules to values 120-127 for things that best appear at the end (e.g. a signature).
Some design issues that concern me:
- The format has lots of options.
- Creating two different ways to encode the same thing is always risky.
- The TLV index feature is really a layering violation
- I'm concerned that limiting the sequence number to 16 bits is choosing conciseness over reality.
- Dan Romascanu: Comment [2008-01-24]: I am actually wondering whether it would not be better that documents that a Gen-ART (or security, or other) review declare non-fit for IESG discussion first address the review issues and only then be placed on an IESG telechat agenda.
- Magnus Westerlund?: Comment [2008-01-24]: This document has so many bugs related its design that it really should go back to the WG for rehashing. Some issue to consider that are evident:
- Lack of default values for optional fields that in fact seems mandatory
- Version extension rules lacks requirement on what fields may not be changed when changing version.
- Unnecessary complexities from lack of willingness to determine what is important and what is not.
- Message Sequence number with unclear definition where part of the text allows any generation, but with uniqueness and the other talks about wrapping. In other words non combinable
properties.
IESG internal process comment: I have to agree with Dan here. It is the work of the responsible A to not place
documents on the IESG agenda that are not ready in the AD's view. That means following up on reviews in WG last call. Yes, in this case the Gen-art review
was two days late.
Telechat:
- Amy: open polition: Lisa pass
- Ross: think we can take these offline; revised-ID needed
- Representing multi-value time in MANETs (Proposed Standard)
draft-ietf-manet-timetlv-07.txt
Token: Ross Callon
Extracted from Balloting:
- Jari Arkko: Comment [2008-06-26]: What makes it hard to read this spec is that the definitions are almost, but not entirely, free of context. A set of addresses is a context for some statement about them. Your specification defines the format of the statement about time, but does not fully define what objects (addresses) it applies to.
- Ron Bonica: Discuss [2008-09-24]: The authors generate a new mechanism for representing time, but they never explain the following:
- why are we constrained to 8 bits
- if all MANET nodes must have the same value C, why is it included in the calculation?
- what granularity is required (seconds, milliseconds?)
- what high and low values must be represented
- Lars Eggert: Comment [2008-01-23]: I agree with the gen-art reviewer that the concept of "distance" is not well- explained. I'm also questioning why it makes sense to specify a relatively
complex construct such as distance-dependent time in a generic TLV format - is this really common enough across MANET protocols so that it needs to be specified generically?
Finally, Chris raises a good point - it's unclear why a new fixed-point format is the right thing here, especially since it can only be understood if one knows what "C" is in use. Burning a few more bits and eliminating "C" seems to be the right tradeoff.
- Chris Newman: Comment [2008-01-21]: I saw no discussion in this document justifying the complexity of creating a new custom 8-bit floating point number format rather than just using a simple 32-bit integer.
Telechat:
- Amy: open, Lisa pass, couple of discusses
- Ross: revised-ID needed
2.2 Individual Submissions
2.2.1 New Items
- WebDAV Current Principal Extension (Proposed Standard)
draft-sanchez-webdav-current-principal-01.txt
Token: Lisa Dusseault
Extracted from Balloting:
- Russ Housley: Discuss [2008-09-24]: Christian Vogt did a (late) Gen-ART Review. I have not seen a response to his review. I would really like to see if the author agrees or disagrees with the technical point that he raises:
Section 3, 2nd paragraph of "description" field:
This paragraph specifies the return value for the principal resource in case there are multiple possible values. The return value is in this a case to be freely chosen by the server. Why not return all possible values?
The disadvantage of returning only a single principal resource value is that it may lead to consistency problems. The paragraph attempts to prevent this by urging servers to /try/ to be consistent. But since consistency cannot be guaranteed, consistency problems may still come up. Always returning all possible values would fix this.
The authors should consider changing the protocol behavior to always returning all available principal resource values. If there are reasons to restrict the number of values returned to a single one, then these reasons should be explained in section 3 of the document.
Comment [2008-09-24]: Christian Vogt did a (late) Gen-ART Review. Please respond to the technical and editorial issues raised in this review.
Telechat:
- Amy: open position: Tim no-pos; one discuss
- Lisa: I think it's better with just one URL
Russ: note I asked that the LastCall comment be answered
- Chris?: document doesn't say you should respond with a canonical URL; I'd agree they should have sent "read section X"
- Russ: I will clear, using PointRaised is fine
- Amy: approved-point-raised
2.2.2 Returning Items
- URI Scheme for GSM Short Message Service (Proposed Standard)
draft-wilde-sms-uri-16.txt
Token: Lisa Dusseault
Extracted from Balloting:
- Jari Arkko: Comment [2008-09-25]: I share the issue in 2nd part of Russ's Discuss: I also felt that the document brought in a bit too many details about the processing, formatting, and delivery of SMSes. This RFC does not define how SMSes are sent, it just defines URIs.
- Pasi Eronen: Comment [2008-09-24]: I think the document would benefit from including an example with a non-global number (not starting with "+"), since the exact syntax used for them changed very recently (when going from version -15 to -16), and the change might not be obvious to someone who read the old versions.
Section 1.3.5 would benefit from one sentence saying that when "sms" URI is used in HTML form, the "sms-body" part (if present) is ignored.
- Russ Housley: Discuss [2008-09-08]: Miguel Garcia did a Gen-ART Review that revealed two major concerns and some minor ones.
First, the SMS URI scheme syntax. Notice that <query> can contain the equal sign, I suspect that more than one equal sign might lead to implementation surprises, so the syntax should be adjusted or there should be text to highlight this situation to the reader.
Second, the scope of this specification is not clear. Are the SMS procedures PART of the scope of this specification?
Comment [2008-09-08]: Please consider the comments provided by Miguel Garcia in his Gen-ART Review. I have not seen a response to this recent review.
- Chris Newman: Discuss [2008-09-22]:
1. The document needs a normative reference to the HTML 4.01 specification which defines the format for the media type application/x-www-form-urlencoded.
2. The following text is factually incorrect: "As SMS transport is "out-of-band" as far as normal HTTP over TCP/IP is concerned, this provides a way to fill in forms offline, and send the data without making a TCP connection to the server, as the set-up time, cost, and overhead for a TCP connection are large compared to an SMS message." With my iPhone, there are contexts where SMS is more expensive that HTTP/TCP (e.g. local use if I'm over my prepaid SMS limit). In addition, SMS can be more expensive on the server infrastructure side; a two-way email-to-SMS gateway has to track a large amount of state because SMS has no extension fields for reply gateways. Finally, I observe this contradicts the previous point that SMS "is a major source of revenue" (which implies it's expensive for end-users).
3. The URI scheme doesn't have an extensibility model as far as I can tell.
4. You need to discuss how use of comma as a delimiter between addresses interacts with use of comma within a telephone-subscriber (e.g., as the RFC 3966 ABNF permits in the isub= parameter).
5. While you've defined the charset of the body parameter, the semantics are not defined. Is a newline permitted? If so, how is a newline encoded? Perhaps a reference to 5198 would be helpful?
6. Why is this "provisional" rather than "Permanent"?
- Dan Romascanu: Comment [2008-09-25]: I support the issue raised by Magnus in his DISCUSS.
- Magnus Westerlund: Discuss [2008-09-09]: Section 1.3.4 contains example phone numbers that appears to be valid ones. The first I find has or are used by the president of the US. The second seems to point to cellphone in California that aren't listed. As it is known that publication in specification of address or reachability information can result in unwanted traffic I would recommend that these numbers are changed to example ones that are certain for the foreseeable future to don't lead to any individual or organization.
Telechat:
- Amy: open, Tim no-pos, number of discusses
- Lisa: should have done full-scale AD review; didn't realize how much had changed; absolutely needs revised-ID
- Chris: document changed so much that we should require extensive work and a new LastCall
- Lisa: pragmatically, how do we ensure the proper rework; can we get RAI-area and Gen-area reviews?
- Lisa: revised-ID needed
3 Document Actions
3.1 WG Submissions
3.1.1 New Items
- CAPWAP Threat Analysis for IEEE 802.11 Deployments (Informational)
draft-ietf-capwap-threat-analysis-04.txt
Token: Dan Romascanu
Extracted from Balloting:
- (none)
Telechat:
- Amy: no discusses, any objection?, approved, notes OK
3.1.2 Returning Items
- (none)
3.2 Individual Submissions via AD
3.2.1 New Items
- (none)
3.2.2 Returning Items
- (none)
3.3 Independent Submissions via RFC Editor
3.3.1 New Items
- MANET Autoconfiguration using Virtual Enterprise Traversal (VET) (Informational)
draft-templin-autoconf-dhcp-16.txt
Token: Ross Callon
Extracted from Balloting:
- Dan Romascanu: Discuss [2008-09-25]: this is a discuss-discuss for the DNP choice in the note - see the mail thread earlier in the day
Telechat:
- Amy: one discuss
- Ross: originally assigned to me (potential overlap with MANET); but this completely overlaps a different WG
- Jari: asked autoconf WG chairs, they recommend blocking; they're currently working on architecture document but charter includes solutions such as the one in this document; WGC don't believe anyone would implement it
- Dan: process question: WG is taking a very long time, is blocking the right thing to do?
- Jari: I'd be happiest if this was six-month delay, not indefinite delay
- Ross: there are fundamentally different approaches here.
- Jari: MANET thinking, routing area thinking...
- Ross: email to Fred, intend to revisit in six months
- Amy: do-not-publish at-this-time; RFCed note as is
- Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs (Informational)
draft-touch-msword-template-v2.0-07.txt
Token: Russ Housley
Extracted from Balloting:
- Lars Eggert: Comment [2008-09-23]: "This version is intended as an update to RFC3285." Then it needs to have an "Updates: 3285" in the header. I also don't see a reason why this document shouldn't simply obsolete 3285 - is there any functionality lost?
Telechat:
- Amy: no discusses, any objection? RFCed note says updates 3285, will go out Monday
3.3.2 Returning Items
- (none)
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
- Application-Layer Traffic Optimization (alto)
Token: Lisa
Telechat:
- Amy: any objection
- Cullen: hum came out No; charter became broader, while BoF thought too broad; charter vague, not crisp on what to discover; tussle over balance between client-sends-all and oracle-sends-all
- Lisa: I personally tracked down folks who hummed against, often the same misunderstanding: we changed charter text to prevent that misunderstanding; mailing-list has been very active and is now quiet
- Cullen: mailing-list tilted toward bit-torrent desires, not service-provider; BoF quite clear against service-discovery
- Lisa: where does charter say otherwise?
- Cullen: some folks wanted a way to discover list of all possible servers and pass that to ALTO servers, not acceptable
- Lisa: we can fix that
- Cullen: one hard thing: how much of the decisions made by clients vs ALTO servers; neither extreme is viable
- Lisa: I think it clear the WG will have to consider some very different proposals on this issue
- Cullen: was expecting something ruling out client-passes-full-list
- Lisa: that can be made clear
- Dave: schema for routing preference, but no routing protocol changes...
- Lisa: I agree that's a bad phrase, will suggest "connection preferences"; perhaps not saying geographic
- Russ: can we do approved-point-raised?
- Lisa: will send email summarizing to authors and ADs, ask list (only) about "routing preferences" wording
- Dave: want it clear whether "proximity information" is in-scope
- Lisa: can't do that much change without involving WG
- Chris: what about changing the term from "geographic" to "proximity"?
- Dave: call out having a way to query for proximity info
- Amy: approved-point-raised, pending info from Lisa
4.1.2 Proposed for Approval
- (none)
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
- (none)
4.2.2 Proposed for Approval
- Softwires (softwire)
Token: Mark
Telechat:
- Amy: any objection?
- Jari: one comment on IESG list, feedback from Randy Bush, should we wait for interim before approval?
- Mark: show progress going to interim, this is well understood
- Jari: let's not wait
- Magnus: what about end-user control of CGN?
- Mark?: what is effect of NAT? hard to say, it's kind-of "best-effort"; can't say how much "carrier-grade-NAT" can do
- Amy: approved, not waiting for anything
1312 EDT break
1318 EDT back
- Loa Andersson--- y
- Jari Arkko--- y
- Marc Blanchet---
- Ron Bonica--- y
- Ross Callon--- y
- Michelle Cotton--- y
- Lisa Dusseault--- delayed
- Lars Eggert--- y
- Pasi Eronen--- y
- Marshall Eubanks---
- Sandy Ginoza--- y
- Russ Housley--- y
- Cullen Jennings--- y
- Olaf Kolkman---
- John Leslie--- y
- Cindy Morgan--- y
- Chris Newman--- y
- Ray Pelletier---
- Jon Peterson---
- Tim Polk--- y
- Dan Romascanu--- y
- Mark Townsley--- y
- Amy Vezza--- y
- Dave Ward---
- Magnus Westerlund--- y
5. IAB News We can use
- Loa: two short things: RFCed restructuring consensus calls, aim for next Wednesday; second, Routing Research Group, discussion will continue
6. Management Issues
- Review of arp-parameters request 2 of 2 [IANA #183428] (Michelle Cotton)
Telechat:
- Michelle: requester info in jabber room
- Jari: (digesting it) seems to make sense
- Amy: approved, official note to IANA
- Large Interim Mtgs (Russ Housley)
Telechat:
- Russ: looking for January timeframe for experiment
- Ray: asked Hilton about venues in Europe; following up on incomplete data; list of potential locations, meeting space $0 to $30,000. Getting quotes from Verilan. Expecting we can find sponsor; registration fee in $400 range, expecting to lose some attendance at regular IETF meetings.
- Ross: hope we'll look at safety issue.
- Ray: range of hotel rooms perhaps $120 - 300+ per night; would help to know likely attendee count; 2nd - 4th week of January, will keep IESG in loop on dates, hopefully by next Thursday; 3 days, 4 tracks; wiki to schedule yourselves; budget model currently assumes 300 in January, more in September
- Referencing Non-Standardized Technology in IETF Documents (Dave Ward)
Telechat:
- (deferred, Dave not present)
- Designated expert for RFC 5341 [IANA #194783] (Michelle Cotton)
Telechat:
- Michelle: looking
- Cullen: hopefully Jon can find one, I'll take the action item
- Review of atom link relations request [IANA #189665] (Michelle Cotton)
Telechat:
- Michelle: looking for IESG approval
- Chris: Lisa is best person to take this: delegate to Lisa
- Amy: action item Lisa to review
- RFC 3932bis (Jari Arkko)
Telechat:
- Jari: two main changes... like feedback before sending to LastCall
- Pasi: new boilerplate, how to ensure consistenty?
- Jari: RFCed note to publish simultaneously
- Russ: IRTF document on IAB agenda for Wednesday, confident all three approved before Minneapolis
- Jari: how long before LastCall? one week?
- Russ: give Jari a go/nogo next Thurs
- Approval of IANA expert for STUN (Magnus)
Telechat:
- Amy: any discussion; approved
7. Agenda Working Group News
- Jari Arkko (Internet)--- two BoF requests, busy with v4v6 interim, tending to approve mulitmod; interim next week 60 participants Wednesday and Thurs
- Ron Bonica (O & M)--- none
- Ross Callon (Routing)--- nomcom, insufficient candidates in some areas, would like three accepting, settle for two; will not publish updated descriptions (less urgent)
- Lisa Dusseault (Applications)--- none
- Lars Eggert (Transport)--- PANA BoF, hum positive, working on charter, tentative mtg in Minneapolis; ?? documents in LastCall which won't complete by Minneapolis; another WG hanging on NAT traversal need
- Pasi Eronen (Security)--- none
- Russ Housley (General)--- close to closing IPR WG
- Cullen Jennings (RAI)--- none
- Chris Newman (Applications)--- expecting LDAP BoF request, possible second
- Jon Peterson (RAI)---
- Tim Polk (Security)--- none
- Dan Romascanu (O & M)--- close to closing IMSS; interim coming for NETMOD
- Mark Townsley (Internet)--- closing iporpr, petered out, nobody to push one remaining document; doc in iap? ITU group--id/loc splits, liaison working on it, happiest if this is an IAB thing.
Loa?: mostly a requirements thing.
Mark: I got heads-up from our liaisons Monique and Stuart; Scot Brim was there, telling them about our ongoing work, he stepped down and this cropped up
Cullen?: good to encourage folks who tend to be involved in both to communicate to us
Mark: best to communicate to Liaisons, not ADs busy with other things
Loa?: need to act on short notice; think we have in this case.
- Dave Ward (Routing)---
- Magnus Westerlund (Transport)--- things quiet; hope to close rserpool WG before next telechat
1418 EDT Went into Executive Session