IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2008-12-18. These are not an official record of the meeting.

Narrative scribe: John Leslie (The scribe was often uncertain who was speaking.)

Corrections from: (none)

1 Administrivia

  1. Roll Call 1135 EDT Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2 Protocol Actions

2.1 WG submission

2.1.1 - New Items

  1. TCP User Timeout Option (Proposed Standard)
    draft-ietf-tcpm-tcp-uto-10.txt
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Ron Bonica: Discuss [2008-12-18]: This may be a very short-lived discuss. In the security section, you recommend the use of IPSEC or TCP-MD5. AFAIK, TCP-MD5 is rarely implemented on boxes that aren't routers. Wouldn't you be better off recommending TCP-AO?
    2. Pasi Eronen: Discuss [2008-12-15]: I have one concern that I'd like to discuss before recommending approval of the document:
      If the data cited in Section 4.1 is a reasonable approximation of reality -- and 3% of TCP connections would fail -- doesn't this mean that either (a) no popular OS or popular application (such as email, IM, or SSH client -- all of which would potentially benefit from longer timeouts) can enable this by default, or (b) it has to implement some kind of recovery logic (if using UTO fails, disable it and establish new connection without UTO).
      If this is the case, it should be mentioned in e.g. Section 4.1, possibly sketching how the recovery logic would work (so each app doesn't have to reinvent it, possible badly).
    3. Russ Housley: Discuss [2008-12-12]: In the Gen-ART Review from Scott Brim, a significant question was raised, and the WG has not provided an answer. Scott asked: "Since a UTO can apparently be sent at any time, what happens if a UTO is received that shortens the timeout and there are unacknowledged packets that are already beyond the new timeout value?"
    4. Cullen Jennings: Comment [2008-12-17]: I think this is great (as long as it works through firewalls and nats - and support that part of Pasi discuss) but I think that it has to be exposed to apps and support that parts of Chris' discuss.
    5. Chris Newman: Discuss [2008-12-15]: Is the intention to have this be used only by operating system software? Or should this be made visible to applications? If the latter is the case, is there work in progress to define the identifiers and structures that would be used with setsockopt() so this would have a chance of deploying?
      Applications sometimes have information about the desirability of long lived connections. For example, HTTP wouldn't benefit from longer user timeouts, IMAP+TLS benefits quite a bit, while SSH could benefit a great deal (especially if the user has spent time setting up multiple data tunnels). But as we've seen with the IPv6 mess prior to getaddrinfo, if the socket extension identifiers/structures aren't nailed down early deployment is slowed greatly when communication between the transport and application layers is needed.
      Also, because communication of timeout information between the TCP stack and application software has been so poor in the past, quality server applications will put sockets in non-blocking mode and implement their own timeouts with select/poll or equivalent and shut down the socket. If applications have no way to communicate this to the TCP stack, the stack could negotiate a timeout longer than the application timeout and thus create a false expectation for connection retention.
    6. Tim Polk: Comment [2008-12-17]: I support Chris's and Pasi's discusses. The failure rate with middleboxes could present a significant problem unless the TCP stack is clever enough to establish new connections without using uto after failure. The onus is clearly on the TCP stack to adjust since the "communication of timeout information between the TCP stack and application software has been so poor in the past" to quote Chris's discuss.
    7. Dan Romascanu: Discuss [2008-12-17]: The document is missing any manageability or operational considerations. Although section 3 mentions that the UTO can be enabled either on a per-connection basis, or controlled by a system-wide setting there is no further indication what this means from the point of view of system opertors. There is also no indication about performance measurement, especially on the light of the fact that reliability issues are a concern and are discussed. Last would the MIB modules defined in RFC 4022 or RFC 4898 need to be extended to cover this new option?

    Telechat:

  2. ForCES Protocol Specification (Proposed Standard)
    draft-ietf-forces-protocol-19.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Cullen Jennings: Discuss [2008-12-17]: I don't see how one can get interoperability without specifying at least one mandatory to implement TML. Or say something like the CE needs to implement A and B and the FE can choose A or B.
    2. Tim Polk: Discuss [2008-12-18]: My concerns are related to Cullen's and Magnus's issues, but with a security area spin:
      This document does not clearly specify the security requirements that need to be supported by every TML. In the absence of those requirements, the document needs to specify a single TML with strong security properties as mandatory to implement. Otherwise, two fully compliant implementations might be interoperable but have no ability to provision security.
      Alternatively, this document could clearly specify that all TMLs MUST include mandatory to implement mechanism that provide the necessary security services. Note that the SCTP TML specification implies that such mechanisms need to be specified for each TML:
      I personally prefer the second solution (establishing requirements for all TMLs) but that does not resolve Cullen's issue. Specifying a mandatory to implement TML with appropriate security properties would resolve both our discusses. (Add in the reliability requirements and you could take care of Magnus' first issue as well.)
    3. Magnus Westerlund: Discuss [2008-12-18]:
      1. Section 1: As the reliability requirement is for varying degrees of reliability it seems that some discussion should be had if this can be realized by using different TMLs or if a single TML needs to provide all the different degrees of reliability?
      2. Section 5: "3. Congestion control..."
      Isn't this split putting to much functionality regarding overload control into the TML rather than having it in the PL? It seems correct to have the TML be responsible for transport congestion avoidance. However, if it is the FORCES nodes themselves that are overloaded rather than the network connecting them duplicating the overload protection mechanism in each TML seems wrong. Are there good reasons for doing overload protection in the TMLS rather than the PL?
      Looking at http://www.ietf.org/internet-drafts/draft-ietf-forces-sctptml-01.txt it seems that the difference between transport congestion control and overload protection is not correctly considered.
      To me it seems that one needs to dig much more into the details of how overload prevention and handling affects the priorities and is affected by head of line blocking within the underlying transport. Also with a two layer approach the pushback in overload situations to the PL becomes more complex and needs to be considered.

    Telechat:

  3. ForCES MIB (Proposed Standard)
    draft-ietf-forces-mib-10.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Dan Romascanu: Comment [2008-12-10]: This document underwent MIB Doctors reviews from John Flick and Bert Wijnen. It would be nice to mention them in the Protocol Quality section of the announcement together with the other reviews and to acknowledge the contribution of the two MIB Doctors in the document (right now only John is mentioned).
    2. Magnus Westerlund: Comment [2008-12-18]: To me it seems this MIB modules fails to instrument any aspect of the protocol that would tell an administrator that there is an overload situation. Maybe for a future MIB.

    Telechat:

  4. Internet Calendaring and Scheduling Core Object Specification (iCalendar) (Proposed Standard)
    draft-ietf-calsify-rfc2445bis-09.txt
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-12-16]: Section 3.2.6., paragraph 5: What's the status of "file://" and "ftp://|? RFC1738 was obsoleted, and while "telnet://" and "gopher://" have been resurrected (RFC 4248, RFC 4266), I couldn't locate an RFC that did the same for these two.
      (Making this a comment, since I won't be on the call and I don't want to block.)
    2. Pasi Eronen: Discuss [2008-12-18]: A question based on Richard Barnes's SecDir review: when using BINARY data type with in-line encoding, should the text say FMTTYPE MUST be included (or SHOULD be included)? Or is the recipient supposed to guess semantics from e.g. file name extension or data contents?
    3. Russ Housley: Comment [2008-12-12]: This minor error was caught in the Gen-ART Review by Gonzalo Camarillo:
      OLD: This property SHOULD not be used to alter the interpretation of
      NEW: This property SHOULD NOT be used to alter the interpretation of
    4. Dan Romascanu: Comment [2008-12-17]: I support Magnus's DISCUSS based on Lars's comment about the reference to RFC1738.
    5. Magnus Westerlund: Discuss [2008-12-17]: I will take on Lars comment and keep that as a discuss. There is a normative reference to RFC 1738 that is an obsoleted RFC.
      Is it necessary to include these scheme identifiers? Can it be done in some other way that doesn't make it into a normative ref?
      Comment [2008-12-17]: The ABNF is not formally correct: There are some multi-line rules containing empty lines, like calprops and many of the other <x>props rules. I understand that this is for readability however, it is against the ABNF rules.

    Telechat:

  5. Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6) (Proposed Standard)
    draft-ietf-mext-nemo-v4traversal-07.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Ross Callon: Discuss [2008-12-11]: I don't believe that this spec is remotely close to complete for the general case of mobile IPv4/IPv6 routers. Unless I am missing something, this is really a document for mobile hosts. The easiest way to resolve this, at least for this one document, is probably to remove the "and routers" from the title and a very few places in the draft (I think just the fourth paragraph in section 2).
      Alternately, has this been thought through for a very specific type of router, such as the NAT box / wireless router that sits between many home networks and the DSL/Cable connection to an ISP? If so, then the scope of what routers this applies to should be described.
    2. Lars Eggert: Discuss [2008-12-16]: (Updated 2008-12-16) Some of the issues raised in Colin Perkins' tsv-fir review seem to not have been addressed in -07. I may not have been CC'ed on all the emails - it would be useful if the authors would respond to his review and briefly outline how each issue got handled.
      Comment [2008-12-10]: Section 2., paragraph 0: "Note also that documents published as "RFC Editor contributions" [RFC3978] are not considered to be IETF documents."
      I think you want to refer to the different streams defined in RFC4844 here, rather than to the long-obsolete RFC3987.
    3. Pasi Eronen: Discuss [2008-12-17]:
      • The text about TLV-header and GRE tunneling seems vastly underspecified,and unlikely to lead to interoperability. For example:
        • Apparently the 'T' bit does means only that MN supports the general TLV format; it may not support any of the specific TLV types, such as GRE (and new ones may be defined in the future). How this is supposed to work?
        • There's no text describing how GRE tunneling is actually done; for example, how the various parts of GRE header are set/used in the context of Mobile IPv6, how that interacts with RFC 4877, etc.
        • Why does the TLV header include the "Length" field? (since the length is already known from the outer header) Can there be multiple TLVs inside one packet, or something?
        • Section 5.1 says "The Type field is limited to values of 0 and 1 to make sure that the receiver can tell the difference between the Type field and the IP version field in a packet that contains an IP header after UDP." Does that mean that IANA sections should say the registry has just a single unallocated value (0)?
        The text is unclear whether UDP tunneling (either vanilla or TLV) can be used when in IPv6 network (that is, IPv6 care-of address). Most of the text (e.g. 1st sentence of Section 5.4.3) indicates it cannot be used (when in IPv6 network, MN works as in RFC 3775), but some parts (e.g. third figure in Section 5.1, 3rd paragraph in Section 6) suggest it can. If it's the former, I'd suggest adding text like "This flag MUST NOT be set when IPv6 Care-Of Address is used" to Sections 4.1.3, 4.2.2, 4.2.3 (and fixing 5.1). If it's the latter, there's more work to do.
      • Section 3.1: "Note that the use of [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile node information that allows it to continue to communicate with the home agent if, for example, the mobile node moved from an IPv6- enabled network to an IPv4-only network."
        This seems incorrect -- this draft can give you e.g. the IPv4 address of the home agent, so the MN can continue to communicate with the HA if it moves to an IPv4-only network. This sentence probably means that if the MN is in an IPv4-only network, and it already doesn't have this information, it can't use this draft to obtain it (since it's based on DHCPv6, not DHCPv4)?
      • Section 3.2: "Securing these messages requires the mobile node to have a security association with the home agent, using IPsec (AH or ESP) and based on the mobile node's IPv4 care-of address as described in [RFC3775]. Since the mobile node needs to encapsulate all IPv6 traffic sent to the home agent into IPv4 while located in an IPv4-only visited network, this SA would match all packets if the selectors were based on the information in the outer header."
        This looks strange (when using tunnel mode IPsec, the selectors select the packets to be protected before the outer header is added -- so the last sentence is weird) -- what are the IPsec SPD entries, and what does the resulting packet look like?
      • Section 5.3 should mention that two sets of keepalives have to be sent (one for DSMIPv6 port, another for 4500).
      Comment [2008-12-17]: While IPsec may have been a reasonable solution for the security requirements of RFC 3775, this draft (and the multiplecoa draft) IMHO clearly show that IPsec is not an appropriate solution for these MIPv6 extensions.
      Once the concerns in my "discuss" have been addressed (which should not be very difficult), I intend to ballot "abstain".
    4. Russ Housley: Discuss [2008-12-14]: Draft -07 was generated to handle the Gen-ART Review comments from Brian Carpenter. Brian raised two more comments when the new version was posted:
      1. A normative reference to an Informational RFC needs to be handled by the downref procedure. That concerns RFC 2983 and RFC 4459.
      2. Several normative references are listed as informative. That's a matter of judgement and consensus, so the WG and the IESG are free to disagree. The fact that GRE is only an optional feature doesn't prevent it being a normative reference, however; the question is whether an implementer can implement that option without reading RFC 2784. The same applies to all the other cases Brian suggested should be normative.
    5. Dan Romascanu: Comment [2008-12-18]: The OPS-DIR review by Tina Tsou raised a number of questions and pointed to nits. Although none of them seem a show stopper, I believe that they should be addressed for better clarity and quality of this document:
      1. In section 5.1, 5.4.2, 6.2.1, vanilla occurs 6 times and is ambiguous. Clarification would be welcome to explain what is meant.
      2. In section 5.3, it is mentioned that if the mobile node is not active, it will send binding update to the home agent. It is not clear how home agent operates upon receiving the binding update message? Also if the mobile node is not active, does it mean the mobile node is not reachable?
      3. In section 5.3, it is mentioned that the mobile node maintains NAT binding, if the mobile node is not reachable, then it need not to refresh the NAT binding. What is confusing here is that NAT devices also maintains NAT binding associated with the mobile node, so if the mobile node is not reachable, will the mobile node refresh the NAT binding in itself or in NAT on the path between the mobile node and the home agent? Moreover if the mobile node is not reachable, does it mean the mobile node changes the port or private address? Clarification would be welcome.
      4. It is not clear what’s the difference for NAT keep alive between the mobile node behind NAT and the home agent behind NAT.
    6. David Ward: Discuss [2008-12-10]: The document specifies that it is to cover the specification for mobile routers as well as hosts. In fact, nothing is called out for routers. In particular, given there are many issues for mobile routers and routers in mobile ad hoc networks; I would have expected at least references to issues associated with mobile routers. The term "router" is used only twice in the document.

    Telechat:

  6. IANA Considerations for RPC Net Identifiers and Universal Address Formats (Proposed Standard)
    draft-ietf-nfsv4-rpc-netid-05.txt
    Token: Lars Eggert Note: Document Shepherd: Spencer Shepler (shepler@storspeed.com)
    Extracted from Balloting:
    1. Lisa Dusseault: Comment [2008-12-17]: I don't understand why this document has both registered netids and constants. That seems redundant to me.
    2. Pasi Eronen: Discuss [2008-12-16]: The document seems to assume that a pointer to a transport protocol spec (e.g. RFC 4340 for DCCP or RFC 2960 for SCTP) is enough to describe how to use it with RPC. I'm not sure that's always the case.
      In particular, are there existing implementations of dccp/dccp6 and sctp/sctp6? If not, consider leaving their registration later. If yes, is there any written documentation about how they use DCCP/SCTP? (For the tcp/tcp6 entries, I'd also suggest adding a pointer to RFC 1831)
      Another question: Section 4.2 says "All requests for assignments to the format registry on a Standards Action basis must undergo Expert Review and must be approved by IESG". Expert Review+IESG Approval is one possible IANA policy for this registry, but it's not the same as Standards Action. Please clarify which is meant.
    3. Tim Polk: Comment [2008-12-17]: In sections 4.1 and 4.2, the registrant provides a value of TBD1 in the registration request, and IANA substitutes the assigned value for TBD1. This is very clear but isn't quite right if a single document requests multiple registrations. In that case, the provided values would also include TBD2, ..., TBDx.
      To be honest, I'm not sure if any readers would actually be confused and I can't think of a better way to write the text myself. If an obvious solution comes to the author, that would be great. Otherwise, there is probably no harm in proceeding as is.

    Telechat:

  7. OSPF Link-local Signaling (Proposed Standard)
    draft-ietf-ospf-lls-05.txt
    Token: David Ward
    Extracted from Balloting:
    1. Ross Callon: Discuss [2008-12-17]: My discuss is really a question. I apologize that I didn't get a chance to ask the authors prior to the telechat and expect that I am quite likely to clear during the telechat.
      How much testing and/or deployment experience is there with this feature? Are we confident that there aren't any existing implementations that suffer some sort of unfortunate reaction (such as crashing) when they get OSPF packets that contain TLVs encoded in this manner?
    2. Lisa Dusseault: Comment [2008-12-17]: I had the same question as Pasi to be sure that this actually gets marked as obsoleting RFC4813.
    3. Lars Eggert: Comment [2008-12-16]: Section 2., paragraph 4: "The LLS data block MAY be attached to OSPF Hello and DD packets." The "MAY" is ambiguous - do you mean "MUST only"?
      Section 6.1., paragraph 4: "[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999." Obsolete normative reference: RFC 2740 (ref. 'OSPFV3') (Obsoleted by RFC 5340). Please add RFC Editor Note.
    4. Pasi Eronen: Discuss [2008-12-16]:
      • Should this document (once approved) obsolete RFC 4813? Either way, the document needs to describe its relationship to RFC 4813, and list changes done since it
      • A question: do you have data to show that existing implementations (that don't support RFC 4813/this draft) actually behave as assumed here? (That is, accept OSPF packets with extra junk at the end -- this sounds like the kind of thing implementations often get wrong....) I assume you have such data, but briefly summarizing the real-worldsituation in Section 4 would be very useful.
      • Section 3 is unclear whether the IANA is asked to create a registry for this document, or just update the registry created for RFC 4813 to point to this document (or possibly something else).

      From Stephen Farrell's SecDir review (which also needs a reply):
      • Section 2.2 describes the use of the checksum field, but never says what to do if the checksum is wrong. Is just the LLS block ignored or the entire OSPF message?
      • Section 2.2 doesn't say whether the checksum bits (presumably zero'd?) are considered part of the LLS block when calculating the checksum.
      • The spec doesn't say what to put in the checksum field when using the Cryptographic Authentication TLV (presumably 0, but should be said)
      • Section 2.5 is quite vague on exactly what data is used when calculating AuthData. Does it include the TLVs following CA-TLV? (Presumably yes, but the text should say so.) What's placed in the AuthData field during the calculation? (Presumably zeroes, but the text doesn't say.)
      Comment [2008-12-16]:
      • Stephen Farrell's SecDir review had some suggestions for clarification and editorial nits.
      • [IANA] has been obsoleted by RFC 5226.
      • [OSPFV3] has been obsoleted by RFC 5340.
    5. Russ Housley: Discuss [2008-12-12]: Spencer Dawkins raised a few questions in his Gen-ART Review that was posted on 2008-11-05. There was not a response to these questions. Please address these questions.
      The document says: "The 16-bit LLS Data Length field contains the length (in 32-bit words) of the LLS block including the header and payload. Implementations MUST NOT use the Length field in the IP packet header to determine the length of the LLS data block."
      Spencer asked: "I'm not sure this is a 2119 MUST NOT - aren't you just saying that if you try it, you'll fail?"
      The document says: "The CA-TLV MUST only appear once in the the LLS block. Also, when present, this TLV SHOULD be the last TLV in the LLS block."
      Spencer asked: "Why SHOULD and not MUST? At a minimum, I would expect to see some description of what should happen if CA-TLV is NOT the last TLV in the LLS block - and if the expectation is that processing continues, I'm not sure what this sentence means..."
    6. Tim Polk:Discuss [2008-12-17]: Two issues I would like to discuss about LLS. Assuming that these issues need to be addressed, I believe they could be handled in the security considerations.
      1. Since LLS is optional and is not a negotiated capability, there is no way to determine if the OSPF router receiving the OSPF packet is using this information. Section 2 glosses over these complications by stating "changes made due to LLS block TLV's do not affect the basic routing when interacting with non-LLS routers."
        This strikes me as a goal rather than a promise. I think text describing the implications of poorly designed LLS data processing is needed, and provide reasonable guidance for protocol designers that want to use this feature.
      2. I think there is a decent chance that a router will be connected to a router that either doesn't recognize LLS at all or expects different information to be transmitted (routers from a different domain or manfacturer?). Given that, wouldn't it be prudent to recommend that this feature be configurable on a per-interface basis?
      Comment [2008-12-17]: The security considerations section would benefit from a few pointers and a bit more text. I suggest adding the following to the first paragraph:
      Security Considerations inherited from OSPFv2 are described in [OSPFV2].
      I would suggest adding the following to the second paragraph:
      Security considerations inherited from OSPFv3 are described in [OSPFv3] and [OSPFV3AUTH].
    7. Dan Romascanu: Discuss [2008-12-17]:
      1. The IANA considerations section should be expressed in terms of RFC 5226, which replaces RFC 2434 which would have been the correct reference for [IANA]. If I understand correctly the policy for values 0-32767 is intended to be IETF Review, while the policy for values 32768-65536 is Expert Review.
      2. It is not clear to me what Private and Experimental TLVs mean. Will an Expermental TLV be marked in any way, so that routers know that they are dealing with an experiment? I do not understand how this is possible, and unless there is some good reason I suggest to drop Experimental and leave this option for private usage only.
      3. I would suggest some more crisp text that makes clear the criteria for approving TLVs i.e. for the goal of OSPF Link-Local signaling. Unless the intent is to allow for this technique to become a vehicle for transfering arbitrary information, it would be good to make clear that such overloading of the semantics is not permitted.
    8. Mark Townsley: Comment [2008-12-18]:
      2.4. Extended Options TLV: "Bits in the Value field do not have any semantics from the point of view of the LLS mechanism. This field MAY be used to announce some OSPF capabilities that are link-specific. Also, other OSPF extensions MAY allocate bits in the bit vector to perform boolean link-local signaling."
      This field doesn't seem to scope the LLS options to be link-local in nature, which I would think would be a minimum requirement. Further, it seems that the bits are not even restricted to being "Extended Options" given that there is explicit wording allowing the bits to be used as boolean flags.
      I think that at a minimum this needs to be scoped to link-local signaling, and should probably be renamed to "Extended Flags" or some such so that people will not mistake that it is only used for capability option signaling, but also is open for use for any sort of boolean signaling.
      2.1. Options Field: I would rename this section to "L-bit in Options Field" so as not to imply that the Options field is being defined in this document, just that the L bit is.
      2.6. Private TLVs: All other TLVs come with a picture, except this one.
      "The data included in the LLS block attached to a Hello packet MAY be used for dynamic signaling since Hello packets may be sent at any time in time."
      time in time?
    9. Magnus Westerlund: Discuss [2008-12-17]: This document allows for up to 64k big data objects to be added to OSPF messages. This clearly affects the amount of data consumed by OSPF however, this document seems to have no discussion about the potential transport issues that adding arbitrary data objects can cause.
      Fragmentation of OSPF messages. A quick glance in RFC 2328 indicates that there are no built in fragmentation support. The reliance on IP fragmentation have two issues:
      1. how the addition of extra data changes the loss probability for the message due to that a single loss among the fragments results in message delivery failure.
      2. That the potential size of the arbitrary data is not 64k, but actually 64k minus all the other message parts in the OSPF message.
      Then there is the issue of congestion avoidance and transmission rate control. I have now idea how this works in OSPF (please enlighten me), but enlarging the messages clearly have a potential impact on the message transmission behavior and consumed resources that at least needs to be commented on. Are you certain that the existing mechanism is suitable for arbitrary data?
      What reliability are provided for the arbitrary data? It seems that the core messages in OSPF handles reliability in various protocol dependent ways directly related to the message type. It is not at all clear that the arbitrary data object will have the same reliability requirements that the OSPF message it is being sent in. That needs consideration.

    Telechat:

  8. Elliptic Curve Cryptography Subject Public Key Information (Proposed Standard)
    draft-ietf-pkix-ecc-subpubkeyinfo-11.txt
    Token: Pasi Eronen Note: Document shepherd is stefans@microsoft.com
    Extracted from Balloting:
    1. (none)

    Telechat:

  9. Sieve Email Filtering: Ihave Extension (Proposed Standard)
    draft-freed-sieve-ihave-03.txt
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Russ Housley: Comment [2008-12-14]: In the Gen-ART Review by Ben Campbell, he suggested that the last paragraph of Section 4, last paragraph be moved toward the front of the document since it significantly constrains the scope.
    2. Tim Polk:Discuss [2008-12-17]:From Section 4, Ihave Test
      "Ihave is designed to be used with extensions that add tests, actions, comparators, or arguments. It MUST NOT be used with extensions that change the underlying Sieve grammer or extensions like variables [RFC5229] that change how the content of Sieve scripts are interpreted."
      Is this constraint (the MUST NOT) enforced by the sieve implementation, or is this an admonition to script writers? I think the spec needs to be clear about the responsibility for this one...
      If the responsibility lies with the script writer, then the security considerations probably needs to describe the results of using ihave with the wrong classes of sieve extensions.
      Comment [2008-12-17]: This is just a style nit, but I found the capitalization of ihave at the beginning of a sentence rather confusing. I kept mentally converting "Ihave" to "I have" and then would have to convert it back again. Personally, I would stay with "ihave", even when starting a sentence. Just a thought.
    3. Magnus Westerlund: Comment [2008-12-17]: I think it would have been beneficial to include ABNF for how this fits the already existing SIEVE grammar.

    Telechat:

  10. Multi-Protocol Label Switching (MPLS) label stack entry: "EXP" field renamed to "Traffic Class" field (Proposed Standard)
    draft-ietf-mpls-cosfield-def-08.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-12-16]: Section 1.2, paragraph 7: "The EXP field has been renamed to the TC field, and thus all references in RFC 3270 to EXP field SHOULD be taken to refer to the TC field."
      I think the "SHOULD" here needs to be a "MUST" - otherwise it leaves the option of not using the new name. (And I don't believe an RFC2119 term is appropriate here, so it should be a lowercase "must".) Similar phrasings occur in Sections 2.3 and 2.4, and they should be changed accordingly.
    2. Tim Polk: Comment [2008-12-17]: Abstract:
      s/current use of the EXP this field/current use of this field/
      Section 1. Introduction
      s/after the work on the document were started/after the work on the document was started/
      Section 3. Use of the TC field
      s/have different TF fields from the rest/have different TC fields from the rest/

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Message Header Field for Indicating Message Authentication Status (Proposed Standard)
    draft-kucherawy-sender-auth-header-18.txt
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2008-12-18]: Some places that need minor clarifications:
      Section 2.4.2, "pass" bullet: "author domain signature" probably should be "author signature" (the term used in other bullets here, and in ADSP draft iself).
      Section 1: "...are the published e-mail authentication methods in common use" should probably be phrased something like "domain-level e-mail authentication methods (as opposed to user-level authentication mechanisms such as S/MIME and OpenPGP)"
      Section 1.5.2: "...a message which validates is indeed entirely authentic" I think in this context "entirely authentic" could be misleading; if the signature validates, the signed parts of the message (the signature doesn't cover everything) haven't been modified after signing. Whether e.g. the value of the "From" field is entirely authentic depends on the signing practices (and for e.g. signatures added by mailing list exploders, that may vary). I'd suggest rephrasing this to something like "...a message which validates has not been modified after it was signed", or something like that.
    2. Russ Housley: Comment [2008-12-14]: In the Gen-ART Review by Suresh Krishnan, he said that one thing was unclear. He wanted to know how the MUA would convey the results to the user. For example, using the case C.5 from the appendix, what would the user actually see (Success indication, Failure indication, or something else)? Is this field used more as input for filters rather than communicating authentication information to the user? How is the authenticity of the sender established?
    3. Cullen Jennings: Comment [2008-12-17]: I can not find evidence on any IETF mailing list of any consensus to publish this.
    4. Chris Newman: Comment [2008-12-15]: ' "CFWS" is as defined in section 3.2.3 of [MAIL]. '
      I believe that should be section 3.2.2.
    5. Dan Romascanu: Discuss [2008-12-18]: There are three issues in the DNS-DIR review by Peter Koch which I would like to be addressed before I can support the approval of this document.
      1. The draft has issues with terminology, when it again uses 'domain' as a synonym for an organization - even though it goes the laudable approach of re-introducing the term ADMD (which reminds me of X.400, again).
        1.2 says: "This document makes several references to the "trust boundary" of an administrative mail domain (ADMD). Given the diversity among existing mail environments, a precise definition of this term isn't possible."
        Fine, although the relation to X.400 ADMDs might be worth noting to appreciate the historical parallels. The problem I see is that later in the document the term isn't used consistently, but instead "domain" again appears as an acting entity, as in [2.4.3] "none: No policy records were published by the sender's domain".
        There is a fundamental and reoccuring disagreement about the nature of "a domain" between the DNS and the Mail community, which is fine as long as each group is having internal conversation. At the overlap areas we have this issue over and over again and I'd really appreciate if that issue would be wider acknowledged and addressed. This isn't only about wording, but also about implications of hierarchy, administrative boundaries, setting "domain wide" defaults and so on.
        That said, introducing "ADMD" seems to be a good way forward, if it's used consistently and if the distinctions between an ADMD and a (DNS) domain are dealt with properly.
      2. 2. More to the protocol level, the references to DNS error conditions in sections 2.4.3 and 2.4.4 as well as 3 need a bit more thought.
        2.4.4 defines the "iprev" method of "authentication" (which reminds me of our, dnsop's, reverse mapping draft under consideration). I can't tell the difference between
        "softfail: The reverse DNS evaluation failed. In particular, one or both of the "reverse" and forward lookups returned no data (i.e. a DNS reply code of NODATA)."
        and
        "permerror: The reverse DNS evaluation could not be completed due to some error which is unrecoverable (e.g. a DNS reply code of NODATA or NXDOMAIN). A later attempt is unlikely to produce a final result."
        First, there is no real reply code of NODATA (the description is usually NOERROR/NODATA, meaning NOERROR and empty answer section), but it's unclear to me what the author really wants to achieve here.
      3. 3. The description of the "iprev" method in section 3 defers details to RFC 4408, which is an experimental RFC, while the draft under consideration aims at Proposed.
      4. 4. Also, there's the conceptual/terminology issue again: "A successful test using this algorithm constitutes a result of "pass" since the domain in which the client's PTR claims it belongs has confirmed that claim. A failure to match constitutes a "hardfail". "
        It isn't that the match acknowledges the membership in some kind of administrative boundary; it's just a consistency check of some limited value. The whole discussion should take into account the long debate that has taken place in DNSOP regarding the draft-ietf-dnsop-reverse-mapping-considerations draft. This is currently expired, but will be revived and WGLCed "soon".
        Comment [2008-12-18]: Nit: 1.6 has a conflicting expansion of ADMD (s/Mail/Management/).

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. LDP IGP Synchronization (Informational)
    draft-ietf-mpls-ldp-igp-sync-03.txt
    Token: David Ward
    Extracted from Balloting:
    1. Ross Callon: Discuss [2008-12-17]: The authors have indicated that they intend to update the document right after the telechat to respond to Gen-Art and Sec-Dir reviews. I am just holding a "friendly" discuss that I will clear as soon as this update is out.
    2. Pasi Eronen: Comment [2008-12-18]: (empty)
    3. Russ Housley: Comment [2008-12-14]: Please look at the editorial comments in the Gen-ART Review from Francis Dupont.

    Telechat:

  2. OSPFv3 Based Layer 1 VPN Auto-Discovery (Experimental)
    draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt
    Token: David Ward
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-12-18]: I have question about TLV numbering. The L1VPN INFO TLV (RFC 5252 Section 2.2) used type "1", but apparently there's no IANA registry for these numbers. The L1VPN IPv6 INFO TLV (this document) uses type "2". Both the Link TLV in RFC 3630 and the Link TLV in ospfv3-traffic (either of which can be present here) also use type "2".
      Should we renumber the L1VPN IPv6 INFO TLV to "3" and the ospfv3-traffic Link TLV to "4", or somehow clarify how these are parsed?
      Comment [2008-12-18]: Section 2.2, "is either the Router Address TLV or Local interface IP address link sub-TLV" probably should be "is either the Router IPv6 Address TLV or Local Interface IPv6 Address sub-TLV" to match the terminology in ospfv3-traffic-13?
    2. Tim Polk: Comment [2008-12-18]: I support Pasi's discuss. In particular, when more than one L1VPN Info TLV is present, it is unclear to me how to determine if a TE Link TLV is present.
    3. Dan Romascanu: Discuss [2008-12-18]: The document contains no manageability or operational impact information. I would have expected at a minimum that it would mention the impact on network traffic (if any), coexistence and/or migration to version 2, how are the network devices configured ('management directives' are mentioned at one place, but this is too little), how is the discovery information exposed, and if any existing management data base (e.g. MIB module) needs to be created or extended to cover this functonality. If this information or part of it is available in some other document please indicate and provide that document as a reference.

    Telechat:

  3. Urban WSNs Routing Requirements in Low Power and Lossy Networks (Informational)
    draft-ietf-roll-urban-routing-reqs-02.txt
    Token: David Ward
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-12-18]: I support Pasi's Discuss.
    2. Ron Bonica: Comment [2008-12-18]: Also support Pasi's DISCUSS
    3. Pasi Eronen: Discuss [2008-12-18]: I have reviewed draft-ietf-roll-urban-routing-reqs, and I have major architectural concerns with the document.
      In particular, I was surprised to not find any description of the assumed network architecture in this document. I had assumed this would be just another routing protocol for IPv6, but that doesn't seem to be the case (the document doesn't actually say much about the network protocol this routing is for -- it could be something else than IP completely!)
      For example, there are parts (for example, "groupcast") that would seem to imply that the network layer protocol is not IPv6 (or it's either heavily extended, or a new network protocol layer is inserted above the link layer and below IPv6).
      There are also text that suggests that routers are not just network layer elements (that forward packets based on the network layer headers), but also include application layer functionality (that interacts with the network layer and routing in rather unspecified ways). It's not clear whether this is intended to be just co-location of different layers in the same physical box, or largely a non-layered architecture where there is no well-defined separation between the network layer/routing and application level functionality (and parts of applications are essentially merged to the network layer/routing -- so the network layer wouldn't really be IPv6 in any sense, even if the on-the-wire headers looked similar).
      Moving from the overall architecture to security specifically, as noted in Sandra Murphy's SecDir review, the document needs to make a clearer distinction between the security requirements/mechanisms of applications using the urban LLNs, requirements/mechanisms of data forwarding, and requirements/mechanisms for routing (maintaining the state used for data forwarding). Much of the confusion here probably comes from the above-mentioned lack of well-defined layers in the network architecture; in non-layered network architures (e.g. "boxes connected by lines" or "beads on a string") the distinction between applications and network is less clear.
      Since it seems the expected modularization of functionality between layers (and in particular, functionality of the network layer protocol(s) and what "the network" looks like to applications) is somewhat different from normal Internet architecture and IPv6, it seems the WG should start with an architecture document before defining requirements for the routing protocol.
      That could describe at least the high-level view of how functions are modularized (layers or otherwise), how forwarding and addressing work (important for routing -- includes where state is needed, how network resources are allocated, etc.), what entities are named/addressed (e.g. what layer the addresses refer to), and -- perhaps most importantly -- what "the network" looks like to applications running "on top of it" (if it's a layered architecture -- if it's not, that's even more complex).
    4. Russ Housley: Discuss [2008-12-14]: Based on the discussion that has followed the Gen_ART Review by Brian Carpenter, an updated document is needed, and it has not been posted yet.
    5. Cullen Jennings: Comment [2008-12-17]: I'll be a bit surprised to see this have the security and reliability to control traffic lights.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1233 EDT break

1239 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Message Organization (morg)
    Token: Chris

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

  1. Loa: not much to say; one aspect of NAT66

6. Management Issues

  1. Early RFC number assignment for draft-jerichow-msec-mikey-genext-oma (Tim Polk)

    Telechat:

7. Agenda Working Group News

1301 EDT Adjourned