IESG Narrative Minutes

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

Narrative scribe: John Leslie, Susan Hares, and Richard Barnes (The scribe was sometimes uncertain who was speaking.)

Corrections from: (none)

1 Administrivia

  1. Roll Call 1133 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. pNFS block disk protection (Proposed Standard)
    draft-ietf-nfsv4-pnfs-block-disk-protection-02
    Token: Martin Stiemerling
    Note: Spencer Shepler (sshepler@microsoft.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-nfsv4-pnfs-block-disk-protection):
    1. Benoit Claise: Comment [2012-06-18]:
      I strongly suggest that you remove the conclusion section, which doesn't add anything to this document
    2. Adrian Farrel: Comment [2012-06-13]:
      Please s/draft/document/ in the text
    3. Stephen Farrell: Comment [2012-06-14]:
      I don't get why you use a SHOULD in "A pNFS client operating system that supports block layouts SHOULD recognize this GUID and use its presence to prevent data access to pNFS block devices until a layout that includes the device is received from the MDS." Maybe you mean "SHOULD use its presence" but it reads as if you're saying "SHOULD recognize."
    4. Barry Leiba: Comment [2012-06-14]:
      These are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      -- Section 3 --
      "The pNFS Block Storage partitions are identified in the GPT with GUID e5b72a69-23e5-4b4d-b176-16532674fc34. This GUID has been generated by one of the draft authors for this purpose."
      This won't be a "draft" when it's published, and I don't think it matters who generate the GUID. How about this?:
      "The pNFS Block Storage partitions are identified in the GPT with GUID e5b72a69-23e5-4b4d-b176-16532674fc34, which has been generated for this purpose."
      As I read section 3, what I think I get is that the whole thing defined by this document is this: - A new GUID is defined. - If servers put this GUID in, clients can use is presence to behave better.
      Is that right? If so, I think the last paragraph of the Introduction could be expanded by another sentence or two to make the simplicity fully clear.
      Of course, if that's NOT right, then I'm missing something, so please tell me what. :-)
      Oh, and you might consider updating the date in the last paragraph of Section 3, especially if you have more recent detail of the implementation.
      I don't think the Conclusions section adds anything, and would remove it. "Conclusions" aren't customary in IETF specs, unless there's really something
      to say.
    5. Sean Turner: Discuss [2012-06-19]:
      The following paragraph seems more like fodder for the proto write-up:
      "As of November 2011, many current operating system versions support the GPT, including FreeBSD, Linux and Solaris [GPT-W]."
      Did you comply with the trademark terms of use for FreeBSD, Linux, and Solaris? For example:
      http://www.freebsdfoundation.org/documents/Guidelines.shtml
      If not then it's probably best to just remove this paragraph.

    Telechat:

  2. Media Type Specifications and Registration Procedures (Best Current Practice)
    draft-ietf-appsawg-media-type-regs-14
    Token: Barry Leiba
    Discusses/comments (from ballot draft-ietf-appsawg-media-type-regs):
    1. Adrian Farrel: Comment [2012-06-15]:
      Thank you for Appendix B which made reviewing a lot easier.
    2. Stephen Farrell: Comment [2012-06-18]:
      - "faceted name" could be defined more clearly, I didn't get the "tree.subtree...subtype" notation in section 3. The draft is readable even so, but that was a bit confusing.
      - Just wondering, if another SDO or a vendor registers a media-type and then updates their specification for that, is there an expectation of backwards compatibility? Is that something the designated expert ought take into account?
      - 3.4, typo s/considered to members/considered to be members/
      - 4.1, "better thought of as..." is a bit vague, but I guess this was thrashed by the appsawg. If not, (and only if not), would this be better with a more objective definition of what's not allowed, and with some 2119 language for the designated expert to follow?
      - 4.2 says that different names for the same thing "is discouraged." Why isn't that a SHOULD NOT with the exception being legacy stuff and things that escape into the wild and get too big to ignore?
      - 4.6 says "MUST NOT be confused with" which isn't really meaningful 2119 language - if you want to outlaw saying there are "no security issues" then just saying that might be a good, if odd, MUST NOT. I'd say you could strike the 2119 lanaguage here though.
      - 4.12 refers to MacOSFileTypes, when you go there it says Apple no longer update that page, so a) is that the best reference? b) should this draft say that those file type codes are legacy stuff (if that's the case, I'm not a Mac user:-).
      - 5.3 doesn't actually say how the media types reviewer makes the decision public which I think it ought (presumably via a mail to IANA and some mailing list?). It also doesn't specify any time limits or goals for responsiveness, which would be nice.
      - 5.6 could usefully reference a "good" example registration (maybe as a pointer to somewhere or a new appendix). I think that'd help people who read this later. (Same for section 6, if one exists.)
      - section 6 assumes (I think), but doesn't say that the same expert does this, is appointed by apps ADs etc. Worth adding?
      - section 7 might usefully provide a reference to some known vulnerabilities that have been seen in complex media types. For example, saying something like: "As noted earlier, complex media types can and have caused real security problems, for an example see [CVE-2010-3116]." That [1] was just the first related CVE I saw in a search, anything similar would do fine. The idea is just to emphasise that these are real problems in real systems.
      [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3116
    3. Russ Housley: Comment [2012-06-18]:
      Section 6 says: "2. If there is no entry for their suffix scheme, fill out the template (specified in Section 6.2) and include that with the media type registration. The template may be contained in an Internet Draft, alone or as part of some other protocol specification. The template may also be submitted in some other form (as part of another document or as a stand-alone document), but the contents will be treated as an "IETF Contribution" under the guidelines of BCP 78 [RFC5378]."
      If a document other than an Internet-Draft is used, how do the authors acknowledge that an IETF contribution is being made?
    4. Pete Resnick: Comment [2012-06-19]:
      A fresh look is always nice. This looks pretty darn reasonable. A few questions:
      3.1: "Standards-tree registrations from recognized standards bodies may be submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval."
      Why is it "may be" in the above? Ought it be "should be" or "are"?
      5.1 and 6: I know there was some discussion about having IANA take care of posting to ietf-types, in particular for standards-tree non-IETF registrations. Was it decided that this was *not* going to be done? Or was it simply idle chatting about a potential change but nothing ever came of it? Just curious.
      5.2.1 The mechanism for abandoning provisional registrations was not clear to me. Do you mean they are considered abandoned after some period of time, or an applicant can explicitly abandon them, or something else? It's not spelled out.
    5. Robert Sparks: Comment [2012-06-20]:
      (Updating to reflect email discussion, clearing the discuss point. The list discussion already describes resolution for the remaining comments below)
      In paragraph 5 of section 4.2.1 where it says "all text/* registrations", should it say "all new text/* registrations"? (Similar to how mime-default-charset allowed for existing registrations that didn't follow these instructions.)
      Very minor nits: [snip]
    6. Sean Turner: Discuss [2012-06-19]:
      We sometimes publish drafts directly to historic. Is there a chance that a historic document might register a media type, and if it did what tree would it go in? (btw - if the answer is we'll never ever, ever do this - that's okay I'm just wondering if anybody can think of a time when this might happen and we couldn't use the procedures.)

    Telechat:

  3. Protocol Independent Multicast ECMP Redirect (Proposed Standard)
    draft-ietf-pim-ecmp-03
    Token: Adrian Farrel
    Note: Mike McBride (mmcbride7@gmail.com) is the document shepherd.
    IPR: Cisco's Statement of IPR Related to draft-ietf-pim-ecmp-03
    Discusses/comments (from ballot draft-ietf-pim-ecmp):
    1. Stewart Bryant: Discuss [2012-06-20]:
      The following points are based on the Routing Directorate review by Dimitri Papadimitriou
      To improve the readability of the document the introduction needs to be a separate section from the protocol operation overview and applicability.
      Section 2.1: From the statement "a PIM ECMP Redirect message is sent by an upstream router to notify downstream routers to redirect PIM Joins to the new RPF neighbor via a different interface. . When the downstream routers receive this message, they SHOULD trigger PIM Joins toward the new RPF neighbor specified in the packet."
      It is unclear how the upstream neighbor (preferred upstream router) determines the alternate neighbor.
      Please describe how the proposed algorithm ensures an upstream neighbor will be determined if the selection rules aren't consistent or known among PIM routers. The document specifies the conditions under which ECMP redirect has to be sent not the selection criteria leading to that decision. The alternative would be to specify tie breaking rules (not just the information) such that at least the downstream neighbor can determine the best among the non-desired upstream neighbors. This also contradicts the statement that pruning is to be used to process incoming " Receiving ECMP Redirect" message.
      Section 3.2: "a preference-based process indicates (at least partially) sequential process, whereas the middle paragraphs of that section reads as if the Join messages would be used as a preference discovery process."
      Would it have been better to have been better to have included the preference/metric information in the Hello exchanges?
      Section 3.3: how does the proposed approach behaves in case upstream neighbor changes its preference rules ?
    2. Stewart Bryant: Comment [2012-06-20]:
      The following points are based on the Routing Directorate review by Dimitri Papadimitriou
      Section 2: "This usually leads to inefficient or ineffective use of network resources."
      Do you have a reference to make this statement quantitative ?
      Section 3.5 s/3.5. Packet Format/Message and Option Format
      Coding of preference and metrics type/value shall be specified.
    3. Benoit Claise: Comment [2012-06-18]:
      The following is a COMMENT. However, let's have a chat on this one, because I really would like to understand.
      "When a downstream router receives an ECMP Redirect, and detects that the desired RPF path from its upstream router's point of view is different from its current one, it SHOULD choose to prune from the current path and join the new path. The exact order of such actions is implementation specific."
      Is the last sentence good enough for a standard track document? Should I first join the new path and then prune? Otherwise, I will miss some traffic, right? Because I see: "In essence, a PIM ECMP Redirect message is sent by an upstream router to notify downstream routers to redirect PIM Joins to the new RPF neighbor via a different interface. When the downstream routers receive this message, they SHOULD trigger PIM Joins toward the new RPF neighbor specified in the packet." So by the time the downstream router sends the JOIN, he will losing some traffic. Unless, the upstream router already sent the traffic to its preferred path: maybe I missed it, but I have not seen this specified in the draft.
      Note: if I join the new path and then prune, then I will have duplicate traffic... which is fine with multicast.
      I'm also confused by those SHOULD in the two sentences I mentioned regarding interoperability between downstream and upstream routers.
      - One minor comment. Not sure what you gain by having the following entry in the terminology section
      "o RPF. RPF stands for Reverse Path Forwarding."
      - With some background in PIM, we can deduce if you speak about ECMP for forwarding traffic (downstream) or ECMP for RFP (upstream). However, sometimes is not that easy. For example:
      "ECMPs are frequently used in networks to provide redundancy and to increase available bandwidth. A PIM router selects a path in the ECMP based on its own implementation specific choice. The selection is a local decision."
      First sentence is downstream, while the second one is upstream. Is my understanding correct? Should we clarify the sentences in the document where ECMP is mentioned.
      - "An upstream router MAY choose not to send ECMP Redirects if it becomes aware that some of the downstream routers are unreachable via some links in ECMP bundle."
      SHOULD NOT send?
      - OLD: When a downstream router receives an ECMP Redirect, and detects that the desired RPF path from its upstream router's point of view is different from its current one, it SHOULD choose to prune from the current path and join the new path. The exact order of such actions is implementation specific.
      NEW: When a downstream router receives an ECMP Redirect, and detects that the desired RPF path from its upstream router's point of view is different from its current one, it SHOULD choose to prune from the current path and join the new suggested path. The exact order of such actions is implementation specific.
      This change might be perceived as a detail. However, at that point in time in the draft, it was not clear that the path was suggested in the ECMP Redirect packet, and I was wondering: what if there are 3 ECMPs?
      - There is something wrong with RECOMMENDED and may in the next sentence
      "In such an event, the following actions are RECOMMENDED."
      "The downstream router may select a new RPF neighbor. Among all ECMP upstream routers, the one on the same LAN as the previous RPF neighbor is preferred.
    4. Stephen Farrell: Comment [2012-06-15]:
      (You should be aware of my ignorance of PIM when reading this;-)
      - I don't quite get what this means: "The ECMP links reside between the upstream and downstream routers over the ECMP bundle." I think its just awkwardly phrased though, if it means that the ECMP links are those whose interfaces are part of some ECMP bundle. If it means something else then I didn't get it.
      - 3.1: What's a "preferred" upstream router? Its not clear whose preference is meant.
      - 3.3: Is "on the same LAN" well-defined? Where?
      - 3.5.2: The text after figure 2 says nothing about the 1st set of fields, I guess a reference to where those are described would be good. (Its kind of obvious, but still...)
      - 3.5.2: "unnumbered" - just curious - is that defined somewhere in an RFC?
      - 3.5.2: This doesn't actually define smaller or bigger very well, but its kind of obvious I guess. Be no harm to say it though, esp. for the Metric or just say "same as RFC foo".
      - security considerations: it might be worth stating that the 4601 statement that you SHOULD NOT accept (PIM) protocol messages from anyone from whom you've not got an acceptable PIM Hello also applies here. I believe that is already implied by the current text, (if not, I'd probably make that a DISCUSS), but maybe could be missed by an implementer since you only say "same as PIM assert" in this document.
    5. Russ Housley: Comment [2012-06-15]:
      Please consider the editorial comments from the Gen-ART Review by Miguel Garcia on 11-Jun-2012.
    6. Barry Leiba: Comment [2012-06-14]:
      Thanks for a very clear, very readable document, giving this Applications guy something in Routing that he can read, understand, and see the use of.
      One very small comment: you have a number of SHOULD, SHOULD NOT, and RECOMMENDED keywords (sections 3.2 thru 3.4, and I'm especially thinking of 3.3). It might be nice to include some sense of when it would be reasonable to choose against these, -- if you can identify such situations --. Remember that "RECOMMENDED", in RFC 2119, isn't just about recommendations: it basically means that this is what you MUST do unless you fully understand the ramifications of not doing so.
      -- Security Considerations --
      "Spoofed ECMP Redirect packets may cause the downstream routers to send PIM Joins to an undesired upstream router, and trigger more ECMP Redirect messages."
      Any recommendations on what to do about this?
    7. Pete Resnick: Comment [2012-06-17]:
      I don't think this is worthy of DISCUSSion, and if you ignore these I will not be throwing a fit, but I strongly suggest that you correct the following problems:
      I feel more strongly than Barry about the 2119 keyword usage. He is correct that you can't tell for many of the SHOULDs what circumstances might cause one to violate the requirement. However, as far as I can tell, most of the 2119 keywords are misused:
      3.1: "An upstream router MAY choose not to send ECMP Redirects if it becomes aware that some of the downstream routers are unreachable via some links in ECMP bundle."
      That's not a proper use of MAY. What if it is *not* aware of unreachable downstream routers? Is it then that it MUST send the ECMP Redirects? What protocol requirement is the sentence trying to describe?
      3.2: What are the interoperability implications of each of these three SHOULDs? What bad things happen if I don't follow those requirements? And again, what are the kinds of circumstances where it might be reasonable to violate?
      3.3: It says that "the following actions are RECOMMENDED", but then the first one says that the "downstream router may select a new neighbor". It is an interoperability RECOMMENDation that the router *may* do something? That seems weird. I don't think RECOMMENDED is used correctly here.
      3.5.2: I think it's generally bad form to use 2119 keywords in the definitions of packet formats.
      "Neighbor Address (32/128 bits): Address of desired upstream neighbor where the downstream receiver SHOULD redirect PIM Joins."
      Where else might it send PIM Joins? Don't you rather mean, "Address of neighbor that has requested redirected PIM Joins."? Same with the other SHOULD in this section.
      "This address MUST be associated with an interface in the same ECMP bundle as the ECMP Redirect message's outgoing interface."
      Doesn't this belong in 3.1 or 3.4?
      "an ECMP Redirect message MUST be discarded if the "Neighbor Address" field in the message does not match cached neighbor address."
      Again, doesn't this belong in 3.2 or 3.4? Here, it should simply say, "is discarded".
      I think the same is true for the other two MUSTs in this section.
    8. Sean Turner: Comment [2012-06-19]:
      1) a: The RFC editor will make you remove the reference from the abstract. If you're going to rec it before the draft gets there r/[RFC4061]/(RFC 4061).
      2) s1: Tripped over the definition of EMCP bundle too.
      3) s2 (nit picking): RFC 4601 calls it a hash function not a hash algorithm.
      4) I tripped on the same thing Stephen did in the security considerations.
      5) The paragraph in the security considerations seems to apply to the PIM message type, but since you're also defining a new hello message option shouldn't those be discussed as well? Even it's just: The use of the PIM Hello option defined in this document does not introduce additional security considerations to those already described in [RFC4601]. (assuming that's true of course)

    Telechat:

  4. Improved Recursive DNS Server Selection for Multi-Interfaced Nodes (Proposed Standard)
    draft-ietf-mif-dns-server-selection-09
    Token: Ralph Droms
    Note: Hui Deng (denghui02@hotmail.com ) is the document shepherd.
    IPR: Nokia Corporation's Statement about IPR related to draft-ietf-mif-dns-server-selection-09
    Discusses/comments (from ballot draft-ietf-mif-dns-server-selection):
    1. Ronald Bonica: Comment [2012-06-20]:
      Support Brian's DISCUSS. Please consider rewriting this document. I found it very difficult to parse.
    2. Stephen Farrell: Discuss [2012-06-19]:
      (1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced that implementations would all do the same thing based on this description and with the same input preferences. Is it required that different implementation's behaviour be the same in that case? If not, then lots of the 2119 language ought to be omitted. If so, then I think you need to re-write it more clearly, e.g. using pseudo-code. (Or convince me this is a dumb DISCUSS point:-)
      (2) What is the lifetime of the domain/network information received in a DHCP response? 4.2 is vague about that, talking about "general events." Given that DHCP lease times vary enormously I'd have thought you'd need to be more precise here.
      (3) I don't see how a piece of DNS or DHCP code can know if the criteria in 4.4 apply, at least as they are stated now. For example, for criterion 1, how can a piece of code know that a given network provides a "secure, trusted channel"? There are cases where you can know, but they're not called out here in a way that can be implemented it seems. My concern is that implementations will just assume its ok and then be vulnerable.
      (4) section 7, 3rd para: is the MUST there expected to be enforced? If so how and by whom?
    3. Stephen Farrell: Comment [2012-06-19]:
      (13 items)
    4. Brian Haberman: Discuss [2012-06-15]:
      1. The start of section 4.1 simply states that resolvers should use DHCP to determine which RDNSSes are capable of resolving specific domain names and/or addresses. Given that the mechanism for doing such a query via DHCP is defined in this document, I would suggest that the introductory text in 4.1 give a forward pointer to section 4.2 where the mechanism is actually defined.
      2. The DHCP option for determining which RDNSSes are capable of resolving certain names and prefixes seems incomplete. How many names/addresses should/can the server return within a single instance of the option? In what situations would you recommend returning more than one instance of the option, one per RDNSS? Additional guidance for both implementers and operators would be useful.
    5. Brian Haberman: Comment [2012-06-15]:
      1. I support the DISCUSS points raised by Barry and agree that the document needs a complete review by a native English speaking author.
      2. The packet layout in Figure 5 puts the option-code name (OPTION_DNS_SERVER_SELECT) in the actual field rather than labeling the field as "option-code".
    6. Russ Housley: Comment [2012-06-15]:
      Please consider the editorial comments from the Gen-ART Review by Christer Holmberg on 5-Jun-2012.
    7. Barry Leiba: Discuss [2012-06-14]:
      -- 4.1 -- "The resolver MUST NOT prioritize less trusted RDNSSes higher than trusted"
      But two paragraphs earlier, you say this:
      "The RDNSSes of untrusted interfaces may be of highest priority only if trusted interfaces specifically configure low priority RDNSSes. The non-exhaustive list on figure 4 illustrates how the different trust levels of received RDNSS selection information SHOULD influence the RDNSS selection logic."
      You give a reason for violating that MUST NOT, and Figure 4 has two cases where the less trusted RDNSS is prioritized higher than the trusted one.
      -- IANA Considerations -- Perhaps this is clear enough for IANA, but I see registries specified without their proper names, so I worry:
      1. It looks like the first option code is meant to go into the "BOOTP Vendor Extensions and DHCP Options" registry in the group "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters".
      2. It looks like the second option code is meant to go into the "DHCP Option Codes" registry in the group "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".
      Please either confirm or correct that and put the *exact* names of the registries in (you can look for them in http://www.iana.org/protocols/ ). That avoids problems for IANA later.
    8. Barry Leiba: Comment [2012-06-14]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      This comment is short of being a DISCUSS, because the document is generally OK and I think I've understood it. I have great respect for the work of the non-native-English editors; still, there are some significant bits that are in sufficiently fractured English as to be hard to read and possibly confusing. I'd like to see the native-English-speaking co-editor (or some other volunteer) go over the document and make sure the articles, tenses, plurals, and commas are right. There's a lot of fixing needed.
      -- 4.1 -- "For security reasons the RDNSS selection information MUST be used only when it is safe to do so, see Section 4.4 for details."
      This phrasing is easy to misinterpret ("[x] MUST be used"). I suggest casting it more directly: "For security reasons the RDNSS selection information MUST NOT be used unless it is safe to do so, see Section 4.4 for details."
      -- 4.1 -- "Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent."
      ...and, I presume, the specification of that trust model is out of scope for this document. I suggest you explicitly say that, before you give the (very good) examples:
      "Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent, and the details of determining that trust are beyond the scope of this specification. Trust might, for example, be based on the nature of the interface: an authenticated and encrypted VPN, or a layer 2 connection to a trusted home network, might be considered as trusted, while an unauthenticated and unencrypted connection to an unknown visited network would likely be considered as untrusted. In some situations, an interface might be considered trusted only if it has been explicitly configured to be."
      I remind you that "shall" is a 2119 keyword (synonymous with "must"), and you should be cautious in using it casually.
      "If a DNS response is not proven to be unmolested using DNSSEC, then a node cannot make a decision to prefer data from any interface with any great assurance: any response could be forged, and there is no way to detect the forgery without DNSSEC."
      First, this is a convoluted sentence, with too many negatives; second, you're burying the lede. The important point here is that DNSSEC is necessary, so put it up front:
      "DNSSEC is necessary to detect forged responses, and without it any DNS response could be forged or altered. Unless the DNS responses have been validated with DNSSEC, a node cannot make a decision to prefer data from any interface with any great assurance."
      -- Figures 5 and 6 -- "Reserved: Field reserved for the future. MUST be set to zero."
      It would seem to be useful for those future applications if we made sure that implementations didn't barf on receipt of some future value here. Would this work?:
      "Reserved: Field reserved for the future. MUST be set to zero; MUST be ignored on receipt."
      -- Figure 8 --
      Does this diagram tell me anything useful? If so, I can't figure out what. The only interesting part is in the "black box".
      -- 10.2 -- "An implementation may not be able to determine trust levels without explicit configuration provided by user or administrator."
      OK, if you're going to go there, I have to: do you really think there's any serious possibility of user configuration here, especially in the case of a home-network user? I think that if you mention user configuration, you have to mention that in many, if not most, scenarios, user configuration is not a realistic possibility, and administrator configuration and policy heuristics are usually the only viable mechanisms.
      Other comments; no need to respond to these. Take them or modify them as you please: [snip]
    9. Robert Sparks: Discuss [2012-06-20]:
      It's not clear from the discussion of the premise in the introduction if the document intends to cover the case of receiving different answers to queries into a public namespace depending on which interface the query was made over. For example, getting different results, per interface, for queries into e164.arpa will lead to calls using different technologies with potentially radically different security properties. This needs to be clarified throughout the document and at least discussed in the security considerations.
      Building on Stephen's first discuss point - the algorithm in 4.1 relies on the interfaces having a ordered "trusted" attribute, but the source of that ordering is unspecified. The text recognizes that this is "implementation and/or node deployment dependent". Won't this also typically be application dependent? How is this specification going to help interoperability (or reliably improve the overall performance of individual nodes) without a more consistent definition of how this ordering is obtained? Is it conflating "trust" with "preference"? As Barry notes, additional discussion of what's actually likely to be used for inputs into this ordering is warranted. For example, if an end user disagrees with the typical trust ordering you call out for a cellular interface in scenario 3.2, should he expect to be able to do anything about it?
      This sentence is problematic: "The non-exhaustive list on figure 4 illustrates how the different trust levels of received RDNSS selection information SHOULD influence the RDNSS selection logic." Please rewrite that without the 2119 keyword, and ensure that the actual normative requirement is well specified.
      You call out a problem with local DNS caching for hosts with a single interface that moves between networks, but don't discuss the effects of local caches when this solution is used. Should that discussion be added (at least commenting on whether this solution helps)? Would you change anything in the local cache as interfaces come and go? What do you do with cached results when the preference or trust levels of interfaces change?
      Can you add guidance for how an administrator should chose the prf settings to be configured. Right now, it's hard to see why they wouldn't always chose "High". If you don't want deployments doing that, please say what they should be doing instead. An example deployment scenario showing the value of having different prf levels would go a long way.
      Is there some discussion of the potential for spoofing the RDNSS (by spoofing its source address) when a client is relying on item 4 of section 4.4 somewhere?
    10. Robert Sparks: Comment [2012-06-20]:
      The reader has to make a fairly large leap to understand what "default" and "specific" mean in FIgure 4. Please consider additional introduction to the figure making what those mean more explicit.
      Nit: (two occurrences) s/SHOULD NOT extent lifetime/SHOULD NOT extend the lifetime/
    11. Sean Turner: Discuss [2012-06-21]:
      1) s4.2 & s4.3: Add that the reserved bits MUST be ignored on receipt.
      2) s4.2 & s4.3: Need to specify what to do if the prf value 10 is received.
    12. Sean Turner: Comment [2012-06-21]:
      I agree with Robert and Stepehen's discuss positions.
      0) s1: Includes the following: "The node ought to be able to ask right RDNSS for the information it needs."
      by "right" you mean the RDNSS that holds the data that's been asked for even if it's private. how about:
      "The node ought to be able to query the RDNSS that can resolve the query regardless of whether the answer comes from the public DNS or a private namespace."
      1) s2.2: r/It is worth noting is that/It is worth noting that
      2) s3.1: r/instead CPE should send/instead CPE need only send
      3) s3.3: r/should be send/need to be sent
      r/network may be used./network may be used for all other traffic.
      4) s4.1: I tend to agree with Stephen here. I think what you want to say is that the specific procedures here are non-normative but an implementation must end up with the same result. Pseudocode would help tremendously. Avoiding using lowercase may, shall, should, and must would also help.
      5) s4.1: When you say precedence are you saying that the higher precedence should cause processing of lower precedence ones to be stopped or is this just about picking the next value to process?
      6) s4.1: priority or precedence pick one ;)
      7) s4.2: r/should be contacted/can be contacted
      8) s4.2: r/MAY then/can then
      9) s4.2: r/extent/extend
      10) s4.2:
      OLD: In the case of conflicting RDNSS address is learned from less trusted interface, the node MUST ignore the option.
      NEW: When a conflicting RDNSS address is learned from less trusted interface, the node MUST ignore the option.
      11) s4.4: Agree with Stephen's discuss #3.

    Telechat:

  5. Pseudowire Control Word Negotiation Mechanism Update (Proposed Standard)
    draft-ietf-pwe3-cbit-negotiation-04
    Token: Stewart Bryant
    Note: Andrew Malis (amalis@gmail.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-pwe3-cbit-negotiation):
    1. Adrian Farrel: Discuss [2012-06-18]:
      (Edit to remove piece of Discuss related to process)
      The Abstract could usefully say that this document updates both 4447 and 6073.
      The Introduction talks of updating 4447 but does not mention 6073. A clear statement of what is updated in 6073 is needed.
      Section 3.1: "-i. Local PE MUST send a label withdraw message to remote PE if it has previously sent a label mapping, and label release message to remote PE, and wait until receiving a label release from the remote PE."
      I'm afraid that this can't be parsed. Does it mean:
      "-i. If a PE has previously sent a Label Mapping message to a remote PE, it MUST send a Label Withdraw message to the remote PE, send a Label Release message to remote PE, and wait until it receives a Label Release message from the remote PE."
      I agree with Section 4 as it applies to single hop PWs, but it is not consistent with the text in Section 3. This is because Section 3 includes normative description of behavior of the legacy node that Section 4 claims will work without modification. Viz.
      "When the remote PE successfully processed the label withdraw and label release, and removed the remote label binding, it MUST reset its use of control word with the locally configured preference, and send label mapping as a response of label request with locally configured preference for use of control word."
      I think you need to reword this to show that it represents no change in behavior of the remote PE (i.e. PE1 in your example).
      However, the case for multi-hop PWs seems less simple. I think you describe behavior required at adjecent S-PEs. Does this come for free or is there a requirement to upgrade all S-PEs to support this function?
    2. Adrian Farrel: Comment [2012-06-17]:
      Please s/draft/document/
      Please request the RFC Editor to not split Appendix A across a page break.
      Please capitalise all mesage names to be consistent with RFC 5036, and include the word "message".
    3. Stephen Farrell: Comment [2012-06-18]:
      - Adrian's process questions in his discuss seem reasonable to me, as does the question about how this updates 6073.
      - PE could usefully be expanded in section 1.
      - The abstract talks about the PREFERRED->NOT-PREFERRED transition, but section 2 talks about the NOT-PREFERRED->PREFERRWED transition at PE2. That confused me, since the abstract implies only the PREFERRED->NOT-PREFERRED transition is problematic.
      - Is it "NOT PREFERRED" or "NOT-PREFERRED"? Pick one.
      - Section 5: I assume the security considerations from 4447 and/or 6073 apply here as well. Worth saying?
    4. Brian Haberman: Comment [2012-06-18]:
      I support Adrian's DISCUSS position on the process used to advance this document.
    5. Russ Housley: Discuss [2012-06-20]:
      The Gen-ART Review by Elwyn Davies on 19-Jun-2012 says:
      "Not ready. The proposal for the NOT PREFERRED to PREFERRED transition case does not appear to be compatible with the existing RFC 4447 standard in the way stated and there are a number of other minor issues."
      This led to a dialogue between the authors and Elwyn. That dialogue has not completed as yet, but it is clear to me that some document changes will be needed in the end. I'll clear this DISCUSS position when the dialogue reaches closure and the document updates are made.
    6. Barry Leiba: Discuss [2012-06-21]:
      To start, realize that I am NOT well versed in PWE3 technology, and please tell me if what I'm asking about would simply be clearly understood by those who are.
      In addition to Adrian's rewrite of Section 3 bullet "i" (which I support), I find some other wording clarifications in Section 3 necessary to the understanding of this document:
      "Note: the FEC element in label request message should be the PE's local FEC element. Only if FEC element in label request message could bind together with peer PE's local FEC element, the peer PE sends label mapping with its bound local FEC element and label as a response."
      I do not understand these two sentences. What is "should be" in the first sentence? Is it, or is it not? I'm not necessarily suggesting changing this to 2119 language, but that you make it clear what you're saying. The second sentence is just unparseable, and I'm not at all sure that I understand what it's trying to say.
      "When Local PE changes the use of control word from PREFERRED to NOT PREFERRED, Local PE would be able to re-negotiate the Control Word to be not used following the procedures defined in [RFC4447], and no label request message to peer PE will be needed. In that case, Local PE will always send new label mapping with C-bit reflecting the locally configured preference for use of Control Word."
      I'm having a hard time with this paragraph, and don't think I understand it. I think "to be not used" may be throwing me... apart from its not parsing, I *think* it says that you won't use the Control Word (please use consistent capitalization -- you have it capitalized and not capitalized in the same sentence here) in this case. Is that right? Does that make sense? Then the next sentence talk about using the Control Word. Please rephrase this paragraph, or assure me that anyone who understands PWE3 will get this, and that's just not me.
    7. Barry Leiba: Comment [2012-06-21]:
      This is non-blocking:
      I *very* much appreciate and applaud the work done by our non-native-speaking colleagues. With that in mind, I strongly suggest an editing pass by a native speaker who is familiar with the technology, to correct articles, number, tenses, and punctuation. The RFC Editor will do this, of course, but they are not technology experts, and may make errors that will be hard to detect during AUTH48.
    8. Sean Turner: Comment [2012-06-19]:
      General: If this draft is about generic renegotiation it should just say that ;)
      This is just word smithing: [snip]

    Telechat:

  6. TRILL: RBridge Channel Support (Proposed Standard)
    draft-ietf-trill-rbridge-channel-06
    Token: Ralph Droms
    Note: Erik Nordmark (nordmark@acm.org) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-trill-rbridge-channel):
    1. Stewart Bryant: Discuss [2012-06-20]:
      Section 2.4 Special Transmission and Rate Considerations says:
      "RBridge Channel messages represent a burden on the RBridges and links in a campus and should be rate limited, especially if they are sent as high priority, multi-destination, or multi-hop frames or have an RBridge Channel Alert extended header flag set."
      In the IANA section you have provision for private use and no standards track channels, but you provide no guidance on how implementers and reviewers ensure that they avoid the concern called up in section 2.4
      I am not sure why the multi value restrictions are in place, and the way that it is worded invites work arounds
      "(2) RBridge Channel protocol code points from 0x100 to 0xFF7 require RFC Publication to allocate a single value or IETF Review to allocate multiple values."
      If the goal is to prevent a run on the registry, it would be simpler to make the range smaller and update the RFC if we look like we are goingto run out.
    2. Stewart Bryant: Comment [2012-06-20]:
      "It is anticipated that various protocols operating at the TRILL level will be desired in RBridge campuses."
      I am not sure what it means to "Operate at the TRILL level"
    3. Adrian Farrel: Comment [2012-06-21]:
      I don't think my Comments warrant a Discuss, although I personally "would not have done it like this".
      There is an assumption here that bridge alert (just like router alert) is an acceptable function. I am not convinced and I note RFC 6398 that seems to suggest that router alert is not a good idea in general, although not catastrophic in certain deployments that might be similar to early Trill deployments.
      But I worry that if the popularity of Trill grows, the bridge alert function will cause many of the same problems it caused in IP networks.
      It is worth noting that MPLS (and you do draw the comparison with G-ACh) has a router alert label, but this is not used on the G-ACh.
      At the very least, the use of bridge alert causes packets to be thrown out of the normal forwarding path at each bridge along the path. This means that packets are not treated the same way as data packets and so some of the properties of OAM are lost. (Note that if you want to send an OAM packet to a transit bridge, you will use bridge alert and all other transit bridges along the path up to the intended target will need to inspect the packet.)
      Section 3.2: What is the meaning of "0 - Not an RBridge Channel error frame."
      I didn't find it discussed in the text.
      Why is "15 Reserved"
      And what does "reserved" mean? IANA will need to know whether it means "never to be allocated".
      Why are Channel protocol numbers 0 and xFFF reserved? (And you will need to clarify to IANA that you mean "reserved and not to be allocated".)
      I wasn't clear about the Security aspects. I understand that if a payload protocol needs protection, it is responsible for this itself. However, is there any way to protext the content of the channel header? What would be the consequence of someone tweaking the SL bit?
      Since Trill (and Ethernet) are routed sysetms (unlike MPLS) attacks from outside seem feasible. While you might protect the payload protocols through their own mechanisms, how do you protect the bridges themselves from attacks? The rbridge channel and the bridge alert flag see like vectors for DoS.
      Rate limiting as described in 2.4 provides some mitigation. Maybe you should reference this in the security section.
    4. Stephen Farrell: Discuss [2012-06-19]:
      (1) I think that section 7 needs a 2119 MUST in the 2nd paragraph, that is, I reckon it ought say: "If these services are required for a particular RBridge Channel protocol, they MUST be supplied by that channel protocol." I'd not like to see someone come along and say that its ok that they don't do security because this doesn't.
      (2) "No protection is provided against forging of the ingress nickname in a TRILL Data formatted channel message or the Outer.MacSA in a native RBridge Channel frame. This may result in misdirected return responses or error messages." Can you explain why this is ok? (Not sure if some text change might follow or not.)
      (3) Is this supposed to allow or prevent end-stations talking to one another? (Rather than to RBridges.) I think that ought be clarified, and if its not supposed to happen, then what prevents/detects it? That last might need a bit of text.
    5. Stephen Farrell: Comment [2012-06-19]:
      - 1.2, "Inner.MacDA and inner Ethertype" could maybe do with references/forward-pointers.
      - Section 2 - the figure mapping the message and document structure is great - thanks!
      - Be better to give the figures/diagrams names, numbers and captions. (If editing tools don't make that a pain.) In particular, referring to "the figure above" from 2.1.1 back to the previous sections isn't great.
      - List of error conditions on p11 - I wondered why aren't there any security conditions?
    6. Brian Haberman: Comment [2012-06-15]:
      I only have two minor comments on this document:
      1. The introduction contains the following standalone sentence: "Familiarity with [RFC6325] and [RFC6327] is assumed in this document." What is the purpose of this sentence given that both references are listed as normative?
      2. Section 3 says that these channel messages are subject to the usual TRILL message checks and then lists some checks that are performed. I would suggest making an explicit reference to the document that defines those checks and list any that are not performed on channel messages.
    7. Barry Leiba: Discuss [2012-06-14]:
      This seems a well-written, clear document, which looks technically sound. One small point that should be easy to resolve:
      For the new RBridge Channel Protocols registry:
      1. The correct 5226 policy is "RFC Required" (not "RFC Publication").
      2. What's the reason for requiring IETF Review for more than one request? If someone has a document in the Independent Stream and needs two codes, this means that it has to be re-routed through the IETF Stream or split into two ISE documents -- both of which might not make sense. If it's just that you want someone to sanity-check requests for multiple values, you could make that "IESG Approval" instead of "IETF Review". That would allow the IESG to block multiple-value registrations through the Independent Stream if necessary, but to choose to approve them without forcing the RFC to go through the IETF Stream.
    8. Sean Turner: Comment [2012-06-19]:
      I support Stephen's discuss positions.

    Telechat:

  7. Default Address Selection for Internet Protocol version 6 (IPv6) (Proposed Standard)
    draft-ietf-6man-rfc3484bis-05
    Token: Brian Haberman
    Note: Bob Hinden (bob.hinden@gmail.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-6man-rfc3484bis):
    1. Ralph Droms: Comment [2012-06-21]:
      These comments are provided with the goal of improving the readability and completeness of the information in the document. I apologize for the vagueness of my complaints about readability in comment 4; if everyone else is able to read and understand the text I commented on, feel free to ignore my suggestions.
      1. I suggest adding a sentence explaining the status of IPv6 site-local unicast addresses and why they are included in the procedures in this document. Perhaps something like:
      "IPv6 site-local unicast addresses are deprecated [RFC 4291]. However, some existing implementations and deployments may still use these addresses and, therefore, they are included in the procedures in this specification."
      2. There is a minor conflict between the definitions of IPv6 multicast scopes in RFC 4007 and RFC 4291. I couldn't find an errata about the issue. RFC 4291 lists scope field value 0x03 as "undefined". The information kept by IANA seems to show RFC 4291 for multicast issues in www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml, so, for consistency, this document might want to follow RFC 4291.
      3. Minor editorial suggestion in section 4:
      OLD: It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.)
      NEW: It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination (the "outgoing" interface).
      4. The one part of this otherwise excellent document I find confusing is the candidate source address selection procedure in section 4. It took several readings for me to understand how the rules in that section are applied; e.g., which rules modify, override or are considered in parallel with other rules. I was unable to understand this paragraph (which seems like it should be swapped with the paragraph immediately following it for clarity):
      "If an application or upper layer specifies a source address that is not in the candidate set for the destination, then the network layer MUST treat this as an error. The specified source address may influence the candidate set, by affecting the choice of outgoing interface."
      However, I'm not sure I have any good suggestions for broad improvement. Here are a few small suggestions:
      For all multicast and link-local unicast destination addresses...
      For site-local unicast addresses...
      Perhaps move the paragraph that begins "It is RECOMMENDED..." to the end of section 4 and begin it with "Unless otherwise specified above, it is RECOMMENDED..."
      5. In section 5, the text describing the comparison rules specifies three outcomes for each rule, "greater than," "less than" or "equal to," while none of the rules explicitly defines an "equal to" outcome. For completeness, I suggest adding a sentence explicitly identifying the default result for each rule is "equal to".
      6. Section 5, Rule 3: s/The addresses/If the addresses/
    2. Adrian Farrel: Comment [2012-06-17]:
      Thank you for a comprehensive Appendix B that made reviewing this document much easier.
      I note that the Ballot Write-up includes text from an old version of the Abstract saying: "All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification."
      This strong requirement appears to have been relaxed in the final revision. Please update the ballot.
    3. Stephen Farrell: Comment [2012-06-18]:
      - Source address rule 5.5 has a lowercase "shall" - since it looks like this document has had a fairly careful scrubbing of lowercase 2119 language I wondered if that's really a 2119 MUST or a "can"?
      - Destination address rule 7 discussion: maybe s/6RD/6rd/ ?
    4. Russ Housley: Discuss [2012-06-18]:
      Please consider the security considerations question raised in the Gen-ART Review by Ben Campbell on 14-Jun-2012. I think this question deserves a response.

    Telechat:

  8. vCard Format extension : represent vCard extensions defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) group (Proposed Standard)
    draft-ietf-vcarddav-oma-cab-extensions-03
    Token: Pete Resnick
    Note: Simon Perreault (simon.perreault@viagenie.ca) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-vcarddav-oma-cab-extensions):
    1. Stephen Farrell: Comment [2012-06-18]:
      - The INDEX parameter in 3.1 seems different from the others. I wondered if it really caused this to update 6530, since presumably it could make sense with any multi-valued thing? I assume the argument that it doesn't is that 6530 implementations will ignore it if they don't also support this spec, and I'm ok with that, but just wanted to check.
      - Is LEVEL (3.2) only supposed to be used with hobby, etc.? If so, then maybe you need some 2119 language for that? If not, then maybe say that. I could imagine LEVEL being used e.g. with ROLE or TITLE or maybe even SOUND (at a stretch:-).
    2. Russ Housley: Comment [2012-06-18]:
      In the Gen-ART Review by Joel Halpern on 8-Jun-2012, it was pointed out that a reference two RFC 2119 is needed since there is one MUST.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Source Ports in ARF Reports (Proposed Standard)
    draft-kucherawy-marf-source-ports-05
    Token: Barry Leiba
    Note: The document shepherd is John Levine <johnl@iecc.com>.
    Discusses/comments (from ballot draft-kucherawy-marf-source-ports):
    1. Benoit Claise: Comment [2012-06-18]:
      - Not really a DISCUSS but please consider the following comment (or please justify your choice)
      I looked at http://www.iana.org/assignments/marf-parameters/marf-parameters.xml for the Source-IP definition, and see:
      "Source-IP: IPv4 or IPv6 address from which the original message was received"
      Now at look at Source-Port definition in the draft, and see:
      "TCP source port from which the reported connection originated"
      Don't you think those two definitions should be aligned, as they are related? What I have in mind is: TCP source port from which the original message was received
      - Also, the following sentence doesn't seem quite right
      "When present in a report, it MUST contain the TCP source port matching the "Source-IP" field in the same report, thereby describing completely the origin of the abuse incident."
      Looking at http://tools.ietf.org/html/rfc5965#section-3.2 as a guideline:
      "o "Source-IP" contains an IPv4 or IPv6 address of the MTA from which the original message was received. Addresses MUST be formatted as per section 4.1.3 of [SMTP]."
      I'm wondering, don't you want to write something such as:
      "When present in a report, it MUST contain the TCP source port of the MTA from which the reported connection originated (characterized by the "Source-IP" field in the same report), thereby describing completely the origin of the abuse incident."
    2. Pete Resnick: Comment [2012-06-12]:
      If you wanted to tighten up the syntax, you could do:
      "source-port = "Source-Port:" [CFWS] 1*5DIGIT [CFWS] CRLF"
      since a port number can't be more than 5 digits. But entirely up to you.
    3. Robert Sparks: Comment [2012-06-19]:
      (Summarizing an IM conversation with Murray) This appears to extend 5965 rather than update it. It would also help to more clearly point to exactly what in RFC6591 is being updated.

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Simple Virtual Aggregation (S-VA) (Informational)
    draft-ietf-grow-simple-va-09
    Token: Ronald Bonica
    Note: Peter Schoenmaker <pds@lugs.com> is the document shepherd.
    Discusses/comments (from ballot draft-ietf-grow-simple-va):
    1. Adrian Farrel: Comment [2012-06-21]:
      I'm inclined to agree with Barry about this being an Informational document. But I don't feel strongly.
    2. Stephen Farrell: Comment [2012-06-18]:
      - This is not an easy read, but it ought be. For example, section 2 says: "In both cases simple VA operates in an identical way however when default route is found and is eligible to become a less specific prefix by router's configuration the S-VA may use it." I'd encourage the authors to try get some additional editorial review aiming at significantly increased clarity. (This was also almost a DISCUSS, but isn't since this algorithm doesn't seem to affect security or interop, and if it did, deployments would turn it off quickly.)
      - Various terms (e.g., ABR, ABSR, SPF, Adj-RIBs-In, Loc-RIB, NLRI, ...) could be expanded. The terminology section even seems to use undefined terms.
    3. Russ Housley: Discuss [2012-06-18]:
      The Gen-ART Review by Meral Shirazipour on 11-Jun-2012 raises some significant issues. Please respond to the review
    4. Barry Leiba: Comment [2012-06-19]:
      These are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      This comment is on the edge of being a DISCUSS, but I think I'll try it this way: The document is generally OK, and I have great respect for the work of the non-native-English editors. But there are some significant bits that are in sufficiently fractured English as to be hard to read and possibly confusing. I've noted the worst of them below, but I'd like to see one of the native-English-speaking co-editors go over the document and make sure the articles, tenses, plurals, and commas are right.
      Also, the document cites RFC 2119 and contains 2119 boilerplate, but I can only find one instance of a "MUST". My sense is that this Informational document doesn't need 2119 at all, and that it should be removed.
      The third paragraph of the Abstract doesn't seem to need to be in the Abstract, and I suggest removing it. It's the sort of thing that will do fine in the Introduction only.
      -- Introduction -- "Finally, provider defaults prevents the ISP from being able to detect martian packets. As a result, the ISP transmits packets that could otherwise have been dropped over its expensive provider links."
      Is "martian packets" a term of art, a bit of humour, or a typo? If the first, is it sufficiently well known that it doesn't need explanation? I don't understand it, but, then, I'm not steeped in this topic. From the context, I can tell that it refers to packets that can safely be dropped. [UPDATE... Lookie here!: Thanks to Robert for referring me to RFC 1208. Who knew? Shows you how much I don't know about things routing (or Martian). Never mind this bit, then. :-) ]
      The second sentence, though, reads funny: it seems like you're talking about dropping packets over expensive links (rather than transmitting packets over them). I think this is clearer:
      NEW: As a result, the ISP transmits packets that could have been dropped, and sometimes does so over expensive provider links.
      "Edge routers may install a default route to core routers, to ABRs which are installed on the Point of Presence (POP) to core boundary or to the ASBR routers."
      With all the "to"s, and too few commas, I find it impossible to parse this sentence. Please re-phrase and/or re-punctuate it so it's clearer.
      "In configurations where BGP routes are used to resolve other routes or where BGP routes are redistributed to other protocols which both happen via RIB simple-va can rather then suppressing routes before they are installed in global RIB flag them as "suppress eligible"."
      Another incomprehensible sentence. Please re-phrase and punctuate it.
      -- Security Considerations -- "The authors are not aware of any new security considerations due to S-VA."
      I believe that, but where *do* the security considerations come from? From full VA? If so, then it's probably a good idea to refer the reader to that document for security considerations.
    5. Sean Turner: Comment [2012-06-19]:
      **word smith alert**
      1) abstract: Isn't this about the router running out of memory for the FIB?
      OLD: must upgrade router hardware simply because the FIB has run out of space,
      NEW: upgrade router hardware simply because the server has run out of memory to store the FIB,
      2) s1, 1st para: same issue as #1
      3) s1: what's a partial default? It's the default some of the time?

    Telechat:

  2. Population Count Extensions to PIM (Experimental)
    draft-ietf-pim-pop-count-06
    Token: Adrian Farrel
    Note: Mike McBride (mmcbride7@gmail.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-pim-pop-count):
    1. Benoit Claise: Comment [2012-06-20]:
      - Same question as Stephen on my side. As an OPS A.D., I have to ask: Any connection with the PIM MIB, RFC5060? Or any other MIB module? Or is the new information only available via a show command in the routers (as a starting point because it's experimental)?
      - I found that many acronyms are not expanded (IGMP, MLD, SSM, ASM, etc..), and are missing references. Sure they're known if you know multicast. However, the RFC-editor will flag those, so you might consider easing the RFC-editor lives and at the end the reader not that familiar with multicast
    2. Stephen Farrell: Comment [2012-06-19]:
      Seems like a good experiment. I wondered if there are any MIB modules for PIM and, if so, if the stats here are commensurate with what the MIB calls for measuring.
    3. Brian Haberman: Comment [2012-06-12]:
      I have no objection to the publication of this experimental document and only have a few non-blocking comments. Take them or leave them as you see fit.
      1. The definition of the A/S flag pair seems incorrect. If A=0 and S=1, that does not mean that all receivers are "only SSM" receivers. It means that all receivers are SSM-capable. The group joined will have an influence on whether all receivers are operating in SSM mode.
      2. The idea of tracking if an OIF list crosses a domain boundary is interesting. How would a router know that a particular OIF links to another domain? Is it driven by what protocol caused the OIF to be added (e.g., MSDP in IPv4)? It would be good to expand on how that is determined, if there is a standard way to detect it.
      3. Given the use of a PIM Join attribute, these statistics can aggregate up a multicast distribution tree. What I would be interested in seeing is *how* a network operator accesses these stats. Is it envisioned that a router's CLI will be used since there is no defined way to push/pull the data out via a management interface?
      4. It is unclear to me how useful the time zone information will be. As mentioned in the draft, that information could be contained as an interface attribute. However, that may not be sufficient given multi-access interfaces. Is there more context that can be added as to how these time zone "boundaries" are detected/configured/managed?
    4. Russ Housley: Comment [2012-06-20]:
      The Gen-ART Review by Pete McCann on 19-Jun-2012 raised two questions that deserve a response.
      (1) The Transit and Stub oif-List counts are only 2 octets. Will these fields be large enough to contain the totals for a large multicast distribution tree?
      (2) Are there any alignment constraints on the options? It looks like all the two-octet options come first and the single-octet options come last. However, is this a requirement for any future options that may be defined?
    5. Barry Leiba: Comment [2012-06-14]:
      I had been wondering, at the start of reading this, why it was going to turn out as Experimental, and thank you for explaining that. I wish such explanations were always there, and I think it helps a lot.
    6. Sean Turner: Comment [2012-06-19]:
      s3: Any reason you decided to list the Flags in reverse order from the figure?

    Telechat:

  3. Resolution of The SPF and Sender ID Experiments (Informational)
    draft-ietf-spfbis-experiment-11
    Token: Pete Resnick
    Discusses/comments (from ballot draft-ietf-spfbis-experiment):
    1. (none)

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules (Informational)
    draft-polk-ipr-disclosure-04
    Token: Russ Housley
    Discusses/comments (from ballot draft-polk-ipr-disclosure):
    1. Stewart Bryant: Comment [2012-06-18]:
      I am clearing my discuss on the basis that text of the following form will be added:
      5. A Note About Preliminary Disclosures
      Early disclosures are not necessarily complete disclosures. Indeed, [RFC3979] can be read as encouraging "preliminary disclosure" (e.g., when a new patent application is made), yet a preliminary disclosure might not be updated as new information becomes available later in the standardization process (e.g., when a patent is actually granted). To help prevent early IPR disclosures from becoming stale or incomplete, at important junctures in the standardization process (e.g., before Working Group Last Call or IETF Last Call) WG chairs and ADs are encouraged to request that the Executive Director of the IETF contact those who submitted early IPR disclosures about updating their disclosures.
    2. Benoit Claise: Comment [2012-06-18]:
      - Section 3.3. Requesting WG Last Call
      "Working Group Last Call is a particularly significant milestone for a working group document, measuring consensus within the working group one final time. If IPR disclosure statements have not been submitted, the judgement of consensus by the chairs would be less than reliable."
      While I think I understand what the second sentence means, my first impression while reading it was: what's connection between "IPR disclosure statement" and the consensus "reliability"? Do you want to say that the "judgement of consensus would be based on incomplete assumptions", or something similar?. Most certainly not an issue for English native speakers!
      - I see in section 3.4
      "If the answer to the write-up question is not favorable, or if the chairs did not take any of the actions listed above, the AD might choose to contact the authors and listed contributors to confirm that the appropriate IPR disclosure statements have been filed before advancing the document through the publication process."
      That document would be perfect if the email for that use case would be added in the Appendix A.
      - Section A.4. Reminder to Meeting Presenter
      Isn't the WG chair who is the supposed to send this email? It's signed by "Christopher (as AD)"
      - For new comers (and this draft mainly targets new comers), maybe a sentence or two or how to check whether there is already an IPR associated with a draft. Example: http://tools.ietf.org/html/draft-polk-ipr-disclosure-04 -> an IPR link would appear on the top right hand side Or insert the draft/RFC in https://datatracker.ietf.org/ipr/search/
    3. Ralph Droms: Discuss [2012-06-21]:
      This Discuss point is pretty focused and should be easy to resolve.
      Should there be a mention in section 3.2 that an IPR declaration on a personal draft must be followed up with an IPR declaration on the renamed draft after it is adopted by a working group?
    4. Ralph Droms: Comment [2012-06-21]:
      "Socialize" is a colloquialism that might better be replaced by "discuss"; e.g., from Section 3:
      "In general, these opportunities are encountered during initial public discussion, working group adoption..."
      "When IETF participants wish to promote public discussion of a personal draft in hopes of future adoption by a working group..."
    5. Stephen Farrell: Comment [2012-06-15]:
      - I had a situation where there was an IPR declaration for RFCfoo, but when the RFCfoo-bis draft was being done, nobody went to the IPR holder and asked them to say if the new draft should also have a declaration, and by the time it got to me, nobody from the IPR holder was involved in the WG. That added a bit of delay. Anyway, would it make sense to say that another good thing for a chair/secrerary to do is, when starting work on a bis document where the original RFC has an IPR declaration, please go check with whoever posted that declaration to see if a new one can be gotten or is needed?
      - I guess the above is similar to handling the replaced-by relationship (that the IPR tools follow) so would similar guidance for that situation be worth adding, i.e. "please check the replaced-by" relationship is in order so the right thing will happen at IETF LC at least.
      (Sorry for thinking of those so late in the game)
    6. Pete Resnick: Comment [2012-06-17]:
      In section 3.4, after the quote from the shepherd questionnaire, at the beginning of the last paragraph, I suggest inserting a sentence like, "Shepherds should be asking these questions of the authors directly." It's implicit, but it seems to me not implicit enough.

    Telechat:

  2. Sanctions Available for Application to Violators of IETF IPR Policy (Informational)
    draft-farrresnickel-ipr-sanctions-06
    Token: Russ Housley
    Discusses/comments (from ballot draft-farrresnickel-ipr-sanctions):
    1. Stewart Bryant: Comment [2012-06-11]:
      The policies set out in [BCP79] state that each individual participant is responsible for disclosing or ensuring the disclosure of Intellectual Property Rights (IPR) where:
      - they are aware of the IPR
      - the IPR is relevant to the IETF work they are participating in
      - the IPR is owned by the individual or by a company that employs or sponsors the individual's work.
      I think that you should put an "and" after each list item.
    2. Benoit Claise: Discuss [2012-06-19]:
      Mister farrresnickel,
      "It is important to note that each individual IETF participant has a choice under the IETF's IPR policy. If the individual is unwilling or unable to disclose the existence of relevant IPR in a timely manner, that individual has the option to refrain from participating in IETF discussions about the technology covered by the IPR."
      In the above sentence, I have an issue with "participating in IETF discussions", which IMHO sends the wrong message. For example: I know of an IPR from my company, which I don't plan on disclosing (whatever the reason), and I'm actually fine because I don't participate in the discussions. In other words, I'm fine because I read the emails but don't reply, I listen to the (virtual) WG meeting but don't say a word, I listen to the side discussions at the IETF but don't say a word.
      This also contradicts your text:
      "The policies set out in [BCP79] state that each individual participant is responsible for disclosing or ensuring the disclosure of Intellectual Property Rights (IPR) where:
      "- they are aware of the IPR
      "- the IPR is relevant to the IETF work they are participating in
      "- the IPR is owned by the individual or by a company that employs or sponsors the individual's work."
      I believe that your intent of your paragraph comes from http://tools.ietf.org/html/rfc3979#section-7
      I propose to reuse "must not contribute to or participate in IETF activities" from http://tools.ietf.org/html/rfc3979#section-7 since "activities" is a broader term covering: emails, discussions, meetings, virtual meetings, etc... So actually RFC3979 has got the sentence right.
      OLD: It is important to note that each individual IETF participant has a choice under the IETF's IPR policy. If the individual is unwilling or unable to disclose the existence of relevant IPR in a timely manner, that individual has the option to refrain from participating in IETF discussions about the technology covered by the IPR.
      NEW: It is important to note that each individual IETF participant has a choice under the IETF's IPR policy. If the individual is unwilling or unable to disclose the existence of relevant IPR in a timely manner, that individual has the option to refrain from contributing to and participating in IETF activities about the technology covered by the IPR.
    3. Stephen Farrell: Comment [2012-06-15]:
      Who's that Barry Liebe guy? Must be someone in love with Berlin:-)
    4. Sean Turner: Comment [2012-06-19]:
      Not sure this worth doing but should we state that the rules also apply to remote participants in the contribution paragraph? Maybe add the following as a new second sentence:
      "Remote participants as well as those participating in person at IETF meetings are bound by this definition."
      Also should we add jabber in there to the first sentence?

    Telechat:

3.2.2 Returning Items

  1. Asymmetric Extended Route Optimization (AERO) (Experimental)
    draft-templin-aero-11
    Token: Stewart Bryant
    Discusses/comments (from ballot draft-templin-aero):
    1. Ralph Droms: Comment [2012-06-20]:
      I've cleared my Discusses. Thanks for addressing those points.
      1. (fixed in rev -11)
      2. (addressed in response from author)
      3. (fixed in rev -11)
      4. (was Discuss 1) I think some text is needed in section 6.4.7 to allow for the scenario suggested in this text from the Introduction:
      "For example, when an ingress link neighbor accepts an ordinary redirection message, it has no way of knowing whether the egress link neighbor is ready and willing to accept packets directly without involving an intermediate router"
      The text in section 6.4.7 seems to assume that the egress node will always be willing to accept traffic from the ingress node. Fred explained in e-mail that the egress node can passively ignore the Predirect message by not sending a response Redirect message. However, section 6.4.7 does not explicitly note that the egress node can implement this behavior.
      5. (was Discuss 2) I suggest s/involving/forwarding through/ for clarification.
      6. (was Discuss 3) In section 6.4.8, what is the advantage to the intermediate router snooping the Redirect response and "relaying" the Redirect on to the ingress node without decrementing the hop count, rather than what would seem to be a less unusual method in which the egress node sends the Redirect to the intermediate router, which receives and processes the Redirect, and then sends a corresponding Redirect on to the ingress node?
      7. (was Discuss 4) Fixed in rev -11.
    2. Adrian Farrel: Comment [2012-06-14]:
      Thanks to the author for providing some cocrete examples and motivation, and for moving the experiment to operate over UDP. This addresses my Discuss and I am happy to ballot "yes" and encourage this experiment.
      I would be interested to hear from the author how he sees the applicability of this work to data centers and the NVO3 working group.
    3. Stephen Farrell: Comment [2012-06-13]:
      FWIW, I (still) agree with a bunch of the the other discusses on this.
      You've now stated that the signature scheme is for future study, which is ok for me for an experimental document like this. However, as a comment, I'm still not keen on how 6.4.4 is written right now. It says: you're ok if one of 4 things, but how to achieve the last one (signatures) is not defined here, yet you say "may be obliged" for that.
      I'd suggest getting rid of the 4th bullet entirely and making the following change (or similar) at the end:
      OLD Note that on links in which link-layer address spoofing is possible, AERO nodes may be obliged to require the use of digital signatures applied through means outside the scope of this document. In that case, only the fourth of the above conditions can be accepted in order to ensure adequate data origin authentication.
      NEW Note that on links in which link-layer address spoofing is possible, (which is common) AERO nodes will not be very secure since the data origin authentication defined here is easily spoofed. To address this, future work might define a strong data origin authentication scheme (such as the use of digital signatures) to address this problem.
    4. Brian Haberman: Comment [2012-06-14]:
      I support the experiment being proposed in this document and appreciate the author's responsiveness to my DISCUSS points.
    5. Russ Housley: Discuss [2012-04-24]:
      I understand that the AERO mechanisms were initially designed for NBMA tunnel virtual interfaces, but these mechanisms can also be applied to any multiple access link types that support redirection. That said, I think we need to better characterize the environments where AERO is appropriate, and maybe even more importantly the environments where AERO is not appropriate.
      This position seems to be supported by the Gen-ART Review by Pete McCann on 24-Apr-2012. Please consider the other comments that are include in this review.
    6. Barry Leiba: Comment [2012-04-25]:
      Lots of DISCUSS positions already, and I don't have anything new to add. I'll just say that I support some of the other AD's DISCUSS positions, particularly Brian's and Ron's.
    7. Pete Resnick: Comment [2012-04-22]:
      I agree with Brian's DISCUSS regarding status. In fact, even Experimental seems a bit odd. The document doesn't describe the circumstances under which you would want to experiment and why you wouldn't want to let this out on the Internet as a proposed standard. I think some more explanation, and perhaps an adjustment to status, is needed.
    8. Martin Stiemerling: Comment [2012-04-25]:
      I'm supporting the other DISCUSSes which cover the issues of the draft.
    9. Sean Turner: Comment [2012-06-20]:
      I like Stephen's suggestion for s4.4.

    Telechat:

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. Native IPv6 Behind NAT44 CPEs (6a44) (Experimental)
    draft-despres-6a44-01
    Token: Ralph Droms
    Note: ISE Submission
    Discusses/comments (from ballot draft-despres-6a44):
    1. Stephen Farrell: Comment [2012-06-19]:
      - I wondered if this was fully compatible with IPsec. Seems like it ought to be but I've not thought it through, but maybe the authors have. If so, that might be a good addition to the security considerations. (And who knows, maybe doing this experiment with btns might be a fun and even useful thing to think about.)
      - section 5, typo: s/piecesa/pieces/
    2. Brian Haberman: Comment [2012-06-20]:
      I have no problems with the publication of this document, but I do have some technical issues that would be good to address in it.
      1. Given the assumption that each network that is supporting 6a44 is using a /48, it would be good to state somewhere that operators who are allocated something smaller (e.g., /56) can't use this approach.
      2. Does the 6a44 approach work correctly with RFC 3484 (or 3484bis) given that it is a prefix of last resort but is built out of an ISP's global prefix?
      3. I do not understand why "Overall design simplicity" is considered an "Operational Requirement".
      4. Section 4.4 mentions an applicability scenario where 6a44 applies when a dual-stack CPE is assigned only an IPv4 address. If that is the case, what happens when the CPE is RFC 6204 (or 6204bis) compliant and supports 6rd or DS-Lite? Does someone need to disable those features in the CPE?
      5. Guidance should be given on what random method(s) should be used to generate the Bubble ID.
      6. Section 6.4 (bullet 3) says 6a44 clients MUST limit the size of IPv6 packets they send to on-link destinations to the link MTU - 20. What is meant by on-link in this case? Any device inside the CPE should not be encapsulated.
      7. Rule CT-2 states that protocol 41 encapsulation (direct to the IPv4 destination address) is used when sending to destinations within the same site. How does that rule relate to RR4-2 which seems to say that clients are still sending data to the relay via UDP?
    3. Martin Stiemerling: Comment [2012-06-19]:
      Changed to no object to follow the right process. Just learned something today about ISE and the datatracker. Sorry for the confusion.
      Nonetheless, those issues should be fixed before publication.
      Section 6.2., paragraph 3:
      "An IPv6 packet transmitted from a 6a44 client to another 6a44 client of the same site is encapsulated in an IPv4 packet whose source and destination addresses are the private-IPv4 addresses of the two hosts. The IPv4 packet is that of a complete datagram (its more-fragment bit is set to 0, its offset is set to 0, and its datagram identification may be set to 0). The size of the IPv6 packet SHOULD NOT exceed 1280 octets for off-link destinations, and MUST NOT exceed the link MTU minus 20 octets for on-link destinations (see Section 6.4)."
      You reuse protocol type 41 but do not give any reference to rfc 2473. 2473 lists a number of considerations in terms of ICMP error handling and also for the security of tunneling.
      Section 6.3., paragraph 1:
      "A Bubble is a UDP/IPv4 packet whose UDP payload comprises a "6a44-client IPv6 prefix" field and a "Bubble ID" field, and whose UDP checksum is set to 0."
      Why is the UDP checksum set to zero in this case? Is there any other protection against packet corruption? There is no other means (as far as I can tell) in this case, it is thus required to have the UDP checksum set. Otherwise, the bubbles might carry wrong information back and forth.
      Section 6.4., paragraph 1:
      Reassembly of a fragmented IPv4 datagram necessitates to remember its identifier from reception of the first fragment to reception the last one, and necessitates a timeout protection against packet losses. If such an IP-layer stateful processing would be necessary for 6a44, it would make it more complex than needed, would introduce a vulnerability to denial of service attacks, and would impose that all fragments of a fragmented IPv4 datagram go to the same relay. This last point would be a constraint on how load balancing may be performed between multiple 6a44 relays, and would therefore be detrimental to scalability."
      First of all, fragmentation and de-fragmentation is performed by the IP layer in IPv4. This is the defined standard behavior which is not changed by this specificiation. This is not an argument for increased complexity or scalability. Please reword to state that fragment is not desired, but remove the rest.
      Section 6.4., paragraph 2:
      "For 6a44 processing to remain completely stateless, IPv4 packets containing encapsulated IPv6 packets must never be fragmented. For this:"
      In your case you must mandate that the Don't Fragment (DF) bit in the IPv4 header is set, but you never state this!
      But your text isn't clear about this, as you write that always a complete UDP must arrive and that the IP packets have the more fragments set to 0, but you do not specify anything about the do not fragement bit. I assume you try to talk about the latter one and not the more fragment bit.
      How should the implementation react to ICMP error messages indicating that the packet is too big?
      Section 6.5.1., paragraph 8:
      "TM-3 In the "Bubble sent" state, if the timer expires AND the Attempt count is less than 4, then: the Attempt count is increased by 1; a new bubble is sent with the current Bubble ID; the "bubble sent" state is re-entered with the timer reset to T1."
      It is better to say T1' = 2*T1. This will allow to back-off smoothly.
      Section 6.3., page 14:
      "In a bubble from a 6a44 client to a 6a44 relay, the "6a44-client IPv6 prefix" field is only reserved space for the response. It is set to 0. In a bubble from a 6a44 relay to a 6a44 client, it contains the IPv6 prefix of the client."
      How are the values encoded on the wire. Please clarify this in the text.
      Section 6.3., page 14:
      "In a bubble from a 6a44 client to a 6a44 relay, the "Bubble ID" field contains a randomly chosen value, renewed in circumstances defined in Section 6.5.1. In a bubble from a 6a44 relay to a 6a44 client: if the bubble is a response to a bubble received from the client, the field contains the value found in the received bubble; if the bubble is it is a reaction to a received IPv6/UDP/IPv4 packet whose IPv6 and UDP/IPv4 sources are inconsistent, the field is set to 0. The purpose of this field is a protection against 6a44-relay spoofing attacks (see Section 7)."
      What means 'inconsistent' in technical terms here?

    Telechat:

1212 EDT break postponed

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Sip Traversal Required for Applications to Work (straw)
    Token: Gonzalo

    Telechat:

4.1.2 Proposed for Approval

  1. IMAP Move extension (imapmove)
    Token: Barry

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

Russ: I've reviewed polk-ipr-disclosure new revision; move to approved-announcement to be sent

1217 EDT break

1224 EDT back

5. IAB News We can use

6. Management Issues

  1. NomCom Requirements (Russ Housley)

    Telechat:

  2. Note Well (Pete Resnick)

    Telechat:

  3. Expert for IODEF registrations per RFC-ietf-mile-iodef-xmlreg (Michelle Cotton)

    Telechat:

  4. Assignment of Expert Reviewer for "Pseudowire Switching Point PE sub-TLV Type" sub-registry of the "Pseudowire Name Spaces (PWE3)" registry (Adrian Farrel)

    Telechat:

  5. Proposed Liaison Statement to ITU-T on References to Documents from Other SDOs (Russ Housley)

    Telechat:

7. Agenda Working Group News

Adrian: can we clear farrresnickles, all discusses cleared Russ: put it in approved, I'll call you if any problem Amy: version 7, approved

1246 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-06-21 07:30:15 PDT)

draft-ietf-nfsv4-pnfs-block-disk-protection

  1. Benoit Claise: Comment [2012-06-18]:
    I strongly suggest that you remove the conclusion section, which doesn't add
    anything to this document
  2. Adrian Farrel: Comment [2012-06-13]:
    Please s/draft/document/ in the text.
  3. Stephen Farrell: Comment [2012-06-14]:
    I don't get why you use a  SHOULD in "A pNFS client operating
    system that supports block layouts SHOULD recognize this GUID
    and use its presence to prevent data access to pNFS block
    devices until a layout that includes the device is received from
    the MDS. " Maybe you mean "SHOULD use its presence" but it reads
    as if you're saying "SHOULD recognize."
  4. Barry Leiba: Comment [2012-06-14]:
    These are non-blocking, but please consider them seriously, and feel free to
    chat with me about them:
    
    -- Section 3 --
            The pNFS Block Storage partitions are identified in the GPT with
            GUID e5b72a69-23e5-4b4d-b176-16532674fc34.  This GUID has been
            generated by one of the draft authors for this purpose.
    
    This won't be a "draft" when it's published, and I don't think it matters who
    generate the GUID.  How about this?:
    
            The pNFS Block Storage partitions are identified in the GPT with
            GUID e5b72a69-23e5-4b4d-b176-16532674fc34, which has been
            generated for this purpose.
    
    As I read section 3, what I think I get is that the whole thing defined by this
    document is this: - A new GUID is defined. - If servers put this GUID in,
    clients can use is presence to behave better.
    
    Is that right?  If so, I think the last paragraph of the Introduction could be
    expanded by another sentence or two to make the simplicity fully clear.
    
    Of course, if that's NOT right, then I'm missing something, so please tell me
    what.  :-)
    
    Oh, and you might consider updating the date in the last paragraph of Section
    3, especially if you have more recent detail of the implementation.
    
    I don't think the Conclusions section adds anything, and would remove it.
     "Conclusions" aren't customary in IETF specs, unless there's really something
    to say.
  5. Sean Turner: Discuss [2012-06-19]:
    The following paragraph seems more like fodder for the proto write-up:
    
      As of November 2011, many current operating system versions support
      the GPT, including FreeBSD, Linux and Solaris [GPT-W].
    
    Did you comply with the trademark terms of use for FreeBSD, Linux, and Solaris?
      For example:
    
    http://www.freebsdfoundation.org/documents/Guidelines.shtml
    
    If not then it's probably best to just remove this paragraph.

draft-ietf-appsawg-media-type-regs

  1. Adrian Farrel: Comment [2012-06-15]:
    Thank you for Appendix B which made reviewing a lot easier.
  2. Stephen Farrell: Comment [2012-06-18]:
    - "faceted name" could be defined more clearly, I didn't get the
    "tree.subtree...subtype" notation in section 3. The draft is readable
    even so, but that was a bit confusing.
    
    - Just wondering, if another SDO or a vendor registers a media-type and
    then updates their specification for that, is there an expectation of
    backwards compatibility? Is that something the designated expert ought
    take into account?
    
    - 3.4, typo s/considered to members/considered to be members/
    
    - 4.1, "better thought of as..." is a bit vague, but I guess this was
    thrashed by the appsawg. If not, (and only if not), would this be
    better with a more objective definition of what's not allowed, and with
    some 2119 language for the designated expert to follow?
    
    - 4.2 says that different names for the same thing "is discouraged."
    Why isn't that a SHOULD NOT with the exception being legacy stuff and
    things that escape into the wild and get too big to ignore?
    
    - 4.6 says "MUST NOT be confused with" which isn't really meaningful
    2119 language - if you want to outlaw saying there are "no security
    issues" then just saying that might be a good, if odd, MUST NOT. I'd
    say you could strike the 2119 lanaguage here though.
    
    - 4.12 refers to MacOSFileTypes, when you go there it says Apple no
    longer update that page, so a) is that the best reference? b) should
    this draft say that those file type codes are legacy stuff (if that's
    the case, I'm not a Mac user:-).
    
    - 5.3 doesn't actually say how the media types reviewer makes the
    decision public which I think it ought (presumably via a mail to IANA
    and some mailing list?). It also doesn't specify any time limits or
    goals for responsiveness, which would be nice.
    
    - 5.6 could usefully reference a "good" example registration (maybe as
    a pointer to somewhere or a new appendix). I think that'd help people
    who read this later. (Same for section 6, if one exists.)
    
    - section 6 assumes (I think), but doesn't say that the same expert
    does this, is appointed by apps ADs etc. Worth adding?
    
    - section 7 might usefully provide a reference to some known
    vulnerabilities that have been seen in complex media types. For
    example, saying something like: "As noted earlier, complex media types
    can and have caused real security problems, for an example see
    [CVE-2010-3116]." That [1] was just the first related CVE I saw in a
    search, anything similar would do fine. The idea is just to emphasise
    that these are real problems in real systems.
    
       [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3116
  3. Russ Housley: Comment [2012-06-18]:
      Section 6 says:
      >
      > 2.  If there is no entry for their suffix scheme, fill out the
      > template (specified in Section 6.2) and include that with the
      > media type registration.  The template may be contained in an
      > Internet Draft, alone or as part of some other protocol
      > specification.  The template may also be submitted in some other
      > form (as part of another document or as a stand-alone document),
      > but the contents will be treated as an "IETF Contribution" under
      > the guidelines of BCP 78 [RFC5378].
      >
      If a document other than an Internet-Draft is used, how do the
      authors acknowledge that an IETF contribution is being made?
  4. Pete Resnick: Comment [2012-06-19]:
    A fresh look is always nice. This looks pretty darn reasonable. A few questions:
    
    3.1:
    
       Standards-tree registrations from recognized standards bodies may be
       submitted directly to the IANA, where they will undergo Expert Review
       [RFC5226] prior to approval.
    
    Why is it "may be" in the above? Ought it be "should be" or "are"?
    
    5.1 and 6: I know there was some discussion about having IANA take care of
    posting to ietf-types, in particular for standards-tree non-IETF registrations.
    Was it decided that this was *not* going to be done? Or was it simply idle
    chatting about a potential change but nothing ever came of it? Just curious.
    
    5.2.1 The mechanism for abandoning provisional registrations was not clear to
    me. Do you mean they are considered abandoned after some period of time, or an
    applicant can explicitly abandon them, or something else? It's not spelled out.
  5. Robert Sparks: Comment [2012-06-20]:
    (Updating to reflect email discussion, clearing the discuss point. The list
    discussion already describes resolution for the remaining comments below)
    
    In paragraph 5 of section 4.2.1  where it says "all text/* registrations",
    should it say "all new text/* registrations"? (Similar to how
    mime-default-charset allowed for existing registrations that didn't follow
    these instructions.)
    
    Very minor nits:
    
    There are a few uses of RFC2119 keywords carried forward from RFC4288 that you
    might consider removing. The SHOULDs in the first paragraphs of section 4.5 are
    what motivated this comment. I understand if you don't want to make such a
    low-yield change at this point in the process though.
    
    The historical note (section 1.1) was copied forward from the introduction to
    rfc4288 without modification. It says things like "has now been moved" and
    "this revision" where "now" and "this" were written with 4288 in mind.
    
    Please grammar check the last sentence of 4.2.7
  6. Sean Turner: Discuss [2012-06-19]:
    We sometimes publish drafts directly to historic.  Is there a chance that a
    historic document might register a media type, and if it did what tree would it
    go in?  (btw - if the answer is we'll never ever, ever do this - that's okay
    I'm just wondering if anybody can think of a time when this might happen and we
    couldn't use the procedures.)

draft-ietf-pim-ecmp

  1. Stewart Bryant: Discuss [2012-06-20]:
    The following points are based on the Routing Directorate review by Dimitri
    Papadimitriou
    
    To improve the readability of the document the introduction needs to be a
    separate section from the protocol operation overview and applicability.
    
    ===
    
       Section 2.1: From the statement "a PIM ECMP Redirect message is sent by
       an upstream router to notify downstream routers to redirect PIM Joins
       to the new RPF neighbor via a different interface. .  When the
       downstream routers receive this message, they SHOULD trigger PIM
       Joins toward the new RPF neighbor specified in the packet."
    
     It is unclear how the upstream neighbor (preferred upstream router) determines
     the alternate neighbor.
    
    Please describe how the proposed algorithm ensures an upstream neighbor will 
    be determined if the selection rules aren't consistent or known among PIM
    routers. The document specifies the conditions under which ECMP redirect has to
    be sent not the selection criteria leading to that decision. The alternative
    would be to specify tie breaking rules (not just the information) such that at
    least the downstream neighbor can determine the best among the non-desired
    upstream neighbors. This also contradicts the statement that pruning is to be
    used to process incoming " Receiving ECMP Redirect" message.
    
    ====
    
       Section 3.2: a preference-based process indicates (at least partially)
       sequential process, whereas the middle paragraphs of that section reads as
       if the Join messages would be used as a preference discovery process.
    
    Would it have been better to have been better to have included the
    preference/metric information in the Hello exchanges?
    
    ====
    
       Section 3.3: how does  the proposed approach behaves in case upstream
       neighbor changes its preference rules ?
    
    ====
  2. Stewart Bryant: Comment [2012-06-20]:
    The following points are based on the Routing Directorate review by Dimitri
    Papadimitriou
    
       Section 2: "This usually leads to inefficient or ineffective use of network
       resources." Do you have a reference to make this statement quantitative ?
    
      Section 3.5 s/3.5.  Packet Format/Message and Option Format
    
       Coding of preference and metrics type/value shall be specified.
  3. Benoit Claise: Comment [2012-06-18]:
    The following is a COMMENT. However, let's have a chat on this one, because I
    really would like to understand.
    
       When a downstream router receives an ECMP Redirect, and detects that
       the desired RPF path from its upstream router's point of view is
       different from its current one, it SHOULD choose to prune from the
       current path and join the new path.  The exact order of such actions
       is implementation specific.
    
    Is the last sentence good enough for a standard track document?
    Should I first join the new path and then prune? Otherwise, I will miss some
    traffic, right? Because I see: "In essence, a PIM ECMP Redirect message is sent
    by an upstream router to notify downstream routers to redirect PIM Joins to the
    new RPF neighbor via a different interface.  When the downstream routers
    receive this message, they SHOULD trigger PIM Joins toward the new RPF neighbor
    specified in the packet." So by the time the downstream router sends the JOIN,
    he will losing some traffic. Unless, the upstream router already sent the
    traffic to its preferred path: maybe I missed it, but I have not seen this
    specified in the draft.
    
    Note: if I join the new path and then prune, then I will have duplicate
    traffic... which is fine with multicast.
    
    I'm also confused by those SHOULD in the two sentences I mentioned regarding
    interoperability between downstream and upstream routers.
    
    - One minor comment. Not sure what you gain by having the following entry in
    the terminology section
       o  RPF.  RPF stands for Reverse Path Forwarding.
    
    - With some background in PIM, we can deduce if you speak about ECMP for
    forwarding traffic (downstream) or ECMP for RFP (upstream). However, sometimes
    is not that easy. For example:
    
       ECMPs are frequently used in networks to provide redundancy and to
       increase available bandwidth.  A PIM router selects a path in the
       ECMP based on its own implementation specific choice.  The selection
       is a local decision.
    
    First sentence is downstream, while the second one is upstream. Is my
    understanding correct? Should we clarify the sentences in the document where
    ECMP is mentioned.
    
    -  "An upstream router MAY choose not to send ECMP Redirects if it
       becomes aware that some of the downstream routers are unreachable via
       some links in ECMP bundle."
    
    SHOULD NOT send?
    
    -
    OLD:
    
       When a downstream router receives an ECMP Redirect, and detects that
       the desired RPF path from its upstream router's point of view is
       different from its current one, it SHOULD choose to prune from the
       current path and join the new path.  The exact order of such actions
       is implementation specific.
    
    NEW:
       When a downstream router receives an ECMP Redirect, and detects that
       the desired RPF path from its upstream router's point of view is
       different from its current one, it SHOULD choose to prune from the
       current path and join the new suggested path.  The exact order of such
       actions is implementation specific.
    
    This change might be perceived as a detail. However, at that point in time in
    the draft, it was not clear that the path was suggested in the ECMP Redirect
    packet, and I was wondering: what if there are 3 ECMPs?
    
    - There is something wrong with RECOMMENDED and may in the next sentence
    
       In such an event, the following actions are  RECOMMENDED.
    
       The downstream router may select a new RPF neighbor.  Among all ECMP
       upstream routers, the one on the same LAN as the previous RPF
       neighbor is preferred.
  4. Stephen Farrell: Comment [2012-06-15]:
    (You should be aware of my ignorance of PIM when reading this;-)
    
    - I don't quite get what this means: "The ECMP links reside
    between the upstream and downstream routers over the ECMP
    bundle." I think its just awkwardly phrased though, if it means
    that the ECMP links are those whose interfaces are part of some
    ECMP bundle. If it means something else then I didn't get it.
    
    - 3.1: What's a "preferred" upstream router? Its not clear
    whose preference is meant.
    
    - 3.3: Is "on the same LAN" well-defined? Where?
    
    - 3.5.2: The text after figure 2 says nothing about the 1st set
    of fields, I guess a reference to where those are described
    would be good. (Its kind of obvious, but still...)
    
    - 3.5.2: "unnumbered" - just curious - is that defined
    somewhere in an RFC?
    
    - 3.5.2: This doesn't actually define smaller or bigger very
    well, but its kind of obvious I guess.  Be no harm to say it
    though, esp. for the Metric or just say "same as RFC foo".
    
    - security considerations: it might be worth stating that the
    4601 statement that you SHOULD NOT accept (PIM) protocol
    messages from anyone from whom you've not got an acceptable PIM
    Hello also applies here. I believe that is already implied by
    the current text, (if not, I'd probably make that a DISCUSS),
    but maybe could be missed by an implementer since you only say
    "same as PIM assert" in this document.
  5. Russ Housley: Comment [2012-06-15]:
      Please consider the editorial comments from the Gen-ART Review by
      Miguel Garcia on 11-Jun-2012.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07506.html
  6. Barry Leiba: Comment [2012-06-14]:
    Thanks for a very clear, very readable document, giving this Applications guy
    something in Routing that he can read, understand, and see the use of.
    
    One very small comment: you have a number of SHOULD, SHOULD NOT, and
    RECOMMENDED keywords (sections 3.2 thru 3.4, and I'm especially thinking of
    3.3).  It might be nice to include some sense of when it would be reasonable to
    choose against these,  -- if you can identify such situations --.  Remember
    that "RECOMMENDED", in RFC 2119, isn't just about recommendations: it basically
    means that this is what you MUST do unless you fully understand the
    ramifications of not doing so.
    
    -- Security Considerations --
       Spoofed ECMP Redirect packets may
       cause the downstream routers to send PIM Joins to an undesired
       upstream router, and trigger more ECMP Redirect messages.
    
    Any recommendations on what to do about this?
  7. Pete Resnick: Comment [2012-06-17]:
    I don't think this is worthy of DISCUSSion, and if you ignore these I will not
    be throwing a fit, but I strongly suggest that you correct the following
    problems:
    
    I feel more strongly than Barry about the 2119 keyword usage. He is correct
    that you can't tell for many of the SHOULDs what circumstances might cause one
    to violate the requirement. However, as far as I can tell, most of the 2119
    keywords are misused:
    
    3.1: "An upstream router MAY choose not to send ECMP Redirects if it becomes
    aware that some of the downstream routers are unreachable via some links in
    ECMP bundle."
    
    That's not a proper use of MAY. What if it is *not* aware of unreachable
    downstream routers? Is it then that it MUST send the ECMP Redirects? What
    protocol requirement is the sentence trying to describe?
    
    3.2: What are the interoperability implications of each of these three SHOULDs?
    What bad things happen if I don't follow those requirements? And again, what
    are the kinds of circumstances where it might be reasonable to violate?
    
    3.3: It says that "the following actions are RECOMMENDED", but then the first
    one says that the "downstream router may select a new neighbor". It is an
    interoperability RECOMMENDation that the router *may* do something? That seems
    weird. I don't think RECOMMENDED is used correctly here.
    
    3.5.2: I think it's generally bad form to use 2119 keywords in the definitions
    of packet formats.
    
       Neighbor Address (32/128 bits):   Address of desired upstream
          neighbor where the downstream receiver SHOULD redirect PIM Joins.
    
    Where else might it send PIM Joins? Don't you rather mean, "Address of neighbor
    that has requested redirected PIM Joins."? Same with the other SHOULD in this
    section.
    
          This address MUST be associated with an interface in the same ECMP
          bundle as the ECMP Redirect message's outgoing interface.
    
    Doesn't this belong in 3.1 or 3.4?
    
          an ECMP Redirect message MUST be discarded if the "Neighbor
          Address" field in the message does not match cached neighbor
          address.
    
    Again, doesn't this belong in 3.2 or 3.4? Here, it should simply say, "is
    discarded".
    
    I think the same is true for the other two MUSTs in this section.
  8. Sean Turner: Comment [2012-06-19]:
    1) a: The RFC editor will make you remove the reference from the abstract.  If
    you're going to rec it before the draft gets there r/[RFC4061]/(RFC 4061).
    
    2) s1: Tripped over the definition of EMCP bundle too.
    
    3) s2 (nit picking): RFC 4601 calls it a hash function not a hash algorithm.
    
    4) I tripped on the same thing Stephen did in the security considerations.
    
    5) The paragraph in the security considerations seems to apply to the PIM
    message type, but since you're also defining a new hello message option
    shouldn't those be discussed as well?  Even it's just:  The use of the PIM
    Hello option defined in this document does not introduce additional security
    considerations to those already described in [RFC4601].  (assuming that's true
    of course)

draft-ietf-mif-dns-server-selection

  1. Ronald Bonica: Comment [2012-06-20]:
    Support Brian's DISCUSS. Please consider rewriting this document. I found it
    very difficult to parse.
  2. Stephen Farrell: Discuss [2012-06-19]:
    (1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced that
    implementations would all do the same thing based on this description
    and with the same input preferences. Is it required that different
    implementation's behaviour be the same in that case? If not, then lots
    of the 2119 language ought to be omitted. If so, then I think you need
    to re-write it more clearly, e.g. using pseudo-code. (Or convince
    me this is a dumb DISCUSS point:-)
    
    (2) What is the lifetime of the domain/network information received in a
    DHCP response? 4.2 is vague about that, talking about "general
    events." Given that DHCP lease times vary enormously I'd have thought
    you'd need to be more precise here.
    
    (3) I don't see how a piece of DNS or DHCP code can know if the criteria
    in 4.4 apply, at least as they are stated now. For example, for
    criterion 1, how can a piece of code know that a given network
    provides a "secure, trusted channel"? There are cases where you can
    know, but they're not called out here in a way that can be implemented
    it seems. My concern is that implementations will just assume its ok
    and then be vulnerable.
    
    (4) section 7, 3rd para: is the MUST there expected to be enforced?  If
    so how and by whom?
  3. Stephen Farrell: Comment [2012-06-19]:
    (This could do with an editorial pass but I'm only going to note
    places where a change is more than purely grammatical.)
    
    - Is the title ok? The spec is more about private namespaces but
    the title reads as something more generic.
    
    - abstract: s/contact to./contact./ but maybe "use" is better than
    contact anyway.
    
    - section 1, 4th para: selection of "route"? do you mean interface?
    (Also is "IP connection" right given UDP is most commonly used
    for DNS?)
    
    - section 1, 4th para: be good to give some refs to the kinds of tool
    you mean in the last sentence. (If possible)
    
    - Acronyms like VLAN, WLAN etc. would be better expanded
    
    - 4.1, 2nd para on p10 says "routes" again, which is probably wrong
    
    - 4.1 mentions "medium priority" but that's not been introduced
    
    - 4.1 says you "MUST" take into account trust levels but those aren't
    defined and are left to implementations, so I'm not sure that 2119
    MUST is usefuln (see dicsuss point 1 as well)
    
    - The encoding of the domains and networks in figure 5 is a bit
    opaque, the reference to 3315 for example is to a section that is 5
    lines long and refers to 1035. Would some more descriptive material or
    examples help here? I can imagine implementers going wrong here, but
    perhaps its ok and the people who'd write code for this would be
    fine.
    
    - OPTION_ORO could do with a reference or brief explanation in 4.2
    for the less DHCP-literate (like me:-)
    
    - I can't parse this, from 4.5: "In the case of DHCPv4 and DHCPv6
    providing conflicting RDNSS selection information on the same
    interface, or on the equally trusted interfaces, the node SHALL
    firstly prefer DHCP-version possibly securing
    OPTION_DNS_SERVER_SELECT, and secondly prefer DHCPv6 over DHCPv4."
    
    - last para of 4.5, would s/may choose to omit/MAY omit/ be better?
    
    - section 7, 2nd para, that MUST is really a SHOULD isn't it?  (There
    are exceptions and its not enforceable.)
  4. Brian Haberman: Discuss [2012-06-15]:
    1. The start of section 4.1 simply states that resolvers should use DHCP to
    determine which RDNSSes are capable of resolving specific domain names and/or
    addresses. Given that the mechanism for doing such a query via DHCP is defined
    in this document, I would suggest that the introductory text in 4.1 give a
    forward pointer to section 4.2 where the mechanism is actually defined.
    
    2. The DHCP option for determining which RDNSSes are capable of resolving
    certain names and prefixes seems incomplete. How many names/addresses
    should/can the server return within a single instance of the option?  In what
    situations would you recommend returning more than one instance of the option,
    one per RDNSS?  Additional guidance for both implementers and operators would
    be useful.
  5. Brian Haberman: Comment [2012-06-15]:
    1. I support the DISCUSS points raised by Barry and agree that the document
    needs a complete review by a native English speaking author.
    
    2. The packet layout in Figure 5 puts the option-code name
    (OPTION_DNS_SERVER_SELECT) in the actual field rather than labeling the field
    as "option-code".
  6. Russ Housley: Comment [2012-06-15]:
      Please consider the editorial comments from the Gen-ART Review by
      Christer Holmberg on 5-Jun-2012.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07482.html
  7. Barry Leiba: Discuss [2012-06-14]:
    -- 4.1 --
       The resolver MUST NOT
       prioritize less trusted RDNSSes higher than trusted
    
    But two paragraphs earlier, you say this:
    
       The RDNSSes of
       untrusted interfaces may be of highest priority only if trusted
       interfaces specifically configure low priority RDNSSes.  The non-
       exhaustive list on figure 4 illustrates how the different trust
       levels of received RDNSS selection information SHOULD influence the
       RDNSS selection logic.
    
    You give a reason for violating that MUST NOT, and Figure 4 has two cases where
    the less trusted RDNSS is prioritized higher than the trusted one.
    
    -- IANA Considerations --
    Perhaps this is clear enough for IANA, but I see registries specified without
    their proper names, so I worry:
    
    1. It looks like the first option code is meant to go into the "BOOTP Vendor
    Extensions and DHCP Options" registry in the group "Dynamic Host Configuration
    Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters".
    
    2. It looks like the second option code is meant to go into the "DHCP Option
    Codes" registry in the group "Dynamic Host Configuration Protocol for IPv6
    (DHCPv6)".
    
    Please either confirm or correct that and put the *exact* names of the
    registries in (you can look for them in http://www.iana.org/protocols/ ).  That
    avoids problems for IANA later.
  8. Barry Leiba: Comment [2012-06-14]:
    Substantive comments; these are non-blocking, but please consider them
    seriously, and feel free to chat with me about them:
    
    This comment is short of being a DISCUSS, because the document is generally OK
    and I think I've understood it.  I have great respect for the work of the
    non-native-English editors; still, there are some significant bits that are in
    sufficiently fractured English as to be hard to read and possibly confusing.
     I'd like to see the native-English-speaking co-editor (or some other
    volunteer) go over the document and make sure the articles, tenses, plurals,
    and commas are right.  There's a lot of fixing needed.
    
    -- 4.1 --
       For security reasons the RDNSS selection information MUST be used
       only when it is safe to do so, see Section 4.4 for details.
    
    This phrasing is easy to misinterpret ("[x] MUST be used").  I suggest casting
    it more directly:
       For security reasons the RDNSS selection information MUST NOT be
       used unless it is safe to do so, see Section 4.4 for details.
    
    -- 4.1 --
       Trustworthiness of an interface and configuration information
       received over the interface is implementation and/or node deployment
       dependent.
    
    ...and, I presume, the specification of that trust model is out of scope for
    this document.  I suggest you explicitly say that, before you give the (very
    good) examples:
       Trustworthiness of an interface and configuration information
       received over the interface is implementation and/or node deployment
       dependent, and the details of determining that trust are beyond the
       scope of this specification.  Trust might, for example, be based on the
       nature of the interface: an authenticated and encrypted VPN, or a layer
       2 connection to a trusted home network, might be considered as trusted,
       while an unauthenticated and unencrypted connection to an unknown
       visited network would likely be considered as untrusted.  In some
       situations, an interface might be considered trusted only if it has been
       explicitly configured to be.
    
    I remind you that "shall" is a 2119 keyword (synonymous with "must"), and you
    should be cautious in using it casually.
    
       If a DNS response is not proven to be unmolested using
       DNSSEC, then a node cannot make a decision to prefer data from any
       interface with any great assurance: any response could be forged, and
       there is no way to detect the forgery without DNSSEC.
    
    First, this is a convoluted sentence, with too many negatives; second, you're
    burying the lede.  The important point here is that DNSSEC is necessary, so put
    it up front:
       DNSSEC is necessary to detect forged responses, and without it any
       DNS response could be forged or altered.  Unless the DNS responses
       have been validated with DNSSEC, a node cannot make a decision to
       prefer data from any interface with any great assurance.
    
    -- Figures 5 and 6 --
       Reserved:      Field reserved for the future. MUST be set to zero.
    
    It would seem to be useful for those future applications if we made sure that
    implementations didn't barf on receipt of some future value here.  Would this
    work?:
       Reserved:      Field reserved for the future. MUST be set to zero; MUST
                                be ignored on receipt.
    
    -- Figure 8 --
    Does this diagram tell me anything useful?  If so, I can't figure out what.
     The only interesting part is in the "black box".
    
    -- 10.2 --
       An implementation may not be able to
       determine trust levels without explicit configuration provided by
       user or administrator.
    
    OK, if you're going to go there, I have to: do you really think there's any
    serious possibility of user configuration here, especially in the case of a
    home-network user?  I think that if you mention user configuration, you have to
    mention that in many, if not most, scenarios, user configuration is not a
    realistic possibility, and administrator configuration and policy heuristics
    are usually the only viable mechanisms.
    
    ========
    Other comments; no need to respond to these. Take them or modify them
    as you please:
    
    "timeout" should be one word, not two (but "timed out" is, correctly, two).
    
    -- 4.1 --
       The resolver SHOULD avoid sending queries over different network
       interfaces in parallel as that wastes resources such as energy.  The
       amount of wasted energy can be significant, for example when radio
       interfaces has to be started just for the queries.
    
    Maybe it's just an artifact of where the page break happened, but I wondered
    what the "energy" thing was until I saw "radio interfaces" (on the next page).
     I suggest using "power" rather than "energy", and specifically noting
    battery-powered and constrained environments.  Perhaps this:
       The resolver SHOULD avoid sending queries over different network
       interfaces in parallel as that wastes resources such as power (in the
       case of battery powered and constrained environments).  The wasted
       power can be significant: consider starting multiple radio interfaces
       just for parallel DNS queries.
  9. Robert Sparks: Discuss [2012-06-20]:
    It's not clear from the discussion of the premise in the introduction if the
    document intends to cover the case of receiving different answers to queries
    into a public namespace depending on which interface the query was made over.
    For example, getting different results, per interface, for queries into
    e164.arpa will lead to calls using different technologies with potentially
    radically different security properties. This needs to be clarified throughout
    the document and at least discussed in the security considerations.
    
    Building on Stephen's first discuss point - the algorithm in 4.1 relies on the
    interfaces having a ordered "trusted" attribute, but the source of that
    ordering is unspecified. The text recognizes that this is "implementation
    and/or node deployment dependent". Won't this also typically be application
    dependent? How is this specification going to help interoperability (or
    reliably improve the overall performance of individual nodes) without a more
    consistent definition of how this ordering is obtained? Is it conflating
    "trust" with "preference"? As Barry notes, additional discussion of what's
    actually likely to be used for inputs into this ordering is warranted. For
    example, if an end user disagrees with the typical trust ordering you call out
    for a cellular interface in scenario 3.2, should he expect to be able to do
    anything about it?
    
    This sentence is problematic: "The non-exhaustive list on figure 4 illustrates
    how the different trust levels of received RDNSS selection information SHOULD
    influence the RDNSS selection logic." Please rewrite that without the 2119
    keyword, and ensure that the actual normative requirement is well specified.
    
    You call out a problem with local DNS caching for hosts with a single interface
    that moves between networks, but don't discuss the affects of local caches when
    this solution is used. Should that discussion be added (at least commenting on
    whether this solution helps)? Would you change anything in the local cache as
    interfaces come and go? What do you do with cached results when the preference
    or trust levels of interfaces change?
    
    Can you add guidance for how an administrator should chose the prf settings to
    be configured. Right now, it's hard to see why they wouldn't always chose
    "High". If you don't want deployments doing that, please say what they should
    be doing instead. An example deployment scenario showing the value of having
    different prf levels would go a long way.
    
    Is there some discussion of the potential for spoofing the RDNSS (by spoofing
    its source address) when a client is relying on item 4 of section 4.4 somewhere?
  10. Robert Sparks: Comment [2012-06-20]:
    The reader has to make a fairly large leap to understand what "default" and
    "specific" mean in FIgure 4. Please consider additional introduction to the
    figure making what those mean more explicit.
    
    Nit: (two occurrences) s/SHOULD NOT extent lifetime/SHOULD NOT extend the
    lifetime/
  11. Sean Turner: Discuss [2012-06-21]:
    1) s4.2 & s4.3: Add that the reserved bits MUST be ignored on receipt.
    
    2) s4.2 & s4.3: Need to specify what to do if the prf value 10 is received.
  12. Sean Turner: Comment [2012-06-21]:
    I agree with Robert and Stepehen's discuss positions.
    
    0) s1: Includes the following:
    
      The node ought to be able to ask right
      RDNSS for the information it needs.
    
    by "right" you mean the RDNSS that holds the data that's been asked for  even
    if it's private.  how about:
    
      The node ought to be able to query the RDNSS that can
      resolve the query regardless of whether the answer comes
      from the public DNS or a privte namespace.
    
    1) s2.2: r/It is worth noting is that/It is worth noting that
    
    2) s3.1: r/instead CPE should send/instead CPE need only send
    
    3) s3.3: r/should be send/need to be sent
       r/network may be used./network may be used for all other traffic.
    
    4) s4.1: I tend to agree with Stephen here.  I think what you want to say is
    that the specific procedures here are non-normative but an implementation must
    end up wit h the same result.  Pseudocode would help tremendously.  Avoiding
    using lowercase may, shall, should, and must would also help.
    
    5) s4.1: When you say precedence are you saying that the higher precedence
    should cause processing of lower precedence ones to be stopped or is this just
    about picking the next value to process?
    
    6) s4.1: priority or precedence pick one ;)
    
    7) s4.2: r/should be contacted/can be contacted
    
    8) s4.2: r/MAY then/can then
    
    9) s4.2: r/extent/extend
    
    10) s4.2:
    
    OLD:
    
     In the case of conflicting
     RDNSS address is learned from less trusted interface, the node MUST
     ignore the option.
    
    NEW:
    
     When a conflicting RDNSS address is learned from less trusted
     interface, the node MUST ignore the option.
    
    11) s4.4: Agree with Stephen's discuss #3.

draft-ietf-pwe3-cbit-negotiation

  1. Adrian Farrel: Discuss [2012-06-18]:
    (Edit to remove piece of Discuss related to process)
    
    The Abstract could usefully say that this document updates both 4447
    and 6073.
    
    The Introduction talks of updating 4447 but does not mention 6073. A
    clear statement of what is updated in 6073 is needed.
    
    ---
    
    Section 3.1
    
          -i.  Local PE MUST send a label withdraw message to remote PE if
          it has previously sent a label mapping, and label release message
          to remote PE, and wait until receiving a label release from the
          remote PE.
    
    I'm afraid that this can't be parsed. Does it mean:
    
          -i.  If a PE has previously sent a Label Mapping message to a
               remote PE, it MUST send a Label Withdraw message to the
               remote PE, send a Label Release message to remote PE, and
               wait until it receives a Label Release message from the
               remote PE.
    
    ---
    
    I agree with Section 4 as it applies to single hop PWs, but it is not
    consistent with the text in Section 3. This is because Section 3
    includes normative description of behavior of the legacy node that
    Section 4 claims will work without modification. Viz.
    
       When the remote PE successfully processed the label withdraw and
       label release, and removed the remote label binding, it MUST reset
       its use of control word with the locally configured preference, and
       send label mapping as a response of label request with locally
       configured preference for use of control word.
    
    I think you need to reword this to show that it represents no change in
    behavior of the remote PE (i.e. PE1 in your example).
    
    However, the case for multi-hop PWs seems less simple. I think you
    describe behavior required at adjecent S-PEs. Does this come for free or
    is there a requirement to upgrade all S-PEs to support this function?
  2. Adrian Farrel: Comment [2012-06-17]:
    Please s/draft/document/
    
    ---
    
    Please request the RFC Editor to not split Appendix A across a page
    break.
    
    ---
    
    Please capitalise all mesage names to be consistent with RFC 5036, and
    include the word "message".
  3. Stephen Farrell: Comment [2012-06-18]:
    - Adrian's process questions in his discuss seem reasonable to me,
    as does the question about how this updates 6073.
    
    - PE could usefully be expanded in section 1.
    
    - The abstract talks about the PREFERRED->NOT-PREFERRED transition,
    but section 2 talks about the NOT-PREFERRED->PREFERRWED transition
    at PE2. That confused me, since the abstract implies only the
    PREFERRED->NOT-PREFERRED transition is problematic.
    
    - Is it "NOT PREFERRED" or "NOT-PREFERRED"? Pick one.
    
    - Section 5: I assume the security considerations from 4447 and/or
    6073 apply here as well. Worth saying?
  4. Brian Haberman: Comment [2012-06-18]:
    I support Adrian's DISCUSS position on the process used to advance this
    document.
  5. Russ Housley: Discuss [2012-06-20]:
      The Gen-ART Review by Elwyn Davies on 19-Jun-2012 says:
      >
      > Not ready. The proposal for the NOT PREFERRED to PREFERRED
      > transition case does not appear to be compatible with the existing
      > RFC 4447 standard in the way stated and there are a number of other
      > minor issues.
      >
      This lead to a dialogue between the authors and Elwyn.  That dialogue
      has not completed as yet, but it is clear to me that some document
      changes will be needed in the end.  I'll clear this DISCUSS position
      when the dialogue reaches closure and the document updates are made.
  6. Barry Leiba: Discuss [2012-06-21]:
    To start, realize that I am NOT well versed in PWE3 technology, and please tell
    me if what I'm asking about would simply be clearly understood by those who are.
    
    In addition to Adrian's rewrite of Section 3 bullet "i" (which I support), I
    find some other wording clarifications in Section 3 necessary to the
    understanding of this document:
    
       Note: the FEC element in label request message should be the PE's
       local FEC element.  Only if FEC element in label request message
       could bind together with peer PE's local FEC element, the peer PE
       sends label mapping with its bound local FEC element and label as a
       response.
    
    I do not understand these two sentences.  What is "should be" in the first
    sentence?  Is it, or is it not?  I'm not necessarily suggesting changing this
    to 2119 language, but that you make it clear what you're saying.  The second
    sentence is just unparseable, and I'm not at all sure that I understand what
    it's trying to say.
    
       When Local PE changes the use of control word from PREFERRED to NOT
       PREFERRED, Local PE would be able to re-negotiate the Control Word to
       be not used following the procedures defined in [RFC4447], and no
       label request message to peer PE will be needed.  In that case, Local
       PE will always send new label mapping with C-bit reflecting the
       locally configured preference for use of Control Word.
    
    I'm having a hard time with this paragraph, and don't think I understand it.  I
    think "to be not used" may be throwing me... apart from its not parsing, I
    *think* it says that you won't use the Control Word (please use consistent
    capitalization -- you have it capitalized and not capitalized in the same
    sentence here) in this case.  Is that right?  Does that make sense?  Then the
    next sentence talk about using the Control Word.  Please rephrase this
    paragraph, or assure me that anyone who understands PWE3 will get this, and
    that's just not me.
  7. Barry Leiba: Comment [2012-06-21]:
    This is non-blocking:
    I *very* much appreciate and applaud the work done by our non-native-speaking
    colleagues.  With that in mind, I strongly suggest an editing pass by a native
    speaker who is familiar with the technology, to correct articles, number,
    tenses, and punctuation.  The RFC Editor will do this, of course, but they are
    not technology experts, and may make errors that will be hard to detect during
    AUTH48.
  8. Sean Turner: Comment [2012-06-19]:
    General: If this draft is about generic renegotiation it should just say that ;)
    
    This is just word smthing:
    
    (section:change - a=abstract)
    
    - a and s1:
    
    OLD:
    
    The control word negotiation mechanism specified in RFC4447 has a problem when
    PE changes the preference for the use of control word from PREFERRED to
    NOT-PREFERRED. This draft updates RFC4447 by introducing a message exchanging
    mechanism to resolve this control word negotiation issue.
    
    NEW:
    
    The control word negotiation mechanism specified in RFC4447 does not support
    renegotiation of a Provider Edges (PEs) when its changed from NOT-PREFERRED to
    PREFERRED.   This draft updates RFC4447 by introducing a renegotiation
    mechanism.
    
    use [RFC4447] in s1.  if it's generic then you could drop the "when ..." bit.
    
    - I think you cold delete s2 entirely and add the following paragraph to s1:
    
    The negotiation mechanism described in [RFC4447] addresses receipt of Label
    Mapping before one is sent and if a Label Mapping message has not been
    received.  It does not support PE's changing their control word setting after
    the PW has been established from NOT-PREFERRED to PREFERRED.
    
    - s3, 1st para:
    
    OLD:
    
    In order to resolve above problem, the control word re-negotiation mechanism as
    described in [RFC4447] section 6 is updated by adding label request message.
    
    NEW:
    
    [RFC4447] section 6.2 is updated to add the control word re-negotiation
    mechanism described in this section.
    
    - s3.1, bullet i: Couldn't parse it.

draft-ietf-trill-rbridge-channel

  1. Stewart Bryant: Discuss [2012-06-20]:
    Section 2.4 Special Transmission and Rate Considerations says:
    
       RBridge Channel messages represent a burden on the RBridges and links
       in a campus and should be rate limited, especially if they are sent
       as high priority, multi-destination, or multi-hop frames or have an
       RBridge Channel Alert extended header flag set.
    
    In the IANA section you have provision for private use and no standards track
    channels, but you provide no guidance on how implementers and reviewers
    ensure that they avoid the concern called up in section 2.4
    
    I am not sure why the multi value restrictions are in place, and the way that
    it is worded invites work arounds
    
     (2) RBridge Channel protocol code points from 0x100 to 0xFF7 require
       RFC Publication to allocate a single value or IETF Review to allocate
       multiple values.
    
    If the goal is to prevent a run on the registry, it would be simpler to
    make the range smaller and update the RFC if we look like we are
    goingto run out.
  2. Stewart Bryant: Comment [2012-06-20]:
       It is anticipated that various protocols operating at the TRILL level
       will be desired in RBridge campuses.
    
    SB> I am not sure what it means to "Operate at the TRILL level"
  3. Adrian Farrel: Comment [2012-06-21]:
    I don't think my Comments warrant a Discuss, although I personally "would not
    have done it like this".
    
    ---
    
    There is an assumption here that bridge alert (just like router alert)
    is an acceptable function. I am not convinced and I note RFC 6398 that
    seems to suggest that router alert is not a good idea in general,
    although not catastrophic in certain deployments that might be similar
    to early Trill deployments.
    
    But I worry that if the popularity of Trill grows, the bridge alert
    function will cause many of the same problems it caused in IP networks.
    
    It is worth noting that MPLS (and you do draw the comparison with G-ACh)
    has a router alert label, but this is not used on the G-ACh.
    
    At the very least, the use of bridge alert causes packets to be thrown
    out of the normal forwarding path at each bridge along the path. This
    means that packets are not treated the same way as data packets and so
    some of the properties of OAM are lost. (Note that if you want to send
    an OAM packet to a transit bridge, you will use bridge alert and all
    other transit bridges along the path up to the intended target will need
    to inspect the packet.)
    
    ---
    
    Section 3.2
    
    What is the meaning of
        0    - Not an RBridge Channel error frame.
    I didn't finf itdiscussed in the text.
    
    Why is
       15    Reserved
    And what does "reserved" mean? IANA will need to know whether it means
    "never to be allocated".
    
    ---
    
    Why are Channel protocol numbers 0 and xFFF reserved? (And you will need
    to clarify to IANA that you mean "reserved and not to be allocated".)
    
    ---
    
    I wasn't clear about the Security aspects. I understand that if a
    payload protocol needs protection, it is responsible for this itself.
    However, is there any way to protext the content of the channel header?
    What would be the consequence of someone tweaking the SL bit?
    
    Since Trill (and Ethernet) are routed sysetms (unlike MPLS) attacks
    from outside seem feasible. While you might protect the payload
    protocols through their own mechanisms, how do you protect the bridges
    themselves from attacks? The rbridge channel and the bridge alert flag
    see like vectors for DoS.
    
    Rate limiting as described in 2.4 provides some mitigation. Maybe you
    should reference this in the security section.
  4. Stephen Farrell: Discuss [2012-06-19]:
    (1) I think that section 7 needs a 2119 MUST in the 2nd paragraph,
    that is, I reckon it ought say: "If these services are required for a
    particular RBridge Channel protocol, they MUST be supplied by that
    channel protocol." I'd not like to see someone come along and say that
    its ok that they don't do security because this doesn't.
    
    (2) "No protection is provided against forging of the ingress nickname
    in a TRILL Data formatted channel message or the Outer.MacSA in a
    native RBridge Channel frame. This may result in misdirected return
    responses or error messages." Can you explain why this is ok? (Not
    sure if some text change might follow or not.)
    
    (3) Is this supposed to allow or prevent end-stations talking to one
    another? (Rather than to RBridges.) I think that ought be clarified,
    and if its not supposed to happen, then what prevents/detects it? That
    last might need a bit of text.
  5. Stephen Farrell: Comment [2012-06-19]:
    - 1.2, "Inner.MacDA and inner Ethertype" could maybe do with
    references/forward-pointers.
    
    - Section 2 - the figure mapping the message and document structure
    is great - thanks!
    
    - Be better to give the figures/diagrams names, numbers and captions.
    (If editing tools don't make that a pain.) In particular, referring to
    "the figure above" from 2.1.1 back to the previous sections isn't
    great.
    
    - List of error conditions on p11 - I wondered why aren't there any
    security conditions?
  6. Brian Haberman: Comment [2012-06-15]:
    I only have two minor comments on this document:
    
    1. The introduction contains the following standalone sentence: "Familiarity
    with [RFC6325] and [RFC6327] is assumed in this document."  What is the purpose
    of this sentence given that both references are listed as normative?
    
    2. Section 3 says that these channel messages are subject to the usual TRILL
    message checks and then lists some checks that are performed.  I would suggest
    making an explicit reference to the document that defines those checks and list
    any that are not performed on channel messages.
  7. Barry Leiba: Discuss [2012-06-14]:
    This seems a well-written, clear document, which looks technically sound.  One
    small point that should be easy to resolve:
    
    For the new RBridge Channel Protocols registry:
    
    1. The correct 5226 policy is "RFC Required" (not "RFC Publication").
    
    2. What's the reason for requiring IETF Review for more than one request?  If
    someone has a document in the Independent Stream and needs two codes, this
    means that it has to be re-routed through the IETF Stream or split into two ISE
    documents -- both of which might not make sense.  If it's just that you want
    someone to sanity-check requests for multiple values, you could make that "IESG
    Approval" instead of "IETF Review".  That would allow the IESG to block
    multiple-value registrations through the Independent Stream if necessary, but
    to choose to approve them without forcing the RFC to go through the IETF Stream.
  8. Sean Turner: Comment [2012-06-19]:
    I support Stephen's discuss positions.

draft-ietf-6man-rfc3484bis

  1. Ralph Droms: Comment [2012-06-21]:
    These comments are provided with the goal of improving the readability
    and completeness of the information in the document.  I apologize for
    the vagueness of my complaints about readability in comment 4; if
    everyone else is able to read and understand the text I commented on,
    feel free to ignore my suggestions.
    
    1. I suggest adding a sentence explaining the status of IPv6
    site-local unicast addresses and why they are included in the
    procedures in this document.  Perhaps something like:
    
       "IPv6 site-local unicast addresses are deprecated [RFC 4291].
       However, some existing implementations and deployments may still
       use these addresses and, therefore, they are included in the
       procedures in this specification."
    
    2. There is a minor conflict between the definitions of IPv6 multicast
    scopes in RFC 4007 and RFC 4291.  I couldn't find an errata about the
    issue.  RFC 4291 lists scope field value 0x03 as "undefined".  The
    information kept by IANA seems to show RFC 4291 for multicast issues
    in
    www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml,
    so, for consistency, this document might want to follow RFC 4291.
    
    3. Minor editorial suggestion in section 4:
    
    OLD:
    
       It is RECOMMENDED that the candidate source addresses be the set of
       unicast addresses assigned to the interface that will be used to send
       to the destination.  (The "outgoing" interface.)
    
    NEW:
    
       It is RECOMMENDED that the candidate source addresses be the set of
       unicast addresses assigned to the interface that will be used to send
       to the destination (the "outgoing" interface).
    
    4. The one part of this otherwise excellent document I find confusing
    is the candidate source address selection procedure in section 4.  It
    took several readings for me to understand how the rules in that
    section are applied; e.g., which rules modify, override or are
    considered in parallel with other rules.  I was unable to understand
    this paragraph (which seems like it should be swapped with the
    paragraph immediately following it for clarity):
    
       If an application or upper layer specifies a source address that is
       not in the candidate set for the destination, then the network layer
       MUST treat this as an error.  The specified source address may
       influence the candidate set, by affecting the choice of outgoing
       interface.
    
    However, I'm not sure I have any good suggestions for broad
    improvement.  Here are a few small suggestions:
    
       For all multicast and link-local unicast destination addresses...
    
       For site-local unicast addresses...
    
       Perhaps move the paragraph that begins "It is RECOMMENDED..." to
       the end of section 4 and begin it with "Unless otherwise specified
       above, it is RECOMMENDED..."
    
    5. In section 5, the text describing the comparison rules specifies
    three outcomes for each rule, "greater than," "less than" or "equal
    to," while none of the rules explicitly defines an "equal to" outcome.
    For completeness, I suggest adding a sentence explicitly identifying
    the default result for each rule is "equal to".
    
    6. Section 5, Rule 3: s/The addresses/If the addresses/
  2. Adrian Farrel: Comment [2012-06-17]:
    Thank you for a comprehensive Appendix B that made reviewing this
    document much easier.
    
    ---
    
    I note that the Ballot Write-up includes text from an old version of
    the Abstract saying:
    
       All IPv6 nodes, including both hosts and routers, must implement
       default address selection as defined in this specification.
    
    This strong requirement appears to have been relaxed in the final
    revision. Please update the ballot.
  3. Stephen Farrell: Comment [2012-06-18]:
    - Source address rule 5.5 has a lowercase "shall" - since it looks like
    this document has had a fairly careful scrubbing of lowercase 2119
    language I wondered if that's really a 2119 MUST or a "can"?
    
    - Destination address rule 7 discussion: maybe s/6RD/6rd/ ?
  4. Russ Housley: Discuss [2012-06-18]:
      Please consider the security considerations question raised in the
      Gen-ART Review by Ben Campbell on 14-Jun-2012.  I think this question
      deserves a response.  The Gen-ART Review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07513.html

draft-ietf-vcarddav-oma-cab-extensions

  1. Stephen Farrell: Comment [2012-06-18]:
    - The INDEX parameter in 3.1 seems different from the others. I
    wondered if it really caused this to update 6530, since presumably it
    could make sense with any multi-valued thing? I assume the argument
    that it doesn't is that 6530 implementations will ignore it if they
    don't also support this spec, and I'm ok with that, but just wanted to
    check.
    
    - Is LEVEL (3.2) only supposed to be used with hobby, etc.? If so, then
    maybe you need some 2119 language for that? If not, then maybe say
    that. I could imagine LEVEL being used e.g. with ROLE or TITLE or
    maybe even SOUND (at a stretch:-).
  2. Russ Housley: Comment [2012-06-18]:
      In the Gen-ART Review by Joel Halpern on 8-Jun-2012, it was pointed
      out that a reference two RFC 2119 is needed since there is one MUST.

draft-kucherawy-marf-source-ports

  1. Benoit Claise: Comment [2012-06-18]:
    - Not really a DISCUSS but please consider the following comment (or please
    justify your choice)
    
    I looked at http://www.iana.org/assignments/marf-parameters/marf-parameters.xml
    for the Source-IP definition, and see:
               Source-IP: IPv4 or IPv6 address from which the original message was
               received
    
    Now at look at Source-Port definition in the draft, and see:
               TCP source port from which the reported connection originated
    
    Don't you think those two definitions should be aligned, as they are related?
    What I have in mind is: TCP source port from which the original message was
    received
    
    - Also, the following sentence doesn't seem quite right
       When present in a report, it MUST contain the TCP source port matching the
       "Source-IP" field in the same report, thereby describing completely
       the origin of the abuse incident.
    
    Looking at http://tools.ietf.org/html/rfc5965#section-3.2 as a guideline:
    
           o  "Source-IP" contains an IPv4 or IPv6 address of the MTA from which
              the original message was received.  Addresses MUST be formatted as
              per section 4.1.3 of [SMTP].
    
    I'm wondering, don't you want to write something such as:
       When present in a report, it MUST contain the TCP source port of the MTA
       from which the reported connection originated (characterized by the
       "Source-IP" field in the same report), thereby describing completely
       the origin of the abuse incident.
  2. Pete Resnick: Comment [2012-06-12]:
    If you wanted to tighten up the syntax, you could do:
    
      source-port = "Source-Port:" [CFWS] 1*5DIGIT [CFWS] CRLF
    
    since a port number can't be more than 5 digits. But entirely up to you.
  3. Robert Sparks: Comment [2012-06-19]:
    (Summarizing an IM conversation with Murray)
    This appears to extend 5965 rather than update it. It would also help to more
    clearly point to exactly what in  RFC6591 is being updated.

draft-ietf-grow-simple-va

  1. Adrian Farrel: Comment [2012-06-21]:
    I'm inclined to agree with Barry about this being an Informational document.
    But I don't feel strongly.
  2. Stephen Farrell: Comment [2012-06-18]:
    - This is not an easy read, but it ought be. For example,
    section 2 says: "In both cases simple VA operates in an
    identical way however when default route is found and is
    eligible to become a less specific prefix by router's
    configuration the S-VA may use it. " I'd encourage the
    authors to try get some additional editorial review aiming at
    significantly increased clarity. (This was also almost a
    DISCUSS, but isn't since this algorithm doesn't seem
    to affect security or interop, and if it did, deployments
    would turn it off quickly.)
    
    - Various terms (e.g., ABR, ABSR, SPF, Adj-RIBs-In, Loc-RIB,
    NLRI, ...) could be expanded.  The terminology section even
    seems to use undefined terms.
  3. Russ Housley: Discuss [2012-06-18]:
      The Gen-ART Review by Meral Shirazipour on 11-Jun-2012 raises some
      significant issues.  Please respond to the review:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07508.html
  4. Barry Leiba: Comment [2012-06-19]:
    These are non-blocking, but please consider them seriously, and feel free to
    chat with me about them:
    
    This comment is on the edge of being a DISCUSS, but I think I'll try it this
    way: The document is generally OK, and I have great respect for the work of the
    non-native-English editors.  But there are some significant bits that are in
    sufficiently fractured English as to be hard to read and possibly confusing.
     I've noted the worst of them below, but I'd like to see one of the
    native-English-speaking co-editors go over the document and make sure the
    articles, tenses, plurals, and commas are right.
    
    Also, the document cites RFC 2119 and contains 2119 boilerplate, but I can only
    find one instance of a "MUST".  My sense is that this Informational document
    doesn't need 2119 at all, and that it should be removed.
    
    The third paragraph of the Abstract doesn't seem to need to be in the Abstract,
    and I suggest removing it.  It's the sort of thing that will do fine in the
    Introduction only.
    
    -- Introduction --
    
       Finally, provider defaults prevents the ISP from being able to detect
       martian packets.  As a result, the ISP transmits packets that could
       otherwise have been dropped over its expensive provider links.
    
    Is "martian packets" a term of art, a bit of humour, or a typo?  If the first,
    is it sufficiently well known that it doesn't need explanation?  I don't
    understand it, but, then, I'm not steeped in this topic.  From the context, I
    can tell that it refers to packets that can safely be dropped.  [UPDATE...
    Lookie here!: Thanks to Robert for referring me to RFC 1208.  Who knew?  Shows
    you how much I don't know about things routing (or Martian).  Never mind this
    bit, then.  :-) ]
    
    The second sentence, though, reads funny: it seems like you're talking about
    dropping packets over expensive links (rather than transmitting packets over
    them).  I think this is clearer:
    
    NEW
    As a result, the ISP transmits packets that could have been dropped, and
    sometimes does so over expensive provider links.
    
       Edge routers may install a default route to core routers, to ABRs
       which are installed on the Point of Presence (POP) to core boundary
       or to the ASBR routers.
    
    With all the "to"s, and too few commas, I find it impossible to parse this
    sentence.  Please re-phrase and/or re-punctuate it so it's clearer.
    
       In configurations where BGP routes are used to resolve other routes
       or where BGP routes are redistributed to other protocols which both
       happen via RIB simple-va can rather then suppressing routes before
       they are installed in global RIB flag them as "suppress eligible".
    
    Another incomprehensible sentence.  Please re-phrase and punctuate it.
    
    -- Security Considerations --
       The authors are not aware of any new security considerations due to
       S-VA.
    
    I believe that, but where *do* the security considerations come from?  From
    full VA?  If so, then it's probably a good idea to refer the reader to that
    document for security considerations.
  5. Sean Turner: Comment [2012-06-19]:
    **word smith alert**
    
    1) abstract: Isn't this about the router running out of memory for the FIB?
    
    OLD:
    
    must upgrade router hardware simply because the FIB has run out of space,
    
    NEW:
    
    upgrade router hardware simply because the server has run out of memory to
    store the FIB,
    
    2) s1, 1st para: same issue as #1
    
    3) s1: what's a partial default?  It's the default some of the time?

draft-ietf-pim-pop-count

  1. Benoit Claise: Comment [2012-06-20]:
    - Same question as Stephen on my side.
    As an OPS A.D., I have to ask: Any connection with the PIM MIB, RFC5060? Or any
    other MIB module? Or is the new information only available via a show command
    in the routers (as a starting point because it's experimental)?
    
    - I found that many acronyms are not expanded (IGMP, MLD, SSM, ASM, etc..), and
    are missing references. Sure they're known if you know multicast. However, the
    RFC-editor will flag those, so you might consider easing the RFC-editor lives
    and at the end the reader not that familiar with multicast
  2. Stephen Farrell: Comment [2012-06-19]:
    Seems like a good experiment. I wondered if there are any MIB
    modules for PIM and, if so, if the stats here are commensurate
    with what the MIB calls for measuring.
  3. Brian Haberman: Comment [2012-06-12]:
    I have no objection to the publication of this experimental document and only
    have a few non-blocking comments.  Take them or leave them as you see fit.
    
    1. The definition of the A/S flag pair seems incorrect.  If A=0 and S=1, that
    does not mean that all receivers are "only SSM" receivers.  It means that all
    receivers are SSM-capable.  The group joined will have an influence on whether
    all receivers are operating in SSM mode.
    
    2. The idea of tracking if an OIF list crosses a domain boundary is
    interesting.  How would a router know that a particular OIF links to another
    domain?  Is it driven by what protocol caused the OIF to be added (e.g., MSDP
    in IPv4)?  It would be good to expand on how that is determined, if there is a
    standard way to detect it.
    
    3. Given the use of a PIM Join attribute, these statistics can aggregate up a
    multicast distribution tree.  What I would be interested in seeing is *how* a
    network operator accesses these stats.  Is it envisioned that a router's CLI
    will be used since there is no defined way to push/pull the data out via a
    management interface?
    
    4. It is unclear to me how useful the time zone information will be.  As
    mentioned in the draft, that information could be contained as an interface
    attribute.  However, that may not be sufficient given multi-access interfaces. 
    Is there more context that can be added as to how these time zone "boundaries"
    are detected/configured/managed?
  4. Russ Housley: Comment [2012-06-20]:
      The Gen-ART Review by Pete McCann on 19-Jun-2012 raised two questions
      that deserve a response.
    
       (1) The Transit and Stub oif-List counts are only 2 octets.  Will
           these fields be large enough to contain the totals for a large
           multicast distribution tree?
    
       (2) Are there any alignment constraints on the options?  It looks
           like all the two-octet options come first and the single-octet
           options come last.  However, is this a requirement for any
           future options that may be defined?
  5. Barry Leiba: Comment [2012-06-14]:
    I had been wondering, at the start of reading this, why it was going to turn
    out as Experimental, and thank you for explaining that.  I wish such
    explanations were always there, and I think it helps a lot.
  6. Sean Turner: Comment [2012-06-19]:
    s3: Any reason you decided to list the Flags in reverse order from the figure?

draft-ietf-spfbis-experiment

  1. (none)

draft-polk-ipr-disclosure

  1. Stewart Bryant: Comment [2012-06-18]:
    I am clearing my discuss on the basis that text of the following form will be
    added:
    
    5.  A Note About Preliminary Disclosures
    
       Early disclosures are not necessarily complete disclosures.  Indeed,
       [RFC3979] can be read as encouraging "preliminary disclosure" (e.g.,
       when a new patent application is made), yet a preliminary disclosure
       might not be updated as new information becomes available later in
       the standardization process (e.g., when a patent is actually
       granted).  To help prevent early IPR disclosures from becoming stale
       or incomplete, at important junctures in the standardization process
       (e.g., before Working Group Last Call or IETF Last Call) WG chairs
       and ADs are encouraged to request that the Executive Director of the
       IETF contact those who submitted early IPR disclosures about updating
       their disclosures.
  2. Benoit Claise: Comment [2012-06-18]:
    - Section 3.3.  Requesting WG Last Call
    
       Working Group Last Call is a particularly significant milestone for a
       working group document, measuring consensus within the working group
       one final time.  If IPR disclosure statements have not been
       submitted, the judgement of consensus by the chairs would be less
       than reliable.
    
    While I think I understand what the second sentence means, my first impression
    while reading it was: what's connection between "IPR disclosure statement" and
    the consensus "reliability"? Do you want to say that the "judgement of
    consensus would be based on incomplete assumptions", or something similar?.
    Most certainly not an issue for English native speakers!
    
    - I see in section 3.4
       If the answer to the write-up
       question is not favorable, or if the chairs did not take any of the
       actions listed above, the AD might choose to contact the authors and
       listed contributors to confirm that the appropriate IPR disclosure
       statements have been filed before advancing the document through the
       publication process.
    
    That document would be perfect if the email for that use case would be added in
    the Appendix A.
    
    - Section A.4.  Reminder to Meeting Presenter
    Isn't the WG chair who is the supposed to send this email?
    It's signed by "Christopher (as AD)"
    
    - For new comers (and this draft mainly targets new comers), maybe a sentence
    or two or how to check whether there is already an IPR associated with a draft.
    Example: http://tools.ietf.org/html/draft-polk-ipr-disclosure-04 -> an IPR link
    would appear on the top right hand side Or insert the draft/RFC in
    https://datatracker.ietf.org/ipr/search/
  3. Ralph Droms: Discuss [2012-06-21]:
    This Discuss point is pretty focused and should be easy to resolve.
    
    Should there be a mention in section 3.2 that an IPR declaration on a
    personal draft must be followed up with an IPR declaration on the
    renamed draft after it is adopted by a working group?
  4. Ralph Droms: Comment [2012-06-21]:
    "Socialize" is a colloquialism that might better be replaced by
    "discuss"; e.g., from Section 3:
    
       In general, these opportunities are encountered during initial
       public discussion, working group adoption...
    
       When IETF participants wish to promote public discussion of a
       personal draft in hopes of future adoption by a working group...
  5. Stephen Farrell: Comment [2012-06-15]:
    - I had a situation where there was an IPR declaration for
    RFCfoo, but when the RFCfoo-bis draft was being done, nobody
    went to the IPR holder and asked them to say if the new draft
    should also have a declaration, and by the time it got to me,
    nobody from the IPR holder was involved in the WG. That added a
    bit of delay. Anyway, would it make sense to say that another
    good thing for a chair/secrerary to do is, when starting work
    on a bis document where the original RFC has an IPR
    declaration, please go check with whoever posted that
    declaration to see if a new one can be gotten or is needed?
    
    - I guess the above is similar to handling the replaced-by
    relationship (that the IPR tools follow) so would similar
    guidance for that situation be worth adding, i.e. "please check
    the replaced-by" relationship is in order so the right thing
    will happen at IETF LC at least.
    
    (Sorry for thinking of those so late in the game)
  6. Pete Resnick: Comment [2012-06-17]:
    In section 3.4, after the quote from the shepherd questionnaire, at the
    beginning of the last paragraph, I suggest inserting a sentence like,
    "Shepherds should be asking these questions of the authors directly." It's
    implicit, but it seems to me not implicit enough.

draft-farrresnickel-ipr-sanctions

  1. Stewart Bryant: Comment [2012-06-11]:
    The policies set out in [BCP79] state that each individual
       participant is responsible for disclosing or ensuring the disclosure
       of Intellectual Property Rights (IPR) where:
    
       - they are aware of the IPR
       - the IPR is relevant to the IETF work they are participating in
       - the IPR is owned by the individual or by a company that employs or
         sponsors the individual's work.
    
    I think that you should put an "and" after each list item.
  2. Benoit Claise: Discuss [2012-06-19]:
    Mister farrresnickel,
    
       It is important to note that each individual IETF participant has a
       choice under the IETF's IPR policy.  If the individual is unwilling
       or unable to disclose the existence of relevant IPR in a timely
       manner, that individual has the option to refrain from participating
       in IETF discussions about the technology covered by the IPR.
    
    In the above sentence, I have an issue with "participating in IETF
    discussions", which IMHO sends the wrong message. For example: I know of an IPR
    from my company, which I don't plan on disclosing (whatever the reason), and
    I'm actually fine because I don't participate in the discussions. In other
    words, I'm fine because I read the emails but don't reply, I listen to the
    (virtual) WG meeting but don't say a word, I listen to the side discussions at
    the IETF but don't say a word.
    
    This also contradicts your text:
    
        The policies set out in [BCP79] state that each individual
        participant is responsible for disclosing or ensuring the disclosure
        of Intellectual Property Rights (IPR) where:
    
           - they are aware of the IPR
           - the IPR is relevant to the IETF work they are participating in
           - the IPR is owned by the individual or by a company that employs or
             sponsors the individual's work.
    
    I believe that your intent of your paragraph comes from
    http://tools.ietf.org/html/rfc3979#section-7
    
    I propose to reuse "must not contribute to or participate in IETF activities"
    from http://tools.ietf.org/html/rfc3979#section-7 since "activities" is a
    broader term covering: emails, discussions, meetings, virtual meetings, etc...
    So actually RFC3979 has got the sentence right.
    
    OLD:
    
       It is important to note that each individual IETF participant has a
       choice under the IETF's IPR policy.  If the individual is unwilling
       or unable to disclose the existence of relevant IPR in a timely
       manner, that individual has the option to refrain from participating
       in IETF discussions about the technology covered by the IPR.
    
    NEW:
    
       It is important to note that each individual IETF participant has a
       choice under the IETF's IPR policy.  If the individual is unwilling
       or unable to disclose the existence of relevant IPR in a timely
       manner, that individual has the option to refrain from contributing to and
       participating in IETF activities about the technology covered by the IPR.
  3. Stephen Farrell: Comment [2012-06-15]:
    Who's that Barry Liebe guy? Must be someone in love
    with Berlin:-)
  4. Sean Turner: Comment [2012-06-19]:
    Not sure this worth doing but should we state that the rules also apply to
    remote participants in the contribution paragraph?  Maybe add the following as
    a new second sentence:
    
      Remote participants as well as those participating in person at
      IETF meetings are bound by this definition.
    
    Also should we add jabber in there to the first sentence?

draft-templin-aero

  1. Ralph Droms: Comment [2012-06-20]:
    I've cleared my Discusses.  Thanks for addressing those points.
    
    1. (fixed in rev -11)
    
    2. (addressed in response from author)
    
    3. (fixed in rev -11)
    
    4. (was Discuss 1) I think some text is needed in section 6.4.7 to
    allow for the scenario suggested in this text from the Introduction:
    
       For example, when an ingress link neighbor accepts an ordinary
       redirection message, it has no way of knowing whether the egress link
       neighbor is ready and willing to accept packets directly without
       involving an intermediate router
    
    The text in section 6.4.7 seems to assume that the egress node will
    always be willing to accept traffic from the ingress node.  Fred
    explained in e-mail that the egress node can passively ignore the
    Predirect message by not sending a response Redirect message.
    However, section 6.4.7 does not explicitly note that the egress node
    can implement this behavior.
    
    5. (was Discuss 2) I suggest s/involving/forwarding through/ for
    clarification.
    
    6. (was Discuss 3) In section 6.4.8, what is the advantage to the
    intermediate router snooping the Redirect response and "relaying" the
    Redirect on to the ingress node without decrementing the hop count,
    rather than what would seem to be a less unusual method in which the
    egress node sends the Redirect to the intermediate router, which
    receives and processes the Redirect, and then sends a corresponding
    Redirect on to the ingress node?
    
    7. (was Discuss 4) Fixed in rev -11.
  2. Adrian Farrel: Comment [2012-06-14]:
    Thanks to the author for providing some cocrete examples and motivation, and
    for moving the experiment to operate over UDP. This addresses my Discuss and I
    am happy to ballot "yes" and encourage this experiment.
    
    I would be interested to hear from the author how he sees the applicability of
    this work to data centers and the NVO3 working group.
  3. Stephen Farrell: Comment [2012-06-13]:
    FWIW, I (still) agree with a bunch of the the other discusses on this.
    
    You've now stated that the signature scheme is for future study,
    which is ok for me for an experimental document like this. However,
    as a comment, I'm still not keen on how 6.4.4 is written right now.
    It says: you're ok if one of 4 things, but how to achieve the last
    one (signatures) is not defined here, yet you say "may be
    obliged" for that.
    
    I'd suggest getting rid of the 4th bullet entirely and making the
    following change (or similar) at the end:
    
    OLD
    
       Note that on links in which link-layer address spoofing is possible,
       AERO nodes may be obliged to require the use of digital signatures
       applied through means outside the scope of this document.  In that
       case, only the fourth of the above conditions can be accepted in
       order to ensure adequate data origin authentication.
    
    NEW
    
       Note that on links in which link-layer address spoofing is possible,
       (which is common) AERO nodes will not be very secure since
       the data origin authentication defined here is easily spoofed. To
       address this, future work might define a strong data origin
       authentication scheme (such as the use of digital signatures) to
       address this problem.
  4. Brian Haberman: Comment [2012-06-14]:
    I support the experiment being proposed in this document and appreciate the
    author's responsiveness to my DISCUSS points.
  5. Russ Housley: Discuss [2012-04-24]:
      I understand that the AERO mechanisms were initially designed for NBMA
      tunnel virtual interfaces, but these mechanisms can also be applied to
      any multiple access link types that support redirection.  That said, I
      think we need to better characterize the environments where AERO is
      appropriate, and maybe even more importantly the environments where
      AERO is not appropriate.
    
      This position seems to be supported by the Gen-ART Review by
      Pete McCann on 24-Apr-2012.  Please consider the other comments that
      are include in this review.  The review can be found at:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07385.html
  6. Barry Leiba: Comment [2012-04-25]:
    Lots of DISCUSS positions already, and I don't have anything new to add.  I'll
    just say that I support some of the other AD's DISCUSS positions, particularly
    Brian's and Ron's.
  7. Pete Resnick: Comment [2012-04-22]:
    I agree with Brian's DISCUSS regarding status. In fact, even Experimental seems
    a bit odd. The document doesn't describe the circumstances under which you
    would want to experiment and why you wouldn't want to let this out on the
    Internet as a proposed standard. I think some more explanation, and perhaps an
    adjustment to status, is needed.
  8. Martin Stiemerling: Comment [2012-04-25]:
    I'm supporting the other DISCUSSes which cover the issues of the draft.
  9. Sean Turner: Comment [2012-06-20]:
    I like Stephen's suggestion for s4.4.

draft-despres-6a44

  1. Stephen Farrell: Comment [2012-06-19]:
    - I wondered if this was fully compatible with IPsec. Seems
    like it ought to be but I've not thought it through, but maybe
    the authors have. If so, that might be a good addition to
    the security considerations. (And who knows, maybe doing
    this experiment with btns might be a fun and even useful
    thing to think about.)
    
    - section 5, typo: s/piecesa/pieces/
  2. Brian Haberman: Comment [2012-06-20]:
    I have no problems with the publication of this document, but I do have some
    technical issues that would be good to address in it.
    
    1. Given the assumption that each network that is supporting 6a44 is using a
    /48, it would be good to state somewhere that operators who are allocated
    something smaller (e.g., /56) can't use this approach.
    
    2. Does the 6a44 approach work correctly with RFC 3484 (or 3484bis) given that
    it is a prefix of last resort but is built out of an ISP's global prefix?
    
    3. I do not understand why "Overall design simplicity" is considered an
    "Operational Requirement".
    
    4. Section 4.4 mentions an applicability scenario where 6a44 applies when a
    dual-stack CPE is assigned only an IPv4 address.  If that is the case, what
    happens when the CPE is RFC 6204 (or 6204bis) compliant and supports 6rd or
    DS-Lite?  Does someone need to disable those features in the CPE?
    
    5. Guidance should be given on what random method(s) should be used to generate
    the Bubble ID.
    
    6. Section 6.4 (bullet 3) says 6a44 clients MUST limit the size of IPv6 packets
    they send to on-link destinations to the link MTU - 20.  What is meant by
    on-link in this case?  Any device inside the CPE should not be encapsulated.
    
    7. Rule CT-2 states that protocol 41 encapsulation (direct to the IPv4
    destination address) is used when sending to destinations within the same site.
    How does that rule relate to RR4-2 which seems to say that clients are still
    sending data to the relay via UDP?
  3. Martin Stiemerling: Comment [2012-06-19]:
    Changed to no object to follow the right process. Just learned something today
    about ISE and the datatracker. Sorry for the confusion.
    
    Nonetheless, those issues should be fixed before publication.
    
    Section 6.2., paragraph 3:
    
    >    An IPv6 packet transmitted from a 6a44 client to another 6a44 client
    >    of the same site is encapsulated in an IPv4 packet whose source and
    >    destination addresses are the private-IPv4 addresses of the two
    >    hosts.  The IPv4 packet is that of a complete datagram (its more-
    >    fragment bit is set to 0, its offset is set to 0, and its datagram
    >    identification may be set to 0).  The size of the IPv6 packet SHOULD
    >    NOT exceed 1280 octets for off-link destinations, and MUST NOT exceed
    >    the link MTU minus 20 octets for on-link destinations (see
    >    Section 6.4).
    
      You reuse protocol type 41 but do not give any reference to rfc 2473.
      2473 lists a number of considerations in terms of ICMP error handling
      and also for the security of tunneling.
    
    Section 6.3., paragraph 1:
    
    >    A Bubble is a UDP/IPv4 packet whose UDP payload comprises a "6a44-
    >    client IPv6 prefix" field and a "Bubble ID" field, and whose UDP
    >    checksum is set to 0.
    
      Why is the UDP checksum set to zero in this case? Is there
      any other protection against packet corruption?
      There is no other means (as far as I can tell) in this case, it
      is thus required to have the UDP checksum set. Otherwise, the bubbles
      might carry wrong information back and forth.
    
    Section 6.4., paragraph 1:
    
    >    Reassembly of a fragmented IPv4 datagram necessitates to remember its
    >    identifier from reception of the first fragment to reception the last
    >    one, and necessitates a timeout protection against packet losses.  If
    >    such an IP-layer stateful processing would be necessary for 6a44, it
    >    would make it more complex than needed, would introduce a
    >    vulnerability to denial of service attacks, and would impose that all
    >    fragments of a fragmented IPv4 datagram go to the same relay.  This
    >    last point would be a constraint on how load balancing may be
    >    performed between multiple 6a44 relays, and would therefore be
    >    detrimental to scalability.
    
      First of all, fragmentation and de-fragmentation is performed
     by the IP layer in IPv4. This is the defined standard behavior which
     is not changed by this specificiation. This is not an argument for
     increased complexity or scalability. Please rewored to state that
     fragment is not desired, but remove the rest.
    
    Section 6.4., paragraph 2:
    
    >    For 6a44 processing to remain completely stateless, IPv4 packets
    >    containing encapsulated IPv6 packets must never be fragmented.  For
    >    this:
    
      In your case you must mandate that the Don't Fragment (DF) bit in the
      IPv4 header is set, but you never state this!
    
      But your text isn't clear about this, as you write that always
      a complete UDP must arrive and that the IP packets have the
      more fragments set to 0, but you do not specify anything about the
      do not fragement bit. I assume you try to talk about the latter one and
      not the more fragment bit.
    
      How should the implementation react to ICMP error messages indicating
      that the packet is too big?
    
    Section 6.5.1., paragraph 8:
    
    >    TM-3  In the "Bubble sent" state, if the timer expires AND the
    >          Attempt count is less than 4, then: the Attempt count is
    >          increased by 1; a new bubble is sent with the current Bubble
    >          ID; the "bubble sent" state is re-entered with the timer reset
    >          to T1.
    
      It is better to say T1' = 2*T1. This will allow to back-off smoothly.
    
    Section 6.3., page 14:
    
    >    In a bubble from a 6a44 client to a 6a44 relay, the "6a44-client IPv6
    >    prefix" field is only reserved space for the response.  It is set to
    >    0.  In a bubble from a 6a44 relay to a 6a44 client, it contains the
    >    IPv6 prefix of the client.
    
     How are the values encoded on the wire. Please clarify this in the text.
    
    Section 6.3., page 14:
    
    >    In a bubble from a 6a44 client to a 6a44 relay, the "Bubble ID" field
    >    contains a randomly chosen value, renewed in circumstances defined in
    >    Section 6.5.1.  In a bubble from a 6a44 relay to a 6a44 client: if
    >    the bubble is a response to a bubble received from the client, the
    >    field contains the value found in the received bubble; if the bubble
    >    is it is a reaction to a received IPv6/UDP/IPv4 packet whose IPv6 and
    >    UDP/IPv4 sources are inconsistent, the field is set to 0.  The
    >    purpose of this field is a protection against 6a44-relay spoofing
    >    attacks (see Section 7).
    
     What means 'inconsistent' in technical terms here?