IESG Narrative Minutes

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

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

Corrections from:

1 Administrivia

  1. Roll Call 1134 EST 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. FLUTE - File Delivery over Unidirectional Transport (Proposed Standard)
    draft-ietf-rmt-flute-revised-13
    Token: David Harrington
    Note: Needs ietf-types review and four downrefs in IETF LC.
    IPR: Nokia Corporation's statement about IPR claimed in draft-ietf-rmt-flute-revised-01.txt
    Discusses/comments (from ballot draft-ietf-rmt-flute-revised):
    1. Ronald Bonica: Comment [2012-02-29]:
      Also concerned about the IPR situation, but Stephen holds the DISCUSS
    2. Ralph E. Droms: Comment [2012-02-29]:
      I have one very minor editorial comment. The document uses "packet" throughout, sometimes without qualification and sometimes with qualification; e.g., "ALC/LCT packet." For the most part, the type of packet can be deduced from the context. However, in section 3.3, it wasn't clear to me if "packet" referred to ALC, transport or IP packet:
      "If an FDT Instance is longer than one packet payload in length, it is RECOMMENDED that an FEC code that provides protection against loss be used for delivering this FDT Instance."
      There may be one or two other instances of "packet," e.g., in section 7, discussing "per-packet" security, that are similarly unclear.
      This use of "packet" seemed a little confusing (although the meaning is probably clear):
      "FLUTE is compatible with both IPv4 or IPv6 as no part of the packet is IP version specific."
    3. Adrian Farrel: Comment [2012-02-29]:
      I have no objection to the publication of this document.
      Thank you for the substantial description of the changes since RFC 3926 which made review considerably easier. I think you might find the need to consolidate the description of the changes which is currently incrementl such tat when more than one change was made to a section over time, it appears in the log more than once. This means that it is currently necessary to read the whole log before understanding what has changed.
      Section 9 ends a little suddenly :-)
    4. Stephen Farrell: Discuss [2012-02-29]:
      #1 The IPR situation here appears complex. This obsoletes the experimental 3296 which has no IPR declarations. A common author for this and 3926 is an inventor of IPR declared in 2006 on this document. Could I get a pointer to where the WG was informed of and/or considered this? (Had a quick look, didn't find it.) Is it (still) the case that 3926 is not considered to require an IPR declaration but this document does? Reading section 11, I don't see much change here so as a result, I'm unclear as to whether the meta-data for these documents is consistent and considered so by the WG.
      So this may be more of a tools issue perhaps - if the new declaration supercedes the old then maybe the tools page for the RFC forgets the old IPR declaration or something. I'll keep the discuss so's we can figure that out.
      http://datatracker.ietf.org/ipr/731/ is a declaration on RFC 3926 as it turns out.
      #2 p20 - why Content-MD5? What's that used for? Is there alg agility? If not, why not (in a standard). If this isn't really needed or useful then why not just deprecate it for the PS version of FLUTE or replace it with something else? Section 7 is quite good btw, but if you do keep Content-MD5 then don't you need to consider a bad (or spoofed) sender that sends different folks different (chunks of) files that are MD5 collisions?
      #3 7.5 calls for IPsec in transport mode as the main security measure and also automated key management which basically means IKE - am I reading that right? Does that actually match the use-cases for FLUTE? Where's the unidirectional aspect gone? If this doesn't match any reasonable FLUTE use-case then don't we end up with no security in practice? I'm not sure what, if any, change might be needed, but I'd first like to understand the reality.
    5. Stephen Farrell: Comment [2012-02-27]:
      (8 items)
    6. Dan Romascanu: Comment [2012-02-27]:
      Is there any companion document that explains the operational model and the manageability aspects related to the deployment of this protocol? If such a document exists it would be worth at least to include a reference to it in this document, in the absence of a operational and manageability considerations section.
    7. Peter Saint-Andre: Discuss [2012-02-29]:
      Other reviewers have expressed many of the concerns I had. Here are a few additional topics I'd like to chat about.
      1. Apparently the application/fdt+xml media type was not reviewed on the ietf-types list, per RFC 4288. At least I see no request for a review in the archives at http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html
      2. The IANA Considerations section is missing a registration of the "urn:ietf:params:xml:ns:fdt" namespace.
    8. Peter Saint-Andre: Comment [2012-02-29]:
      (7 items)
    9. Robert Sparks: Discuss [2012-02-28]:
      In 3.4.2, Content-Location MUST be assigned a valid URI. What does "valid" mean in this context. Does it mean anything more than well-formed? In particular, if the URI is in a scheme that has GET semantics, does "valid" mean you can get the document that way? What does an implementation do if it sees a scheme it doesn't understand? (URI comparison is scheme-specific - it would be dangerous to an implementation to assume two URIs meant different things if it doesn't understand the scheme). If all you need is a unique identifier, what's the advantage of allowing arbitrary schemes to provide it?
      In the discussion of handling time wraparound, "can determine" seems problematic. How do you have interoperability unless both the receiver and the sender interpret this the same way?
      The XML Schema registration (section 8.1) should provide a URI.
      The document needs clearer discussion around the reuse of FDT Instance IDs. I hope I've misunderstood a fundamental idea and a simple clarification will address the following questions.
      * Is the intent that IDs increment by one again after wraparound? Or once wraparound happens, do you always select the next ID using "the smallest FDT Instance value" (you mean ID value, yes?) "assigned to an expired FDT Instance". If the later, then both the receiver and the sender will have to keep an explicit ordering based on when reassignments were received - in the extreme it would be possible to construct a degenerate case where the ordering ended up completely reversed (...,5,4,3,2,1) by using a set of decreasing expiration times as the ID space is traversed the first time. I realize a sender wouldn't really do that, but it's enough that it only have a couple of elements in the sequence that aren't in increasing order. That should be made clearer, particularly where you talk about the ordering being used (such as when describing the semantics for any two "File" elements declaring the same "Content-Location" but differing "TOI"). It would also help to summarize where the ordering is actually used by the protocol.
      * How would a receiver that joined after the sender started reusing IDs know that had happened? If it can't, the consequence is that all receivers have to keep track of what order they received FDTs in from whenever they join.
      * Since it's possible for a receiver to miss FDT instances, once wraparound starts it looks like its possible for two different receivers to have a different idea of what's "newer". Does that break anything?
      * Currently, receipt of an instance that reuses the id from a non-expired instance SHOULD be considered an error. When would the reciever _NOT_ consider this an error? Why is the document leaving receiver behavior out of scope? This seems to invite interoperability failure in deployed systems.
    10. Robert Sparks: Comment [2012-02-28]:
      The last paragraph of 3.4.2 says it is RECOMMENDED that new attributes are defined in 2616 or a well-known specification. RECOMMENDED is a synonym for SHOULD. It would help to describe why this isn't REQUIRED in the document.
      In the last paragraph of section 3.3 (which talks about using out-of-band mechanisms for communicating attributes associated with files), consider reinforcing that using such an out-of-band mechanism does not make sending FDT instances in the session optional.
      The section on Intended Environments claims FLUTE is applicable for non-Internet systems, providing an example, but no support for the claim. Consider editing this to say something less subjective, like "FLUTE has also been adapted for use in other network architectures, such as..." and if possible, provide a reference.
      The document never explicitly says when the application/fdt+xml media type gets used.
      I'm a little surprised there's not a registry around that already assigns codepoints to encoding (particularly compressing encoiding) algorithms. The closest I could find is <http://www.iana.org/assignments/http-parameters/http-parameters.xml> which doesn't establish codepoints. Please consider reconciling with that registry.
      NIT: Section 3.1 has a list of rules. Several of the bullets in the list are not actually rules. Consider moving those to an introductory paragraph before the actual rules.

    Telechat:

  2. Localized Routing for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-netext-pmip-lr-08
    Token: Jari Arkko
    Note: Basavaraj Patil (basavaraj.patil@nokia.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-netext-pmip-lr):
    1. Ralph E. Droms: Discuss [2012-02-29]:
      1. I think there is some confusion about the "R" flag. The caption for Figure 2 (and other Figures) includes:
      "where R and U are the flags defined in Section 9.1 and 9.2."
      but I don't see any definition of an "R" flag in section 9.1. In my opinion, the "R" flag is unneeded if the LRI and LRA messages each have a separate header type code.
      2. I don't see any text that describes how an LMA cancels local forwarding service, as implied in this text in section 4:
      "For instance, the LMA may send a LRI message with a request to cancel an existing local forwarding service."
      3. In section 5, what happens if, for some reason, one of the MAGs (e.g., MAG1) responds with a non-zero status code in its LRA to the LMA? Does MAG2 need to be notified, perhaps because it has some state that must be taken down? This text should be extended to allow for error cases:
      "When the MAG IP Address option is present, each MAG MUST create a local forwarding entry such that the packets for the MN attached to the remote MAG are sent over a tunnel associated with that remote MAG."
      The only mention of error cases in section 5 seems to be:
      "Barring the error cases, all subsequent packets are routed between the MAGs locally, without traversing the LMA."
      4. In section 5:
      "It will hence initiate LR at nMAG1 and update the LR state of MAG2 to use nMAG1 instead of MAG1."
      how does the LMA perform the state update and doesn't it also have to update some state in MAG1?
      5. The text in section 6.1 is completely lacking any description of what the various participants should do in the case where an MN moves to a new MAG.
      6. I'm not sure section 7 gives enough detail into the various ways in which an established LR situation must be torn down. For example, in the A11 case, does the LMA or the MAG determine that one of the MNs has moved and the participants are now in A22?
      7. In section 9, I can't find definitions for LRA_WAIT_TIME and LRI_RETRIES.
    2. Ralph E. Droms: Comment [2012-02-29]:
      (6 items)
    3. Adrian Farrel: Discuss [2012-02-29]:
      Updated Discuss and Comment to make it clearer which points I want to see addressed, and which are just "desirable".
      The issues come from the Routing Directorate review by Les Ginsberg on 2/27/12. You can engage with Les direct at ginsberg@cisco.com for clarification, but the Discuss issues are mine.
      Why are you not using the "MN-CN" terminology from RFC 6279? The fact that you use "MN-MN" makes me think that you are only addressing cases where both endpoints are MNs. Is this the case? If so, this should be explicitly stated. If not, it would seem to be better to use the RFC 6279 terminology.
      Section 5
      I assume the lack of requirement for synchronization works because the LMA will always forward packets regardless of whether it has sent an LRI/received an LRA? This implies that MNs and MAGs may receive duplicate packets at times - which presumably should be no problem. I am wondering if it would be useful to discuss these points?
      Similarly, in Section 6.1 it is assumed that LMAs always forward inter-MN packets regardless of the state of LR?
    4. Adrian Farrel: Comment [2012-02-29]:
      Nits: A number of acronyms are used without definition. For example, in Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not represent a complete list. Can you please scrub the document for all such occurences?
    5. Stephen Farrell: Comment [2012-02-29]:
      - LR with two MAGs implies that MAG1 knows that MAG2 is the CN's location at the granularity of the MAG (MAG2) with which the CN is associated.. Since there is a way for a MAG to initiate this then a bad or compromised MAG could attempt to track any CN for which LR is enabled who's address the bad MAG knows. That is a privacy problem for the CN's. I noted this about the DIME WG equivalent draft and the authors of tha suggested that text as per the above would be better in this document. I'm not sure there's a mitigation here really but I'd say its worth noting at least.
      - Figures 1 and 2 have no real caption and aren't referred to from the text so are less useful than they could be.
    6. Russ Housley: Discuss [2012-02-27]:
      The Gen-ART Review by Mary Barnes on 24-Feb-2012 includes many issues, and the authors have agreed to make fixes. The revised document has not been posted yet.

    Telechat:

  3. MANET Cryptographical Signature TLV Definition (Proposed Standard)
    draft-ietf-manet-packetbb-sec-08
    Token: Adrian Farrel
    Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-manet-packetbb-sec):
    1. Stewart Bryant: Comment [2012-02-28]:
      minor nit - TLVs is plural of "Type-Length-Value" not "Type-Length-Value structure" and expansion is NOT REQUIRED
      It's a bit confusing putting a mini-IANA section in the Intro.
      Section 13 after "This specification requests" a number of the terms defined are not used in the document.
    2. Stephen Farrell: Discuss [2012-02-28]:
      I have a number of discuss points here. Maybe some of this is just that I don't have the right context but I find it hard to see how this is really baked as-is. I guess I'm wondering if it would perhaps be better to wait until someone actually does an implementation? (The write-up says there are none known.)
      #1 I don't understand why this does not define any actual algorithms. Is there another document going to do that? If not, then what's the point of this being on the standards track with no algorithms and no automated key management? I don't see any MANET WG documents that will obviously provide those nor any relevant milestones. (Mind you, all the milestones are dated 2007;-)
      #2 Does this allow or preclude MACs such as HMAC-SHA1? If the former then you need to change terminology as those are not signatures. (I'd suggest integrity check value instead.) If the latter, then why do you want to prevent that? While I don't care too much about the specific terminology, (others do though), you definitely need to be clear if you really mean only digital signatures or not.
      #3 I don't understand why an 8-bit key index is sufficient for a large network. (And key index is not really a good term, I think key identifier would be much better.) With key rollovers and some form of key derivation for different directions (to prevent reflection attacks) and maybe two different key usages for different kinds of message or something like that, that would mean only supporting 32 unique keys values for a given purpose in the entire network which just seems too small. I'd suggest changing that to a key identifier length-value field or at least providing some way to identify key number 257 and beyond.
      #4 Are "badly formed" and "insecure" assumed to be the same? (Section 4 implies they are.) If so, that would seem to preclude any MANET routing scheme where a node might forward cryptographic fields but not act upon a routing message that it understands but cannot verify. Was that considered by the WG and was it rejected? Rejecting that seems to imply that all nodes need to be kept up to date with all keying material all the time which seems brittle and would also seem to make it very hard to introduce a new algorithm except as a flag-day or by having all nodes add fields for all algorithms. (Which in turn implies MANETs will remain tiny so that this will be practical or that large MANETs won't be able to use security.)
      #5 I don't understand why you don't define at least one timestamp precisely. Why would you want 250 varieties of timestamp anyway?
      #6 Having separate hash and cryptographic function registries might not be the best plan since not all combinations will make sense. Is that really a good idea? Why not make use of some other registries that already exist? (That is, is there a particular reason why you need new registries or have you looked but not found one that'd work?)
    3. Stephen Farrell: Comment [2012-02-28]:
      - Title seems misleading reading the abstract. Suggest adding mention of timestamps in title and fixing signature term as per discuss point 1.
      - Using the term "unsigned timestamp" in 13.2 seems like a bad choice given that a you're using signature all over the place. I'd suggest qualifying that.
    4. Peter Saint-Andre: Comment [2012-02-28]:
      I concur with Stephen Farrell's thorough analysis.
    5. Robert Sparks: Discuss [2012-02-28]:
      Section 10.2 says "If both a TIMESTAMP TLV and a SIGNATURE TLV are associated with an address, the TIMESTAMP TLV <value> SHOULD be considered when calculating the value of the signature".
      "be considered" is vague - can it be made more precise? Is this trying to say the signature should cover the timestamp? If so, how is this interoperable as a SHOULD instead of a MUST?

    Telechat:

  4. Port Control Protocol (PCP) (Proposed Standard)
    draft-ietf-pcp-base-23
    Token: Jari Arkko
    Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-pcp-base):
    1. Wesley Eddy: Discuss [2012-02-28]:
      (1) In Section 13.1.3, when discussing responses to unsolicited multicasted ANNOUNCE messages, there seems to be potential for a large number of packets to be generated all at once. There should be some guidance here about whether the responses need to be dithered or paced in some way. This was raised as part of Pasi Sarolahti's TSVDIR review.
      (2) It seems that there isn't a good way to unambiguously match a response up to the request that generated it; especially when there have been (perhaps multiple) retransmissions. Is this really the case? If so, it seems that it should either be remedied or the impact needs to be discussed.
      (3) In Section 7.1, note that the guideline from RFC 5405 for retransmission is one datagram per RTT or in absence of an RTT measurement, one datagram every 3 seconds. The 2-3 seconds in section 7.1 is slightly more aggressive than this. I think timers on the order of seconds may be horribly long though compared to the expected RTT between the client and server. Would it be possible to cache an RTT if it could be measured during some request-response pair, and use that rather than the 2-3 second rule? (note this would require unambiguous relation of responses to requests, as in the prior DISCUSS point).
    2. Adrian Farrel: Comment [2012-02-27]:
      (8 items)
    3. Russ Housley: Discuss [2012-02-27]:
      The Gen-ART Review by Richard Barnes on 27-Feb-2012 raised a few concerns. Please respond to at least these concerns:
      (1) Several people, including Richard, think that implementation would be simplified if a transaction identifier were used. An identifier can simplify response processing, clarify the meaning of lifetime parameters, and provide some protection against address spoofing.
      (2) Add explanation of consequences from spoofed packets. (Or better, make it easier to detect and discard them.) An off-path attacker might be able to break synchronization in state between clients and servers, for example, by sending gratuitous responses. Richard offers this example flow as a way for an off-path attacker to steal traffic:
      1. Attacker obtains mapping from address:port=A:P on PCP controlled device to one of its ports B:Q
      2. Attacker convinces client that it has a mapping from A:P to its port C:R
      3. Attacker acts as a man in the middle: remote -> A:P -> B:Q -> C:R
      (3) It seems the ANNOUNCE method provides an opportunity for an attacker capable of spoofing to cause an arbitrary number clients to flood the server with requests. Please add explanation of consequences if an attacker mounts this attack. (Or better, make it more difficult for an attacker to do so.)
    4. Russ Housley: Comment [2012-02-27]:
      The Gen-ART Review by Richard Barnes on 27-Feb-2012 raised a few concerns. Please consider these points:
      (a) The document says that v4-mapped addresses are not used as source or destination addresses for real IPv6 packets. Richard is aware of some work on IPv6 traceroute scanning where numerous routers will respond from v4-mapped addresses. It probably would be accurate to say that these addresses would never appear in a mapping.
      (b) In Section 6.4, the first paragraph says that each error is "long" or "short", but they're not all marked. Is there a default? It also seems like some of these errors are effectively permanent, such as UNSUPP_VERSION; the PCP NAT isn't going to support a new version of the protocol half an hour from now.
      (c) In Section 7.1, you first say that "only a single PCP server address is supported", but then in a couple of other places mention a "list of PCP servers". Which is it?
      (d) In Section 7.1, it seems like it would be pretty unusual for the PCP server to be the first-hop router, at least outside of the CPE case. Would it be better to use an anycast address to find the server?
      (e) I did not find that the code samples in Section 9 added any information. The one case where one would have been helpful (9.4), there was none.
    5. Pete Resnick: Discuss [2012-02-27]:
      [Note: I'm on vacation this week and therefore my RTT will be exceedingly long. I've only just gotten through the beginning of section 7 and already I have a slew of comments. Some of the ones in the COMMENT section might move up to DISCUSS, but I haven't had time to sort through all of it yet. The two that are currently labeled DISCUSS are definitely in that category. Either way, I asked Jari and he said to send you what I've got so far. More to come soon.]
      Section 6.3: "The handling of an Option by the PCP client and PCP server MUST be specified in an appropriate document, which MUST state whether the PCP Option can appear in a request and/or response, whether it can appear more than once, and indicate what sort of Option data it conveys."
      This does not belong here. This sounds like an IANA Consideration, that you are requiring a document for registration, and you are specifying what goes in that document. If so, then put this (without the MUST) into the IANA Considerations section with appropriate language. Otherwise, I don't understand what protocol force this documentation requirement has.
      "Option definitions MUST include the information below:"
      Again, that looks like IANA considerations.
      Section 7: "PCP is idempotent"
      That's a fine thing, but I believe there's a missing bit of functionality in this protocol to pull it off: Let's say I send a request that results in an error condition, and the error response is sent back but it is delayed. I'm an aggressive client, so I send another request. That one succeeds. Now I get back the error response. Or I get the success response first, and then finally the error response comes back. How do I know which request succeeded and which one failed? Do I have to check the Epoch Time to put them in order and assume that none of the responses were lost? A serial or sequence number in the request that is turned around in the response would solve this problem. Am I missing something?
    6. Pete Resnick: Comment [2012-02-29]:
      I find all of the references to the "interworking function" from UPnP to be inappropriate in this document and should be removed. This is specific implementation advice for a specific environment, not protocol and not required for interoperability. I think it weakens the protocol specification and could have bad effects down the road. (Cf. IMAP, where specific accomodation of implmentation semantics led to all sorts of interoperability failures.) I think having a separate document with specifics of how to do PCP for UPnP is fine, but it shouldn't be in this document.
      The notion of "subscriber" is unnecessary for this protocol and should be removed. It is sufficient to talk about per-host limits and quotas to explain the concepts that are there and then the document will not have to talk about the mapping of a business model onto the protocol.
      All of the forward references in this document make it somewhat confusing, and I suspect longer than it needs to be. I don't see why sections 10-12 can't be moved earlier in the document.
      Section 3:
      PCP Client definition. I don't find the parenthetical bit about several web browsers useful; readers will confuse multiple instances of the same browser with multiple browsers and the message will be muddied. Not only that, anyone who will be coding this is well aware that multiple applications can run on a single host. I found myself wondering what the note was trying to get at. I also found the reference to UPnP not terribly helpful. I would strike it and simplify this description.
      PCP Server definition is circular. Better would be: "A PCP software instance that resides on the NAT or Firewall that receives PCP requests from the PCP Client and sets up the appropriate state in response to that request."
      "* Explicit dynamic mappings are created as a result of explicit PCP MAP and PEER requests."
      MAP and PEER are not defined yet. You could define the actions of mapping and peering and then use the verbs instead of the OPCODEs here.
      Section 6.1:
      "Version: This document specifies protocol version 1. This value MUST be 1 when sending, and MUST be 1 when receiving."
      I'll begrudingly allow that it "MUST be 1 when sending", but I find this to be a silly use of 2119 anyway; it MUST be 1 iff you are implementing this version of the protocol, which seems stupidily redundant. I think such language also encourages receivers to do stupid things if the version is not 1. ("Well, the protocol says that it MUST be 1, so I don't have to do any error checking.") So, I would drop that bit. But it is simply not true that it "MUST be 1 when receiving." It very well might not be, which is why there's an error code for wrong version.
      "Requested Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 2^32-1 seconds. This is used by the MAP and PEER Opcodes defined in this document for their requested lifetime. Future Opcodes which don't need this field MUST set the field to zero on transmission and ignored on reception."
      So, it seems to me (given the last sentence) that this should have been opcode specific and appeared in that part of the header. I assume that ship has sailed. But I still don't understand the last sentence: Why should future opcodes be required to have that field filled with zero if it's not being used? If I use it, I fill it in with what I think it means. If it's not used, neither side will use it and the opcode will specify that. I don't see what use it is to make the admonishment here. (Same issue in 6.2.)
      And again, MAP and PEER are used before being defined. (I'll not mention this problem again, but MAP and PEER are mentioned several times before section 9 rolls around.)
      Section 6.3:
      "It is the responsibility of the PCP client to ensure the server has sufficient room to reply without exceeding the 1024-byte size limit."
      What 1024-byte size limit? This is the first mention in the document.
      "An Option MAY appear more than once in a request or in a response, if permitted by the definition of the Option. If the Option's definition allows the Option to appear only once but it appears more than once in a request, and the Option is understood by the PCP server, the PCP server MUST respond with the MALFORMED_OPTION result code; if this occurs in a response, the PCP client processes the first occurrence and MAY log an error."
      What's this error logging business? Is the server (for some interoperability reason) not allowed to log an error but the client is? This doesn't sound like protocol to me; sounds like implementation advice, and boring implementation advice at that. Strike the "and MAY log an error." A client doesn't need your permission to do so.
      "PCP clients are free to ignore any or all Options included in responses, although naturally if a client explicitly requests an Option where correct execution of that Option requires processing the Option data in the response, that client is expected to implement code to do that."
      I cannot figure out what the above is trying to accomplish that is non-obvious. Is there some case where this makes some sort of interoperability difference? How could you tell if the client actually ignored it or processed it?
      Section 7:
      "PCP messages MUST be sent over UDP [RFC0768]."
      It seems to me that ICMP might be the correct choice instead of UDP, but I understand I may be blowing into the wind.
      Section 8:
      1. If a client or server supports more than one version it SHOULD support a contiguous range of versions -- i.e., a lowest version and a highest version and all versions in between."
      Why is it useful (let alone an interoperability RECOMMENDation) to do that? I can see a stinker of a version potentially come out and the implementer decide that it's not worth implementing that version. What's the downside?
      Section 9:
      "Some applications will break if mappings are created on different IP addresses, so applications should carefully consider the implications of using this capability."
      What applications are those? And what is the nature of that breakage? I don't understand what this sentence means.
      "Static mappings for that Internal Address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) SHOULD also be assigned to the same External Address."
      Why? What breaks if they are assigned to different External addresses? (I'm also not sure why static mappings are discussed in this document at all; there is no protocol involved in static mappings.) Also, what happens if the client requests two different explicit mappings? What should the server do then?
      Section 10.2:
      "If the client wants all protocols mapped it uses Protocol 0 (zero) and Internal Port 0 (zero)."
      I don't understand how this will work. If I am a client that says "Protocol 0, Internal Port 0", haven't I just taken over the entire external address from the NAT, and therefore nobody else connected to that NAT can use PCP?
    7. Peter Saint-Andre: Comment [2012-02-29]:
      Other reviewers have provided significant input. I have a few additional comments.
      In Section 7.5, is the recommendation about 6.25% clock skew based on empirical evidence?
      In Section 8 (bullet 6), why would the client expect that the server might support its old version after 30 minutes?
    8. Robert Sparks: Discuss [2012-02-28]:
      1) Section 7 paragraph 2 asserts the protocol is idempotent, but then shows an example where it isn't. If you allow a retransmitted request to produce a different response, the protocol is not idempotent. Given that you allow this, not changing any bits in the request when you retransmit it allows the client and server to end up with different views of the request's success. Example:
      View in a fixed-width font:
      
         Client                   Server
      
           |          req            |
      
           |------------------------>|
      
           |        error response   |
      
           |     X<------------------|
      
           |       req               |
      
           |----------->X            |
      
           |          req            |
      
           |------------------------>|
      
           |        error response   |
      
           |               ----------||  Big delay in network between
      
           |   req       /           ||  client and server here
      
           |------------c--.         ||
      
           |           /    \        ||
      
           |<---------       `------>|
      
           |       success response  |
      
           |         X<--------------|
      
           |                         |
      
           |                         |
      
      

      Note that epoch time doesn't help with this, but might with the below variants:
      variant 1 - the success response actually delivers, after the client is no longer looking for a response
      variant 2 - the success response delivered first, followed by the delayed error response
      Adding a transaction identifier would only help if it was allowed to change with retransmission, and then the client would have to keep retransmitting until it got a response matching its most recent transmission before assuming it and the server were in agreement about the state at the server. Alternatively, you could require the server to actually be idempotent and never respond differently to the same request. (But you would need to put a finite limit on how long a client should retry before giving up on getting a response so that the server wouldn't have to remember the request and what response it sent forever).
      2) Having text written for having a list of servers, and other text that says "for this document, the list can only have one element in it" is very confusing, and will likely lead to implementation mistakes. Would it be too hard to rewrite the text to say "the server" instead of "the first server in its list", and add a section warning implementers to anticipate handling lists when the protocol is extended?
      3) I'm not seeing a discussion of the consequences of someone being able to spoof an unsolicited ANNOUNCE response - that seems like an attractive target for someone wanting to DoS a large scale server. Related - if you are operating a CGN-sized server, what keeps sending such an ANNOUNCE response from effectively resulting in an avalanche-restart style flood of traffic from all the clients using that server?
    9. Robert Sparks: Comment [2012-02-28]:
      The statement "Of course, this sort of behavior is common to all UDP-based protocols" just before section 7.1 is not true.

    Telechat:

  5. Wildcards in Multicast VPN Auto-Discovery Routes (Proposed Standard)
    draft-ietf-l3vpn-mvpn-wildcards-02
    Token: Stewart Bryant
    Note: Ben Niven-Jenkins (ben@niven-jenkins.co.uk) is the Document Shepherd
    Discusses/comments (from ballot draft-ietf-l3vpn-mvpn-wildcards):
    1. Stephen Farrell: Comment [2012-02-28]:
      I would have thought that the ability to mis-direct traffic would be enhanced with the addition of wildcards and that that might be worth a mention in the security considerations. That is, while there may be no new threat, nor any new countermeasure needed, the potential impact of an existing threat would seem to be increased by this.

    Telechat:

2.1.2 Returning Items

  1. Elliptic Curve DSA for DNSSEC (Proposed Standard)
    draft-ietf-dnsext-ecdsa-07
    Token: Ralph E. Droms
    Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd.
    IPR: Certicom Corp's Statement of IPR Related to draft-ietf-dnsext-ecdsa-00
    Discusses/comments (from ballot draft-ietf-dnsext-ecdsa):
    1. Wesley Eddy: Comment [2012-02-14]:
      I support Russ and PSA's DISCUSS points
    2. Adrian Farrel: Comment [2012-02-14]:
      I presume that Section 6 needs to be updated as this document goes through the publication process. I think you should provide instructions to the RFC Editor on what should be done to this section.
      A way to do this would be to supply an RFC Editor note that fixes the section consistent with the actual IANA allocations, but will not show in the document until published as an RFC.
    3. Stephen Farrell: Comment [2012-02-13]:
      Section 4 says you MUST support signing "and/or" validation with both lengths. I think that is not quite clear enough as the requirement differs for different players in the DNSSEC game. Aside from basic clarity, which is the most important thing, there is also an IPR declaration here that distinguishes between things that are needed and things that are optional so I think expressing it in a way that makes clear that there are no optional-to-implement bits for anyone would be an improvement. I'd say that it'd be better to spell it out that implementations that create DNSSEC values to put into the DNS MUST implement signing and verification for both lengths, and that DNSSEC clients MUST implement verification for both lengths. (Or whatever is the right way to say thing.)
      Will the examples be re-done after IANA have allocated codes? Be more than nice if that were to be the case.
      An informational pointer to RFC 6090 might be no harm here (and everywhere that uses ECC).
    4. Peter Saint-Andre: Comment [2012-02-28]:
      Thank you for addressing the issues raised by Bill Mills in his AppsDir review.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Simplified Multicast Forwarding (Experimental)
    draft-ietf-manet-smf-13
    Token: Adrian Farrel
    Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-manet-smf):
    1. Stewart Bryant: Discuss [2012-02-29]:
      Please confirm that the issue raised by IANA on 28/Feb has been addressed.

    Telechat:

  2. Interworking LISP with IPv4 and IPv6 (Experimental)
    draft-ietf-lisp-interworking-05
    Token: Jari Arkko
    Note: Terry Manderson <terry.manderson@icann.org> is the document shepherd.
    Discusses/comments (from ballot draft-ietf-lisp-interworking):
    1. Stewart Bryant: Comment [2012-02-29]:
      Default Free Zone (DFZ) should have a reference, if only a forward ref to section 2 when you first use it in section 1
      Asymmetry is a problem with certain types of application, NTP for example. It would be useful if there was some discussion on the relative degree of asymmetry imposed by these LISP solutions vs the degree of asymmetry in the existing Internet, and a note made about the impact of asymmetry on applications
    2. Adrian Farrel: Discuss [2012-02-29]:
      I only have a minor Discussion point (do I hear the authors sighing?)
      Section 4.2 says
      "Non-LISP sites today use BGP to, among other things, enable ingress traffic engineering. Relaxing this requirement is another primary design goal of LISP."
      I went back to look for the description of this design goal in the LISP spec and I couldn't find it. Might be my search was a bit random. Might be the design goal wasn't stated in the base spec and so shouldn't be claimed here.
    3. Adrian Farrel: Comment [2012-02-29]:
      Thank you for the paragraph at the end of the Introduction.
      This document would be made significantly more useful by the addition of a figure showing the architectural components.
      Please s/draft/document/ throughout.
      Section 2: "For traffic not to be dropped, either some mechanism to make this destination EID routable must be in place."
      Typo "either", or missing "or".
      Section 5.2:Are there any consequences of the assymetry of PITR use that we should investigate? Yes, I know that the Internet is not always symmetric, but in general it often is.
    4. Stephen Farrell: Comment [2012-02-29]:
      - Its not clear to me that the mapping system can reliably know that all non-LISP IP addresses are in fact not EIDs. But I'm willing to suspend disbelief for the experiment:-)

    Telechat:

  3. Analysis of Stateful 64 Translation (Informational)
    draft-ietf-behave-64-analysis-06
    Token: David Harrington
    Note: Dan Wing (dwing@cisco.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-behave-64-analysis):
    1. Adrian Farrel: Comment [2012-02-28]:
      (6 issues)
    2. Russ Housley: Discuss [2012-02-28]:
      The Gen-ART Review by David Black on 28-Feb-2012 raises one major concern that needs to be addressed. David offers alternative text, but the authors have not said whether they agree with it as yet.

    Telechat:

  4. Overview of Pre-Congestion Notification Encoding (Informational)
    draft-ietf-pcn-encoding-comparison-08
    Token: David Harrington
    Note: Steven Blake, PCN co-chair (slblake@petri-meat.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-pcn-encoding-comparison):
    1. Adrian Farrel: Discuss [2012-02-29]:
      Section 3.2.3
      I cannot reconcile the text in option (1) that says:
      with the conclusion of the section that says:
      "Option (1) seems to be the most viable and efficient solution."
      If it is the intention of the PCN working group to be "PCN for IP-only networks" then I do think this could be s[elled out. OTOH, if MPLS is in scope, then surely option (1) is impractical.
      Note that draft-ietf-pcn-3-in-1-encoding makes a specific statement about applicability only to IP.
      What does "Primarily" mean in this context?
      I would like you to replace the passive voice in Section 4.5 so I can tell who made the decision!
      Additionally, I would like to understand why there are other PCN working group documents for other encodings (draft-ietf-pcn-3-state-encoding, draft-ietf-pcn-psdm-encoding) if this section represent a full statement of the WG's decisions.
      I'm afraid I found the conclusion in Section 5 particularly impenetrable.
      Could you:
      - Break out "what we did in this document" as a separate paragraph.
      - Make a definitive statement about what the WG has concluded.
      - Place the summary of the reasons for the conclusion as a third paragraph.
    2. Adrian Farrel: Comment [2012-02-29]:
      (6 items)

    Telechat:

  5. Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication (Experimental)
    draft-ietf-mext-mip6-tls-03
    Token: Jari Arkko
    Note: Basavaraj Patil (Basavaraj.Patil@nokia.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-mext-mip6-tls):
    1. Adrian Farrel: Comment [2012-02-29]:
      I am balloting No Objection on the assumption that this has been thoroughly reviewed by the INT ADs and the Security Directorate.
    2. Stephen Farrell: Discuss [2012-02-29]:
      So while this seems to be quite a good idea, I've a couple of things I want to understand...(oops - added #3 below, forgot that)
      #1 Has the security of the auth protocol in 5.8 been studied much? If so, where is that described? I'm surprised there's nothing directional to prevent reflection attacks or cross-protocol attacks, e.g. by including MN and HAC-specific strings in the HMAC input. As-is, it also looks like messages 2 and 3 could maybe be reflected. It also looks like messges can be replayed since the tls-server-end-point CB-octets are fixed per-hac. Since CB-octets are essentially public, guesses of the MN's PSK are also possible, if that is somehow human-memorable. This all looks like a problem to me that needs to be looked at even for an experimental spec, or maybe I'm misreading something. (I guess similar concerns might exist for the eap method in 5.9 as well.)
      #2 If MN authentication is done above TLS then you might need to ensure that TLS implementations are not vulnerable to the TLS re-negotiation bug. (See RFC 5746.) Did you think that thgrough? Might be worth noting in the security considerations even though the MN<->HAC authentiction scheme uses channel-bindings, just in case. (Actually since the CB-octets are not session-specific this might be a gotcha too.)
      #3 The draft seems to be missing information on how to match TLS certificates to identities for HAC authentication.
    3. Stephen Farrell: Comment [2012-02-29]:
      - I don't see why MN authentication has to be done outside the TLS session setup (handshake). TLS supports client authentication and it's not clear why that couldn't be used here instead of the scheme in 5.8/5.9.
      - Isn't there already a way to do EAP over TLS? Why invent a new one? I think you should say why, if its justified. (e.g. RFC 5281.)
      - 4.2: I guess you also need mutual authentication between non-colocated HAC and HA instances? (That might seem like nit-picking, but there are ways to get integ. & confid. without knowing for sure from whom stuff is coming.)
      - I'm a bit surprised that you don't want to use RFC5705 to extract some key material from TLS sessions. Worth considering and/or noting as a possible future improvement?
      - 5.6 seems a bit brittle - if TLS changes the set of preferred ciphersuites that could in principle result in a mismatch between the TLS preferred ciphersuites and what's doable between MN and HA.
      - In 5.8 you don't seem to have algorithm agility for your "auth" algorithm - can it be other than HMAC-SHA256? Maybe ok for an experimental RFC though but worth noting.
      - In 5.8 after figure 4, step 2, what is msg-octets when none of the optional fields are included? The description in the last two paragraphs seems a bit broken too. (2nd last para should be about step 2 I thought)
      - As commonly used, TLS doesn't quite give the same level of security as IPsec as commonly used. IPsec has perfect forward secrecy due to its use of D-H, whereas TLS with RSA key transport does not. That means that a later exposure of a server RSA private key (e.g. if de-commissioned h/w isn't properly scrubbed) potentially allows anyone to recover TLS pre-master keys from any recorded TLS sessions. That's worth noting so that if someone does deploy this, they know to not just sell old server h/w that used to store RSA private keys on disk.
      - TLS with RSA key transport also relies on the entropy provided by the client for security. That has been a source of known problems over the years (including very recently) and so is also worth noting since the client here is a mobile node that might just have been turned on and so not have lots of entropy.
      - While TLS protects against replays, if somehow I get the auth protocol messages then I can replay those in a new TLS session with the HAC so the text in the security considerations on this point might need to change depending on the discuss pionts above.
      - There're some points worth noting in the secdir review as well. http://www.ietf.org/mail-archive/web/secdir/current/msg03131.html
    4. Russ Housley: Comment [2012-02-29]:
      Please see the comments in the Gen-ART Review by Ben Campbell on 28-Feb-2012. The comment that causes me the greatest concern is covered by the (updated) DISCUSS position from Stephen Farrell. Please consider all of Ben's review comments: http://www.ietf.org/mail-archive/web/gen-art/current/msg07232.html
    5. Peter Saint-Andre: Discuss [2012-02-28]:
      Section 9.2 states that "Server-side certificate based authentication MUST be performed using TLS 1.2 [RFC5246]" but that "The client-side authentication may depend on the specific deployment and is therefore not mandated." However, you don't say anything about the basis for authentication or identity checking. What identifiers need to be in the certificates? How are those identifiers checked? What are the rules? We can't just wave our hands here, else interoperability will be impossible (as will real security). Profiling RFC 6125 might make sense, if the identifiers are domain names. If the identifiers are IP addresses, then life is simpler, but we would still need to say something about identity checking.

    Telechat:

  6. Operational Neighbor Discovery Problems (Informational)
    draft-ietf-v6ops-v6nd-problems-04
    Token: Ronald Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-v6ops-v6nd-problems):
    1. Stewart Bryant: Comment [2012-02-29]:
      I have no objection to the publication of this document.
      It discusses a problem that is very close to the problem that we have chartered the ARMD to address and I am wondering whether there needs to be a reference to that work.
    2. Adrian Farrel: Comment [2012-02-28]:
      I have no objeciton to the publication of this document, but I noticed a few small points I hope you will look at before publication.
      While appreciating the desire to use RFCs to force vendors to provide specific function to the operators, I don't think that the use of RFC 2119 language in this Informational document adds very much (the language is intended to add clarity to protocol specifiations, and is sometimes used to make requirements documents clearer). In fact, I cold only find two uses of such language (both are "SHOULD") in this document so I suggest you change them to normal lower case, and drop the boilerplate from Section 1.
      Section 4: "During testing it was concluded that 4 simultaneous nmap sessions from a low-end computer was sufficient to make a router's neighbor discovery process unusable and therefore forwarding became unavailable to the destination subnets."
      Without casting aspertions on the authors, is it possible to provide some qualification of this statement? For example, a reference to the test description and results, or a simple note as to by whom the testing was carried out.
      Similarly... "The failure to maintain proper NDP behavior whilst under attack has been observed across multiple platforms and implementations, including the largest modern router platforms available (at the inception of work on this document)."
      ... would benefit from a reference.
      Section 6: s/stipulated/suggested/ or s/stipulated/stated/
      Section 7 might benefit from more detail on the management interfaces that operators would like to see provided by vendors both for the control of the optional mechanisms discussed in this document and for the notification about and analysis of attacks.
      It might have been nice to add a note about the interaction with mobility (such as of VMs in a data center).
    3. Peter Saint-Andre: Comment [2012-02-28]:
      This document sure feels like a standards-track Applicability Statement to me. Did the WG consider requesting a status of Proposed Standard?
      Please consider citing RFC 4732 at the first use of the term Denial of Service.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. The Atom "deleted-entry" Element (Informational)
    draft-snell-atompub-tombstones-14
    Token: Peter Saint-Andre
    Discusses/comments (from ballot draft-snell-atompub-tombstones):
    1. Adrian Farrel: Comment [2012-02-27]:
      I have no objection to the publicaiton of this document. I think that the Introduction could have been more extensive - a good place for citations and explanations.
    2. Stephen Farrell: Comment [2012-02-24]:
      1. I didn't really get what's meant by
      "When an at:deleted-entry element appears in a Feed document other than it's source Feed or when an at:deleted-entry element that has a source Feed document is used in the context of a Deleted Entry Document, it MUST contain an atom:source element."
      But I guess Atom developers probably do so that's ok.
      2. Last para of section 6: I guess that if someone did MAC and then symmetrically encrypt one of these (is that as unlikely as I think?) then it might be useful to tell them not to use the same key for both.
      3. Digital signatures by themselves do not provide non-repudiation. Please delete that term.
    3. Robert Sparks: Discuss [2012-02-29]:
      This is a solid document. Before moving to Yes, I would like to ask if publishing it as Proposed Standard rather than Informational was considered? I don't object to publishing it as Informational, but suggest that Proposed Standard is a better track for it.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1254 EST break

1300 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. End-to-end Session Identifier in SIP (sessionid)
    Token: Gonzalo

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. Locator/ID Separation Protocol (lisp)
    Token: Jari

    Telechat:

  2. Hypertext Transfer Protocol Bis (httpbis)
    Token: Peter

    Telechat:

5. IAB News We can use

6. Management Issues

  1. Designated Port Experts

    Telechat:

7. Agenda Working Group News

1425 EST Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-03-01 04:25:43 PST)

draft-ietf-rmt-flute-revised

  1. Ronald Bonica: Comment [2012-02-29]:
    Also concerned about the IPR situation, but Stephen holds the DISCUSS
  2. Ralph E. Droms: Comment [2012-02-29]:
    I have one very minor editorial comment.  The document uses "packet"
    
    throughout, sometimes without qualification and sometimes with
    
    qualification; e.g., "ALC/LCT packet."  For the most part, the type of
    
    packet can be deduced from the context.  However, in section 3.3, it
    
    wasn't clear to me if "packet" referred to ALC, transport or IP
    
    packet: 
    
    
    
       If an FDT Instance is longer than one packet
    
       payload in length, it is RECOMMENDED that an FEC code that provides
    
       protection against loss be used for delivering this FDT Instance.
    
    
    
    There may be one or two other instances of "packet," e.g., in section
    
    7, discussing "per-packet" security, that are similarly unclear.
    
     
    
    This use of "packet" seemed a little confusing (although the meaning
    
    is probably clear):
    
    
    
       FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
    
       is IP version specific.
  3. Adrian Farrel: Comment [2012-02-29]:
    I have no objection to the publication of this document.
    
    
    
    Thank you for the substantial description of the changes since RFC 3926
    
    which made review considerably easier. I think you might find the need
    
    to consolidate the description of the changes which is currently
    
    incrementl such tat when more than one change was made to a section
    
    over time, it appears in the log more than once. This means that it is
    
    currently necessary to read the whole log before understanding what has
    
    changed.
    
    
    
    ---
    
    
    
    Seciton 9 ends a little suddenly :-)
  4. Stephen Farrell: Discuss [2012-02-29]:
    
    #1 The IPR situation here appears complex. This obsoletes the
    
    experimental 3296 which has no IPR declarations. A common author
    
    for this and 3926 is an inventor of IPR declared in 2006 on this
    
    document.  Could I get a pointer to where the WG was informed of
    
    and/or considered this?  (Had a quick look, didn't find it.) Is it
    
    (still) the case that 3926 is not considered to require an IPR
    
    declaration but this document does?  Reading section 11, I don't
    
    see much change here so as a result, I'm unclear as to whether the
    
    meta-data for these documents is consistent and considered so by
    
    the WG.
    
    
    
    So this may be more of a tools issue perhaps - if the new declaration
    
    supercedes the old then maybe the tools page for the RFC forgets the
    
    old IPR declaration or something. I'll keep the discuss so's we can 
    
    figure that out.
    
    
    
      http://datatracker.ietf.org/ipr/731/ is a declaration on RFC 3926 as
    
      it turns out.
    
    
    
    #2 p20 - why Content-MD5? What's that used for? Is there alg
    
    agility? If not, why not (in a standard). If this isn't really
    
    needed or useful then why not just deprecate it for the PS version
    
    of FLUTE or replace it with something else? Section 7 is quite good
    
    btw, but if you do keep Content-MD5 then don't you need to consider
    
    a bad (or spoofed) sender that sends different folks different
    
    (chunks of) files that are MD5 collisions?
    
    
    
    #3 7.5 calls for IPsec in transport mode as the main security
    
    measure and also automated key management which basically means IKE
    
    - am I reading that right? Does that actually match the use-cases
    
    for FLUTE?  Where's the unidirectional aspect gone?  If this
    
    doesn't match any reasonable FLUTE use-case then don't we end up
    
    with no security in practice? I'm not sure what, if any, change
    
    might be needed, but I'd first like to understand the reality.
    
    
  5. Stephen Farrell: Comment [2012-02-27]:
    - What was the experiment for 3926 that has now concluded
    
    indicating that this document should be on the standards track?
    
    I'd like to have known. (A reference to something or short
    
    paragraph would have been fine.)
    
    
    
    - The introductory material isn't very clear to this reader.  I'd
    
    suggest adding text like the intro from [1] and/or adding
    
    references to that or similar papers that introduce the protocol.
    
    ([1] was just the first thing that I found that seemed to have
    
    that, I'm sure there are many others, and maybe better ones, but
    
    its intro helped me.)
    
    
    
       [1]
    
    http://mad.cs.tut.fi/doc/Analysis_of_the_FLUTE_Data_Carousel_presentation.pdf
    
    
    
    - 1.1.3 - "works with all types of networks" - academic training
    
    tells me to always question all absolute statements like that all
    
    the time:-) Is it really true? How do you know? Would acoustic
    
    underwater networks or 6lowpans be counterexamples?  (Section 3.4
    
    implies a requirement for UDP as well.) I think you need references
    
    or an argument, or (most likely) to weaken the claim, e.g. via
    
    s/all/many/
    
    
    
    - p10 - is it clear (enough) what's meant by a temporary IP
    
    address? Not a big deal but not sure its the right term.
    
    
    
    - p15: I don't get what this means really: "If the receiver does
    
    not understand the FEC Encoding ID in a FDT Instance, the receiver
    
    MUST NOT decode the associated FDT." It sounds like decoding and
    
    not decoding all at once.
    
    
    
    - s3.3: I've not parsed this out fully but the 2119 lanaguage here
    
    seems a tad loose - if this section were to avoid 2119 language and
    
    just be an intro, would that be better? (That might be a lot of
    
    work though, so just consider this a suggestion.)
    
    
    
    - why is this the case in 3.4.1? "Sender behavior when all the FDT
    
    Instance IDs are used by non expired FEC Instances is outside the
    
    scope of this specification and left to individual implementations
    
    of FLUTE." Seems like that'd create interop problems - why not?
    
    Similarly, the receiver behaviour being out of scope also seems
    
    wrong.
    
    
    
    - 7.3.4 RECOMMENDS that receivers identify themselves in case they
    
    mess up congestion control. Is that reasonable? It doesn't seem so
    
    since this doesn't define how to do that.  I'd say weaken that and
    
    say that if receivers are known then you might be able to catch
    
    them messing up the CC scheme.
    
    
    
    - Is section 11 intended to remain in the RFC?
  6. Dan Romascanu: Comment [2012-02-27]:
    Is there any companion document that explains the operational model and the
    
    manageability aspects related to the deployment of this protocol? If such a
    
    document exists it would be worth at least to include a reference to it in this
    
    document, in the absence of a operational and manageability considerations
    
    section.
  7. Peter Saint-Andre: Discuss [2012-02-29]:
    
    Other reviewers have expressed many of the concerns I had. Here are a few
    
    additional topics I'd like to chat about.
    
    
    
    1. Apparently the application/fdt+xml media type was not reviewed on the ietf-
    
    types list, per RFC 4288. At least I see no request for a review in the archives
    
    at http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html
    
    
    
    2. The IANA Considerations section is missing a registration of the
    
    "urn:ietf:params:xml:ns:fdt" namespace.
    
    
  8. Peter Saint-Andre: Comment [2012-02-29]:
    1. Why does the "Expires" attribute have a datatype of "xs:string"? Given that
    
    it is the UTF-8 decimal representation of a 32 bit unsigned integer,
    
    "xs:unsignedInt" might be more appropriate.
    
    
    
    2. Did you consider assigning a default value for the "Complete" attribute?
    
    Presumably it defaults to FALSE, but it would be good to make that clear. (You
    
    might also consider mentioning that there are two lexical representations for
    
    boolean in W3C XML Schema, '1' or 'true' for TRUE and '0' or 'false' for FALSE.)
    
    
    
    3. The terms "MIME field name" and "MIME field body" are never defined. Perhaps
    
    a reference to RFC 2045 is in order?
    
    
    
    4. Please change "MIME type" and "MIME media type" to "media type".
    
    
    
    5. In Section 3.5, you have "due to unexpected network conditions, packets for
    
    the FDT Instances MAY be interleaved" -- I think you mean "might", not "MAY".
    
    
    
    6. The lack of a mandatory-to-implement integrity protection mechanism in
    
    Section 7.2.2 might harm interoperability. The same is true of Section 7.3.3 and
    
    Section 7.3.4. It is not completely clear to me whether Section 7.5 fills that
    
    gap.
    
    
    
    7. Citing RFC 3470 might be appropriate in the security considerations.
  9. Robert Sparks: Discuss [2012-02-28]:
    
    In 3.4.2, Content-Location MUST be assigned a valid URI. What does "valid" mean
    
    in this context. Does it mean anything more than well-formed? In particular, if
    
    the URI is in a scheme that has GET semantics, does "valid" mean you can get the
    
    document that way? What does an implementation do if it sees a scheme it doesn't
    
    understand? (URI comparison is scheme-specific - it would be dangerous to an
    
    implementation to assume two URIs meant different things if it doesn't
    
    understand the scheme). If all you need is a unique identifier, what's the
    
    advantage of allowing arbitrary schemes to provide it?
    
    
    
    In the discussion of handling time wraparound, "can determine" seems
    
    problematic. How do you have interoperability unless both the receiver and the
    
    sender interpret this the same way?
    
    
    
    The XML Schema registration (section 8.1) should provide a URI.
    
    
    
    The document needs clearer discussion around the reuse of FDT Instance IDs. I
    
    hope I've misunderstood a fundamental idea and a simple clarification will
    
    address the following questions.
    
    
    
    * Is the intent that IDs increment by one again after wraparound? Or once
    
    wraparound happens, do you always select the next ID using "the smallest FDT
    
    Instance value" (you mean ID value, yes?) "assigned to an expired FDT Instance".
    
    If the later, then both the receiver and the sender will have to keep an
    
    explicit ordering based on when reassignments were received - in the extreme it
    
    would be possible to construct a degenerate case where the ordering ended up
    
    completely reversed (...,5,4,3,2,1) by using a set of decreasing expiration
    
    times as the ID space is traversed the first time. I realize a sender wouldn't
    
    really do that, but it's enough that it only have a couple of elements in the
    
    sequence that aren't in increasing order. That should be made clearer,
    
    particularly where you talk about the ordering being used (such as when
    
    describing the semantics for any two "File" elements declaring the same
    
    "Content-Location" but differing "TOI"). It would also help to summarize where
    
    the ordering is actually used by the protocol.
    
    
    
    * How would a receiver that joined after the sender started reusing IDs know
    
    that had happened? If it can't, the consequence is that all receivers have to
    
    keep track of what order they received FDTs in from whenever they join.
    
    
    
    * Since it's possible for a receiver to miss FDT instances, once wraparound
    
    starts it looks like its possible for two different receivers to have a
    
    different idea of what's "newer". Does that break anything?
    
    
    
    * Currently, receipt of an instance that reuses the id from a non-expired
    
    instance SHOULD be considered an error. When would the reciever _NOT_ consider
    
    this an error? Why is the document leaving receiver behavior out of scope? This
    
    seems to invite interoperability failure in deployed systems.
    
    
  10. Robert Sparks: Comment [2012-02-28]:
    The last paragraph of 3.4.2 says it is RECOMMENDED that new attributes are
    
    defined in 2616 or a well-known specification. RECOMMENDED is a synonym for
    
    SHOULD. It would help to describe why this isn't REQUIRED in the document.
    
    
    
    In the last paragraph of section 3.3 (which talks about using out-of-band
    
    mechanisms for communicating attributes associated with files), consider
    
    reinforcing that using such an out-of-band mechanism does not make sending FDT
    
    instances in the session optional.
    
    
    
    The section on Intended Environments claims FLUTE is applicable for non-Internet
    
    systems, providing an example, but no support for the claim. Consider editing
    
    this to say something less subjective, like "FLUTE has also been adapted for use
    
    in other network architectures, such as..." and if possible, provide a
    
    reference.
    
    
    
    The document never explicitly says when the application/fdt+xml media type gets
    
    used.
    
    
    
    I'm a little surprised there's not a registry around that already assigns
    
    codepoints to encoding (particularly compressing encoiding) algorithms. The
    
    closest I could find is <http://www.iana.org/assignments/http-parameters/http-
    
    parameters.xml> which doesn't establish codepoints. Please consider reconciling
    
    with that registry.
    
    
    
    NIT: Section 3.1 has a list of rules. Several of the bullets in the list are not
    
    actually rules. Consider moving those to an introductory paragraph before the
    
    actual rules.

draft-ietf-netext-pmip-lr

  1. Ralph E. Droms: Discuss [2012-02-29]:
    
    1. I think there is some confusion about the "R" flag.  The caption
    
    for Figure 2 (and other Figures) includes:
    
    
    
       where R and U are the flags defined in Section 9.1 and 9.2.
    
    
    
    but I don't see any definition of an "R" flag in section 9.1.  In my
    
    opinion, the "R" flag is unneeded if the LRI and LRA messages each
    
    have a separate header type code.
    
    
    
    2. I don't see any text that describes how an LMA cancels local
    
    forwarding service, as implied in this text in section 4:
    
    
    
       For instance, the LMA may
    
       send a LRI message with a request to cancel an existing local
    
       forwarding service.
    
    
    
    3. In section 5, what happens if, for some reason, one of the MAGs
    
    (e.g., MAG1) responds with a non-zero status code in its LRA to the LMA?
    
    Does MAG2 need to be notified, perhaps because it has some state that
    
    must be taken down?  This text should be extended to allow for error
    
    cases:
    
    
    
       When the
    
       MAG IP Address option is present, each MAG MUST create a local
    
       forwarding entry such that the packets for the MN attached to the
    
       remote MAG are sent over a tunnel associated with that remote MAG.
    
    
    
    The only mention of error cases in section 5 seems to be:
    
    
    
       Barring the error cases, all subsequent packets are routed between
    
       the MAGs locally, without traversing the LMA.
    
    
    
    4. In section 5:
    
    
    
       It will hence initiate LR at nMAG1 and update the LR state
    
       of MAG2 to use nMAG1 instead of MAG1.
    
    
    
    how does the LMA perform the state update and doesn't it also have to
    
    update some state in MAG1?
    
    
    
    5. The text in section 6.1 is completely lacking any description of
    
    what the various participants should do in the case where an MN moves
    
    to a new MAG.
    
    
    
    6. I'm not sure section 7 gives enough detail into the various ways in
    
    which an established LR situation must be torn down.  For example, in
    
    the A11 case, does the LMA or the MAG determine that one of the MNs
    
    has moved and the participants are now in A22?
    
    
    
    7. In section 9, I can't find definitions for LRA_WAIT_TIME and
    
    LRI_RETRIES.
    
    
  2. Ralph E. Droms: Comment [2012-02-29]:
    1. In section 4, what does it mean for a MAG to "statically initiate
    
    LR"?
    
    
    
    2. Also in section 4, does:
    
    
    
       It then verifies if the
    
       EnableMAGLocalRouting flag is set to 1.
    
    
    
    refer to the EnableMAGLocalRouting flag for MAG?
    
    
    
    3. Editorial nit: because there is only one MAG in the scenario in
    
    section 4, the identifier MAG1 is probably unnecessary in Figure 2
    
    and the related text.
    
    
    
    4. In section 4.1, does "LR state of the MAG" refer to the state in the
    
    LMA?  Also, is pMAG == MAG?
    
    
    
    5. This text from section 6 seems awkward and the RFC 2119 language
    
    seems unnecessary:
    
    
    
       Only after it receives both
    
       the LRA messages each with Status value set to zero (success) from
    
       the two different LMAs, the MAG MUST conclude that it can provide
    
       local forwarding support for the two Mobile Nodes.
    
    
    
    6. In section 10.1, "for now" is unnecessary.  Why is the alignment
    
    requirement mentioned here and not for the definitions in section 9,
    
    and what does "8n+4" mean?
  3. Adrian Farrel: Discuss [2012-02-29]:
    
    Updated Discuss and Comment to make it clearer which points I want
    
    to see addressed, and which are just "desirable".
    
    
    
    The issues come from the Routing Directorate review by Les Ginsberg 
    
    on 2/27/12.
    
    
    
    You can engage with Les direct at ginsberg@cisco.com for clarification, 
    
    but the Discuss issues are mine.
    
    
    
    - - - - -
    
    
    
    Why are you not using the "MN-CN" terminology from RFC 6279? The fact
    
    that you use "MN-MN" makes me think that you are only addressing cases
    
    where both endpoints are MNs. Is this the case? If so, this should be
    
    explicitly stated. If not, it would seem to be better to use the RFC
    
    6279 terminology.
    
    
    
    ---
    
    
    
    Section 5
    
    
    
    I assume the lack of requirement for synchronization works because the
    
    LMA will always forward packets regardless of whether it has sent an
    
    LRI/received an LRA? This implies that MNs and MAGs may receive
    
    duplicate packets at times - which presumably should be no problem. I am
    
    wondering if it would be useful to discuss these points?
    
    
    
    Similarly, in Section 6.1 it is assumed that LMAs always forward
    
    inter-MN packets regardless of the state of LR?
    
    
  4. Adrian Farrel: Comment [2012-02-29]:
    Nits:
    
    A number of acronyms are used without definition. For example, in
    
    Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not
    
    represent a complete list. Can you please scrub the document for all
    
    such occurences?
  5. Stephen Farrell: Comment [2012-02-29]:
    - LR with two MAGs implies that MAG1 knows that MAG2 is the CN's 
    
    location at the granularity of the MAG (MAG2) with which the CN
    
    is associated.. Since there is a way for a MAG to initiate this 
    
    then a bad or compromised MAG could attempt to track any CN 
    
    for which LR is enabled who's address the bad MAG knows. That 
    
    is a privacy problem for the CN's. I noted this about the DIME WG 
    
    equivalent draft and the authors of tha suggested that text as per 
    
    the above would be better in this document. I'm not sure there's
    
    a mitigation here really but I'd say its worth noting at least.
    
    
    
    - Figures 1 and 2 have no real caption and aren't referred to
    
    from the text so are less useful than they could be.
  6. Russ Housley: Discuss [2012-02-27]:
    
    The Gen-ART Review by Mary Barnes on 24-Feb-2012 includes many issues,
    
      and the authors have agreed to make fixes.  The revised document has
    
      not been posted yet.
    
    

draft-ietf-manet-packetbb-sec

  1. Stewart Bryant: Comment [2012-02-28]:
    minor nit - TLVs is plural of "Type-Length-Value" not "Type-Length-Value
    
    structure" and expansion is NOT REQUIRED
    
    
    
    It's a bit confusing putting a mini-IANA section in the Intro.
    
    
    
    Section 13 after "This specification requests" a number of the terms defined are
    
    not used in the document.
  2. Stephen Farrell: Discuss [2012-02-28]:
    
    I have a number of discuss points here. Maybe some of this is just
    
    that I don't have the right context but I find it hard to see how
    
    this is really baked as-is. I guess I'm wondering if it would perhaps
    
    be better to wait until someone actually does an implementation? (The
    
    write-up says there are none known.)
    
    
    
    #1 I don't understand why this does not define any actual algorithms.
    
    Is there another document going to do that? If not, then what's the
    
    point of this being on the standards track with no algorithms and no
    
    automated key management? I don't see any MANET WG documents that
    
    will obviously provide those nor any relevant milestones. (Mind you,
    
    all the milestones are dated 2007;-)
    
    
    
    #2 Does this allow or preclude MACs such as HMAC-SHA1?  If the former
    
    then you need to change terminology as those are not signatures. (I'd
    
    suggest integrity check value instead.) If the latter, then why do
    
    you want to prevent that? While I don't care too much about the
    
    specific terminology, (others do though), you definitely need to be
    
    clear if you really mean only digital signatures or not. 
    
    
    
    #3 I don't understand why an 8-bit key index is sufficient for a
    
    large network. (And key index is not really a good term, I think key
    
    identifier would be much better.) With key rollovers and some form of
    
    key derivation for different directions (to prevent reflection
    
    attacks) and maybe two different key usages for different kinds of
    
    message or something like that, that would mean only
    
    supporting 32 unique keys values for a given purpose in the 
    
    entire network which just seems too small. I'd suggest changing 
    
    that to a key identifier length-value field or at least providing some 
    
    way to identify key number 257 and beyond.
    
    
    
    #4 Are "badly formed" and "insecure" assumed to be the same?  (Section 
    
    4 implies they are.) If so, that would seem to preclude any MANET 
    
    routing scheme where a node might forward cryptographic fields but 
    
    not act upon a routing message that it understands but cannot verify. 
    
    Was that considered by the WG and was it rejected?  Rejecting that 
    
    seems to imply that all nodes need to be kept up to date with all 
    
    keying material all the time which seems brittle and would also seem 
    
    to make it very hard to introduce a new algorithm except as a flag-day 
    
    or by having all nodes add fields for all algorithms.  (Which in turn 
    
    implies MANETs will remain tiny so that this will be practical or
    
    that large MANETs won't be able to use security.)
    
    
    
    #5 I don't understand why you don't define at least one timestamp
    
    precisely.  Why would you want 250 varieties of timestamp anyway?
    
    
    
    #6 Having separate hash and cryptographic function registries might
    
    not be the best plan since not all combinations will make sense.  Is
    
    that really a good idea? Why not make use of some other registries
    
    that already exist? (That is, is there a particular reason why you
    
    need new registries or have you looked but not found one that'd
    
    work?)
    
    
  3. Stephen Farrell: Comment [2012-02-28]:
    - Title seems misleading reading the abstract. Suggest adding mention
    
    of timestamps in title and fixing signature term as per discuss point 1.
    
    
    
    - Using the term "unsigned timestamp" in 13.2 seems like a bad choice
    
    given that a you're using signature all over the place.  I'd suggest
    
    qualifying that.
  4. Peter Saint-Andre: Comment [2012-02-28]:
    I concur with Stephen Farrell's thorough analysis.
  5. Robert Sparks: Discuss [2012-02-28]:
    
    Section 10.2 says "If both a TIMESTAMP TLV and a SIGNATURE TLV are associated
    
    with an address, the TIMESTAMP TLV <value> SHOULD be considered when calculating
    
    the value of the signature".
    
    
    
    "be considered" is vague - can it be made more precise? Is this trying to say
    
    the signature should cover the timestamp?
    
    If so, how is this interoperable as a
    
    SHOULD instead of a MUST?
    
    

draft-ietf-pcp-base

  1. Wesley Eddy: Discuss [2012-02-28]:
    
    (1) In Section 13.1.3, when discussing responses to unsolicited multicasted
    
    ANNOUNCE messages, there seems to be potential for a large number of packets to
    
    be generated all at once.  There should be some guidance here about whether the
    
    responses need to be dithered or paced in some way.  This was raised as part of
    
    Pasi Sarolahti's TSVDIR review.
    
    
    
    (2) It seems that there isn't a good way to unambiguously match a response up
    
    to the request that generated it; especially when there have been (perhaps
    
    multiple) retransmissions.  Is this really the case?  If so, it seems that it
    
    should either be remedied or the impact needs to be discussed.
    
    
    
    (3) In Section 7.1, note that the guideline from RFC 5405 for retransmission is
    
    one datagram per RTT or in absence of an RTT measurement, one datagram every 3
    
    seconds.   The 2-3 seconds in section 7.1 is slightly more aggressive than this.
    
    I think timers on the order of seconds may be horribly long though compared to
    
    the expected RTT between the client and server.  Would it be possible to cache
    
    an RTT if it could be measured during some request-response pair, and use that
    
    rather than the 2-3 second rule?  (note this would require unambiguous relation
    
    of responses to requests, as in the prior DISCUSS point).
    
    
  2. Adrian Farrel: Comment [2012-02-27]:
    Note to responsible AD. This document requests the creation of
    
    regsistries that use the "specification required" allocation policy.
    
    That means you will need designated experts.
    
    
    
    ---
    
    
    
    Please consider addressing the minor points and questions raised by
    
    Loa Anderson in his Routing Directorate review especially the question
    
    about Section 15.
    
    
    
    Additionally, I have some comments as follows. There are quite a few
    
    and some of them are relatively significant. None of them merits a 
    
    Discuss, but I do hope you will take them seriously.            
    
    
    
    ---
    
    
    
    Section 6.3
    
    
    
       It is the
    
       responsibility of the PCP client to ensure the server has sufficient
    
       room to reply without exceeding the 1024-byte size limit.
    
    
    
    This is the first mention of the "1024-byte size limit" (I think you 
    
    mean the 1024=byte message size limit") and it would be helpful to 
    
    explain why that limit applies.
    
    
    
    ---
    
    
    
    Section 7
    
    
    
       Every PCP request    
    
       generates at least one response, so PCP does not need to run over a
    
       reliable transport protocol.
    
    
    
    Now, I can see how this would be made to work by a protocol spec that
    
    implements a timer waiting for a response and a retransmission (as 
    
    described in Section 7.1), and a "more responses to follow mechanism"
    
    (as possibly hinted at in Section 7.3), but your statement is too bold
    
    as it stands. Perhaps you could rewrite as:
    
    
    
       Every PCP request generates at least one response, amd PCP is 
    
       responsible for retrying requests and correlating responses, so PCP
    
       does not need to run over a reliable transport protocol.
    
    
    
    It would also be good (maybe in 7.3) to clarify the processing when 
    
    there are multiple responses to a request. How does the client actually
    
    know that it has received all of the responses?
    
    
    
    ---
    
       
    
    Section 7.1
    
    
    
       Prior to sending its first PCP message, the PCP client determines
    
       which server to use.  The PCP client performs the following steps to
    
       determine its PCP server:
    
    
    
       1.  if a PCP server is configured (e.g., in a configuration file or
    
           via DHCP), that single configuration source is used as the list
    
           of PCP Server(s), else;
    
    
    
       2.  the default router list (for IPv4 and IPv6) is used as the list
    
           of PCP Server(s).
    
    
    
       For the purposes of this document, only a single PCP server address
    
       is supported.  Should future specifications define configuration
    
       methods that provide a list of PCP server addresses, those             
    
       specifications will define how clients select one or more addresses          
    
       from that list.
    
    
    
    It seems to me that the second option listed here is exactly a case of
    
    a configuration method where there is a list of PCP server addresses.
    
    So don't you need to define the method of selection (probably, first in
    
    the list is selected)?
    
    
    
    Furthermore, a couple of paragraphs later you have:
    
    
    
       When attempting to contact a PCP server, the PCP client sends a PCP
    
       message to the first server in its list of PCP servers, 
    
    
    
    which seems to be exactly the specification of how to select a server
    
    from a list.
    
    
    
    ---
    
    
    
    Section 7.1
    
    
    
       As with all UDP or TCP client
    
       software on any operating system, when several independent PCP
    
       clients exist on the same host, each uses a distinct source port
    
       number to disambiguate their requests and replies.  The PCP client's
    
       source port SHOULD be randomly generated [RFC6056].
    
    
    
    I suggest you don't need/want to mention TCP here. While what you say is
    
    true, it is not relevant to this spec.
    
                                                                   
    
    ---
    
    
    
    Unless I missed it, you have not described the fact that a client can
    
    receive an apparently unsolicited response from a server. This could
    
    happen after client restart.
    
    
    
    ---
    
    
    
    Section 10.1
    
    
    
    There is some fluff in the terminology where (e.g.) the figure is
    
    described as showing the packet format where it actually shows the
    
    opcode-specific data.
    
    
    
    Same issue in Section 11.1 and Sections 12.1, 12.2 etc.
    
    
    
    ---
    
    
    
    Sections 17.2, 17.3, and 17.4
    
    
    
    It seems entirely perverse to me to have just one code point available
    
    in each registry (and three in one of the registries) for future 
    
    Standards Action, but many for specification required and private use.
  3. Russ Housley: Discuss [2012-02-27]:
    
    The Gen-ART Review by Richard Barnes on 27-Feb-2012 raised a few
    
      concerns.  Please respond to at least these concerns:
    
      
    
      (1) Several people, including Richard, think that implementation would
    
      be simplified if a transaction identifier were used.  An identifier
    
      can simplify response processing, clarify the meaning of lifetime
    
      parameters, and provide some protection against address spoofing.
    
    
    
      (2) Add explanation of consequences from spoofed packets. (Or better,
    
      make it easier to detect and discard them.)  An off-path attacker
    
      might be able to break synchronization in state between clients and
    
      servers, for example, by sending gratuitous responses.  Richard offers
    
      this example flow as a way for an off-path attacker to steal traffic:
    
      >
    
      > 1. Attacker obtains mapping from address:port=A:P on PCP controlled
    
      >    device to one of its ports B:Q
    
      > 2. Attacker convinces client that it has a mapping from A:P to its
    
      >    port C:R
    
      > 3. Attacker acts as a man in the middle: remote -> A:P -> B:Q -> C:R
    
    
    
      (3) It seems the ANNOUNCE method provides an opportunity for an
    
      attacker capable of spoofing to cause an arbitrary number clients to
    
      flood the server with requests.  Please add explanation of
    
      consequences if an attacker mounts this attack.  (Or better, make it
    
      more difficult for an attacker to do so.)
    
    
  4. Russ Housley: Comment [2012-02-27]:
    The Gen-ART Review by Richard Barnes on 27-Feb-2012 raised a few
    
      concerns.  Please consider these points:
    
      
    
      (a) The document says that v4-mapped addresses are not used as source
    
      or destination addresses for real IPv6 packets.  Richard is aware of
    
      some work on IPv6 traceroute scanning where numerous routers will
    
      respond from v4-mapped addresses.  It probably would be accurate to
    
      say that these addresses would never appear in a mapping.
    
    
    
      (b) In Section 6.4, the first paragraph says that each error is "long"
    
      or "short", but they're not all marked.  Is there a default?  It also
    
      seems like some of these errors are effectively permanent, such as
    
      UNSUPP_VERSION; the PCP NAT isn't going to support a new version of
    
      the protocol half an hour from now.
    
    
    
      (c) In Section 7.1, you first say that "only a single PCP server
    
      address is supported", but then in a couple of other places mention
    
      a "list of PCP servers".  Which is it?
    
    
    
      (d) In Section 7.1, it seems like it would be pretty unusual for the
    
      PCP server to be the first-hop router, at least outside of the CPE
    
      case.  Would it be better to use an anycast address to find the server?
    
    
    
      (e) I did not find that the code samples in Section 9 added any
    
      information.  The one case where one would have been helpful (9.4),
    
      there was none.
  5. Pete Resnick: Discuss [2012-02-27]:
    
    [Note: I'm on vacation this week and therefore my RTT will be exceedingly long.
    
    I've only just gotten through the beginning of section 7 and already I have a
    
    slew of comments. Some of the ones in the COMMENT section might move up to
    
    DISCUSS, but I haven't had time to sort through all of it yet. The two that are
    
    currently labeled DISCUSS are definitely in that category. Either way, I asked
    
    Jari and he said to send you what I've got so far. More to come soon.]
    
    
    
    Section 6.3:
    
    
    
       The handling of an Option by the PCP client and PCP server MUST be
    
       specified in an appropriate document, which MUST state whether the
    
       PCP Option can appear in a request and/or response, whether it can
    
       appear more than once, and indicate what sort of Option data it
    
       conveys.
    
    
    
    This does not belong here. This sounds like an IANA Consideration, that you are
    
    requiring a document for registration, and you are specifying what goes in that
    
    document. If so, then put this (without the MUST) into the IANA Considerations
    
    section with appropriate language. Otherwise, I don't understand what protocol
    
    force this documentation requirement has.
    
    
    
       Option definitions MUST include the information below:
    
    
    
    Again, that looks like IANA considerations.
    
    
    
    Section 7:
    
    
    
       PCP is idempotent
    
    
    
    That's a fine thing, but I believe there's a missing bit of functionality in
    
    this protocol to pull it off: Let's say I send a request that results in an
    
    error condition, and the error response is sent back but it is delayed. I'm an
    
    aggressive client, so I send another request. That one succeeds. Now I get back
    
    the error response. Or I get the success response first, and then finally the
    
    error response comes back. How do I know which request succeeded and which one
    
    failed? Do I have to check the Epoch Time to put them in order and assume that
    
    none of the responses were lost? A serial or sequence number in the request that
    
    is turned around in the response would solve this problem. Am I missing
    
    something?
    
    
  6. Pete Resnick: Comment [2012-02-29]:
    I find all of the references to the "interworking function" from UPnP to be
    
    inappropriate in this document and should be removed. This is specific
    
    implementation advice for a specific environment, not protocol and not required
    
    for interoperability. I think it weakens the protocol specification and could
    
    have bad effects down the road. (Cf. IMAP, where specific accomodation of
    
    implmentation semantics led to all sorts of interoperability failures.) I think
    
    having a separate document with specifics of how to do PCP for UPnP is fine, but
    
    it shouldn't be in this document.
    
    
    
    The notion of "subscriber" is unnecessary for this protocol and should be
    
    removed. It is sufficient to talk about per-host limits and quotas to explain
    
    the concepts that are there and then the document will not have to talk about
    
    the mapping of a business model onto the protocol.
    
    
    
    All of the forward references in this document make it somewhat confusing, and I
    
    suspect longer than it needs to be. I don't see why sections 10-12 can't be
    
    moved earlier in the document.
    
    
    
    Section 3:
    
    
    
    PCP Client definition. I don't find the parenthetical bit about several web
    
    browsers useful; readers will confuse multiple instances of the same browser
    
    with multiple browsers and the message will be muddied. Not only that, anyone
    
    who will be coding this is well aware that multiple applications can run on a
    
    single host. I found myself wondering what the note was trying to get at. I also
    
    found the reference to UPnP not terribly helpful. I would strike it and simplify
    
    this description.
    
    
    
    PCP Server definition is circular. Better would be: "A PCP software instance
    
    that resides on the NAT or Firewall that receives PCP requests from the PCP
    
    Client and sets up the appropriate state in response to that request."
    
    
    
          *  Explicit dynamic mappings are created as a result of explicit
    
             PCP MAP and PEER requests.
    
    
    
    MAP and PEER are not defined yet. You could define the actions of mapping and
    
    peering and then use the verbs instead of the OPCODEs here.
    
    
    
    Section 6.1:
    
    
    
       Version:  This document specifies protocol version 1.  This value
    
          MUST be 1 when sending, and MUST be 1 when receiving.
    
    
    
    I'll begrudingly allow that it "MUST be 1 when sending", but I find this to be a
    
    silly use of 2119 anyway; it MUST be 1 iff you are implementing this version of
    
    the protocol, which seems stupidily redundant. I think such language also
    
    encourages receivers to do stupid things if the version is not 1. ("Well, the
    
    protocol says that it MUST be 1, so I don't have to do any error checking.") So,
    
    I would drop that bit. But it is simply not true that it "MUST be 1 when
    
    receiving." It very well might not be, which is why there's an error code for
    
    wrong version.
    
    
    
       Requested Lifetime:  An unsigned 32-bit integer, in seconds, ranging
    
          from 0 to 2^32-1 seconds.  This is used by the MAP and PEER
    
          Opcodes defined in this document for their requested lifetime.
    
          Future Opcodes which don't need this field MUST set the field to
    
          zero on transmission and ignored on reception.
    
    
    
    So, it seems to me (given the last sentence) that this should have been opcode
    
    specific and appeared in that part of the header. I assume that ship has sailed.
    
    But I still don't understand the last sentence: Why should future opcodes be
    
    required to have that field filled with zero if it's not being used? If I use
    
    it, I fill it in with what I think it means. If it's not used, neither side will
    
    use it and the opcode will specify that. I don't see what use it is to make the
    
    admonishment here. (Same issue in 6.2.)
    
    
    
    And again, MAP and PEER are used before being defined. (I'll not mention this
    
    problem again, but MAP and PEER are mentioned several times before section 9
    
    rolls around.)
    
    
    
    Section 6.3:
    
    
    
       It is the
    
       responsibility of the PCP client to ensure the server has sufficient
    
       room to reply without exceeding the 1024-byte size limit.
    
    
    
    What 1024-byte size limit? This is the first mention in the document.
    
    
    
       An Option MAY appear more than once in a request or
    
       in a response, if permitted by the definition of the Option.  If the
    
       Option's definition allows the Option to appear only once but it
    
       appears more than once in a request, and the Option is understood by
    
       the PCP server, the PCP server MUST respond with the MALFORMED_OPTION
    
       result code; if this occurs in a response, the PCP client processes
    
       the first occurrence and MAY log an error.
    
    
    
    What's this error logging business? Is the server (for some interoperability
    
    reason) not allowed to log an error but the client is? This doesn't sound like
    
    protocol to me; sounds like implementation advice, and boring implementation
    
    advice at that. Strike the "and MAY log an error." A client doesn't need your
    
    permission to do so.
    
    
    
       PCP clients are free to ignore any or all Options included in
    
       responses, although naturally if a client explicitly requests an
    
       Option where correct execution of that Option requires processing the
    
       Option data in the response, that client is expected to implement
    
       code to do that.
    
    
    
    I cannot figure out what the above is trying to accomplish that is non-obvious.
    
    Is there some case where this makes some sort of interoperability difference?
    
    How could you tell if the client actually ignored it or processed it?
    
    
    
    Section 7:
    
    
    
       PCP messages MUST be sent over UDP [RFC0768].
    
    
    
    It seems to me that ICMP might be the correct choice instead of UDP, but I
    
    understand I may be blowing into the wind.
    
    
    
    Section 8:
    
    
    
       1.  If a client or server supports more than one version it SHOULD
    
           support a contiguous range of versions -- i.e., a lowest version
    
           and a highest version and all versions in between.
    
    
    
    Why is it useful (let alone an interoperability RECOMMENDation) to do that? I
    
    can see a stinker of a version potentially come out and the implementer decide
    
    that it's not worth implementing that version. What's the downside?
    
    
    
    Section 9:
    
    
    
       Some applications will break if mappings are created on different IP
    
       addresses, so applications should carefully consider the implications
    
       of using this capability.
    
    
    
    What applications are those? And what is the nature of that breakage? I don't
    
    understand what this sentence means.
    
    
    
       Static mappings for that Internal Address
    
       (e.g., those created by a command-line interface on the PCP server or
    
       PCP-controlled device) SHOULD also be assigned to the same External
    
       Address.
    
    
    
    Why? What breaks if they are assigned to different External addresses? (I'm also
    
    not sure why static mappings are discussed in this document at all; there is no
    
    protocol involved in static mappings.) Also, what happens if the client requests
    
    two different explicit mappings? What should the server do then?
    
    
    
    Section 10.2:
    
    
    
       If the client wants all protocols mapped it uses Protocol 0 (zero)
    
       and Internal Port 0 (zero).
    
    
    
    I don't understand how this will work. If I am a client that says "Protocol 0,
    
    Internal Port 0", haven't I just taken over the entire external address from the
    
    NAT, and therefore nobody else connected to that NAT can use PCP?
  7. Peter Saint-Andre: Comment [2012-02-29]:
    Other reviewers have provided significant input. I have a few additional
    
    comments.
    
    
    
    In Section 7.5, is the recommendation about 6.25% clock skew based on empirical
    
    evidence?
    
    
    
    In Section 8 (bullet 6), why would the client expect that the server might
    
    support its old version after 30 minutes?
  8. Robert Sparks: Discuss [2012-02-28]:
    
    1) Section 7 paragraph 2 asserts the protocol is idempotent, but then shows an
    
    example where it isn't.
    
    If you allow a retransmitted request to produce a
    
    different response, the protocol is not idempotent.
    
    Given that you allow this,
    
    not changing any bits in the request when you retransmit it allows the
    
    client
    
    and server to end up with different views of the request's success. Example:
    
    
    
    View in a fixed-width font:
    
    
    
       Client                   Server
    
         |          req            |
    
         |------------------------>|
    
         |        error response   |
    
         |     X<------------------|
    
         |       req               |
    
         |----------->X            |
    
         |          req            |
    
         |------------------------>|
    
         |        error response   |
    
         |               ----------||  Big delay in network between
    
         |   req       /           ||  client and server here
    
         |------------c--.         ||
    
         |           /    \        ||
    
         |<---------       `------>|
    
         |       success response  |
    
         |         X<--------------|
    
         |                         |
    
         |                         |
    
    
    
    Note that epoch time doesn't help with this, but might with the below variants:
    
    variant 1 - the success response actually delivers, after the client is no
    
    longer looking for a response
    
    variant 2 - the success response delivered first,
    
    followed by the delayed error response
    
    
    
    Adding a transaction identifier would only help if it was allowed to change with
    
    retransmission, and then the client would have to keep retransmitting until it
    
    got a response matching its most recent transmission before assuming it and the
    
    server were in agreement about the state at the server. Alternatively, you could
    
    require the server to actually be idempotent and never respond differently to
    
    the same request. (But you would need to put a finite limit on how long a client
    
    should retry before giving up on getting a response so that the server wouldn't
    
    have to remember the request and what response it sent forever).
    
    
    
    2) Having text written for having a list of servers, and other text that says
    
    "for this document, the list can only have one element in it" is very confusing,
    
    and will likely lead to implementation mistakes. Would it be too hard to rewrite
    
    the text to say "the server" instead of "the first server in its list", and add
    
    a section warning implementers to anticipate handling lists when the protocol is
    
    extended?
    
    
    
    3) I'm not seeing a discussion of the consequences of someone being able to
    
    spoof an unsolicited ANNOUNCE response - that seems like an attractive target
    
    for someone wanting to DoS a large scale server. Related - if you are operating
    
    a CGN-sized server, what keeps sending such an ANNOUNCE response from
    
    effectively resulting in an avalanche-restart style flood of traffic from all
    
    the clients using that server?
    
    
  9. Robert Sparks: Comment [2012-02-28]:
    The statement "Of course, this sort of behavior is common to all UDP-based
    
    protocols" just before section 7.1 is not true.

draft-ietf-l3vpn-mvpn-wildcards

  1. Stephen Farrell: Comment [2012-02-28]:
    I would have thought that the ability to mis-direct traffic would be
    
    enhanced with the addition of wildcards and that that might be worth
    
    a mention in the security considerations.  That is, while there may
    
    be no new threat, nor any new countermeasure needed, the potential
    
    impact of an existing threat would seem to be increased by this.

draft-ietf-dnsext-ecdsa

  1. Wesley Eddy: Comment [2012-02-14]:
    I support Russ and PSA's DISCUSS points
  2. Adrian Farrel: Comment [2012-02-14]:
    I presume that Section 6 needs to be updated as this document goes
    
    through the publication process. I think you should provide instructions
    
    to the RFC Editor on what should be done to this section.
    
    
    
    A way to do this would be to supply an RFC Editor note that fixes the
    
    section consistent with the actual IANA allocations, but will not show
    
    in the document until published as an RFC.
  3. Stephen Farrell: Comment [2012-02-13]:
    Section 4 says you MUST support signing "and/or" validation with
    
    both lengths. I think that is not quite clear enough as the
    
    requirement differs for different players in the DNSSEC game.
    
    Aside from basic clarity, which is the most important thing, there
    
    is also an IPR declaration here that distinguishes between things
    
    that are needed and things that are optional so I think expressing
    
    it in a way that makes clear that there are no
    
    optional-to-implement bits for anyone would be an improvement.
    
    I'd say that it'd be better to spell it out that implementations
    
    that create DNSSEC values to put into the DNS MUST implement
    
    signing and verification for both lengths, and that DNSSEC clients
    
    MUST implement verification for both lengths. (Or whatever is
    
    the right way to say thing.)
    
    
    
    Will the examples be re-done after IANA have allocated codes?  Be
    
    more than nice if that were to be the case.
    
    
    
    An informational pointer to RFC 6090 might be no harm here (and
    
    everywhere that uses ECC).
    
    
  4. Peter Saint-Andre: Comment [2012-02-28]:
    Thank you for addressing the issues raised by Bill Mills in his AppsDir review.

draft-ietf-manet-smf

  1. Stewart Bryant: Discuss [2012-02-29]:
    
    Please confirm that the issue raised by IANA on 28/Feb has been addressed.
    
    

draft-ietf-lisp-interworking

  1. Stewart Bryant: Comment [2012-02-29]:
    Default Free Zone (DFZ) should have a reference, if only a forward ref to
    
    section 2 when you first use it in section 1
    
    
    
    ====
    
    
    
    Asymmetry is a problem with certain types of application, NTP for example. It
    
    would be useful if there was some discussion on the relative degree of asymmetry
    
    imposed by these LISP solutions vs the degree of asymmetry in the existing
    
    Internet, and a note made about the impact of asymmetry on applications
  2. Adrian Farrel: Discuss [2012-02-29]:
    
    I only have a minor Discussion point (do I hear the authors sighing?)
    
    
    
    Section 4.2 says
    
    
    
       Non-LISP sites today use BGP to, among other things, enable ingress
    
       traffic engineering.  Relaxing this requirement is another primary
    
       design goal of LISP.
    
    
    
    I went back to look for the description of this design goal in the LISP
    
    spec and I couldn't find it. Might be my search was a bit random. Might
    
    be the design goal wasn't stated in the base spec and so shouldn't be 
    
    claimed here.
    
    
  3. Adrian Farrel: Comment [2012-02-29]:
    Thank you for the paragraph at the end of the Introduction.
    
    
    
    ---
    
    
    
    This document would be made significantly more useful by the addition
    
    of a figure showing the architectural components.
    
    
    
    ---
    
    
    
    Please s/draft/document/ throughout.
    
    
    
    ---
    
    
    
    Section 2 
    
    
    
       For traffic not to be
    
       dropped, either some mechanism to make this destination EID routable
    
       must be in place.
    
    
    
    Typo "either", or missing "or".
    
    
    
    ---
    
    
    
    Section 5.2
    
    
    
    Are there any consequences of the assymetry of PITR use that we should
    
    investigate? Yes, I know that the Internet is not always symmetric,
    
    but in general it often is.
  4. Stephen Farrell: Comment [2012-02-29]:
    - Its not clear to me that the mapping system can reliably know
    
    that all non-LISP IP addresses are in fact not EIDs. But I'm
    
    willing to suspend disbelief for the experiment:-)

draft-ietf-behave-64-analysis

  1. Adrian Farrel: Comment [2012-02-28]:
    I have no objection to the publication of this document, but I have a
    
    number of small issues I hope you will attend to before publication.
    
    
    
    ---
    
    
    
    Section 2 is unnecessary and should be removed (deosn't idnits give a 
    
    warning about this?)
    
    
    
    ---
    
    
    
    In Section 3, it would help the reader if you did not use the passive
    
    voice.
    
    
    
       Following is a point by point
    
       analysis of the problems.  Issues listed in [RFC4966] are classified
    
       into three categories:
    
    
    
    Is the classification yours or does it come from RFC 4966? It is a bit 
    
    of a nuisance to have to read RFC 4966 to discover the answer?
    
    
    
    In view of this, I found the category "impossible to solve" to be an
    
    "interesting" categorisation! Where is the proof?
    
    
    
    ---
    
    
    
    Section 3.3
    
    
    
              Analysis: This issue has mitigated severity as the DNS is
    
              separated from the NAT functionality.
    
    
    
    Using a past participle as an adjective is all very well, but here is  
    
    has confused the meaning! It reads as though the issue has done the 
    
    mitigation. Better to say:
    
    
    
       The severity of this issue has been mitigated...
    
    
    
    And then it is normal to treat mitigation as transitive. So, what did
    
    the mitigation?
    
    
    
       The severity of this issue has been mitigated by the separation of
    
       the DNS from the NAT functionality.
    
    
    
    ---
    
    
    
    Section 3.3, item 3
    
    
    
    This item suggests that you need a fourth category: viz. issues that
    
    do not apply to this problem space.
    
    
    
    ---
    
    
    
    Section 6 would be enhanced by pointing at the issues within the
    
    document that are related to security.
    
    
    
    ---
    
    
    
    I'm slightly suspiscious that the reference to 
    
    [I-D.haddad-mext-nat64-mobility-harmful] in Section 3.1 may be 
    
    normative.
    
    
    
    I am pretty sure that [I-D.ietf-pcp-base] is normative in item 4 of
    
    Section 3.3.
    
    
    
    [I-D.ietf-behave-lsn-requirements] in item 6 of Section 3.3 may be
    
    normative.
  2. Russ Housley: Discuss [2012-02-28]:
    
    The Gen-ART Review by David Black on 28-Feb-2012 raises one major
    
      concern that needs to be addressed.  David offers alternative
    
      text, but the authors have not said whether they agree with it as
    
      yet.  The review form David can be found here:
    
      
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07228.html
    
    

draft-ietf-pcn-encoding-comparison

  1. Adrian Farrel: Discuss [2012-02-29]:
    
    Section 3.2.3
    
    
    
    I cannot reconcile the text in option (1) that says:
    
    
    
    with the conclusion of the section that says:
    
    
    
       Option (1) seems to be the most viable and efficient solution. 
    
    
    
    If it is the intention of the PCN working group to be "PCN for IP-only
    
    networks" then I do think this could be s[elled out. OTOH, if MPLS is
    
    in scope, then surely option (1) is impractical.
    
    
    
    Note that draft-ietf-pcn-3-in-1-encoding makes a specific statement 
    
    about applicability only to IP.
    
    
    
    --- 
    
    
    
    What does "Primarily" mean in this context?
    
    
    
    I would like you to replace the passive voice in Section 4.5 so I can
    
    tell who made the decision!
    
    
    
    Additionally, I would like to understand why there are other PCN working
    
    group documents for other encodings (draft-ietf-pcn-3-state-encoding, 
    
    draft-ietf-pcn-psdm-encoding) if this section represent a full statement
    
    of the WG's decisions.
    
    
    
    ---
    
    
    
    I'm afraid I found the conclusion in Section 5 particularly
    
    impenetrable.
    
    
    
    Could you:
    
    - Break out "what we did in this document" as a separate paragraph.
    
    - Make a definitive statement about what the WG has concluded.
    
    - Place the summary of the reasons for the conclusion as a third
    
      paragraph.
    
    
  2. Adrian Farrel: Comment [2012-02-29]:
    In Section 1  
    
    
    
       This
    
       requires at least three different codepoints for not-marked PCN
    
       traffic, PCN traffic re-marked by the threshold-marker,
    
       and PCN traffic re-marked by the excess-traffic-marker.
    
    
    
    Please insert a colon after "codepoints" in order to fix the meaning.
    
    
    
    ---
    
    
    
    In Section 1
    
    
    
       This 
    
       document summarizes these issues for historical purposes.
    
    
    
    Do you want to publish this as a Historic RFC?
    
    
    
    ---
    
    
    
    Section 3
    
    
    
       The Differentiated Services (DS) field is chosen for the encoding of
    
       PCN marks.
    
    
    
    This use of the passive voice is not helpful!
    
    
    
    - Has the choice already been made? If so give a reference.
    
    - Does this document document the choice being made? If so give a
    
      forward pointer or explanation.
    
    - Or is this just commentary? :-)
    
    
    
    ---
    
    
    
    I think Section 3.1 makes [RFC0793], [RFC2474], and [RFC3168] into 
    
    normative references. 3.3.1 reinfotces that for [RFC3168].
    
    
    
    Section 3.3 and 3.3.2 appear to make [RFC4774] normative.
    
    
    
    ---
    
    
    
    Section 3.3.3.4 uses "CU" before it is explained in Seciton 4 and 
    
    defined in Section 4.3
    
    
    
    ---
    
    
    
    Section 4
    
    
    
       Figure 7 summarizes these PCN encodings. as summarized  
    
       in Figure 7.
    
    
    
    :-)

draft-ietf-mext-mip6-tls

  1. Adrian Farrel: Comment [2012-02-29]:
    I am balloting No Objection on the assumption that this has been
    
    thoroughly reviewed by the INT ADs and the Security Directorate.
  2. Stephen Farrell: Discuss [2012-02-29]:
    
    So while this seems to be quite a good idea, I've a couple of things
    
    I want to understand...(oops - added #3 below, forgot that)
    
    
    
    #1 Has the security of the auth protocol in 5.8 been studied much?  If
    
    so, where is that described?  I'm surprised there's nothing
    
    directional to prevent reflection attacks or cross-protocol attacks,
    
    e.g. by including MN and HAC-specific strings in the HMAC input.
    
    As-is, it also looks like messages 2 and 3 could maybe be reflected.
    
    It also looks like messges can be replayed since the
    
    tls-server-end-point CB-octets are fixed per-hac. Since CB-octets are
    
    essentially public, guesses of the MN's PSK are also possible, if that
    
    is somehow human-memorable. This all looks like a problem to me that
    
    needs to be looked at even for an experimental spec, or maybe I'm
    
    misreading something. (I guess similar concerns might exist for
    
    the eap method in 5.9 as well.)
    
    
    
    #2 If MN authentication is done above TLS then you might need to ensure
    
    that TLS implementations are not vulnerable to the TLS re-negotiation
    
    bug.  (See RFC 5746.) Did you think that thgrough? Might be worth
    
    noting in the security considerations even though the MN<->HAC
    
    authentiction scheme uses channel-bindings, just in case. (Actually
    
    since the CB-octets are not session-specific this might be a
    
    gotcha too.)
    
    
    
    #3 The draft seems to be missing information on how to match TLS 
    
    certificates to identities for HAC authentication.
    
    
  3. Stephen Farrell: Comment [2012-02-29]:
    - I don't see why MN authentication has to be done outside the TLS
    
    session setup (handshake). TLS supports client authentication and its
    
    not clear why that couldn't be used here instead of the scheme in
    
    5.8/5.9.
    
    
    
    - Isn't there already a way to do EAP over TLS? Why invent a new one?
    
    I think you should say why, if its justified.  (e.g. RFC 5281.)
    
    
    
    - 4.2: I guess you also need mutual authentication between
    
    non-colocated HAC and HA instances? (That might seem like nit-picking,
    
    but there are ways to get integ. & confid.  without knowing for sure
    
    from whom stuff is coming.)
    
    
    
    - I'm a bit surprised that you don't want to use RFC5705 to extract
    
    some key material from TLS sessions. Worth considering and/or noting
    
    as a possible future improvement?
    
    
    
    - 5.6 seems a bit brittle - if TLS changes the set of preferred
    
    ciphersuites that could in principle result in a mismatch between the
    
    TLS preferred ciphersuites and what's doable between MN and HA. 
    
    
    
    - In 5.8 you don't seem to have algorithm agility for your "auth"
    
    algorithm - can it be other than HMAC-SHA256? Maybe ok for an
    
    experimental RFC though but worth noting.
    
    
    
    - In 5.8 after figure 4, step 2, what is msg-octets when none of the
    
    optional fields are included? The description in the last two
    
    paragraphs seems a bit broken too. (2nd last para should be about step
    
    2 I thought) 
    
    
    
    - As commonly used, TLS doesn't quite give the same level of security
    
    as IPsec as commonly used. IPsec has perfect forward secrecy due to
    
    its use of D-H, whereas TLS with RSA key transport does not. That
    
    means that a later exposure of a server RSA private key (e.g. if
    
    de-commissioned h/w isn't properly scrubbed) potentially allows anyone
    
    to recover TLS pre-master keys from any recorded TLS sessions. That's
    
    worth noting so that if someone does deploy this, they know to not
    
    just sell old server h/w that used to store RSA private keys on disk. 
    
    
    
    - TLS with RSA key transport also relies on the entropy provided by
    
    the client for security. That has been a source of known problems over
    
    the years (including very recently) and so is also worth noting since
    
    the client here is a mobile node that might just have been turned on
    
    and so not have lots of entropy.
    
    
    
    - While TLS protects against replays, if somehow I get the auth
    
    protocol messages then I can replay those in a new TLS session with
    
    the HAC so the text in the security considerations on this point might
    
    need to change depending on the discuss pionts above.
    
    
    
    - There're some points worth noting in the secdir review as well.
    
    
    
       http://www.ietf.org/mail-archive/web/secdir/current/msg03131.html
  4. Russ Housley: Comment [2012-02-29]:
    Please see the comments in the Gen-ART Review by Ben Campbell
    
      on 28-Feb-2012.  The comment that causes me the greatest concern
    
      is covered by the (updated) DISCUSS position from Stephen Farrell.
    
      Please consider all of Ben's review comments:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07232.html
  5. Peter Saint-Andre: Discuss [2012-02-28]:
    
    Section 9.2 states that "Server-side certificate based authentication MUST be
    
    performed using TLS 1.2 [RFC5246]" but that "The client-side authentication may
    
    depend on the specific deployment and is therefore not mandated." However, you
    
    don't say anything about the basis for authentication or identity checking. What
    
    identifiers need to be in the certificates? How are those identifiers checked?
    
    What are the rules? We can't just wave our hands here, else interoperability
    
    will be impossible (as will real security). Profiling RFC 6125 might make sense,
    
    if the identifiers are domain names. If the identifiers are IP addresses, then
    
    life is simpler, but we would still need to say something about identity
    
    checking.
    
    

draft-ietf-v6ops-v6nd-problems

  1. Stewart Bryant: Comment [2012-02-29]:
    I have no objection to the publication of this document.
    
    
    
    It discusses a problem that is very close to the problem that we have chartered
    
    the ARMD  to address and I am wondering whether there needs to be a reference to
    
    that work.
  2. Adrian Farrel: Comment [2012-02-28]:
    I have no objeciton to the publication of this document, but I noticed
    
    a few small points I hope you will look at before publication.
    
    
    
    ---
    
    
    
    While appreciating the desire to use RFCs to force vendors to provide
    
    specific function to the operators, I don't think that the use of
    
    RFC 2119 language in this Informational document adds very much (the
    
    language is intended to add clarity to protocol specifiations, and is
    
    sometimes used to make requirements documents clearer). In fact, I
    
    cold only find two uses of such language (both are "SHOULD") in this
    
    document so I suggest you change them to normal lower case, and drop
    
    the boilerplate from Section 1.
    
    
    
    ---
    
    
    
    Section 4
    
    
    
       During testing it was concluded that 4 simultaneous
    
       nmap sessions from a low-end computer was sufficient to make a
    
       router's neighbor discovery process unusable and therefore forwarding
    
       became unavailable to the destination subnets.
    
    
    
    Without casting aspertions on the authors, is it possible to provide
    
    some qualification of this statement? For example, a reference to the 
    
    test description and results, or a simple note as to by whom the testing
    
    was carried out.
    
    
    
    Similarly...
    
    
    
       The failure to maintain proper NDP behavior whilst under attack has
    
       been observed across multiple platforms and implementations,
    
       including the largest modern router platforms available (at the
    
       inception of work on this document).
    
    
    
    ... would benefit from a reference.
    
    
    
    ---
    
    
    
    Section 6
    
    
    
    s/stipulated/suggested/ or s/stipulated/stated/
    
    
    
    ---
    
    
    
    Section 7 might benefit from more detail on the management interfaces
    
    that operators would like to see provided by vendors both for the
    
    control of the optional mechanisms discussed in this document and for
    
    the notification about and analysis of attacks.
    
    
    
    ---
    
    
    
    It might have been nice to add a note about the interaction with
    
    mobility (such as of VMs in a data center).
  3. Peter Saint-Andre: Comment [2012-02-28]:
    This document sure feels like a standards-track Applicability Statement to me.
    
    Did the WG consider requesting a status of Proposed Standard?
    
    
    
    Please consider citing RFC 4732 at the first use of the term Denial of Service.

draft-snell-atompub-tombstones

  1. Adrian Farrel: Comment [2012-02-27]:
    I have no objection to the publicaiton of this document. I think that the
    
    Introduction could have been more extensive - a good place for citations and
    
    explanations.
  2. Stephen Farrell: Comment [2012-02-24]:
    1. I didn't really get what's meant by 
    
    
    
    "  When an at:deleted-entry element appears in a Feed document other
    
    than it's source Feed or when an at:deleted-entry element that has a
    
    source Feed document is used in the context of a Deleted Entry
    
    Document, it MUST contain an atom:source element."
    
    
    
    But I guess Atom developers probably do so that's ok.
    
    
    
    2. Last para of section 6: I guess that if someone did MAC and then
    
    symmetrically encrypt one of these (is that as unlikely as I think?)
    
    then it might be useful to tell them not to use the same key for
    
    both.
    
    
    
    3. Digital signatures by themselves do not provide non-repudiation.
    
    Please delete that term.
    
    
  3. Robert Sparks: Discuss [2012-02-29]:
    
    This is a solid document. Before moving to Yes, I would like to ask if
    
    publishing it as Proposed Standard rather than Informational was considered? I
    
    don't object to publishing it as Informational, but suggest that Proposed
    
    Standard is a better track for it.