IESG Narrative Minutes

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

Narrative scribe: Barry Leiba and John Leslie (The scribe was sometimes uncertain who was speaking.)

Corrections from:

1 Administrivia

  1. Roll Call 1134 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 Submissions

2.1.1 New Items

  1. RBridges: Adjacency (Proposed Standard)
    draft-ietf-trill-adj-06
    Token: Ralph Droms
    Note: Erik Nordmark (nordmark@acm.org) is the document shepherd.
    Discusses/comments (from ballot 3794):
    1. Jari Arkko: Discuss [2011-04-28]:
      I must be missing something obvious, but I thought that the following statement in the draft was odd:
      "Layer 3 packets are already "tamed" when they are originated by an end station: they include a hop count and layer 3 source and destination addresses. Furthermore, there is no requirement to preserve their outer layer 2 addressing and, at least for unicast packets, they are addressed to their first hop router."
      First of all, not all IP packets have a real layer 3 source address. The unspecified address may be used in, say, ND packets. Secondly, preserving layer 2 addresses does seem to be important, at least if we expect ND and SLLA options to work. Can you clarify what you really meant with the above?
    2. Jari Arkko: Comment [2011-04-28]:
      The state machines are given as (event,state) => (new state) tuples. I'm kind of missing the action part, presumably there are events that cause an action to be taken. Why is not the (event,state) => (action, new state) model not used here?
    3. Russ Housley: Comment [2011-04-27]:
      Please consider the editorial comments from the Gen-ART Review by Pete McCann on 23-Apr-2011.
    4. Sean Turner: Comment [2011-04-27]:
      I went and looked at what's holding up publishing RFCtrill and it's this document. If -adj is updating RFCtrill wouldn't it be better to roll this on in to the base as opposed to having RFC XXXX be updated by RFC XXXX+2? I know it happens, but I'm just saying...
      If two do get published, is there a plan to later combine the two?

    Telechat:

  2. Best Current Practice for Communications Services in support of Emergency Calling (BCP)
    draft-ietf-ecrit-phonebcp-17
    Token: Robert Sparks
    Note: Marc Linsner (mlinsner@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3186):
    1. Jari Arkko: Discuss [2011-04-28]:
      I hate to pile on the comments that were already made by others, but I think the document places unreasonable mandatory requirements on access networks, often without much actual current practice in the world for doing so. Some examples..
    2. Ron Bonica: Comment [2011-04-27]:
      Support most of the discuss positions posted
    3. Stephen Farrell: Discuss [2011-04-26]:
      (1) Is this stating requirements (if so for whom) or documenting BCP based on *current* implementations and deployments? That's not clear to me and I think it ought be clear for a BCP.
      (2) ED-1 has a SHOULD requirement for when its ok to not support emergency calls. Saying its driven by user expectation seems vague and not that easy for a developer to handle. I can see how this could be hard, but I do wonder if there's not a more objective criterion that could be stated.
      (3) ED-48 has MUST for IPsec or TLS. ED-62 says that if the TLS handshake fails then location retrieval MUST be retried. What if IPsec SA establishment fails? (Would the UA know?)
      (4) I think the overall use of TLS and IPsec maybe needs to be restated perhaps along the lines of "Do try to use TLS, but if the handshake fails, then for emergency calls only, its ok to do everything in clear."
      (5) I'm not sure that you even want to mention IPsec here, other than to say that an emergency call might require a UA to break some IPsec policy rule. (E.g. if the IPsec policy is that all traffic be routed to a VPN g/w.) I may have missed where that is stated - is that there somewhere or what's the BCP for that case?
    4. Stephen Farrell: Comment [2011-04-26]:
      (1) Abstract could make it clear if this doc just addresses BCP for IETF docs or also for others as well, and if others are included which SDOs?
      (2) Is ietf-ecrit-framework required reading or not? Make it clear.
      (3) 6.1 mentions not changing the determination mechanism but that's only introduced in 6.2. Add a forward reference.
      (4) LCP is used without expansion
      (5) s/IPSEC/IPsec/
    5. Russ Housley: Discuss [2011-04-21]:
      The Gen-ART Review by Miguel Garcia on 20-Feb-2011 lead to a discussion, but that discussion has not reached closure yet. That discussion needs to reach a conclusion to determine what changes, if any, are needed to the document.
    6. Pete Resnick: Discuss [2011-04-24]:
      Some of these might turn out to be comments rather than discussions:
      AN-5 and AN-10 seem to conflict. Can you not do network measured location *instead of* hard-wired location configuration and still not require end system measured location?
      I'm not clear on AN-13/INT-14. If a proxy is providing the location, and the network is providing, e.g., hard-wired location configuration, why would DHCP or HELD ever be involved? And does this have anything to do with ED-24?
      ED-25-27/INT-19-21. If the endpoint measures or has manual configuration for its location, it still "SHOULD obtain...after local network config" and "MUST include [DHCP] options for location acquisition"? That doesn't seem correct.
      ED-59/SP-31 and ED-62/AN-29: There's clearly a security consideration here, but the Security Considerations section is empty except for pointers to two documents which do not address the security consideration of the downgrade.
      Section 12 reads like a big security hole without any attempt at solution. Once a call is established, shouldn't some sort of security token be exchanged so that callback can occur securely if necessary?
      The rest of this is for the IESG and need not be addressed by the WG. I will move it to a non-blocking comment if all of the rest of the above comments are cleared.
      ---
      I am very concerned that this document is being put forward as a BCP *and* is using 2119 language when it is really serving as a conformance statement for other SDOs. On the one hand, it could be seen as an applicability statement for implementers of the protocols, expressing what they need to account for in the use of those protocols. But if it's an AS, then it should be standards track, as reviewing the interoperation of actual implementations is a reasonable thing, and BCP is not inappropriate. However, there is no expectation that there is going to be review of the AS from an interoperability point of view because it really become a set of conformance requirements imposed by external bodies. So if interoperability is not going to be checked, the 2119 language is inappropriate in the first place.
      But even if the WG wanted to make this a standards track AS, the 2119 language in here is *way* outside of the scope of 2119. To pick an example right off the top:
      4. Which devices and services should support emergency calls:
      "ED-1 A device or application SHOULD support emergency calling if a user could reasonably expect to be able to place a call for help with the device. Some jurisdictions have regulations governing this."
      I don't see how the interoperability of that SHOULD could possibly be tested from an interoperability perspective, which is what 2119 requires for the use of the keyword. In other places, 2119 language is used reasonably (e.g., "It is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location..."), but it's a big mixture.
      I think this document should either be informational (without 2119 language at all) or a standards track AS (with sane 2119 language). But this is important work and the working group made a conscious decision (with AD approval) to go forward this way. I'm therefore not willing to hold up this document based on this process issue. But the IESG really needs to discuss and fix this problem for the future.
    7. Pete Resnick: Comment [2011-04-21]:
      Editorial: Weird use of the term "element". It's non-obvious to me. I might have used "entity". Maybe it's understood in this environment.
      ED-3 looks like it should be ED/SP statement. I assume that anyone who reads the second sentence understands why location of the device has anything to do with recognizing dial strings; I sorta can figure it out, but not my area. I don't understand what "could" implies in the second sentence.
      Editorial: The term "UA" magically appears in 6.9 and is used elsewhere as well. Is that an "endpoint"?
      ED-47: S/MIME is mentioned here without reference. And I'm not clear why S/MIME is NOT RECOMMENDED here.
      Editorial (I think): ED-78 gives an example of "urn:servicetest.sos.fire". Is there a missing ":" in there?
    8. Dan Romascanu: Discuss [2011-04-27]:
      Part of the issues in the DISCUSS were raised in Bernard Aboba's OPS-DIR review. I recommend all his review to be addressed. I included in my DISCUSS those issues that seemed to me critical.
      1. A number of the recommendations made would appear to assume an all-IP NG911 "NENA i3" architecture, as opposed to the "NENA i2" transitional architecture. In those cases, the recommendations would represent "Best Future Practice" rather than"Best Current Practice".
      In a number of cases normative language appears to be used in ways different from those described in RFC 2119. In some cases, the term "SHOULD" is used in situations where statutes or regulations may mandate behavior.
      I agree here with Bernard that the BCP status is probably adequate, but in some places the requirements need clarification.
      Bernard also writes:
      Overall, I was left with the question as to whether the recommendations in this document applied beyond "all-IP" deployments based on the framework document, to transitional "NENA i2" environments as well. I suspect that the "INT" requirements would also apply to gateways between IP and legacy PSAPs, but this isn't stated explicitly.
      I also find odd the fact that the document does not refer at least informationaly to the NENA i2 and i3 architectures. The behavior of the system and requirements may be different in i2 and i3 environments. There are places where behavior should be configurable or negotiated to allow for better behavior in a transitional environment. There are also places where behavior will be prescribed by local statues or regulations, so that configuration and/or negotiation is a practical requirement.
      2. I had a hard time translating some of the AN (Access Networks related) requirements. For example:
      "AN-5 Access networks supporting copper, fiber or other hard wired IP packet service SHOULD support location configuration. If the network does not support location configuration, it MUST require every device that connects to the network to support end system measured location."
      If I am an operator of an AN that does not support location configuration how should I read the requirement? Is this an administrative requirement, or should the network be designed so that devices that do not support end system measured location (and have it activated?) cannot connect to the network?
      3. ED-3 is confusing. I think that it tries to state that string recognition MUST be supported and that the endpoints SHOULD provide this function, but if this is not the case the SP MAY do it. If I am correct than this needs to be an ED/SP requirement, and I would like the cases of exception to be clarified. If I mis-understood please help me understand, maybe with some text changes.
      4. Section 17.2: "The registration process is Expert review by ECRIT working group, its successor, or, in their absence, the IESG."
      I suggest to define this policy as Expert Review as per RFC 5226 and have a Designated Expert nominated. The designated expert can than use help from ECRIT, IESG, or other in the future.
    9. Dan Romascanu: Comment [2011-04-27]:
      I support Pete's part of the DISCUSS that states that section 12 points to a security hole that needs to be addressed
    10. Sean Turner: Discuss [2011-04-28]:
      Section 6.1: For the 1st paragraph which entity is the requirement on? All the other requirements statements are targeted at an entity or entities.
    11. Sean Turner: Comment [2011-04-26]:
      I support Stephen's discusses 3-5.

    Telechat:

  3. Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (Proposed Standard)
    draft-ietf-softwire-dual-stack-lite-07
    Token: Jari Arkko
    Note: Dave Ward (dward@juniper.net) is the document shepherd.
    Discusses/comments (from ballot 3497):
    1. Wesley Eddy: Discuss [2011-04-25]:
      Section 5.6 is a little strange, since it says that the topic is out of scope, but doesn't give any hint as to where this information might be found, why it's deemed out of scope, or who it would be in-scope for. I would think this should be easy to clarify.
    2. Wesley Eddy: Comment [2011-04-25]:
      In section 5.2, the final paragraph should be slightly more clear that it's saying to fragment the IPv6 tunnel packet into multiple IPv6 fragments, and not the inner IPv4 packet into multiple tunnelled IPv6 packets. It may be worth mentioning here also that fragmenting the IPv4 packet instead is not a good idea or alternative.
      Typos: - in Section 6.4, "a B4 elements" -> "a B4 element"
    3. Adrian Farrel: Comment [2011-04-24]:
      Thanks for a fine and readble document. Herewith, a few minor points you might like to look at to improve the document.
      I was surprised that the following statements use a weak "MAY"
      "The B4 element MAY use any other addresses within the 192.0.0.0/29 range."
      "The AFTR MAY use the well-known IPv4 address 192.0.0.1"
      "MAY" is usually used when there is some other more normal behavior, but you don't say what that is.
      7.2. VPN: "Dual-stack lite implementations SHOULD NOT interfere with the functioning of IPv4 or IPv6 VPNs.
      Seems a bit of an odd use of "SHOULD NOT". I'm not clear whether you are commentng that "in your view the DS-Lite technology should not cause anything to break" or observing that it would be a broken implementation that *chose* to interfere with VPN function.
      8.4. Sharing global IPv4 addresses: "AFTR shares a single IP to multiple users."
      s/to/address with/
      8.5. Port forwarding / keep alive: "Work on a control plane to the carrier-grade NAT is done in the PCP working group at IETF. The PCP protocol enables"
      What does the second 'P' in "PCP" stand for?
    4. Stephen Farrell: Discuss [2011-04-26]:
      (1) Where's it say that DNSSEC needs to work through the B4 thing? I don't know if that's problematic or not but RFC4033 does say the DNS proxies need to be security aware for DNSSEC to work (section 6 of 4033) so that may be worth repeating here.
      (2) Is the "SHOULD NOT interfere" language in 7.2 sufficient? I don't know but it seems awfully short. Is there anything similar that needs to be said about TLS or DTLS?
      (3) 8.1 - ought that say "the address ranges in the pools"? (Instead of the "the address range in the pools")
      (4) How would the AFTR impact on anti-spam solutions such as DNSRBLs? I think that may warrant a mention.
    5. Stephen Farrell: Comment [2011-04-26]:
      8.3: s/require ALG to work properly/require ALGs to work properly/ (maybe) There are a few other English language issues (mainly improper singluar/plurals).
    6. David Harrington: Discuss [2011-04-25]:
      There are a few question I would like to discuss before approving this document.
      1) 6.3 makes assumptions, but doesn't prescribe behavior if the assumption is false. what should happen if an AFTR runs out of resources due to reassembly?
      2) 6.5 why MAY, and not SHOULD or MUST?
      3) 7.1 why SHOULD and not MUST? what are the acceptable exceptions to SHOULD?
      4) 7.2 why SHOULD NOT rather than MUST NOT? what are the acceptable exceptions, what types of interference are expected/allowed, and how should implementations handle the interference?
      5) 7.3 why is this out of scope?
      6) 8.1 s/must not/MUST NOT/
      7) 8.2 why SHOULD rather than MUST? acceptable exceptions? how should implementations respond to the exceptional case for interoperability?
    7. David Harrington: Comment [2011-04-25]:
      There are a few places where I feel the document could be improved, if the document is revised.
      section 4.1 what is horizontal scaling?
      4.2 last sentence duplicates section 1 diagrams would help
      6.3 discusses clients, but clients are not defined.
      6.4 the English is a little weak;
      8.5 carrier-grade nat is not defined
      B.1 s/DCHP/DHCP/
      figure 1 uses 10.0 addresses, while the text talks about 192.168 addresses. are the addresses used consistent with reserved example addresses?
      s/concentrartor/concentrator/
      B.1.2 SE not defined on first use.
      B.2.1 why a.b.c.d rather than 192.0.0.2?
    8. Russ Housley: Comment [2011-04-22]:
      Please consider the editorial comments from the Gen-ART Review by Roni Even on 9-Apr-2011.
    9. Robert Sparks: Comment [2011-04-26]:
      Consider adding a short discussion or perhaps an example of how services that sit on the Internet side of an AFTR (especially those in the same administrative domain of the AFTR) that need to know which B4 IPv4 traffic came through might get that information from the AFTR (perhaps using the information in the extended binding table described in section 6.6). Showing how a location query in a protocol like HELD (RFC5985) would be answered would be a good example.
    10. Sean Turner: Comment [2011-04-26]:
      The reference for 1918 should be normative based on the following:
      "However, it SHOULD operate its own DHCP(v4) server handing out [RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home."

    Telechat:

  4. Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks (Proposed Standard)
    draft-ietf-pwe3-fc-encap-15
    Token: Stewart Bryant
    Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3694):
    1. Jari Arkko: Comment [2011-04-28]:
      I'm not looking to block the document based on this, but I think we should discuss in the IESG telechat about this document and what it expects out of the underlying MPLS network. The combination of requiring no reordering and the possibility of any error resulting in 30-60 second delays at the FC processing level is worrisome. Can this statement from the draft be made precise:
      :FC PW traffic should only traverse controlled MPLS or MPLS-TP networks. The network should enforce policing of incoming traffic and network resource/bandwidth allocation so that the FC PW delivery quality can be assured. To extend FC across an uncontrolled network, FCIP SHOULD be used instead of an FC PW, see [RFC3821] and [FC-BB-6].:
      What exactly is considered a controlled network? What kind of mechanisms are sufficient for the resource allocation?
    2. Adrian Farrel: Discuss [2011-04-24]:
      I have two issues I would like to resolve with this document before moving to a "Yes" ballot.
      I was a little surprised by the mention of MPLS-TP in the Abstract. I am not sure how "taking advantage of MPLS-TP" is in any way different from "using an MPLS PW".
      It is probably not important, but it feels a bit like marketing-speak has escaped into your spec.
      Later in the document, however, I find:
      "MPLS-TP provides mechanisms for communication over MPLS networks with very low loss rates and very low probability of reordering, making it possible for Fibre Channel ports to be interconnected directly over MPLS networks."
      I don't see how MPLS-TP provides such mechanisms, but the sentence is ambiguous because it is not clear from what you have written whether the networks intrinsically have the qualities described (and MPLS-TP provides mechanisms for communicating over them) or whether MPLS-TP somehow enhances the loss rates and reordering probability. In the first case, this something of a non-statement; in the second case I don't think it is true. How about cutting this text?
      Later still I find:
      "FC PW traffic should only traverse controlled MPLS or MPLS-TP networks."
      Since all MPLS-TP networks are MPLS networks, I suggest you delete "or MPLS-TP" from this sentence.
      similalry, in the next paragraph:
      "As a consequence, resilience of the emulated FC service to such outages is dependent upon MPLS-TE/MPLS-TP network."
      I suggest you change "MPLS-TE/MPLS-TP networks." to "the underlying MPLS network."
      This element of the Discuss is for discussion with the IESG. No action from the authors is requested.
      The procedures for lock-step with ANSI seem worrisome. Do we really need to go through these hoops, and how vulnerable are we to ANSI delays?
      It seems to me that, although [FC-BB-6] is needed in conjunciton to this spec to get the whole picture, [FC-BB-6] is not actually required as a normative reference for the understanding of this spec.
    3. Adrian Farrel: Comment [2011-04-25]:
      Section 3.1 Although you say: "The fragmentation bits (bits 8-9) are not used by the FC PW protocol. These bits may be used in the future for FC specific indications as defined in [RFC4385]."
      It appears from the diagram that you require these bits to be set to zero, and I suspect that a future extension might interpret the bits. I think you should be more explicit in the text.
      Nits
      Section 1: "the TCP protocol" The P in TCP stands for what? :-)
      Section 1.1: s/port on far end of the FC link/port on the far end of the FC link/
    4. Stephen Farrell: Comment [2011-04-26]:
      (blank)
    5. Pete Resnick: Comment [2011-04-27]:
      I don't think this is worthy of a discuss, but is the byte order for FC PW Control Word (and other items) specified? Does it need to be in this document?
    6. Dan Romascanu: Discuss [2011-04-27]:
      The document has no operational and manageability considerations section, and no reference to the operational and manageability aspects. I would have expected at least some considerations about the OAM mapping extensions, as the Pseudowire (PW) OAM Message Mapping I-D (draft-ietf-pwe3-oam-msg-map-16.txt) does not cover FC services over PW.

    Telechat:

  5. Manifests for the Resource Public Key Infrastructure (Proposed Standard)
    draft-ietf-sidr-rpki-manifests-10
    Token: Stewart Bryant
    Note: Sandra Murphy (sandra.murphy@sparta.com) is the document shepherd.
    Discusses/comments (from ballot 3729):
    1. Wesley Eddy: Comment [2011-04-20]:
      A couple of typos:
      - period missing at end of first sentence in section 3
      - at end of section 5.2 "CAs" should be "CA"
    2. Stephen Farrell: Discuss [2011-04-26]:
      The secdir and apps reviews raise a few issues that are worth checking/addressing. I'd expect these should be addressed fairly quickly via a few email exchanges.
    3. Russ Housley: Comment [2011-04-21]:
      Please consider the editorial comments in the Gen-ART Review by Francis Dupont on 23-Mar-2011.

    Telechat:

  6. Runtime LMA Assignment Support for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-netext-redirect-07
    Token: Jari Arkko
    Note: Rajeev Koodli (rkoodli@cisco.com) is the document shepherd.
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-netext-redirect-03
    Discusses/comments (from ballot 3752):
    1. Ralph Droms: Discuss [2011-04-26]:
      1. I'd like to hear the motivation for what seems to be three different (related) methods for LMA assignment:
      a) colocated rfLMA/r2LMA, with CBE passed through some unspecified mechanism
      b) separate rfLMA/r2LMA, with CBE created through proxy PBU/PBA exchange
      c) separate rfLMA/r2LMA, with MAG redirected to restart mobility session establishment with r2LMA
      Am I summarizing the 3 methods correctly? I can understand method a as taking advantage of more efficient/direct communication between colocated devices. Method c seems to have the virtues of simplicity in design and operation. Where does method b, which seems more complex than c with none of the efficiencies of a, fit?
      2. In section 3, paragraphs 3 and 5 appear to be redundant, specifying protocol behavior. I list this issue as a DISCUSS point, because redenudancy in the specification can result in confusing or conflicting text. I suggest simply dropping those paragraphs.
      3. If RFC 5142 can be used for mid-session LMA reassignment, why is there a need for specification of a separate protocol extension for LMA reassignment at session initiation time?
      4. In section 4.1, why is "the MAG SHOULD include [...]" specified as SHOULD rather than MUST? This example of "SHOULD" seems to me to need an explanation: under what circumstances would a MAG not include the Redirect-Capability option; what is the effect of not including the option? This question is partially answered by some text in section 5.1, but that text is kind of redundant with this text in 4.1. Might be better to have this rule just in section 5.1 concerning MAG behavior.
    2. Ralph Droms: Comment [2011-04-26]:
      In section 4.1, the following text is unclear to me:
      "When this option is included, the MAG may be assigned with another LMA, and the assigned LMA may simultaneously create a Binding Cache Entry (BCE). Hence, the MAG including this option MUST be able to support runtime LMA assignment with and without a creation of a BCE in the runtime assigned LMA."
      As I understand the architecture of the LMA, the BCE is an implementation structure in the LMA and not immediately visible to the MAG. What change in behavior on the part of the MAG is required to support these two different scenarios?
      Nits:
      In section 4.1, BCE is expanded in RFC 5213, which is pointed to in the Terminology section. For consistency, no need to expand it here.
      In section 4.1, s/There can zero/There can be zero/
      End of section 5.1, s/treat the of the PBA/process the PBA/
      In section 5.2, is "LMA" as used in this section equivalent to "runtime assignment domain" as defined in the terminology section?
      Section 7 seems superfluous, and it mentions three configuration variables but only lists two.
      Is there a registry for the Status values defined in section 9?
    3. Wesley Eddy: Discuss [2011-04-20]:
      (1) in section 4, why shouldn't the Redirect-Capability S & F bits or the Redirect K & N bits be set at the same time? Does it break anything? It seems like it should be allowed, with the LMA and MAG (respectively) able to determine which to use.
      This seems to relate to the rule in section 5.2 about not cross-assigning IPv4-only LMAs to IPv6-only MAGs, and vice-versa.
      Also, the configuration variables in section 7 only refer to enable/disable controls without regard to IPv4 or IPv6, so how to operate with both seems unclear.
      (2) in section 5.2, this paragraph and the decision to leave some of the prerequisite information needed for LMA assignment out of scope seems like it could lead to making it difficult to understand what is required for cross-vendor interoperability of rfLMA and r2LMA implementations. This should at least be clarified in this document, which otherwise focuses on the LMA to MAG interaction.
      (3) for the multihoming discussion in section 6, the requirement that all mobility sessions for an MN be under control of a single LMA seems to be unnecessary. How could multiple providers over multiple interfaces be supported? Is there motivation for this requirement? If so, the document needs to include it, as it doesn't seem clear, and may lead to limits in applicability.
    4. Wesley Eddy: Comment [2011-04-20]:
      Some typos:
      -in section 1, "practise" -> "practice"
      -in section 1, "due caching" -> "due to caching"
      -missing period at end of section 3
      -in section 5.1, "at time" -> "at a time"
      -in section 5.1, "the of the" -> "the"
    5. Adrian Farrel: Comment [2011-04-26]:
      Would be really nice to include a reference to RFC 5213 really early in the Introduction.
    6. Stephen Farrell: Discuss [2011-04-24]:
      (1) "The trust relationship and coordination management between LMAs within a PMIPv6 domain is deployment specific and not described in this specification." Hard to buy that as a way to get interop and security. What if the rfLMA and r2LMA and MAG are each from different vendors? Put another way: "adequate means to secure their inter-LMA communication" with interop implies this needs to be specified.
      (2) "That is, the runtime assignment functionality specified in this document is not enabled in the r2LMA, or the r2LMA does not belong to the same runtime assignment domain as the rfLMA, or the r2LMA is down or otherwise unreachable." That doesn't seem to be a sentence and I don't understand it anyway.
      (3) Section 3 says that rfc5142 may be used for a mid-session LMA assignment. If that works, why bother defining this protocol?
      (4) "The rfLMA MUST only assign the MAG with a new r2LMA that it knows the MAG has a SA with or the MAG and the r2LMA are able to create it dynamically." The grammar there is pretty bad, but aside from that *how*, in general, could the rfLMA *know* that the MAG and r2LMA are able to setup an SA? That seems like an intractable problem if different vendor implementations are in use for rfLMA, MAG and r2LMA. "These SA related knowledge issues and trust relationships are deployment specific in a PMIPv6 domain and in a runtime assignment domain, and out of scope of this specification. " Doesn't seem acceptable.
      (5) 5.3.2 says the MAG "SHOULD" establish an SA with the r2LMA. Why is that not a MUST and under what circumstances is it ok to not establish an SA? Is the the ability to establish an SA mandatory to implement or not?
      (6) What happens if the new SA cannot be established? What should the MAG do?
      (7) 5.3.3 says to create a tunnel as specified in rfc 5213 - where in (the 89 pages of) 5213 is that specified?
      (8) 5.3.1 has a ~~~~ line between rfLMA and r2LMA for LMA assignment, but 5.3.4 says that the r2LMA can be a "any 5213 compliant LMA". I think that needs more explanation.
      (9) I assume that this is not controversial for MIPv6 people but it seems quite odd to me, so I wanted to check. Do you really expect that "A single LMA entity should have the control over all possible multi-homed mobility sessions the MN has." is likely to be the case? Seems unlikely to me, but I'll not insist if told its a general assumption.
      (10) "Alternatively, the rfLMA can do all required security processing on the PBU/PBA, and the communication between the rfLMA and the r2LMA would be unprotected at the PMIPv6 protocol level. In this case the runtime assignment domain MUST implement adequate level of security using other means, such as layer-2 VPNs." So I don't get that. What data is sent from rfLMA to r2LMA according to this spec?
    7. Stephen Farrell: Comment [2011-04-24]:
      (1) Last para of section 3 says "The LMA..." a couple of times. It probably ok but would that be better as "An rfLMA..."?
      (2) Saying "MAY make use of [RFC5142]" is not very clear - why not describe what may be used with more than just a reference and make it clear what you mean?
      (3) "The rfLMA MUST NOT assign a MAG using IPv6 transport with a new r2LMA using IPv4 transport, if the MAG does not indicate support for IPv4 in the Redirect-Capability mobility option, as there is no guarantee that the MAG supports switching from IPv6 transport to IPv4 transport. The same also applies for assigning a MAG using IPv4 transport with a r2LMA supporting only IPv6 transport." That could be a good bit clearer - but I think its saying only provide an r2LMA address where you already know the MAG/rfLMA connection can work using that address family.
      (4) What's a "MAG-rfLMA-r2LMA proxy state"? Is that defined in 5213?
      (5) The document could do with an editorial pass for English language issues.
    8. Russ Housley: Discuss [2011-04-21]:
      The Gen-ART Review by Pete McCann on 14-Apr-2011 raised major concerns, yet there has been no respons to the review. The major issues raised are:
      Section 5.4: please include a discussion of the possibility of loops in the LMA assignment operation and specify the actions that must taken by the MAG to detect and resolve them.
      Section 6: This section assues that all of the MN's sessions are able to be correlated and that all MAGs will direct their tunnels back to the same LMA. There is no way to enforce that all sessions go to the same LMA.
    9. Russ Housley: Comment [2011-04-21]:
      Please consider the minor and editorial comments from the Gen-ART Review by Pete McCann on 14-Apr-2011.
    10. Dan Romascanu: Comment [2011-04-28]:
      Section 7. Configuration variables starts by mentioning that three configuration variables are defined in the document, and then defines ... two.
      Also - why are these called 'configuration variables' and not 'configuration objects'?
    11. Robert Sparks: Comment [2011-04-26]:
      Support Russ' discuss point asking for additional text around the detection and prevention of loops

    Telechat:

  7. Computing TCP's Retransmission Timer (Proposed Standard)
    draft-paxson-tcpm-rfc2988bis-02
    Token: Wesley Eddy
    Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd.
    Discusses/comments (from ballot 3754):
    1. Jari Arkko: Comment [2011-04-28]:
      Thank you for writing this. I do agree that the issue raised by Adrian needs to be resolved, however.
    2. Stewart Bryant: Comment [2011-04-27]:
      I agree with Adrian's discuss.
    3. Ralph Droms: Comment [2011-04-27]:
      I notice the file name for the document is draft-paxson-tcpm-rfc2988bis (not draft-ietf...). I can't tell from the history or the document writeup, so may I assume the document was formally adopted as a working group work item and went through a working group last call?
    4. Adrian Farrel: Discuss [2011-04-24]:
      I would like to ballot "Yes" on this document, but the following small issue needs to be resolved first. It can probably be handled through an RFC Editor note.
      It is odd, IMHO, that a bis makes such small reference to the RFC it is bis'ing. I think you are completely replacing RFC 2988, so I would expect:
      - obsoletes in the document header
      - a note on obsoletes in the abstract and introduction
      - a short section somewhere "Changes from RFC 2988" (I can probably deduce this from the notes in the text, but it would be useful to write the section.)
      Are you also intending that this document updates RFC 1122?
    5. Dan Romascanu: Comment [2011-04-27]:
      1. I support Adrian's DISCUSS.
      2. In the Introduction Section:
      "In some situations it may be beneficial for a TCP sender to be more conservative than the algorithms detailed in this document allow. However, a TCP MUST NOT be more aggressive than the following algorithms allow."
      s/TCP MUST NOT/TCP sender MUST NOT/
      Also this paragraph should probably be moved to a later section, as it is not common practice to include key-worded statements in the Introduction, and certainly not before the paragraph that explains the role of keywords notations.
    6. Robert Sparks: Comment [2011-04-25]:
      Support Adrian's discuss
    7. Sean Turner: Comment [2011-04-26]:
      I support Adrian's discuss.
      Sec 6: r/This document requires a TCP to wait/This document requires a TCP *sender* to wait ?
      As noted in the SECDIR review there really needs to be a more overt homage to the security considerations in 5681. Something like the following would suffice: "Refer to [RFC5681] for TCP congestion control security considerations."

    Telechat:

  8. Protocol Support for High Availability of IKEv2/IPsec (Proposed Standard)
    draft-ietf-ipsecme-ipsecha-protocol-05
    Token: Sean Turner
    Note: Yaron Sheffer (yaronf.ietf@gmail.com) is the document shepherd.
    IPR: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ipsecme-ipsecha-protocol-04
    Discusses/comments (from ballot 3756):
    1. Adrian Farrel: Discuss [2011-04-26]:
      I have two concerns with this document that I would be happy to discuss.
      I had some difficulty understanding that Section 7 says: "The standby member can initiate the synchronization of IKEv2 Message ID's under different circumstances. - When it receives a problematic IKEv2/IPsec packet, i.e. a packet outside its expected receive window."
      This seems to conflict with the DoS avoidance described in Section 11. It seemed to me that this trigger is not needed since the standby member since whenever a failure (or forced) take-over has happened the new active member will know that it has taken over as in the third bullet in the list.
      Your trade-off here seems to be that you would like to not have to resynch when the new active member is already in synch, and the only way you can find out that you are out of synch is by waiting for a message.
      Similarly the second trigger: "- When it has to send the first IKEv2/IPsec packet after a failover event."
      ...can only serve to spread the load of resynch, and is really just a sub-case of the third trigger in the list.
      Yet the third trigger: "- When it has just received control from the active member and wishes to update the values proactively, so that it need not start this exchange later, when sending or receiving the request."
      ...is rather vague with "just received control" and, in the case of a very large number of peers, such behavior might very well cripple the new active member.
      So I think you should look again at the triggers:
      - in the light of DoS protection (perhaps the first case can only be applied once per peer per take-over)
      - in order to take load distribution more explicitly into account.
      ---
      Section 8.2 says: "For IPsec, there is often a trade-off between security and reliability of the protected protocols. Here again there is some leeway for local policy. Some implementations might accept incoming traffic that is outside the replay window for some time after the failover event. Strict implementations will only accept traffic that's inside the "safe" window."
      Shouldn't you at least be recommending against this behavior? Isn't this like saying tat an IPsec implementation can sometimes ignore the fact that it is a security implementation? You should at least draw out this case in Section 11 if itis really something that is considered as an option.
    2. Adrian Farrel: Comment [2011-04-26]:
      I also have a few minor suggestions you might consider to help polish the document
      I missed a reference to RFC 6027 in Section 1.
      Please consider whether a reference figure showing a "cluster" would help the reader.
      Section 1: "This document proposes an extension to the IKEv2 protocol to solve the main issues of IKE Message ID synchronization and IPsec SA replay counter synchronization and gives implementation advice for others. Following is a summary of the solutions provided in this document:"
      This is a Standards Track document, so you "define" not "propose".
      Ditto Section 5
      Additionally could you clarify "for others"? I think this is "to address other issues."
      It would be helpful if this document made a distinction between 2119 langauge for behavior that is defined in this document and behavior defined in another document (such as the based spec.) Perhaps use lower case for behavior defined elsewhere, and include an explicit reference to where the behavior is defined.
      I think: 10. Interaction with other drafts
      ...should s/drafts/specifications/
    3. Stephen Farrell: Comment [2011-04-26]:
      - I guess there's a 4th case for the list on the end of p10 - that the newly active member does neither if the peer didn't support this spec. Maybe worth a mention.
      - 5.2 says a "rekey SHOULD follow shortly..." is that really 2119 language or just what's going to happen when you add a large increment? If the latter, then maybe s/SHOULD/is likely to/
      - 6.4: The sentence "Note that this solution requires that all these Child SAs either use or do not use Extended Sequence Numbers" seems odd - I guess you mean "requires that either all Child SAs use Extended Sequence Numbers or else that no Child SA uses Extended Sequence Numbers," which is different.
      - a nit, 5.1, 1st sentence; s/two counter value/two counter/values/
    4. Russ Housley: Comment [2011-04-21]:
      Please consider the editorial comments from the Gen-ART Review by Alexey Melnikov on 9-Apr-2011.
    5. Pete Resnick: Comment [2011-04-26]:
      Please insert in section 6, just before 6.1.
      "All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first", or "network byte order")."
      (This should have appeared at the top of section 3 of RFC 5996, but unfortunately it only appears in section 3.1. Just trying to avoid confusion.)
    6. Robert Sparks: Comment [2011-04-26]:
      Please add a little more detail to the examples on page 22 (explain what the tuples represent), and verify that the examples are correct.

    Telechat:

  9. Unique Per-Node Origin ASNs for Globally Anycasted Services (BCP)
    draft-ietf-grow-unique-origin-as-00
    Token: Ron Bonica
    Note: Peter Schoenmaker (pds@lugs.com) is the document shepherd.
    Discusses/comments (from ballot 3762):
    1. Stewart Bryant: Comment [2011-04-24]:
      When do the authors anticipate closing their advertisement for sponsorship?
      "Others? Your name could be here......."
    2. Wesley Eddy: Comment [2011-04-19]:
      Section 3 seems like it would work better if the 4th paragraph (on ASN conservation) were moved up to be the 1st paragraph, since it would describe why the rest of the section is now advisable after the addition of support for 32-bit ASNs, and it also describes what this document means by the "critical infrastructure" term that's used in some of the other paragraphs in this section..
      Note: idnits complains that the 2119 boilerplate doesn't exist and that 2119 is included as a reference but not referred to in the document.
    3. Adrian Farrel: Comment [2011-04-28]:
      I have a number of comments that don't quite make it to the level of Discusses, but I would surely welcome it were you to attend to them.
      I feel it would be worth going the extra mile to clarify what level of uniqueness you are asking for. You have text such as:
      "This document makes recommendations regarding the use of per-node unique origin ASNs for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix." (Abstract)
      and
      "In order to be able to better detect changes to routing information associated with crtical anycasted resources, globally anycasted services with partitioned origin ASNs SHOULD utilize a unique origin ASN per node where possible." (Section 3)
      Owing to the lamentable state of the education system, there is considerable risk that people will not know whether you mean:
      - A globally-unique ASN is allocated per node
      or
      - A node-unique ASN is allocated per anycasted service
      The Routing Directorate review by Stig Venaas raised the following issues that I think should be attended to.
      Section 2: Regarding traceroute it says:
      "enables service-level identification of a given server. Tools such as traceroute are also used to determine which location a given query is being routed to, although it may not reveal local-scope anycast instances, or if there are multiple servers within a given anycast node, which of the servers responded to a given query, in particular when multiple servers within an anycast node are connected to a single IP router. When utilizing these service level capabilities,"
      Why is local-scope emphasized here? I would think that traceroute always gives you one node. It may be a particular global node, or a local node, depending on your location. It may not reveal local-scope, but it may not reveal global-scope either. They key thing is that you get only one. And you may not know what the scope is either. Am I missing something, or should the text be changed?
      Section 2: Regarding synchronization of instances it says:
      "Additionally, while it goes without saying that anycasted services should always strive for exact synchronization across all instances of an anycasted service address, if local policies or data plane response manipulation techniques were to "influence" responses within a given region in such a way that those response are no longer authentic or that they diverge from what other nodes within an anycasted service were providing, then it should be an absolute necessity that those modified resources only be utilized by service consumers within that region or influencer's jurisdiction."
      Isn't this a bit DNS centric? I can think of anycast services where different nodes intentionally have different content. I'm not sure if it necessarily is important to restrict it to region or jurisdiction either. It all depends on the service.
      Maybe rephrase this to point out that this may be an important issue, depending on the service?
      Nit: In the paragraph above I found this line:
      a given region in such a way that those response are no longer
      s/response/responses
    4. Russ Housley: Discuss [2011-04-27]:
      There are three copyright statements in the document. Please consolidate.
      This document uses RFC 2119 key words. Please add the usual RFC 2119 boilerplate...
      The Acknowledgements section includes: "Others? Your name could be here......." Please finalize this section.
    5. Pete Resnick: Comment [2011-04-25]:
      It's not clear to me why this document is going for BCP rather than standards track, but I expect this topic will be discussed in the context of other documents on the agenda this week, so I'm not going to hold up this one specifically.
    6. Dan Romascanu: Discuss [2011-04-27]:
      Although RFC2119 is included in the references there is no RFC2119 boilerplate. As far as I can tell there are three capitalized key words in Section 3. While the first one (the recommendation to utilize a unique origin ASN per node) makes sense, for the other two it seems that the document could do well without them:
      "Furthermore, inconsistent origin AS announcements associated with anycasted services for critical infrastructure SHOULD NOT be deemed undesirable by routing system reporting functions, but should instead be embraced in order to better identify the connectedness and footprint of a given anycasted service."
      While namespace conservation and reasonable use of AS number resources should always be a goal, the introduction of 32-bit ASNs significantly lessens concerns in this space. Globally anycasted resources, in particular those associated with critical infrastructure-enabling services such as root and TLD name servers, SHOULD warrant special consideration with regard to AS number allocation practices during policy development by the constituents of those responsible organizations (e.g., the Regional Internet Registries)."
      'SHOULD NOT be deemed undesirable' and 'SHOULD warrant special consideration' seem too vague for a capitalized recommendation in a BCP.
    7. Dan Romascanu: Comment [2011-04-27]:
      1. ASN should be expanded earlier, probably as soon as the title of the document.
      2. In the IANA Considerations section all the text that follows the statement that no actions are required from IANA does not seem IANA related and could be dropped.
    8. Robert Sparks: Comment [2011-04-26]:
      If you have not already done so, please coordinate with DNSOP regarding <https://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-ops/> and consider whether either document should discuss the other.

    Telechat:

  10. Locally-served DNS Zones (BCP)
    draft-ietf-dnsop-default-local-zones-15
    Token: Ron Bonica
    Note: Peter Koch (pk@ISOC.DE) is the document shepherd.
    Discusses/comments (from ballot 3780):
    1. Ralph Droms: Discuss [2011-04-27]:
      I'd like to discuss whether this document should define the lists of prefix names for inclusion in the IANA registry for special use names defined in draft-cheshire-dnsext-special-names.
    2. Adrian Farrel: Comment [2011-04-26]:
      Will it be clear to IANA exactly what they have to do in order to satisfy the following text from Section 6?
      "IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is deployed in the reverse tree, delegations for these zones are made in the manner described in Section 7."
    3. Pete Resnick: Comment [2011-04-26]:
      I don't understand why this is not standards track. It might not be likely that implementation experience will change this spec, but it's certainly possible.
    4. Sean Turner: Comment [2011-04-27]:
      wordsmithing here: Sec 3: use 2219 language in the following?:
      OLD: "This document recommends that the NS record defaults to the name of the zone and the SOA MNAME defaults to the name of the only NS RR's target."
      NEW: "It is RECOMMENDED that the NS record defaults to the name of the zone and the SOA MNAME defaults to the name of the only NS RR's target."

    Telechat:

2.1.2 Returning Items

  1. "Guidelines for the use of the OAM acronym in the IETF" (BCP)
    draft-ietf-opsawg-mpls-tp-oam-def-09
    Token: Adrian Farrel
    Note: Chris Liljenstolpe (ietf@cdl.asgaard.org) is the document shepherd.
    Discusses/comments (from ballot 3439):
    1. Adrian Farrel: Comment [2011-04-27]:
      Repagination shows that this is really just an 8 page document not the 14 that it appears. I think some pruning could usefully be done to make it even shorter.
      1. What value does the long list of "wrong" OAM expansions in Section 1 serve?
      2. Section 2.1 immediately lapses into a discussion of different interpretations of "OAM" in the source material of other SDOs. This has some interest in qualifying that the problem exists in other SDOs as well as in the IETF, but nothing in this section seems to have relevance to the purpose of the document or to the IETF scope. I wonder about the value of this whole section.
      The main purpose of the document is clear from the first paragraph of the Introduction:
      The main purpose of this document is to provide a definition of the OAM acronym such that it is useful for the IETF."
      But the document does not say *why* this objective is worthwhile.
      Section 2.1 says: "However there is some ambivalence in the definition and scope of the term "Operation"."
      This may be true, but as it stands no context or explanation is given, and so the sentence is not helpful.
      An alternative to consider, even at this late stage, is to move the recommended acronym expansions into I-D.ietf-opsawg-oam-overview and scrap this document.
    2. Russ Housley: Discuss [2011-04-27]:
      The Gen-ART Review by Scott Brim in 12-Apr-2011 raises some major concerns, but I have not seen a response. Please provide a response to this review.
    3. Pete Resnick: Discuss [2011-04-26]:
      I do not understand why this document is necessary when the definition could be given in 1 sentence at the top of any document that wants to use it. I do not understand why this document is going for BCP instead of Informational given that I don't see the harm in defining the term differently in a document that wants to use it differently (again, so long as it is appropriately defined). I do not think that this document should be trying to mandate the definition of a term IETF-wide when its motivation is only for the MPLS arena of discussion. I do not think that dead silence from the non-working group portion of the IETF should be construed as consensus to publish in this particular case, because I don't see anybody noticing that this definition is the one they like or don't like until they wish to use it. I would prefer that this document be published as Informational with WG-only scope, or simply not published at all.

    Telechat:

  2. Pseudowire (PW) OAM Message Mapping (Proposed Standard)
    draft-ietf-pwe3-oam-msg-map-16
    Token: Stewart Bryant
    Note: Andrew Malis, andrew.g.malis@verizon.com is the document shepherd.
    IPR: Cisco's Statement about IPR Claimed in draft-ietf-pwe3-oam-msg-map-05.txt
    Discusses/comments (from ballot 3588):
    1. Adrian Farrel: Comment [2011-04-21]:
      Thanks for addressing the last dregs of my Discuss and Comment
    2. Russ Housley: Comment [2011-01-05]:
      Appendix B.3: s/Los/Loss/

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. IANA Registration for Enumservice 'iax' (Informational)
    draft-ietf-enum-iax-10
    Token: Gonzalo Camarillo
    Note: Bernie Hoeneisen (bernie@ietf.hoeneisen.ch) is the document shepherd.
    IPR: Comcast IP Holdings I, LLC's Statement about IPR related to RFC 3953, RFC 4415, RFC 4759, RFC 4769, RFC 4002, RFC 4355, RFC 4414, RFC 4725, RFC 4969, RFC 4979, RFC 5028, RFC 5278, RFC 5346, RFC 5067, RFC 5076, RFC 5105, RFC 2168, RFC 3401, RFC 3402, RF...
    Discusses/comments (from ballot 2880):
    1. Adrian Farrel: Comment [2011-04-26]:
      Clearing my Discuss with a red face. The Downrefs reported by idnits are a combination of very up-to-date referencing by the authors and a bug in idnits
    2. Sean Turner: Discuss [2011-04-26]:
      For some reason, the IPR statement submitted way back in 2008 on version -04 wasn't included in the IETF LC. The IETF LC is here:
      https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=9169&tid=1303832421

    Telechat:

  2. Current Practices for Multiple Interface Hosts (Informational)
    draft-ietf-mif-current-practices-11
    Token: Jari Arkko
    Note: Hui Deng (denghui02@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3569):
    1. Stewart Bryant: Comment [2011-04-25]:
      I agree with Adrian's Discuss.
    2. Ralph Droms: Discuss [2011-04-26]:
      In section 2, are the differentiations between the various mechanisms in the subsections really differentiated between mobile handset and desktop systems? Is making that differentiation germane? In particular, does the configuration information for mobile handsets not come from "DHCP, proprietary configurations systems or manual configuration"? Does Android implement a "connection manager"?
      In section 2.3, why is RA/SLAAC not mentioned for desktop systems?
    3. Ralph Droms: Comment [2011-04-26]:
      I support Adrian's DISCUSS and would like to hear why the details of the specific operating systems are included.
      I'm also a little confused, as I was when reading the problem statement draft, about the scope of the documents, based on the WG charter. Is the scope focused on dealing with "configuration objects" from different "provisioning domains" or is it more broadly issues related to multiple simultaneously active interfaces?
      Also, the problem statement document, referenced in this document, talks about "provisioning domains" and "attachment to a provisioning domain", while this document says nothing about provisioning domains. In my opinion, it would strengthen the documents if this document provided some additional motivation for the discussion of provisioning domains in the problem statement document.
      Include a citation for the MIF problem statement at the first reference in section 1.
      The Introduction include OS X in the list of operating systems for which information has been collected, but I don't see any specific information (or even any other references) to OS X.
      Why are Linux and BSD-based operating systems together in section 3.2.2, when many of the details are different?
    4. Adrian Farrel: Discuss [2011-04-24]:
      I found this document quite a good read, but I have three issues I would like to Discuss before balloting "no objection". The first two issues are relatively easily addressed. The third one might result in the deletion of substantial portions of the text.
      As with draft-ietf-mif-problem-statement, I would be happier if discussion of "routing" was clarified to "first hop selectiong" as what is going on here is not to be confused with general path selection or the type of routing that a router does.
      Does it actually matter for this document whether the different interfaces on the host provide unequal levels of service or connectivity? The Abstract seems to think so, but many of the decisions to be made eixst regardless of this point.
      While it is, of course, useful to survey existing implementations, and the use of public domain information cannot be complained about, I find it unfortunate that this document presents a comparison of the behaviors of different products rather than restricting itself to the (very good) sections that provide a generic anlysis of the mechanisms in use.
    5. Pete Resnick: Comment [2011-04-27]:
      In section 2, I was left a bit confused because I think you reversed the sense of the opening sentences of 2.1, 2.2, and 2.3. Are you describing the approach, or summarizing which OSs use which approach? I think you meant to do the former. For example, in 2.1, do desktop OSs ever use centralized connection management? If not, perhaps this would be a better opening for 2.1:
      "A centralized connection manager does network interface selection based on application or user input. This approach to dealing with multiple interfaces is employed by many mobile handset operating systems."
      Similarly for 2.2 and 2.3. I *think* each of these are simply describing the approach.
    6. Dan Romascanu: Comment [2011-04-27]:
      I support Adrian's DISCUSS and Ralph's COMMENT.

    Telechat:

  3. Validation of Route Origination using the Resource Certificate PKI and ROAs (Informational)
    draft-ietf-sidr-roa-validation-10
    Token: Adrian Farrel
    Note: Sandra Murphy (sandra.murphy@sparta.com) is the document shepherd.
    IPR: Cisco's Statement of IPR claimed in draft-ietf-sidr-roa-validation-03.txt
    Discusses/comments (from ballot 3728):
    1. (none)

    Telechat:

  4. IPv6 AAAA DNS Whitelisting Implications (Informational)
    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
    Token: Ron Bonica
    Note: Joel Jaeggli (joelja@bogus.com) is the document shepherd.
    Discusses/comments (from ballot 3741):
    1. Ralph Droms: Discuss [2011-04-26]:
      I would like to hear more about the reasons for including "universal deployment" as a potential deployment scenario in this document. Is universal deployment in any way a realistic outcome? Section 6.2 states:
      "it is unlikely that DNS whitelisting would, at least in the next several years, become universally deployed"
      and lists several other conditions necessary for universal deployment. Given all of these roadblocks, is there any real possibility of universal deployment?
      In section 3, in the interest of full disclosure, the way in which whitelisting "protects [...] users of their domain [...] from having a negative experience" is by only allowing users who resolve the domain in question from a whitelisted recursive resolver to have IPv6 access to the domain.
      What would make whitelisting go away?
    2. Ralph Droms: Comment [2011-04-26]:
      From Section 2: "for some on the authorized whitelist"
      "for all"? Why would just "some" on the authorized whitelist receive the AAAA records?
      In my opinion, "a few" should be dropped from the first sentence of section 3.
      My first reaction to the third paragraph of section 3 is that the scenario described in the paragraph would be better solved by a blacklist rather than a whitelist. I'd like to know how the scenario supports the whitelist solution.
      In the fourth paragraph of section 4, s/networks,/networks;/
      In section 8.2: s/discovering that they a given domain/discovering that a given domain/
    3. Wesley Eddy: Discuss [2011-04-26]:
      In section 7, it seems like there should be more discussion of what happens as (working) IPv6 deployments proceed, at some point possibly at a rapid pace, and the burden of adding to whitelists or dealing with requests for whitelist addition potentially grows quickly.
      In the same vein, it seems like whitelists work well well when they're relatively short; will systems scale as the whitelists grow longer?
      These concerns could lead to shared whitelists being commonly used and distributed amongst sites using rsync or similar means to reduce the admnistrative burden of updating them, but this has problems of paths between sites not being the same so there could not be a single universal whitelist, though there may be one that's close.
    4. Wesley Eddy: Comment [2011-04-26]:
      section 8 is "solutions", but it's not really clear what the problem is. Not all of the solutions seem to help if the problem is that some users have suboptimal IPv6 experiences, so they aren't really solutions, so it seems like the problem is just lack of global advice or position on deployment plans for whitelisting? Instead of describing solutions, this is really repetitive of section 6 on "likely deployment scenarios". I would suggest combining these sections and not calling it solutions, as it is a bit confusing.
    5. Adrian Farrel: Comment [2011-04-24]:
      Thanks for a document that was both informative and easy to read.
      One tiny nit: Section 3: "someone slower than usual"
      s/someone/somewhat/
    6. Stephen Farrell: Discuss [2011-04-26]:
      I don't think the language used to describe the "universal deployment" option is sufficiently negative. For example, I would like to see the phrase "considered harmful" liberally scattered whenever this option is described. Would/did the WG consider adding such a statement at the front of the document to send out a clear signal? The current text is far too even-handed IMO, even though it makes what appears to be all the very telling arguments against doing that.
      Newby question for the IESG: If we as a group did consider that option harmful, is it the kind of thing we'd add as IESG note? Is there a process for that other than just discussing it on the telechat etc?
    7. Stephen Farrell: Comment [2011-04-26]:
      - Spaces in references are odd and may break some tools. Be better not do to that I think. Example: "[Evaluating IPv6 Adoption]"
      - I'm not sure the reference to world IPv6 day should stay, it'll be outdated just after an RFC issues so why bother? (Describing what happens in June in retrospect will be very interesting but this bit isn't.)
    8. Robert Sparks: Discuss [2011-04-26]:
      The document should state explicitly that recursive resolvers must not themselves filter records based on the whitelist technique described here.
    9. Robert Sparks: Comment [2011-04-26]:
      At section 8.3, it does not follow from not implementing DNS whitelisting that the internet community will "choose to take no action whatsoever". Please rephrase this to reflect the points made elsewhere in the document that other approaches to ensuring a good experience during v4/v6 transition are being pursued. Please consider pointing to the happy-eyeballs work.

    Telechat:

  5. Moving DIGEST-MD5 to Historic (Informational)
    draft-ietf-kitten-digest-to-historic-04
    Token: Stephen Farrell
    Note: Tom Yu (tlyu@mit.edu) is the document shepherd.
    Discusses/comments (from ballot 3764):
    1. Adrian Farrel: Comment [2011-04-25]:
      The purpose of my Discuss has been achieved. The IESG has started a discussion on the wider relevance of "obsoletion" and "historic". There is no need to hold up this document any further, and I have cleared my Discuss.

    Telechat:

  6. I'm Being Attacked by PRISONER.IANA.ORG! (Informational)
    draft-ietf-dnsop-as112-under-attack-help-help-05
    Token: Ron Bonica
    Note: Peter Koch (pk@DENIC.DE) is the document shepherd.
    Discusses/comments (from ballot 3781):
    1. Jari Arkko: Comment [2011-04-28]:
      Thanks for writing this document, we do need documents like this to explain unexpected behaviors and the services provided by network infrastructure.
      However, I have one fundamental question. The document's explanation is built on the premise that responses from AS 112 will be unexpected. I have a hard time understanding how this can be the case. Either the user's network is disconnected from the Internet in its entirety, in which case there should not be DNS queries leaving the network. Or the network allows some traffic and some DNS queries to be made. What kind of intrusion detection system would cause an alarm over a properly formed response to a DNS query?
    2. Pete Resnick: Comment [2011-04-24]:
      Please see apps-review nits by S. Moonesamy.

    Telechat:

  7. AS112 Nameserver Operations (Informational)
    draft-ietf-dnsop-as112-ops-07
    Token: Ron Bonica
    Note: Peter Koch (pk@DENIC.DE) is the document shepherd.
    Discusses/comments (from ballot 3782):
    1. Stewart Bryant: Discuss [2011-04-27]:
      "The use of a UNIX or UNIX-like operating system (e.g. FreeBSD [1], OpenBSD [2], Linux [3]) is recommended for the construction of AS112 nodes,"
      "Suitable choices of free software to allow hosts to act as BGP speakers include,"
      It is not appropriate for the IETF to endorse a particular brand of operating system, or a particular brand of routing software.
      Please remove the recommendation, or reword in the form of a factual report on existing implementations of the protocol.
    2. Adrian Farrel: Comment [2011-04-26]:
      Should this document comment on who should install AS112 nodes and what their incentive is?
      Isn't the recommendation to use a UNIX or UINIX-like OS in section 3.3 a little too strong for the IETF? Wouldn't it be enough to make the statement about the weight of experience, and allow the readed to make up their own mind?
      The statement in Section 3 that... "A host that is configured to act as an AS112 anycast node should be dedicated to that purpose, and should not be used to simultaneously provide other services."
      Seems an odd requirement. I assume that there is an underlying requirement such as "AS112 anycast nodes may be epxected to respond rapidly to very large numbers of DNS queries in a small amount of time. For this reasons, it is recommended that..."
    3. Pete Resnick: Comment [2011-04-25]:
      Please address comments from Subramanian Moonesamy's 16-April Apps Area review.
    4. Robert Sparks: Comment [2011-04-26]:
      This project chose a different approach than what's recommended in <https://datatracker.ietf.org/doc/draft-ietf-grow-unique-origin-as/>. If the recommendations in that draft had been around at the time the AS112 project were coming together, would it have been built any differently? If so, would it make sense for this draft to point that out (in case someone in the future uses this document as a template for a similar project?)

    Telechat:

3.1.2 Returning Items

  1. Framework for Emergency Calling using Internet Multimedia (Informational)
    draft-ietf-ecrit-framework-12
    Token: Robert Sparks
    Note: IETF LC ends Mar 10.
    Marc Linsner (mlinsner@cisco.com) is the document shepherd.
    IPR: Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-framework-11
    Discusses/comments (from ballot 3187):
    1. Stephen Farrell: Discuss [2011-04-28]:
      (1) Section 3 says: "a caller must obtain his location...prior to making emergency calls." That seems overstated - if I can't find my location are you saying that the call can't happen? (A "should" would be right here I think.)
      (3) How would any of this work with p2psip? (Just checking again.)
    2. Stephen Farrell: Comment [2011-04-26]:
      (1) I support Sean's discuss wrt IPR and LC processes. I'm also unclear how IPR that affects this informational document would not affect the phonebcp document but who knows with these things.
      (2) Intro: "there are currently no international standards" - doesn't 112 qualify as an international standard for an existing emergency call system? Then: "However, the Internet crosses national boundaries, and thus international standards for equipment and software are required." Don't you mean that Internet standards are required?
    3. Russ Housley: Discuss [2010-03-11]:
      The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor issues. What, if anything, was done to address this IETF Last Call comment: "the Terminology is incomplete, no PSAP for instance"
    4. Russ Housley: Comment [2010-03-11]:
      The Gen-ART Review by Francis Dupont on 2010-03-05 included some editorial comments. Please consider them if an update to this document is needed for any reason.
    5. Cullen Jennings: Discuss [2010-03-08]:
      AD needs to check if any new LC comments came.
      Few small comments as part of my AD review. Typically I would have sent these before IETF Last Call but given the timing of the IESG calls and next IETF meeting, I decided we could sort them out as part of IETF Last Call. They are all small and could likely be fixed with RFC Editor notes after we decide what they need to say.
      6.2.1 Para 2. The statement that user provided location information is less accurate seems to be contradicted by the later statement that emergency responders will be dispatch to user self-declared location. I know what you are getting at here but seems like some words could be tightened up.
      Section 9.1 - para 1. Typo with the xref.
      Section 10. The text around the contact header and GRU does not seem right. Are contacts optional in an INVITE? a device with a global reachable IP can still use a GRU. When you say that the B2B contact manipulations should result in a contact header that is usable for call back it sounds like you are saying that current B2BUAs will all do this. Is that true or did it mean to say this can be a problem and they need to do this? The text here just seems to a a bit out of sync with the phone-bcp. Just have a look at this section and see if you think any changes are needed.
      Section 10. Use of PAI. Need to discuss how this works with anonymous call. Places like women's shelters, or many phones in some legal jurisdictions, typically configure all calls to be anonymous in the 3325 sense yet it seems like they still need call back from emergency call to work. I also wonder about how the spec-T would work. If the solutions requires every service provider to have a spec-T with every psap, this does not seem feasible. How does the PAI not get removed when passing it to out of the domain of the service prover and too the psap?
      Section 14. 2nd para. At the time this was first written, this was true, however, at this point of time the IETF does have consensus about keying for SRTP. It seems that given that security is desirable, we should use the agreed on keying solution.
    6. Cullen Jennings: Comment [2010-03-08]:
      (blank)
    7. Pete Resnick: Discuss [2011-04-24]:
      9.1: There is no discussion here of the security and privacy implications of continuing a call without TLS, and there is no such information in the Security Considerations section. For example, if TLS cannot be established, should I give a more coarse-grained location? Should I use some mechanism to encrypt the location? Somewhere this needs to be discussed.
      (The remainder of this discussion, like that for draft-ietf-ecrit-phonebcp, is for the IESG and need not be addressed by the WG at this time.)
      There are several places from 6.5 on which contain *very* normative text. I've noted a few below. I don't think they belong in this document, as the document itself states in section 2.
      6.5 paragraph 2, from "For this reason" to the end, is normative language. Not appropriate for this document.
      6.9 paragraph 2 and 4: More normative language. The references are sufficient.
      6.10: "When validation fails, the location given must not be used for an emergency call." This is normative language that probably doesn't belong here.
      Sections 9-15 are in large part redundant with draft-ietf-ecrit-phonebcp, and have lots of normative statements.
      It is again not clear to me whether this document (or parts of this document) or draft-ietf-ecrit-phonebcp intends to be framework, or "best current practice", or applicability statement, etc. One way or the other, this document should get rid of its normative text, but what the resultant document set should look like needs to be discussed.
    8. Pete Resnick: Comment [2011-04-24]:
      General comment: Some of the language seems more SIP-centric than it needs to be, and most of the document is not SIP-centric. It provides important information to people implementing emergency calling services irrelevant of protocol. I've given a couple of specifics below.
      "The IETF has historically refused to create national variants..." seems rather judgemental. How about "The IETF has historically not created national variants..."
      No mention in made in the intro paragraph of section 3 regarding manual config (where neither measurment nor LCP is used).
      Example in section 3: Why does the phone get its location both at boot time and at emergency call time? The latter would seem to suffice. Belt and suspenders? Isn't location something that gets periodically updated by most devices anyway?
      Section 3, Alice example: Why is SIP REGISTER even part of this discussion? Seems to be that SIP register could occur before or after contacting a LIS, and is not really part of emergency calling at all.
      The dial string appears only to be retrieved at boot time. Doesn't it have to be periodically refreshed to make sure that the current local dial string is correct based on current location?
      Section 3, top of p. 11: "initial LoST query [M3] to learn a URI for use if the LoST query fails during an emergency call". If the LoST query fails during an emergency call, there is no guarantee that the URI that you got at boot time will be valid anyway. Given that, why isn't there a generic hard-coded "pray and hope someone will help" URI that I can use if the LoST query fails? That is, why do I have to do that initial LoST query at all?
      Section 6.2.1: "The use of the mechanism introduces the possibility of users falsely declaring themselves to be somewhere they are not. As an aside, normally, if an emergency caller insists that he is at a location different from what any automatic location determination system reports he is, responders will always be sent to the user's self-declared location. However, this is a matter of local policy and is outside the scope of this document."
      I don't understand the hedge. It seems perfectly reasonable to say: "The use of the mechanism introduces the possibility of users falsely declaring themselves to be somewhere they are not. However, this is generally not a problem in practice. Commonly, if an emergency caller insists that he is at a location different from what any automatic location determination system reports he is, responders will always be sent to the user's self-declared location."
      It doesn't sound "outside the scope of this document" at all.
      6.2.1 makes more sense to me at the end of section 6.2 instead of the beginning.
      6.2.4: Location beacons are end-system measured location mechanisms, not network measured.
      6.6 paragraph 1 seems much more about *how* one gets location than *when*. What you are saying here is that if you are getting netwok measured location information, you had better be asking the local network and not some VPN. In the case of NATs, again it's not timing, but mechanism that is important: You had better pass your globally visible address corresponding to your local network and not your NAT address when talking to an LCP.
      6.6 paragraph 2: Once per day for a mobile device seems like an extremely low rate. Maybe add a sentence like, "For networks with mobile devices, much higher refresh rates could be expected."
      6.7: Why not change section title to simply "Conveying location"? SIP is the example in this section, not the point of it (AFAICT).
      6.10: "When validation fails, the location given must not be used for an emergency call." What if I have no other location information? Should I not send something? Or is this supposed to be covered in 6.11 (in which case a forward reference would be useful)?
    9. Robert Sparks: Comment [2010-04-14]:
      (blank)
    10. Sean Turner: Discuss [2011-04-28]:
      The IETF LC was issued in 2010-02. The IPR disclosure was filed in 2010-08 and obviously wasn't in the IETF LC. Has the IPR disclosure been discussed by the WG?
    11. Sean Turner: Comment [2011-04-28]:
      I agree with Pete's first discuss. Is this addressed somewhere else in the SIP stack of documents (i.e., if you don't use security an attacker can ...).
    12. Magnus Westerlund: Comment [2010-03-11]:
      Section 1: PSAP is not explained in this section, please write out on first usage
      Section 1: NENA (National Emergency Number Association):
      I guess that this is an USA National association, if that is true please make it clear.
      Section 6.2.2: "The threshold for when interior location is needed is approximately 650 square meters. This value is derived from fire brigade recommendations of spacing of alarm pull stations. However, interior space layout, construction materials and other factors should be considered."
      In this type of reference it would be good to specify which fire brigade that has this recommendations. I would be highly surprised if the California recommendations are exactly the same as the one in Stockholm.

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. SIP (Session Initiation Protocol) Usage of the Offer/Answer Model (Informational)
    draft-ietf-sipping-sip-offeranswer-14
    Token: Robert Sparks
    Discusses/comments (from ballot 2807):
    1. Pete Resnick: Discuss [2011-04-27]:
      I saw no followup to Juergen Schoenwalder's secdir review, in particular the following:
      It seems all these relevant specifications are on the standards track while this clarification, which tries to handle situations that can lead to "failed or degraded calls", is submitted as an Informational document. Should this not be standards track, formerly updating the relevant RFCs? I see in the IESG writeup that this has been discussed before, the proposed move to publish this as Informational still sounds surprising to me as an outsider. If there is consensus to resolve the ambiguities as described in the document, then why not via a standards-track action? Or is the idea that this resolution simply can be ignored or that something very different might be invented? That latter would more speak for Experimental then.
      I tend to agree and would like to hear more of the thinking before I move to No Objection. There is a good deal of "normative sounding" text in this document, so Standards Track or Experimental seems more reasonable.
    2. Sean Turner: Discuss [2011-04-28]:
      Please add some text in the security considerations to point to where the mechanisms to protect the offer/answer exchange from tampering by 3rd parties is located (i.e., point to 4744 and 3261).

    Telechat:

  2. Best Current Practices for NAT Traversal for Client-Server SIP (Informational)
    draft-ietf-sipping-nat-scenarios-15
    Token: Robert Sparks
    Note: Mary Barnes is the document shepherd
    Discusses/comments (from ballot 3568):
    1. Stephen Farrell: Discuss [2011-04-27]:
      Discuss discuss: Hopefully a trivial process point - this has BCP in the title, does RECOMMEND a few things but is listed for informational - what's up there?
      (I see that the intended status was changed back in Feb by Robert so he can probably answer and then I can clear:-)
    2. Stephen Farrell: Comment [2011-04-27]:
      The use of 2119 language here is a tiny bit odd. RECOMMENDED is used a bunch of times, but the doc's informational. I assume that those RECOMMENDED's just replicate what's already in standards-track or BCP documents? Might be worth pointing that out if its true.
    3. Pete Resnick: Comment [2011-04-27]:
      I agree with Stephen's Discuss point.
    4. Sean Turner: Comment [2011-04-28]:
      I agree with Stephen's discuss.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. Real Time Communication on the World Wide Web (rtcweb)
    Token: Gonzalo

    Telechat:

  2. Protocol to Access WS database (paws)
    Token: Dan

    Telechat:

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

6. Management Issues

  1. RFC6193 and media types application/ike-esp and application/ike-esp-encap (Robert Sparks)

    Telechat:

  2. igmp/mld work placement (Jari Arkko)

    Telechat:

  3. Historic and Obsolete (Sean Turner)

    Telechat:

7. Agenda Working Group News

1412 EDT Adjourned

Appendix: Snapshot of discusses/comments

(at 2011-04-28 07:30:02 PDT)

draft-ietf-ecrit-phonebcp

  1. Jari Arkko: Discuss [2011-04-28]:
        I hate to pile on the comments that were already made by others, but I think the
document places unreasonable mandatory requirements on access networks, often
without much actual current practice in the world for doing so. Some examples:

   AN-12 Access networks with range of <10 meters (e.g. personal area
   networks such as Bluetooth MUST provide a location to mobile devices
   connected to them.  The location provided SHOULD be that reported by
   the upstream access network unless a more accurate mechanism is
   available.

A *MUST* requirement for every access network? Most networks today do not do
this, and there are networks where it would be difficult to do so. For instance,
a sensor-only network that runs off stateless address autoconfiguration and has
no DHCP. A SHOULD would be a very reasonable requirement, however.

   AN-14/INT-15 Where a router is employed between a LAN and WAN in a
   small (less than approximately 650 square meters) area, the router
   MUST be transparent to the location provided by the WAN to the LAN.
   This may mean the router must obtain location as a client from the
   WAN, and supply an LCP server to the LAN with the location it
   obtains.  Where the area is larger, the LAN MUST have a location
   configuration mechanism satisfying the requirements of this document.

I think this is another reasonable requirement, but not at a MUST level. A
SHOULD be OK here, I think.

   AN-16 Network administrators MUST take care in assigning IP addresses
   such that VPN address assignments can be distinguished from local
   devices (by subnet choice, for example), and LISs SHOULD NOT attempt
   to provide location to addresses that arrive via VPN connections
   unless it can accurately determine the location for such addresses.

This is a tough requirement. Especially at a MUST level. There are very good
reasons why one might wish to place devices in the same subnet (link local
discovery, for instance).

   ED-46/AN-26 To prevent against spoofing of the DHCP server, elements
   implementing DHCP for location configuration SHOULD use [RFC3118]
   although the difficulty in providing appropriate credentials is
   significant.

This one is a SHOULD, and notes the difficulties. Nevertheless, having this
requirement in a BCP is laughable, because as far as we can tell *no one* on the
entire planet has turned RFC 3118 on. I would suggest deleting this requirement
entirely, or perhaps constructing some other requirement about recommending L2
security be turned on.
  2. Ron Bonica: Comment [2011-04-27]:
    Support most of the discuss positions posted
  3. Stephen Farrell: Discuss [2011-04-26]:
        
(1) Is this stating requirements (if so for whom) or documenting
BCP based on *current* implementations and deployments? 
That's not clear to me and I think it ought be clear for a BCP.

(2) ED-1 has a SHOULD requirement for when its ok to not 
support emergency calls. Saying its driven by user 
expectation seems vague and not that easy for a developer 
to handle. I can see how this could be hard, but I do wonder
if there's not a more objective criterion that could be stated.

(3) ED-48 has  MUST for IPsec or TLS. ED-62 says that if the
TLS handshake fails then location retrieval MUST be retried.
What if IPsec SA establishment fails? (Would the UA know?)

(4) I think the overall use of TLS and IPsec maybe needs to 
be restated perhaps along the lines of "Do try to use TLS,
but if the handshake fails, then for emergency calls only, its 
ok to do everything in clear." 

(5) I'm not sure that you even want to mention IPsec here, 
other than to say that an emergency call might require a 
UA to break some IPsec policy rule. (E.g. if the IPsec policy is 
that all traffic be routed to a VPN g/w.) I may have missed
where that is stated - is that there somewhere or what's the
BCP for that case?
  4. Stephen Farrell: Comment [2011-04-26]:
    (1) Abstract could make it clear if this doc just addresses
BCP for IETF docs or also for others as well, and if others
are included which SDOs?

(2) Is ietf-ecrit-framework required reading or not? Make it
clear.

(3) 6.1 mentions not changing the determination mechanism but
that's only introduced in 6.2. Add a forward reference.

(4) LCP is used without expansion

(5) s/IPSEC/IPsec/
  5. Russ Housley: Discuss [2011-04-21]:
        
  The Gen-ART Review by Miguel Garcia on 20-Feb-2011 lead to a
  discussion, but that discussion has not reached closure yet.
  That discussion needs to reach a conclusion to determine what
  changes, if any, are needed to the document.
  6. Pete Resnick: Discuss [2011-04-24]:
        Some of these might turn out to be comments rather than discussions:

AN-5 and AN-10 seem to conflict. Can you not do network measured location
*instead of* hard-wired location configuration and still not require end system
measured location?

I'm not clear on AN-13/INT-14. If a proxy is providing the location, and the
network is providing, e.g., hard-wired location configuration, why would DHCP or
HELD ever be involved? And does this have anything to do with ED-24?

ED-25-27/INT-19-21. If the endpoint measures or has manual configuration for its
location, it still "SHOULD obtain...after local network config" and "MUST
include [DHCP] options for location acquisition"? That doesn't seem correct.

ED-59/SP-31 and ED-62/AN-29: There's clearly a security consideration here, but
the Security Considerations section is empty except for pointers to two
documents which do not address the security consideration of the downgrade.

Section 12 reads like a big security hole without any attempt at solution. Once
a call is established, shouldn't some sort of security token be exchanged so
that callback can occur securely if necessary?

---
The rest of this is for the IESG and need not be addressed by the WG. I will
move it to a non-blocking comment if all of the rest of the above comments are
cleared.
---

I am very concerned that this document is being put forward as a BCP *and* is
using 2119 language when it is really serving as a conformance statement for
other SDOs. On the one hand, it could be seen as an applicability statement for
implementers of the protocols, expressing what they need to account for in the
use of those protocols. But if it's an AS, then it should be standards track, as
reviewing the interoperation of actual implementations is a reasonable thing,
and BCP is not inappropriate. However, there is no expectation that there is
going to be review of the AS from an interoperability point of view because it
really become a set of conformance requirements imposed by external bodies. So
if interoperability is not going to be checked, the 2119 language is
inappropriate in the first place.

But even if the WG wanted to make this a standards track AS, the 2119 language
in here is *way* outside of the scope of 2119. To pick an example right off the
top:

4.  Which devices and services should support emergency calls

   ED-1 A device or application SHOULD support emergency calling if a
   user could reasonably expect to be able to place a call for help with
   the device.  Some jurisdictions have regulations governing this.

I don't see how the interoperability of that SHOULD could possibly be tested
from an interoperability perspective, which is what 2119 requires for the use of
the keyword. In other places, 2119 language is used reasonably (e.g., "It is
RECOMMENDED that location determination not take longer than 250 ms to obtain
routing location..."), but it's a big mixture.

I think this document should either be informational (without 2119 language at
all) or a standards track AS (with sane 2119 language). But this is important
work and the working group made a conscious decision (with AD approval) to go
forward this way. I'm therefore not willing to hold up this document based on
this process issue. But the IESG really needs to discuss and fix this problem
for the future.
  7. Pete Resnick: Comment [2011-04-21]:
    Editorial: Weird use of the term "element". It's non-obvious to me. I might have
used "entity". Maybe it's understood in this environment.

ED-3 looks like it should be ED/SP statement. I assume that anyone who reads the
second sentence understands why location of the device has anything to do with
recognizing dial strings; I sorta can figure it out, but not my area. I don't
understand what "could" implies in the second sentence.

Editorial: The term "UA" magically appears in 6.9 and is used elsewhere as well.
Is that an "endpoint"?

ED-47: S/MIME is mentioned here without reference. And I'm not clear why S/MIME
is NOT RECOMMENDED here.

Editorial (I think): ED-78 gives an example of "urn:servicetest.sos.fire". Is
there a missing ":" in there?
  8. Dan Romascanu: Discuss [2011-04-27]:
        Part of the issues in the DISCUSS were raised in Bernard Aboba's OPS-DIR review.
I recommend all his review to be addressed. I included in my DISCUSS those
issues that seemed to me critical.

1. A number of the recommendations made would appear to assume an all-IP NG911
"NENA i3" architecture, as opposed to the "NENA i2" transitional architecture.
In those 
cases, the recommendations would represent "Best Future Practice"
rather than 
"Best Current Practice".

In a number of cases normative language appears to be used in ways different
from 
those described in RFC 2119.  In some cases, the term "SHOULD" is used in
situations where statutes or regulations may mandate behavior.

I agree here with Bernard that the BCP status is probably adequate, but in some
places the requirements need clarification.

Bernard also writes: 

Overall, I was left with the question as to whether the
recommendations in this document applied beyond "all-IP"
deployments based on the framework document, to transitional
"NENA i2" environments as well.  I suspect that the "INT"
requirements would also apply to gateways between IP and
legacy PSAPs, but this isn't stated explicitly.  

I also find odd the fact that the document does not refer at least
informationaly to the NENA i2 and i3 architectures. The behavior of the system
and requirements may be different in i2 and i3 environments. There are places
where behavior should be configurable or negotiated to allow for better behavior
in a transitional environment. There are also places where behavior will be
prescribed by local statues or regulations, so that configuration and/or
negotiation is a practical requirement.

2. I had a hard time translating some of the AN (Access Networks related)
requirements. For example:

   AN-5 Access networks supporting copper, fiber or other hard wired IP
   packet service SHOULD support location configuration.  If the network
   does not support location configuration, it MUST require every device
   that connects to the network to support end system measured location.

If I am an operator of an AN that does not support location configuration how
should I read the requirement? Is this an administrative requirement, or should
the network be designed so that devices that do not support end system measured
location (and have it activated?) cannot connect to the network?

3. ED-3 is confusing. I think that it tries to state that string recognition
MUST be supported and that the endpoints SHOULD provide this function, but if
this is not the case the SP MAY do it. If I am correct than this needs to be an
ED/SP requirement, and I would like the cases of exception to be clarified. If I
mis-understood please help me understand, maybe with some text changes.

4. Section 17.2: 

> The
   registration process is Expert review by ECRIT working group, its
   successor, or, in their absence, the IESG.  

I suggest to define this policy as Expert Review as per RFC 5226 and have a
Designated Expert nominated. The designated expert can than use help from ECRIT,
IESG, or other in the future.
  9. Dan Romascanu: Comment [2011-04-27]:
    I support Pete's part of the DISCUSS that states that section 12 points to a
security hole that needs to be addressed
  10. Sean Turner: Discuss [2011-04-28]:
        This is an updated discuss.  

Section 6.1: For the 1st paragraph which entity is the requirement on?  All the
other requirements statements are targeted at an entity or entities.
  11. Sean Turner: Comment [2011-04-26]:
    I support Stephen's discusses 3-5.

draft-ietf-softwire-dual-stack-lite

  1. Wesley Eddy: Discuss [2011-04-25]:
        Section 5.6 is a little strange, since it says that the topic 
is out of scope, but doesn't give any hint as to where this 
information might be found, why it's deemed out of scope, or 
who it would be in-scope for.  I would think this should be
easy to clarify.
  2. Wesley Eddy: Comment [2011-04-25]:
    In section 5.2, the final paragraph should be slightly more 
clear that it's saying to fragment the IPv6 tunnel packet 
into multiple IPv6 fragments, and not the inner IPv4 packet 
into multiple tunnelled IPv6 packets.  It may be worth 
mentioning here also that fragmenting the IPv4 packet instead 
is not a good idea or alternative.

Typos:
- in Section 6.4, "a B4 elements" -> "a B4 element"
  3. Adrian Farrel: Comment [2011-04-24]:
    Thanks for a fine and readble document.

Herewith, a few minor points you might like to look at to improve the document.

---

I was surprised that the following statements use a weak "MAY"

   The B4 element MAY use any other addresses within
   the 192.0.0.0/29 range.

   The AFTR MAY use the well-known IPv4 address 192.0.0.1 

"MAY" is usually used when there is some other more normal behavior, but
you don't say what that is.

---

7.2.  VPN

   Dual-stack lite implementations SHOULD NOT interfere with the
   functioning of IPv4 or IPv6 VPNs.

Seems a bit of an odd use of "SHOULD NOT". I'm not clear whether you
are commentng that "in your view the DS-Lite technology should not 
cause anything to break" or observing that it would be a broken 
implementation that *chose* to interfere with VPN function.

---

8.4.  Sharing global IPv4 addresses

   AFTR shares a single IP to multiple users.

s/to/address with/

---

8.5.  Port forwarding / keep alive

   Work on a control plane to the carrier-grade NAT is done in the PCP
   working group at IETF.  The PCP protocol enables 

What does the second 'P' in "PCP" stand for?
  4. Stephen Farrell: Discuss [2011-04-26]:
        
(1) Where's it say that DNSSEC needs to work through
the B4 thing? I don't know if that's problematic or
not but RFC4033 does say the DNS proxies need to be
security aware for DNSSEC to work (section 6 of 4033)
so that may be worth repeating here.

(2) Is the "SHOULD NOT interfere" language in 7.2
sufficient? I don't know but it seems awfully short. 
Is there anything similar that needs to be said 
about TLS or DTLS?

(3)  8.1 - ought that say "the address ranges in the
pools"? (Instead of the "the address range in the 
pools") 

(4) How would the AFTR impact on anti-spam solutions 
such as DNSRBLs? I think that may warrant a mention.
  5. Stephen Farrell: Comment [2011-04-26]:
    8.3: s/require ALG to work properly/require ALGs
to work properly/ (maybe) There are a few other English
language issues (mainly improper singluar/plurals).
  6. David Harrington: Discuss [2011-04-25]:
        There are a few question I would like to discuss before approving this document.

1) 6.3 makes assumptions, but doesn't prescribe behavior if the assumption is
false.
what should happen if an AFTR runs out of resources due to reassembly?
2)
6.5 why MAY, and not SHOULD or MUST?
3) 7.1 why SHOULD and not MUST? what are
the acceptable exceptions to SHOULD?
4) 7.2 why SHOULD NOT rather than MUST NOT?
what are the acceptable exceptions, what types of interference are
expected/allowed, and how should implementations handle the interference?
5) 7.3
why is this out of scope? 
6) 8.1 s/must not/MUST NOT/
7) 8.2 why SHOULD rather
than MUST? acceptable exceptions? how should implementations respond to the
exceptional case for interoperability?
  7. David Harrington: Comment [2011-04-25]:
    There are a few places where I feel the document could be improved, if the
document is revised.

section 4.1 what is horizontal scaling?
4.2 last sentence duplicates section 1
diagrams would help
6.3 discusses clients, but clients are not defined.
6.4 the English is a little weak; 
8.5 carrier-grade nat is not defined
B.1 s/DCHP/DHCP/
figure 1 uses 10.0 addresses, while the text talks about 192.168 addresses.
are the addresses used consistent with reserved example addresses?
s/concentrartor/concentrator/
B.1.2 SE not defined on first use.
B.2.1 why a.b.c.d rather than 192.0.0.2?
  8. Russ Housley: Comment [2011-04-22]:
      Please consider the editorial comments from the Gen-ART Review by
  Roni Even on 9-Apr-2011.
  9. Robert Sparks: Comment [2011-04-26]:
    Consider adding a short discussion or perhaps an example of how services that
sit on the Internet side of an AFTR (especially those in the same administrative
domain of the AFTR) that need to know which B4 IPv4 traffic came through might
get that information from the AFTR (perhaps using the information in the
extended binding table described in section 6.6). Showing how a location query
in a protocol like HELD (RFC5985) would be answered would be a good example.
  10. Sean Turner: Comment [2011-04-26]:
    The reference for 1918 should be normative based on the following:

  However, it SHOULD operate its own DHCP(v4) server handing out
   [RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home.

draft-ietf-pwe3-fc-encap

  1. Jari Arkko:
  2. Jari Arkko: Comment [2011-04-28]:
    I'm not looking to block the document based on this, but I think we should
discuss in the IESG telechat about this document and what it expects out of the
underlying MPLS network. The combination of requiring no reordering and the
possibility of any error resulting in 30-60 second delays at the FC processing
level is worrisome. Can this statement from the draft be made precise:

   FC PW traffic should only traverse controlled MPLS or MPLS-TP
   networks. The network should enforce policing of incoming traffic and
   network resource/bandwidth allocation so that the FC PW delivery
   quality can be assured. To extend FC across an uncontrolled network,
   FCIP SHOULD be used instead of an FC PW, see [RFC3821] and
   [FC-BB-6].

What exactly is considered a controlled network? What kind of mechanisms are
sufficient for the resource allocation?
  3. Adrian Farrel: Discuss [2011-04-24]:
        I have two issues I would like to resolve with this document before
moving to a "Yes" ballot.

---

I was a little surprised by the mention of MPLS-TP in the Abstract.
I am not sure how "taking advantage of MPLS-TP" is in any way
different from "using an MPLS PW".

It is probably not important, but it feels a bit like marketing-speak
has escaped into your spec.

Later in the document, however, I find:

   MPLS-TP provides mechanisms for communication over MPLS networks with
   very low loss rates and very low probability of reordering, making it
   possible for Fibre Channel ports to be interconnected directly over
   MPLS networks.

I don't see how MPLS-TP provides such mechanisms, but the sentence is
ambiguous because it is not clear from what you have written whether the
networks intrinsically have the qualities described (and MPLS-TP 
provides mechanisms for communicating over them) or whether MPLS-TP
somehow enhances the loss rates and reordering probability. In the
first case, this something of a non-statement; in the second case I
don't think it is true. How about cutting this text?

Later still I find:

   FC PW traffic should only traverse controlled MPLS or MPLS-TP
   networks.

Since all MPLS-TP networks are MPLS networks, I suggest you delete
"or MPLS-TP" from this sentence.

similalry, in the next paragraph:

   As a consequence, resilience of the emulated
   FC service to such outages is dependent upon MPLS-TE/MPLS-TP network.
                                          t
I suggest you change "MPLS-TE/MPLS-TP networks." to "the underlying MPLS
network."

---

This element of the Discuss is for discussion with the IESG. No action  
from the authors is requested.

The procedures for lock-step with ANSI seem worrisome. Do we really need
to go through these hoops, and how vulnerable are we to ANSI delays?

It seems to me that, although [FC-BB-6] is needed in conjunciton to this
spec to get the whole picture, [FC-BB-6] is not actually required as a 
normative reference for the understanding of this spec.
  4. Adrian Farrel: Comment [2011-04-25]:
    Section 3.1

Although you say:

   The fragmentation bits (bits 8-9) are not used by the FC PW protocol.
   These bits may be used in the future for FC specific indications as
   defined in [RFC4385].

It appears from the diagram that you require these bits to be set to
zero, and I suspect that a future extension might interpret the bits.
I think you should be more explicit in the text.

===                                                              

Nits

Section 1
"the TCP protocol"
The P in TCP stands for what? :-)

---

Section 1.1
s/port on far end of the FC link/port on the far end of the FC link/
  5. Stephen Farrell: Comment [2011-04-26]:
    
    
  6. Pete Resnick: Comment [2011-04-27]:
    
    
    I don't think this is worthy of a discuss, but is the byte order for FC PW
Control Word (and other items) specified? Does it need to be in this document?
    
    
  7. Dan Romascanu: Discuss [2011-04-27]:
    
    
        The document has no operational and manageability considerations section, and no
reference to the operational and manageability aspects. I would have expected at
least some considerations about the OAM mapping extensions, as the Pseudowire
(PW) OAM Message Mapping I-D (draft-ietf-pwe3-oam-msg-map-16.txt) does not cover
FC services over PW. 
    
    
  




draft-ietf-sidr-rpki-manifests


  
    
    
  1. Wesley Eddy: Comment [2011-04-20]:
    
    
    A couple of typos:
- period missing at end of first sentence in section 3
- at end of section 5.2 "CAs" should be "CA"
    
    
  2. Stephen Farrell: Discuss [2011-04-26]:
    
    
        
The secdir and apps reviews raise a few issues that are worth
checking/addressing.
I'd expect these should be addressed fairly quickly via a
few email exchanges.

The secdir review is at [1], the apps review is at [2].

[1] http://www.ietf.org/mail-archive/web/secdir/current/msg02651.html
[2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02510.html
 
    
    
    
  3. Russ Housley: Comment [2011-04-21]:
    
    
      Please consider the editorial comments in the Gen-ART Review by
  Francis Dupont on 23-Mar-2011.
    
  




draft-ietf-netext-redirect


  
    
    
  1. Ralph Droms: Discuss [2011-04-26]:
    
    
        1. I'd like to hear the motivation for what seems to be three
different (related) methods for LMA assignment:

a colocated rfLMA/r2LMA, with CBE passed through some unspecified
  mechanism
b separate rfLMA/r2LMA, with CBE created through proxy PBU/PBA
  exchange
c separate rfLMA/r2LMA, with MAG redirected to restart mobility
  session establishment with r2LMA

Am I summarizing the 3 methods correctlt?  I can understand method a
as taking advantage of more efficient/direct communication between
colocated devices.  Method c seems to have the virtues of simplicity
in design and operation.  Where does method b, which seems more
complex than c with none of the efficiencies of a, fit?

2. In section 3, paragraphs 3 and 5 appear to be redundant, specifying
protocol behavior.  I list this issue as a DISCUSS point, because
redenudancy in the specification can result in confusing or
conflicting text.  I suggest simply dropping those paragraphs.

3. If RFC 5142 can be used for mid-session LMA reassignment, why is
there a need for specification of a separate protocol extension for
LMA reassignment at session initiation time?

4. In section 4.1, why is "the MAG SHOULD include [...]" specified as
SHOULD rather than MUST?  This example of "SHOULD" seems to me to need
an explanation: under what circumstances would a MAG not include the
Redirect-Capability option; what is the effect of not including the
option?  This question is partially answered by some text in section
5.1, but that text is kind of redundant with this text in 4.1.  Might
be better to have this rule just in section 5.1 concerning MAG
behavior.
 
    
    
    
  2. Ralph Droms: Comment [2011-04-26]:
    
    
    In section 4.1, the following text is unclear to me:

   When this
   option is included, the MAG may be assigned with another LMA, and the
   assigned LMA may simultaneously create a Binding Cache Entry (BCE).
   Hence, the MAG including this option MUST be able to support runtime
   LMA assignment with and without a creation of a BCE in the runtime
   assigned LMA.

As I understand the architecture of the LMA, the BCE is an
implementation structure in the LMA and not immediately visible to the
MAG.  What change in behavior on the part of the MAG is required to
support these two different scenarios?

Nits:

In section 4.1, BCE is expanded in RFC 5213, which is pointed to in
the Terminology section.  For consistency, no need to expand it here.

In section 4.1, s/There can  zero/There can be zero/

End of section 5.1, s/treat the of the PBA/process the PBA/

In section 5.2, is "LMA" as used in this section equivalent to
"runtime assignment domain" as defined in the terminology section?

Section 7 seems superfluous, and it mentions three configuration
variables but only lists two.

Is there a registry for the Status values defined in section 9?

    
    
  3. Wesley Eddy: Discuss [2011-04-20]:
    
    
        (1) in section 4, why shouldn't the Redirect-Capability S &F bits or the
Redirect K & N bits be set at the same time?  Does it break anything?  It seems
like it should be allowed, with the LMA and MAG (respectively) able to determine
which to use.

This seems to relate to the rule in section 5.2 about not cross-assigning
IPv4-only LMAs to IPv6-only MAGs, and vice-versa.

Also, teh configuration variables in section 7 only refer to enable/disable
controls without regard to IPv4 or IPv6, so how to operate with both seems
unclear.

(2) in section 5.2, this paragraph and the decision to leave some of the
prerequisite information needed for LMA assignment out of scope seems like it
could lead to making it difficult to understand what is required for cross-
vendor interoperability of rfLMA and r2LMA implementations.  This should at
least be clarified in this document, which otherwise focuses on the LMA to MAG
interaction.

(3) for the multihoming discussion in section 6, the requirement that all
mobility sessions for an MN be under control of a single LMA seems to be
unnecessary.  How could multiple providers over multiple interfaces be
supported?  Is there motivation for this requirement?  If so, the document needs
to include it, as it doesn't seem clear, and may lead to limits in
applicability. 
    
    
    
  4. Wesley Eddy: Comment [2011-04-20]:
    
    
    Some typos:
-in section 1, "practise" -> "practice"
-in section 1, "due caching" -> "due to caching"
-missing period at end of section 3
-in section 5.1, "at time" -> "at a time"
-in section 5.1, "the of the" -> "the"
    
    
  5. Adrian Farrel: Comment [2011-04-26]:
    
    
    Would be really nice to include a reference to RFC 5213 really early
in the Introduction.

    
    
  6. Stephen Farrell: Discuss [2011-04-24]:
    
    
        
This is quite a long discuss, but probably a bunch of the points are related so
it may be less scary than it seems.

(1) " The trust relationship and coordination management between LMAs within a
PMIPv6 domain is deployment specific and not described in this specification."
Hard to buy that as a way to get interop and security. What if the rfLMA and
r2LMA and MAG are each from different vendors?  Put another way: "adequate
means to secure their inter-LMA communication" with interop implies this needs
to be specified.

(2) "That is, the runtime assignment functionality specified in this document
is not enabled in the r2LMA, or the r2LMA does not belong to the same runtime
assignment domain as the rfLMA, or the r2LMA is down or otherwise unreachable."
That doesn't seem to be a sentence and I don't understand it anyway.

(3) Section 3 says that rfc5142 may be used for a mid-session LMA assignment.
If that works, why bother defining this protocol?

(4) "The rfLMA MUST only assign the MAG with a new r2LMA that it knows the MAG
has a SA with or the MAG and the r2LMA are able to create it dynamically." The
grammar there is pretty bad, but aside from that *how*, in general, could the
rfLMA *know* that the MAG and r2LMA are able to setup an SA? That seems like an
intractable problem if different vendor implementations are in use for rfLMA,
MAG and r2LMA.  "These SA related knowledge issues and trust relationships are
deployment specific in a PMIPv6 domain and in a runtime assignment domain, and
out of scope of this specification. " Doesn't seem acceptable. 

(5) 5.3.2 says the MAG "SHOULD" establish an SA with the r2LMA. Why is that not
a MUST and under what circumstances is it ok to not establish an SA? Is the the
ability to establish an SA mandatory to implement or not?

(6) What happens if the new SA cannot be established? What should the MAG do?

(7) 5.3.3 says to create a tunnel as specified in rfc 5213 - where in (the 89
pages of) 5213 is that specified?

(8) 5.3.1 has a ~~~~ line between rfLMA and r2LMA for LMA assignment, but 5.3.4
says that the r2LMA can be a "any 5213 compliant LMA".  I think that needs more
explanation.  

(9) I assume that this is not controversial for MIPv6 people but it seems quite
odd to me, so I wanted to check. Do you really expect that "A single LMA entity
should have the control over all possible multi-homed mobility sessions the MN
has." is likely to be the case? Seems unlikely to me, but I'll not insist if
told its a general assumption.

(10) "Alternatively, the rfLMA can do all required security processing on the
PBU/PBA, and the communication between the rfLMA and the r2LMA would be
unprotected at the PMIPv6 protocol level.  In this case the runtime assignment
domain MUST implement adequate level of security using other means, such as
layer-2 VPNs." So I don't get that. What data is sent from rfLMA to r2LMA
according to this spec?  
 
    
    
    
  7. Stephen Farrell: Comment [2011-04-24]:
    
    
    (1) Last para of section 3 says "The LMA..." a couple of times.  It probably ok
but would that be better as "An rfLMA..."?

(2) Saying "MAY make use of [RFC5142]" is not very clear - why not describe
what may be used with more than just a reference and make it clear what you
mean?

(3) "The rfLMA MUST NOT assign a MAG using IPv6 transport with a new r2LMA
using IPv4 transport, if the MAG does not indicate support for IPv4 in the
Redirect-Capability mobility option, as there is no guarantee that the MAG
supports switching from IPv6 transport to IPv4 transport.  The same also
applies for assigning a MAG using IPv4 transport with a r2LMA supporting only
IPv6 transport." That could be a good bit clearer - but I think its saying only
provide an r2LMA address where you already know the MAG/rfLMA connection can
work using that address family.

(4) What's a "MAG-rfLMA-r2LMA proxy state"? Is that defined in 5213?

(5) The document could do with an editorial pass for English language 
issues.
    
    
  8. Russ Housley: Discuss [2011-04-21]:
    
    
        
  The Gen-ART Review by Pete McCann on 14-Apr-2011 raised major
  concerns, yet there has been no respons to the review.  The major
  issues raised are:

  Section 5.4: please include a discussion of the possibility of loops
  in the LMA assignment operation and specify the actions that must
  taken by the MAG to detect and resolve them.

  Section 6: This section assues that all of the MN's sessions are able
  to be correlated and that all MAGs will direct their tunnels back to
  the same LMA.  There is no way to enforce that all sessions go to the
  same LMA. 
    
    
    
  9. Russ Housley: Comment [2011-04-21]:
    
    
      Please consider the minor and editorial comments from the Gen-ART
  Review by Pete McCann on 14-Apr-2011.

    
    
  10. Dan Romascanu: Comment [2011-04-28]:
    
    
    Section 7. Configuration variables starts by mentioning that three configuration
variables are defined in the document, and then defines ... two.

Also - why are these called 'configuration variables' and not 'configuration
objects'?
    
    
  11. Robert Sparks: Comment [2011-04-26]:
    
    
    Support Russ' discuss point asking for additional text around the detection and
prevention of loops
    
  




draft-paxson-tcpm-rfc2988bis


  
    
    
  1. Jari Arkko: Comment [2011-04-28]:
    
    
    Thank you for writing this.

I do agree that the issue raised by Adrian needs to be resolved, however.
    
    
  2. Stewart Bryant: Comment [2011-04-27]:
    
    
    I agree with Adrian's discuss.
    
    
  3. Ralph Droms: Comment [2011-04-27]:
    
    
    I notice the file name for the document is draft-paxson-tcpm-rfc2988bis
(not draft-ietf...).  I can't tell from the history or the document writeup,
so may I assume the document was formally adopted as a working group
work item and went through a working group last call?
    
    
  4. Adrian Farrel: Discuss [2011-04-24]:
    
    
        I would like to ballot "Yes" on this document, but the following small issue
needs to be resolved first. It can probably be handled through an RFC Editor
note.

It is odd, IMHO, that a bis makes such small reference to the RFC it is
bis'ing. I think you are completely replacing RFC 2988, so I would 
expect:
- obsoletes in the document header
- a note on obsoletes in the abstract and introduction
- a short section somewhere "Changes from RFC 2988" (I can probably
  deduce this from the notes in the text, but it would be useful to
  write the section.)

Are you also intending that this document updates RFC 1122?
 
    
    
    
  5. Dan Romascanu: Comment [2011-04-27]:
    
    
    1. I support Adrian's DISCUSS.

2. In the Introduction Section: 

> In some situations it may be beneficial for a TCP sender to be more
   conservative than the algorithms detailed in this document allow.
   However, a TCP MUST NOT be more aggressive than the following
   algorithms allow.

s/TCP MUST NOT/TCP sender MUST NOT/

Also this paragraph should probably be moved to a later section, as it is not
common practice to include key-worded statements in the Introduction, and
certainly not before the paragraph that explains the role of keywords notations.
    
    
  6. Robert Sparks: Comment [2011-04-25]:
    
    
    Support Adrian's discuss
    
    
  7. Sean Turner: Comment [2011-04-26]:
    
    
    I support Adrian's discuss.

Sec 6: r/This document requires a TCP to wait/This document requires a TCP
*sender* to wait ?

As noted in the SECDIR review there really needs to be a more overt homage to
the security considerations in 5681.  Something like the following would
suffice:

   Refer to [RFC5681] for TCP congestion control security considerations.
    
  




draft-ietf-ipsecme-ipsecha-protocol


  
    
    
  1. Adrian Farrel: Discuss [2011-04-26]:
    
    
        I have two concerns with this document that I would be happy to discuss.

---

I had some difficulty understanding that Section 7 says:

   The standby member can initiate the synchronization of IKEv2 Message
   ID's under different circumstances.
   o  When it receives a problematic IKEv2/IPsec packet, i.e. a packet
      outside its expected receive window.

This seems to conflict with the DoS avoidance described in Section 11.
It seemed to me that this trigger is not needed since the standby
member since whenever a failure (or forced) take-over has happened the
new active member will know that it has taken over as in the third 
bullet in the list.

Your trade-off here seems to be that you would like to not have to
resynch when the new active member is already in synch, and the only
way you can find out that you are out of synch is by waiting for a
message. 

Similarly the second trigger:

   o  When it has to send the first IKEv2/IPsec packet after a failover
      event.

...can only serve to spread the load of resynch, and is really just a
sub-case of the third trigger in the list.

Yet the third trigger:

   o  When it has just received control from the active member and
      wishes to update the values proactively, so that it need not start
      this exchange later, when sending or receiving the request.

...is rather vague with "just received control" and, in the case of
a very large number of peers, such behavior might very well cripple the
new active member.

So I think you should look again at the tirggers:
- in the light of DoS protection (perhaps the first case can only be
  applied once per peer per take-over)
- in order to take load distribution more explicitly into account.

---

Section 8.2 says:

   For IPsec, there is often a trade-off between security and
   reliability of the protected protocols.  Here again there is some
   leeway for local policy.  Some implementations might accept incoming
   traffic that is outside the replay window for some time after the
   failover event.  Strict implementations will only accept traffic
   that's inside the "safe" window.

Shouldn't you at least be recommending against this behavior? Isn't
this like saying tat an IPsec implementation can sometimes ignore
the fact that it is a security implementation? You should at least
draw out this case in Section 11 if itis really something that is 
considered as an option.
 
    
    
    
  2. Adrian Farrel: Comment [2011-04-26]:
    
    
    I also have a few minor suggestions you might consider to help polish the
document

---

I missed a reference to RFC 6027 in Section 1.

---

Please consider whether a reference figure showing a "cluster" would
help the reader.    

---

Section 1

   This document proposes an extension to the IKEv2 protocol to solve
   the main issues of IKE Message ID synchronization and IPsec SA replay
   counter synchronization and gives implementation advice for others.
   Following is a summary of the solutions provided in this document:

This is a Standards Track document, so you "define" not "propose".

Ditto Section 5

Additionally could you clarify "for others"? I think this is "to
address other issues."

---

It would be helpful if this document made a distinction between 2119
langauge for behavior that is defined in this document and behavior
defined in another document (such as the based spec.) Perhaps use 
lower case for behavior defined elsewhere, and include an explicit
reference to where the behavior is defined.

---                                  

I think:

10.  Interaction with other drafts

...should s/drafts/specifications/

    
    
  3. Stephen Farrell: Comment [2011-04-26]:
    
    
    - I guess there's a 4th case for the list on the end of p10 - that
the newly active member does neither if the peer didn't support this
spec. Maybe worth a mention.

- 5.2 says a "rekey SHOULD follow shortly..." is that really 2119
language or just what's going to happen when you add a large 
increment? If the latter, then maybe s/SHOULD/is likely to/

- 6.4: The sentence "Note that this solution requires that
all these Child SAs either use or do not use Extended Sequence
Numbers" seems odd - I guess you mean "requires that either all 
Child SAs use Extended Sequence Numbers or else that no Child SA 
uses Extended Sequence Numbers," which is different. 

- a nit, 5.1, 1st sentence; s/two counter value/two counter/values/

    
    
  4. Russ Housley: Comment [2011-04-21]:
    
    
      Please consider the editorial comments from the Gen-ART Review by
  Alexey Melnikov on 9-Apr-2011.
    
    
  5. Pete Resnick: Comment [2011-04-26]:
    
    
    Please insert in section 6, just before 6.1.

   All multi-octet fields representing integers are laid out in big
   endian order (also known as "most significant byte first", or
   "network byte order").

(This should have appeared at the top of section 3 of RFC 5996, but
unfortunately it only appears in section 3.1. Just trying to avoid confusion.)
    
    
  6. Robert Sparks: Comment [2011-04-26]:
    
    
    Please add a little more detail to the examples on page 22 (explain what the
tuples represent), and verify that the examples are correct.
    
  




draft-ietf-grow-unique-origin-as


  
    
    
  1. Stewart Bryant: Comment [2011-04-24]:
    
    
    When do the authors anticipate closing their advertisement for sponsorship?

"Others?  Your name could be here......."
    
    
  2. Wesley Eddy: Comment [2011-04-19]:
    
    
    Section 3 seems like it would work better if the 4th paragraph (on ASN
conservation) were moved up to be the 1st paragraph, since it would describe why
the rest of the section is now advisable after the addition of support for
32-bit ASNs, and it also describes what this document means by the "critical
infrastructure" term that's used in some of the other paragraphs in this
section..

Note: idnits complains that the 2119 boilerplate doesn't exist and that 2119 is
included as a reference but not referred to in the document.
    
    
  3. Adrian Farrel: Comment [2011-04-28]:
    
    
    I have a number of comments that don't quite make it to the level of
Discusses, but I would surely welcome it were you to attend to them.

---

I feel it would be worth going the extra mile to clarify what level
of uniqueness you are asking for. You have text such as:

   This document makes recommendations regarding the use of per-node
   unique origin ASNs for globally anycasted critical infrastructure
   services in order to provide routing system discriminators for a
   given anycasted prefix.  (Abstract)

and

   In order to be able to better detect changes to routing information
   associated with crtical anycasted resources, globally anycasted
   services with partitioned origin ASNs SHOULD utilize a unique origin
   ASN per node where possible. (Section 3)

Owing to the lamentable state of the education system, there is 
considerable risk that people will not know whether you mean:

- A globally-unique ASN is allocated per node
or
- A node-unique ASN is allocated per anycasted service

---

The Routing Directorate review by Stig Venaas raised the following
issues that I think should be attended to.

Section 2

Regarding traceroute it says:

    enables service-level identification of a given server.  Tools such
    as traceroute are also used to determine which location a given query
    is being routed to, although it may not reveal local-scope anycast
    instances, or if there are multiple servers within a given anycast
    node, which of the servers responded to a given query, in particular
    when multiple servers within an anycast node are connected to a
    single IP router.  When utilizing these service level capabilities,

Why is local-scope emphasized here? I would think that traceroute
always gives you one node. It may be a particular global node, or a
local node, depending on your location. It may not reveal local-scope,
but it may not reveal global-scope either. They key thing is that you
get only one. And you may not know what the scope is either. Am I
missing something, or should the text be changed?

---

Section 2

Regarding synchronization of instances it says:

    Additionally, while it goes without saying that anycasted services
    should always strive for exact synchronization across all instances
    of an anycasted service address, if local policies or data plane
    response manipulation techniques were to "influence" responses within
    a given region in such a way that those response are no longer
    authentic or that they diverge from what other nodes within an
    anycasted service were providing, then it should be an absolute
    necessity that those modified resources only be utilized by service
    consumers within that region or influencer's jurisdiction.

Isn't this a bit DNS centric? I can think of anycast services where
different nodes intentionally have different content. I'm not sure
if it necessarily is important to restrict it to region or jurisdiction
either. It all depends on the service.

Maybe rephrase this to point out that this may be an important issue,
depending on the service?

---

Nit:

In the paragraph above I found this line:

    a given region in such a way that those response are no longer
                                            ^^^^^^^^
s/response/responses

    
    
  4. Russ Housley: Discuss [2011-04-27]:
    
    
        
  There are three copyright statements in the document.  Please 
  consolidate.

  This document uses RFC 2119 key words.  Please add the usual RFC 2119
  boilerplate.

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
     this document are to be interpreted as described in RFC 2119.

  The Acknowledgements section includes: "Others?  Your name could be
  here......."  Please finalize this section. 
    
    
    
  5. Pete Resnick: Comment [2011-04-25]:
    
    
    It's not clear to me why this document is going for BCP rather than standards
track, but I expect this topic will be discussed in the context of other
documents on the agenda this week, so I'm not going to hold up this one
specifically.
    
    
  6. Dan Romascanu: Discuss [2011-04-27]:
    
    
        Although RFC2119 is included in the references there is no RFC2119 boilerplate.
As far as I can tell there are three capitalized key words in Section 3. While
the first one (the recommendation to utilize a unique origin ASN per node) makes
sense, for the other two it seems that the document could do well without them:

> Furthermore, inconsistent origin AS announcements associated with
   anycasted services for critical infrastructure SHOULD NOT be deemed
   undesirable by routing system reporting functions, but should instead
   be embraced in order to better identify the connectedness and
   footprint of a given anycasted service.

   While namespace conservation and reasonable use of AS number
   resources should always be a goal, the introduction of 32-bit ASNs
   significantly lessens concerns in this space.  Globally anycasted
   resources, in particular those associated with critical
   infrastructure-enabling services such as root and TLD name servers,
   SHOULD warrant special consideration with regard to AS number
   allocation practices during policy development by the constituents of
   those responsible organizations (e.g., the Regional Internet
   Registries).  

'SHOULD NOT be deemed undesirable' and 'SHOULD warrant special consideration'
seem too vague for a capitalized recommendation in a BCP. 
    
    
    
  7. Dan Romascanu: Comment [2011-04-27]:
    
    
    1. ASN should be expanded earlier, probably as soon as the title of the
document.

2. In the IANA Considerations section all the text that follows the statement
that no actions are required from IANA does not seem IANA related and could be
dropped.
    
    
  8. Robert Sparks: Comment [2011-04-26]:
    
    
    If you have not already done so, please coordinate with DNSOP regarding
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-ops/>
and consider whether either document should discuss the other.
    
  




draft-ietf-dnsop-default-local-zones


  
    
    
  1. Ralph Droms: Discuss [2011-04-27]:
    
    
        I'd like to discuss whether this document should
define the lists of prefix names for inclusion
in the IANA registry for special use names
defined in draft-cheshire-dnsext-special-names. 
    
    
    
  2. Adrian Farrel: Comment [2011-04-26]:
    
    
    Will it be clear to IANA exactly what they have to do in order to satisfy the
following text from Section 6?

   IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
   deployed in the reverse tree, delegations for these zones are made in
   the manner described in Section 7.

    
    
  3. Pete Resnick: Comment [2011-04-26]:
    
    
    I don't understand why this is not standards track. It might not be likely that
implementation experience will change this spec, but it's certainly possible.
    
    
  4. Sean Turner: Comment [2011-04-27]:
    
    
    wordsmithing here:

Sec 3: use 2219 language in the following?:

OLD:

   This document recommends that the NS record
   defaults to the name of the zone and the SOA MNAME defaults to the
   name of the only NS RR's target.

NEW:

   It is RECOMMENDED that the NS record
   defaults to the name of the zone and the SOA MNAME defaults to the
   name of the only NS RR's target.
    
  




draft-ietf-trill-adj


  
    
    
  1. Jari Arkko: Discuss [2011-04-28]:
    
    
        I must be missing something obvious, but I thought that the following statement
in the draft was odd:

   Layer 3 packets are already "tamed" when they are originated by an
   end station: they include a hop count and layer 3 source and
   destination addresses. Furthermore, there is no requirement to
   preserve their outer layer 2 addressing and, at least for unicast
   packets, they are addressed to their first hop router.

First of all, not all IP packets have a real layer 3 source address. The
unspecified address may be used in, say, ND packets. Secondly, preserving layer
2 addresses does seem to be important, at least if we expect ND and SLLA options
to work. Can you clarify what you really meant with the above? 
    
    
    
  2. Jari Arkko: Comment [2011-04-28]:
    
    
    The state machines are given as (event,state) => (new state) tuples. I'm kind of
missing the action part, presumably there are events that cause an action to be
taken. Why is not the (event,state) => (action, new state) model not used here?
    
    
  3. Russ Housley: Comment [2011-04-27]:
    
    
      Please consider the editorial comments from the Gen-ART Review by
  Pete McCann on 23-Apr-2011.
    
    
  4. Sean Turner: Comment [2011-04-27]:
    
    
    I went and looked at what's holding up publishing RFCtrill and it's this
document.  If -adj is updating RFCtrill wouldn't it be better to roll this on in
to the base as opposed to having RFC XXXX be updated by RFC XXXX+2?  I know it
happens, but I'm just saying...

If two do get published, is there a plan to  later combine the two?
    
  




draft-ietf-opsawg-mpls-tp-oam-def


  
    
    
  1. Adrian Farrel: Comment [2011-04-27]:
    
    
    Repagination shows that this is really just an 8 page document not the 14 that
it appears. I think some pruning could usefully be done to make it even shorter.

1. What value does the long list of "wrong" OAM expansions in Section 1 serve?

2. Section 2.1 immediately lapses into a discussion of different interpretations
of "OAM" in the source material of other SDOs. This has some interest in
qualifying that the problem exists in other SDOs as well as in the IETF, but
nothing in this section seems to have relevance to the purpose of the document
or to the IETF scope. I wonder about the value of this whole section.

---

The main purpose of the document is clear from the first paragraph of the
Introduction:

   The main purpose of this document is to provide a definition of the
   OAM acronym such that it is useful for the IETF.

But the document does not say *why* this objective is worthwhile.

---

Section 2.1 says:

   However there is some ambivalence in the definition and scope of the
   term "Operation".

This may be true, but as it stands no context or explanation is given, and so
the sentence is not helpful.

---

An alternative to consider, even at this late stage, is to move the recommended
acronym expansions into I-D.ietf-opsawg-oam-overview and scrap this document.
    
    
  2. Russ Housley: Discuss [2011-04-27]:
    
    
        
  The Gen-ART Review by Scott Brim in 12-Apr-2011 raises some major
  concerns, but I have not seen a response.  Please provide a response
  to this review. 
    
    
    
  3. Pete Resnick: Discuss [2011-04-26]:
    
    
        I do not understand why this document is necessary when the definition could be
given in 1 sentence at the top of any document that wants to use it. I do not
understand why this document is going for BCP instead of Informational given
that I don't see the harm in defining the term differently in a document that
wants to use it differently (again, so long as it is appropriately defined). I
do not think that this document should be trying to mandate the definition of a
term IETF-wide when its motivation is only for the MPLS arena of discussion. I
do not think that dead silence from the non-working group portion of the IETF
should be construed as consensus to publish in this particular case, because I
don't see anybody noticing that this definition is the one they like or don't
like until they wish to use it. I would prefer that this document be published
as Informational with WG-only scope, or simply not published at all. 
    
    
  




draft-ietf-pwe3-oam-msg-map


  
    
    
  1. Adrian Farrel: Comment [2011-04-21]:
    
    
    Thanks for addressing the last dregs of my Discuss and Comment

    
    
  2. Russ Housley: Comment [2011-01-05]:
    
    
      Appendix B.3: s/Los/Loss/
    
  




draft-ietf-enum-iax


  
    
    
  1. Adrian Farrel: Comment [2011-04-26]:
    
    
    Clearing my Discuss with a red face. 
The Downrefs reported by idnits are a
combination of very upt-to-date referencing by the authors and a bug in idnits
    
    
  2. Sean Turner: Discuss [2011-04-26]:
    
    
        For some reason, the IPR statement submitted way back in 2008 on version -04
wasn't included in the IETF LC.  The IETF LC is here:

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=9169&tid=1303832421 
    
    
  




draft-ietf-mif-current-practices


  
    
    
  1. Stewart Bryant: Comment [2011-04-25]:
    
    
    I agree with Adrian's Discuss.
    
    
  2. Ralph Droms: Discuss [2011-04-26]:
    
    
        In section 2, are the differentiations between the various mechanisms
in the subsections really differentiated between mobile handset and
desktop systems?  Is making that differentiation germane?  In
particular, does the configuration information for mobile handsets not
come from "DHCP, proprietary configurations systems or manual
configuration"?  Does Android implement a "connection manager"?

In section 2.3, why is RA/SLAAC not mentioned for desktop systems? 
    
    
    
  3. Ralph Droms: Comment [2011-04-26]:
    
    
    I support Adrian's DISCUSS and would like to hear why the details
of the specific operating systems are included.

I'm also a little confused, as I was when reading the problem
statement draft, about the scope of the documents, based
on the WG charter.  Is the scope focused on dealing with
"configuration objects" from different "provisioning domains"
or is it more broadly issues related to multiple simultaneously
active interfaces?

Also, the problem statement document, referenced in this
document, talks about "provisioning domains" and "attachment
to a provisioning domain", while this document says nothing
about provisioning domains.  In my opinion, it would strengthen
the documents if this document provided some additional
motivation for the discussion of provisioning domains in the
problem statement document.

Include a citation for the MIF problem statement at the first
reference in section 1.

The Introduction include OS X in the list of operating systems for
which information has been collected, but I don't see any specific
information (or even any other references) to OS X.

Why are Linux and BSD-based operating systems together in
section 3.2.2, when many of the details are different?


    
    
  4. Adrian Farrel: Discuss [2011-04-24]:
    
    
        I found this document quite a good read, but I have three issues I would like to
Discuss before balloting "no objection".

The first two issues are relatively easily addressed. The third one might result
in the deletion of substantial portions of the text.

---

As with draft-ietf-mif-problem-statement, I would be happier if 
discussion of "routing" was clarified to "first hop selectiong" as
what is going on here is not to be confused with general path 
selection or the type of routing that a router does.

---

Does it actually matter for this document whether the different
interfaces on the host provide unequal levels of service or 
connectivity?  The Abstract seems to think so, but many of the
decisions to be made eixst regardless of this point.

---

While it is, of course, useful to survey existing implementations, 
and the use of public domain information cannot be complained about,
I find it unfortunate that this document presents a comparison of
the behaviors of different products rather than restricting itself
to the (very good) sections that provide a generic anlysis of the
mechanisms in use. 
    
    
    
  5. Pete Resnick: Comment [2011-04-27]:
    
    
    In section 2, I was left a bit confused because I think you reversed the sense
of the opening sentences of 2.1, 2.2, and 2.3. Are you describing the approach,
or summarizing which OSs use which approach? I think you meant to do the former.
For example, in 2.1, do desktop OSs ever use centralized connection management?
If not, perhaps this would be a better opening for 2.1:

   A centralized connection manager does network interface selection
   based on application or user input. This approach to dealing with
   multiple interfaces is employed by many mobile handset operating
   systems.

Similarly for 2.2 and 2.3. I *think* each of these are simply describing the
approach.
    
    
  6. Dan Romascanu: Comment [2011-04-27]:
    
    
    I support Adrian's DISCUSS and Ralph's COMMENT. 
    
  




draft-ietf-sidr-roa-validation


  
    
  




draft-ietf-v6ops-v6-aaaa-whitelisting-implications


  
    
    
  1. Ralph Droms: Discuss [2011-04-26]:
    
    
        I would like to hear more about the reasons for including "universal
deployment" as a potential deployment scenario in this document.  Is
universal deployment in any way a realistic outcome?  Section 6.2
states: 

   it is
   unlikely that DNS whitelisting would, at least in the next several
   years, become universally deployed

and lists several other conditions necessary for universal deployment.
Given all of these roadblocks, is there any real possibility of
universal deployment?

In section 3, in the interest of full disclosure, the way in which
whitelisting "protects [...] users of their domain [...] from having a
negative experience" is by only allowing users who resolve the domain
in question from a whitelisted recursive resolver to have IPv6 access
to the domain.

What would make whitelisting go away?
 
    
    
    
  2. Ralph Droms: Comment [2011-04-26]:
    
    
    From Section 2:

   for some on the
   authorized whitelist

"for all"?   Why would just "some" on the authorized whitelist receive
the AAAA records?

In my opinion, "a few" should be dropped from the first sentence of
section 3.

My first reaction to the third paragraph of section 3 is that the
scenario described in the paragraph would be better solved by a
blacklist rather than a whitelist.  I'd like to know how the
scenario supports the whitelist solution.

In the fourth paragraph of section 4, s/networks,/networks;/

In section 8.2:
s/discovering that they a given domain/discovering that a given domain/

    
    
  3. Wesley Eddy: Discuss [2011-04-26]:
    
    
        In section 7, it seems like there should be more discussion of what happens as
(working) IPv6 deployments proceed, at some point possibly at a rapid pace, and
the burden of adding to whitelists or dealing with requests for whitelist
addition potentially grows quickly.

In the same vein, it seems like whitelists work well well when they're
relatively short; will systems scale as the whitelists grow longer?

These concerns could lead to shared whitelists being commonly used and
distributed amongst sites using rsync or similar means to reduce the
admnistrative burden of updating them, but this has problems of paths between
sites not being the same so there could not be a single universal whitelist,
though there may be one that's close. 
    
    
    
  4. Wesley Eddy: Comment [2011-04-26]:
    
    
    section 8 is "solutions", but it's not really clear what the problem is.  Not
all of the solutions seem to help if the problem is that some users have
suboptimal IPv6 experiences, so they aren't really solutions, so it seems like
the problem is just lack of global advice or position on deployment plans for
whitelisting?   Instead of describing solutions, this is really repetitive of
section 6 on "likely deployment scenarios".  I would suggest combining these
sections and not calling it solutions, as it is a bit confusing.
    
    
  5. Adrian Farrel: Comment [2011-04-24]:
    
    
    Thanks for a document that was both informative and easy to read.

One tiny nit:

Section 3

"someone slower than usual"

s/someone/somewhat/

    
    
  6. Stephen Farrell: Discuss [2011-04-26]:
    
    
        I don't think the language used to describe the "universal deployment"
option is sufficiently negative. For example, I would like to see the phrase
"considered harmful" liberally scattered whenever this option is described. 
Would/did the WG consider adding such a statement at the front of the
document to send out a clear signal? The current text is far too even-handed
IMO, even though it makes what appears to be all the very telling arguments 
against doing that.

Newby question for the IESG: If we as a group did consider that option 
harmful, is it the kind of thing we'd add as IESG note? Is there a process
for that other than just discussing it on the telechat etc? 
 
    
    
    
  7. Stephen Farrell: Comment [2011-04-26]:
    
    
    - Spaces in references are odd and may break some tools. Be better
not do to that I think. Example: "[Evaluating IPv6 Adoption]"

- I'm not sure the reference to world IPv6 day should stay,
it'll be outdated just after an RFC issues so why bother?
(Describing what happens in June in retrospect will be very
interesting but this bit isn't.)

    
    
  8. Robert Sparks: Discuss [2011-04-26]:
    
    
        The document should state explicitly that recursive resolvers must not
themselves
filter records based on the whitelist technique described here. 
    
    
    
  9. Robert Sparks: Comment [2011-04-26]:
    
    
    At section 8.3, it does not follow from not implementing DNS whitelisting that
the internet community
will "choose to take no action whatsoever". Please
rephrase this to reflect the points made elsewhere
in the document that other
approaches to ensuring a good experience during v4/v6 transition are being
pursued. Please consider pointing to the happy-eyeballs work.
    
  




draft-ietf-kitten-digest-to-historic


  
    
    
  1. Adrian Farrel: Comment [2011-04-25]:
    
    
    The purpose of my Discuss has been achieved. The IESG has started a discussion
on the wider relevance of "obsoletion" and "historic". There is no need to hold
up this document any further, and I have cleared my Discuss.
    
  




draft-ietf-dnsop-as112-under-attack-help-help


  
    
    
  1. Jari Arkko: Comment [2011-04-28]:
    
    
    Thanks for writing this document, we do need documents like this to explain
unexpected behaviors and the services provided by network infrastructure.

However, I have one fundamental question. The document's explanation is built on
the premise that responses from AS 112 will be unexpected. I have a hard time
understanding how this can be the case. Either the user's network is
disconnected from the Internet in its entirety, in which case there should not
be DNS queries leaving the network. Or the network allows some traffic and some
DNS queries to be made. What kind of intrusion detection system would cause an
alarm over a properly formed response to a DNS query?
    
    
  2. Pete Resnick: Comment [2011-04-24]:
    
    
    Please see apps-review nits by S. Moonesamy.
    
  




draft-ietf-dnsop-as112-ops


  
    
    
  1. Stewart Bryant: Discuss [2011-04-27]:
    
    
        "The use of a UNIX or UNIX-like operating system (e.g.  FreeBSD [1],
   OpenBSD [2], Linux [3]) is recommended for the construction of AS112
   nodes, "

"Suitable choices of free software to allow hosts to act as BGP
   speakers include,"

It is not appropriate for the IETF to indorse a particular brand of operating
system, or a particular brand of routing software.

Please remove the recommendation, or reword in the form of a factual report on
existing implementations of the protocol.

    
    
    
  2. Adrian Farrel: Comment [2011-04-26]:
    
    
    Should this document comment on who should install AS112 nodes and 
what their incentive is?

---

Isn't the recommendation to use a UNIX or UINIX-like OS in section 3.3
a little too strong for the IETF?  Wouldn't it be enought to make the
statement about the weight of experience, and allow the readed to make
up their own mind? 

---

The statement in Section 3 that...

   A host that is configured to act as an AS112 anycast node should be
   dedicated to that purpose, and should not be used to simultaneously
   provide other services.

Seems an odd requirement. I assume that there is an underlying
requirement such as "AS112 anycast nodes may be epxected to respond
rapidly to very large numbers of DNS queries in a small amount of time.
For this reasons, it is recommended that..."

    
    
  3. Pete Resnick: Comment [2011-04-25]:
    
    
    Please address comments from Subramanian Moonesamy's 16-April Apps Area review.
    
    
  4. Robert Sparks: Comment [2011-04-26]:
    
    
    This project chose a different approach than what's recommended in
<https://datatracker.ietf.org/doc/draft-ietf-grow-unique-origin-as/>. If the
recommendations in that draft had been around at the time the AS112
project were coming together, would it have been built any differently?
If so, would it make sense for this draft to point that out (in case someone
in the future uses this document as a template for a similar project?)
    
  




draft-ietf-ecrit-framework


  
    
    
  1. Stephen Farrell: Discuss [2011-04-28]:
    
    
        (1) Section 3 says: "a caller must obtain his location...prior to making
emergency calls." That seems overstated - if I can't find my location 
are you saying that the call can't happen? (A "should" would be right
here I think.)

(3) How would any of this work with p2psip? (Just checking again.)
 
    
    
    
  2. Stephen Farrell: Comment [2011-04-26]:
    
    
    (1) I support Sean's discuss wrt IPR and LC processes. I'm also unclear
how IPR that affects this informational document would not affect the 
phonebcp document but who knows with these things.

(2) Intro: "there are currently no international standards" - doesn't 112
qualify as an international standard for an existing emergency call system?
Then: "However, the Internet crosses national boundaries, and thus
international standards for equipment and software are required." Don't you
mean that Internet standards are required?

    
    
  3. Russ Housley: Discuss [2010-03-11]:
    
    
        
  The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address this IETF Last Call
  comment: "the Terminology is incomplete, no PSAP for instance" 
    
    
    
  4. Russ Housley: Comment [2010-03-11]:
    
    
      The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.
    
    
  5. Cullen Jennings: Discuss [2010-03-08]:
    
    
        AD needs to check if any new  LC comments came. 

Few small comments as part of my AD review. Typically I would have sent these
before IETF Last Call but given the timing of the IESG calls and next IETF
meeting, I decided we could sort them out as part of IETF Last Call. They are
all small and could likely be fixed with RFC Editor notes after we decide what
they need to say.

6.2.1 Para 2. The statement that user provided location information is less
accurate seems to be contradicted by the later statement that emergency
responders will be dispatch to user self-declared location. I know what you are
getting at here but seems like some words could be tightened up.

Section 9.1 - para 1. Typo with the xref. 

Section 10. The text around the contact header and GRU does not seem right. Are
contacts optional in an INVITE? a device with a global reachable IP can still
use a GRU. When you say that the B2B contact manipulations should result in a
contact header that is usable for call back it sounds like you are saying that
current B2BUAs will all do this. Is that true or did it mean to say this can be
a problem and they need to do this? The text here just seems to a a bit out of
sync with the phone-bcp. Just have a look at this section and see if you think
any changes are needed.

Section 10. Use of PAI. Need to discuss how this works with anonymous call.
Places like women's shelters, or many phones in some legal jurisdictions,
typically configure all calls to be anonymous in the 3325 sense yet it seems
like they still need call back from emergency call to work. I also wonder about
how the spec-T would work. If the solutions requires every service provider to
have a spec-T with every psap, this does not seem feasible. How does the PAI not
get removed when passing it to out of the domain of the service prover and too
the psap?

Section 14. 2nd para. At the time this was first written, this was true,
however, at this point of time the IETF does have consensus about keying for
SRTP. It seems that given that security is desirable, we should use the agreed
on keying solution. 
    
    
    
  6. Cullen Jennings: Comment [2010-03-08]:
    
    
    
    
  7. Pete Resnick: Discuss [2011-04-24]:
    
    
        9.1: There is no discussion here of the security and privacy implications of
continuing a call without TLS, and there is no such information in the Security
Considerations section. For example, if TLS cannot be established, should I give
a more coarse-grained location? Should I use some mechanism to encrypt the
location? Somewhere this needs to be discussed.

(The remainder of this discussion, like that for draft-ietf-ecrit-phonebcp, is
for the IESG and need not be addressed by the WG at this time.)

There are several places from 6.5 on which contain *very* normative text. I've
noted a few below. I don't think they belong in this document, as the document
itself states in section 2.

6.5 paragraph 2, from "For this reason" to the end, is normative language. Not
appropriate for this document.

6.9 paragraph 2 and 4: More normative language. The references are sufficient.

6.10: "When validation fails, the location given must not be used for an
emergency call." This is normative language that probably doesn't belong here.

Sections 9-15 are in large part redundant with draft-ietf-ecrit-phonebcp, and
have lots of normative statements.

It is again not clear to me whether this document (or parts of this document) or
draft-ietf-ecrit-phonebcp intends to be framework, or "best current practice",
or applicability statement, etc. One way or the other, this document should get
rid of its normative text, but what the resultant document set should look like
needs to be discussed. 
    
    
    
  8. Pete Resnick: Comment [2011-04-24]:
    
    
    General comment: Some of the language seems more SIP-centric than it needs to
be, and most of the document is not SIP-centric. It provides important
information to people implementing emergency calling services irrelevant of
protocol. I've given a couple of specifics below.

"The IETF has historically refused to create national variants..." seems rather
judgemental. How about "The IETF has historically not created national
variants..."

No mention in made in the intro paragraph of section 3 regarding manual config
(where neither measurment nor LCP is used).

Example in section 3: Why does the phone get its location both at boot time and
at emergency call time? The latter would seem to suffice. Belt and suspenders?
Isn't location something that gets periodically updated by most devices anyway?

Section 3, Alice example: Why is SIP REGISTER even part of this discussion?
Seems to be that SIP register could occur before or after contacting a LIS, and
is not really part of emergency calling at all.

The dial string appears only to be retrieved at boot time. Doesn't it have to be
periodically refreshed to make sure that the current local dial string is
correct based on current location?

Section 3, top of p. 11: "initial LoST query [M3] to learn a URI for use if the
LoST query fails during an emergency call". If the LoST query fails during an
emergency call, there is no guarantee that the URI that you got at boot time
will be valid anyway. Given that, why isn't there a generic hard-coded "pray and
hope someone will help" URI that I can use if the LoST query fails? That is, why
do I have to do that initial LoST query at all?

Section 6.2.1:

   The use of the mechanism introduces the possibility of users falsely
   declaring themselves to be somewhere they are not.  As an aside,
   normally, if an emergency caller insists that he is at a location
   different from what any automatic location determination system
   reports he is, responders will always be sent to the user's self-
   declared location.  However, this is a matter of local policy and is
   outside the scope of this document.

I don't understand the hedge. It seems perfectly reasonable to say:

   The use of the mechanism introduces the possibility of users falsely
   declaring themselves to be somewhere they are not.  However, this is
   generally not a problem in practice. Commonly, if an emergency caller
   insists that he is at a location different from what any automatic
   location determination system reports he is, responders will always
   be sent to the user's self-declared location.

It doesn't sound "outside the scope of this document" at all.

6.2.1 makes more sense to me at the end of section 6.2 instead of the beginning.

6.2.4: Location beacons are end-system measured location mechanisms, not network
measured.

6.6 paragraph 1 seems much more about *how* one gets location than *when*. What
you are saying here is that if you are getting netwok measured location
information, you had better be asking the local network and not some VPN. In the
case of NATs, again it's not timing, but mechanism that is important: You had
better pass your globally visible address corresponding to your local network
and not your NAT address when talking to an LCP.

6.6 paragraph 2: Once per day for a mobile device seems like an extremely low
rate. Maybe add a sentence like, "For networks with mobile devices, much higher
refresh rates could be expected."

6.7: Why not change section title to simply "Conveying location"? SIP is the
example in this section, not the point of it (AFAICT).

6.10: "When validation fails, the location given must not be used for an
emergency call." What if I have no other location information? Should I not send
something? Or is this supposed to be covered in 6.11 (in which case a forward
reference would be useful)?
    
    
  9. Robert Sparks: Comment [2010-04-14]:
    
    
    
    
  10. Sean Turner: Discuss [2011-04-28]:
    
    
        The IETF LC was issued in 2010-02.  The IPR disclosure was filed in 2010-08 and
obviously wasn't in the IETF LC.  Has the IPR disclosure been discussed by the
WG? 
    
    
    
  11. Sean Turner: Comment [2011-04-28]:
    
    
    I agree with Pete's first discuss.  Is this addressed somewhere else in the SIP
stack of documents (i.e., if you don't use security an attacker can ...).
    
    
  12. Magnus Westerlund: Comment [2010-03-11]:
    
    
    Section 1:
PSAP is not explained in this section, please write out on first usage

Section 1:
NENA (National Emergency Number Association):

I guess that this is an USA National association, if that is true please make it
clear.

Section 6.2.2
   The threshold for when interior location is needed is approximately
   650 square meters.  This value is derived from fire brigade
   recommendations of spacing of alarm pull stations.  However, interior
   space layout, construction materials and other factors should be
   considered.

In this type of reference it would be good to specify which fire brigade
that
has this recommendations. I would be highly surprised if the California
recommendations are exactly the same as the one in Stockholm.
    
  




draft-ietf-sipping-sip-offeranswer


  
    
    
  1. Pete Resnick: Discuss [2011-04-27]:
    
    
        I saw no followup to Juergen Schoenwalder's secdir review, in particular the
following:

It seems all these relevant specifications are on the standards track
while this clarification, which tries to handle situations that can lead to
"failed or degraded calls", is submitted as an Informational document.
Should this not be standards track, formerly updating the relevant
RFCs? I see in the IESG writeup that this has been discussed before,
the proposed move to publish this as Informational still sounds
surprising to me as an outsider. If there is consensus to resolve the
ambiguities as described in the document, then why not via a
standards-track action?  Or is the idea that this resolution simply
can be ignored or that something very different might be invented?
That latter would more speak for Experimental then.

I tend to agree and would like to hear more of the thinking before I move to No
Objection. There is a good deal of "normative sounding" text in this document,
so Standards Track or Experimental seems more reasonable. 
    
    
    
  2. Sean Turner: Discuss [2011-04-28]:
    
    
        Please add some text in the security considerations to point to where the
mechanisms to protect the offer/answer exchange from tampering by 3rd parties is
located (i.e., point to 4744 and 3261). 
    
    
  




draft-ietf-sipping-nat-scenarios


  
    
    
  1. Stephen Farrell: Discuss [2011-04-27]:
    
    
        
Discuss discuss: Hopefully a trivial process point - this has BCP in the title,
does 
RECOMMEND a few things but is listed for informational - what's up there?
(I see 
that the intended status was changed back in Feb by Robert so he can
probably 
answer and then I can clear:-) 
    
    
    
  2. Stephen Farrell: Comment [2011-04-27]:
    
    
    The use of 2119 language here is a tiny bit odd. RECOMMENDED is used a bunch
of times, but the doc's informational. I assume that those RECOMMENDED's just
replicate what's already in standards-track or BCP documents? Might be worth
pointing that out if its true.

    
    
  3. Pete Resnick: Comment [2011-04-27]:
    
    
    I agree with Stephen's Discuss point.
    
    
  4. Sean Turner: Comment [2011-04-28]:
    
    
    I agree with Stephen's discuss.