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.

Valid HTML 4.01 Strict