IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2009-06-04. These are not an official record of the meeting.

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

Corrections from: Adrian, Alexey, Russ, Dan, Pasi

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. DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (Proposed Standard)
    draft-ietf-dkim-ssp-10
    Token: Pasi Eronen; Note: Document shepherd is Stephen Farrell (stephen.farrell@cs.tcd.ie)
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-06-02]: In the Gen-ART Review by Miguel Garcia on 2009-05-29, an editorial suggestion is made regarding text that changed in the last revision:
      At the end of Section 4.1, there is now a "Note" (the last one) that includes normative text. The recommendation here is to remove the word "Note" from the last paragraph.
    2. Magnus Westerlund: Discuss [2009-06-01]: Section 4.2.1:
      ABNF: adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP ("unknown" / "all" / "discardable")
      Neither this syntax or Section 5.2 (IANA consideration) specifies what the allowed syntax are for any future extensions. Maybe this should be limited to be only a token? Please clarify what is allowed for ease of handling any extensions in the future.

    Telechat:

  2. Managing Client Initiated Connections in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sip-outbound-19
    Token: Robert Sparks
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-02]: From the Introduction:
      "Most IP phones and personal computers get their network configurations dynamically via a protocol such as DHCP..."
      For the sake of (perhaps foolish) consistency, use the same format "Full Name of Protocol (ACRONYM)" for DHCP, DNS and TLS? And, for completeness and consistency, add an informative reference for DNS (I see Alexey has already suggested a similar ref for DHCP).
    2. Adrian Farrel: Comment [2009-05-31]: Comprehensive and well written.
      Need to decide on "keep alive" or "keep-alive"
      In 4.4.1 [suggested "MUST NOT" instead of "MUST only"...]
      In 4.5 all of these timers may be configurable... [suggested wording]
      There are rather a lot of "SHOULD" uses in the document. Some of these have clauses like "Alternatively, the UA..." which is great. I would prefer for some thought to be given to the other cases where deviation from the SHOULD is allowed.
      The IANA considerations sections seem a tad verbose.
    3. Alexey Melnikov: Comment [2009-05-30]: This is a solid document. I have some comments, which are mostly nits:
      • 1. Introduction: I think this needs an Informative reference to DHCP.
      • 4.1. Instance ID Creation: [are the references correct?]
      • 4.3. Sending Non-REGISTER Requests: You should probably mention that you mean uniformResourceIdentifier subjectAltName value.
      • 9.1. Subscription to configuration package: Missing <"> before the final dot.
      • 10. Grammar: To be pedantic: the rule for "uric" was obsoleted by RFC 3986 (it is mentioned in passing in its Appendix D.2.) There is also "uric" in RFC 3261.
        from the message-header in the [RFC3261] ABNF: I just want to double check this is intentional: you allow for empty value?
      • 11.7. Media Feature Tag: According to RFC 2506, this should be "String (equality relationship)".

    Telechat:

  3. SDP Capability Negotiation (Proposed Standard)
    draft-ietf-mmusic-sdp-capability-negotiation-10
    Token: Cullen Jennings; Note: Proto Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com)
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-03]: Minor editorial point: I think the acronym SDP is overloaded, to mean both Session Description Protocol, and a specific SDP session configuration; for example as in this text from the third paragraph in section 1:
      "This offer SDP is sent to the answerer, [...]"
      Is there another expansion for SDP that could be included in the text to clarify this use of the acronym, or some explanation that could be given about this use of the acronym?
    2. Russ Housley: Discuss [2009-06-02]: The Gen-ART Review by Christian Vogt posted on 24-Oct-2008 has gone unanswerd. The review says that the document is basically ready for publication, but it has minor issues that should be fixed before publication.
      The review says:
      One of the main purposes for differentiating between actual and potential configurations is to express preferences of the offerer: Potential configuration are of higher preference for the offerer than actual configurations. This property does not become sufficiently clear in the introduction and model description at the beginning of the document. On the contrary, a reader may assume the opposite preference order, namely, that actual configuration are preferred because the offerer would have to re-configure in order to use any of the potential configurations. Suggest to clarify the correct prioritization early on in the document.
      Please respond to this review.
    3. Alexey Melnikov: Discuss [2009-06-03]: I would like to vote "Yes" on this document, but I have 3 points (which might or might not result in changes to the document) I would like to discuss first. Note that point 3 needs to be discussed with the rest of IESG.
      1. 3.6.3. Offerer Processing of the Answer
        "When the offerer attempted to use SDP Capability Negotiation in theoffer, the offerer MUST examine the answer for actual use of SDP Capability Negotiation."
        "For each media description where the offerer included a potential configuration attribute ("a=pcfg"), the offerer MUST first examine that media description for the presence of an actual configuration attribute ("a=acfg"). If an actual configuration attribute is not present in a media description, then the offerer MUST process the answer SDP for that media stream per the normal offer/answer rules defined in [RFC3264]. However, if one is found, the offerer MUST instead process the answer as follows: ..."
        What should the offerer do if the answerer response doesn't correspond to one of the potential configurations? If the offerer just process the received response without checking that it matches one of the potential configurations, then maybe this can be used to bypass some policy checks. I think this is an additional security consideration that needs to be discussed in the document.
      2. 9.2. Informative References
        [RFC3261]...
        [ICE]...
        Use of these 2 RFCs seems to be Normative to me. In particular there is a SHOULD about using ICE together with the capability negotiation specified in this draft.
      3. In the Security Considerations section I see a recommendation to use S/MIME for securing SDP payloads in SIP. This advice is not consistent with an advice I was given by RAI Area, stating that S/MIME is not deployable in SIP.

      Comment [2009-06-03]: This is a very detailed document, which I really like. Some comments I have so far:
      3.3.2. Required Capability Negotiation Extensions Attribute
      "[...] A recipient that receives an SDP and does not support one or more of the required extensions listed in a "creq" attribute, MUST NOT "
      I might be confused here. Is this MUST NOT the same as this MUST?:
      "When an SDP recipient does not support one or more required SDP Capability Negotiation extensions listed in the option tags, the recipient MUST proceed as if the SDP Capability Negotiation ..."
      3.5.1. Potential Configuration Attribute: what is the meaning of "attribute capabilities with no transport capabilities"? I.e., is the transport capability required if any configuration list is provided at all?
      3.5.1. Potential Configuration Attribute: Just to confirm: a line like this: "a=pcfg:1 t=4|3 a=1|2" would actually define 4 potential configuration, right?
      3.6.1. Generating the Initial Offer: I think you meant "support for one or more extensions ..."
      3.6.2. Generating the Answer
      "[...] If attribute capabilities are present with a delete-attributes session indication ("-s"), then all session-level attributes from the actual configuration SDP MUST be deleted in accordance with the procedures in Section 3.5.1. If attribute capabilities are present with a delete-attributes media indication ("-m"), then all attributes from the actual configuration SDP inside this media description MUST be deleted. "
      "-ms" is not listed here?
      "[...] If the answerer has exhausted all potential configurations for the media description, without finding a valid one that is also supported, then the answerer MUST process the offered media stream based on the actual configuration plus any session-level attributes added by a valid and supported potential configuration from another media description in the offered SDP."
      This seems overly complicated.
      6.2. New SDP Capability Negotiation Option Tag Registry: It would be useful to mention that this section talks about extensions to "a=pcfg" and "a=acfg".
      "New SDP attributes that are intended to be capabilities for use by the capability negotiation framework..."
      You lost me here.
    4. Tim Polk: Comment [2009-06-04]: Section 5, paragraph 6
      suggest referencing 3.11 as well as 3.1 in the discussion of DOS through inclusion of a large number of offers...
    5. Robert Sparks: Discuss [2009-06-04]:
      1) It's not clear in the normative text (or perhaps I missed it?) that the attributes used for negotiation (a=acap..., or worse, a=creq:cap_v1 for example) are not deleted by the -s and -m delete-attribute indicators. (Most places where they are mentioned currently say something like "deletes all attribute lines").
      2) It's not clear what it would mean to encounter "a=acap:1 acap:2 ptime:30" The spec should call out whether constructs like this should be allowed.
      3) It's not clear whether or not the config-number indicated in a acfg line is chosen by the answerer or if the answerer has to copy that number from some pcfg line in an offer.
      4) In section 3.4.3, if an extension does have an option tag, why isn't IANA registration of it mandatory?
      Comment [2009-06-04]:
      1) Support the suggestion to say "the SDP message" instead of "the SDP" when that's what's meant.
      2) The last paragraph of 3.6.1 has a mixed use of "SHOULD" and "should".
      3) Please double-check the last example (on page 69).
      4) (Very minor) The last paragraph could be misconstrued as permission to "play out garbage".
    6. Magnus Westerlund: Discuss [2009-06-03]: It is great that this is finally being request to be published. However, before allowing it to go forward I have some issues that needs discussion and resolution.
      Section 3.4.1:
      "Conversely, media level attributes can be provided in attribute capabilities at either the media level or session-level. The base SDP Capability Negotiation framework however only defines procedures for use of media-level attribute capabilities at the media level (extensions may define use at the session level)."
      I found this confusing, are there any difference to say that media attributes in attribute capabilities may only be provided at media level? If you are expecting implementations to have a specific support related to this, please express that requirement clearly.
      Section 3.4.1 and Section 3.4.2:
      att-cap-num = 1*DIGIT ;defined in [RFC5234]
      trpr-cap-num = 1*DIGIT ;defined in [RFC5234]
      Why isn't the number of digit limited, the range is limied by the text, please provide a limitation in number of digits also to avoid syntactical correct but resource exhausting attacks.
      Section 3.4.2:
      I fail to find any discussion about the limitation for the tcap attribute with no possibility to specify alternative format strings. That restricts any media lines tcap alternatives to protocols that has coampatible format strings, and where the content of the format string is not changed based on the protocol. This happens to be true for RTP and the profiles defined so far.
      Section 3.5.1:
      config-number = 1*DIGIT ;defined in [RFC5234]
      Also here should the number of digits be limited.
      Section 3.5.1:
      ABNF is in error, no construct | in RFC 5234 ABNF. I think / (slash) is intended here:
      mo-att-cap-list      = mandatory-optional-att-cap-list | 
                                          mandatory-att-cap-list | 
                                             optional-att-cap-list 
      

      I would also note that not having the equal mark on the same line as the rule name like for the "attribute-config-list" prevents it from being a rule.
        attribute-config-list
                              = "a=" [delete-attributes ":"] 
                                       mo-att-cap-list *(BAR mo-att-cap-list) 
      

      Section 3.5.1:
      What about potential configurations without any attributes? And don't forget about the case when one wants to delete the actual configuration attributes but not add any new attributes. That could be the case fore transports that don't need attributes for configuration.
            attribute-config-list = "a=" [delete-attributes ":"] 
                                       mo-att-cap-list *(BAR mo-att-cap-list) 
          
            delete-attributes = DELETE ( "m"    ; media attributes 
                                    / "s"    ; session attributes 
                                    / "ms" ) ; media and session attributes 
      
      
           mo-att-cap-list      = mandatory-optional-att-cap-list | 
                                          mandatory-att-cap-list | 
                                             optional-att-cap-list 
      
            mandatory-optional-att-cap-list  = mandatory-att-cap-list   
                                                   "," optional-att-cap-list 
            mandatory-att-cap-list           = att-cap-list 
            optional-att-cap-list            = "[" att-cap-list "]" 
      

      I think allowing the empty list as a mo-att-cap-list is the simplest solution.
      Section 3.6.1:
      So there is consensus in the WG in killing early media?
      "The above rule assumes that the offerer can determine whether incoming media adheres to the actual configuration offered or one of the potential configurations instead; this may not always be the case. If the offerer wants to ensure he does not play out any garbage, the offerer SHOULD discard all media received before the answer SDP is received. Conversely, if the offerer wants to avoid clipping, he should attempt to play any incoming media as soon as it is received (at the risk of playing out garbage). For further details, please refer to Section 3.9."
      As any combination of AVP in the actual configuration offer and SAVP or SAVPF in the potential configuration may result in garbage due to the SRTP encryption it seems that discarding media will be the norm. I just want to ensure that there is consensus on killing early media, as that has always been a hot potato and requiring support.
      In relation to this I think the following text is ambigous:
      3.9. Processing Media before Answer
      "The offer/answer model requires an offerer to be able to receive media in accordance with the offer prior to receiving the answer. This property is retained with the SDP Capability Negotiation extensions defined here, but only when the actual configuration is selected by the answerer. If a potential configuration is chosen, it is permissible for the offerer to not process any media received before the answer is received. This may lead to clipping."
      Because if the answerer may select a potential configuration that results in an offerer playing back the packets and them resulting in garbage then any mandate which can't be determined by the offerer is plain useless.
      So please clarify if there is a requirement to play early media or a wish which the offerer may do what ever it want with.
      Section 3.10:
      "Also, the Transport Independent Application Specific Maximum (TIAS) bandwidth type defined in [RFC3890] can be used to alleviate bandwidth variability concerns due to different transport protocols."
      Considering that the offer/answer behavior for TIAS is broken, I don't think this should be recommended as a remedy for the issue.
      Section 6.2:
      "The IANA is hereby requested to create a new SDP Capability Negotiation Option Tag registry. An IANA SDP Capability Negotiation option tag registration MUST be documented in an RFC in accordance with the [RFC5226] Specification Required policy."
      This text clearly has an addition to the specification required policy that requires an RFC. I want to confirm that this was intentional. And in that case why not use the "RFC Required" policy, or the IETF Review one. Please note, that I personally think Specification required without the "RFC" requirement being a suitable policy.
      Comment [2009-06-03]:
      section 3.3.1: This construction disallows white spaces between option tags. I think this is likely to fail. Why was spaces disallowed? At a minimum I think the "note" should be strengthen to directly say that white space are not allowed.
      Section 3.4.1: Is the english in the first sentence really clear. Shouldn't it be clearer if the sentence said: When the attribute capability contain a session-level attribute, the "acap" attribute can only be provided at the session level.
      Section 3.5.1: Why isn't the handling of already present attributes in the actual configuration discussed in the overview.
      I would suggest including some overview explanation of how to handle attributes in the actual configuration that are not desired in an alternative one.

    Telechat:

  4. IPv4 Support for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-netlmm-pmip6-ipv4-support-12
    Token: Jari Arkko; Note: Document Shepherd is Vidya Narayanan (vidyan@qualcomm.com); Was deferred by Pasi Eronen on 2009-05-19
    Extracted from Balloting:
    1. Ralph Droms: Discuss [2009-05-19]: From conversations with the authors, a "handoff" is a change of network attachment that is not reported to layer 3 as a loss of link connection. The differentiation between handoff and a change of network attachment that is reported to L3 is important in section 3.4, as a DHCP message exchange is triggered by network reconnection reported to L3.
      The use of 'client identifier' and 'chaddr' in this text from section 3.4 differs from the use of those fields in DHCP servers.
      "A DHCP server identifies the DHCP client and its interface for which the address is assigned from the client identifier and the client hardware address (chaddr) [RFC-2131] fields respectively. A mobile node in a Proxy Mobile IPv6 domain, can attach to the network through multiple interfaces and additionally may perform handoffs between its interfaces. Following are the related considerations:"
      The first issue is that DHCPv4 does not have any concept of multiple interfaces attached to a single host computer. Each address assignment - called a 'binding' (this term should be cited as defined in RFC 2131, to clarify and make distinct from other bindings in this document) - is regarded as independent, even if the addresses are assigned to interfaces on the same host.
      The second issue is that the DHCP server uses the client identifier (if it's available) or the chaddr to identify the entity to which an address is assigned. Therefore, it's not possible to assign addresses as suggested in the following text:
      "If the mobile node attaches to the Proxy Mobile IPv6 domain through multiple interfaces, the DHCP server will uniquely identify each of those interfaces from the client hardware address and will perform address assignment. As the mobile node changes its point of attachment in the network and performs an handoff to a different mobile access gateway, using the same interface, the DHCP server will always be able to identify the binding using the presented client hardware address. The client hardware address and client identifier will remain as the primary keys for each binding, just as how they are unique in a Binding Cache entry.
      Specifically, the client identifier is the identifier for a binding, so there is no concept of using both the client identifier and hardware address as primary keys.
      So, I think I understand what's going on in this first sub-bullet (although the first sentence seems out of place).
      The second sub-bullet, if I undertstand it correctly, is also easy to fix:
      "However, if the mobile node is capable of performing handoff between interfaces, as per [RFC-5213], the client hardware address in such scenarios needs to be an identifier that is not tied to any of those interfaces. The identifier must be a stable identifier which remains the same through out the mobile node's attachment in that Proxy Mobile IPv6 domain. This identifier must remain fixed for a given binding. This identifier in some implementations can be the identifier associated to a virtual interface, that is abstracting the physical interfaces.
      I'm guessing that the idea here is to move the IPv4 address from interface A to interface B when the handoff happens. If I've got that right, then the client needs to use the same client identifier for any subsequent DHCP message exchanges on interface B.
      I'm still not clear about how the use of multiple simultaneous interfaces fits into the model.
      Section 3.4.1 needs some additional detail to describe what happens when the steps 2-4 in Figure 5 occur before step 1. When the DHCP server receives the DHCPDISCOVER message, it needs to check to see if the tunnel is already set up.
      If the tunnel setup is not complete before the DHCP client retransmits the DHCPDISCOVER, the DHCP server needs to ignore the subsequent DHCPDISCOVER messages and wait for the tunnel to be set up.
      Does the DHCP server also get a subnet mask from the LMA? I suggest also adding text to the second bullet after Figure 5 that the default router option in the DHCPOFFER sent to the mobile node be set to the default router from the mobile node's Binding Cache entry.
      Still in section 3.4.1, in the subsection that starts at:
      "IPv4 Home Address Renewal with a different DHCP server (After Handoff):"
      How is the mobile node's default router handled during a handoff? This paragraph implies that the new MAG may have a different address from the old MAG. But, if the new MAG isn't using the mobile node's default router address, how are packets forwarded from the mobile node?
      A better way to handle the case in which nMAG has a different address than oMAG would be for the nMAG DHCP server to ignore the unicast RENEWING DHCPREQUEST messages and respond to the broadcast REBINDING DHCPREQUEST message, which is normal DHCP client behavior for changing DHCP servers.
      I think the error case in which the nMAG "is unable to complete the Proxy Mobile IPv6 signaling or is unable to acquire the same IPv4 address as requested by the mobile node" applies to either case in this subsection.
      In Section 3.4.2, "Initial IPv4 Home Address Assignment:" should the MAG check for an assigned IPv4 home address or the existence of the MAG-LMA tunnel? Or, are those checks equivalent? Is there a reason that the note "the mobile node needs to be identified by the MN-Identifier" appears in this step and not the corresponding step in the process described in section 3.4.1?
      More generally, I think the corresponding first steps, in which the MAG receives a DHCPDISCOVER from the mobile node, in sections 3.4.1 and 3.4.2 are pretty much the same, except for the location of the DHCP server and relay agents. Yet, the text in the two is much different; e.g., 3.4.1 defines "the mobile access gateway MUST NOT enable IPv4 support for the mobile node on that access link" while 3.4.2 defines "the mobile access gateway will discard the DHCPDISCOVER messages from the mobile node" as the behaviors in response to failure to set up the tunnel to the LMA.
      Still in section 3.4.2, subsection "IPv4 Home Address Renewal to the same DHCP server: (No Handover)", in the third bullet, why would the test on the negotiated IPv4 address ever fail and why would the relay agent drop the DHCPREQUEST message?
      I think section 3.4.3 applies in the situation where the mobile node stack L3 has received an indication that network reattachment has happened. It would be clearer to call this event something other than "handoff", which is used in the previous two sections to indicate that L3 was not notified of the change in attachment.
      Comment [2009-05-19]: Is there any impact of lease lengths on the use of DHCP address assignment? If so, guidance would be helpful; if not, explicitly mentioning that lease length doesn't matter would be helpful.
      Nit: s/handover/handoff/ for consistency (I think there is just one occurrence of "handover")
      Nit: s/default-router/default router/ for consistency (both are used in various places in the document)
      In section 3.4.1, is there a sentence fragment or some other kind of typo here:
      "The use of fixed DHCP server address on all DHCP servers...
      In figure 7, deleted "(IPv4HoA)" in step 4.
    2. Pasi Eronen: Discuss [2009-06-04]: I have reviewed draft-ietf-netlmm-pmip6-ipv4-support-12, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document:
      1) When the MN attaches to an access link, how does the MAG determine whether the MN is IPv4-only, IPv6-only, or dual-stack?
      Figure 3.4.1 suggests the MAG would wait until it receives DHCPDISCOVER before sending the PBU -- but if the MN host has e.g. disabled IPv4, the DHCPDISCOVER will never come...?
      While the policy profile might tell whether the user is authorized for IPv4, IPv6, or both, that doesn't necessarily tell what the actual hosts supports -- the user might have changed the configuration, upgraded from XP to Vista, or something.
      2) I had some difficulties in understanding what the text about "subnet mask" means. It seems this specification doesn't support allocating an IPv4 prefix to the MN, only a single address, right? In this situation, draft-ietf-mext-nemo-v4-traversal says that the Prefix-len field in IPv4 Home Address Option is set to 32. But if the MN gets only a single IPv4 (home) address, what does the MAG do with subnet masks?
      3) I was expecting to see some text about MTU and related issues (at least pointers to other documents -- quite obviously, the text in base PMIP6 doesn't work as is here), and perhaps something about the Interface MTU DHCP option. But the draft never mentions MTU at all?
      4) Section 3.4.1 says that when the MN needs to send a DHCP lease renewal, but it has moved to a different MAG, "it is required that the mobile node updates the DHCP server address and uses the address of the DHCP server that is co-located with the new mobile access gateway". How does this happen? Does this require PMIP-specific modifications to the DHCP code?
      5) Section 3.4.3 says DHCPRELEASE "should not release any IPv6 home network prefix(es) assigned to the mobile node". Why isn't this "MUST NOT release..."?
      6) RFC 5213 uses IPsec in a very simple way (much simpler than client Mobile IPv6), and doesn't really require anything Mobile IP specific from the IPsec stack (beyond using MH type as traffic selector). The text in Section 4 isn't very clear on how IPsec would be used (e.g. what the SAD/SPD entries would be?) here, but it seems to assume some unspecified modifications to the IPsec stack (perhaps similar to DSMIPv6, but it's not clear).
      This text needs to be significantly clearer on how the IPsec processing would actually work, and what the SAs (negotiated by e.g. IKEv2) would actually be. I would really prefer if we could keep this simpler than DSMIPv6 (where the IPsec parts are absolutely horrible).
      7) Section 3.3.2: The IPv4 DHCP Support Mode option has number of bits reserved for future use. Should there be an IANA registry?
      8) IANA considerations doesn't mention the IPv4 DHCP Support Mode Option?
    3. Adrian Farrel: Comment [2009-05-20]: I have raised my issues as Comments as they are all editorial. But the volume of issues brings them very close to being bundled together as a Discuss.
      I know that the RFC Editor can sort a lot of this out, and it is no criticism of the authors, but the reviews would be smoother and more likely to focus on technical details if in future you could get someone to take a pass on the English of the document preferably before WG last call.
      Fixing some of the language has the potential to accidentally break the meaning of the text, and you cannot rely on the RFC Editor to understand all of the technical details.
      Section 1
      "It is also reasonable to expect the same mobility infrastructure in the Proxy Mobile IPv6 domain to provide mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode and when the network between the local mobility anchor and the mobile access gateway is an IPv4 or an IPv6 network."
      I can't parse this sentence. I get lost around "and when". Any chance of a rephrase?
      Section 1 bullet 1
      "The mobile node is not required to be allocated or assigned an IPv6 address for enabling IPv4 home address support."
      I think you mean s/for enabling/to enable/ but this is a subtly different meaning.
      Figure 1
      This figure is an orphan! I can't find any text that refers to it and it really needs some explanation. It also uses some acronyms that aren't explained until quite a bit later.
      It *is* good to have a figure early in the I-D, but you can't just plonk it in.
      Section 1.1
      The section title is clear, and the bullet points appear to match the title, but the introduction paragraph:
      "The following are the configuration requirements from the mobility entities in the Proxy Mobile IPv6 domain for supporting the extensions defined in this document."
      talks of configuration requirements and is only relevant to some of the assumptions. Separate assumptions from configuration requirements?
      Figure 2 also uses some acronyms/identifiers that are not explained.
      I don't find the use of "IPv4 default-router" and "IPv4 default-router address" very clear.
      In 1.1 there is
      "The mobile access gateway is the IPv4 default-router for the mobile node on its access link."
      which is clear. But later (3.1.1 etc. and even in 3.3.1)
      "The IPv4 default-router address assigned to the mobile node."
      Can you make this clear throughout the document (search on default-router) whether this is an address assigned to the mobile node (i.e. and address of the mobile node) or the address of the default-router that has been assigned to the mobile node (i.e. the address of the default-router).
      3.3.2
      You might consider creating a registry for bits in the DHCP Support Mode Option.
      The IANA section seems to be deficient in detail and also missing the IPv4 DHCP Support Mode Option. But I see that IANA has an open issue to be addressed by the authors.
    4. Russ Housley: Discuss [2009-05-19]: Spencer Dawkins posted an extensive Gen-ART Review.
      The review has resulted in some additional discussion, which is also in the Gen-ART mail archive. It is pretty clear to me that an update to the Internet-Draft is needed once the discussion converges.
    5. Tim Polk: Comment [2009-06-04]: Paraphrased from Stephen Farrell's secdir review:
      3.1.2.7 says: "when there is not a single Home Network Prefix option with NON_ZERO value present in the request..." That's very hard to interpret and possibly badly ambiguous. "Not a single" could mean zero or >1.
      Perhaps "when there are no Home Network Prefix options with a NON_ZERO value present in the request ..." would be clearer.
      3.1.3 says that the mobility anchor MUST advertise a connected route but doesn't say how. Perhaps a reference is in order here?
      section 7: s/news/new/
    6. Dan Romascanu: Comment [2009-06-04]: The OPSA-DIR review included a number of editorial comments. None of them is a show stopper, but incase the document goes though a revision for other reasons I suggest that they are considered.

    Telechat:

  5. GSS-API Extension for Storing Delegated Credentials (Proposed Standard)
    draft-ietf-kitten-gssapi-store-cred-04
    Token: Tim Polk; Note: Alexey Melnikov is the document shepherd
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-06-04]: I believe these two text excerpts are in contradiction:
      "default_cred BOOLEAN -- if TRUE make the stored credential available as the default credential (for acquisition with GSS_C_NO_NAME as the desired name or for use as GSS_C_NO_CREDENTIAL)"
      "Finally, if the current credential store has no default credential (that is, no credential that could be acquired for GSS_C_NO_NAME) or if the default_cred input argument is TRUE, and the input credential can be successfully stored, then the input credential will be available for acquisition with GSS_C_NO_NAME"
    2. Adrian Farrel: Discuss [2009-06-04]: Nice, easy-to-read drat. Thanks.
      Are you sure that this document shouldn't be marked as updating 2743 and/or 2744?
    3. Russ Housley: Comment [2009-06-02]: In the Gen-ART Review by Elwyn Davies on 23-May-2009, two minor points are raised:
      1. The whole sequence of GSS-API standards does not define the type names (whether generic e.g., INTEGER or specific e.g., CREDENTIAL HANDLE) used in the pseudo-code definitions of the APIs.
      2. It is fairly obvious but it would be worth a phrase indicating that the error codes, etc come from RFC 2743 and the C type names come from RFC 2744.

    Telechat:

  6. Generic Security Service API Version 2 : Java Bindings Update (Proposed Standard)
    draft-ietf-kitten-rfc2853bis-05
    Token: Tim Polk
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2009-06-03]: I'd like to discuss these two items on the call and expect to clear after they have been clarified:
      The numbers associated with the GSS Status Codes in Section 5.12.1 are different than they were in RFC2853 - does this create incompatibilities?
      The document contains various snippets of example (C++?) code, but no code license.
    2. Adrian Farrel: Discuss [2009-06-03]: The document should be marked "Obsoletes RFC 2853"
      The Abstract makes that statement clearly (good), but there is nothing in the Introduction.
    3. Russ Housley: Comment [2009-06-02]:
      Please consider the places where "service@host" is used in examples. It would be better to use the domain names in RFC 2606 in examples.
      The Gen-ART Review by Gonzalo Camarillo on 2-Jun-2009 included a few comments that shoule be considered:
      In general, Abstracts should not contain references. While referencing RFC 2853 to explain that this document obsoletes it is probably OK, I would remove the rest of the references from the Abstract.
      The naming of the references is not consistent. Some of them are named [RFCxxxx] but not all of them.
      In Section 4, a ':' to introduce the definition of each optional service would probably make the text clearer (e.g., Mutual Authentication: in addition...)
      The word "Section" should be capitalized when referring to a specific section (e.g., in Section 8).
      The ID nits tool makes a few observations about boilerplates. The authors should make sure that the boilerplates in the draft are okay.
    4. Dan Romascanu: (blank)

    Telechat:

  7. RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update (Proposed Standard)
    draft-ietf-dkim-rfc4871-errata-05
    Token: Pasi Eronen
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-06-04]: Can the indentation of the various pieces of ABNF be fixed? I'd hate anyone to submit an errata against this RFC...
      Personally, I would have been much happier to see this as a full document obsoleting the original RFC. I realize people sometimes fear such an action when other issues and redesign might be done as soon as a document is "opened". But there is no reason for that, and I think we have a responsibility to the readers of our RFCs to produce clear, up-to-date specs, and not a patchwork of erratas.
    2. Ralph Droms: Comment [2009-06-02]: Generally, +1 to the request for clarity about section 4-8 adding new sections to RFC 4871.
      I'm also looking forward to discussion of relative merits of revising RFC 4871 and publishing this doc as a new RFC.
      Really minor nit: is there any significance to the different indentation styles used throughout the doc?
      9. RFC4871 Section 3.5 The DKIM-Signature Header Field
      ...what is the "This" in "This is the domain..."? The domain identified by the SDID?
    3. Lars Eggert: Comment [2009-06-03]: I don't understand what the advantage of an "errata RFC" is over the normal collection RFC Editor erratas. (I mean, I expect Alfred within days to file an errata on this errata RFC...)
      If a new RFC is desired, I'd much rather see a comprehensive update that would obsolete 4821.
    4. Adrian Farrel: Discuss [2009-05-31]: A nice simple, easy-to-fix Discuss.
      Sections 4 through 8 make references to sections 2.7 through 2.11 of RFC 4871. But those sections do not exist in RFC 4871.
      Could you make it clearer that, as well as this text being "Additional text.", you are defining "Additional Section."
      Similarly in your section 12 about a new section 3.9.
      There are several Errata filed at http://www.rfc-editor.org A number of these have been Verified. Why are these not addressed at the same time?
      Comment [2009-05-31]: This comment is perilously close to a Discuss!
      I agree with Alexey that I would have prefered a revision of 4871. I assume that the WG and advising ADs have discussed this and have a Good Reason (TM) for not revising an RFC. To me, however, it is non-intuitive why we would create a second normative RFC when a single one could be constructed.
      In particular, I am uncomfortable with an update to the Abstract of another RFC.
    5. Cullen Jennings: Comment [2009-06-04]: I asked three implementors to have a look at this and let me know what changes might be needed to an 4871 implementation to make the code complaint with this errata. They all told me this document was completely incomprehensible and they have no idea what needs to change.
      I suspect this draft says anything more than "you MUST have a (d=) and you MAY have (i=)", but I have missed it.
    6. Alexey Melnikov: Comment [2009-05-29]: I wish you have done a revision of RFC 4871. But I trust this was discussed in the WG.
      In Section 9:
      Indentation is wrong (not a big deal).
      I also suggest you reference RFC 5321 in the comment above.
      In Section 12:
      "INFORMATIVE DISCUSSION: This document does not require the value of the SDID or AUID to match the identity in any message header fields. This is considered to be an assessor policy issue. Constraints between the value of the SDID or AUID and other identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author."
      I've reread the last quoted sentence 4 times and still don't know what it means. Is any word missing? Or maybe this sentence can be split into multiple?
    7. Tim Polk: Discuss [2009-06-04]: This is a discuss for ADs only and is not being forwarded to the chairs or authors.
      Like many others, I find the format of this document less useful than republishing 4871 with the changes. However, I understand the reasons people prefer to process them this way.
      Is there any reason we can't direct the RFC Editor to make the noted changes to the text in 4871 and republish the whole document? (Okay, I can think of one - the boilerplate. Any others?)
      Comment [2009-06-04]: (blank)
    8. Dan Romascanu: Comment [2009-06-03]: I support Adrian's DISCUSS and COMMENT.

    Telechat:

  8. DNS Proxy Implementation Guidelines (BCP)
    draft-ietf-dnsext-dnsproxy-05
    Token: Ralph Droms
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-06-04]: This a long-overdue and very good document. Thanks!
      However, I would like to talk about the strength of the recommendations. We've already talked TCP, but there's another case as well -- flags in Section 4.1, and how it affect EDNS0.
      I believe both this and the TCP case actually warrant a MUST statement. My argument for the appropriateness of a Discuss is as follows.
      First, the IETF specification should not just be a representation of the minimal functionality that vendors appear to implement; it should be the right functionality that is required to get the job done. While I think there is some chance of a MUST being ignored, I think the overall effect of saying MUST would be that more devices would support the functionality than otherwise.
      Second, without this MUST some functionality does break (as evidenced by Lars's home gateway example). The DNS proxy is not alone, what it does affects severely also on the clients and DNS servers.
    2. Lars Eggert: Discuss [2009-06-04]: (I'm temporarily updating this part of my original comment to a Discuss, to make sure we talk about this on the call. I expect to go back to a Yes afterwards.)
      Section 6.1.3.2, paragraph 1:
      "DNS proxies SHOULD therefore be prepared to receive and forward queries over TCP."
      Shouldn't this be a MUST? Under which conditions is it OK to not do TCP?
      Comment [2009-06-03]: Great document overall. Two minor comments:
      Section 1., paragraph 3:
      "Note that to ensure full DNS protocol interoperability it is preferred that client stub resolvers should communicate directly with full-feature upstream recursive resolvers wherever possible."
      An uppercase SHOULD may be appropriate here to stress that direct communication is preferred.
      Section 6.1.3.2, paragraph 1:
      "DNS proxies SHOULD therefore be prepared to receive and forward queries over TCP."
      Shouldn't this be a MUST? Under which conditions is it OK to not do TCP?
    3. Pasi Eronen: Comment [2009-06-04]: I support Lars's discuss -- we know that lack of TCP support in broadband gateways (etc.) is already causing problems (when zones deploy DNSSEC), and we're expecting DNSSEC to become more widely used, not less. TCP might have been an optional capability in RFC 1123 (20 years ago), but it is required today.
    4. Adrian Farrel: Comment [2009-06-03]: Easy to read and helpful document. Thanks.
      Just a small 2119 issue that you should look at along the way.
      Section 4.1
      "Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown DNS flags and proxy those packets as usual."
      I think this is slightly tautological.
      Change to one of...
      - Therefore it is RECOMMENDED that proxies ignore any unknown DNS flags and proxy those packets as usual.
      ...or...
      - Therefore proxies SHOULD ignore any unknown DNS flags and proxy those packets as usual.
      However, subsequent sections use "MUST" to ensure that transparency is achieved, so I'd like to understand why you use "SHOULD". Is it because you do not want to pronounce existing implementations as non-conformant? The use of "SHOULD" begs the question of under what circumstances an implementation MAY drop the packets and what they MUST do when they do that.
      This pops up again in 4.4.2.
    5. Tim Polk: Comment [2009-06-04]: (blank)
    6. Dan Romascanu: Comment [2009-06-04]: I support Lars's DISCUSS.
    7. Robert Sparks: Comment [2009-06-03]:
      1) I had the same question as Lars (in the section on TCP Transport) - why does the document say proxies SHOULD be prepared to forward queries over TCP instead of MUST?
      2) At the bottom of page 10, the document recommends responding to malformed requests rather than dropping them to avoid retransmissions of the request. In circumstances where there would be enough traffic for this to make a difference, would it also be useful to discuss the alternative of dropping packets if an attacker is (perhaps statelessly) sending a large number of malformed packets just to consume the processor?

    Telechat:

  9. Extended Generic Security Service Mechanism Inquiry APIs (Proposed Standard)
    draft-ietf-kitten-extended-mech-inquiry-06
    IPR: Statement
    Token: Tim Polk
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-06-04]: Reduced from Discuss
      In section 3.4.6
      "Note that there is a bug in the C bindings of the GSS-APIv2u1 [RFC2744] in that the C 'const' attribute is applied to types which are pointer typedefs. This is a bug because this declares that the pointer argument is 'const' rather than that the object pointed by it is const. To avoid this error we hereby define new typdefs which include const properly:"
      What action is being taken about the bug in RFC 2744? - Shouldn't an Erratum be raised and approved?

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Internet Mail Architecture (Proposed Standard)
    draft-crocker-email-arch-13
    Token: Alexey Melnikov; Note: Tony Hansen is document shepherd
    Extracted from Balloting:
    1. Ron Bonica: Comment [2009-06-03]: I am voting "YES" on this document because I think that it provides an excellent exposition on a very important topic. However. I have a few comments:
      - I share Tim's question about why it is PS as opposed to INFORMATIONAL
      - Section 1.2 borders on philosophical musing. I wonder if the document wouldn't be improved by its omission
      - Indentation broken above figure in section 2.2
    2. Ralph Droms: Comment [2009-06-03]: This document is excellent - informative, well-organized, readable.
      I'm conflicted about whether to publish the document as Standards Track or Informational.
      One specific concern is that there are just a few (fewer than 10, if I searched correctly) occurrences of RFC 2119 requirements language. Why are those few instances sufficiently important to be included in this doc? Do those uses of RFC 2119 language establish new behavior or do they reflect requirements from other RFCs. If the latter, why not cite those RFCs rather than including the requirements language in this doc? If there are new requirements in this doc, will implementors know to look through the entire doc to find and implement those requirements?
      My preference would be publication as Informational, with replacement of any RFC 2119 requirements with pointers to the RFCs in which those requirements are established.
      Editorial nits: In section 2.2, I don't think this text should be centered:
      "Figure 3 shows the relationships among transfer participants in..."
      In section 3.1, where are "<addr-spec>" and "<local-part>" defined? Really tiny nit (which I'm almost embarrassed to mention) - "local-part" appears in the index while "addr-spec" does not.
      Section 4 (page 23) - another centering problem?
      This figure shows function modules and the standardized protocols used between them.
    3. Adrian Farrel: Comment [2009-05-31]: This is a really helpful document. I'm glad it has been written.
      I would be more comfortable with this I-D as Informational. As the Absatract points out, the document provides a description of the current architecture. But I can't get up enough steam on the topic to Discuss it.
      It would have been better if the I-D had passed idnits cleanly before submission for review. Most of the nits are simply fixed (by the authors or the RFC Editor).
      But looking at idnits would reveal the existence of a downref. I don't see any reference to a downref in the last call announcement in the data tracker. Was it flagged, or did it get lost in the change from Info to Std Track? Surely another reason to stay on the Std Track.
      I would suggest that it is not necessary to use 2119 language in this document since it describes how things are. The I-D does not need to make proscriptive statements as those are already made in the referenced RFCs. Instead, the I-D can say "as defined in [RFCxxx] the MUA must blah-blah"
      Not sure that the index is necessary. It certainly hints at a bunch of extra work for the RFC Editor.
    4. Cullen Jennings: Comment [2009-06-04]: This should be informational.
      On the call today, I would like to make sure that I understand what is to happen with the PDF version of the draft.
    5. Tim Polk: Discuss [2009-06-03]: I am marking this as a DISCUSS to ensure it is discussed on the call. I will move to No Objection on the call regardless of how this is decided.
      I believe that this document should be an Informational RFC. A variety of reasons for standards track or BCP have been raised, but I did not find them very compelling. I would like to hear from ADs that support PS or BCP regarding their rationale...
      Comment [2009-06-03]: Figure 2 is never referenced in the text.
      Figure 2/Section 2.1.3
      The Return Handler does not appear in the figure, and the text in 2.1.3 does not provide any rationale or connecting text. While it would unduly complicate the figure, it might be nice to close the loop in section 2.1.3.
      Section 2.2.4 Receiver
      I thought that the Receiver would operate "with dual allegiance" just as the Originator does (see section 2.2.1), but the brief text in 2.2.4 does not make any references to the ADMD. Doesn't the Receiver represent the local operator of the MHS regarding incoming message, just as the originator represents the local operator of the MHS regarding outgoing messages?

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) (Experimental)
    draft-ietf-webdav-bind-24
    Token: Alexey Melnikov; Note: Cyrus Daboo (cyrus at daboo dot name) is the document shepherd; This is an individual submission despite the draft name, at the WebDAV WG has closed
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-03]: Comment has been resolved...
      I don't understand the example in section 2.3.2. How would the COPY operation update any bindings and affect the contents of R3? If I understand the semantics as described in section 9.8.4 of RFC 4918, the result of the copy would result in deletion of the bindings in C2 to Resource C3, the deletion of C2, creation of a new C1 in CollY containing bindings x.gif and y.gif to new resources R1' and R2'.
    2. Adrian Farrel: Comment [2009-06-03]: Teenie nit...
      Section 14
      "and other members of the WebDAV working group."
      But there is no WG. Say...
      "and other subscribers to the WebDAV mailing list."
    3. Cullen Jennings: Discuss [2009-06-04]: I think we need to talk about what consensus means in the context of this document. This is not a WG document the WG was closed. One of the reasons the WG was closed was that it could not come to consensus on this document.
      This document makes significant normative changes to a PS document that did reach WG consensus. I don't recall the WG every reaching consensus to make the change in Appendix A.
      I would also like to discuss when ex chairs of old WG should recuse on a document. I have not yet decided if I need to recuse on this one or not and I'm looking for advice on that.
      The Last Call was too short and claimed it was a WG draft.
      We need to talk about how to proceed here.
    4. Tim Polk: Comment [2009-06-04]: The Security Considerations section has a textual reference to the considerations for HTTP/1.1 and WebDAV, but does not indicate which RFCs contain those considerations. It would be helpful to readers if there were explicit references added for 2616, 3744 and 4918 at that point in the text.
    5. Robert Sparks: Discuss [2009-06-03]: I have one issue to discuss with the IESG before progressing this document.
      The intended status for this document is Experimental, but it is updating an existing P.S. RFC. Is this the right way to capture this update?
      Comment [2009-06-03]: The document provides some discussion of the ramifications of simple loops, but it's not immediately obvious that the recommendations for handling them are sufficient for dealing with more complex loops. Are there additional issues introduced when each added level of depth adds an exponentially growing number of elements?

    Telechat:

  2. Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) (Informational)
    draft-ietf-smime-3278bis-08
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43... IPR1004, IPR1153, IPR1154
    Token: Tim Polk
    Extracted from Balloting:
    1. Alexey Melnikov: Comment [2009-06-03]:
      3.1.1. Fields of KeyAgreeRecipientInfo
      "When using ephemeral-static ECDH with EnvelopedData, the fields of KeyAgreeRecipientInfo are as follows:
      "- version MUST be 3.
      "- originator MUST be the alternative originatorKey. The originatorKey algorithm field MUST contain the id-ecPublicKey object identifier (see Section 7.1.2). The parameters associated with id-ecPublicKey MUST be absent, ECParameters, or NULL. The parameters associated with id-ecPublicKey SHOULD be absent or ECParameters, and NULL is allowed to support legacy implementations."
      I can't parse the last 2 sentences. I think some words are missing.
      Similar problem in the Section 3.2.1.

    Telechat:

  3. The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP (Informational)
    draft-ietf-avt-seed-srtp-11
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-06-04]: IANA considerations have to be fixed, as other ADs have already noted.
    2. Pasi Eronen: Discuss [2009-06-03]: I have reviewed draft-ietf-avt-seed-srtp-11, and I have one concern that I'd like to discuss before recommending approval of the document:
      Section 2.3 does not actually say what the authentication tag length is for GCM mode, but the example in Appendix A.3 suggests it would be 80 bits. However, this length is not allowed by the GCM spec (800-38D). The easiest way to fix this would be to change this to 96 bits.
    3. Russ Housley: Comment [2009-06-03]: I agree with the DISCUSS ballot position already provided by Alexey. In particular, Section 5 must be clarified. The SEED algorithm is not mandatory-to-implement for all RTP implementations. However, an RTP implementation that supports SEED, it must implement the modes listed in Section 5.
    4. Alexey Melnikov: Discuss [2009-05-24]:
      5. Default and mandatory-to-implement Transforms
      The default transforms also are mandatory-to-implement transforms in SRTP. Of course, "mandatory-to-implement" means conformance to the specification.
                              man.-to-impl.      optional        default 
      
         encryption            SEED-CTR      SEED-CCM,SEED-GCM   SEED-CTR 
         message integrity     HMAC-SHA1     SEED-CCM,SEED-GCM   HMAC-SHA1 
         key derivation (PRF)  SEED-CTR              -           SEED-CTR
      

      It is not clear if this section is supposed to replace Section 5 of RFC 3711, or whether it just extends it. Please clarify.
      Table 1: Mandatory-to-implement, optional and default transforms in SRTP and SRTCP.
      I also need to discuss the following with the rest of IESG and/or authors before deciding whether I should clear this part of my DISCUSS or update it:
      7. IANA Considerations
      "This document has no actions for IANA."
      This looks wrong. I was trying to find in RFC 3711 where cipher/authentication mode identifiers are transported in SRTP and couldn't find anything apart from statements like:
      4. Pre-Defined Cryptographic Transforms
      "While there are numerous encryption and message authentication algorithms that can be used in SRTP, below we define default algorithms in order to avoid the complexity of specifying the encodings for the signaling of algorithm and parameter identifiers."
      which made me wonder if the list of ciphers is hardcoded somewhere. Please help me find where cipher identifiers are described.
    5. Tim Polk: Discuss [2009-06-04]: This expands upon Pasi's discuss...
      Unlike section 2.2 (CCM), section 2.3 does not discuss the parameters for SEED-GCM. GCM requires specification of the authentication tag length, usually denoted t.
      Since 2.3 is silent, the assumption is that the 80 bit default specified in 2.1 for counter or 2.2 for SEED-CCM would apply. However, this violates the constraints specified in the GCM base spec.
      From SP 800 38D:
      "The bit length of the tag, denoted t, is a security parameter, as discussed in Appendix B. In general, t may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, t may be 64 or 32; guidance for the use of these two tag lengths, including requirements on the length of the input data and the lifetime of the key in these cases, is given in Appendix C."
      I would strongly suggest specifying 96 bits as the default for t (larger values do not appear to be needed; selection of a smaller value would be insecure imho).
      Comment [2009-06-04]: (blank)
    6. Magnus Westerlund: Comment [2009-06-01]:
      I would like to support Alexey's Discuss regarding IANA registration. It seems to me to be an unnecessary complexity to define the algorithm in one place and not register the necessary identifiers with the key-management. Sure SRTP has several keying mechanisms. However, this question should be well thought through as there may be issues down the road in publishing this as informational status.
      From RFC 4568: 10.3.2.1. SRTP Crypto Suite Registry and Registration
      "The IANA has created a new subregistry for SRTP crypto suites under the SRTP transport of the SDP Security Descriptions. An IANA SRTP crypto suite registration MUST indicate the crypto suite name in accordance with the grammar for srtp-crypto-suite-ext defined in Section 9.2.
      "The semantics of the SRTP crypto suite MUST be described in an RFC in accordance with the RFC 2434 Standards Action, including the semantics of the "inline" key-method and any special semantics of parameters."
      This may be a qualified downref for a future standards track document to register the crypto suit identifiers. But it should be considered now.

    Telechat:

  4. Implications of 'retransmission-allowed' for SIP Location Conveyance (Informational)
    draft-ietf-geopriv-sip-lo-retransmission-02
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Alexey Melnikov: Comment [2009-05-31]:
      1. Introduction
      "[...] The Session Initiation Protocol [RFC3261] is one proposed UsingProtocol for PIDF-LO."
      This sentence doesn't read well.
      2. Problem Statement
      "[...] Bear in mind, however, that <retransmission-allowed> is not intended to provide any protocol-level mechanism to prevent unauthorized parties from learning location through means like eavesdropping. It is merely a way to express the preferences of the Rule Maker to the LR.
      LR is not defined. I think it should be defined after introducing Location Recipient in the previous paragraph of the same section.
      The same comment about first use of LS later in the same section.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. UA-Driven Privacy Mechanism for SIP (Informational)
    draft-ietf-sip-ua-privacy-08
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2009-05-26]: The example in Section 5.1.2 should probably use "example.com" (or "atlanta.example.com") instead of a real domain name.
    2. Alexey Melnikov: Comment [2009-06-02]: (blank)

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. Unintended Consequence of two NAT deployments with Overlapping Address Space (Informational)
    draft-ford-behave-top-06
    IPR: Statement
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-02]: I'm confused by the example in section 3.2.4. Does the example discuss hijacking inbound mail, outbound mail or IMAP/POP access?
      Does this sentence from the second paragraph in 3.2.4 refer to NAT-2 in figure 1.1:
      "Ideally, ISPs should not use NAT devices to provide connectivity to their customers."
      LSNs (large scale NATs) seem to be an inevitable example of deployments like NAT-2. Perhaps section 3.2.4 could be expanded to explain how NAT-2 and NAT-3 would be configured to accommodate inbound mail to a mail server on Host G?
    2. Cullen Jennings: Discuss [2009-06-03]: I think document is confused about how two different interfaces can have the same IP and how that works. The advice about split VPN goes strongly against what the RAI area generally recommends. The advice about blocking IP that mach the IP of of the access router is really bad and goes against what pretty much every VPN product I could find to test actually does. I would like to talk on the call about if this draft is harmful for VPN deployments and if it should be DNP.

    Telechat:

3.3.2 Returning Items

  1. (none)

1325 EDT break

1328 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Behavior Engineering for Hindrance Avoidance (behave)
    Token: Magnus

    Telechat:

  2. Geographic Location/Privacy (geopriv)
    Token: Cullen

    Telechat:

  3. Point-to-Point Protocol Extensions (pppext)
    Token: Jari

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

  1. DaveO: sent note to IESG list; Jon Peterson appointed as liaison to NomCom; "harmful" draft ready to go; Department of Commerce ongoing; Tech Chat on RPKI (Randy Bush), getting close, working on trust anchor and who makes changes

6. Management Issues

  1. IESG Requirements to NomCom (Russ Housley)

    Telechat:

  2. Review of application/mp21 Media Type (Alexey Melnikov)

    Telechat:

  3. Review of application/3gpp-ims+xml Media Type (Alexey Melnikov)

    Telechat:

  4. RFC 4543 IANA allocations for IKEv1 (Pasi Eronen)

    Telechat:

  5. Webex use for IESG Telechats (Russ Housley)

    Telechat:

  6. BSD license for BNF formal definitions (Adrian)

    Telechat:

7. Agenda Working Group News

1428 EDT Adjourned