IESG Narrative Minutes

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

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

Corrections from: Cindy

1 Administrivia

  1. Roll Call 1134 EDT Cindy:
  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. Internet X.509 Public Key Infrastructure - Certificate Image (Proposed Standard)
    draft-ietf-pkix-certimage-09
    Token: Tim Polk
    Note: Steve Kent is the document shepherd <kent@bbn.com>
    Discusses/comments (from ballot 3462):
    1. Ralph Droms: Discuss [2010-07-15]:
      I don't understand how these points from the Security Considerations might be enforced:
      A bad performing CA may for example;
      - include information in graphical form that is in conflict with information in provided text based attributes or other name forms
      Certificates, and hence their cert images, are commonly public objects and as such usually will not not contain privacy sensitive information. However, when a cert image that is referenced from a certificate contains privacy sensitive information appropriate security controls should be in place to protect the privacy of that information. Details of such controls are outside the scope of this document.
    2. Ralph Droms: Comment [2010-07-15]:
      I can't parse this syntax: "...to that [RFC5280] certificate...". Is "[RFC5280]" an adjective describing a kind of certificate?
    3. Adrian Farrel: Comment [2010-07-15]:
      I was disappointed to find that this draft has nothing to do with reliability of magicians.
    4. Alexey Melnikov: Discuss [2010-07-13]:
      I have some small set of issues on RFC 3709, which would have been DISCUSS level material if I were to review it for IESG. So this is DISCUSS DISCUSS (i.e. I want to discuss it with the rest of IESG):
      In Section 4.1 of RFC 3709: "LogotypeDetails ::= SEQUENCE { mediaType IA5String, -- MIME media type name and optional parameters"
      The format of this field is not specified. This turned out to be an interop problem in some other similar cases.
      Process related issue: image/svg+xml MIME type is not registered in the IANA MIME type registry.
      In Section 5.2: "The referenced SVG file MAY be provided in GZIP [RFC1952] compressed form as an SVGZ file according to section 1.2 in SVG 1.1 [SVG]. Hash over the SVGZ file is calculated over the decompressed SVG content with canonicalized EOL characters (<LF>) as specified above."
      This would require a separate MIME type registration. I don't think it is Ok to just reuse image/svg+xml.
    5. Alexey Melnikov: Comment [2010-07-13]:
      1) 5. Embedded images: To clarify: this document doesn't update RFC 3709 to allow use of "data" in
      - Community logotype
      - Issuer organization logotype
      - Subject organization logotype
      2) 4.2. PNG: It is a shame that there is no RFC that describe this MIME type. But this is not a problem of this document.
      3) I have some small set of issues on RFC 3709, which would have been a COMMENT level material if I were to review it for IESG: ...
    6. Dan Romascanu: Discuss [2010-07-14]:
      In Section 3: The optional LogotypeImageInfo structure is defined in [RFC3709]..."
      Alexey already observed in a COMMENT that it looks useless to tag a logo image for language. Moreover, RFC 3709 is using the RFC 3066 Lamnguage Tag, while 3066 was obsolete by RFC 4646 which was later obsoleted by RFC 5646. I wonder if this would not rather cause problems than help.
    7. Peter Saint-Andre: Discuss [2010-07-14]:
      1. What in the world is "a visual representation of a certificate"?
      2. Memorability and therefore perhaps security would be enhanced if a visual representation were assigned by the relying party. This would result in something like a petname system... It might make sense to mention this alternate (or complementary) approach in the security considerations.
    8. Peter Saint-Andre: Comment [2010-07-14]:
      1. There are many violations of subject-verb agreement, such as "Images incorporated according to RFC 3709 provides" (instead of "provide").
    9. Robert Sparks: Comment [2010-07-13]:
      Support Alexey's Discuss points regarding the mime type
      Please consider an additional sentence or so at the start of the security considerations section explicitly reinforcing that a CA needs to understand the security considerations section of 3709 before signing a certificate using this extension.
    10. Sean Turner: Discuss [2010-07-13]:
      The -06 version added RFC 1952 as a normative reference. This RFC is not in the DOWNREF registry and (obviously) wasn't part of the IETF LC, which was on the -02 version. A second abbreviated IETF LC is required to call out this DOWNREF.

    Telechat:

2.1.2 Returning Items

  1. Session Initiation Protocol Event Package for Voice Quality Reporting (Proposed Standard)
    draft-ietf-sipping-rtcp-summary-12
    Token: Robert Sparks
    Discusses/comments (from ballot 2032):
    1. Adrian Farrel: Comment [2010-02-02]:
      Unclear on the use use of references within the ABNF comments. Sometimes they are used, and sometimes not. Suspect that (as per MIB Modules) they should not be used.
      Wonder if the Proto Writeup should be updated. This would certainly have caught Alexey's issues with the ABNF.
    2. David Harrington: Discuss [2010-07-14]:
      1) in 3.2 the reporter should send an options message to ensure support of the publish message; what happens if should the reporter do if it is not supported?
      2) in 4.6.2.4, s/can/MAY/
    3. David Harrington: Comment [2010-07-14]:
      1) in section 3.2, where is "unmanaged" defined?
      2) in 3.2, s/recommended/RECOMMENDED/
      3) in 3.3., where is report bodies defined?
      4) in 4.5, "always shares" - with whom?
      5) in 4.6.2.3.8, where is "fmtp" defined?
    4. Russ Housley: Comment [2010-07-13]:
      Some of the comments in the Gen-ART Review by Scott Brim were not addressed. Please consider them.
    5. Alexey Melnikov: Comment [2010-03-10]:
      The document shepherd/sponsoring AD should rerun <http://tools.ietf.org/tools/bap/abnf.cgi> on the ABNF from this document.
      4.6.2.2. Timestamps: ABNF for timestamps allows for timezones, so it would be good to mention in the ABNF section that timezones other than "Z" are not allowed.
      4.6.2.11.2. RLQEstAlg: Is there an IANA registry for such algorithms, or does this field contain free form text?
      4.6.2.11.4. RCQEstAlg: As above.
      4.6.2.11.6. ExtRInEstAlg: As above.
      4.6.2.11.8. ExtROutEstAlg: All but the first sentence don't seem to belong to this section.
      4.6.2.11.11. MOSCQEstAlg: Is there an IANA registry for such algorithms, or does this field contain free form text?
    6. Tim Polk: Comment [2007-07-03]:
      In 4.2.6.10, the specifications for both Round Trip Delay and End System Delay end with "This parameter does no require any conversion."
      Perhaps "no" should be "not" in both cases?
    7. Dan Romascanu: Comment [2009-07-31]:
      Section 4.6.2.3 and 4.6.2.13 - I do not understand what is the usage of the following: "Payload Desc..."
      How is interoperability ensured without a proper register that defines what text applies to each algorithm?
    8. Peter Saint-Andre: Comment [2010-07-14]:
      1. Section 4.4 talks about subscription duration but not about when to cancel a subscription (by either the reporter or the collector); for example, it might be appropriate to recommend cancelling the subscription when the voice session had ended?
      2. The RemoteID "bill@elpmaxe.org" does not conform to RFC 2606.
      3. The references to draft-ietf-sipping-config-framework and RFC 5389 appear to be informative, not normative.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. NSIS Protocols operation in Mobile Environments (Informational)
    draft-ietf-nsis-applicability-mobility-signaling-19
    Token: Lars Eggert
    Note: The document shepherd is Martin Stiemerling (martin.stiemerling@neclab.eu).
    Discusses/comments (from ballot 1548):
    1. Adrian Farrel: Discuss [2010-07-15]:
      Section 1 "currently there two standardized NSLP protocols, the QoS NSLP [draft-ietf-nsis-qos-nslp], and the NAT/Firewall NSLP [draft-ietf-nsis-nslp-natfw]"
      s/standardized/specified/
    2. Adrian Farrel: Comment [2010-07-15]:
      This is an example of a well-written document that is sometimes hard to parse becuse of small issues with the use of English. I know that the RFC Editor will make a pass for this type of issue, but it would have been (could still be!) good to get a native speaker from the WG to take an editorial pass on the document. The risks associated with the RFC Editor correcting text without the knowledge of the technical details are considerable.

    Telechat:

  2. Mailing Lists and Internationalized Email Addresses (Experimental)
    draft-ietf-eai-mailinglist-07
    Token: Alexey Melnikov
    Note: Pete Resnick is the document shepherd
    Discusses/comments (from ballot 3291):
    1. David Harrington: Discuss [2010-07-14]:
      1) in section 5, should "can only" be "MUST only"?
    2. Tim Polk: Comment [2010-07-15]:
      I support Peter's discuss issue 5 (also appearing in Dan's comment) regarding the security considerations. The attacks Peter lists seem to fall outside the scope of 4952's security considerations, and should be addressed in this document.
    3. Dan Romascanu: Comment [2010-07-14]:
      In the OPS-DIR review Mehmet Ersue made the observation that the Security Consideration section refers to RFC 4952, and that no further security considerations are raised by this document. However, the security consideration section in 4952 seems to deal with various threats resulting from the expansion of the charaters sets in messages and specifically in addresses and headers, but does not deal at all with mail lists. I am wondering if there are not specific threats related to mail lists. Did the security reviewer and ADs see and agree that there is no potential problem here?
    4. Peter Saint-Andre: Discuss [2010-07-14]:
      1. Section 5 states: "These mailing list header fields contain URLs." However, that is not true of List-ID.
      2. This statement might be confusing to readers: "... discussion on whether internationalized domain names should be percent-encoded or puny-coded, is ongoing; see [IRI-bis]"
      Does it make sense to reference the IDNAbis work here, since it is concluded and directly covers the topic of internationalized domain names (as opposed to the less direct discussion in IRI-bis)? Will interoperability suffer if this specification does not make a recommendation regarding percent-encoded vs. puny-coded IDNs?
      3. The paragraph about List-ID at the end of Section 5 does not make a recommendation. For example, it could say: "Therefore, the value of the List-ID header field SHOULD NOT contain ASCII encodings of non-ASCII values." Did the WG have consensus to avoid making a recommendation here?
      4. Also, the paragraph about List-ID at the end of Section 5 does not mention whether it is reasonable to include non-ASCII values that have not been encoded into ASCII. Was this also the intent of the WG?
      5. To expand on Dan Romascanu's COMMENT regarding the security considerations, RFC 4952 does not seem to discuss the use of email addresses for authorization decisions. Given that a mailing list subscription is one kind of authorization decision, it seems possible that an attacker could subscribe to a mailing list using a UTF-8 address whose alt-address matches the (non-UTF-8) address of a victim, thus potentially preventing the victim from subscribing to the list. Similarly, the attacker could send messages from its i18n-address but subscribers that are not UTF8SMTP-aware might attribute the message to the victim's (non-UTF-8) address. Finally, the list itself could use an alt-address that matches the (non-UTF-8) address of another list. Are these attacks possible? If so, are there guidelines regarding these cases in RFC 4952 but I'm simply missing them? Does this spec need to have some text about the potential mismatch between a UTF-8 address and an alt-address?

    Telechat:

  3. "The OAM Acronym Soup" (Informational)
    draft-ietf-opsawg-mpls-tp-oam-def-06
    Token: Adrian Farrel
    Note: Scott Bradner (sob@harvard.edu) is the document shepherd.
    Discusses/comments (from ballot 3439):
    1. Stewart Bryant: Comment [2010-07-12]:
      I am not sure that "ambivalence" is the right word: "However there is some ambivalence in the definition and scope of the term "Operation"."
      Did the authors mean "ambiguity" ?
    2. David Harrington: Discuss [2010-07-12]:
      I found the purpose of this document to be rather muddled. In the Abstract, it says "This document provides a definition ... for use in all future IETF documents that refer to OAM."
      The Introduction says "The main purpose of this document is to provide a definition ... that is useful for MPLS."
      I object to the text that says this document provides a definition for use in all future IETF documents.
    3. David Harrington: Comment [2010-07-12]:
      I think this document should clearly separate what exists in practice across SDOs and what will be the new IETF-wide standard for use of these acronymns. I find it unclear about where section 2 falls on this point. Section 3 and 4 define terminology for the MPLS-TP effort, but the section titles limit it to the MPLS-TP effort, and the Informational status of the document makes this less than a standard.
      2) Various flavors of OAM from multiple SDOs have started coming into play. If the document provides a definition for use in all future IETF documents that refer to OAM, are the other SDOs agreeing to use the ***SAME*** definition in all their future documents as well? If not, then I think it highly likely that future IETF documents that deal with cross-SDO OAM are likely to have the same problem we face now with MPLS-TP.
      3) "The ITU documents also clearly define a maintenance philosophy." - Does this mean that the IETF hereby adopts the same maintenance philosophy for all future IETF documents? or for MPLS-TP efforts? I don't think the IETF has agreed to that. Are the documents that define this maintenance philosophy freely available?
    4. Russ Housley: Comment [2010-07-12]:
      Please consider the editorial comments in the Gen-ART Review by Francis Dupont on 2010-07-01.

    Telechat:

  4. Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP) (Informational)
    draft-ietf-martini-reqs-08
    Token: Gonzalo Camarillo
    Discusses/comments (from ballot 3448):
    1. Lars Eggert: Comment [2010-07-09]:
      INTRODUCTION, paragraph 5: "This work is being discussed on the martini@ietf.org mailing list." Remove.
    2. Alexey Melnikov: Comment [2010-07-11]:
      Section 3 is hard to follow for somebody not involved with SIP on a daily basis. I suggest adding some ASCII art to demonstrate relationship between entities and possibly some examples of messages demonstrating issues.

    Telechat:

  5. Secure Proxy ND Support for SEND (Experimental)
    draft-ietf-csi-proxy-send-04
    Token: Ralph Droms
    Note: Marcelo Bagnulo (marcelo@it.uc3m.es) is the document shepherd.
    Discusses/comments (from ballot 3465):
    1. Jari Arkko: Comment [2010-07-01]:
      I think that the decision to employ two levels of security in proxied messages (ND or SPND) has lead to the rules that are not optimal in all circumstances. In particular, the document says:
      "As a rule of thumb, if the proxied nodes can return to the link in which the proxy operates, the Secure ND Proxy MUST only generate PS options on behalf of nodes with SEND capabilities (i.e. that they could use SEND to defend their messages if being in the same link than the proxy, either RFC3971 nodes or SPND nodes). This is relevant to allow nodes preferring secured information over unsecured one ..."
      What this essentially says is that unless there is knowledge about the network structure and movement patterns, secure proxy cannot proxy plain old ND messages with security at all. I happen to believe that this situation is the typical situation.
      If you had provided one additional bit of information in the secure proxy messages about the SEND/non-SEND status of the original message, there would not be this limitation. You could have amended the backwards compatibility rules of SEND to prefer native SEND messages over proxied SEND messages over unsecured ND messages.
      I would like to ask the authors to consider this before final approval of the document as an RFC.
    2. Alexey Melnikov: Discuss [2010-07-01]:
      Does Section 5.2.2 item 1 contradict text in Section 5.2.1?
    3. Alexey Melnikov: Comment [2010-07-01]:
      The last sentence in section 5.2.2 looks out of sync when compared to the text in item 1 of the same section.
    4. Tim Polk: Comment [2010-07-15]:
      I support Sean's discuss.
    5. Sean Turner: Discuss [2010-07-13]:
      The SECDIR review pointed out a number of changes that are needed. The author agreed. I'll remove this DISCUSS once a new version (or an RFC editors note) is posted to incorporate the agreed changes.
      The SECDIR review also pointed out issues with this document and with draft-ietf-csi-send-cert. That discussion has not completed.

    Telechat:

  6. IPsec Cluster Problem Statement (Informational)
    draft-ietf-ipsecme-ipsec-ha-09
    Token: Sean Turner
    Note: Yaron Sheffer (yaronf.ietf@gmail.com) is the document shepherd.
    IPR: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ipsecme-ipsec-ha-08
    Discusses/comments (from ballot 3466):
    1. Lars Eggert: Comment [2010-06-30]:
      INTRODUCTION, paragraph 4: "An agreed terminology, problem statement and requirements will allow the IPSECME WG to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations."
      Suggest to remove text that talks about IETF WGs, which are after all ephemeral, from this document before publication as an RFC.
    2. David Harrington: Comment [2010-06-30]:
      1) in 3.7, I think it would make the document easier to read if you spelled out the LS and HS acronyms.
      2) "the other half of the flow" - s/the the/the/
      is "the other half" a response, or ...; can you clarify, "the other half" doesn't seem very specific.
      3) in 3.8 "this looks weird". I don't think the problem is that it looks weird; it's that the peer might respond to the fact that it looks weird and do something like discard it or filter it, and this would cause problems. Simply saying "it looks weird" doesn't really describe this in a clear and unambiguous manner.
      4) "Reply packets might arrive ..." I think this should be discussed in the security considerations
      5) in section 2, PAD needs to be spelled out or referenced.
      6) aren't RFC2119, IKEv2bis and 4306 normative? Others may be also, but these seem obvious.
    3. Alexey Melnikov: Comment [2010-06-27]:
      I think some of the references should be Normative.

    Telechat:

  7. IPv6 Deployment in Internet Exchange Points (IXPs) (Informational)
    draft-ietf-v6ops-v6inixp-08
    Token: Ron Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3468):
    1. Jari Arkko: Comment [2010-07-15]:
      Do IXPs normally run SIP gateways (Section 7)? That would be news to me...
      Ari Keränen's review noted some editorial issues
    2. Alexey Melnikov: Comment [2010-07-11]:
      In Section 3, last paragraph: s/dns/DNS; s/ftp/FTP; Also add informative references for these.
      More acronyms with no references in Section 7.
    3. Dan Romascanu: Comment [2010-07-14]:
      "However, some management functions may require explicit IPv6 support (such as switch management, SNMP [RFC3411] support or flow analysis exportation) and this should be assessed by the IXP operator."
      I do not understand what switch management means here, and support of SNMP and IPFIX (which I suspect is what is meant by flow analysis exportation) should be transparent to the network layer.

    Telechat:

  8. NSIS Operation Over IP Tunnels (Experimental)
    draft-ietf-nsis-tunnel-12
    Token: Lars Eggert
    Note: The document shepherd is Jukka Manner (jukka.manner@tkk.fi).
    Discusses/comments (from ballot 3471):
    1. Adrian Farrel: Comment [2010-07-15]:
      Section 3.1 "The following definition of IP tunneling is derived from [RFC2473] and adapted for both IPv4 and IPv6."
      This is a bit odd given the existence of RFC 1853.
    2. Russ Housley: Comment [2010-06-28]:
      Pleae consider the editorial comments from the Gen-ART Review by Francis Dupont on 2010-06-15.
    3. Peter Saint-Andre: Comment [2010-06-28]:
      It appears that the following references might be normative, not informative: [RFC4080], [RFC2473], [RFC2113], [RFC2711], [RFC2746], [RFC3697], [RFC4081].

    Telechat:

  9. Rogue IPv6 Router Advertisement Problem Statement (Informational)
    draft-ietf-v6ops-rogue-ra-01
    Token: Ron Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3476):
    1. Stewart Bryant: Comment [2010-07-14]:
      It's not clear what he following means: "But for accidental problems like Windows ICS and 6to4, it could be useful." In particular references are needed.
      In Section 5.1 "If a host sending rogues RAs" Spurious "s"
      "In the case of Windows ICS" Needs a reference (and an expansion of "ICS")
      Section 8 "Where managed switches are no available" S/no/not/; Then next line I think s/moreso/more so/
    2. Ralph Droms: Comment [2010-07-14]:
      Stig is now with Cisco.
    3. Tim Polk: Discuss [2010-07-14]:
      discuss-discuss, as it conflicts in part with wg consensus.
      The security considerations section states: "This document is Informational. It does not describe solutions for malicious attacks on a network for which malicious RAs may be part of a broader attack, e.g. including malicious NA messages."
      While it may be reasonable to place malicious RAs out of scope for the corresponding protocol work, I do not believe we should exclude it from the security considerations!
      ... Understanding which malicious rogue RAs are not addressed might be helpful in deciding whether to deploy this technology.
    4. Dan Romascanu: Comment [2010-07-14]:
      1. Many acronyms lack expansion at first occurance.
      2. It would be good to provide references to the tools descreibed in Section 3.8
      3. Section 3.10 - not clear what exactly is meant by 'different layer 2 medium'
      - if this means 'physically separate layer 2 network' than the later terminology is better.
    5. Sean Turner: Comment [2010-07-14]:
      I support Tim's DISCUSS position.

    Telechat:

  10. IPv6 RA-Guard (Informational)
    draft-ietf-v6ops-ra-guard-06
    Token: Ron Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    IPR: Cisco System's Statement of IPR related to draft-ietf-v6ops-ra-guard-02
    Discusses/comments (from ballot 3477):
    1. Stewart Bryant: Comment [2010-07-14]:
      Just some minor issues with definition of abbreviations:
    2. Ralph Droms: Discuss [2010-07-14]:
      I found the text in section 4.1 insufficient to understand how the state machine RA-Guard works. Does this text:
      "The information gathered is compared against pre-defined criteria which qualify the validity of the RAs."
      imply deeper analysis than the rules in stateless RA-Guard?
    3. Ralph Droms: Comment [2010-07-14]:
      Style comment - move citation for SeND reference from Abstract to Introduction; give expansion of SeND abbreviation on first reference in both Abstract and body of document. As an aside, I see that "SeND" is actually abbreviated "SEND" in the title of RFC 3971 (according to the reference).
      Figure 1 isn't actually labeled "Figure 1"; I don't understand the angled lines between the links connecting the hosts and router to the L2 device.
      Just to make sure I have the correct understanding, "stateless" RA-guard could also be described as "statically-configured", in which the rules for accepting or dropping RAs are pre-defined. If I have that right, and it wasn't quite clear to me when I read the description, it might help the reader to add an example of the static rules used in stateless RA-guard.
    4. Adrian Farrel: Discuss [2010-07-15]:
      Have I misunderstood something? This looks like a layer violation. If I understand correctly, a layer 2 device is asked to examine the content of the data it is forwarding in order to provide a filter to remove unwanted RAs. Why is this considered acceptable?
    5. Adrian Farrel: Comment [2010-07-15]:
      The RFC Editor will make you remove the citations from the Abstract.
    6. Russ Housley: Comment [2010-07-12]:
      Please consider the editorial comments in the Gen-ART Review by Miguel Garcia on 2010-07-12.
    7. Tim Polk: Discuss [2010-07-14]:
      (1) Has the SAVI wg looked at the SEND-based solution? It seems reasonably straightforward, but does overlap.
      (2) This may be clear to a reader with expertise in the field, but I found the state machine in section 4.1 rather confusing.
      (a) Transitions between States 2, 3, and 4 are not clear. what are the conditions where RA Guard should transition from 2 to state 3 or 4? What about transitions out of state 3 or 4?
      (b) Further, State 2 (LEARNING) ends with the following text: "In this state, the RA-Guard enabled device or interface is either blocking all RAs until their validity is verified or, alternatively it can temporarily forward the RAs until the decision is being made."
      Given that State 2 can block or forward RAS, how does LEARNING differ from the BLOCKING and FORWARDING states?
    8. Sean Turner: Comment [2010-07-14]:
      I support Tim's DISCUSS position.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Fundamental Elliptic Curve Cryptography Algorithms (Informational)
    draft-mcgrew-fundamental-ecc-03
    Token: Tim Polk
    IPR: Certicom's Statement of IPR regarding draft-mcgrew-fundamental-ecc-03
    Discusses/comments (from ballot 3470):
    1. Ralph Droms: Comment [2010-07-15]:
      This text from the Introduction could be a little clearer: "Its intent is to provide the Internet community with a summary of the basic algorithms that predate any specialized or optimized algorithms, which can be used as a normative specification."
      Is this document intended for use as a normative specification or is it intended to provide pointers to other documents that can be used as normative specifications?
    2. Russ Housley: Comment [2010-07-14]:
      Section 3.3.1 (Discriminant) includes: "For each elliptic curve group, the discriminant - 16*(4*a^3 + 27*b^2) must be nonzero modulo p [S1986]; ..."
      I agree with the observation by Vijay Gurbani in the Gen-ART Review on 14-July-2010 that the hyphen can be misread as a minus sign. I suggest replacing placing "16*(4*a^3 + 27*b^2)" in commas.
      Section 3.3.2 (Security) begins: "Security is highly dependent on the choice of these parameters. This section gives normative guidance on acceptable choices. See also Section 10 for informative guidance."
      This use of "normative" in an Information RFC is unusual. I suggest the section be renamed and the rewording or removal of this paragraph. I propose "Choosing Secure ECC Parameters" as a useful section name.
      In section 9: s/May, 1994/May 1994/

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions Via RFC Editor

3.3.1 New Items

  1. A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem (Informational)
    draft-irtf-p2prg-alto-survey-05
    Token: Peter Saint-Andre
    Note: Stefano Previdi <sprevidi@cisco.com> is the document shepherd.
    Discusses/comments (from ballot 3454):
    1. Adrian Farrel: Discuss [2010-07-15]:
      I was disappointed that Section 5 is so thin and that the only mention of security issues is found in Section 4.2.
      If there is no literature on the security considerations for ALTO then I think this should be pulled out as a major sub-section of section 4. On the other hand, if there is prior work on security, it needs to be referenced in section 5.
    2. Adrian Farrel: Comment [2010-07-15]:
      Abstract uses "traditionally" where Introduction uses "originally". "Traditional" jars a little given the relatively short history.

    Telechat:

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. Open Research Issues in Internet Congestion Control (Informational)
    draft-irtf-iccrg-welzl-congestion-control-open-research-07
    Token: Russ Housley
    Note: Wesley Eddy (weddy@grc.nasa.gov) is the document shepherd.

    Telechat:

1239 EDT break

1244 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Port Control Protocol (pcp)
    Token: Jari

    Telechat:

  2. Authority-to-Citizen Alert (atoca)
    Token: Robert

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Transparent Interconnection of Lots of Links (trill)
    Token: Ralph

    Telechat:

4.2.2 Proposed for Approval

  1. Kitten (GSS-API Next Generation) (kitten)
    Token: Tim

    Telechat:

  2. Host Identity Protocol (hip)
    Token: Ralph

    Telechat:

5. IAB News We can use

  1. Lars: we seem to be having less interaction; should we talk about that Russ: let's talk about that Sunday lunch at Maastricht

6. Management Issues

  1. Designated expert for IMAP Keywords registry (Peter Saint-Andre)

    Telechat:

  2. Discussion of Historical Meeting Data (Russ Housley)

    Telechat:

  3. ISIS IANA designated experts (Stewart Bryant)

    Telechat:

  4. IANA #351929 (Michelle)

    Telechat:

  5. Scheduling SALUD WG (Robert)

    Telechat:

7. Agenda Working Group News

1406 EDT Adjourned



Appendix: Snapshot of discusses/comments

(at 2010-07-15 08:30:25 PDT)

draft-ietf-pkix-certimage

  1. Ralph Droms: Discuss [2010-07-15]:
        After a little reflection, I decided to change this point to a DISCUSS...
    
    Following up on Peter's first DISCUSS point, without additional description of
    how the information that might be represented in the certimage, I don't
    understand how these points from the Security Considerations might be enforced:
    
      A bad performing CA may for example;
    
          - include information in graphical form that is in conflict with
            information in provided text based attributes or other name
            forms
    
    Another nit: s/;/:/ above.
    
       Certificates, and hence their cert images, are commonly public
       objects and as such usually will not not contain privacy sensitive
       information.  However, when a cert image that is referenced from a
       certificate contains privacy sensitive information appropriate
       security controls should be in place to protect the privacy of that
       information. Details of such controls are outside the scope of this
       document. 
        
  2. Ralph Droms: Comment [2010-07-15]:
    Nit: OK, so I've learned to live with (or at least stop complaining about) the
    citation syntax "... as defined in [RFC FOO]" because of the availability of
    hyperlinks (in some representations) and the convenience of clicking through to
    the cited reference.  But I can't parse this syntax: "...to that [RFC5280]
    certificate...".  Is "[RFC5280]" an adjective describing a kind of certificate?
  3. Adrian Farrel: Comment [2010-07-15]:
    I was disappointed to find that this draft has nothing to do with 
    reliability of magicians.
  4. David Harrington: Comment [2010-07-12]:
    
        
  5. Alexey Melnikov: Discuss [2010-07-13]:
        This is a fine document and I generally support its publication:
    
    3) I have some small set of issues on RFC 3709, which would have been DISCUSS
    level material if I were to review it for IESG. So this is DISCUSS DISCUSS (i.e.
    I want to discuss it with the rest of IESG):
    
    In Section 4.1 of RFC 3709:
    
    LogotypeDetails ::= SEQUENCE {
       mediaType       IA5String, -- MIME media type name and optional
                                  -- parameters
    
    The format of this field is not specified. This turned out to be an interop
    problem in some other similar cases.
    
       logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
       logotypeURI     SEQUENCE SIZE (1..MAX) OF IA5String }
    
    4) Process related issue: image/svg+xml MIME type is not registered in the IANA
    MIME type registry.
    
    5) (Thanks to Robert)
    
    In Section 5.2:
    
       The referenced SVG file MAY be provided in GZIP [RFC1952] compressed
       form as an SVGZ file according to section 1.2 in SVG 1.1 [SVG]. Hash
       over the SVGZ file is calculated over the decompressed SVG content
       with canonicalized EOL characters (<LF>) as specified above.
    
    This would require a separate MIME type registration. I don't think it is Ok to
    just reuse image/svg+xml. 
        
  6. Alexey Melnikov: Comment [2010-07-13]:
    1) 5. Embedded images
    
       The certificate image otherLogos type MAY be stored within the
       logotype extension using the "data" URL scheme defined in RFC 2397
       [RFC2397] if the logotype image is provided through direct
       addressing, i.e. the image is referenced using the LogotypeDetails
       structure.
    
    To clarify: this document doesn't update RFC 3709 to allow use of "data" in
         1) Community logotype
         2) Issuer organization logotype
         3) Subject organization logotype
    ?
    
    2) 4.2. PNG
    
       If a certificate image is provided as a bit mapped image, the PNG
       [ISO15948] format SHOULD be used.
    
       PNG images are identified by the following mediaType in
       LogotypeDetails:
    
          image/png
    
    It is a shame that there is no RFC that describe this MIME type. But this is not
    a problem of this document.
    
    3) I have some small set of issues on RFC 3709, which would have been a COMMENT
    level material if I were to review it for IESG:
    
    In Section 4.1 of RFC 3709:
    
    In Section 4.1 of RFC 3709:
    
    LogotypeImageInfo ::= SEQUENCE {
       type            [0] LogotypeImageType DEFAULT color,
       fileSize        INTEGER,  -- In octets
       xSize           INTEGER,  -- Horizontal size in pixels
       ySize           INTEGER,  -- Vertical size in pixels
       resolution      LogotypeImageResolution OPTIONAL,
       language        [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag
    
    I have to say that I don't see much point in tagging *images* with a language
    tag. If the image is in a format like PDF, then one would hope that language
    tagging is possible in the document itself. If the image is in a format like
    text/plain, then it is not really an image.
    
    But I suppose this is mostly harmless, as long as any language tagging
    information in the media itself overrides this value.
    So I think this is
    something that needs to be clarified if RFC 3709 is updated.
    
     [...]
    
       When using indirect addressing, the URI (refStructURI) pointing to
       the external data structure MUST point to a binary file containing
       the DER encoded data with the syntax LogotypeData.  The referenced
       file name SHOULD include a file extension of "LTD".
    
    This should have been a proper MIME type registration. I don't think it is
    possible to just register a file extension.
  7. Dan Romascanu: Discuss [2010-07-14]:
        In Section 3: 
    
    The optional LogotypeImageInfo structure is defined in [RFC3709] and
       is included here for convenience:
    
          LogotypeImageInfo ::= SEQUENCE {
            type          [0] LogotypeImageType DEFAULT color,
            fileSize      INTEGER,  -- In octets
            xSize         INTEGER,  -- Horizontal size in pixels
            ySize         INTEGER,  -- Vertical size in pixels
            resolution    LogotypeImageResolution OPTIONAL,
            language      [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag
    
    Alexey already observed in a COMMENT that it looks useless to tag a logo image
    for language. Moreover, RFC 3709 is using the RFC 3066 Lamnguage Tag, while 3066
    was obsolete by RFC 4646 which was later obsoleted by RFC 5646. I wonder if this
    would not rather cause problems than help. 
        
  8. Dan Romascanu: Comment [2010-07-14]:
    
        
  9. Peter Saint-Andre: Discuss [2010-07-14]:
        1. What in the world is "a visual representation of a certificate"? This notion
    is not explained very clearly in the spec. Is it a company logo for the
    organization to which the cert was issued? Is it something like a "tag cloud"
    <http://en.wikipedia.org/wiki/Tag_cloud> that maps out the information contained
    in the cert? Is it a geeky form of kitten auth
    <http://thepcspy.com/read/the_cutest_humantest_kittenauth/>? Is it whatever the
    issuer decides to include? Please explain this intriguing idea in more concrete
    terms or at least provide examples.
    
    2. Memorability and therefore perhaps security would be enhanced if a visual
    representation were assigned by the relying party. This would result in
    something like a petname system
    <http://www.skyhunter.com/marcs/petnames/IntroPetNames.html> instead of using an
    issuer-imposed or even subject-created representation that is common to all
    relying parties. It might make sense to mention this alternate (or
    complementary) approach in the security considerations. 
        
  10. Peter Saint-Andre: Comment [2010-07-14]:
    1. There are many violations of subject-verb agreement, such as "Images
    incorporated according to RFC 3709 provides" (instead of "provide").
  11. Robert Sparks: Comment [2010-07-13]:
    Support Alexey's Discuss points regarding the mime type
    
    Please consider an additional sentence or so at the start of the security
    considerations section explicitly reinforcing that a CA needs to understand the
    security considerations section of 3709 before signing a certificate using this
    extension.
  12. Sean Turner: Discuss [2010-07-13]:
        The -06 version added RFC 1952 as a normative reference.  This RFC is not in the
    DOWNREF registry
    (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry) and
    (obviously) wasn't part of the IETF LC, which was on the -02 version.  A second
    abbreviated IETF LC is required to call out this DOWNREF. 
        
  13. Sean Turner: Comment [2010-07-13]:
    
      

draft-ietf-sipping-rtcp-summary

  1. Lars Eggert: Comment [2010-02-02]:
    
        
  2. Adrian Farrel: Comment [2010-02-02]:
    Unclear on the use use of references within the ABNF comments.
    Sometimes they are used, and sometimes not.
    Suspect that (as per MIB Modules) they should not be used.
    
    Wonder if the Proto Writeup should be updated. This would certainly have caught
    Alexey's issues with the ABNF.
  3. David Harrington: Discuss [2010-07-14]:
        1) in 3.2 the reporter should send an options message to ensure support of the
    publish message; what happens if should the reporter do if it is not supported?
    
    2) in 4.6.2.4, s/can/MAY/ 
        
  4. David Harrington: Comment [2010-07-14]:
    1) in section 3.2, where is "unmanaged" defined?
    
    2) in 3.2, s/recommended/RECOMMENDED/
    
    3) in 3.3., where is report bodies defined?
    
    4) in 4.5, "always shares" - with whom?
    
    5) in 4.6.2.3.8, where is "fmtp" defined?
  5. Russ Housley: Comment [2010-07-13]:
      Some of the comments in the Gen-ART Review by Scott Brim were
      not addressed.  Please consider them.
    
      In Secrion 3.4 (Overload Avoidance) has small editorial issues
    
      - Typo: "MUST send a 503 Service Unavailable or other 5xx esponse"
    
      - "on these responses and respect the retry after time interval."
        Perhaps it should say "Retry-After."
  6. Alexey Melnikov: Comment [2010-03-10]:
    [Updated as per draft-ietf-sipping-rtcp-summary-10.txt]
    
    The document shepherd/sponsoring AD should rerun
    <http://tools.ietf.org/tools/bap/abnf.cgi> on the ABNF from this document.
    
           ; SignalLevel will normally be a negative value
           ; the absence of the negative sign indicates a positive value
    
    I think "." is missing at the end of the previous line.
    
           ; where the signal level is negative, the sign MUST be
           ; included.This metric applies to the speech signal decoded
           ; from the received packet stream.
    
           SignalLevel = "SL" EQUAL (["-"] 1*2DIGIT)
    
           RLQEstAlg = "RLQEstAlg" EQUAL word ; "P.564", or other
    
    Some pointer where P.564 is defined would be good hear.
    
    4.6.2.2.  Timestamps
    
       Following SIP and other IETF convention, timestamps are provided in
       Coordinated Universal Time (UTC) using the ABNF format provided in
       RFC 3339 [7].
    
    ABNF for timestamps allows for timezones, so it would be good to mention
    in the ABNF section that timezones other than "Z" are not allowed.
    
    4.6.2.11.2.  RLQEstAlg
    
       This field provides a text name for the algorithm used to estimate
       ListeningQualityR.
    
    Is there an IANA registry for such algorithms, or does this field
    contain free form text?
    
    4.6.2.11.4.  RCQEstAlg
    
       This field provides a text name for the algorithm used to estimate
       ConversationalQualityR.
    
    As above.
    
    4.6.2.11.6.  ExtRInEstAlg
    
       This field provides a text name for the algorithm used to estimate
       ExternalR-In.
    
    As above.
    
    4.6.2.11.8.  ExtROutEstAlg
    
       This field provides a text name for the algorithm used to estimate
       ExternalR-Out.  Conversion of RFC3611 reported MOS scores for use in
       reporting MOS-LQ and MOS-CQ MUST be performed by dividing the RFC3611
       reported value by 10 if this value is less than or equal to 50 or
       omitting the MOS-xQ parameter if the RFC3611 reported value is 127
       (which indicates unavailable).
    
    All but the first sentence don't seem to belong to this section.
    
    4.6.2.11.11.  MOSCQEstAlg
    
       This field provides a text name for the algorithm used to estimate
       MOS-CQ.
    
    Is there an IANA registry for such algorithms, or does this field
    contain free form text?
  7. Tim Polk: Comment [2007-07-03]:
    In 4.2.6.10, the specifications for both Round Trip Delay and End System Delay
    end with
    
    "This parameter does no require any conversion."
    
    Perhaps "no" should be "not" in both cases?
  8. Dan Romascanu: Comment [2009-07-31]:
     Section 4.6.2.3 and 4.6.2.13 - I do not understand what is the usage of the
    following:
    
    Payload Desc
    
    This parameter is not mapped from any specific SDP 
    or RTP field; provides a text description of the 
    Payload Type/codec.
    
      RLQEstAlg 
    
      This field provides a text description of the algorithm used 
      to estimate ListeningQualityR.  
    
      RCQEstAlg 
    
      This field provides a text description of the algorithm used 
      to estimate ConversationalQualityR
    
    How is interoperability ensured without a proper register that defines what text
    applies to each algorithm?
  9. Peter Saint-Andre: Comment [2010-07-14]:
    1. Section 4.4 talks about subscription duration but not about when to cancel a
    subscription (by either the reporter or the collector); for example, it might be
    appropriate to recommend cancelling the subscription when the voice session had
    ended?
    
    2. The RemoteID "bill@elpmaxe.org" does not conform to RFC 2606.
    
    3. The references to draft-ietf-sipping-config-framework and RFC 5389 appear to
    be informative, not normative.

draft-ietf-nsis-applicability-mobility-signaling

  1. Adrian Farrel: Discuss [2010-07-15]:
        A small but important point that can be fixed in an RFC Editor note.
    
    Section 1
    
       currently there two standardized NSLP protocols, the QoS
       NSLP [draft-ietf-nsis-qos-nslp], and the NAT/Firewall NSLP
       [draft-ietf-nsis-nslp-natfw]
    
    s/standardized/specified/ 
        
  2. Adrian Farrel: Comment [2010-07-15]:
    This is an example of a well-written document that is sometimes hard to parse
    becuse of small issues with the use of English. I know that the RFC Editor will
    make a pass for this type of issue, but it would have been (could still be!)
    good to get a native speaker from the WG to take an editorial pass on the
    document. The risks associated with the RFC Editor correcting text without the
    knowledge of the technical details are considerable.
  3. Russ Housley: Comment [2010-06-25]:
    
      

draft-ietf-eai-mailinglist

  1. David Harrington: Discuss [2010-07-14]:
        1) in section 5, should "can only" be "MUST only"? 
        
  2. David Harrington: Comment [2010-07-14]:
    
        
  3. Tim Polk: Comment [2010-07-15]:
    I support Peter's discuss issue 5 (also appearing in Dan's comment) regarding
    the security
    considerations.  The attacks Peter lists seem to fall outside the
    scope of 4952's security
    considerations, and should be addressed in this
    document.
  4. Dan Romascanu: Comment [2010-07-14]:
    In the OPS-DIR review Mehmet Ersue made the observation that the Security
    Consideration section refers to RFC 4952, and that no further security
    considerations are raised by this document. However, the security consideration
    section in 4952 seems to deal with various threats resulting from the expansion
    of the charaters sets in messages and specifically in addresses and headers, but
    does not deal at all with mail lists. I am wondering if there are not specific
    threats related to mail lists. Did the security reviewer and ADs see and agree
    that there is no potential problem here?
  5. Peter Saint-Andre: Discuss [2010-07-14]:
        Overall this is a clear and carefully-constructed specification. I have a few
    questions that I'd like answered before recommending it for approval.
    
    1. Section 5 states: "These mailing list header fields contain URLs." However,
    that is not true of List-ID.
    
    2. This statement might be confusing to readers:
    
        ... discussion on whether internationalized domain 
        names should be percent-encoded or puny-coded, is 
        ongoing; see [IRI-bis]
    
    Does it make sense to reference the IDNAbis work here, since it is concluded and
    directly covers the topic of internationalized domain names (as opposed to the
    less direct discussion in IRI-bis)? Will interoperability suffer if this
    specification does not make a recommendation regarding percent-encoded vs. puny-
    coded IDNs?
    
    3. The paragraph about List-ID at the end of Section 5 does not make a
    recommendation. For example, it could say: "Therefore, the value of the List-ID
    header field SHOULD NOT contain ASCII encodings of non-ASCII values." Did the WG
    have consensus to avoid making a recommendation here?
    
    4. Also, the paragraph about List-ID at the end of Section 5 does not mention
    whether it is reasonable to include non-ASCII values that have not been encoded
    into ASCII. Was this also the intent of the WG?
    
    5. To expand on Dan Romascanu's COMMENT regarding the security considerations,
    RFC 4952 does not seem to discuss the use of email addresses for authorization
    decisions. Given that a mailing list subscription is one kind of authorization
    decision, it seems possible that an attacker could subscribe to a mailing list
    using a UTF-8 address whose alt-address matches the (non-UTF-8) address of a
    victim, thus potentially preventing the victim from subscribing to the list.
    Similarly, the attacker could send messages from its i18n-address but
    subscribers that are not UTF8SMTP-aware might attribute the message to the
    victim's (non-UTF-8) address. Finally, the list itself could use an alt-address
    that matches the (non-UTF-8) address of another list. Are these attacks
    possible? If so, are there guidelines regarding these cases in RFC 4952 but I'm
    simply missing them? Does this spec need to have some text about the potential
    mismatch between a UTF-8 address and an alt-address? 
        
  6. Peter Saint-Andre: Comment [2010-07-14]:
    
      

draft-ietf-opsawg-mpls-tp-oam-def

  1. Stewart Bryant: Comment [2010-07-12]:
    I am not sure that "ambivalence" is the right word:
    
    However there is some ambivalence in the definition and scope of the
    term "Operation".
    
    Did the authors mean "ambiguity" ?
  2. David Harrington: Discuss [2010-07-12]:
        1) I found the purpose of this document to be rather muddled. In the Abstract,,
    it says "This document provides a definition ... for use in all future IETF
    documents that refer to OAM."
    
    The Introduction says "The main purpose of this document is to provide a
    definition ... that is useful for MPLS."
    
    I object to the text that says this document provides a definition for use in
    all future IETF documents.
    
    •The IETF as a whole does not have consensus on the technical approach or
    document. There are cases where individual working groups or areas have forged
    rough consensus around a technical approach which does not garner IETF
    consensus. An AD may DISCUSS a document where she or he believes this to be the
    case. While the Area Director should describe the technical area where consensus
    is flawed, the focus of the DISCUSS and its resolution should be on how to forge
    a cross-IETF consensus."
    
    I suggest that if we want to define new terminology for all future IETF
    documents that discuss OAM, then the title should be changed to "New Required
    Terminology for Referencing OAM in IETF Documents" and make it a Proposed
    Standard.
    
    Otherwise, this is an Informational document that provides a definition of OAM
    for use in MPLS-TP documents. Other IETF documents MAY choose to use the same
    definition when discussing OAM. I think the title should be changed to be clear
    about the purpose and scope of the applicability of this document. 
        
  3. David Harrington: Comment [2010-07-12]:
    I think this document should clearly seoarate what exists in practice across
    SDOs and what will be the new IETF-wide standard for use of these acronymns. I
    find it unclear about where section 2 falls on this point. Section 3 and 4
    define terminology for the MPLS-TP effort, but the section titles limit it to
    the MPLS-TP effort, and the Informational status of the document makes this less
    than a standard.
    
    2) Various flavors of OAM from multiple SDOs have started coming into play. If
    the document provides a definition for use in all future IETF documents that
    refer to OAM, are the other SDOs agreeing to use the ***SAME*** definition in
    all their future documents as well? If not, then I think it highly likely that
    future IETF documents that deal with cross-SDO OAM are likely to have the same
    problem we face now with MPLS-TP.
    
    3) "The ITU documents also clearly define a maintenance philosophy." - Does this
    mean that the IETF hereby adopts the same maintenance philosophy for all future
    IETF documents? or for MPLS-TP efforts? I don't think the IETF has agreed to
    that. Are the documents that define this maintenance philosophy freely
    available?
  4. Russ Housley: Comment [2010-07-12]:
      Please consider the editorial comments in the Gen-ART Review by
      Francis Dupont on 2010-07-01.

draft-ietf-martini-reqs

  1. Lars Eggert: Comment [2010-07-09]:
    INTRODUCTION, paragraph 5:
    >    This work is being discussed on the martini@ietf.org mailing list.
    
      Remove.
  2. Alexey Melnikov: Comment [2010-07-11]:
    Section 3 is hard to follow for somebody not involved with SIP on a daily basis.
    I suggest adding some ASCII art to demonstrate relationship between entities and
    possibly some examples of messages demonstrating issues.

draft-ietf-csi-proxy-send

  1. Jari Arkko: Comment [2010-07-01]:
    This is a very well written specification and it was nice to read it.
    I did not spot any major or minor issues.
    
    However, we have in the past discussed the question of compatibility
    with non-SEND, SEND, and proxy SEND nodes. I think the current 
    specification is now reasonable in that respect. However, I think that
    the decision to employ two levels of security in proxied messages (ND
    or SPND) has lead to the rules that are not optimal in all circumstances.
    In particular, the document says:
    
       As a rule of thumb, if the proxied nodes can return to the link in
       which the proxy operates, the Secure ND Proxy MUST only generate PS
       options on behalf of nodes with SEND capabilities (i.e. that they
       could use SEND to defend their messages if being in the same link
       than the proxy, either RFC3971 nodes or SPND nodes).  This is
       relevant to allow nodes preferring secured information over unsecured
       one ...
    
    What this essentially says is that unless there is knowledge about the
    network structure and movement patterns, secure proxy cannot proxy
    plain old ND messages with security at all. I happen to believe that
    this situation is the typical situation. 
    
    If you had provided one additional bit of information in the secure
    proxy messages about the SEND/non-SEND status of the original message,
    there would not be this limitation. You could have amended the
    backwards compatibility rules of SEND to prefer native SEND messages
    over proxied SEND messages over unsecured ND messages.
    
    I would like to ask the authors to consider this before final approval
    of the document as an RFC.
  2. Alexey Melnikov: Discuss [2010-07-01]:
        This is a minor point and I would like to have a quick discussion on whether I
    am right or wrong here:
    
    Does Section 5.2.2 item 1 contradict text in Section 5.2.1? 
        
  3. Alexey Melnikov: Comment [2010-07-01]:
    The last sentence in section 5.2.2 looks out of sync when compared to the text
    in item 1 of the same section.
  4. Tim Polk: Comment [2010-07-15]:
    I support Sean's discuss.
  5. Sean Turner: Discuss [2010-07-13]:
        The SECDIR review pointed out a number of changes that are needed.  The author
    agreed.  I'll remove this DISCUSS once a new version (or an RFC editors note) is
    posted to incorporate the agreed changes.
    
    The SECDIR review also pointed out issues with this document and with draft-
    ietf-csi-send-cert.  That discussion has not completed. 
        
  6. Sean Turner: Comment [2010-07-13]:
    
      

draft-ietf-ipsecme-ipsec-ha

  1. Lars Eggert: Comment [2010-06-30]:
    INTRODUCTION, paragraph 4:
    >    An agreed terminology, problem statement and
    >    requirements will allow the IPSECME WG to consider development of
    >    IPsec/IKEv2 mechanisms to simplify cluster implementations.
    
      Suggest to remove text that talks about IETF WGs, which are after all
      ephemeral, from this document before publication as an RFC.
  2. David Harrington: Comment [2010-06-30]:
    1) in 3.7, I think it would make the document easier to read if you spelled out
    the LS and HS acronyms.
    
    2) "the other half of the flow" - s/the the/the/
    is "the other half" a response,
    or ...; can you clarify, "the other half" doesn't seem very specific.
    
    3) in 3.8 "this looks weird". I don't think the problem is that it looks weird;
    it's that the peer might respond to the fact that it looks weird and do
    something like discard it or filter it, and this would cause problems. Simply
    saying "it looks weird" doesn't really describe this in a clear and unambiguous
    manner.
    
    4) "Reply packets might arrive ..." I think this should be discussed in the
    security considerations
    
    5) in section 2, PAD needs to be spelled out or referenced.
    
    6) aren't RFC2119, IKEv2bis and 4306 normative? Others may be also, but these
    seem obvious.
  3. Alexey Melnikov: Comment [2010-06-27]:
    I think some of the references should be Normative.

draft-ietf-v6ops-v6inixp

  1. Jari Arkko: Comment [2010-07-15]:
    Do IXPs normally run SIP gateways (Section 7)? That would be news
    to me...
    
    Ari Keränen's review noted some editorial issues:
    
    2. Switch Fabric Configuration
    
           2.  independent VLAN (Virtual Local Area Network): when an IXP
            logically separates IPv4 and IPv6 traffic in different VLANs.
    
    Missing VLAN reference.
    
    3. Addressing Plan
    
        o  IXP may decide that LANs should (attempt to be) be globally
    
    The word "be" twice in a row.
    
        Additionally, possible IXP external services (such as dns, web pages,
        ftp servers)
    
    DNS and FTP not capitalized.
    
    4.1. Multicast Support and Monitoring for ND at an IXP
    
    "ND" not expanded (mentioned first time). Probably would be better to do 
    it somewhere before the title.
  2. Alexey Melnikov: Comment [2010-07-11]:
    Slightly pedantic comments:
    
    In Section 3, last paragraph:
    
       Additionally, possible IXP external services (such as dns, web pages,
       ftp servers) need to be globally routed. 
    
    s/dns/DNS
    s/ftp/FTP
    
    Also add informative references for these.
    
    More acronyms with no references in Section 7.
  3. Dan Romascanu: Comment [2010-07-14]:
    >  However, some management
       functions may require explicit IPv6 support (such as switch
       management, SNMP [RFC3411] support or flow analysis exportation) and
       this should be assessed by the IXP operator.
    
    I do not understand what switch management means here, and support of SNMP and
    IPFIX (which I suspect is what is meant by flow analysis exportation) should be
    transparent to the network layer.

draft-ietf-nsis-tunnel

  1. Adrian Farrel: Comment [2010-07-15]:
    Section 3.1
    
       The following definition of IP tunneling is derived from [RFC2473]
       and adapted for both IPv4 and IPv6.
    
    This is a bit odd given the existence of RFC 1853.
  2. Russ Housley: Comment [2010-06-28]:
      Pleae consider the editorial comments from the Gen-ART Review by
      Francis Dupont on 2010-06-15.  The review can be found at:
    
        http://www.softarmor.com/rai/temp-gen-art/
        draft-ietf-nsis-tunnel-11-dupont.txt
  3. Peter Saint-Andre: Comment [2010-06-28]:
    It appears that the following references might be normative, not informative:
    [RFC4080], [RFC2473], [RFC2113], [RFC2711], [RFC2746], [RFC3697], [RFC4081].
    Please consult http://www.ietf.org/iesg/statement/normative-informative.html for
    guidelines regarding the difference between normative and informative
    references, and consider whether some of the foregoing references would best be
    changed to normative.

draft-ietf-v6ops-rogue-ra

  1. Stewart Bryant: Comment [2010-07-14]:
    It's not clear what he following means:
    
    "But for accidental problems like Windows ICS and 6to4, it could be useful." 
    
    In particular references are needed.
    
    ===========
    In Section 5.1
    
    If a host sending rogues RAs
                           ^
    Spurious "s"
    
    ===========
    
    "In the case of Windows ICS"
    
    Needs a reference (and an expansion of "ICS"
    
    ===========
    
    Section 8
    
    "Where managed switches are no available"
    
    S/no/not/
    
    Then next line I think s/moreso/more so/
  2. Ralph Droms: Comment [2010-07-14]:
    Stig is now with Cisco.
  3. Tim Polk: Discuss [2010-07-14]:
        This is a discuss-discuss, as it conflicts in part with wg consensus.  The
    security considerations
    section states:
    
    7.  Security Considerations
    
       This document is Informational.  It does not describe solutions for
       malicious attacks on a network for which malicious RAs may be part of
       a broader attack, e.g. including malicious NA messages.
    
    While it may be reasonable to place malicious RAs out of scope for the
    corresponding protocol
    work, I do not believe we should exclude it from the
    security considerations!  I understand
    that the wg decided not to attempt to
    resolve this problem, but a description of the malicious
    RA problem, and the
    extent that it overlaps with the administrator and user configuration
    issues
    that are addressed would be helpful.
    
    This seems reasonable, since a robust defense against administrator and user
    configuration
    issues should mitigate some rogue RAs generated via malicious
    configuration.  Understanding
    which malicious rogue RAs are not addressed might
    be helpful in deciding whether to deploy
    this technology. 
        
  4. Tim Polk: Comment [2010-07-14]:
    
        
  5. Dan Romascanu: Comment [2010-07-14]:
    I found this document to be quite clear and informative. I have a few comments
    that could improve readability:
    
    1. Many acronyms lack expansion at first occurance. For example because NA is
    not expanded the last paragraph in section 1 is hard to understand. Also lacking
    - VLAN, DHCPO, SeND, ICS.
    
    2. It would be good to provide references to the tools descreibed in Section 3.8
    
    3. Section 3.10 - not clear what exactly is meant by 'different layer 2 medium'
    - if this means 'physically separate layer 2 network' than the later terminology
    is better.
  6. Sean Turner: Comment [2010-07-14]:
    I support Tim's DISCUSS position.

draft-ietf-v6ops-ra-guard

  1. Stewart Bryant: Comment [2010-07-14]:
    Just some minor issues with definition of abbreviations:
    
    "When operating IPv6 in a shared L2 network segment without complete
    SeND support by all devices"
    
    Need a REF to SeND - it is in the Abstract but not in the main body of the doc.
    
    =======
    
    "RA-Guard can be seen as a superset of SEND"
    s/SEND/SeND/   ?
    
    =======
    
    In section 4.2
    
    CGA, CPS, CPANTP and CRL all used without expansion or definition
    
    =======
  2. Ralph Droms: Discuss [2010-07-14]:
        Following up and supporting Tim's DISCUSS, I found the text in section 4.1
    insufficient to understand how the state machine RA-Guard works.  Does this
    text:
    
             The information gathered is compared
             against pre-defined criteria which qualify the validity of the
             RAs.
    
    imply deeper analysis than the rules in stateless RA-Guard? 
        
  3. Ralph Droms: Comment [2010-07-14]:
    Style comment - move citation for SeND reference from Abstract to Introduction;
    give expansion of SeND abbreviation on first reference in both Abstract and body
    of document. As an aside, I see that "SeND" is actually abbreviated "SEND" in
    the title of RFC 3971 (according to the reference).
    
    Figure 1 isn't actually labeled "Figure 1"; I don't understand the angled lines
    between the links connecting the hosts and router to the L2 device.
    
    Just to make sure I have the correct understanding, "stateless" RA-guard could
    also be described as "statically-configured", in which the rules for accepting
    or dropping RAs are pre-defined.  If I have that right, and it wasn't quite
    clear to me when I read the description, it might help the reader to add an
    example of the static rules used in stateless RA-guard.
  4. Adrian Farrel: Discuss [2010-07-15]:
        Have I misunderstood something? This looks like a layer violation. If I
    understand correctly, a layer 2 device is asked to examine the content of the
    data it is forwarding in order to provide a filter to remove unwanted RAs. Why
    is this conseidered acceptable? 
        
  5. Adrian Farrel: Comment [2010-07-15]:
    The RFC Editor will make you remove the citations from the Abstract.
  6. Russ Housley: Comment [2010-07-12]:
      Please consider the editorial comments in the Gen-ART Review by
      Miguel Garcia on 2010-07-12.
  7. Tim Polk: Discuss [2010-07-14]:
        (1) Has the SAVI wg looked at the SEND-based solution?  It seems reasonably
    straightforward,
    but does overlap.
    
    (2) This may be clear to a reader with expertise in the field, but I found the
    state machine in
    section 4.1 rather confusing.
    
    (a) Transitions between States 2, 3, and 4 are not clear. what are the
    conditions where
    RA Guard should transition from 2 to state 3 or 4?  What about
    transitions out of state 3 or 4?
    
    (b) Further, State 2 (LEARNING) ends with the following text:
    
             In this state, the RA-Guard enabled device or interface is
             either blocking all RAs until their validity is verified or,
             alternatively it can temporarily forward the RAs until the
             decision is being made. 
    
    Given that State 2 can block or forward RAS, how does LEARNING differ from the 
    BLOCKING and FORWARDING states? 
        
  8. Tim Polk: Comment [2010-07-14]:
    
        
  9. Dan Romascanu: Comment [2010-07-14]:
    
        
  10. Sean Turner: Comment [2010-07-14]:
    I support Tim's DISCUSS position.

draft-mcgrew-fundamental-ecc

  1. Ralph Droms: Comment [2010-07-15]:
    This text from the Introduction could be a little clearer:
    
       Its intent is to provide the Internet community
       with a summary of the basic algorithms that predate any specialized
       or optimized algorithms, which can be used as a normative
       specification.
    
    Is this document intended for use as a normative specification or is it intended
    to provide pointers to other documents that can be used as normative
    specifications?
  2. Russ Housley: Comment [2010-07-14]:
      Section 3.3.1 (Discriminant) includes:
      >
      > For each elliptic curve group, the discriminant - 16*(4*a^3 + 27*b^2)
      > must be nonzero modulo p [S1986]; ...
      >
      I agree with the observation by Vijay Gurbani in the Gen-ART Review on
      14-July-2010 that the hyphen can be misread as a minus sign. I suggest
      replacing placing "16*(4*a^3 + 27*b^2)" in commas.
      
      Section 3.3.2 (Security) begins:
      >
      > Security is highly dependent on the choice of these parameters. This
      > section gives normative guidance on acceptable choices. See also
      > Section 10 for informative guidance.
      >
      This use of "normative" in an Information RFC is unusual.  I suggest
      the section be renamed and the rewording or removal of this paragraph.
      I propose "Choosing Secure ECC Parameters" as a useful section name.
    
      In section 9: s/May, 1994/May 1994/

draft-irtf-p2prg-alto-survey

  1. Adrian Farrel: Discuss [2010-07-15]:
        Thanks for a useful document that helped me undertsand the background to ALTO.
    
    I have a small Disucss that I would like to talk through with the Security ADs. 
    
    I was disappointed that Section 5 is so thin and that the only mention of
    security issues is found in Section 4.2.
    
    If there is no literature on the security considerations for ALTO then I think
    this should be pulled out as a major sub-section of section 4. On the other
    hand, if there is prior work on security, it needs to be referenced in section
    5. 
        
  2. Adrian Farrel: Comment [2010-07-15]:
    One small nit...
    
    Abstract uses "traditionally" where Introduction uses "originally".
    "Traditional" jars a little given the relatively short history.

draft-irtf-iccrg-welzl-congestion-control-open-research