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

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)