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

Valid HTML 4.01 Strict

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