IESG Narrative Minutes

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

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

Corrections from: Cindy, Barry, Pete, Adrian

1 Administrivia

  1. Roll Call 1132 EDT Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. CoRE Link Format (Proposed Standard)
    draft-ietf-core-link-format-11
    Token: Peter Saint-Andre
    Note: Carsten Bormann (cabo@tzi.org) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-core-link-format):
    1. Jari Arkko: Discuss [2012-03-11]:
      This is a well written document, thank you for doing it. I have a small problem with the ABNF, however, see below for the details. Perhaps this video also illustrates my point:
      http://www.youtube.com/watch?amp;feature=player_embedded&v=LbK-g8tKnoc
    2. Jari Arkko: Comment [2012-03-11]:
      Bill's ABNF parser suggests this change:
      OLD: cardinal = "0" / %x31-39 *DIGIT
      NEW: cardinal = "0" / ( %x31-39 *DIGIT )
      Also: "The CoRE link format is the [RFC5988] production named "Link", and imports the ABNF description and associated rules in Section 5 of that document. The "Link:" text is omitted as that is part of the HTTP Link Header. Note that the ABNF in the present document is compliant with [RFC5234]."
      This was very misleading to me, it took a while to realize that RFC 5988 uses the RFC 2616 ABNF, which is different from RFC 5234 ABNF. Simply copying the ABNF from various RFCs into a file and compiling or verifying the ABNF will not work. Also, the actual definition of Link does not use the string "Link:" literally:
      Link = "Link" ":" #link-value
      I would suggest a rewrite as follows:
      "The CoRE link format is the [RFC5988] ABNF production named "Link". This specification imports the ABNF from Section 5 of [RFC5988]. However, that ABNF has been defined using the format and auxiliary productions defined in [RFC2616] whereas the present document uses ABNF as defined in [RFC5234]. As a result, for the purposes of the present document, the [RFC5988] ABNF needs to be understood as if it were written in [RFC5234] form."
      "In addition, for the purposes of CoRE link format, the "Link:" text is omitted as [RFC5988] used it only for the HTTP Link Header. As a result, for CoRE link type, the [RFC5988] "Link" production should be defined as follows:"
      Link = link-value-list
      link-value-list = [ link-value *[ "," link-value ]]
      ; link-value is as defined in [RFC5988]
    3. Ralph Droms: Comment [2012-03-12]:
      One minor editorial suggestion: in the Introduction, RFC 4919 might be a better general reference for "6LoWPAN" than RFC 4944.
    4. Stephen Farrell: Comment [2012-03-11]:
      - Richard Barnes' secdir review suggested text for section 6 about authorization that the author seems to like, so this is just to note that until its fixed.
      - I'd also suggest adding the following to Richard's suggest text: "While such servers might not return all links to all requesters, not providing the link does not, by itsef, control access to the relevant resource - a bad actor could know or guess the right URIs."
      - I'd also suggest adding something about servers that might tell lies to feed bad data to clients, e.g. "Servers can lie about the resources available. If it is important for a client to only get information from a known source, then that source needs to be authenticated."
    5. Russ Housley: Discuss [2012-03-09]:
      The Gen-ART Review by Joel Halpern on 18-Feb 2012 raised a question that still needs to be resolved in the document. Joel asked:
      "What is the registration / collision avoidance strategy for resource type (rt) and interface description (if) values? They are both defined as opaque strings which can happen to be URIs. So there seems to be potential for collision."
      The author indicates that two separate IANA registries for rt and if types are fine with him, but this is not reflected in the document.
    6. Pete Resnick: Comment [2012-03-09]:
      Only stylistic nits. Otherwise no problems.
    7. Sean Turner: Comment [2012-03-14]:
      s3.2 Any chance for an actual size for the reasonable size limit?

    Telechat:

  2. Extensions to DKIM for Failure Reporting (Proposed Standard)
    draft-ietf-marf-dkim-reporting-14
    Token: Pete Resnick
    Discusses/comments (from ballot draft-ietf-marf-dkim-reporting):
    1. Jari Arkko: Discuss [2012-03-15]:
      I can not believe I am doing this again for the third time this week, but:
      http://www.youtube.com/watch?v=LbK-g8tKnoc
    2. Jari Arkko: Comment [2012-03-15]:
      rep-rr-tag = %x72.72 *WSP "=" *WSP rep-rr-type *WSP 0* ( ":" *WSP rep-rr-type )
      Bill's parser (http://tools.ietf.org/tools/bap/abnf.cgi) says:
      stdin(1:28): error: No whitespace allowed between repeat and element.
      There are two instances of this error in the draft.
    3. Adrian Farrel: Comment [2012-03-13]:
      Thanks for handling my Discuss and Comments
    4. Stephen Farrell: Comment [2012-03-12]:
      Thanks for handling my discuss points.
    5. Peter Saint-Andre: Comment [2012-03-08]:
      Section 3.2 states: "Any tag found in the content of this record that is not registered with IANA as described in Section 7.3 MUST be ignored."
      Does this really need to be "MUST", or is "SHOULD" sufficient? Saying MUST would prevent any further experimentation, which you might consider a good thing or a bad thing.
    6. Sean Turner: Discuss [2012-03-14]:
      Is the assumption here that the report-generator/DKIM-verifier also supports DKIM-signing and will send the report back DKIM-signed? If that's true shouldn't there be some kind of requirement that the DKIM l= value MUST cover the entire report body? Or, do you think folks will do that by default because that's the l= default in RFC 6376? And, would it be better to state a requirement that returned reports MUST be DKIM-signed?
    7. Sean Turner: Comment [2012-03-14]:
      s2.4: r/entitiy/entity

    Telechat:

  3. SPF Authentication Failure Reporting using the Abuse Report Format (Proposed Standard)
    draft-ietf-marf-spf-reporting-09
    Token: Pete Resnick
    Discusses/comments (from ballot draft-ietf-marf-spf-reporting):
    1. Adrian Farrel: Comment [2012-03-13]:
      I have no objection to the publication of this document.
      Very trivial nits...
    2. Stephen Farrell: Comment [2012-03-11]:
      - s3, is "unauthorized routing" the right term for what causes an SPF fail?
      - s3, "rr=all" as the default - depending on how the discuss on the marf dkim draft is resolved there might be a similar change needed here.
    3. Sean Turner: Comment [2012-03-14]:
      s6.1: r/SPF SPF/SPF
      s6.1: missing the closing ) in the last para.

    Telechat:

  4. Deprecating the X- Prefix and Similar Constructs in Application Protocols (Best Current Practice)
    draft-ietf-appsawg-xdash-04
    Token: Pete Resnick
    Discusses/comments (from ballot draft-ietf-appsawg-xdash):
    1. Ralph Droms: Comment [2012-03-12]:
      This text:
      2. Recommendations for Implementers of Application Protocols: "Implementers of application protocols MUST NOT treat the general categories of "standard" and "non-standard" parameters in programatically different ways within their applications."
      while probably not harmful, is sufficiently vague and refers to undefined terms in a way as to contribute, perhaps, more confusion than value.
    2. Dan Romascanu: Comment [2012-03-15]:
      I agree with Ralph terminology comment. I also find confusing the repeated usage of the phrase 'deprecating a convention (or construct)' where in fact there is no specific place in standard-track or BCP RFCs where such a convention or construct was clearly articulated. I would have found more clear if instead of this the document would have pointed to an explicit list of conventions or constructs that are NOT RECOMMENDED.

    Telechat:

  5. xDSL multi-pair bonding (G.Bond) MIB (Proposed Standard)
    draft-ietf-adslmib-gbond-mib-10
    Token: Dan Romascanu
    Note: Menachem Dodge (Menachem.Dodge@ecitele.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-adslmib-gbond-mib):
    1. Adrian Farrel: Comment [2012-03-15]:
      I have no objection to the publication of this document.
      I have a number of small Comments. They are non-blocking and you can take them or leave them
      The shepherd write-up appears to disagree with the ballot write-up wrt implementations. I choose to believe the shepherd not the AD since the shepherd gives better news!
      It is not necessary to say the document "proposes". You can say "defines".
      Thanks for the detail in Section 4. It really helps.
      Question for you. How likely is it that new bonding schemes (i.e. other technologies) will come along and be handled by this MIB module without extensions? I think the intention is that this module is technology-independent, so that it would not need to be revised for a new bonding type.
      However, GBondSchemeList and GBondScheme are closed lists such that you would need to revise the module to support new technologies. That seems a shame.
      You could move the TCs into a separate module so that only that module needs to be revised.
      An alternative, is to define an IANA Textual convention for this and allow just the TC to be updated as necessary.
      I find the presence of 'unknown' as a bit in GBondSchemeList to be a bit odd. In general, bits in an object with a Syntax of Bits can be independently set. But here you could not set 'unknown' and any of the other bits.
      On the other hand, what would it mean to return the object with none of the bits set? Is that different from returning the 'unknown' bit?
      gBondLowUpRateCrossing Description
      s/port'/port's/
    2. Pete Resnick: Comment [2012-03-12]:
      Please update the document writeup and shepherd report to include information about review and implementation.
    3. Peter Saint-Andre: Comment [2012-03-12]:
      You might consider adding informational references for NTP and SNTP.

    Telechat:

  6. ATM-Based xDSL Bonded Interfaces MIB (Proposed Standard)
    draft-ietf-adslmib-gbond-atm-mib-06
    Token: Dan Romascanu
    Note: Menachem Dodge (Menachem.Dodge@ecitele.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-adslmib-gbond-atm-mib):
    1. Stephen Farrell: Comment [2012-03-09]:
      Just wondering: Could access to gBondAtmPortPmCur1DayUpDiffDelay or similar measurements extend the reach of timing-based attacks on cryptographic protocols? That is, if I could do a timing attack on a node from its next hop router, access to this data might then allow me to mount the same attack from further away. I guess in principle that might increase the sensitivity of some of these real-time measurements, however, its probably too low a probability to make any change worthwhile and even if it was worthwhile to note somewhere, it probably wouldn't be here.

    Telechat:

  7. Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB (Proposed Standard)
    draft-ietf-adslmib-gbond-eth-mib-06
    Token: Dan Romascanu
    Note: Menachem Dodge (Menachem.Dodge@ecitele.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-adslmib-gbond-eth-mib):
    1. Adrian Farrel: Discuss [2012-03-15]:
      This is a procedural Discuss that I am holding while I have a question outstanding to the liaison to IEEE. I do not have any action for the document authors, and expect to be able to clear the Discuss when I have the answer.

    Telechat:

  8. xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB (Proposed Standard)
    draft-ietf-adslmib-gbond-tdim-mib-08
    Token: Dan Romascanu
    Note: Menachem Dodge (Menachem.Dodge@ecitele.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-adslmib-gbond-tdim-mib):
    1. (none)

    Telechat:

  9. Deprecation of ICMP Source Quench messages (Proposed Standard)
    draft-ietf-tsvwg-source-quench-06
    Token: Wesley Eddy
    Note: Gorry Fairgurst (gorry@erg.abdn.ac.uk) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-tsvwg-source-quench):
    1. Adrian Farrel: Comment [2012-03-14]:
      Thank you for this document. Clear and well constructed.
      I did wonder whether RFC 1016 should be moved to Historic at this time.
    2. Pete Resnick: Comment [2012-03-09]:
      A document so clear that I feel comfortable balloting "Yes", even if it's not in my area.
    3. Dan Romascanu: Comment [2012-03-14]:
      This is probably late in the process, but I think that such a document should have been last-called with the OPSAWG as well and also with some of the operators fora, to make sure that there are no critical operator tools depending on the deprecated option, and for the operators to have a prior warning about the changes in the implementations resulting from the approval of this update.
    4. Peter Saint-Andre: Comment [2012-03-08]:
      I found a minor error:
      o Processing of ICMP Source Quench messages by routers has been deprecated for more than 20 years [RFC1812].
      Actually, it's less than 17 years: RFC 1812 was published in June 1995.

    Telechat:

  10. Packet Pseudowire Encapsulation over an MPLS PSN (Proposed Standard)
    draft-ietf-pwe3-packet-pw-03
    Token: Adrian Farrel
    Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-pwe3-packet-pw):
    1. Stewart Bryant: Comment [2012-03-05]:
      Previous Abstain position was a mouse error.
    2. Pete Resnick: Comment [2012-03-11]:
      Sometimes I feel like people do fun things with 2119 language entirely for my entertainment when it's a document outside of my area. :-)
      Seriously, these are all simply comments that I think will improve the comprehensibility of the document. I hope they help.
      Section 1: "Where the client equipment is connected to the server equipment via a physical interface, the same data-link type MUST be used to attach the clients to the Provider Edge equipments (PE)s, and a pseudowire (PW) of the same type as the data-link MUST be used [RFC3985]."
      Something is odd here. RFC3985 is Informational and is not a normative reference, and it doesn't include any MUSTs, so those requirements can't be coming from 3985 per se. And I suspect they are not new requirements in this document at all. Do you actually mean the following?
      "The architecture in [RFC3985] says that, where the client equipment is connected to the server equipment via a physical interface, the same data-link type will be used to attach the clients to the Provider Edge (PE) equipment, and a pseudowire (PW) of the same type as the data-link will be used."
      Also in Section 1: "Non-normative Appendix Appendix A provides information..."
      This verbal tic of inserting the words "non-normative" I find completely silly. It is absolutely clear from the contents of the appendix that it is non-normative, and we're heading down the path where sections will be titled, "Non-normative Table of Contents" and "Non-normative Acknowledgements". Please remove those words.
      Section 5: "The PEs MAY use a local Ethernet address for the Ethernet header used to encapsulate the client network layer packet. Alternatively the PEs may use the following procedure."
      I found the above confusing. The first "procedure" after this is an IANA procedure, and the "may" there looks like it should be a "MAY". Perhaps instead:
      "The PEs MAY use a local Ethernet address for the Ethernet header used to encapsulate the client network layer packet, or MAY use one of the special Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as described below."
      Also in section 5: "IANA are requested to allocate two unicast Ethernet addresses [RFC5342] to this protocol (PacketPWEthA and PacketPWEthB). PacketPWEthA is the value lower Ethernet address and PacketPWEthB is the higher value Ethernet address. Where [RFC4447] signalling is used to set up the PW, the LDP peers compare IP addresses and with the PE with the higher IP address uses PacketPWEthA, whilst the LDP peer with the lower IP address uses PacketPWEthB."
      Very awkwardly worded and confusing to me. Instead maybe:
      "IANA is requested to allocate [ed note: RFC Editor will change to "has allocated"] two unicast Ethernet addresses [RFC5342] for use with this protocol, referred to as "PacketPWEthA" and "PacketPWEthB". Where [RFC4447] signalling is used to set up the PW, the LDP peers numerically compare their IP addresses. The LDP PE with the higher value IP address will use PacketPWEthA, whilst the LDP peer with the lower value IP address uses PacketPWEthB."
      Also in section 5: "Not withstanding the fact that this PW represents a point-to-point connection, some client layer protocols require the use of a destination multicast address in the Ethernet encapsulation. This mode of operation MUST be supported."
      The passive voice in the last sentence is problematic. Do you mean, "Peers MUST be prepared to handle a destination mulitcast address in the Ethernet encapsulation"?
      Section 6: "Thus, for example, the Ethernet OAM is NOT REQUIRED."
      "NOT REQUIRED" is not a 2119 term. I think you might mean "Thus, for example, a server LSR MAY choose not to use Ethernet OAM". Or you might simply mean "not required".
      Appendix A: "This appendix is non-normative."
      Please strike.
    3. Dan Romascanu: Comment [2012-03-13]:
      1. In the Abstract s/is the case/in the case/
      2. In Section 6 - VLANs, 802.1p and 802.1Q are not Ethernet but bridging fucntions
      So I suggest the following changes:
      in the title s/Ethernet/Ethernet and IEEE 802.1/
      and:
      OLD: "The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q between PEs is not supported."
      NEW: "The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q between PEs is not supported."
      Maybe adding 'tagging' after 802.1Q would help if this is the intent.

    Telechat:

  11. Definitions of Managed Objects for IP Flow Information Export (Proposed Standard)
    draft-ietf-ipfix-rfc5815bis-02
    Token: Dan Romascanu
    Note: Juergen Quittek (Quittek@neclab.eu) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-ipfix-rfc5815bis):
    1. Russ Housley: Discuss [2012-03-13]:
      The Gen-ART Review by Joel Halpern on 23-Feb-2012 raised several small concerns. Each individual one is minor, but taken together, they are sufficiently confusing that I would like to see them resolved.
      Joel's review includes these three concerns:
      - The description in the first paragraph of 5.2 on the Template table is written in such a way as to lead the reader to think the Observation Domain is somehow associated with the Transport Session (which table provides the device mode which is discussed in that text.) Could you split the Observation Domain reference out to a separate sentence (possibly before the reference to the Transport Session)?
      - In the example of the export table in section 5.4, there are two blocks of export entries, on with ipfixExportIndex 7, and one with 8. They are mirrors of each other except that they reverse which transport session is primary, and which is secondary. There is no explanation of why both are present. And there is no explanation of why the settings in index 7 are used, rather than those in index 8.
      - If you define an Observation Point with 0 for both Physical Entity and Physical Interface, what is it observing? Similarly, what is a metering process metering if its Observation Point Group Ref is 0?
    2. Pete Resnick: Comment [2012-03-11]:
      This document appears to Obsolete RFC 5815, but that is not indicated anywhere in the document, nor in the header.
      This appears to be simply errata fixes from 5815. Is there a reason it is recycling at Proposed rather than advancing to Internet Standard?
    3. Sean Turner: Comment [2012-03-12]:
      s1: Not sure you need the MUST/MAY in the following because they're not telling me much:
      "Most of the objects defined by the IPFIX MIB module MUST be implemented. Some objects MAY be implemented corresponding to the functionality implemented in the equipment."

    Telechat:

  12. IANA Registry for MEDIACTRL Interactive Voice Response Control Package (Proposed Standard)
    draft-ietf-mediactrl-6231-iana-00
    Token: Robert Sparks
    Discusses/comments (from ballot draft-ietf-mediactrl-6231-iana):
    1. Pete Resnick: Comment [2012-03-09]:
      Not important enough to hold up publication of this very simple document for even a second, and this is mostly for IESG discussion, but: Is Standards Track appropriate for this document? Seems like even Informational would do.
    2. Peter Saint-Andre: Comment [2012-03-08]:
      Section 3 does not specify the name for the registry. One could assume that it is the "MEDIACTRL Interactive Voice Response Control Package Registry", but it would be good to make that clear.
    3. Sean Turner: Comment [2012-03-12]:
      To avoid any possibility of transcription errors couldn't you just point to Table 1 in RFC 6231 from s3?

    Telechat:

2.1.2 Returning Items

  1. Encoding 3 PCN-States in the IP header using a single DSCP (Proposed Standard)
    draft-ietf-pcn-3-in-1-encoding-09
    Token: David Harrington
    Note: Scott Bradner (sob@harvard.edu) is the document shephed.
    Discusses/comments (from ballot draft-ietf-pcn-3-in-1-encoding):
    1. Ronald Bonica: Discuss [2012-03-14]:
      I am confused about why this document is being published on the Standards Track as opposed to EXPERIMENTAL. The two documents that describe how these markings are used are both EXPERIMENTAL. Why not this one, too?
    2. Adrian Farrel: Discuss [2012-02-29]:
      It appears that there are a number of alternative encoding being proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding, draft-ietf-pcn-psdm-encoding, etc., and as discussed in draft-ietf-pcn-encoding-comparison. It isn't clear to me whether these encodings are being proposed to co-exist, to be used by different operators depending on specific environments, or whether they are being floated to see which one gets more market-place support.
      In the latter case, I would have thought that the encoding documents would have been Experimental.
      I might also have expected some mention of the other I-Ds if all of the solutions are to be completed by the WG.
      I think [I-D.ietf-pcn-sm-edge-behaviour] and [I-D.ietf-pcn-cl-edge-behaviour] are used normatively.
      Section 4.3 has: "It may not be possible to upgrade every pre-RFC6040 tunnel endpoint within a PCN-domain. In such circumstances a limited version of the 3-in-1 encoding can still be used but only under the following stringent condition. If any pre-RFC6040 tunnel endpoint exists within a PCN-domain then every PCN-node in the PCN-domain MUST be configured so that it never sets the ThM codepoint. PCN-interior nodes in this case MUST solely use the Excess Traffic marking function, as defined in Section 5.2.3.1."
      I completely get this, but I am worried about accidents. What happens if the operator thinks that they have upgraded all of the nodes, but have actually missed one?
      And then...: "In all other situations where legacy tunnel endpoints might be present within the PCN domain, the 3-in-1 encoding is not applicable."
      But what happens if an attempt is made to use it?
      In both cases, it is OK (probably/possibly) that the traffic using 3-in-1 will have problems, but quite another thing if other traffic is impacted (for example, traffic using pre6040 tunnel endpoints. Can you add text to say what happens?
      Section 5.1: "If a PCN-packet arrives at the PCN-ingress-node with its ECN field already set to a value other than not-ECT, then appropriate action MUST be taken to meet the requirements of [RFC4774]. The simplest appropriate action is to just drop such packets. However, this is a drastic action that an operator may feel is undesirable. Appendix B provides more information and summarises other alternative actions that might be taken."
      This is a protocol spec that tells implementers what to build. You can't leave the behavior open like this.
      At the very least you need to give a default behavior, state the other possible behaviors, amke it clear which MUST be implemented, and require a configuration option such that the operator can select.
      BTW, a spec that says that "appropriate action MUST be taken" is not helpful on two counts:
      1. What action is appropriate?
      2. Who MUST take the action?
    3. Adrian Farrel: Comment [2012-02-29]:
      (7 items)
    4. Stephen Farrell: Comment [2012-02-28]:
      The acronym PHB is used but not defined.
    5. Pete Resnick: Comment [2012-03-11]:
      "emphatically NOT RECOMMENDED" looks kinda like a cool new 2119 term, but it's not defined there and probably shouldn't be used. (I note that it isn't capitalized in Appendix B.) Maybe better would be "Implementation SHOULD NOT engage in this behavior except in the most extreme circumstances because..."
      "This appendix is informative, not normative." I find this sentence to be an increasingly used verbal tic in documents. I think it's useless and should be removed. In the case of Appendix A, you already say at the end that "operators are ultimately free to" use PCN or not. In Appendix B, you remind the reader that in the event of a conflict between the appendix and the rest of the document, implementations should follow the guidelines in the rest of the document. This "informative vs. normative" distinction is just jargon that isn't necessary.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. CalDAV Scheduling Extensions to WebDAV (Proposed Standard)
    draft-desruisseaux-caldav-sched-11
    Token: Peter Saint-Andre
    Note: Mike Douglass - douglm@rpi.edu - is the document shepherd.
    Discusses/comments (from ballot draft-desruisseaux-caldav-sched):
    1. Jari Arkko: Discuss [2012-03-11]:
      This is a well written document, thanks for writing it. I have a small problem with the ABNF, however, please see below for further details and correct as you see necessary. Perhaps this video also illustrates my point:
      http://www.youtube.com/watch?amp;feature=player_embedded&v=LbK-g8tKnoc
    2. Jari Arkko: Comment [2012-03-11]:
      Section 7.1 and 7.2 ABNF definitions should point out that "x-name" and "iana-token" definitions are from RF 5545, just as Section 7.3 does for other definitions. It took a while for me to search where this definitions are, particularly when the RFC series has multiple different definitions for these two productions.
    3. Stephen Farrell: Comment [2012-03-11]:
      - Thanks for handling Klaas Wierenga's good secdir review so well and quickly!
      - 3.2.2.1 says the server "MUST allow" but later says how the server can return errors if e.g. the client hasn't permission for the change requested. It might be better to say at the top that "The server MUST be able to allow Attendees to:"
      - 3.2.3 says its about HTTP methods, but uses webdav methods as well (e.g. COPY, MOVE) so maybe a reference to rfc 4918 would be useful at the start here? (Or wherever is best to go for those.)
      - I guess this is maybe not too likely but just to check. If a client guesses a UID to try find out who's up to what, 3.2.4.1 says the server SHOULD return the URL if there is a collision. I wondered whether that URL might expose some information, in which case the question is whether such UIDs are easily guessed or not. If such UIDs can be guessable, then maybe say something to the effect that the server might want to not return URLs that might expose details of the events (if such exist) and might want to return an innocuous error. Or better might be to RECOMMNEND that the UIDs (and URLs as well maybe) used for this be hard to guess. Note that the attack here (if it exists) could come from an authenticated client as well as from the Internet. The point here is to check that the UIDs don't allow me to get at information for which I'd get only 403 if I sent a request to the URL. (I guess its a separate question as to whether sending 403 gives away something that a 404 doesn't, but if so, that'd be for another day and draft.)
      - In 7.x sections you say clients MUST NOT include these parameters. Is there a need to say that server MUST NOT accept messages from (bad) clients that do in fact contain these parameters? Might be easy enough to get wrong if the server developer didn't pay any attention to what the client developer might get or do wrong.
    4. Pete Resnick: Comment [2012-03-14]:
      Generally: I think the 2119 language could use a good scrub. I think you use it in places where there is no real option, or there is no real interoperability implication. Please review.
      Section 3.2.8: "Servers MUST reset the "PARTSTAT" property parameter value of all "ATTENDEE" properties, except the one that corresponds to the Organizer, to "NEEDS-ACTION" when the Organizer reschedules an event."
      Don't you mean for all "ATTENDEE" properties *on each affected component*? I wouldn't have complained about this except for the MUST; if it's a requirement, you've got to be clear. If the change is for a recurrence instance that does not include that attendee, PARTSTAT shouldn't be reset, correct? (See section 3.2.6.)

    Telechat:

  2. AES-CCM Cipher Suites for TLS (Proposed Standard)
    draft-mcgrew-tls-aes-ccm-03
    Token: Sean Turner
    Note: Joe Salowey <jsalowey@cisco.com> is the Document Shepherd.
    Discusses/comments (from ballot draft-mcgrew-tls-aes-ccm):
    1. Stephen Farrell: Comment [2012-03-11]:
      A few easily fixed, but worth fixing, near-nits:
      1. RFC 5288 names ciphersuites such as TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 but this draft uses TLS_RSA_DHE_WITH_AES_256_CCM. Why change the order from DHE_RSA to RSA_DHE? If there's no good reason then maybe sticking with DHE_RSA would be better since it'd help with ordered lists and searches when folks want to find out how to do stuff.
      2. Even if you don't change these names (as above), the reference to RSA-DHE being in 5288 should probably be fixed since that string doesn't occur in 5288, where DHE_RSA is used, as in 5246.
      3. This draft says the RSA and RSA-DHE key exchanges are defined in 5288, but 5288 says that the RSA and DHE_RSA key exchanges are defined in 5246. Why the 2nd indirection?
      4. Section 4 has no reference to RFC 4279 which is where PSK stuff is really defined. I think adding that would be good.
      5. As above, the ciphersuite naming could be made more consistent. RFC 4279 defines TLS_DHE_PSK_WITH_AES_256_CBC_SHA whereas this draft defines TLS_PSK_DHE_WITH_AES_256_CCM.
      6. Section 5 could be more clear about why its a bad idea to negotiate these ciphersuites with TLS 1.1 and below. A pointer to a reference or a short sentence should be enough, just so developers don't ignore this so easily. (It'd maybe be easy to get this wrong for a developer with a TLS1.1 library on a constrained device who's nervous about moving to TLS1.2.)
      And one that's maybe less easily fixed:
      7. Clients using these ciphersuites will not be able to work with random TLS servers on the Internet for quite a while. Would it be worth noting that, so that we don't mis-direct constrained node developers or other SDOs into selecting these in the expectation that they will get the same level of interop as with the ciphersuites that are actually used in the wild? I say that accepting that there are real benefits to these ciphersuites for such clients, but the lack of interop is also a real downside, and one that not all the relevant folks seem to appreciate. (Even if we prefer authenticated encryption and more optimal ciphersuites for constrained nodes, that can force use of hop-by-hop security via some gateway in which case we're no long clearly winning overall.)
      And finally a non-actionable lament:-)
      7. Isn't it a pity 330 ciphersuites wasn't enough already.
    2. Peter Saint-Andre: Comment [2012-03-12]:
      Typo: s/abiltiy/ability/
      The missing "T" at the beginning of Section 2 causes the document to fail ID-nits.
      The cipher names use the "_8" suffix to indicate 8-octet authentication tags, and the lack of a suffix to indicate 16-octet authentication tags. Excuse my ignorance, but are any other lengths allowed in AEAD?

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation (Experimental)
    draft-ietf-pcn-cl-edge-behaviour-12
    Token: David Harrington
    Note: Steven Blake (slblake@petri-meat.com> is the document shepherd)
    Discusses/comments (from ballot draft-ietf-pcn-cl-edge-behaviour):
    1. Stephen Farrell: Comment [2012-03-11]:
      [SM-Specific] please see my comment on the other one of these...
    2. Peter Saint-Andre: Comment [2012-03-08]:
      This document contains quite a bit of requirements terminology. Are we sure that Informational is appropriate? Did the WG consider making this a standards-track Applicability Statement (Section 3.2 of RFC 2026)?
    3. Sean Turner: Comment [2012-03-15]:
      Same comments as draft-ietf-pcn-sm-edge-behavior.
      s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term "decision point" explicitly, I think that adding some text along the lines of "The decision point is considered to be part of a PCN-node; therefore, the decision point is considered to be trusted for truthful decisions." This makes it clear that s6.3.1 of RFC 5559 applies.
      s4.2.1: I find it a little odd that you say you're paraphrasing two sections but there's 2119 language in this draft where there was none in RFC 5559. Granted it's mostly MAY this and MAY that so it's not that big of a deal, but there is a MUST and a NOT RECOMMENDED. Are you really paraphrasing the text from RFC 5559 in that case?
      s1.1: Need to add NOT RECOMMENDED to the key words.

    Telechat:

  2. PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation (Experimental)
    draft-ietf-pcn-sm-edge-behaviour-09
    Token: David Harrington
    Note: Steven Blake (slblake@petri-meat.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-pcn-sm-edge-behaviour):
    1. Stephen Farrell: Comment [2012-03-11]:
      - The security considerations section doesn't note the inherent vulnerability if the decision point is separated from the enforcement point(s). That is, the enforcement points (in/egress nodes) have to have an interface that could be called from some malicious node. Even if the PDP/PEP protocol is not in scope here, this scheme means that problem exists and there are clear DoS vectors implicit in that. RFC 5559 which is referenced from this does say that "The signalling between the PCN-boundary-nodes must be protected from attacks" so I guess this is not discuss-worthy.
      - Total nit: t-recvFail is not a great name for a time - too easy to mistake for a subtraction, I'd suggest t_recvFail if it makes no difference. (And same for other names.)
    2. Russ Housley: Discuss [2012-03-13]:
      The Gen-ART Review by Joel Halpern on 31-Dec-2011 raised several issues. That lead to a significant discussion, but not all of the issues have been resolved.
    3. Peter Saint-Andre: Comment [2012-03-08]:
      This document contains quite a bit of requirements terminology. Are we sure that Informational is appropriate? Did the WG consider making this a standards-track Applicability Statement (Section 3.2 of RFC 2026)?
    4. Sean Turner: Comment [2012-03-15]:
      s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term "decision point" explicitly, I think that adding some text along the lines of "The decision point is considered to be part of a PCN-node; therefore, the decision point is considered to be trusted for truthful decisions." This makes it clear that s6.3.1 of RFC 5559 applies.
      s4.2.1: I find it a little odd that you say you're paraphrasing two sections but there's 2119 language in this draft where there was none in RFC 5559. Granted it's mostly MAY this and MAY that so it's not that big of a deal, but there is a MUST and a NOT RECOMMENDED. Are you really paraphrasing the text from RFC 5559 in that case?
      s1.1: Need to add NOT RECOMMENDED to the key words.

    Telechat:

  3. DECoupled Application Data Enroute (DECADE) Problem Statement (Informational)
    draft-ietf-decade-problem-statement-05
    Token: David Harrington
    Note: Richard Woundy (richard_woundy@cable.comcast.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-decade-problem-statement):
    1. Ronald Bonica: Discuss [2012-03-14]:
      The document may be conflating the following issues:
      - Problems that P2P applications present
      - How those problems can be solved by in-network caching
      - Deficiencies in currently deployed in-network caching solution.
      Deficiencies in currently deployed in-network caching solution might include:
      - lack of standardized singling protocols
      - lack of access control mechanisms
      - etc
      While the first first two issues are interesting, I think that the WG wants:
      - for the reader of this document to focus on deficiencies in currently deployed caching strategies
      - to address deficiencies in currently deployed caching strategies
      Would it be possible to make that more clear? One thing that you could do to focus the reader's attention is to remove text that isn't relevant to the point that you are making.
    2. Adrian Farrel: Comment [2012-03-14]:
      I have no objection to the publication of this document.
      I wondered whether Section 5 should discuss the problem that in-network storage may result in false data being supplied either through the data on a legitimate store being modified, or through a bogus store being introduced into the network. The material in Section 5 seems to cover the security of the protocol itself (and that may be enough) without describing these risks. Sis I miss something?
    3. Peter Saint-Andre: Comment [2012-03-12]:
      This is a well-written document. The first paragraph of Section 3 reads like marketing text. Is it needed?
    4. Robert Sparks: Comment [2012-03-13]:
      Here are some suggestions that might make this document more useful to the working group:
      Much of this document states the problem is that there's no standardized network storage solution. That's the solution you want to pursue, not the problem. A reader can get that the problem is some peer-to-peer protocols put stress on access networks. A potential solution that might treat the network as a whole more nicely would be to make it possible for peers that were on bandwidth constrained access to put things in a place that is both not bandwidth constrained and accessible by other peers. A secondary problem is that if existing protocols each tried to make this possible in their own way, it's harder for middleboxes that aren't explicitly part of that protocol to inject themselves to "help", and that could be avoided by giving all of the existing (and potentially any new) p2p protocols a common way to minimize moving content across the constrained barrier. A reader can get this message, but they have to read deeply and infer some of it. Please consider making the problem the main point of the text, and clearly identifying that network storage is the proposed solution path.
      The document speaks of a service "inside a network". It would help to be more precise. Do you mean "in the relatively bandwidth-unconstrained part of the network" or "in an access-regulated single administrative domain" or something else?
      The document asserts several times that using in-network resources will help, but doesn't support the assertion. Are there studies you can point to that show it's likely to help?
      The second paragraph quotes some reports on p2p traffic on access networks, using it to motivate reducing access traffic, but then claims it also motivates reducing "cross-domain and backbone traffic". While reducing traffic in general is probably a good idea the argument presented doesn't support the conclusion.
      The document says a P2P cache is likely to be much better connected to end hosts than to remote peers. The remote peers _are_ end hosts. What are you actually trying to distinguish here?
      Section 5.2 (Copyright and Legal Issues) puts filtering and DRM out of scope for this document. It would be better to say something like "is not in scope for the problem this document proposes solving".
    5. Sean Turner: Comment [2012-03-14]:
      I agree with Peter's thought about para 1 of s3 sounding a lot like marketing.
      I was surprised by the references to RFC 3414 in s5.4-5.7. Is that where the solution is expected to come from or where the definition came from? If it's the later wouldn't RFC 4949 be a better reference - it's the Internet Security Glossary, Version 2. Also are there any privacy considerations to be worried about?
      I also found myself thinking along the same lines as Ron and Robert.

    Telechat:

  4. An Overview of the IETF Network Management Standards (Informational)
    draft-ietf-opsawg-management-stds-06
    Token: Dan Romascanu
    Note: Christopher Liljenstolpe <ietf@cdl.asgaard.org> is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-opsawg-management-stds):
    1. Stewart Bryant: Discuss [2012-03-15]:
      This is a well written document and I support its publication.
      However I am concerned that it takes an inconsistent position WRT the dataplane.
      One the one hand it says "Note that this document does not cover OAM technologies on the data-path" but on the other hand it says:
      "The IPPM working group ... The metrics include connectivity, one-way delay and loss, round-trip delay and loss, delay variation, loss patterns, packet reordering, bulk transport capacity, and link bandwidth capacity."
      which is the sort of thing that we measure in data-plane OAM.
      The document needs to either provide an objective discussion of all data plane techniques, or it needs to be scrubbed of all data plane techniques.
      Similarly I am concerned that FCAPS makes no mention of OAM and yet many aspects of FCAPS are intimately bound to OAM.
      Similarly a discussion of active vs passive monitoring is incomplete without a discussion of OAM.
    2. Stewart Bryant: Comment [2012-03-15]:
      It is harmless but unusual to note that RFC2119 is not used.
      Why does the IPPM section not discuss the measurement of the convergence characteristics of networks?
    3. Wesley Eddy: Comment [2012-03-13]:
      I agree with many of Adrian's DISCUSS points.
      Other COMMENTs:
      (1) The last paragraph of section 1.2 should have at least some reference to an I-D or other document to indicate what the authors are talking about
      (2) Section 3.2 seems odd compared to the rest of the document, as the RFCs mentioned in this section are not management standards; several are just informational RFCs.
      (3) At the end of Section 3.4, it says that there are two protocols standardized, and then has three bullets underneath. I think the third bullet should be separated out, since its relation to OWAMP and TWAMP is not clearly explained here.
    4. Adrian Farrel: Discuss [2012-03-12]:
      I had some difficulty determining what are "IETF network management standards".
      The Introduction helpfully explains that "OAM technologies on the data-path" are not covered. I think this might usefully be mentioned in the Abstract.
      I found the lists of existing MIB modules in Section 4.1 a bit hit and miss.
      For example, in Section 4.1.2 only one of te GMPLS MIB module RFCs is listed. This is kind of "by example" of a data plane model, so is probably OK, but why not mention the MIB modules for the GMPLS control plane.
      In Section 4.1.3 I would have expected to see discussion of both the MPLS forwarding plane, and some of the MPLS control plane protcols. Conversely, I found it off-puting that Section 4.1.3 lumps together the routing protocols with the IP forwarding plane.
      Looking at Section 4.1 as a whole, I wondered whether you really want to enumerate the existing MIB modules for all IETF protocols. This seems like a thankless task and one that is hard to keep complete unless you go to the OID tree (in IANA) and make a full list.
      On the other hand, there are some technology-specific "MIB overview" documents that might provide useful things to point at. For example:
      - RFC 4221
      - draft-ietf-mpls-tp-mib-management-overview
      I'm finding this a hard one to make actionable! How about...
      Please use the OID tree in the IANA registry to ensure that you have not left out any MIB modules for key IETF protocols.
      Please consider including references to RFC 4221 and draft-ietf-mpls- tp-mib-management-overview.
      You might also find it beneficial to split 4.1 into forwarding plane management and control protocol management.
      Rather than removing Section 6, I think you should use it to summarise the secuirty issues of network management, point to the sections of this document that discuss security, and reference other documents specific to the security of network management.
      This might point to the fact that security discussions are patchy in this document. 2.1.4 is a good detailed cover of SNMP security, 2.2 briefly mentions how to secure syslog, and 2.3 has a rather scanty mention of security for ipfix. Why is there not similar discussion of how to secure netconf?
      Similarly, in section 3 there is mention of security for RADIUS, DIAMETER, CAPWAP, ANCP, and ACAP, but not for DHCP, BOOTP, the various autoconf options, COPS, and XCAP.
    5. Adrian Farrel: Comment [2012-03-12]:
      I think that a general change of s/MIB/MIB module/ is needed.
    6. Robert Sparks: Discuss [2012-03-13]:
      This document needs some minor adjustments to account for RFC6410 (Reducing the Standards Track to Two Maturity Levels), and to use the terms from 2026 correctly (The string "full standard" does not appear in 2026).
      The following two paragraphs seem out of place with the rest of the document:
      "With further information elements, IPFIX can also be applied to monitoring of application-level protocols, for example, Session Initiation Protocol (SIP) [RFC3261] and related media transfer protocols. Requirements to such a monitoring on the application level include measuring signaling quality (e.g., session request delay, session completion ratio, or hops for request), media Quality of Service (QoS) (e.g., jitter, delay or bit rate), and user experience (e.g., Mean Opinion Score).
      Note that even if the initial IPFIX focus has been around IP flow information exchange, non-IP-related information elements are now specified in IPFIX IANA registration (e.g. MAC (Media Access Control) address, MPLS (Multiprotocol Label Switching) labels, etc.). At the time of this writing, there are requests to widen the focus of IPFIX and to export also non-IP related information elements (such as SIP monitoring IEs)."
      The rest of the document discusses work in progress that's already well underway
      - this is more of a motivation for future work or an explanation that future work is possible. Why is it important for this document? I suggest just removing these two paragraphs, but if something like this really needs to be said, can it reference work in progress?

    Telechat:

  5. Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks (Informational)
    draft-ietf-multimob-igmp-mld-tuning-05
    Token: Jari Arkko
    Note: Behcet Sarikaya (sarikaya2012@gmail.com) is the document shepherd.
    Note: document is on the telechat 5 days before the LC ends. I'd like to complete this doc while I'm on the IESG, and handle additional last call comments (if any) in Paris IESG meeting. We'll hand it off to Brian if there's anything substantial.

    Discusses/comments (from ballot draft-ietf-multimob-igmp-mld-tuning):
    1. Stewart Bryant: Comment [2012-03-08]:
      No objection provisional on nothing bad being uncovered in IETF LC
    2. Adrian Farrel: Discuss [2012-03-14]:
      Discuss updated after email exchanges (some points are agreed and just need a revised I-D, some points still to be discussed to completion)
      I like this document: thank you. However, I have some small issues.
      I think the first of my Discuss issues is a small procedural question that can be resolved through process rather than changes to the document. Thus the actions should come from the AD, chairs, and shepherd.
      The subsequent issues are for the authors.
      The Shepherd write-up says... "(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why."
      "There have been no IPR disclosures filed on this document"
      This is not an answer to the question that was asked.
      To be precise in my question: have the authors been asked and confirmed that there is no IPR to be disclosed, or is the shepherd deducing this from the absence of dsiclosures?
      I don't understand the last sentence in Section 1: "The proposed behavior interoperates with the IGMPv3 and MLDv2 protocols."
      How could the behavior not interoperate with these protocols since you are directly describing the protocols?
      Maybe it would be better to replace this sentence with...
      "This document does not make any changes to the IGMPv3 and MLDv2 protocls and only suggests optimal settings for the configurable parameters of the protocols in mobile and wireless environments."
      Of course, if my suggested text is not true, we have a bigger issue to address :-)
      Is Appendix A normative? It includes advice and RFC2119 language. There is no reference to the Appendix from the body of the text, and no explanation in the Appendix itself as to why it is not in the main part of the document. Please clarify.
    3. Pete Resnick: Discuss [2012-03-14]:
      I feel more strongly than Robert about the status of this document. This is introducing particular protocol parameter values that will effect performance and interoperability of the protocol. The recommendations are put in the form of some 2119 language. And the shepherd report says that there was strong consensus behind the solution. I don't understand why it is not Standards Track.
    4. Pete Resnick: Comment [2012-03-14]:
      I very much agree with Adrian's DISCUSS related to asking authors about IPR. Please do.
      Both the ballot writeup and the shepherd report are really inadequate. "Nothing worth noting outside ordinary WG process" is not helpful at all to the rest of the IESG to understand the history of this document. The answers in the shepherd report really give little information. The one answer of any substance was where it says, "There is a strong consensus behind this solution." Again, that sounds like a reason for Standards Track.
      I agree that the Appendix should probably be in the main body.
      The 2119 language in this document has lots of problems and should be reviewed. Examples:
      3: "... a large number of the reply messages sent from all member hosts MAY cause network congestion or consume network bandwidth."
      "...messages MAY be lost during transmission."
      4.1: "This shorter interval contributes to quick synchronization of the membership information tracked by the router but MAY consume battery power of mobile hosts."
      MAY is for protocol options. None of these are protocol options. Almost none of the MAYs are used correctly.
      4.4. Tuning Startup Query Interval
      "The [Startup Query Interval] is the interval between General Queries sent by a Querier on startup. The default value is 1/4 of [Query Interval]; however, in this document it is RECOMMENDED that the use of its shortened value such as 1 second since the shorter value would contribute to shortening handover delay for mobile hosts in, e.g., the base solution with PMIPv6 [10]. Note that the [Startup Query Interval] is a static value and cannot be changed by any external signal. Therefore operators who maintain routers and wireless links MUST properly configure this value."
      The MUST here isn't specifying a protocol behavior. You probably mean "need to". But do you really mean that the value MUST be 1 second?
      4.6: "Thus the effects of the IGMP/MLD message transmission through a tunnel link SHOULD be considered during the parameter setting."
      What interoperability problem occurs if they are not considered? Instead of SHOULD, "ought to".
      6: "This document assumes that both multicast routers and mobile hosts MUST be IGMPv3/MLDv2 capable"
      That MUST isn't a directive for this document. Instead of "MUST be", "are".
    5. Robert Sparks: Comment [2012-03-13]:
      Did you consider PS for this document? Operational/interop experience might suggest changed values.
      Small thing: Consider pointing out that as you start talking about Max Resp Code values larger than 12.8 seconds, the exponential representation in 4.1.1 of RFC3376 kicks in so the granularity of changes you can indicate becomes coarser.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Secure PSK Authentication for IKE (Experimental)
    draft-harkins-ipsecme-spsk-auth-07
    Token: Sean Turner
    Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd.
    Discusses/comments (from ballot draft-harkins-ipsecme-spsk-auth):
    1. Adrian Farrel: Comment [2012-03-14]:
      I have no objection to the publiction of this document.
      I love the concept of "distilling entropy". This is, I think, really just hiding the absence of entropy, but I have no objection to the term being used in this document.
    2. Stephen Farrell: Discuss [2012-03-15]:
      #1 8.1 - why an 8-bit counter? that's usually wrong unless there's a reason to want it so short. In this case if len(r)~=len(p) then 3 in every 1000 IKE exchanges might not work with this scheme. While that might be ok for an experimental RFC, having to change it if this became a standard would be bad. I'd suggest a 16 bit counter or else providing a way to iterate until you do find a good ske-value. (If I'm right about the probability there.) The pseudo-code in 8.2.1 & 8.2.2 also need something to terminate their loops, e.g. "while (found == 0 && counter < limit )"
      #2 hunting and pecking: is this a potential timing attack vector for passphrases? If the answer is known then adding that to the security considerations seems warranted. If not, then just saying that that's for further study would be ok, but I think at least that is needed.
    3. Stephen Farrell: Comment [2012-03-15]:
      (12 items)
    4. Peter Saint-Andre: Comment [2012-03-08]:
      Section 6 states:
      "The first step of pre-processing is to remove ambiguities that may arise due to internationalization. Each character-based password or passphrase MUST be pre-processed to remove that ambiguity by processing the character-based password or passphrase according to the rules of the [RFC4013] profile of [RFC3454]."
      Please be aware there there is work underway to obsolete RFC 3454 and RFC 4013, primarily because stringprep is limited to Unicode 3.2; see draft-melnikov-precis-saslprepbis. This is just a heads-up, and I'm not necessarily suggesting that you change the text to something like "use RFC 4013 or equivalent". However, when your experiment is done and you put this on the standards track, you'll probably be asked to update the internationalization to use saslprepbis (if the PRECIS WG finishes before your experiment does!).

    Telechat:

  2. Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 (Experimental)
    draft-shin-augmented-pake-14
    Token: Sean Turner
    Note: Paul Hoffman is the document shepherd (paul.hoffman@vpnc.org).
    IPR: National Institute of Advanced Industrial Science and Technology (AIST)'s Statement about IPR related to draft-shin-augmented-pake-00 (1)
    IPR: National Institute of Advanced Industrial Science and Technology (AIST)'s Statement about IPR related to draft-shin-augmented-pake-00 (2)
    Discusses/comments (from ballot draft-shin-augmented-pake):
    1. Stephen Farrell: Comment [2012-03-15]:
      - section 2.2.1 could badly do with some examples if that's possible. I'd expect interop problems in any case, but more without that. Those might be shared with the other scheme drafts.
      - Section 2, last paragraph - that's confusing - which Y and K calculation is to be done? I think you need to be much clearer about this.
      - saying "server S does not store any plaintext passwords" is missing 2119 language. While a MUST would be most correct, perhaps a SHOULD is right, in case someone wants to do this using an existing DB of cleartext passwords.
      - Providing a reference for "Shamir's trick" would be good.
    2. Peter Saint-Andre: Comment [2012-03-08]:
      Both draft-harkins-ipsecme-spsk-auth and draft-kuegler-ipsecme-pace-ikev2 specify that the password will be prepared using SASLprep (RFC 4013). Why doesn't this specification also define how 'w' is prepared for input to other operations?

    Telechat:

  3. Password Authenticated Connection Establishment with IKEv2 (Experimental)
    draft-kuegler-ipsecme-pace-ikev2-08
    Token: Sean Turner
    Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd.
    Discusses/comments (from ballot draft-kuegler-ipsecme-pace-ikev2):
    1. Stephen Farrell: Comment [2012-03-15]:
      - I found the overall description of PACE hard to follow, it'd be better if you gave the MODP method for mapping s in the overview so that someone who just knows standard D-H can see why this is a ZKPP.
      - "free of patents" is not possible, and not really appropriate as a claim in an RFC
      - section 5.1 could badly do with some examples if that's possible. I'd expect interop problems in any case, but more without that. Those might be shared with the other scheme drafts.
      - [I-D.kivinen-ipsecme-secure-password-framework] is now an RFC
      - s2, point 1: don't just say that a value encrypted with the password (ENONCE) is sent to the responder, since that'd in general be vulnerable to off-line dictionary attacks. Maybe say that ENONCE is ok to send because it is specially constructed so as not to expose anything about the password.
      - "MUST be presisted to stable memory" might be too onerous, I'd say a SHOULD would be better there in case someone has to use an existing DB of shared secrets.
      - The LongTermSecret scheme seems to be independent of PACE so I wondered why its here and not in a document of its own.
      - 4.1 seems to call for a table of mappings from authenticated ciphers to the unauthenticated equivalents, otherwise interop is not likely. I think you need to provide those mappings (or at least some) and ideally ask IANA to create a registry for others (it'd be needed if this got onto the standards track later).
    2. Peter Saint-Andre: Comment [2012-03-08]:
      Section 5.1 states: "The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]."
      Why or when would an implementation violate the SHOULD? That is, why is this not a MUST? Also, please be aware there there is work underway to obsolete RFC 3454 and RFC 4013, primarily because stringprep is limited to Unicode 3.2; see draft-melnikov-precis-saslprepbis. This is just a heads-up, and I'm not necessarily suggesting that you change the text to something like "use RFC 4013 or equivalent". However, when your experiment is done and you put this on the standards track, you'll probably be asked to update the internationalization to use saslprepbis (if the PRECIS WG finishes before your experiment does!).

    Telechat:

  4. Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6) (Informational)
    draft-garcia-shim6-applicability-03
    Token: Jari Arkko
    Discusses/comments (from ballot draft-garcia-shim6-applicability):
    1. Stewart Bryant: Comment [2012-03-07]:
      As a courtesy to the RFC Editor, the authors should scrub the document for terms not expanded on first use.
    2. Adrian Farrel: Comment [2012-03-15]:
      The first two paragraphs of the Security section reads oddly.
      Suggest:
      OLD: "This section considers the applicability of the Shim6 protocol from a security perspective, i.e. which security features can expect applications and users of the Shim6 protocol.
      "First of all, it should be noted that the Shim6 protocol is not a security protocol, like for instance HIP."
      NEW: "This section considers the applicability of the Shim6 protocol from a security perspective, i.e. which security features can be expected by applications and users of the Shim6 protocol.
      "First of all, it should be noted that the Shim6 protocol is not a security protocol, unlike for instance HIP."
    3. Stephen Farrell: Comment [2012-03-09]:
      - I wondered how IPsec was affected by or affects shim6. Figure 3 didn't really tell me.
      - Section 3.3 seems a bit odd - why do you want to control CGA parameters via DHCP? (That's also the subject of a discuss on ietf-csi-dhcpv6-cga-ps.) Its also not the case (is it?) that private key information is ever exchanged like this. Similarly with 3.4. Could both these sections not actually just be deleted?
    4. Russ Housley: Discuss [2012-03-13]:
      The Gen-ART Review by Joel Halpern on 18-Feb-2012 raised several concerns, and there seems to be agreement on the nature of the changes to the document that are needed. Yet, the changes have not been made yet.
    5. Sean Turner: Comment [2012-03-14]:
      I like the edits agreed as a result of Stephen's comments.

    Telechat:

  5. The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect) (Experimental)
    draft-reschke-http-status-308-06
    Token: Peter Saint-Andre
    Note: Cyrus Daboo (cyrus@daboo.name) is the document shepherd.
    Discusses/comments (from ballot draft-reschke-http-status-308):
    1. Wesley Eddy: Comment [2012-03-11]:
      The writeup doesn't mention why this isn't just part of the httpbis specifications, since it was apparently fine with the working group and received positive comments there. Why did it have to be done as AD-sponsored, and why is the target Experimental?
    2. Adrian Farrel: Comment [2012-03-12]:
      I have no objection to the publication of this document.
      In section 3 you have "ought". It might be nice to use a RFC 2119 word for this.
      Section 3 also contains two instances of "SHOULD". It would be good to explain (often a "MAY") why these are not "MUST". (I think the exsiting "MAY" applies as a varience to the "ought".)

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. "Gateway-Initiated" 6rd (Informational)
    draft-tsou-softwire-gwinit-6rd-06
    Token: Ralph Droms
    Note: The IESG has concluded that this work is related to IETF work done
    in the softwire WG, but this relationship does not prevent publishing.
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-tsou-softwire-gwinit-6rd-05
    Discusses/comments (from ballot draft-tsou-softwire-gwinit-6rd):
    1. (none)

    Telechat:

3.3.2 Returning Items

  1. (none)

1329 EDT no break

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. INtermediary-safe SIP session ID (insipid)
    Token: Gonzalo

    Telechat:

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. Make all IETF e-mail and web point to tools or datatracker urls (Jari Arkko)

    Telechat:

  2. text/jcr-cnd media type (Peter Saint-Andre)

    Telechat:

7. Agenda Working Group News

1405 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

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

draft-ietf-core-link-format

  1. Jari Arkko: Discuss [2012-03-11]:
    This is a well written document, thank you for doing it. I have a small problem
    with the ABNF, however, see below for the details. Perhaps this video also
    illustrates my point:
    
    http://www.youtube.com/watch?feature=player_embedded&v=LbK-g8tKnoc
    
  2. Jari Arkko: Comment [2012-03-11]:
    Bill's ABNF parser suggests this change:
    
    OLD:
          cardinal          = "0" / %x31-39 *DIGIT
    NEW:
          cardinal          = "0" / ( %x31-39 *DIGIT )
    
    Also:
    
       The CoRE link format is the [RFC5988] production named "Link", and
       imports the ABNF description and associated rules in Section 5 of
       that document.  The "Link:" text is omitted as that is part of the
       HTTP Link Header.  Note that the ABNF in the present document is
       compliant with [RFC5234].
    
    This was very misleading to me, it took a while to realize that RFC 5988
    uses the RFC 2616 ABNF, which is different from RFC 5234 ABNF.
    Simply copying the ABNF from various RFCs into a file and compiling 
    or verifying the ABNF will not work. Also, the actual definition of Link 
    does not use the string "Link:" literally:
    
      Link           = "Link" ":" #link-value
    
    I would suggest a rewrite as follows:
    
       The CoRE link format is the [RFC5988] ABNF production named
       "Link". This specification imports the ABNF from Section 5 of
       [RFC5988]. However, that ABNF has been defined using the
       format and auxiliary productions defined in [RFC2616] whereas
       the present document uses ABNF as defined in [RFC5234]. As a
       result, for the purposes of the present document, the [RFC5988]
       ABNF needs to be understood as if it were written in [RFC5234]
       form.
    
       In addition, for the purposes of CoRE link format, the "Link:" text
       is omitted as [RFC5988] used it only for the HTTP Link Header.
       As a result, for CoRE link type, the [RFC5988] "Link" production
       should be defined as follows:
    
       Link = link-value-list
       link-value-list = [ link-value *[ "," link-value ]]
       ;  link-value is as defined in [RFC5988]
  3. Ralph Droms: Comment [2012-03-12]:
    One minor editorial suggestion: in the Introduction,
    RFC 4919 might be a better general reference for
    "6LoWPAN" than RFC 4944.
  4. Stephen Farrell: Comment [2012-03-11]:
    - Richard Barnes' secdir review suggested text for section 6 about
    authorization that the author seems to like, so this is just to note
    that until its fixed.
    
    - I'd also suggest adding the following to Richard's suggest text:
    "While such servers might not return all links to all requesters, not
    providing the link does not, by itsef, control access to the relevant
    resource - a bad actor could know or guess the right URIs."
    
    - I'd also suggest adding something about servers that might tell
    lies to feed bad data to clients, e.g. "Servers can lie about the
    resources available. If it is important for a client to only get
    information from a known source, then that source needs to be
    authenticated."
  5. Russ Housley: Discuss [2012-03-09]:
    
      The Gen-ART Review by Joel Halpern on 18-Feb 2012 raised a question
      that still needs to be resolved in the document.  Joel asked:
      >
      > What is the registration / collision avoidance strategy for resource
      > type (rt) and interface description (if) values?  They are both
      > defined as opaque strings which can happen to be URIs.  So there
      > seems to be potential for collision.
      >
      The author indicates that two separate IANA registries for rt and if
      types are fine with him, but this is not reflected in the document.
    
  6. Pete Resnick: Comment [2012-03-09]:
    Only stylistic nits. Otherwise no problems.
    
    I find the questions in section 1.1 a poor writing style and suggest they be
    removed.
    
    The first sentence of section 6: "This document needs the same security
    considerations...". Please change "needs" to "has".
  7. Sean Turner: Comment [2012-03-14]:
    s3.2 Any chance for an actual size for the reasonable size limit?

draft-ietf-marf-dkim-reporting

  1. Jari Arkko: Discuss [2012-03-15]:
    I can not believe I am doing this again for the third time this week, but:
    
    http://www.youtube.com/watch?v=LbK-g8tKnoc
    
  2. Jari Arkko: Comment [2012-03-15]:
           rep-rr-tag = %x72.72 *WSP "=" *WSP rep-rr-type
                        *WSP 0* ( ":" *WSP rep-rr-type )
    
    Bill's parser (http://tools.ietf.org/tools/bap/abnf.cgi) says: 
    
    stdin(1:28): error: No whitespace allowed between repeat and element.
    
    There are two instances of this error in the draft.
  3. Adrian Farrel: Comment [2012-03-13]:
    Thanks for handling my Discuss and Comments
  4. Stephen Farrell: Comment [2012-03-12]:
    Thanks for handling my discuss points.
  5. Peter Saint-Andre: Comment [2012-03-08]:
    Section 3.2 states:
    
       Any tag found in the content of this record that is not registered
       with IANA as described in Section 7.3 MUST be ignored.
    
    Does this really need to be "MUST", or is "SHOULD" sufficient? Saying MUST would
    prevent any further experimentation, which you might consider a good thing or a
    bad thing.
  6. Sean Turner: Discuss [2012-03-14]:
    Is the assumption here that the report-generator/DKIM-verifier also supports
    DKIM-signing and will send the report back DKIM-signed?  If that's true
    shouldn't there be some kind of requirement that the DKIM l= value MUST cover
    the entire report body?  Or, do you think folks will do that by default because
    that's the l= default in RFC 6376?  And, would it be better to state a
    requirement that returned reports MUST be DKIM-signed?
    
  7. Sean Turner: Comment [2012-03-14]:
    s2.4: r/entitiy/entity

draft-ietf-marf-spf-reporting

  1. Adrian Farrel: Comment [2012-03-13]:
    I have no objection to the publication of this document.
    
    Very trivial nits...
    
    It would be nice if the Introduction carried exapnsions of the terms
    ARF and SPF as found in the Abstract.
    
    ---
    
    In the Intoduction...
    
       This document additionally creates a an IANA registry of [SPF] record
       modifiers to avoid modifier namespace collisions.
    
    ...should not use square brackets, I think.
    
    ---
    
    I think you should really include a reference to the place where your
    ABNF is defined, and point to this from Section 2.
    
    ---
    
    You don't need to use RFC 2119 langauge in Section 5.
  2. Stephen Farrell: Comment [2012-03-11]:
    - s3, is "unauthorized routing" the right term for what causes an SPF
    fail?
    
    - s3, "rr=all" as the default - depending on how the discuss on the
    marf dkim draft is resolved there might be a similar change needed
    here.
  3. Sean Turner: Comment [2012-03-14]:
    s6.1: r/SPF SPF/SPF
    
    s6.1: missing the closing ) in the last para.

draft-ietf-appsawg-xdash

  1. Ralph Droms: Comment [2012-03-12]:
    This text:
    
    2.  Recommendations for Implementers of Application Protocols
    
       Implementers of application protocols MUST NOT treat the general
       categories of "standard" and "non-standard" parameters in
       programatically different ways within their applications.
    
    while probably not harmful, is sufficiently vague and refers to
    undefined terms in a way as to contribute, perhaps, more confusion
    than value.
  2. Dan Romascanu: Comment [2012-03-15]:
    I agree with Ralph terminology comment. I also find confusing the repeated usage
    of the phrase 'deprecating a convention (or construct)' where in fact there is
    no specific place in standard-track or BCP RFCs where such a convention or
    construct was clearly articulated. I would have found more clear if instead of
    this the document would have pointed to an explicit list of conventions or
    constructs that are NOT RECOMMENDED.

draft-ietf-adslmib-gbond-mib

  1. Adrian Farrel: Comment [2012-03-15]:
    I have no objection to the publication of this document.
    
    I have a number of small Comments. They are non-blocking and you can
    take them or leave them
    
    ---
    
    The shepherd write-up appears to disagree with the ballot write-up wrt
    implementations. I choose to believe the shepherd not the AD since the
    shepherd gives better news!
    
    ---
    
    It is not necessary to say the document "proposes". You can say 
    "defines".
    
    ---
    
    Thanks for the detail in Section 4. It really helps.
    
    ---                                                          
    
    Question for you. How likely is it that new bonding schemes (i.e. other
    technologies) will come along and be handled by this MIB module without
    extensions? I think the intention is that this module is technology-
    independent, so that it would not need to be revised for a new bonding
    type.
    
    However, GBondSchemeList and GBondScheme are closed lists such that you
    would need to revise the module to support new technologies. That seems
    a shame.
    
    You could move the TCs into a separate module so that only that module
    needs to be revised.
    
    An alternative, is to define an IANA Textual convention for this and
    allow just the TC to be updated as necessary.
                             
    ---                     
    
    I find the presence of 'unknown' as a bit in GBondSchemeList to be a bit
    odd. In general, bits in an object with a Syntax of Bits can be 
    independently set. But here you could not set 'unknown' and any of the
    other bits.
    
    On the other hand, what would it mean to return the object with none of
    the bits set? Is that different from returning the 'unknown' bit?
    
    ---
    
    gBondLowUpRateCrossing Description
    s/port'/port's/
  2. Pete Resnick: Comment [2012-03-12]:
    Please update the document writeup and shepherd report to include information
    about review and implementation.
  3. Peter Saint-Andre: Comment [2012-03-12]:
    You might consider adding informational references for NTP and SNTP.

draft-ietf-adslmib-gbond-atm-mib

  1. Stephen Farrell: Comment [2012-03-09]:
    Just wondering: Could access to gBondAtmPortPmCur1DayUpDiffDelay
    or similar measurements extend the reach of timing-based attacks on
    cryptographic protocols? That is, if I could do a timing attack
    on a node from its next hop router, access to this data might then
    allow me to mount the same attack from further away. I guess in
    principle that might increase the sensitivity of some of these
    real-time measurements, however, its probably too low a probability
    to make any change worthwhile and even if it was worthwhile to
    note somewhere, it probably wouldn't be here.

draft-ietf-adslmib-gbond-eth-mib

  1. Adrian Farrel: Discuss [2012-03-15]:
    This is a procedural Discuss that I am holding while I have a question
    outstanding to the liaison to IEEE. I do not have any action for the 
    document authors, and expect to be able to clear the Discuss when I have
    the answer.
    

draft-ietf-adslmib-gbond-tdim-mib

  1. (none)

draft-ietf-tsvwg-source-quench

  1. Adrian Farrel: Comment [2012-03-14]:
    Thank you for this document. Clear and well constructed.
    
    I did wonder whether RFC 1016 should be moved to Historic at this time.
  2. Pete Resnick: Comment [2012-03-09]:
    A document so clear that I feel comfortable balloting "Yes", even if it's not in
    my area.
  3. Dan Romascanu: Comment [2012-03-14]:
    This is probably late in the process, but I think that such a document should
    have been last-called with the OPSAWG as well and also with some of the
    operators fora, to make sure that there are no critical operator tools depending
    on the deprecated option, and for the operators to have a prior warning about
    the changes in the implementations resulting from the approval of this update.
  4. Peter Saint-Andre: Comment [2012-03-08]:
    I found a minor error:
    
       o  Processing of ICMP Source Quench messages by routers has been
          deprecated for more than 20 years [RFC1812].
    
    Actually, it's less than 17 years: RFC 1812 was published in June 1995.

draft-ietf-pwe3-packet-pw

  1. Stewart Bryant: Comment [2012-03-05]:
    Previous Abstain position was a mouse error.
  2. Pete Resnick: Comment [2012-03-11]:
    Sometimes I feel like people do fun things with 2119 language entirely for my
    entertainment when it's a document outside of my area. :-)
    
    Seriously, these are all simply comments that I think will improve the
    comprehensibility of the document. I hope they help.
    
    Section 1:
    
       Where the client equipment is connected to the server equipment via a
       physical interface, the same data-link type MUST be used to attach
       the clients to the Provider Edge equipments (PE)s, and a pseudowire
       (PW) of the same type as the data-link MUST be used [RFC3985].
    
    Something is odd here. RFC3985 is Informational and is not a normative
    reference, and it doesn't include any MUSTs, so those requirements can't be
    coming from 3985 per se. And I suspect they are not new requirements in this
    document at all. Do you actually mean the following?
    
       The architecture in [RFC3985] says that, where the client equipment
       is connected to the server equipment via a physical interface, the
       same data-link type will be used to attach the clients to the Provider
       Edge (PE) equipment, and a pseudowire (PW) of the same type as
       the data-link will be used.
    
    Also in Section 1:
    
       Non-normative Appendix Appendix A provides information...
    
    This verbal tic of inserting the words "non-normative" I find completely silly.
    It is absolutely clear from the contents of the appendix that it is non-
    normative, and we're heading down the path where sections will be titled, "Non-
    normative Table of Contents" and "Non-normative Acknowledgements". Please remove
    those words.
    
    Section 5:
    
       The PEs MAY use a local Ethernet address for the Ethernet header used
       to encapsulate the client network layer packet.  Alternatively the
       PEs may use the following procedure.
    
    I found the above confusing. The first "procedure" after this is an IANA
    procedure, and the "may" there looks like it should be a "MAY". Perhaps instead:
    
       The PEs MAY use a local Ethernet address for the Ethernet header used
       to encapsulate the client network layer packet, or MAY use one of the
       special Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as
       described below.
    
    Also in section 5:
    
       IANA are requested to allocate two unicast Ethernet addresses
       [RFC5342] to this protocol (PacketPWEthA and PacketPWEthB).
       PacketPWEthA is the value lower Ethernet address and PacketPWEthB is
       the higher value Ethernet address.  Where [RFC4447] signalling is
       used to set up the PW, the LDP peers compare IP addresses and with
       the PE with the higher IP address uses PacketPWEthA, whilst the LDP
       peer with the lower IP address uses PacketPWEthB.
    
    Very awkwardly worded and confusing to me. Instead maybe:
    
       IANA is requested to allocate [ed note: RFC Editor will change to
       "has allocated"] two unicast Ethernet addresses [RFC5342] for use
       with this protocol, referred to as "PacketPWEthA" and
       "PacketPWEthB". Where [RFC4447] signalling is used to set up the PW,
       the LDP peers numerically compare their IP addresses. The LDP PE
       with the higher value IP address will use PacketPWEthA, whilst the
       LDP peer with the lower value IP address uses PacketPWEthB.
    
    Also in section 5:
    
       Not withstanding the fact that this PW represents a point-to-point
       connection, some client layer protocols require the use of a
       destination multicast address in the Ethernet encapsulation.  This
       mode of operation MUST be supported.
    
    The passive voice in the last sentence is problematic. Do you mean, "Peers MUST
    be prepared to handle a destination mulitcast address in the Ethernet
    encapsulation"?
    
    Section 6:
    
       Thus, for example, the Ethernet OAM is NOT REQUIRED.
    
    "NOT REQUIRED" is not a 2119 term. I think you might mean "Thus, for example, a
    server LSR MAY choose not to use Ethernet OAM". Or you might simply mean "not
    required".
    
    Appendix A:
    
       This appendix is non-normative.
    
    Please strike.
  3. Dan Romascanu: Comment [2012-03-13]:
    1. In the Abstract s/is the case/in the case/
    
    2. In Section 6 - VLANs, 802.1p and 802.1Q are not Ethernet but bridging
    fucntions
    
    So I suggest the following changes: 
    
    in the title s/Ethernet/Ethernet and IEEE 802.1/
    
    and: 
    
    OLD: 
    
    The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q
       between PEs is not supported.
    
    NEW: 
    
    The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q 
       between PEs is not supported.
    
    Maybe adding 'tagging' after 802.1Q would help if this is the intent.

draft-ietf-ipfix-rfc5815bis

  1. Russ Housley: Discuss [2012-03-13]:
    
      The Gen-ART Review by Joel Halpern on 23-Feb-2012 raised several small
      concerns.  Each individual one is minor, but taken together, they are
      sufficiently confusing that I would like to see them resolved.
    
      Joel's review includes these three concerns:
      >
      > The description in the first paragraph of 5.2 on the Template table
      > is written in such a way as to lead the reader to think the
      > Observation Domain is somehow associated with the Transport Session
      > (which table provides the device mode which is discussed in that
      > text.)  Could you split the Observation Domain reference out to a
      > separate sentence (possibly before the reference to the Transport
      > Session)?
      >
      > In the example of the export table in section 5.4, there are two
      > blocks of export entries, on with ipfixExportIndex 7, and one 
      > with 8. They are mirrors of each other except that they reverse
      > which transport session is primary, and which is secondary.
      > There is no explanation of why both are present.  And there is
      > no explanation of why the settings in index 7 are used, rather
      > than those in index 8.
      >
      > If you define an Observation Point with 0 for both Physical Entity
      > and Physical Interface, what is it observing?  Similarly, what is a
      > metering process metering if its Observation Point Group Ref is 0?
    
  2. Pete Resnick: Comment [2012-03-11]:
    This document appears to Obsolete RFC 5815, but that is not indicated anywhere
    in the document, nor in the header.
    
    This appears to be simply errata fixes from 5815. Is there a reason it is
    recycling at Proposed rather than advancing to Internet Standard?
  3. Sean Turner: Comment [2012-03-12]:
    s1: Not sure you need the MUST/MAY in the following because they're not telling
    me much:
    
     Most of the objects defined by the IPFIX MIB module MUST
     be implemented.  Some objects MAY be implemented corresponding to the
     functionality implemented in the equipment.

draft-ietf-mediactrl-6231-iana

  1. Pete Resnick: Comment [2012-03-09]:
    Not important enough to hold up publication of this very simple document for
    even a second, and this is mostly for IESG discussion, but: Is Standards Track
    appropriate for this document? Seems like even Informational would do.
  2. Peter Saint-Andre: Comment [2012-03-08]:
    Section 3 does not specify the name for the registry. One could assume that it
    is the "MEDIACTRL Interactive Voice Response Control Package Registry", but it
    would be good to make that clear.
  3. Sean Turner: Comment [2012-03-12]:
    To avoid any possibility of transcription errors couldn't you just point to
    Table 1 in RFC 6231 from s3?

draft-ietf-pcn-3-in-1-encoding

  1. Ronald Bonica: Discuss [2012-03-14]:
    I am confuse about why this document is being published on the Standards Track
    as opposed to EXPERIMENTAL. The two documents that describe how these markings
    are used are both EXPERIMENTAL. Why not this one, too?
    
  2. Adrian Farrel: Discuss [2012-02-29]:
    It appears that there are a number of alternative encoding being 
    proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding, 
    draft-ietf-pcn-psdm-encoding, etc., and as discussed in 
    draft-ietf-pcn-encoding-comparison. It isn't clear to me whether these
    encodings are being proposed to co-exist, to be used by different 
    operators depending on specific environments, or whether they are being
    floated to see which one gets more market-place support.
    
    In the latter case, I would have thought that the encoding documents 
    would have been Experimental.
    
    I might also have expected some mention of the other I-Ds if all of 
    the solutions are to be completed by the WG.
    
    ---
    
    I think [I-D.ietf-pcn-sm-edge-behaviour] and 
    [I-D.ietf-pcn-cl-edge-behaviour] are used normatively.
    
    ---                                                                 
    
    Section 4.3 has
    
       It may not be possible to upgrade every pre-RFC6040 tunnel endpoint
       within a PCN-domain.  In such circumstances a limited version of the
       3-in-1 encoding can still be used but only under the following
       stringent condition.  If any pre-RFC6040 tunnel endpoint exists
       within a PCN-domain then every PCN-node in the PCN-domain MUST be
       configured so that it never sets the ThM codepoint.  PCN-interior
       nodes in this case MUST solely use the Excess Traffic marking
       function, as defined in Section 5.2.3.1.  
    
    I completely get this, but I am worried about accidents. What happens if
    the operator thinks that they have upgraded all of the nodes, but have
    actually missed one?
    
    And then...
    
       In all other situations
       where legacy tunnel endpoints might be present within the PCN domain,
       the 3-in-1 encoding is not applicable.
    
    But what happens if an attempt is made to use it?
    
    In both cases, it is OK (probably/possibly) that the traffic using
    3-in-1 will have problems, but quite another thing if other traffic is
    impacted (for example, traffic using pre6040 tunnel endpoints. Can you
    add text to say what happens?
    
    ---
    
    Section 5.1
    
       If a PCN-packet arrives at the PCN-ingress-node with its ECN field
       already set to a value other than not-ECT, then appropriate action
       MUST be taken to meet the requirements of [RFC4774].  The simplest
       appropriate action is to just drop such packets.  However, this is a
       drastic action that an operator may feel is undesirable.  Appendix B
       provides more information and summarises other alternative actions
       that might be taken.
    
    This is a protocol spec that tells implementers what to build. You can't
    leave the behavior open like this.
    
    At the very least you need to give a default behavior, state the other
    possible behaviors, amke it clear which MUST be implemented, and require
    a configuration option such that the operator can select.
    
    BTW, a spec that says that "appropriate action MUST be taken" is not
    helpful on two counts:
    
    1. What action is appropriate?
    2. Who MUST take the action?
    
  3. Adrian Farrel: Comment [2012-02-29]:
    This document (6.2) implies that 5696 was never built or deployed. The
    shepherd write-up doesn't mention any implementations or plans to
    implement.
    
    It is undeniable that the WG is chartered to work on this, but it is
    unclear to me why this is Standards Track not Experimental if there
    are no implementations
    
    ---
    
    I wish the (current) limitation of applicability to IP-only networks 
    that is correctly noted at the end of the Introduciton was also noted in
    the Abstract.
    
    ---
    
    Section 1
    
       The full version of this encoding requires any tunnel endpoint within
       the PCN-domain to support the normal tunnelling rules defined in
       [RFC6040].
    
    Could you clarify whether "this encoding" means "the encoding described 
    in this document" or "the encoding described in RFC 5696" (or somehting
    different).
    
    ---
    
    Section 3 begins...
    
       The 3-in-1 PCN encoding scheme allows for two or three PCN-marking
       states to be encoded within the IP header.
    
    Hmmm. Does it allow 2 or 3 states to be encoded?
    I think it allows 3, but in some cases you only need 2. So how about...
    
    ...supports foo that needs two PCN-marking states, and also bar that 
       needs three PCN-marking states.
    
    ---
    
    Section 4.1
    
       PCN-
       ingress-nodes mark them as Not-marked (PCN-colouring)
    
    As the poster says: Defense d'afficher
    
    ---
    
    I thin kyou can safely dispose of Section 9.
    
    ---
    
    I would have liked to see more discssion in a single place about 
    interactions with management. There are several places where alarms or
    notifications are discussed and quite a number of things that are 
    configurable.
    
    There is also the question of how a PCN system may be diagnosed.
    
    Your AD may be able to point you at an RFC that provides guidance :-)
  4. Stephen Farrell: Comment [2012-02-28]:
    The acronym PHB is used but not defined.
  5. Pete Resnick: Comment [2012-03-11]:
    "emphatically NOT RECOMMENDED" looks kinda like a cool new 2119 term, but it's
    not defined there and probably shouldn't be used. (I note that it isn't
    capitalized in Appendix B.) Maybe better would be "Implementation SHOULD NOT
    engage in this behavior except in the most extreme circumstances because..."
    
    "This appendix is informative, not normative." I find this sentence to be an
    increasingly used verbal tic in documents. I think it's useless and should be
    removed. In the case of Appendix A, you already say at the end that "operators
    are ultimately free to" use PCN or not. In Appendix B, you remind the reader
    that in the event of a conflict between the appendix and the rest of the
    document, implementations should follow the guidelines in the rest of the
    document. This "informative vs. normative" distinction is just jargon that isn't
    necessary.

draft-desruisseaux-caldav-sched

  1. Jari Arkko: Discuss [2012-03-11]:
    This is a well written document, thanks for writing it. I have a small problem
    with the ABNF, however, please see below for further details and correct as you
    see necessary. Perhaps this video also illustrates my point:
    
    http://www.youtube.com/watch?feature=player_embedded&v=LbK-g8tKnoc
    
  2. Jari Arkko: Comment [2012-03-11]:
    Section 7.1 and 7.2 ABNF definitions should point out that "x-name" and
    "iana-token" definitions are from RF 5545, just as Section 7.3 does for
    other definitions. It took a while for me to search where this definitions are,
    particularly when the RFC series has multiple different definitions for
    these two productions.
  3. Stephen Farrell: Comment [2012-03-11]:
    - Thanks for handling Klaas Wierenga's good secdir review so well and
    quickly!
    
    - 3.2.2.1 says the server "MUST allow" but later says how the server
    can return errors if e.g. the client hasn't permission for the change
    requested. It might be better to say at the top that "The server MUST
    be able to allow Attendees to:"
    
    - 3.2.3 says its about HTTP methods, but uses webdav methods as well
    (e.g. COPY, MOVE) so maybe a reference to rfc 4918 would be useful at
    the start here?  (Or wherever is best to go for those.)
    
    - I guess this is maybe not too likely but just to check. If a client
    guesses a UID to try find out who's up to what, 3.2.4.1 says the
    server SHOULD return the URL if there is a collision. I wondered
    whether that URL might expose some information, in which case the
    question is whether such UIDs are easily guessed or not.  If such
    UIDs can be guessable, then maybe say something to the effect that
    the server might want to not return URLs that might expose details of
    the events (if such exist) and might want to return an innocuous
    error. Or better might be to RECOMMNEND that the UIDs (and URLs as
    well maybe) used for this be hard to guess. Note that the attack here
    (if it exists) could come from an authenticated client as well as
    from the Internet.  The point here is to check that the UIDs don't
    allow me to get at information for which I'd get only 403 if I sent a
    request to the URL. (I guess its a separate question as to whether
    sending 403 gives away something that a 404 doesn't, but if so,
    that'd be for another day and draft.)
    
    - In 7.x sections you say clients MUST NOT include these parameters.
    Is there a need to say that server MUST NOT accept messages from
    (bad) clients that do in fact contain these parameters? Might be easy
    enough to get wrong if the server developer didn't pay any attention
    to what the client developer might get or do wrong.
  4. Pete Resnick: Comment [2012-03-14]:
    Generally: I think the 2119 language could use a good scrub. I think you use it
    in places where there is no real option, or there is no real interoperability
    implication. Please review.
    
    Section 3.2.8:
    
       Servers MUST reset the "PARTSTAT" property parameter value of all
       "ATTENDEE" properties, except the one that corresponds to the
       Organizer, to "NEEDS-ACTION" when the Organizer reschedules an event.
    
    Don't you mean for all "ATTENDEE" properties *on each affected component*? I
    wouldn't have complained about this except for the MUST; if it's a requirement,
    you've got to be clear. If the change is for a recurrence instance that does not
    include that attendee, PARTSTAT shouldn't be reset, correct? (See section
    3.2.6.)

draft-mcgrew-tls-aes-ccm

  1. Stephen Farrell: Comment [2012-03-11]:
    A few easily fixed, but worth fixing, near-nits:
    
    1. RFC 5288 names ciphersuites such as
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 but this draft uses
    TLS_RSA_DHE_WITH_AES_256_CCM. Why change the order from DHE_RSA to
    RSA_DHE? If there's no good reason then maybe sticking with DHE_RSA
    would be better since it'd help with ordered lists and searches when
    folks want to find out how to do stuff. 
    
    2. Even if you don't change these names (as above), the reference to
    RSA-DHE being in 5288 should probably be fixed since that string
    doesn't occur in 5288, where DHE_RSA is used, as in 5246.
    
    3. This draft says the RSA and RSA-DHE key exchanges are defined in
    5288, but 5288 says that the RSA and DHE_RSA key exchanges are
    defined in 5246. Why the 2nd indirection?
    
    4. Section 4 has no reference to RFC 4279 which is where PSK stuff is
    really defined. I think adding that would be good.
    
    5. As above, the ciphersuite naming could be made more consistent.
    RFC 4279 defines TLS_DHE_PSK_WITH_AES_256_CBC_SHA whereas this draft
    defines TLS_PSK_DHE_WITH_AES_256_CCM. 
    
    6. Section 5 could be more clear about why its a bad idea to
    negotiate these ciphersuites with TLS 1.1 and below. A pointer to a
    reference or a short sentence should be enough, just so developers
    don't ignore this so easily. (It'd maybe be easy to get this wrong for
    a developer with a TLS1.1 library on a constrained device who's
    nervous about moving to TLS1.2.)
    
    And one that's maybe less easily fixed:
    
    7. Clients using these ciphersuites will not be able to work with
    random TLS servers on the Internet for quite a while. Would it be
    worth noting that, so that we don't mis-direct constrained node
    developers or other SDOs into selecting these in the expectation that
    they will get the same level of interop as with the ciphersuites that
    are actually used in the wild? I say that accepting that there are
    real benefits to these ciphersuites for such clients, but the lack of
    interop is also a real downside, and one that not all the relevant
    folks seem to appreciate. (Even if we prefer authenticated
    encryption and more optimal ciphersuites for constrained nodes,
    that can force use of hop-by-hop security via some gateway
    in which case we're no long clearly winning overall.)
    
    And finally a non-actionable lament:-)
    
    7. Isn't it a pity 330 ciphersuites wasn't enough already.
  2. Peter Saint-Andre: Comment [2012-03-12]:
    Typo: s/abiltiy/ability/
    
    The missing "T" at the beginning of Section 2 causes the document to fail ID-
    nits.
    
    The cipher names use the "_8" suffix to indicate 8-octet authentication tags,
    and the lack of a suffix to indicate 16-octet authentication tags. Excuse my
    ignorance, but are any other lengths allowed in AEAD?

draft-ietf-pcn-cl-edge-behaviour

  1. Stephen Farrell: Comment [2012-03-11]:
    [SM-Specific] please see my comment on the other one of these...
  2. Peter Saint-Andre: Comment [2012-03-08]:
    This document contains quite a bit of requirements terminology. Are we sure that
    Informational is appropriate? Did the WG consider making this a standards-track
    Applicability Statement (Section 3.2 of RFC 2026)?
  3. Sean Turner: Comment [2012-03-15]:
    Same comments as draft-ietf-pcn-sm-edge-behavior.
    
    s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term
    "decision point" explicitly, I think that adding some text along the lines of
    "The decision point is considered to be part of a PCN-node; therefore, the
    decision point is considered to be trusted for truthful decisions."  This makes
    it clear that s6.3.1 of RFC 5559 applies.
    
    s4.2.1: I find it a little odd that you say you're paraphrasing two sections but
    there's 2119 language in this draft where there was none in RFC 5559.  Granted
    it's mostly MAY this and MAY that so it's not that big of a deal, but there is a
    MUST and a NOT RECOMMENDED.  Are you really paraphrasing the text from RFC 5559
    in that case?
    
    s1.1: Need to add NOT RECOMMENDED to the key words.

draft-ietf-pcn-sm-edge-behaviour

  1. Stephen Farrell: Comment [2012-03-11]:
    - The security considerations section doesn't note the inherent
    vulnerability if the decision point is separated from the enforcement
    point(s). That is, the enforcement points (in/egress nodes) have to
    have an interface that could be called from some malicious node. Even
    if the PDP/PEP protocol is not in scope here, this scheme means that
    problem exists and there are clear DoS vectors implicit in that. RFC
    5559 which is referenced from this does say that "The signalling
    between the PCN-boundary-nodes must be protected from attacks" so I
    guess this is not discuss-worthy.
    
    - Total nit: t-recvFail is not a great name for a time - too easy to
    mistake for a subtraction, I'd suggest t_recvFail if it makes no
    difference. (And same for other names.)
  2. Russ Housley: Discuss [2012-03-13]:
    
      The Gen-ART Review by Joel Halpern on 31-Dec-2011 raised several
      issues.  That lead to a significant discussion, but not all of the
      issues have been resolved.
    
  3. Peter Saint-Andre: Comment [2012-03-08]:
    This document contains quite a bit of requirements terminology. Are we sure that
    Informational is appropriate? Did the WG consider making this a standards-track
    Applicability Statement (Section 3.2 of RFC 2026)?
  4. Sean Turner: Comment [2012-03-15]:
    s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term
    "decision point" explicitly, I think that adding some text along the lines of
    "The decision point is considered to be part of a PCN-node; therefore, the
    decision point is considered to be trusted for truthful decisions."  This makes
    it clear that s6.3.1 of RFC 5559 applies.
    
    s4.2.1: I find it a little odd that you say you're paraphrasing two sections but
    there's 2119 language in this draft where there was none in RFC 5559.  Granted
    it's mostly MAY this and MAY that so it's not that big of a deal, but there is a
    MUST and a NOT RECOMMENDED.  Are you really paraphrasing the text from RFC 5559
    in that case?
    
    s1.1: Need to add NOT RECOMMENDED to the key words.

draft-ietf-decade-problem-statement

  1. Ronald Bonica: Discuss [2012-03-14]:
    The document may be conflating the following issues:
    
    - Problems that P2P applications present
    - How those problems can be solved by in-network caching
    - Deficiencies in currently deployed in-network caching solution.
    
    Deficiencies in currently deployed in-network caching solution might include:
    - lack of standardized singling protocols
    - lack of access control mechanisms
    - etc
    
    While the first first two issues are interesting, I think that the WG wants:
    -
    for the reader of this document to focus on deficiencies in currently deployed
    caching strategies
    - to address  deficiencies in currently deployed caching
    strategies
    
    Would it be possible to make that more clear? One thing that you could do to
    focus the reader's attention is to remove text that isn't relevant to the point
    that you are making.
    
  2. Adrian Farrel: Comment [2012-03-14]:
    I have no objection to the publication of this document.
    
    I wondered whether Section 5 should discuss the problem that in-network
    storage may result in false data being supplied either through the
    data on a legitimate store being modified, or through a bogus store
    being introduced into the network. The material in Section 5 seems to
    cover the security of the protocol itself (and that may be enough)
    without describing these risks. Sis I miss something?
  3. Peter Saint-Andre: Comment [2012-03-12]:
    This is a well-written document. The first paragraph of Section 3 reads like
    marketing text. Is it needed?
  4. Robert Sparks: Comment [2012-03-13]:
    Here are some suggestions that might make this document more useful to the
    working group:
    
    Much of this document states the problem is that there's no standardized network
    storage solution. That's the solution you want to pursue, not the problem. A
    reader can get that the problem is some peer-to-peer protocols put stress on
    access networks. A potential solution that might treat the network as a whole
    more nicely would be to make it possible for peers that were on bandwidth
    constrained access to put things in a place that is both not bandwidth
    constrained and accessible by other peers. A secondary problem is that if
    existing protocols each tried to make this possible in their own way, it's
    harder for middleboxes that aren't explicitly part of that protocol to inject
    themselves to "help", and that could be avoided by giving all of the existing
    (and potentially any new) p2p protocols a common way to minimize moving content
    across the constrained barrier. A reader can get this message, but they have to
    read deeply and infer some of it. Please consider making the problem the main
    point of the text, and clearly identifying that network storage is the proposed
    solution path.
    
    The document speaks of a service "inside a network". It would help to be more
    precise. Do you mean "in the relatively bandwidth-unconstrained part of the
    network" or "in an access-regulated single administrative domain" or something
    else?
    
    The document asserts several times that using in-network resources will help,
    but doesn't support the assertion. Are
    there studies you can point to that show
    it's likely to help?
    
    The second paragraph quotes some reports on p2p traffic on access networks,
    using it to motivate reducing access traffic, but then claims it also motivates
    reducing "cross-domain and backbone traffic". While reducing traffic in general
    is probably a good idea the argument presented doesn't support the conclusion.
    
    The document says a P2P cache is likely to be much better connected to end hosts
    than to remote peers. The remote
    peers _are_ end hosts. What are you actually
    trying to distinguish here?
    
    Section 5.2 (Copyright and Legal Issues) puts filtering and DRM out of scope for
    this document. It would be better to say something like "is not in scope for the
    problem this document proposes solving".
  5. Sean Turner: Comment [2012-03-14]:
    I agree with Peter's thought about para 1 of s3 sounding a lot like marketing.
    
    I was surprised by the references to RFC 3414 in s5.4-5.7.  Is that where the
    solution is expected to come from or where the definition came from?  If it's
    the later wouldn't RFC 4949 be a better reference - it's the Internet Security
    Glossary, Version 2.   Also are there any privacy considerations to be worried
    about?
    
    I also found myself thinking along the same lines as Ron and Robert.

draft-ietf-opsawg-management-stds

  1. Stewart Bryant: Discuss [2012-03-15]:
    This is a well written document and I support its publication.
    
    However I am concerned that it takes an inconsistent position WRT the dataplane.
    
    One the one hand it says "Note that this document does not cover OAM
    technologies on the data-path" but on the other hand it says:
    
    "The IPPM working group ... The metrics include connectivity, one-way delay and
    loss, round-trip delay and loss, delay variation, loss patterns, packet
    reordering, bulk transport capacity, and link bandwidth capacity."
    
    which is the sort of thing that we measure in data-plane OAM.
    
    The document needs to either provide an objective discussion of all data plane
    techniques, or it needs to be scrubbed of all data plane techniques.
    
    Similarly I am concerned that FCAPS makes no mention of OAM and yet many aspects
    of FCAPS are intimately bound to OAM.
    
    Similarly a discussion of active vs passive monitoring is incomplete without a
    discussion of OAM.
    
  2. Stewart Bryant: Comment [2012-03-15]:
    It is harmless but unusual to note that RFC2119 is not used.
    
    Why does the IPPM section  not discuss the measurement of the convergence
    characteristics of networks?
  3. Wesley Eddy: Comment [2012-03-13]:
    I agree with many of Adrian's DISCUSS points.
    
    Other COMMENTs:
    
    (1) The last paragraph of section 1.2 should have at
    least some reference to an I-D or other document to
    indicate what the authors are talking about
    
    (2) Section 3.2 seems odd compared to the rest of the
    document, as the RFCs mentioned in this section are
    not management standards; several are just
    informational RFCs.
    
    (3) At the end of Section 3.4, it says that there are
    two protocols standardized, and then has three bullets
    underneath.  I think the third bullet should be
    separated out, since its relation to OWAMP and TWAMP
    is not clearly explained here.
  4. Adrian Farrel: Discuss [2012-03-12]:
    I had some difficulty determining what are "IETF network management
    standards".
    
    The Introduction helpfully explains that "OAM technologies on the data-
    path" are not covered. I think this might usefully be mentioned in the
    Abstract.
    
    ---
    
    I found the lists of existing MIB modules in Section 4.1 a bit hit and
    miss.
    
    For example, in Section 4.1.2 only one of te GMPLS MIB module RFCs is
    listed. This is kind of "by example" of a data plane model, so is
    probably OK, but why not mention the MIB modules for the GMPLS control
    plane.
    
    In Section 4.1.3 I would have expected to see discussion of both the
    MPLS forwarding plane, and some of the MPLS control plane protcols.
    Conversely, I found it off-puting that Section 4.1.3 lumps together
    the routing protocols with the IP forwarding plane.
    
    Looking at Section 4.1 as a whole, I wondered whether you really want to
    enumerate the existing MIB modules for all IETF protocols. This seems
    like a thankless task and one that is hard to keep complete unless you
    go to the OID tree (in IANA) and make a full list.
    
    On the other hand, there are some technology-specific "MIB overview"
    documents that might provide useful things to point at. For example:
    - RFC 4221
    - draft-ietf-mpls-tp-mib-management-overview
    
    I'm finding this a hard one to make actionable! How about...
    
      Please use the OID tree in the IANA registry to ensure that you have
      not left out any MIB modules for key IETF protocols.
    
      Please consider including references to RFC 4221 and draft-ietf-mpls-
      tp-mib-management-overview.
    
    You might also find it beneficial to split 4.1 into forwarding plane
    management and control protocol management.
    
    ---
    
    Rather than removing Section 6, I think you should use it to summarise
    the secuirty issues of network management, point to the sections of this
    document that discuss security, and reference other documents specific
    to the security of network management.
                                                     
    This might point to the fact that security discussions are patchy in 
    this document. 2.1.4 is a good detailed cover of SNMP security, 2.2 
    briefly mentions how to secure syslog, and 2.3 has a rather scanty 
    mention of security for ipfix. Why is there not similar discussion of
    how to secure netconf?
    
    Similarly, in section 3 there is mention of security for RADIUS, 
    DIAMETER, CAPWAP, ANCP, and ACAP, but not for DHCP, BOOTP, the various
    autoconf options, COPS, and XCAP.
    
  5. Adrian Farrel: Comment [2012-03-12]:
    I think that a general change of s/MIB/MIB module/ is needed.
  6. Robert Sparks: Discuss [2012-03-13]:
    This document needs some minor adjustments to account for RFC6410 (Reducing the
    Standards Track to Two Maturity Levels), and to use the terms from 2026
    correctly (The string "full standard" does not appear in 2026).
    
    The following two paragraphs seem out of place with the rest of the document:
    
    "  With further information elements, IPFIX can also be applied to
       monitoring of application-level protocols, for example, Session
       Initiation Protocol (SIP) [RFC3261] and related media transfer
       protocols.  Requirements to such a monitoring on the application
       level include measuring signaling quality (e.g., session request
       delay, session completion ratio, or hops for request), media Quality
       of Service (QoS) (e.g., jitter, delay or bit rate), and user
       experience (e.g., Mean Opinion Score).
    
       Note that even if the initial IPFIX focus has been around IP flow
       information exchange, non-IP-related information elements are now
       specified in IPFIX IANA registration (e.g.  MAC (Media Access
       Control) address, MPLS (Multiprotocol Label Switching) labels, etc.).
       At the time of this writing, there are requests to widen the focus of
       IPFIX and to export also non-IP related information elements (such as
       SIP monitoring IEs).
    "
    
    The rest of the document discusses work in progress that's already well
    underway
    - this is more of a motivation for future work or an explanation
    that future
    work is possible. Why is it important for this document? I suggest just
    removing these two paragraphs, but if  something like this really needs to be
    said, 
    can it reference work in progress?
    

draft-ietf-multimob-igmp-mld-tuning

  1. Stewart Bryant: Comment [2012-03-08]:
    No objection provisional on nothing bad being uncovered in IETF LC
  2. Adrian Farrel: Discuss [2012-03-14]:
    Discuss updated after email exchanges (some points are agreed and just need a
    revised I-D, some points still to be discussed to completion)
    
    I like this document: thank you. However, I have some small issues.
    
    I think the first of my Discuss issues is a small procedural
    question that can be resolved through process rather than changes
    to the document. Thus the actions should come from the AD, chairs,
    and shepherd.
    
    The subsequent issues are for the authors.
    
    ---
    
    The Shepherd write-up says...
    
      (7) Has each author confirmed that any and all appropriate IPR
      disclosures required for full conformance with the provisions of BCP 78
      and BCP 79 have already been filed. If not, explain why.
    
      There have been no IPR disclosures filed on this document
    
    This is not an answer to the question that was asked.
    
    To be precise in my question: have the authors been asked and confirmed that
    there is no IPR to be disclosed, or is the shepherd deducing this from the
    absence of dsiclosures?
    
    ---
    
    I don't understand the last sentence in Section 1
    
       The proposed behavior interoperates with
       the IGMPv3 and MLDv2 protocols.
    
    How could the behavior not interoperate with these protocols since you
    are directly describing the protocols?
    
    Maybe it would be better to replace this sentence with...
    
       This document does not make any changes to the IGMPv3 and MLDv2 
       protocls and only suggests optimal settings for the configurable
       parameters of the protocols in mobile and wireless environments.
    
    Of course, if my suggested text is not true, we have a bigger issue to
    address :-)
    
    ---
    
    Is Appendix A normative? It includes advice and RFC2119 language. There
    is no reference to the Appendix from the body of the text, and no 
    explanation in the Appendix itself as to why it is not in the main part
    of the document. Please clarify.
    
  3. Pete Resnick: Discuss [2012-03-14]:
    I feel more strongly than Robert about the status of this document. This is
    introducing particular protocol parameter values that will effect performance
    and interoperability of the protocol. The recommendations are put in the form of
    some 2119 language. And the shepherd report says that there was strong consensus
    behind the solution. I don't understand why it is not Standards Track.
    
  4. Pete Resnick: Comment [2012-03-14]:
    I very much agree with Adrian's DISCUSS related to asking authors about IPR.
    Please do.
    
    Both the ballot writeup and the shepherd report are really inadequate. "Nothing
    worth noting outside ordinary WG process" is not helpful at all to the rest of
    the IESG to understand the history of this document. The answers in the shepherd
    report really give little information. The one answer of any substance was where
    it says, "There is a strong consensus behind this solution." Again, that sounds
    like a reason for Standards Track.
    
    I agree that the Appendix should probably be in the main body.
    
    The 2119 language in this document has lots of problems and should be reviewed.
    Examples:
    
    3.
    
       ... a large number of the reply messages sent
       from all member hosts MAY cause network congestion or consume network
       bandwidth.
    
       ...messages MAY be lost during transmission.
    
    4.1
    
      This shorter interval contributes to quick synchronization
       of the membership information tracked by the router but MAY consume
       battery power of mobile hosts.
    
    MAY is for protocol options. None of these are protocol options. Almost none of
    the MAYs are used correctly.
    
    4.4.  Tuning Startup Query Interval
    
       The [Startup Query Interval] is the interval between General Queries
       sent by a Querier on startup.  The default value is 1/4 of [Query
       Interval]; however, in this document it is RECOMMENDED that the use
       of its shortened value such as 1 second since the shorter value would
       contribute to shortening handover delay for mobile hosts in, e.g.,
       the base solution with PMIPv6 [10].  Note that the [Startup Query
       Interval] is a static value and cannot be changed by any external
       signal.  Therefore operators who maintain routers and wireless links
       MUST properly configure this value.
    
    The MUST here isn't specifying a protocol behavior. You probably mean "need to".
    But do you really mean that the value MUST be 1 second?
    
    4.6
    
       Thus the effects of the
       IGMP/MLD message transmission through a tunnel link SHOULD be
       considered during the parameter setting.
    
    What interoperability problem occurs if they are not considered? Instead of
    SHOULD, "ought to".
    
    6.
    
       This document assumes that both multicast routers and mobile hosts
       MUST be IGMPv3/MLDv2 capable
    
    That MUST isn't a directive for this document. Instead of "MUST be", "are".
  5. Robert Sparks: Comment [2012-03-13]:
    Did you consider PS for this document? Operational/interop experience might
    suggest changed values.
    
    Small thing: Consider pointing out that as you start talking about Max Resp Code
    values larger than 12.8 seconds,
    the exponential representation in 4.1.1 of
    RFC3376 kicks in so the granularity of changes you can indicate
    becomes coarser.

draft-harkins-ipsecme-spsk-auth

  1. Adrian Farrel: Comment [2012-03-14]:
    I have no objection to the publiction of this document.
    
    I love the concept of "distilling entropy". This is, I think, really
    just hiding the absence of entropy, but I have no objection to the
    term being used in this document.
  2. Stephen Farrell: Discuss [2012-03-15]:
    
    #1 8.1 - why an 8-bit counter? that's usually wrong unless there's a
    reason to want it so short. In this case if len(r)~=len(p) then 3 in
    every 1000 IKE exchanges might not work with this scheme. While that
    might be ok for an experimental RFC, having to change it if this
    became a standard would be bad. I'd suggest a 16 bit counter or else
    providing a way to iterate until you do find a good ske-value. (If
    I'm right about the probability there.) The pseudo-code in 8.2.1 &
    8.2.2 also need something to terminate their loops, e.g. "while
    (found == 0 && counter < limit )"
    
    #2 hunting and pecking: is this a potential timing attack vector for
    passphrases? If the answer is known then adding that to the security
    considerations seems warranted. If not, then just saying that that's
    for further study would be ok, but I think at least that is needed.
    
  3. Stephen Farrell: Comment [2012-03-15]:
    - s1, saying 5996 is "insecure" is maybe overstated, I'd suggest
    "insecure with weak pre-shared keys, such as human-memorable
    passwords"
    
    - maybe say "MUST use the same group" in section 4 rather than "uses
    the same group" just to call that out.
    
    - s4, you don't define "scalar" - I guess you mean an integer but
    better to say.
    
    - p5, typo: s/consists points/consists of points"
    
    - The scalar-op description is confusing, or wrong (would
    s/multiplication/addition/ be right? I forget too much math;-)
    Wouldn't it be better to just say that 2*X = X + X after the
    element-op has been defined?
    
    - 4.1, last para: better to name the IANA registry there maybe
    
    - 4.2, s/modulus a prime/modulo a prime/
    
    - section 6 could badly do with some examples if that's possible. I'd
    expect interop problems in any case, but more without that. Those
    might be shared with the other scheme drafts.
    
    - Is the last paragraph of section 6 really achieveable? A common
    pattern here is that one side needs the cleartext password, e.g.  if
    using an existing DB that's also used for some other protocol.  Might
    be bad practice, but would a SHOULD store the pre-processed value be
    more likely to get implemented?
    
    - section 7, point 3 - is this really correct? If the PSK is based on
    a passphrase then the pre-processed values will not really be
    uniformly distributed amongst all 256 bit strings. The set of
    pre-processed strings might be indistinguishable from any subset of
    the set of 256 bit strings but that's not quite the same.
    
    - Its probably wrong to say that Dragonfly is "patent-free and
    royalty-free." We can't know the former and the latter seems to
    require that some IPR exists.
    
    - 8.2.1 - "hunting and pecking continues" means increment the counter
    and get a new ske-value right? Be better to say that.
    
    - 8.2.1 - be good to explain how y=sqrt(...) produces FAIL since
    that's not very obvious
  4. Peter Saint-Andre: Comment [2012-03-08]:
    Section 6 states:
    
       The first step of pre-processing is to remove ambiguities that may
       arise due to internationalization.  Each character-based password or
       passphrase MUST be pre-processed to remove that ambiguity by
       processing the character-based password or passphrase according to
       the rules of the [RFC4013] profile of [RFC3454].
    
    Please be aware there there is work underway to obsolete RFC 3454 and RFC 4013,
    primarily because stringprep is limited to Unicode 3.2; see draft-melnikov-
    precis-saslprepbis. This is just a heads-up, and I'm not necessarily suggesting
    that you change the text to something like "use RFC 4013 or equivalent".
    However, when your experiment is done and you put this on the standards track,
    you'll probably be asked to update the internationalization to use saslprepbis
    (if the PRECIS WG finishes before your experiment does!).

draft-shin-augmented-pake

  1. Stephen Farrell: Comment [2012-03-15]:
    - section 2.2.1 could badly do with some examples if that's possible.
    I'd expect interop problems in any case, but more without that. Those
    might be shared with the other scheme drafts.
    
    - Section 2, last paragraph - that's confusing - which Y and K
    calculation is to be done? I think you need to be much clearer about
    this. 
    
    - saying "server S does not store any plaintext passwords" is missing
    2119 language. While a MUST would be most correct, perhaps a SHOULD
    is right, in case someone wants to do this using an existing DB of
    cleartext passwords.
    
    - Providing a reference for "Shamir's trick" would be good.
  2. Peter Saint-Andre: Comment [2012-03-08]:
    Both draft-harkins-ipsecme-spsk-auth and draft-kuegler-ipsecme-pace-ikev2
    specify that the password will be prepared using SASLprep (RFC 4013). Why
    doesn't this specification also define how 'w' is prepared for input to other
    operations?

draft-kuegler-ipsecme-pace-ikev2

  1. Stephen Farrell: Comment [2012-03-15]:
    - I found the overall description of PACE hard to follow, it'd be
    better if you gave the MODP method for mapping s in the overview so
    that someone who just knows standard D-H can see why this is a ZKPP.
    
    - "free of patents" is not possible, and not really appropriate as a
    claim in an RFC
    
    - section 5.1 could badly do with some examples if that's possible.
    I'd expect interop problems in any case, but more without that. Those
    might be shared with the other scheme drafts.
    
    - [I-D.kivinen-ipsecme-secure-password-framework] is now an RFC
    
    - s2, point 1: don't just say that a value encrypted with the
    password (ENONCE) is sent to the responder, since that'd in general
    be vulnerable to off-line dictionary attacks. Maybe say that ENONCE
    is ok to send because it is specially constructed so as not to expose
    anything about the password.
    
    - "MUST be presisted to stable memory" might be too onerous, I'd say
    a SHOULD would be better there in case someone has to use an existing
    DB of shared secrets.
    
    - The LongTermSecret scheme seems to be independent of PACE so I
    wondered why its here and not in a document of its own.
    
    - 4.1 seems to call for a table of mappings from authenticated
    ciphers to the unauthenticated equivalents, otherwise interop is not
    likely. I think you need to provide those mappings (or at least some)
    and ideally ask IANA to create a registry for others (it'd be needed
    if this got onto the standards track later).
  2. Peter Saint-Andre: Comment [2012-03-08]:
    Section 5.1 states:
    
       The input password string SHOULD be processed according to the rules
       of the [RFC4013] profile of [RFC3454].
    
    Why or when would an implementation violate the SHOULD? That is, why is this not
    a MUST? Also, please be aware there there is work underway to obsolete RFC 3454
    and RFC 4013, primarily because stringprep is limited to Unicode 3.2; see draft-
    melnikov-precis-saslprepbis. This is just a heads-up, and I'm not necessarily
    suggesting that you change the text to something like "use RFC 4013 or
    equivalent". However, when your experiment is done and you put this on the
    standards track, you'll probably be asked to update the internationalization to
    use saslprepbis (if the PRECIS WG finishes before your experiment does!).

draft-garcia-shim6-applicability

  1. Stewart Bryant: Comment [2012-03-07]:
    As a courtesy  to the RFC Editor, the authors should scrub the document for
    terms not expanded on first use.
  2. Adrian Farrel: Comment [2012-03-15]:
    The first two paragraphs of the Security section reads oddly.
    
    Suggest:
    OLD
       This section considers the applicability of the Shim6 protocol from a
       security perspective, i.e. which security features can expect
       applications and users of the Shim6 protocol.
    
       First of all, it should be noted that the Shim6 protocol is not a
       security protocol, like for instance HIP.
    NEW
       This section considers the applicability of the Shim6 protocol from a
       security perspective, i.e. which security features can be expected by
       applications and users of the Shim6 protocol.
    
       First of all, it should be noted that the Shim6 protocol is not a
       security protocol, unlike for instance HIP.
    END
  3. Stephen Farrell: Comment [2012-03-09]:
    - I wondered how IPsec was affected by or affects shim6.  Figure 3
    didn't really tell me.
    
    - Section 3.3 seems a bit odd - why do you want to control CGA
    parameters via DHCP? (That's also the subject of a discuss on
    ietf-csi-dhcpv6-cga-ps.) Its also not the case (is it?) that private
    key information is ever exchanged like this. Similarly with 3.4.
    Could both these sections not actually just be deleted?
  4. Russ Housley: Discuss [2012-03-13]:
    
      The Gen-ART Review by Joel Halpern on 18-Feb-2012 raised several
      concerns, and there seems to be agreement on the nature of the
      changes to the document that are needed.  Yet, the changes have not
      been made yet.
    
  5. Sean Turner: Comment [2012-03-14]:
    I like the edits agreed as a result of Stephen's comments.

draft-reschke-http-status-308

  1. Wesley Eddy: Comment [2012-03-11]:
    The writeup doesn't mention why this isn't just part of the httpbis
    specifications, since it was apparently fine with the working group and received
    positive comments there.  Why did it have to be done as AD-sponsored, and why is
    the target Experimental?
  2. Adrian Farrel: Comment [2012-03-12]:
    I have no objection to the publication of this document.
    
    In section 3 you have "ought".
    It might be nice to use a RFC 2119 word for this.
    
    ---
    
    Section 3 also contains two instances of "SHOULD". It would be good to
    explain (often a "MAY") why these are not "MUST". (I think the exsiting
    "MAY" applies as a varience to the "ought".)

draft-tsou-softwire-gwinit-6rd

  1. (none)