IESG Narrative Minutes

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

Narrative scribe: Barry Leiba (The scribe was sometimes uncertain who was speaking.)

Corrections from:

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. MPLS Upstream Label Assignment for LDP (Proposed Standard)
    draft-ietf-mpls-ldp-upstream-09
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    IPR: Juniper's Statement of IPR related to draft-ietf-mpls-ldp-upstream-03
    Discusses/comments (from ballot 3375):
    1. Stewart Bryant: Comment [2010-12-02]:
      (blank)
    2. David Harrington: Comment [2010-11-30]:
      SECTION 3: s/MUST be carried only LDP initialization messages/MUST be carried only in LDP initialization messages/
    3. Russ Housley: Comment [2010-11-28]:
      The Gen-ART Review by Avshalom Houri on 13-Oct-2010 includes some editorial suggestions. Please consider them.
    4. Sean Turner: Comment [2010-11-30]:
      Section 4: Shouldn't the two "optional"s be "OPTIONAL"? They're indicating support requirements.

    Telechat:

  2. An Alternative Connection Model for the Message Session Relay Protocol (MSRP) (Proposed Standard)
    draft-ietf-simple-msrp-acm-09
    Token: Gonzalo Camarillo
    Note: Hisham Khartabil (hisham.khartabil@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3416):
    1. Lars Eggert: Comment [2010-11-30]:
      five Nits
    2. Adrian Farrel: Comment [2010-12-01]:
      Acronyms need to be expanded in the main text on first usage (regardless of their use in the Abstract).
      Section 3: "Support of this specification is optional for MSRP user agents in"
      Is that "OPTIONAL"?
      Section 4.2.2: "In accordance with [RFC4145], if the a=setup attribute value is "active", the port number value should be 9."
      s/should/SHOULD/ ?
    3. Sean Turner: Comment [2010-11-30]:
      Sec 1: Spell out SDP on first usage.
      Sec 3: r/optional/OPTIONAL? It's specifying support requirements.
      Sec 4.2.1: r/An MSRP UA must support the a=setup.../An MSRP UA MUST support the a=setup...

    Telechat:

  3. Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sipcore-reinvite-07
    Token: Robert Sparks
    Note: Paul Kyzivat (pkyzivat@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3440):
    1. Adrian Farrel: Comment [2010-12-02]:
      This issue is not quite a Discuss for me, but I would welcome considetation by the authors and resposnsible AD to wee whether any changes can be made to clarify the document.
      I struggled to see the separation between this document and RFC 3261.
      Many of the procedures described in this documet are already described in RFC 3261 and I wondered (for example, in the event of a mistake in this document) which provides the normative description.
      Additionally, this document describes itself as "clarifying" RFC 3261. That implies (to me) that it does not introduce any new procedures. This would seem to me to make the document Informational (not Standards Track) and not an Update.
    2. Peter Saint-Andre: Comment [2010-11-29]:
      The description of "dialog's local target" is confusingly worded. Perhaps you could tweak the text so that it's a bit clearer, or provide an example to illustrate the concept.
    3. Sean Turner: Discuss [2010-11-30]:
      #1: Section 2: I see that in sirpcore-event-rate-control it notes that indented paragraphs don't contain normative protocol behavior. Is the same true of the indented paragraphs in this draft? I thought maybe it was just an odd formatting thing that some paragraphs are indented.
      #2: Section 3.4: "The purpose of this new offer/answer exchange is to synchronize both UAs, not to request changes that the UAS may choose to reject. Therefore, session parameters in the offer/answer exchange SHOULD be as close to those in the pre-re-INVITE state as possible."
      Why isn't it "SHOULD be the same"?
    4. Sean Turner: Comment [2010-11-30]:
      three editorial suggestions

    Telechat:

  4. Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control (Proposed Standard)
    draft-ietf-sipcore-event-rate-control-05
    Token: Robert Sparks
    Note: Adam Roach (adam@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3444):
    1. Jari Arkko: Comment [2010-12-02]:
      I have reviewed this document and placed a no-objection vote, even if I do agree with most of the issues raised by Lars and David. I do think though that despite its problems and complexity, the document is understandable enough to be reviewed. I think the right path is to fix the specific issues in the document rather than to bring the document back to the working group. I do think that the document should stick to using either rate or frequency terminology, however.
      Also, here are some review comments from Ari Keränen who I asked to take another look at the document...
    2. Ralph Droms: Discuss [2010-12-02]:
      I fall somewhere between Jari and David regarding the use of "rate" "frequencey" and "interval" terminology. I agree with Jari that the document can be reviewed and fixed with editorial updates. However, this text from section 5.2 is an example of what I think needs to be fixed, not just improved:
      "A compliant notifier MUST NOT generate notifications more frequently than the maximum rate allows for [...]"
      The specific parameter is a minimum interval, not a maximum rate. To ensure accurate compliance with the specification, the requirement must be stated in terms of the parameter, not the inverse of the parameter (which, speaking pedantically, is not as precise):
      "A compliant notifier MUST NOT generate notifications with an interval between notifications less than the currently allowed minimum interval [...]"
      Text such as this excerpt from the next paragraph is OK, but could be improved:
      "When a local policy dictates a maximum rate for notifications, a notifier will not generate notifications more frequently than the local policy maximum rate"
      which mixes frequency and rate but is still understandable and has no normative requirements langauge. I think this text would be more accurate:
      "When a local policy dictates a minimum interval for notifications, a notifier will not generate notifications more frequently than the local policy minimum interval [...]:
    3. Lars Eggert: Discuss [2010-11-30]:
      Section 6., paragraph 0: "Operation of the Minimum Rate Mechanism"
      DISCUSS: Assuming that you disallow max_interval := 0, this mechanism can still be used to get the notifier to generate a notification once per second. This can put some stress on the network as well as on the notifier. It's also questionable from the example use cases that a notification rate that is that aggressive can be useful. Can we define a useful max_interval that is larger than 1 second? If not, can we add some strong language here to caution implementers to use the lowest possible useful rate here? (This also applies to the "adaptive" variant.)
    4. Lars Eggert: Comment [2010-11-30]:
      two Nits
      Section 7.3., paragraph 5: "period: The rolling average period, in seconds. The value of the "period" parameter is chosen by the notifier, however the notifier MUST choose a value greater than the value of the "average-interval" parameter."
      Additionally, period should be several times larger than the average-interval, because otherwise, not much averaging will happen - the mechanism degrades to the non-adaptive variant.
    5. Adrian Farrel: Comment [2010-12-02]:
      Just a few nits in a document I found otherwise to be very readable...
    6. David Harrington: Discuss [2010-11-30]:
      1) The document continually refers to both rate and interval - two sides of the same coin. I find the current approach to handling this very distracting. I think the document would be clearer if you chose one perspective, explained in the terminology section how it relates to the other perspective, and then used the one perspective consistently. Maybe you should rename the parameters to reflect the rate perspective - e.g., change "min-interval" to "max-rate".
      2) 3.1 talks about "notifications that do not comply with the maximum rate". I'm not sure quite what that means - I assume it means notifications are generated faster than they are allowed to be sent. Why not say that?
      3) 3.1 says the RLS will "batch all of the buffered state changes together in a single notification only when allowed by the maximum rate." - I don't understand "when allowed by the maximum rate".
      The maximum rate is a number. How does that number "allow" batching? In addition, section 1 says "it is strictly an implementation decision whether batching of notifications is supported, and by what means." So I don't understand what "allowed by the maximum rate" means relative to the implementation decision. My impression is that "maximum rate" is being used to refer to an abstraction of the whole process, and that does not lead to clear and unambiguous standards specification.
      4) 3.1 says "The presence client can also modify the "min-interval" parameter during the lifetime of the subscription. For example, if the User Interface (UI) of the application shows inactivity for a period of time, it can simply pause the notifications by setting the "min-interval" parameter to the subscription expiration time, while still keeping the subscription alive. When the user becomes active again, the presence client can resume the stream of notifications by re-subscribing with a "min-interval" parameter set to the earlier used value."
      This text conflates the application, the UI, the user, and the presence client. These are potentially different entities - an application's database of activity might be a totally different process than its UI. I assume the presence client is an abstract fucntionality supported by an application - possibly implemented in a totally different process. and the user obviously is neither the application, nor the UI, nor the presence client. Is the presence client supposed to have a mechanism to watch the UI to see whether there is UI activity? or does it detect inactivity by monitoring protocol acivity? How exactly does it detect this- which protocols should be watched?
      5) in 3.2, "In order to control the actual state, the location application sets a minimum rate ("max-interval" parameter), i.e. a maximum time interval between two notifications."
      Again, this approach of "here, let me say this three different ways" is distracting. More important, should this text say that it sends the parameter to the RLS? or does it just set an internal parameter paid attention to at the presence client?
      6) 3.3 says "The "average-interval" parameter value is used by the notifier to dynamically calculate the actual maximum time ("timeout" parameter) between two notifications."
      Is the maximum time "timeout" parameter the same parameter called "max-interval" in section 1? Is"actual maximum time" the same as the configured max-interval? Or is the actual maximum time an imperical measurement value about the "actual" maximum time in practice?
      7) 4.1 says "If the subscriber did not include at least one of the "min-interval, "max-interval", or "average-interval" header field parameters in the most recent SUBSCRIBE request in a given dialog, it MUST NOT include an Event header field with any of those parameters in a 2xx response to a NOTIFY request in that dialog."
      The "it" in this sentence should be replaced by a named "actor". Is this the server that MUST NOT include things in the response?
      8) 4.2 says "A notifier that supports the different rate control mechanisms will comply with the value given in "min-interval", "max-interval" and "average-interval" parameters and adjust its rate of notification accordingly. However, if the notifier needs to lower the subscription expiration value or if a local policy or other implementation-determined constraint at the notifier can not satisfy the rate control request, then the notifier can adjust (i.e. increase or decrease) appropriately the subscriber requested rate control."
      How do I comply with a value? I know how to comply weith a standard, but not with a value. The "will comply" seems to call for a RFC2119 keyword. "will comply" seems to call for a MUST, but the next sentence discusses the exceptions, so I guess "will comply" needs to tbe replaced by a SHOULD.
      9) 5.1 says "Note that the witnessed time between two consecutive received notifications may not conform to the "min-interval" value for a number of reasons. For example, network jitter and retransmissions may result in the subscriber receiving the notifications with smaller intervals than the "min-interval" value recommends."
      Hmmm. Doesn't min-interval mean do not send notifications more fequently than every X seconds? Am I missing something in my interprwetation? Doesn't this text say that the receiver might receive the notifications at a rate faster than the rate they are sent?
      I stopped reviewing the document at section 5.1. I find the loose terminology used in this document makes this document not ready for publication as a standard. the language must be clear and unambiguous. I think this document should go back to the WG for tightening, and be resubmitted only after it has been tightened up.
    7. Alexey Melnikov: Discuss [2010-12-02]:
      In 9.2: "..."
      delta-seconds is not defined in the document. I think it is coming from RFC 3261, but this needs to be stated explicitly.
    8. Peter Saint-Andre: Comment [2010-11-30]:
      1. In Section 3.4, the parameter names do not belong in the requirement definitions because they are implementations of the requirements. Thus I suggest:
      REQ1: The subscriber must be able to set a maximum rate of notifications in a specific subscription.
      REQ2: The subscriber must be able to set a minimum rate of notifications in a specific subscription.
      REQ3: The subscriber must be able to set an adaptive minimum rate, which adjusts the minimum rate of notifications based on a moving average.
      REQ7: The notifier must be allowed to use a policy in which the maximum rate, minimum rate, and adaptive minimum rate are adjusted from the value given by the subscriber.
      2. In Sections 5.1, 6.1, and 7.1, what is "an integral number of seconds in decimal"?
      An integral number sounds like an integer, i.e., a whole number, i.e., not a decimal number. Please clarify.

    Telechat:

  5. Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information (Proposed Standard)
    draft-ietf-geopriv-rfc3825bis-14
    Token: Robert Sparks
    Note: The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com).
    Discusses/comments (from ballot 3481):
    1. Stewart Bryant: Comment [2010-12-01]:
      PIFF-LO term used but not defined
      GML term used but not defined
      Code: GEOCONF_GEODETIC (16 bits). is "Option Code" in the fig above.
      AType: Altitude Type (4 bits). would be clearer with a ref to section 2.4 (appears in two places)
    2. Ralph Droms: Discuss [2010-12-02]:
      (Including the dhc WG chairs in the discussion thread for their input on the reuse of option code 123 or use of a new option code.)
      Like Adrian, I am concerned about the details of how this document refers to RFC 3825 and the disposition of RFC 3825. For example, because of the changes to the interpretation of the Datum field, it is important that 3825bis, when published, is a self-contained description of the syntax and semantics of both versions of the options.
      As another example, the text in section 2.2.1.1 that begins "Moving forward..." would be better written to simply reference "3825bis-compliant clients"
      Did the working group consider defining a new option for the new format? Were the alternatives of an RFC3825bis versus a new option discussed with the dhc WG? Although there is some need to conserve DHCP option codes, the use of a new option code for this new format of the option would avoid the problems with backward compatibility:
      * an RFC 3825 compliant client misinterprets the contents of a 3825bis DHCP option 123 because of the unexpected version value 1
      * an RFC 3825 compliant client rejects the contents of a 3825bis option 123 because the version value 1 causes the client to interpret the option as containing an invalid datum value; the client has no way to indicate to the server that it has rejected the option contents
      * a DHCP client can't indicate which version of the option it understands
      In the IANA considerations section, I would like to see a clarification that the registries replace the existing registries. The second paragraph states that new Altitude Types and Datums must define the way in which the related uncertainty values are interpreted. However, the registry values in the table do not include those definitions; presumably, the uncertainty values are interpreted as in 3825bis, but this interpretation should be indicated in the registry.
    3. Ralph Droms: Comment [2010-12-02]:
      I found the wording of the IANA Considerations section confusing and inconsistent. I suggest:
      IANA maintains registries for the Altitude Type (AType), Datum and Version fields. New values for each of these registries are assigned through "Standards Actions" [RFC5226].
      Each AType registry entry MUST define the way that the 30 bit altitude values and the associated 6 bit uncertainty are interpreted.
      Each Datum registry entry MUST include specification of both horizontal and vertical datum, and MUST define the way that the 34 bit values and the respective 6 bit uncertainties are interpreted.
      The initial AType registry is:
      The initial Datum registry is:
      The initial Version registry is:
    4. Adrian Farrel: Discuss [2010-12-01]:
      I'm afraid that I don't understand the situation after it is published as an RFC. It claims to obsolete RFC 3825, but a lot of the text refers to things like...
      "This document defines the Ver field for the DHCPv4 and DHCPv6 options. New values for the Ver field are assigned through "Standards Action" [RFC5226]. Initial values are as follows:
      0: DHCPv4 Implementations conforming to [RFC3825]
      1: Implementations of this specification (for both DHCPv4 and DHCPv6)"
      This is not possible because this document obsoletes RFC 3825, so there cannot be conformance to the RFC any more!
      I think a little time should be spent re-working the text around references to RFC 3825. Either 3825 is being made historic, or this document is replacing (obsoleting) 3825 and becaomes the full (self-contained) reference for implementations. In fact (as is stated in seciton 2.2)...
      "This specification defines the behavior of version 0 (originally specified in [RFC3825]) as well as version 1."
      ...so you don't need to reference 3825, and can just get on with the specification of the two versions.
    5. David Harrington: Comment [2010-11-30]:
      1) section 1, paragraph 4 says "The DHCP server could correlate the Circuit-ID with the geographic location where the identified circuit terminates (such as the location of the wall jack)."
      Would it be the job of the DHCP server to do this correlation? I would assume it was a NM application function to do such correlation.
      2) In 2.2.1.2, s/same response. This is not useful since/same response, since/
      3) When aType=2, numbering starts at ground level. How does one represent an underground parking garage level?
      Should 2.4.3 mention how to represent this? Should Appendix B include such an example?

    Telechat:

  6. Extensible Messaging and Presence Protocol (XMPP): Core (Proposed Standard)
    draft-ietf-xmpp-3920bis-19
    Token: Gonzalo Camarillo
    Note: Ben Campbell (ben@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3578):
    1. Adrian Farrel: Discuss [2010-12-02]:
      I checked through the Errata raised against RFC 3920 and cannot satisfy myself that the issue raised in 1406 (http://www.rfc-editor.org/errata_search.php?eid=1406) has been addressed. The idea was, I think, simply to qualify the use of digests in examples to prevent anyone attempting to deduce meaning from them.
      Does anything need to be added to this revision?
    2. Alexey Melnikov: Discuss [2010-12-01]:
      1) 4.5.3. Idle Peer: "Even if the underlying TCP connection is alive and the stream is not broken, the peer might have sent no stanzas for a certain period of time. In this case, the peer SHOULD close the stream using the handshake described under Section 4.4.
      SHOULD close the stream, or SHOULD use the procedure in Section 4.4 if it decides to close it?
      "If the idle peer does not close the stream, the other party MAY either close the stream using the handshake described under Section 4.4 or return a stream error (e.g., <resource-constraint/> if the entity has reached a limit on the number of open TCP connections or <policy-violation/> if the connection has exceeded a local timeout policy). However, consistent with the order of layers (specified under Section 13.3), the other party is advised to verify that the underlying TCP connection is alive and the stream is unbroken (as described above) before concluding that the peer is idle. Furthermore, it is preferable to be liberal in accepting idle peers, since experience has shown that doing so improves the reliability of communication over XMPP networks and that it is typically more efficient to maintain a stream between two servers than to aggressively timeout such a stream.
      This is arguing for MAY above.
      2) 4.6.4. xml:lang: "If the receiving entity supports a language that closely matches the initiating entity's preferred language (e.g., "de" instead of "de-CH"),"
      I think you really need to be referencing Section 3.4 of RFC 4647 for this, as the process you describe above is not very formal (and might introduce wrong results if coded by a naive implementor).
      3) 5.3.5. TLS Renegotiation: "Support for TLS renegotiation is strictly OPTIONAL. However, implementations that support TLS renegotiation MUST implement and use the TLS Renegotiation Extension [TLS-NEG]."
      This makes [TLS-NEG] a Normative Reference.
      4) 6.4.2. Initiation: "If the initiating entity subsequently sends another <auth/> element (even if the ongoing authentication handshake has not yet completed), the server SHOULD discard the ongoing handshake and begin a new handshake for the subsequently requested SASL mechanism."
      What are the possible conditions for violating the SHOULD? The server really MUST fail the existing handshake, but maybe it doesn't have to begin a new handshake (e.g. it might choose to close the connection instead?).
      5) DISCUSS DISCUSS: "[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3.2.0", 2000."
      Should this be upgraded to at least Unicode 5.1?
      6) 13.8.2. For Confidentiality Only: "For confidentiality only, servers SHOULD support TLS with the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite."
      Why only a SHOULD?
      7) TLS-server-identity documents requires that protocols referencing it explicitly specify if wildcards are allowed in certificates. XMPP Core is silent on this, yet it shows some examples of certificates with wildcards.
    3. Alexey Melnikov: Comment [2010-12-01]:
      1.4. Terminology: "The term "whitespace" is used to refer to any character that matches production [3] content of [XML], i.e., any instance of the SP, HTAB, CR, or LF rules defined in [ABNF]."
      Any single character or multiple characters?
      3.2.1. Preferred Process: SRV Lookup: "3. [...] 7. [...]"
      While this is implied, it might be better to point out that the "next" is selected based on priority/weight from [DNS-SRV].
      3.2.2. Fallback Processes: "For client-to-server connections, the fallback MAY be a [DNS-TXT]"
      Is this Normative? It looks like it is.
      3.2.3. When Not to Use SRV: "If the initiating entity has been explicitly configured to associate a particular hostname (and potentially port) with the origin domain of the receiving entity (say, to "hardcode" an association from an origin domain of example.net to a configured hostname of webcm.example.com:80), the initiating entity SHOULD use the"
      Is use of port 80 a good example in this document?
      4.2.2. Stream Features Format: "A <features/> element MAY contain more than one mandatory feature. This means that the initiating entity can choose among the mandatory features. For example, perhaps a future technology will perform roughly the same function as TLS, so the receiving entity might advertise support for both TLS and the future technology."
      So if the server requires both TLS and SASL, does this mean that it first advertises TLS as required (and SASL is either advertised as optional or not advertised), and then once TLS negotiation is complete, SASL needs to be advertised as required (on the restarted stream)?
      4.2.7. Flow Chart: In the flowchart - is "receive stream features" required after each negotiation of a voluntary feature?
      4.6. Stream Attributes: "The attributes of the root <stream/> element are defined in the following sections. Security Note: Until and unless the confidentiality and integrity of a stream header is ensured via Transport Layer Security as described under Section 5, the attributes provided in a stream header could be tampered with by an attacker."
      Or SASL security layer (e.g. GSSAPI).
      4.7.2. Content Namespace: "When a content namespace is not declared as the default namespace and so-called "prefix-free canonicalization" is used instead, in rough outline a stream will look something like the following.
         <stream
             from='juliet@im.example.com'
             to='im.example.com'
             version='1.0'
             xml:lang='en'
             xmlns='http://etherx.jabber.org/streams'>
           <message xmlns='jabber:client'>
             <body>foo</body>
           </message>
         </stream:stream>
      

      Should the closing tag be </stream> above?
      4.7.4. Namespace Declarations and Prefixes: "An implementation MUST NOT generate namespace prefixes for elements qualified by the content namespace if the content namespace is 'jabber:client' or 'jabber:server' (e.g., <foo:presence/>). An XMPP"
      Can you try to explain this again, you lost me here.
      5.4.3.1. Rules: "7. Following successful TLS negotiation, all further data transmitted by either party MUST be encrypted."
      Did you really meant "encrypted" here? What about use of NULL ciphers with integrity protection?
      5.4.3.3. TLS Success: "..."
      This should include SCRAM-SHA-1 :-), as it is an MTI.
      6.3.3. Mechanism Preferences: "Any entity that will act as a SASL client or a SASL server MUST maintain an ordered list of its preferred SASL mechanisms according to the client or server, where the list is ordered according to local policy or user configuration (which SHOULD be in order of perceived strength to enable the strongest authentication possible). A server MUST offer and a client MUST try SASL mechanisms in preference order."
      Is this clear that server's and client's preference orders are different?
      6.3.7. Simple User Name: "Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify that the authentication identity used in the context of such mechanisms is a "simple user name" (see Section 2 of [SASL] as well as [SASLPREP]). The exact form of the simple user name in any particular mechanism or deployment thereof is a local matter, and a simple user name does not necessarily map to an application identifier such as a JID or JID component (e.g., a localpart). However, in the absence of local information provided by the server, an XMPP client SHOULD assume that the authentication identity for such a SASL mechanism is a simple user name equal to the localpart of the user's JID."
      Or bare JID? I believe many implementations based on Cyrus SASL allow full email-like syntax here.
      6.3.9. Realms: "The receiving entity MAY include a realm when negotiating certain SASL mechanisms. If the receiving entity does not communicate a realm, the initiating entity MUST NOT assume that any realm exists. The realm MUST be used only for the purpose of authentication; in particular, an initiating entity MUST NOT attempt to derive an XMPP hostname from the realm information provided by the receiving entity."
      Should this be clearer about which mechanisms are we talking about? IMHO, being vague is not being helpful here.
      8.3.1. Rules:
      "4. An error stanza MUST contain an <error/> child element."
      "7. An <error/> child MUST NOT be included if the 'type' attribute has a value other than "error" (or if there is no 'type' attribute)."
      Are these 2 in conflict? If they are not, should they be combined into a single rule?
      8.3.3.13. policy-violation: "The entity has violated some local service policy (e.g., a message contains words that are prohibited by the service); the server MAY choose to specify the policy in the <text/> element or in an application-specific condition element; the associated error type SHOULD be "modify" or "wait" depending on the policy being violated. (In the following example, the client sends an XMPP message that is too large according to the server's local service policy.)"
      It might be better to change the description to mention prohibited words (e.g. "!!!"). Otherwise this looks too similar to <not-acceptable/>...
      13.7.2.2.1. Case #1: "If the client certificate appears to be certified by a certification path terminating in a trust anchor (as described in Section 6.1 of [PKIX]), the server MUST check the certificate for any instances of the XmppAddr as described under Section 13.7.1.4. There are three possible sub-cases:"
      "Sub-Case #1: The server finds one XmppAddr for which the domainpart of the represented JID matches one of the configured hostnames of the server; the server SHOULD use this represented JID as the validated identity of the client."
      "Sub-Case #2: The server finds more than one XmppAddr for which the domainpart of the represented JID matches one of the configured hostnames of the server; the server SHOULD use one of these represented JIDs as the validated identity of the client, choosing among them according to local service policies or based on the 'to' address of the initial stream header."
      What if the client has multiple accounts on the same server and they use the same certificate? (I admit that that might be an obscure case.) Should the server be using the 'from' value to differentiate as well?
      13.9.4. Use of SASL "Many deployed XMPP services authenticate client connections by means of passwords. It is well-known that most human users choose relatively weak passwords. Although service provisioning is out of scope for this document, XMPP servers that allow password-based authentication SHOULD enforce minimal criteria for password strength to help prevent dictionary attacks. Because all password-based authentication mechanisms are susceptible to password guessing attacks, XMPP servers MUST implement common rate-limiting mitigations.
      Rate-limiting during SASL authentication?
      13.9.5. Use of TLS "Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, XMPP servers and clients MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for further details."
      This should probably point to draft-ietf-tls-ssl2-must-not. The reference doesn't need to be normative.
      "Service providers SHOULD include the DNS-ID identifier type in certificate requests."
      XMPP Service providers?
    4. Robert Sparks: Discuss [2010-11-30]:
      1) This draft requires that an intial stream be established before starting TLS negotiation, and requires (at SHOULD strength) that the stream element that is sent in the clear have a from attribute identifying the user if known. It doesn't feel right to require a privacy leak like that. Would it make more sense to elide the from if the client knows it wants to try using TLS, or at least provide a way to use a from that couldn't be used by third parties to identify the user?
      2) Section 3.2.2's MAY seems to make [DNS-TXT] and [XEP-0156] normative.
      3) Section 4.4 - why is the specified behavior for the element that sends a closing stream tag defined as a SHOULD? When is it ok for the element to do something different, and what would it do?
      4) Section 8.3.1 - Does "generated stanza" mean "the stanza that caused an error to be generated"? Can you provide more detail about why swapping the to and from are SHOULD (I can't figure out what in section 13.10 would have you not simply swap.)
      5) page 137 (delivery related attack point 2) : this paragraph "How a server ... bare JID." does not parse.
      6) Section 10.5.3.1 The second bullet seems to make [XMPP-IM] a normative reference. There were other places in the document where [XMPP-IM] seemed to be required reading in order to build a conformant implementation.
      7) Section 10.5.3.2 : Why, for a message stanza, do you say SHOULD deliver to at least one matching resource? Why is this not a MUST, and why do you allow something between one and all?
      8) Section 13.10.1 : It's not clear what you really mean by "make the IP address or method of access public". How do you test this MUST NOT? Can you give examples of what you're worried a server implementation might do in error?
      9) Section 13.12, item 4 : this 10000 is a magic number - please consider calling out that it was arbitrarily chosen. More importantly, please add text disuading implementers from chosing to set a limit of 10000 bytes by default.
    5. Robert Sparks: Comment [2010-11-30]:
      Please consider clarifying that you are not requiring elements to reject streams that use a prefix with the literal value "stream", only that you are allowing them to do so to allow legacy implementations to be compliant. It might help to be even more explicit that clients that chose not to use the literal "stream" prefix may have interoperability problems with those legacy implementations. Also consider pointing to this exception to the general principal of allowing the sender to set the string it uses as a prefix label in the section on page 124 (where you note that "receiving entities MUST NOT depend on the prefix strings to have any particular value.")
      Some additional explanation of SRV's resolving to "." meaning "don't use SRV" would help. Why is this mechanism there?
      In 4.2.5 - Please consider a little more explanation on why an initiating element might send stanzas to itself?
      Please consider adding forward pointers from the keep-alive sections (such as 4.5.1) to the requirement to not send whitespace during TLS and SASL negotiation. (5.3.3, 6.3.5)
      In 4.8.3.9 - "not a valid JID" may be ambiguous - is it intended to include "not well formed"?
      In 5.3.5 - what does "blindly attempt" mean? why is the requirement around it SHOULD NOT? When is it OK to blindly attempt?
      In 5.4.3.3 - the "Implementation Note:" actually contains a normative requirement defining protocol behavior. Similarly, 8.3.3.14 has a Security Note with normative requirements. I strongly suggest moving actual protocol requirements out of those notes.
      In 6.3.8 - Can you provide a reference to where is the behavior for acting on the behalf of another party is specified?
      In 6.4.6 - Can you add some text justifying why the entity SHOULD terminate the connection attempt if the from identity and the SASL authentication identity do not match, and why this is a SHOULD not a MUST?
      In 8.3.3.15 : This section doesn't provide a way to protect against redirect loops (such as see-other-host did). Should it?
      In 10.4.1 : should this "will" be a MUST?
      In 13.1 : has the group considered a "fail this stanze if it would go over a hop that isn't TLS protected" request extension?

    Telechat:

  7. Extensible Messaging and Presence Protocol (XMPP): Address Format (Proposed Standard)
    draft-ietf-xmpp-address-07
    Token: Gonzalo Camarillo
    Note: Ben Campbell (ben@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3580):
    1. Russ Housley: Discuss [2010-11-30]:
      In the Gen-ART Review by Elwyn Davies on 30 November 2010, one issue was discovered that is easily addressed. I think consistent terms will aid future readers and implementers.
    2. Alexey Melnikov: Discuss [2010-11-19]:
      1). RFC 3920: "[...]"
      draft-ietf-xmpp-address: "[...]"
      RFC 3986: "[...]"
      (DISCUSS DISCUSS) This means that the draft is proposing usage of "[" and "]" around IPv6 addresses, which is a change from RFC 3920. I think the change is sensible, but is it covered by Appendix C?
      2). In Section 2.1: "An XMPP URI or IRI [XMPP-URI] is in essence a JID prepended with 'xmpp:', but the native addressing format used in XMPP is that of a mere JID without a URI scheme."
      I think this text is misleading for URIs: it is effectively suggesting that percent-decoding/encoding is not needed when converting a JID to URI, which is not correct. URIs are always in US-ASCII, while JIDs are not. Similar assumptions about mailto: URIs caused some interoperability problems.
      3). [DNS] seems to be Normative (for the definition of a Fully Qualified Domain Name).
      4). DISCUSS DISCUSS: Should domainpart be migrated to IDNA2008 now? Apps Area is pretty much requiring use of IDNA2008 in all documents.
      5). I still need to double check the following, but from a cursory look this seems to be a minor problem:
      Can application of Nodeprep/resourceprep to a non empty string result in an empty string, which would violate the requirement on nodepart/resourcepart being non empty?
      This will affect several sections, including Section 6.
    3. Alexey Melnikov: Comment [2010-11-19]:
      1). In 4.3.1 SASL needs an Informative Reference
      2). "A resourcepart can be employed as one part of an entity's address in XMPP. One common usage is as the name for an instant messaging user's connected resource; another is as the nickname of a user in a multi-user chat room; and many other kinds of entities could use resourceparts as part of their addresses. The security of such services could be compromised based on different interpretations of the internationalized resourcepart; for example, a user could attempt to bind multiple resources with the same name,"
      Can you expand on what is the problem with binding multiple resources to the same name?
      3). In Section 6: "Feature: address-domain-length
      Description: Ensure that the domainpart of an XMPP address is at least one byte in length and at most 1023 bytes in length.
      Domain names have lower length boundary due to DNS restrictions. Should this be at least mentioned? (Also applies elsewhere)

    Telechat:

  8. DHCPv4 lease query by Relay Agent Remote ID (Proposed Standard)
    draft-ietf-dhc-leasequery-by-remote-id-08
    Token: Ralph Droms
    Note: Ted Lemon <mellon@nominum.com> is the shepherd for this document.
    Discusses/comments (from ballot 3587):
    1. Lars Eggert: Comment [2010-11-30]:
      two Nits
    2. Adrian Farrel: Comment [2010-12-02]:
      In section 4.1: "The DHCPLEASEQUERY message is typically sent by an access concentrator."
      I really hate this type of language :-)
      We can assume that you do not mean that most messages sent by an access concentrator are DHCPLEASEQUERY messages.
      You mean that most DHCPLEASEQUERY messages are sent by access concentrators (not just by "an access concentrator" - I have an image of some poor box in the Internet responsible for sending all the messages)
      But missing from the description is a statement of who sends the other (atypical) DHCPLEASEQUERY messages.
    3. Tim Polk: Discuss [2010-12-01]:
      The security considerations state:: "This document does not introduce any new security concerns beyond those specified in the original lease query protocol RFC 4388 [RFC4388] specifications."
      RFC 4388's Security Considerations note that: "DHCP servers SHOULD prevent exposure of location information (particularly the mapping of hardware address to IP address lease, which can be an invasion of broadband subscriber privacy) by employing the techniques detailed in [RFC3118], "Authentication for DHCP Messages"."
      While exposure of location information was possible with RFC 4388, this specification seems to simplify and magnify the problem. If the DHCP server accepts an unauthenticated message (or fails to verify the authentication information), a lease query by remote ID permits an attacker to obtain all the location information in a very efficient manner. Since the risk is heightened, I think a few additional words highlighting the importance of the DHCP authentication mechanism would be appropriate in this specification.
    4. Sean Turner: Comment [2010-12-02]:
      #1) I support Tim's discuss.
      #2) I can't parse this sentence in the abstract: "RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server as and when this information is lost."
      remove "as and"?
      #3) Expand DSLAM.
      #4) Section 4.7/8/9: Should the shoulds be SHOULDs?

    Telechat:

  9. Mobility Support in IPv6 (Proposed Standard)
    draft-ietf-mext-rfc3775bis-10
    Token: Ralph Droms
    Note: Julien Laganier (julienl@qualcomm.com) is the document shepherd.
    Discusses/comments (from ballot 3594):
    1. Stewart Bryant: Comment [2010-12-02]:
      It would be useful to the reader to describe the reason for the update much earlier in the introduction.
    2. David Harrington: Discuss [2010-12-02]:
      1) the follwoing text (from rfc3775) should probably be made more/less normative: "The deletion of a binding can be indicated by setting the Lifetime field to 0 and by setting the care-of address equal to the home address. In deletion, the generation of the binding management key depends exclusively on the home keygen token, as explained in Section 5.2.5. (Note that while the senders are required to set both the Lifetime field to 0 and the care-of address equal to the home address, Section 9.5.1 rules for receivers are more liberal, and interpret either condition as a deletion.)"
      What is REQUIRED of a compliant inmplementation?
    3. David Harrington: Comment [2010-12-02]:
      1) There is a TBD in 6.1.8 and the IANA Consderations, in the Status Codes registry.
      2) "format of the format of the"
    4. Alexey Melnikov: Comment [2010-12-01]:
      I've scanned wdiff changes since RFC 3775 and I don't think my review can add much value to the quality of the document. So I have No Objections to its publication.
    5. Tim Polk: Discuss [2010-12-02]:
      Nico Williams raised some important points in his (late) secdir review, and I want to be sure the authors consider these points before publication.
      The two issues I was particularly interested in are the use of subject alternative names in PKIX certificates and the use of SHA-1. (See "Binding of home addresses to mobile node credentials when using IKEv2" and "Hash/MAC algorithm agility" in the review, respectively)
      (1) I would like to confirm that subject alternative names are commonly used in Mobile IPv6. If subject alternative names are not commonly used, as Nico suggests, I beleive it is important for the text to reflect actual practice.
      (2) I believe that Nico is correct, and there is no risk incurred by the use of SHA-1 in this document. However, this is a source of great confusion to many readers. Adding text to the security considerations noting that the use of SHA-1 has been reviewed and is safe would be a really good idea. If such a review has not been performed, I would be glad to connect the authors to some NIST cryptographers to do that review...
    6. Tim Polk: Comment [2010-12-02]:
      Please review Nico's discussion of " Enrolment/assignment of home address bindings to mobile node credentials." If work is underway, an informative reference would be nice.
    7. Peter Saint-Andre: Comment [2010-12-01]:
      HMAC appears to be a normative reference.
    8. Sean Turner: Discuss [2010-12-02]:
      #1) HMAC [26] appears to be a normative reference.
    9. Sean Turner: Comment [2010-12-02]:
      #1) Is there a reason not to point to the latest FIPS PUB 180-3?
      National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008.
      #2) I assume we want good keys? Add the following to the first paragraph in 5.2.1:
      The keys MUST be generated by using a random number generator that is known to have good randomness properties [13].
      #3) Section 5.2.4: People keep telling me it's SHA-1 not SHA1 when not used with HMAC.
      #3) Should the recommendations in Section 5.2.2 and 5.2.4 be made upper case? (i.e., r/recommended/RECOMMENDED).

    Telechat:

2.1.2 Returning Items

  1. Use of Device Identity in HTTP-Enabled Location Delivery (HELD) (Proposed Standard)
    draft-ietf-geopriv-held-identity-extensions-06
    Token: Robert Sparks
    Note: The Document Shepherd for this document is Alissa Cooper (acooper@cdt.org).
    Discusses/comments (from ballot 3483):
    1. Stewart Bryant: Comment [2010-10-27]:
      I agree with the discusses already posted, but no additional issues.
    2. Lars Eggert: Comment [2010-10-26]:
      Section 3.6., paragraph 4: "A domain name does not always correspond to a single IP address or host. If this is the case, a domain name is not a suitable identifier.
      Right. Domain names are also clearly context specific (split-horizon DNS, etc.)
    3. Adrian Farrel: Comment [2010-12-02]:
      I support Dan's Discuss. draft-ietf-georiv-arch is (somewhat) careful in its definition of "device" and I do not think it means "network interface". Although it is true that network interfaces do not currently wander independent of devices (and if they did, they might need to be independently trackable) some care is needed in the wording to make the association clear.
    4. Alexey Melnikov: Comment [2010-11-15]:
      2.2. Identifier Format and Protocol Details: "If the LIS requires an identifier that is not provided in the request, the desired identifiers MAY be identified in the HELD error response, using the "requiredIdentifiers" element. This element contains a list of XML qualified names [W3C.REC-xml-names11-20060816] that identify the identifier elements required by the LIS. Namespace prefix bindings for the qualified names are taken from document context. Figure 2 shows an example error indicating that the requester needs to include a MAC address (Section 3.2) if the request is to succeed.
      Is there an IANA registry for these?
      5. Security Considerations: "All HELD requests containing identity MUST be authenticated by the LIS. How authentication is accomplished and what assurances are desired is a matter for policy.
      Is this description sufficient for providing interoperability?
    5. Tim Polk: Discuss [2010-10-27]:
      This discuss expands upon one of the comments in Alexey's ballot position.
      In section 5. Security Considerations, paragraphs 2 and 3 state: "All HELD requests containing identity MUST be authenticated by the LIS. How authentication is accomplished and what assurances are desired is a matter for policy. The base HELD protocol uses return reachability of an IP address implied by the requester being able to successfully complete a TCP handshake. It is RECOMMENDED that any means of authentication provide at least this degree of assurance. For requests that include Device identity, the LIS MUST support HTTP digest authentication [RFC2617]. Unauthenticated location requests containing Device identity can be challenged with an HTTP 401 (Unauthorized) response or rejected with an HTTP 403 (Forbidden) response."
      However, RFC 5985 states:: "A Device that conforms to this specification MAY choose not to support HTTP authentication [RFC2617] or cookies [RFC2965]."
      Where IP reachability is not an appropriate means of authentication, the only authentication mechanism that MUST be required by the LIS is optional for the Device. Should digest authentication be a MUST for the Device? The combination of digest authentication and TLS seems a straightforward solution. Alternatively, TLS client authentication is a more complex solution but might be more scalable.
    6. Dan Romascanu: Discuss [2010-10-26]:
      In Section 3.2: "The media access control (MAC) address used by the IEEE 802 family of access technologies is an identifier that is assigned to a particular network Device. A MAC address is a unique sequence that is either assigned at the time of manufacture of a Device, or assigned by a local administrator. A MAC address rarely changes; therefore, a MAC address is an appropriate identifier for a Device."
      Actually MAC addresses are not assigned to devices but to network interfaces that connect devices to a physical segment. There may be more than one MAC address per device in the case of devices with multiple network interfaces, and even more MAC addresses per one physical interface in some cases (for example one MAC address per VLAN). The scheme works but only for the globally unique addresses which are guaranteed to be unique and any of the MAC addresses on the device interfaces can be used to identify the device.
    7. Dan Romascanu: Comment [2010-10-26]:
      I support the issues raised by Alexey in his DISCUSS.
    8. Sean Turner: Comment [2010-12-01]:
      I support Tim's discuss.
      The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then it's not suitable. Should this be repeated in the other sections? e.g., if the URI doesn't specifically refer to a particular device, then a URI is not a suitable identifier. I see the general guidance in Section 2- just curious why only FQDN got this special treatment.
      In Section 3.7, I says:: "Each identifier contains a string of decimal digits with a length as specified."
      But, the imsi and min identifier descriptions don't include length constraints. Seems like they all should (they're in the schema I guess just copy the values forward to the descriptions).

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. X.509v3 Certificates for Secure Shell Authentication (Proposed Standard)
    draft-igoe-secsh-x509v3-06
    Token: Sean Turner
    Note: The Document Shepherd for this document is Jeffrey Hutzelman (jhutz@cmu.edu).
    Discusses/comments (from ballot 3590):
    1. Russ Housley: Discuss [2010-11-28]:
      Section 2.1 says:: "There is no requirement on the ordering or number of OCSP responses."
      There is no reason for the number of OCSP responses to exceed the number of certificates proviced. Why allow more?
      Section 2.1 also says: "[RFC5280] describes the structure of X.509v3 certificates to be used with RSA and Digital Signature Algorithm (DSA) public keys."
      I think that RFC 3279 is a better reference for these algorithms.
      Section 2.2.1 says: "The digitalSignature KeyUsage identifier MAY be used with""certificates for x509v3-ssh-dss, x509v3-ssh-rsa, and x509v3-ecdsa-sha2-* public key algorithms."
      I think this is incorrect. I think it should say: If the keyUsage extension is present in the cerificate, then digitalSignature MUST be set for these identifiers.
      Section 2.2.1 also says: "The keyAgreement KeyUsage identifier MAY be used for certificates with convey keys for use with the ecmqv-sha2 key exchange method."
      I think this is incorrect. I think it should say: If the keyUsage extension is present in the cerificate, then digkeyAgreement MUST be set for these identifiers.
    2. Russ Housley: Comment [2010-11-28]:
      Section 1 says: "Digital certificates, such as those in X.509 version 3 (X.509v3) format, ..."
      Please add a reference. [RFC5280] seems appropriate.
      Section 1 also says: "This document is concerned with SSH implementation details; specification of the underlying cryptographic algorithms and the handling and structure of X.509v3 certificates is left to other standards documents.
      What documents does an implementer need to read? Obviously, RFC 5280 is needed. Please list them as normative references.
    3. Alexey Melnikov: Comment [2010-11-24]:
      2.1. Public Key Format: "For all of the public key algorithms specified in this document, the key format consists of a sequence of one or more X.509v3 certificates followed by a sequence of 0 or more Online Certificate Status Protocol (OCSP) responses as in Section 4.2 of [RFC2560]. Providing OCSP responses directly in this data structure can reduce the number of communication rounds required (saving the implementation from needing to perform OCSP checking out-of-band) and can also allow a client outside of a private network to receive OCSP responses from a server behind firewall."
      This text almost make it sound as if OCSP data is optional to include.
    4. Tim Polk: Discuss [2010-12-02]:
      This is a discuss-discuss. A third party IPR disclosure was recently filed on this document. Given that Certicom is assumed to have IPR that could apply to any Internet Draft including elliptic curve technology, I do not think this changes the community consensus but I want to hear the opinions of other ADs.
    5. Peter Saint-Andre: Discuss [2010-11-30]:
      Section 4 states: "For the purposes of server authentication, the mapping between certificates and host names is left as an implementation and configuration issue for implementers and system administrators."
      Leaving this up to software implementers and service operators seems shortsighted. For the sake of interoperability and improved security, I think it would be good to specify rules for checking the identity of hostnames asserted by the server (if the client does not check the server's identity, how can it be said to have authenticated the server?). It might be appropriate to cite draft-saintandre-tls-server-id-check or to borrow some text from that document.

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Requirements for a Tunnel Based EAP Method (Informational)
    draft-ietf-emu-eaptunnel-req-08
    Token: Sean Turner
    Note: Alan DeKok (aland@deployingradius.com) is the document shepherd.
    Discusses/comments (from ballot 3596):
    1. Jari Arkko: Discuss [2010-12-02]:
      I would have voted Yes on this excellent document if it were not for the following statement:
      "The mandatory to implement cipher suites MUST NOT include "export strength" cipher suites"
      First of all, I want to know what this means. What specific requirements are you setting, and from whose perspective?
      Secondly, the IETF has not been and I don't think it should be in the business of changing its technical requirements based on requirements from governments. And in particular not requirements specific to any individual country. I think we need to make this new method as strong as it needs to be. In terms of symmetric ciphers, AES-128 or AES-256 would be fine, for instance. If that's exceeding the particular export limitations mentioned above, I do not think we should compromise the specification. If not, why do we need to say something? Finally, do you expect to be able to implement this method based on OpenSSL or some limited version of it? I surely hope that the intention is the former.
    2. Jari Arkko: Comment [2010-12-02]:
      I support Lars' discuss, but I also think that the document is clear with respect to what it is recommending, i.e., I'm not supportive of Alexey's discuss.
    3. Stewart Bryant: Comment [2010-12-01]:
      I support Lars' Discuss on RFC2119 language. I also found it very confusing.
    4. Lars Eggert: Discuss [2010-11-30]:
      Section 2., paragraph 0: Conventions Used In This Document:
      DISCUSS: It is *extremely* confusing to see RFC2119 terms being redefined in the local scope of a document, especially since the redefinitions seem comparable to what RFC2119 specified. Suggest to either include the normal RFC2119 boilerplate and reference, or else chose different local terms.
      Section 4.2.2., paragraph 1: "Tunnel establishment sometimes requires the exchange of information that exceeds what can be carried in a single EAP message. In addition information carried within the tunnel may also exceed this limit. Therefore a tunnel method MUST support fragmentation and reassembly.
      DISCUSS: I'm not sure I understand this requirement. A TLS tunnel uses TLS on top of TCP. TCP byte streams have no fragmentation issues.
    5. Adrian Farrel: Comment [2010-12-01]:
      A number of acronyms need to be expanded on first use.
    6. Russ Housley: Discuss [2010-11-30]:
      Based on the discussion following the posting of the Gen-ART Review by Roni Even on 25-Oct-2101, at least one change to the document was agreed. The revised document has not been posted yet.
    7. Alexey Melnikov: Discuss [2010-12-01]:
      For readers not familiar about internal discussions within EMU WG, it would be helpful to understand what exactly is the WG planning to design. Can you please describe in the Introduction the thing you are trying to build. Sean explained to me that that is supposed to be a new EAP method, that uses TLS and multiple EAP methods inside the TLS tunnel.
      Once I understood the scope, it became easier to review the document. Some additional comments:
      3.9. Certificate-less Authentication and Generic EAP Method Extension: "In some cases the peer will not have a way to verify a server certificate and in some cases a server might not have a certificate to verify. Therefore, it is desirable to support certificate-less authentication. An application for this is credential provisioning where the peer and server authenticate each other with a shared password and credentials for subsequent authentication (e.g. a key pair and certificate or a shared key) can be passed inside the tunnel. Another application is to extend existing EAP methods with new features such as channel bindings."
      This is the first time the term channel bindings is used. Did you mean EAP channel bindings or the channel bindings as used by other protocols such as GSS-API and SASL?
      I think you meant the latter here, but this is not clear.
    8. Alexey Melnikov: Comment [2010-12-01]:
      3.1. Password Authentication: "Many legacy systems only support user authentication with passwords. Some of these systems require transport of the actual username and password to the authentication server. This is true for systems where the authentication server does not have access to the cleartext password or a consistent transform of the cleartext password. Example of such systems are one time password (OTP) systems and other"
      I don't think OTP systems require password in the clear, or at least not all of them.
      4.2.1. TLS Requirements: "The tunnel based method MUST support TLS version 1.2 [RFC5246] and may support earlier versions to enable the possibility of backwards compatibility."
      Just not SSL 2.0 :-).
      4.5. Requirements Associated with Carrying Username and Passwords: "This section describes the requirements associated with tunneled password authentication. The password authentication mentioned here refers to user or machine authentication using a legacy password database or verifier, such as LDAP, OTP, etc. These typically require the password in its original text form in order to authenticate the peer, hence they require the peer to send the clear text user name and password to the EAP server.
      LDAP needs an Informative Reference.
      4.5.2. Internationalization: "The password authentication exchange MUST support user names and passwords in international languages. It MUST support encoding of user name and password strings in UTF-8 [RFC3629] format. The method MUST specify how username and password normalizations and/or comparisons is performed in reference to SASLPrep [RFC4013] or Net-UTF-8 [RFC5198]."
      Please add "or their replacement", as SASLPrepbis is going to be worked on in the Precis WG.
      4.5.2. Internationalization: "These numeric codes are not subject internationalization during transmission"
      Missing "to" after "subject".
    9. Tim Polk: Comment [2010-12-02]:
      After reading the secdir review and various AD comments, I have come to the conclusion that diagrams and other architectural information are necessary for this document to be widely useful. I enter this as a comment, since the primary audience for the document is the emu working group, and I expect that the participants are in rough agreement about the architecture. That is, adding the diagrams and architectural information will have limited utility for emu itself (although we might identify some unknown disagreements in the process!) The specification can serve its main purpose as it stands - guide and focus the development of a standards track EAP tunnel method.
      I leave to the authors, chairs, and sponsoring AD's discretion whether the working group has sufficient cycles or energy to fill this gap.
    10. Peter Saint-Andre: Comment [2010-12-01]:
      1. In Section 3.9, a reference to RFC 5056 would be helpful with regard to channel binding.
      2. In Section 3.9 and Section 4.6.3, it might be good to describe in a bit more how cryptographic binding is different from channel binding.
    11. Robert Sparks: Comment [2010-12-01]:
      Support Lars' DISCUSS re: 2119 language

    Telechat:

  2. Security Assessment of the Internet Protocol version 4 (Informational)
    draft-ietf-opsec-ip-security-04
    Token: Ron Bonica
    Note: The Document Shepherd is Joel Jaeggli (joelja@bogus.com).
    Discusses/comments (from ballot 3604):
    1. Jari Arkko: Discuss [2010-12-02]:
      Section 4.3.4 claims that based on ongoing work, the treatment of Class E address space (240/4) should be changed in current routers and hosts. I think this is inappropriate because the referred work is not actually currently pursued in any way. There are also numerous technical problems in deploying something like that. Finally, while this is a great and much needed document, it should not be used as a vehicle to specify specific technical proposals of controversial nature.
    2. Jari Arkko: Comment [2010-12-02]:
      (blank)
    3. Stewart Bryant: Discuss [2010-12-01]:
      The text in 3.5.2.2 on not using UDP c/s does not do justice to systems where performance requirements make this impractical, for example systems such as LISP where UDP is a tunnel, and IPFIX where the exporter is often a linecard forwarder. Equally, the text glosses over just how poor the UDP c/s is.
    4. Stewart Bryant: Comment [2010-12-01]:
      The introduction appears to incorrectly uses the term TCP/IP when the author means the Internet Protocol suit.
      "This document is the result of an assessment of the IETF specifications of the Internet Protocol (IP)" - The document only discusses IPv4.
      I am surprised that Section 3 does not have a normative reference to RFC791
      In Figure 3, an attacker sends a 17914-byte datagram meant to the s/to/for/
      NDIS is used before it is defined.
      Section 3.11 (related to the aside on SA being an interface) ought to have some text on loop-back addresses, and unnumbered interfaces.
    5. Adrian Farrel: Discuss [2010-11-15]:
      I am disappointed that this document doesn't highlight more fully the issues and concerns for security created by the Router Alert option. A reference to draft-ietf-intarea-router-alert-considerations might serve well.
    6. Adrian Farrel: Comment [2010-11-15]:
      (blank)
    7. Peter Saint-Andre: Comment [2010-12-01]:
      Appendix A borders on marketing and seems like a strange thing to include in an RFC. Why is this here?

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Media Gateway Control Protocol (MGCP) Voiceband Data Package (VBD) and General Purpose Media Descriptor Parameter Package (Informational)
    draft-stone-mgcp-vbd-08
    Token: Gonzalo Camarillo
    Discusses/comments (from ballot 3447):
    1. Sean Turner: Discuss [2010-12-02]:
      #1) The security considerations recommend both IPsec and SRTP, but one is not specified as the mandatory-to-implement. In order to achieve interop one needs to be picked or are you suggesting both be used?
      #2) The security considerations say use IPsec as the end-to-end protection scheme. It needs to say a whole lot more. See Section 8 of RFC 5406.
      #3) In the same veil is just pointing at SRTP sufficient to get two interoperable solutions?
    2. Sean Turner: Comment [2010-12-02]:
      #1) Section 9: r/securuty/security

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. The Babel Routing Protocol (Experimental)
    draft-chroboczek-babel-routing-protocol-05
    Token: Stewart Bryant
    Discusses/comments (from ballot 3560):
    1. Lars Eggert: Comment [2010-11-30]:
      Section 5., paragraph 0: IANA Considerations:
      I note that the IANA Considerations do not actually *instruct* IANA to make any registrations?
    2. Adrian Farrel: Comment [2010-11-23]:
      I'd like to thank the author for being willing to engage with reviewers and working to accommodate their concerns even though this I-D is an independent submission.
    3. David Harrington: Discuss [2010-12-02]:
      I am interested in understanding the operational impact of deploying this experimental protocol in, say, a production environment or in the Internet. Will this experimental protocol interfere with other routing protocols, if deployed together, or can it co-exist easily?

    Telechat:

  2. Session-Specific Explicit Diameter Request Routing (Informational)
    draft-tsou-diameter-explicit-routing-05
    Token: Dan Romascanu
    Note: 'The IESG has concluded that this work is related to IETF work done in the Diameter Maintenance and Extensions (DIME) WG, but this relationship does not prevent publishing. The DIME WG discussed a predecessor of this document. There was no consensus in the WG that the problems addressed by the document are a real concern in existing Diameter deployments, and there was no consensus that the solutions meet the architectural principles of the Diameter protocol. As a result the DIME WG decided not to undertake this work. The IESG also does not know of any information on record that such work is needed as a reference by other SDOs'.
    Discusses/comments (from ballot 3616):
    1. Jari Arkko: Discuss [2010-12-02]:
      I do not think that we should publish a document that says it is a basis for a standardized extension, and it is particularly suspect in a situation where we have not gotten any formal expression of requirements from the 3GPP. They normally give us all their requirements and references to work that they depend on ends up in the 3GPP-IETF dependency list, which has not happened in this case AFAICT.
      Given this, the proposed IESG note is too weak, IMO.
      Here's a possible rewrite:
      The IESG has concluded that this work is related to IETF work done in the Diameter Maintenance and Extensions (DIME) WG, but this relationship does not prevent publishing, if (1) the abstract is changed to remove the discussion of standardized solutions and (2) the following text appears either in the document body or as an IESG note:
      Techniques similar to those discussed in this document were discussed in the IETF DIME Working Group. The group had no consensus that the problems addressed by such work are a real concern in Diameter deployments. Furthermore, there was no consensus that the proposed solutions would meet the architectural principles of the Diameter protocol. As a result the working group decided not to undertake the work. There has also not been any formal requests for this functionality from other standards bodies. This RFC represents a continuation of the abandoned work. Readers of this specification should be aware that the IETF has not reviewed this specification and cannot say anything about its suitability for a particular purpose or about its compatibility with the Diameter architecture and other extensions.
    2. Jari Arkko: Comment [2010-12-02]:
      (blank)
    3. Lars Eggert: Comment [2010-11-30]:
      No objection with the proposed IESG Note.
    4. Adrian Farrel: Discuss [2010-12-02]:
      This is a Discuss-Discuss and does not require any action from the authors.
      I am not an expert on this protocol and would like to IANA situation with someone with deeper understanding.
      To me it looks like all AVPs are supposed to be tracked by IANA regardless of whether they are allocated for IETF standards track use, or for vendor-specific use.
      At the top of the AVP registry I see... "Registration Procedures: Expert review with Specification. Note If more than 3 are needed, IETF consensus."
      The I-D only appears to need three new AVP Codes so IETF consensus is not required, but I would still expect IANA to be requested to track the AVP Codes to avoid clashes.
      Furthermore, the Vendor-Id AVP value of 2011 proposed for use in the Experimental-Result AVP indicates Huawei Technology Co. This doesn't seem apporpriate to the scope of the document as set out in the Abstract and Introduction.

    Telechat:

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. Cisco Vendor Specific RADIUS Attributes for the Delivery of Keying Material (Informational)
    draft-zorn-radius-keywrap-17
    Token: Dan Romascanu
    Discusses/comments (from ballot 2377):
    1. Dan Romascanu: Discuss [2007-01-19]:
      The following input was received from AAA Doctor Bernard Aboba. I believe the points he is raising are correct. The solution seems to be not to approve the document and ask that it's re-submitted as AD-sponsored to allow for proper community review.
      I do not think this document is eligible for publication as an Independent Submission, since it requests IANA to allocate parameters (RADIUS attributes) that require "IETF Consensus" under RFC 3575...
      In addition, the document updates a Draft Track RFC (RFC 2865).

    Telechat:

1312 EDT break

1318 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. Keys In DNS (kidns)
    Token: Tim

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. Ad-Hoc Network Autoconfiguration (autoconf)
    Token: Jari

    Telechat:

  2. Multicast Mobility (multimob)
    Token: Jari

    Telechat:

  3. DNS Extensions (dnsext)
    Token: Ralph

    Telechat:

5. IAB News We can use

6. Management Issues

  1. IESG tools team liaison (Lars Eggert)

    Telechat:

  2. Protocol Number Modification Question [IANA #404374] (Michelle Cotton)

    Telechat:

  3. ENUM Expert (Gonzalo Camarillo)

    Telechat:

7. Agenda Working Group News

1405 EDT Adjourned



Appendix: Snapshot of discusses/comments

(at 2010-12-02 07:30:20 PST)

draft-ietf-mpls-ldp-upstream

  1. Stewart Bryant: Comment [2010-12-02]:
    
        
  2. David Harrington: Comment [2010-11-30]:
    SECTION 3: s/MUST be carried only LDP initialization messages/MUST be carried
    only in LDP initialization messages/
  3. Russ Housley: Comment [2010-11-28]:
      The Gen-ART Review by Avshalom Houri on 13-Oct-2010 includes some
      editorial suggestions.  Please consider them.
  4. Sean Turner: Comment [2010-11-30]:
    Section 4: Shouldn't the two "optional"s be "OPTIONAL"?  They're indicating
    support requirements.

draft-ietf-simple-msrp-acm

  1. Lars Eggert: Comment [2010-11-30]:
      Nit: s/MRSP/MSRP/ in several places in the document.
    
    Section 1., paragraph 2:
    >    [RFC4145] defines a connection-oriended media mechanism, COMEDIA,
    
      Nit: s/connection-oriended/connection-oriented/
    
    Section 1., paragraph 4:
    >    to support more complex mechanims (e.g.  TCP Candidates with
    
      Nit: s/mechanims/mechanisms/
    
    Section 9., paragraph 2:
    >    o  Changes based on comments from Gonzalo Camrillo.
    
      Nit: s/Camrillo./Camarillo./
    
    Section 9., paragraph 8:
    >    Changes from draft-ietf-simple-mscp-acm-02
    
      Nit: s/draft-ietf-simple-mscp-acm-02/draft-ietf-simple-msrp-acm-02/
    
  2. Adrian Farrel: Comment [2010-12-01]:
    Acronyms need to be expanded in the main text on first usage (regardless
    of their use in the Abstract).
    
    ---
    
    Section 3
    
       Support of this specification is optional for MSRP user agents in
    
    Is that "OPTIONAL"?
    
    ---
    
    Section 4.2.2
    
       In accordance with [RFC4145], if the a=setup attribute value is
       "active", the port number value should be 9.
    
    s/should/SHOULD/ ?
    
  3. Sean Turner: Comment [2010-11-30]:
    Sec 1: Spell out SDP on first usage.
    
    Sec 3: r/optional/OPTIONAL?  It's specifying support requirements.
    
    Sec 4.2.1: r/An MSRP UA must support the a=setup.../An MSRP UA MUST support the
    a=setup...

draft-ietf-sipcore-reinvite

  1. Adrian Farrel: Comment [2010-12-02]:
    This issue is not quite a Discuss for me, but I would welcome considetation by
    the authors and resposnsible AD to wee whether any changes can be made to
    clarify the document.
    
    I struggled to see the separation between this document and RFC 3261. 
    
    Many of the procedures described in this documet are already described in RFC
    3261 and I wondered (for example, in the event of a mistake in this document)
    which provides the normative description.
    
    Additionally, this document describes itself as "clarifying" RFC 3261. That
    implies (to me) that it does not introduce any new procedures. This would seem
    to me to make the document Informational (not Standards Track) and not an
    Update.
  2. Peter Saint-Andre: Comment [2010-11-29]:
    The description of "dialog's local target" is confusingly worded. Perhaps you
    could tweak the text so that it's a bit clearer, or provide an example to
    illustrate the concept.
  3. Sean Turner: Discuss [2010-11-30]:
        #1: Section 2:  I see that in sirpcore-event-rate-control it notes that indented
    paragraphs don't contain normative protocol behavior.  Is the same true of the
    indented paragraphs in this draft?  I thought maybe it was just an odd
    formatting thing that some paragraphs are indented.
    
    #2: Section 3.4:
    
       The purpose of this new offer/
       answer exchange is to synchronize both UAs, not to request changes
       that the UAS may choose to reject.  Therefore, session parameters in
       the offer/answer exchange SHOULD be as close to those in the pre-re-
       INVITE state as possible.
    
    Why isn't it "SHOULD be the same"? 
        
  4. Sean Turner: Comment [2010-11-30]:
    #1: Section 3.1:
    
    At a later point, the UAC moves to an access that provides ...
    
    Should it be "access point"?
    
    #2: Section 3.3: 
    
    UASs should only return an error response to a re-INVITE
    
    Should it be "SHOULD"?
    
    #3: Section 3.3:
    
    However, they will not actually be used until the UAS decides so.
    
    Should it be ....until the UAS decides to use them?
    
    

draft-ietf-sipcore-event-rate-control

  1. Jari Arkko: Comment [2010-12-02]:
    I have reviewed this document and placed a no-objection vote, even if I do agree
    with most of the issues raised by Lars and David. I do think though that despite
    its problems and complexity, the document is understandable enough to be
    reviewed. I think the right path is to fix the specific issues in the document
    rather than to bring the document back to the working group. I do think that the
    document should stick to using either rate or frequency terminology, however.
    
    Also, here are some review comments from Ari Keränen who I asked to take another
    look at the document:
    
    The abstract should state that this document updates RFC 3265.
    
    5.1.  Subscriber Behavior
    
        The value of
        this parameter is an integral number of seconds in decimal.
    
    Should that be "decimal integer"? And probably negative values are not 
    OK (should be stated), but how about zero? Same issue in sections 6.1. 
    and 7.1.
    
    7.3.  Calculating the Timeout
    
        timeout = (average-interval ^ 2) * count / period              (1)
    
    It's not really immediately clear how this formula results in correct 
    timeouts. Say, if one uses average-interval of 10s and period of 100s, 
    based on quick calculation, it seems that the timeouts would be 
    0,1,2,...,9 for the first 10 (batches of) messages (10*10*0/100, 
    10*10*1/100, ...) resulting in all 10 messages being sent during the 
    first 45 seconds (as opposed to 100 seconds); or didn't I get the 
    formula right?
    
    9.2.  Grammar
    
           min-interval-param =   "min-interval" EQUAL delta-seconds
    
    The "delta-seconds" token is not defined.
  2. Ralph Droms: Discuss [2010-12-02]:
        
    I fall somewhere between Jari and David regarding the use of "rate"
    "frequencey" and "interval" terminology.  I agree with Jari that the
    document can be reviewed and fixed with editorial updates.  However,
    this text from section 5.2 is an example of what I think needs to be
    fixed, not just improved:
    
       A compliant notifier MUST NOT generate notifications more frequently
       than the maximum rate allows for [...]
    
    The specific parameter is a minimum interval, not a maximum rate.
    To ensure accurate compliance with the specification, the requirement must
    be stated in terms of the parameter, not the inverse of the parameter
    (which, speaking pedantically, is not as precise):
    
       A compliant notifier MUST NOT generate notifications with an
       interval between notifications less than the currently allowed
       minimum interval [...]
    
    Text such as this excerpt from the next paragraph is OK, but could be
    improved:
    
       When a local policy dictates a maximum rate for notifications, a
       notifier will not generate notifications more frequently than the
       local policy maximum rate
    
    which mixes frequency and rate but is still understandable and has no
    normative requirements langauge.  I think this text would be more
    accurate:
    
       When a local policy dictates a minimum interval for notifications,
       a notifier will not generate notifications more frequently than the
       local policy minimum interval [...]
     
        
  3. Lars Eggert: Discuss [2010-11-30]:
        Section 6., paragraph 0:
    > 6.  Operation of the Minimum Rate Mechanism
    
      DISCUSS: Assuming that you disallow max_interval := 0, this mechanism
      can still be used to get the notifier to generate a notification once
      per second. This can put some stress on the network as well as on the
      notifier. It's also questionable from the example use cases that a
      notification rate that is that aggressive can be useful. Can we define
      a useful max_interval that is larger than 1 second? If not, can we add
      some strong language here to caution implementers to use the lowest
      possible useful rate here? (This also applies to the "adaptive"
      variant.)
     
        
  4. Lars Eggert: Comment [2010-11-30]:
    Section 3.4., paragraph 7:
    >            paremeters are adjusted from the value given by the
    
      Nit: s/paremeters/parameters/
    
    Section 7.1., paragraph 4:
    >    The main consequence for the subscriber when applying the adative
    
      Nit: s/adative/adaptive/
    
    Section 7.3., paragraph 5:
    >    period:  The rolling average period, in seconds.  The value of the
    >       "period" parameter is chosen by the notifier, however the notifier
    >       MUST choose a value greater than the value of the "average-
    >       interval" parameter.
    
      Additionally, period should be several times larger than the
      average-interval, because otherwise, not much averaging will happen -
      the mechanism degrades to the non-adaptive variant.
    
  5. Adrian Farrel: Comment [2010-12-02]:
    Just a few nits in a document I found otherwise to be very readable.
    
    idnits points out...
    
      -- The document has a disclaimer for pre-RFC5378 work, but was first
         submitted on or after 10 November 2008.  Does it really need the
         disclaimer?
    
    ---
    
    Section 1
    
       none of the event package specifications have defined such a
       mechanism.
                                                                                  
    s/have/has/
    
    ---
    
    Section 3.4 Req 7
                                                  
                  For example, due to congestion reasons, local policy at
    
    s/due/owing/
    
    ---
    
    Section 4.1                                                                     
    
       In general, the way in which a subscriber generates SUBSCRIBE
       requests and processes NOTIFY requests is according to RFC 3265
       [RFC3265].
    
    "In general"?
    
    Similarly in section 4.2
    
       In general, the way in which a notifier processes SUBSCRIBE requests
       and generates NOTIFY requests is according to RFC 3265 [RFC3265].
    
  6. David Harrington: Discuss [2010-11-30]:
        1) The document continually refers to both rate and interval - two sides of the
    same coin. I find the current approach to handling this very distracting. I
    think the document would be clearer if you chose one perspective, explained in
    the terminology section how it relates to the other perspective, and then used
    the one perspective consistently. Maybe you should rename the parameters to
    reflect the rate perspective - e.g., change "min-interval" to "max-rate".
    2) 3.1
    talks about "notifications that do not comply with the maximum rate". I'm not
    sure quite what that means - I assume it means notifications are generated
    faster than they are allowed to be sent. Why not say that? 
    3) 3.1 says the RLS
    will "batch all    of the buffered state changes together in a single
    notification only
       when allowed by the maximum rate." - I don't uinderstand
    "when allowed by the maximum rate". The maximum rate is a number. How does that
    number "allow" batching?
    In addition, section 1 says "it is strictly an
    implementation decision whether batching of notifications is
       supported, and
    by what means." So I don't understand what "allowed by the maximum rate" means
    relative to the implementation decision. My impression is that "maximum rate" is
    being used to refer to an abstraction of the whole process, and that does not
    lead to clear and unambiguous standards specification.
    4) 3.1 says "The presence
    client can also modify the "min-interval" parameter during the lifetime of the
    subscription.  For example, if the User Interface (UI) of the application shows
    inactivity for a period of time, it can simply pause the notifications by
    setting the "min-interval" parameter to the subscription expiration time, while
    still keeping the subscription alive.  When the user becomes active again, the
    presence client can resume the stream of notifications by re-subscribing with a
    "min-interval" parameter set to the earlier used value." 
    This text conflates
    the application, the UI, the user, and the presence client. These are
    potentially different entities - an application's database of activity might be
    a totally different process than its UI. I assume the presence client is an
    abstract fucntionality supported by an application - possibly implemented in a
    totally different process. and the user obviously is neither the application,
    nor the UI, nor the presence client. Is the presence client supposed to have a
    mechanism to watch the UI to see whether there is UI activity? or does it detect
    inactivity by monitoring protocol acivity? How exactly does it detect this-
    which protocols should be watched? 
    5) in 3.2, "In order to control the actual
    state, the location application sets a minimum rate ("max-interval" parameter),
    i.e. a maximum time interval between two notifications." Again, this approach of
    "here, let me say this three different ways" is distracting. More important,
    should this text say that it sends the parameter to the RLS? or does it just set
    an internal parameter paid attention to at the presence client? 
    6) 3.3 says
    "The "average-interval" parameter value is used by the notifier to dynamically
    calculate the actual maximum time ("timeout" parameter) between two
    notifications." Is the maximum time "timeout" parameter the same parameter
    called "max-interval" in section 1? Is"actual maximum time" the same as the
    configured max-interval? Or is the actual maximum time an imperical measurement
    value about the "actual" maximum time in practice?
    7) 4.1 says "If the
    subscriber did not include at least one of the "min-interval, "max-interval", or
    "average-interval" header field parameters in the most recent SUBSCRIBE request
    in a given dialog, it MUST NOT include an Event header field with any of those
    parameters in a 2xx response to a NOTIFY request in that dialog." The "it" in
    thsi sentence should be replaced by a named "actor". Is this the server that
    MUST NOT include things in the response?
    8) 4.2 says "A notifier that supports
    the different rate control mechanisms will comply with the value given in "min-
    interval", "max-interval" and "average-interval" parameters and adjust its rate
    of notification accordingly.  However, if the notifier needs to lower the
    subscription expiration value or if a local policy or other implementation-
    determined constraint at the notifier can not satisfy the rate control request,
    then the notifier can adjust (i.e. increase or decrease) appropriately the
    subscriber requested rate control." How do I comply with a value? I know how to
    comply weith a standard, but not with a value. The "will comply" seems to call
    for a RFC2119 keyword. "will comply" seems to call for a MUST, but the next
    sentence discusses the exceptions, so I guess "will comply" needs to tbe
    replaced by a SHOULD.
    9) 5.1 says "Note that the witnessed time between two
    consecutive received notifications may not conform to  the "min-interval" value
    for a number of reasons.  For example, network jitter and retransmissions may
    result in the subscriber receiving the notifications with smaller intervals than
    the "min-interval" value recommends." Hmmm. Doesn't min-interval mean do not
    send notifications more fequently than every X seconds?  Am I missing somethign
    in my interprwetation? Doesn't this text say that the receiver might receive the
    notifications at a rate faster than the rate they are sent?
    
    I stopped reviewing the document at section 5.1. I find the loose terminology
    used in this document makes this document not ready for publication as a
    standard. the language must be clear and unambiguous. I think this document
    should go back to the WG for tightening, and be resubmitted only after it has
    been tightened up. 
        
  7. Alexey Melnikov: Discuss [2010-12-02]:
        In 9.2:
    
          event-param    =/  min-interval-param
          subexp-params  =/  min-interval-param
          min-interval-param =   "min-interval" EQUAL delta-seconds
    
          event-param    =/  max-interval-param
          subexp-params  =/  max-interval-param
          max-interval-param =   "max-interval" EQUAL delta-seconds
    
          event-param    =/  average-interval-param
          subexp-params  =/  average-interval-param
          average-interval-param =   "average-interval" EQUAL delta-seconds
    
    delta-seconds is not defined in the document. I think it is coming from RFC
    3261, but this needs to be stated explicitly. 
        
  8. Peter Saint-Andre: Comment [2010-11-30]:
    1. In Section 3.4, the parameter names do not belong in the requirement
    definitions because they are implementations of the requirements. Thus I
    suggest:
    
       REQ1:   The subscriber must be able to set a maximum rate 
               of notifications in a specific subscription.
    
       REQ2:   The subscriber must be able to set a minimum rate
               of notifications in a specific subscription.
    
       REQ3:   The subscriber must be able to set an adaptive 
               minimum rate, which adjusts the minimum rate of
               notifications based on a moving average.
    
       REQ7:   The notifier must be allowed to use a policy in which
               the maximum rate, minimum rate, and adaptive minimum 
               rate are adjusted from the value given by the subscriber.
    
    2. In Sections 5.1, 6.1, and 7.1, what is "an integral number of seconds in
    decimal"? An integral number sounds like an integer, i.e., a whole number, i.e.,
    not a decimal number. Please clarify.

draft-ietf-geopriv-rfc3825bis

  1. Stewart Bryant: Comment [2010-12-01]:
    PIFF-LO term used but not defined
    GML term used but not defined
    Code:
    GEOCONF_GEODETIC (16 bits). is "Option Code" in the fig above.
    AType:
    Altitude Type (4 bits). would be clearer with a ref to section 2.4 (appears in
    two places)
    
    
  2. Ralph Droms: Discuss [2010-12-02]:
        (Including the dhc WG chairs in the discussion thread for their input on
    the reuse of option code 123 or use of a new option code.)
    
    Like Adrian, I am concerned about the details of how this document
    refers to RFC 3825 and the disposition of RFC 3825.  For example,
    because of the changes to the interpretation of the Datum field, it is
    important that 3825bis, when published, is a self-contained
    description of the syntax and semantics of both versions of the
    options. 
    
    As another example, the text in section 2.2.1.1 that begins "Moving forward..."
    would be better written to simply reference "3825bis-compliant clients"
    
    Did the working group consider defining a new option for the new
    format?  Were the alternatives of an RFC3825bis versus a new option
    discussed with the dhc WG?  Although there is some need to conserve
    DHCP option codes, the use of a new option code for this new format of
    the option would avoid the problems with backward compatibility: 
    
    * an RFC 3825 compliant client misinterprets the
      contents of a 3825bis DHCP option 123 because of the
      unexpected version value 1
    * an RFC 3825 compliant client rejects the contents of
      a 3825bis option 123 because the version value 1 causes
      the client to interpret the option as containing an
      invalid datum value; the client has no way to indicate
      to the server that it has rejected the option contents
    * a DHCP client can't indicate which version of the option
      it understands
    
    In the IANA considerations section, I would like to see a
    clarification that the registries replace the existing registries.
    The second paragraph states that new Altitude Types and Datums must
    define the way in which the related uncertainty values are
    interpreted.  However, the registry values in the table do not include
    those definitions; presumably, the uncertainty values are interpreted
    as in 3825bis, but this interpretation should be indicated in the
    registry. 
        
  3. Ralph Droms: Comment [2010-12-02]:
    I found the wording of the IANA Considerations section confusing and
    inconsistent.  I suggest:
    
       IANA maintains registries for the Altitude Type (AType), Datum and
       Version fields.  New values for each of these registries are
       assigned through "Standards Actions" [RFC5226].
    
       Each AType registry entry MUST define the way that the 30 bit
       altitude values and the associated 6 bit uncertainty are
       interpreted. 
    
       Each Datum registry entry MUST include specification of both
       horizontal and vertical datum, and MUST define the way that the 34
       bit values and the respective 6 bit uncertainties are interpreted.
    
       The initial AType registry is:
    
       The initial Datum registry is:
    
       The initial Version registry is:
    
  4. Adrian Farrel: Discuss [2010-12-01]:
        Thank you for this document.
    
    I'm afraid that I don't understand the situation after it is published as an
    RFC. It claims to obsolete RFC 3825, but a lot of the text refers to things
    like...
    
       This document defines the Ver field for the DHCPv4 and DHCPv6
       options.  New values for the Ver field are assigned through
       "Standards Action" [RFC5226].  Initial values are as follows:
    
       0: DHCPv4 Implementations conforming to [RFC3825]
       1: Implementations of this specification (for both DHCPv4 and DHCPv6)
    
    This is not possible because this document obsoletes RFC 3825, so there cannot
    be conformance to the RFC any more!
    
    I think a little time should be spent re-working the text around references to
    RFC 3825. Either 3825 is being made historic, or this document is replacing
    (obsoleting) 3825 and becaomes the full (self-contained) reference for
    implementations. In fact (as is stated in seciton 2.2)...
    
                  This specification defines the behavior of
                  version 0 (originally specified in [RFC3825]) as well as
                  version 1. 
    
    ...so you don't need to reference 3825, and can just get on with the
    specification of the two versions. 
        
  5. David Harrington: Comment [2010-11-30]:
    This document is well-written, with clear and unambiguous language. 
    
    1) section 1, paragraph 4 says "The DHCP server could correlate the Circuit-ID
    with the geographic location where the
       identified circuit terminates (such as
    the location of the wall jack)." Would it be the job of the DHCP server to do
    this correlation? I would assume it was a NM application function to do such
    correlation. 
    2) In 2.2.1.2, s/same response. This is not useful since/same
    response, since/
    3) When aType=2, numbering starts at ground level. How does one
    represent an underground parking garage level?
    Should 2.4.3 mention how to
    represent this? Should Appendix B include such an example?

draft-ietf-xmpp-3920bis

  1. Adrian Farrel: Discuss [2010-12-02]:
        A very substantial piece of work: thanks.
    
    I checked through the Errata raised against RFC 3920 and cannot satisfy myself
    that the issue raised in 1406 (http://www.rfc-
    editor.org/errata_search.php?eid=1406) has been addressed. The idea was, I
    think, simply to qualify the use of digests in examples to prevent anyone
    attempting to deduce meaning from them.
    
    Does anything need to be added to this revision? 
        
  2. Alexey Melnikov: Discuss [2010-12-01]:
        [I now finished reading the whole document, but there might be a couple of more
    issues that I am planning to raise later. New comments in each section since the
    last time are after the "----NEW----" marker]
    
    I am not really surprised, but this is a very well written document. Some quick
    comments/questions before I can recommend approving it:
    
    1)
    4.5.3.  Idle Peer
    
       Even if the underlying TCP connection is alive and the stream is not
       broken, the peer might have sent no stanzas for a certain period of
       time.  In this case, the peer SHOULD close the stream using the
       handshake described under Section 4.4.
    
    SHOULD close the stream, or SHOULD use the procedure in Section 4.4 if it
    decides to close it?
    
       If the idle peer does not
       close the stream, the other party MAY either close the stream using
       the handshake described under Section 4.4 or return a stream error
       (e.g., <resource-constraint/> if the entity has reached a limit on
       the number of open TCP connections or <policy-violation/> if the
       connection has exceeded a local timeout policy).  However, consistent
       with the order of layers (specified under Section 13.3), the other
       party is advised to verify that the underlying TCP connection is
       alive and the stream is unbroken (as described above) before
       concluding that the peer is idle.  Furthermore, it is preferable to
       be liberal in accepting idle peers, since experience has shown that
       doing so improves the reliability of communication over XMPP networks
       and that it is typically more efficient to maintain a stream between
       two servers than to aggressively timeout such a stream.
    
    This is arguing for MAY above.
    
    2)
    4.6.4.  xml:lang
    
       o  If the receiving entity supports a language that closely matches
          the initiating entity's preferred language (e.g., "de" instead of
          "de-CH"),
    
    I think you really need to be referencing Section 3.4 of RFC 4647 for this,
    as the process you describe above is not very formal (and might introduce
    wrong results if coded by a naive implementor).
    
          then the value of the 'xml:lang' attribute SHOULD be the
          identifier for the matching language (e.g., "de") but MAY be the
          identifier for the default language of the receiving entity (e.g.,
          "en").
    
    3)
    5.3.5.  TLS Renegotiation
    
       Support for TLS renegotiation is strictly OPTIONAL.  However,
       implementations that support TLS renegotiation MUST implement and use
       the TLS Renegotiation Extension [TLS-NEG].
    
    This makes [TLS-NEG] a Normative Reference.
    
    4)
    6.4.2.  Initiation
    
       If the initiating entity subsequently sends another <auth/> element
       (even if the ongoing authentication handshake has not yet completed),
       the server SHOULD discard the ongoing handshake and begin a new
       handshake for the subsequently requested SASL mechanism.
    
    What are the possible conditions for violating the SHOULD?
    The server really
    MUST fail the existing handshake, but maybe it doesn't have
    to begin a new
    handshake (e.g. it might choose to close the connection instead?).
    
    5) DISCUSS DISCUSS
    
       [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
                  3.2.0", 2000.
    
                  The Unicode Standard, Version 3.2.0 is defined by The
                  Unicode Standard, Version 3.0 (Reading, MA, Addison-
                  Wesley, 2000.  ISBN 0-201-61633-5), as amended by the
                  Unicode Standard Annex #27: Unicode 3.1
                  (http://www.unicode.org/reports/tr27/) and by the Unicode
                  Standard Annex #28: Unicode 3.2
                  (http://www.unicode.org/reports/tr28/).
    
    Should this be upgraded to at least Unicode 5.1?
    
    6)
    13.8.2.  For Confidentiality Only
    
       For confidentiality only, servers SHOULD support TLS with the
       TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.
    
    Why only a SHOULD?
    
    ----NEW----
    
    7) TLS-server-identity documents requires that protocols referencing it
    explicitly specify if wildcards are allowed in certificates. XMPP Core is silent
    on this, yet it shows some examples of certificates with wildcards. 
        
  3. Alexey Melnikov: Comment [2010-12-01]:
    1.4.  Terminology
    
       The term "whitespace" is used to refer to any character that matches
       production [3] content of [XML], i.e., any instance of the SP, HTAB,
       CR, or LF rules defined in [ABNF].
    
    Any single character or multiple characters?
    
    3.2.1.  Preferred Process: SRV Lookup
    
       3.  If a response is received, it will contain one or more
           combinations of a port and hostname, each of which is weighted
           and prioritized as described in [DNS-SRV].  However, if the
           result of the SRV lookup is a single resource record with a
           Target of ".", i.e. the root domain, then the initiating entity
           MUST abort SRV processing at this point (but SHOULD attempt the
           fallback process described in the next section).
    
     [...]
    
       7.  If the initiating entity fails to connect using all resolved IP
           addresses for a given hostname, then it repeats the process of
           resolution and connection for the next hostname returned by the
           SRV lookup.
    
    While this is implied, it might be better to point out that the "next" is
    selected based on priority/weight from [DNS-SRV].
    
    3.2.2.  Fallback Processes
    
       For client-to-server connections, the fallback MAY be a [DNS-TXT]
    
    Is this Normative? It looks like it is.
    
       lookup for alternative connection methods, for example as described
       in [XEP-0156].
    
    3.2.3.  When Not to Use SRV
    
       If the initiating entity has been explicitly configured to associate
       a particular hostname (and potentially port) with the origin domain
       of the receiving entity (say, to "hardcode" an association from an
       origin domain of example.net to a configured hostname of
       webcm.example.com:80), the initiating entity SHOULD use the
    
    Is use of port 80 a good example in this document?
    
    4.2.2.  Stream Features Format
    
       A <features/> element MAY contain more than one mandatory feature.
       This means that the initiating entity can choose among the mandatory
       features.  For example, perhaps a future technology will perform
       roughly the same function as TLS, so the receiving entity might
       advertise support for both TLS and the future technology.
    
    So if the server requires both TLS and SASL, does this mean that it first
    advertises TLS as required (and SASL is either advertised as optional or not
    advertised),
    and then once TLS negotiation is complete, SASL needs to be
    advertised as required
    (on the restarted stream)?
    
    4.2.7.  Flow Chart
    
    In the flowchart - is "receive stream features" required after each negotiation
    of a voluntary feature?
    
    4.6.  Stream Attributes
    
       The attributes of the root <stream/> element are defined in the
       following sections.
    
          Security Note: Until and unless the confidentiality and integrity
          of a stream header is ensured via Transport Layer Security as
          described under Section 5, the attributes provided in a stream
          header could be tampered with by an attacker.
    
    Or SASL security layer (e.g. GSSAPI).
    
    4.7.2.  Content Namespace
    
       When a content namespace is not declared as the default namespace and
       so-called "prefix-free canonicalization" is used instead, in rough
       outline a stream will look something like the following.
    
       <stream
           from='juliet@im.example.com'
           to='im.example.com'
           version='1.0'
           xml:lang='en'
           xmlns='http://etherx.jabber.org/streams'>
         <message xmlns='jabber:client'>
           <body>foo</body>
         </message>
       </stream:stream>
    
    Should the closing tag be </stream> above?
    
    4.7.4.  Namespace Declarations and Prefixes
    
       An implementation MUST NOT generate namespace prefixes for elements
       qualified by the content namespace if the content namespace is
       'jabber:client' or 'jabber:server' (e.g., <foo:presence/>).  An XMPP
    
    Can you try to explain this again, you lost me here.
    
       entity MUST NOT accept data that violates this rule (in particular,
       an XMPP server MUST NOT route or deliver such data to another
       entity); instead it MUST either ignore the data or return a stream
       error (which SHOULD be <bad-namespace-prefix/>).
    
    5.4.3.1.  Rules
    
       7.  Following successful TLS negotiation, all further data
           transmitted by either party MUST be encrypted.
    
    Did you really meant "encrypted" here? What about use of NULL ciphers
    with integrity protection?
    
    5.4.3.3.  TLS Success
    
       R: <stream:features>
            <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
              <mechanism>EXTERNAL</mechanism>
              <mechanism>PLAIN</mechanism>
            </mechanisms>
          </stream:features>
    
    This should include SCRAM-SHA-1 :-), as it is an MTI.
    
    6.3.3.  Mechanism Preferences
    
       Any entity that will act as a SASL client or a SASL server MUST
       maintain an ordered list of its preferred SASL mechanisms according
       to the client or server, where the list is ordered according to local
       policy or user configuration (which SHOULD be in order of perceived
       strength to enable the strongest authentication possible).  A server
       MUST offer and a client MUST try SASL mechanisms in preference order.
    
    Is this clear that server's and client's preference orders are different?
    
       For example, if the server offers the ordered list "PLAIN SCRAM-SHA-1
       GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list
       is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then
       SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list).
    
    6.3.7.  Simple User Name
    
       Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify
       that the authentication identity used in the context of such
       mechanisms is a "simple user name" (see Section 2 of [SASL] as well
       as [SASLPREP]).  The exact form of the simple user name in any
       particular mechanism or deployment thereof is a local matter, and a
       simple user name does not necessarily map to an application
       identifier such as a JID or JID component (e.g., a localpart).
       However, in the absence of local information provided by the server,
       an XMPP client SHOULD assume that the authentication identity for
       such a SASL mechanism is a simple user name equal to the localpart of
       the user's JID.
    
    Or bare JID? I believe many implementations based on Cyrus SASL allow full
    email-like syntax here.
    
    6.3.9.  Realms
    
       The receiving entity MAY include a realm when negotiating certain
       SASL mechanisms.  If the receiving entity does not communicate a
       realm, the initiating entity MUST NOT assume that any realm exists.
       The realm MUST be used only for the purpose of authentication; in
       particular, an initiating entity MUST NOT attempt to derive an XMPP
       hostname from the realm information provided by the receiving entity.
    
    Should this be clearer about which mechanisms are we talking about?
    IMHO, being vague is not being helpful here.
    
    8.3.1.  Rules
    
       4.  An error stanza MUST contain an <error/> child element.
    
       7.  An <error/> child MUST NOT be included if the 'type' attribute
           has a value other than "error" (or if there is no 'type'
           attribute).
    
    Are these 2 in conflict? If they are not, should they be combined into a single
    rule?
    
    8.3.3.13.  policy-violation
    
       The entity has violated some local service policy (e.g., a message
       contains words that are prohibited by the service); the server MAY
       choose to specify the policy in the <text/> element or in an
       application-specific condition element; the associated error type
       SHOULD be "modify" or "wait" depending on the policy being violated.
    
       (In the following example, the client sends an XMPP message that is
       too large according to the server's local service policy.)
    
    It might be better to change the description to mention prohibited words (e.g.
    "!!!").
    Otherwise this looks too similar to <not-acceptable/>.
    
       C: <message from='romeo@example.net/foo'
                   to='bill@im.example.com'
                   id='vq71f4nb'>
            <body>%#&@^!!!</body>
          </message>
    
    13.7.2.2.1.  Case #1
    
       If the client certificate appears to be certified by a certification
       path terminating in a trust anchor (as described in Section 6.1 of
       [PKIX]), the server MUST check the certificate for any instances of
       the XmppAddr as described under Section 13.7.1.4.  There are three
       possible sub-cases:
    
       Sub-Case #1:  The server finds one XmppAddr for which the domainpart
          of the represented JID matches one of the configured hostnames of
          the server; the server SHOULD use this represented JID as the
          validated identity of the client.
    
       Sub-Case #2:  The server finds more than one XmppAddr for which the
          domainpart of the represented JID matches one of the configured
          hostnames of the server; the server SHOULD use one of these
          represented JIDs as the validated identity of the client, choosing
          among them according to local service policies or based on the
          'to' address of the initial stream header.
    
    What if the client has multiple accounts on the same server and they use
    the same certificate? (I admit that that might be an obscure case.)
    Should the server be using the 'from' value to differentiate as well?
    
    13.9.4.  Use of SASL
    
       Many deployed XMPP services authenticate client connections by means
       of passwords.  It is well-known that most human users choose
       relatively weak passwords.  Although service provisioning is out of
       scope for this document, XMPP servers that allow password-based
       authentication SHOULD enforce minimal criteria for password strength
       to help prevent dictionary attacks.  Because all password-based
       authentication mechanisms are susceptible to password guessing
       attacks, XMPP servers MUST implement common rate-limiting
       mitigations.
    
    Rate-limiting during SASL authentication?
    
    13.9.5.  Use of TLS
    
       Implementations of TLS typically support multiple versions of the
       Transport Layer Security protocol as well as the older Secure Sockets
       Layer (SSL) protocol.  Because of known security vulnerabilities,
       XMPP servers and clients MUST NOT request, offer, or use SSL 2.0.
       See Appendix E.2 of [TLS] for further details.
    
    This should probably point to draft-ietf-tls-ssl2-must-not. The reference
    doesn't need to be normative.
    
    ----NEW----
    
          Service providers SHOULD include the
          DNS-ID identifier type in certificate requests.
    
    XMPP Service providers?
    
  4. Robert Sparks: Discuss [2010-11-30]:
        This is a solid document. I have one major point (the first below) that I would
    like to discuss.
    I expect the remaining points to be easy to address (or be
    convinced to remove them after discussion).
    
    1) This draft requires that an intial stream be established before starting TLS
    negotiation,
       and requires (at SHOULD strength) that the stream element that
    is sent in the clear
       have a from attribute identifying the user if known. It
    doesn't feel right to require a
       privacy leak like that. Would it make more
    sense to elide the from if the client knows
       it wants to try using TLS, or at
    least provide a way to use a from that couldn't be used
       by third parties to
    identify the user?
    
    2) Section 3.2.2's MAY seems to make [DNS-TXT] and [XEP-0156] normative.
    
    3) Section 4.4 - why is the specified behavior for the element that sends a
    closing stream tag defined
       as a SHOULD? When is it ok for the element to do
    something different, and what would it do?
    
    4) Section 8.3.1 - Does "generated stanza" mean "the stanza that caused an error
    to be generated"?
       Can you provide more detail about why swapping the to and
    from are SHOULD (I can't figure out what
       in section 13.10 would have you not
    simply swap.)
    
    5) page 137 (delivery related attack point 2) : this paragraph "How a server ...
    bare JID." does not parse.
    
    6) Section 10.5.3.1 The second bullet seems to make [XMPP-IM] a normative
    reference. There were other
       places in the document where [XMPP-IM] seemed to
    be required reading in order to build a conformant
       implementation.
    
    7) Section 10.5.3.2 : Why, for a message stanza, do you say SHOULD deliver to at
    least one matching resource?
       Why is this not a MUST, and why do you allow
    something between one and all?
    
    8) Section 13.10.1 : It's not clear what you really mean by "make the IP address
    or method of access public".
       How do you test this MUST NOT? Can you give
    examples of what you're worried a server implemenation  might
       do in error?
    
    9) Section 13.12, item 4 : this 10000 is a magic number - please consider
    calling out that it was arbitrarily
       chosen. More importantly, please add text
    disuading implementers from chosing to set a limit of 10000 bytes
       by default. 
        
  5. Robert Sparks: Comment [2010-11-30]:
    Please consider clarifying that you are not requiring elements to reject streams
    that use a prefix with
    the literal value "stream", only that you are allowing
    them to do so to allow legacy implementations to be
    compliant. It might help to
    be even more explicit that clients that chose not to use the literal "stream"
    prefix may have interoperability problems with those legacy implementations.
    Also consider pointing to this
    exception to the general principal of allowing
    the sender to set the string it uses as a prefix label in the
    section on page
    124 (where you note that "receiving entities MUST NOT depend on the prefix
    strings to have
    any particular value.")
    
    Some additional explanation of SRV's resolving to "." meaning "don't use SRV"
    would help.
    Why is this mechanism there?
    
    In 4.2.5 - Please consider a little more explanation on why an initiating
    element might send stanzas to itself?
    
    Please consider adding forward pointers from the keep-alive sections (such as
    4.5.1) to the requirement
    to not send whitespace during TLS and SASL
    negotiation. (5.3.3, 6.3.5)
    
    In 4.8.3.9 - "not a valid JID" may be ambiguous - is it intended to include "not
    well formed"?
    
    In 5.3.5 - what does "blindly attempt" mean? why is the requirement around it
    SHOULD NOT? 
    When is it OK to blindly attempt?
    
    In 5.4.3.3 - the "Implementation Note:" actually contains a normative
    requirement defining protocol behavior.
    Similarly, 8.3.3.14 has a Security Note
    with normative requirements. I strongly suggest moving actual
    protocol
    requirements out of those notes.
    
    In 6.3.8 - Can you provide a reference to where is the behavior for acting on
    the behalf of another party is specified?
    
    In 6.4.6  - Can you add some text justifying why the entity SHOULD terminate the
    connection attempt 
    if the from identity and the SASL authentication identity do
    not match, and why this is a SHOULD not a MUST?
    
    In 8.3.3.15 : This section doesn't provide a way to protect against redirect
    loops (such as see-other-host did). Should it?
    
    In 10.4.1 : should this "will" be a MUST?
    
    In 13.1 : has the group considered a "fail this stanze if it would go over a hop
    that isn't TLS protected" request extension?

draft-ietf-xmpp-address

  1. Russ Housley: Discuss [2010-11-30]:
        
      In the Gen-ART Review by Elwyn Davies on 30 November 2010, one issue
      was discovered that is easily addressed.  I think consistent terms
      will aid future readers and implementers.
    
        s4.3.1, last para: There should be a formal definition of 'Bare JID'
        as it is extensively used in draft-ietf-xmpp-3920bis.  Note that
        almost all the cases where 'Bare JID' is used, both in this document
        and 3920bis add a expansion that this means <localpart@domainname>,
        except for one instance in s8.1.2.1 of 3920bis where it means just
        <domainname> (also referred to as 'Mere Dominname' elsewhere in
        3920bis!). 
        
  2. Alexey Melnikov: Discuss [2010-11-19]:
        I just can't possibly resist not having a DISCUSS on this document ;-). Below
    are my review comments:
    
    1).
    RFC 3920:
    
          domain          = fqdn / address-literal
          fqdn            = (sub-domain 1*("." sub-domain))
          sub-domain      = (internationalized domain label)
          address-literal = IPv4address / IPv6address
    
    draft-ietf-xmpp-address:
    
          domainpart    = IP-literal / IPv4address / ifqdn
                          ; the "IPv4address" and "IP-literal" rules are
                          ; defined in RFC 3986, and the first-match-wins
                          ; (a.k.a. "greedy") algorithm described in RFC
                          ; 3986 applies to the matching process
    
    RFC 3986:
    
          IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
    
          IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
    
    (DISCUSS DISCUSS)
    This means that the draft is proposing usage of "[" and "]"
    around IPv6 addresses, which is a change from RFC 3920.
    I think the change is
    sensible, but is it covered by Appendix C?
    
    2).
    In Section 2.1:
    
       An XMPP URI or IRI
       [XMPP-URI] is in essence a JID prepended with 'xmpp:', but the native
       addressing format used in XMPP is that of a mere JID without a URI
       scheme.
    
    I think this text is misleading for URIs: it is effectively suggesting that
    percent-decoding/encoding is not needed
    when converting a JID to URI, which is
    not correct. URIs are always in US-ASCII, while JIDs are not.
    Similar
    assumptions about mailto: URIs caused some interoperability problems.
    
    3). [DNS] seems to be Normative (for the definition of a Fully Qualified Domain
    Name).
    
    4). DISCUSS DISCUSS:
    Should domainpart be migrated to IDNA2008 now? Apps Area is
    pretty much requiring use of IDNA2008 in all documents.
    
    5). I still need to double check the following, but from a cursory look this
    seems to be a minor problem:
    
    Can application of Nodeprep/resourceprep to a non empty string result in an
    empty string, which would violate the requirement on nodepart/resourcepart being
    non empty?
    
    This will affect several sections, including Section 6.
     
        
  3. Alexey Melnikov: Comment [2010-11-19]:
    1). In 4.3.1 SASL needs an Informative Reference
    
    2).
    
    o  A resourcepart can be employed as one part of an entity's address
          in XMPP.  One common usage is as the name for an instant messaging
          user's connected resource; another is as the nickname of a user in
          a multi-user chat room; and many other kinds of entities could use
          resourceparts as part of their addresses.  The security of such
          services could be compromised based on different interpretations
          of the internationalized resourcepart; for example, a user could
          attempt to bind multiple resources with the same name,
    
    Can you expand on what is the problem with binding multiple resources to the
    same name?
    
    3).
    In Section 6:
    
       Feature:  address-domain-length
       Description:  Ensure that the domainpart of an XMPP address is at
          least one byte in length and at most 1023 bytes in length.
    
    Domain names have lower length boundary due to DNS restrictions.
    Should this be at least mentioned? (Also applies elsewhere)
    
       Section:  Section 2.2
       Roles:  Both MUST.
    

draft-ietf-dhc-leasequery-by-remote-id

  1. Lars Eggert: Comment [2010-11-30]:
    Section 1., paragraph 1:
    >    active lease informations associated with a given connection/circuit,
    
      Nit: s/informations/information/
    
    Section 4.8., paragraph 2:
    >    To generate replies for a lease query by Remote ID effeciently, a
    
      Nit: s/effeciently,/efficiently,/
    
  2. Adrian Farrel: Comment [2010-12-02]:
    In section 4.1
    
       The DHCPLEASEQUERY message is typically sent by an access
       concentrator.
    
    I really hate this type of language :-)
    
    We can assume that you do not mean that most messages sent by an access
    concentrator are DHCPLEASEQUERY messages.
    
    You mean that most DHCPLEASEQUERY messages are sent by access
    concentrators (not just by "an access concentrator" - I have an image of
    some poor box in the Internet responsible for sending all the messages)
    
    But missing from the description is a statement of who sends the other
    (atypical) DHCPLEASEQUERY messages.
    
  3. Tim Polk: Discuss [2010-12-01]:
        The security considerations state:
    
       This document does not introduce any new security concerns beyond
       those specified in the original lease query protocol RFC 4388
       [RFC4388] specifications.
    
    RFC 4388's Security Considerations note that:
    
       DHCP servers SHOULD prevent exposure of location information
       (particularly the mapping of hardware address to IP address lease,
       which can be an invasion of broadband subscriber privacy) by
       employing the techniques detailed in [RFC3118], "Authentication for
       DHCP Messages".
    
    While exposure of location information was possible with RFC 4388, this
    specification seems to simplify and magnify the problem.  If the DHCP
    server accepts an unauthenticated message (or fails to verify the authentication
    information), a lease query by remote ID permits an attacker to obtain all the
    location information in a very efficient manner.  Since the risk is heightened,
    I think a few additional words highlighting the importance of the DHCP
    authentication mechanism would be appropriate in this specification. 
        
  4. Sean Turner: Comment [2010-12-02]:
    #1) I support Tim's discuss.
    
    #2) I can't parse this sentence in the abstract:
    
       RFC 4388 defines a mechanism for relay
       agents to retrieve the lease information from the DHCP server as and
       when this information is lost.
    
    remove "as and"?
    
    #3) Expand DSLAM.
    
    #4) Section 4.7/8/9: Should the shoulds be SHOULDs?

draft-ietf-mext-rfc3775bis

  1. Stewart Bryant: Comment [2010-12-02]:
    It would be useful to the reader to describe the reason for the update much
    earlier in the introduction.
  2. David Harrington: Discuss [2010-12-02]:
        1) the follwoing text (from rfc3775) should probably be made more/less
    normative:
       The deletion of a binding can be indicated by setting the Lifetime
    field to 0 and by setting the care-of address equal to the home
       address.  In
    deletion, the generation of the binding management key
       depends exclusively on
    the home keygen token, as explained in Section
       5.2.5.  (Note that while the
    senders are required to set both the
       Lifetime field to 0 and the care-of
    address equal to the home
       address, Section 9.5.1 rules for receivers are more
    liberal, and
       interpret either condition as a deletion.)
    What is REQUIRED of a
    compliant inmplementation?
    
        
  3. David Harrington: Comment [2010-12-02]:
    1) There is a TBD in 6.1.8 and the IANA Consderations, in the Status Codes
    registry.
    2) "format of the format of the"
  4. Alexey Melnikov: Comment [2010-12-01]:
    I've scanned wdiff changes since RFC 3775 and I don't think my review can add
    much value to the quality of the document. So I have No Objections to its
    publication.
  5. Tim Polk: Discuss [2010-12-02]:
        This is a good document, and I don't want to delay publication unnecessarily.
    However, Nico Williams raised
    some important points in his (late) secdir review,
    and I want to be sure the authors consider these points before
    publication.
    
    The two issues I was particularly interested in are  the use of subject
    alternative names in PKIX certificates and
    the use of SHA-1.  (See "Binding of
    home addresses to mobile node credentials when using IKEv2" and "Hash/MAC
    algorithm agility" in the review, respectively)
    
    (1) I would like to confirm that subject alternative names are commonly used in
    Mobile IPv6.  If subject alternative
    names are not commonly used, as Nico
    suggests, I beleive it is important for the text to reflect actual practice.
    
    (2) I believe that Nico is correct, and there is no risk incurred by the use of
    SHA-1 in this document.  However, this
    is a source of great confusion to many
    readers.  Adding text to the security considerations noting that the use of
    SHA-1 has been reviewed and is safe would be a really good idea.  If such a
    review has not been performed, I would
    be glad to connect the authors to some
    NIST cryptographers to do that review... 
        
  6. Tim Polk: Comment [2010-12-02]:
    Please review Nico's discussion of " Enrolment/assignment of home address
    bindings to mobile node
    credentials."  If work is underway, an informative
    reference would be nice.
  7. Peter Saint-Andre: Comment [2010-12-01]:
    HMAC appears to be a normative reference.
  8. Sean Turner: Discuss [2010-12-02]:
        #1) HMAC [26] appears to be a normative reference.   
        
  9. Sean Turner: Comment [2010-12-02]:
    #1) Is there a reason not to point to the latest FIPS PUB 180-3?
    
            National Institute of Standards and Technology (NIST), FIPS
            Publication 180-3: Secure Hash Standard, October 2008. 
    
    #2) I assume we want good keys?  Add the following to the first paragraph in
    5.2.1:
    
    The keys MUST be generated by using a random number generator that is known to
    have good randomness properties [13].
    
    #3) Section 5.2.4: People keep telling me it's SHA-1 not SHA1 when not used with
    HMAC.
    
    #3) Should the recommendations in Section 5.2.2 and 5.2.4 be made upper case?
    (i.e., r/recommended/RECOMMENDED).

draft-ietf-geopriv-held-identity-extensions

  1. Stewart Bryant: Comment [2010-10-27]:
    I agree with the discusses already posted, but no additional issues.
  2. Lars Eggert: Comment [2010-10-26]:
    Section 3.6., paragraph 4:
    >    A domain name does not always correspond to a single IP address or
    >    host.  If this is the case, a domain name is not a suitable
    >    identifier.
    
      Right. Domain names are also clearly context specific (split-horizon
      DNS, etc.)
    
  3. Adrian Farrel: Comment [2010-12-02]:
    I support Dan's Discuss.
    draft-ietf-georiv-arch is (somewhat) careful in its
    definition of "device" and I do not think it means "network interface".
    Although
    it is true that network interfaces do not currently wander independent of
    devices (and if they did, they might need to be independently trackable) some
    care is needed in the wording to make the association clear.
  4. Alexey Melnikov: Comment [2010-11-15]:
    2.2.  Identifier Format and Protocol Details
    
       If the LIS requires an identifier that is not provided in the
       request, the desired identifiers MAY be identified in the HELD error
       response, using the "requiredIdentifiers" element.  This element
       contains a list of XML qualified names [W3C.REC-xml-names11-20060816]
       that identify the identifier elements required by the LIS.  Namespace
       prefix bindings for the qualified names are taken from document
       context.  Figure 2 shows an example error indicating that the
       requester needs to include a MAC address (Section 3.2) if the request
       is to succeed.
    
    Is there an IANA registry for these?
    
    5.  Security Considerations
    
       All HELD requests containing identity MUST be authenticated by the
       LIS.  How authentication is accomplished and what assurances are
       desired is a matter for policy.
    
    Is this description sufficient for providing interoperability?
    
  5. Tim Polk: Discuss [2010-10-27]:
        This discuss expands upon one of the comments in Alexey's ballot position.
    
    In section 5. Security Considerations, paragraphs 2 and 3 state:
    
       All HELD requests containing identity MUST be authenticated by the
       LIS.  How authentication is accomplished and what assurances are
       desired is a matter for policy.
    
       The base HELD protocol uses return reachability of an IP address
       implied by the requester being able to successfully complete a TCP
       handshake.  It is RECOMMENDED that any means of authentication
       provide at least this degree of assurance.  For requests that include
       Device identity, the LIS MUST support HTTP digest authentication
       [RFC2617].  Unauthenticated location requests containing Device
       identity can be challenged with an HTTP 401 (Unauthorized) response
       or rejected with an HTTP 403 (Forbidden) response.
    
    However, RFC 5985 states:
    
       A Device that conforms to this specification MAY choose not to
       support HTTP authentication [RFC2617] or cookies [RFC2965]. 
    
    Where IP reachability is not an appropriate means of authentication, the only
    authentication mechanism that MUST be required by the LIS is optional for
    the
    Device.  Should digest authentication be a MUST for the Device?
    The combination
    of digest authentication and TLS seems a straightforward solution.
    Alternatively, TLS client authentication is a more complex solution but 
    might
    be more scalable. 
        
  6. Dan Romascanu: Discuss [2010-10-26]:
         In Section 3.2:
    
       The media access control (MAC) address used by the IEEE 802 family of
       access technologies is an identifier that is assigned to a particular
       network Device.  A MAC address is a unique sequence that is either
       assigned at the time of manufacture of a Device, or assigned by a
       local administrator.  A MAC address rarely changes; therefore, a MAC
       address is an appropriate identifier for a Device.
    
    Actually MAC addresses are not assigned to devices but to network interfaces
    that connect devices to a physical segment. There may be more than one MAC
    address per device in the case of devices with multiple network interfaces, and
    even more MAC addresses per one physical interface in some cases (for example
    one MAC address per VLAN). The scheme works but only for the globally unique
    addresses which are guaranteed to be unique and any of the MAC addresses on the
    device interfaces can be used to identify the device. 
        
  7. Dan Romascanu: Comment [2010-10-26]:
    I support the issues raised by Alexey in his DISCUSS. 
  8. Sean Turner: Comment [2010-12-01]:
    I support Tim's discuss.
    
    The FQDN section specifically mentions that if the FQDN doesn't correspond to a
    singular IP address or host then it's not suitable. Should this be repeated in
    the other sections? e.g., if the URI doesn't specifically refer to a particular
    device, then a URI is not a suitable identifier.  I see the general guidance in
    Section 2- just curious why only FQDN got this special treatment.
    
    In Section 3.7, I says:
    
    Each identifier contains a string of decimal digits with a length as specified.
    
    But, the imsi and min identifier descriptions don't include length constraints.
    Seems like they all should (they're in the schema I guess just copy the values
    forward to the descriptions).

draft-igoe-secsh-x509v3

  1. Russ Housley: Discuss [2010-11-28]:
        
      Section 2.1 says:
      >
      > o  There is no requirement on the ordering or number of OCSP
      >    responses.
      >
      There is no reason for the number of OCSP responses to exceed the
      number of certificates proviced.  Why allow more?
    
      Section 2.1 also says:
      >
      > [RFC5280] describes the structure of X.509v3 certificates to be
      > used with RSA and Digital Signature Algorithm (DSA) public keys.
      >
      I think that RFC 3279 is a better reference for these algorithms.
    
      Section 2.2.1 says:
      >
      > o  The digitalSignature KeyUsage identifier MAY be used with
      >    certificates for x509v3-ssh-dss, x509v3-ssh-rsa, and x509v3-
      >    ecdsa-sha2-* public key algorithms.
      >
      I think this is incorrect.  I think it should say: If the keyUsage
      extension is present in the cerificate, then digitalSignature MUST
      be set for these identifiers.
    
      Section 2.2.1 also says:
      >
      > o  The keyAgreement KeyUsage identifier MAY be used for certificates
      >    with convey keys for use with the ecmqv-sha2 key exchange method.
      >
      I think this is incorrect.  I think it should say: If the keyUsage
      extension is present in the cerificate, then digkeyAgreement MUST
      be set for these identifiers. 
        
  2. Russ Housley: Comment [2010-11-28]:
      Section 1 says:
      >
      > Digital certificates, such as those in X.509 version 3 (X.509v3)
      > format, ...
      >
      Please add a reference.  [RFC5280] seems appropriate.
    
      Section 1 also says:
      >
      > This document is concerned with SSH implementation details;
      > specification of the underlying cryptographic algorithms and the
      > handling and structure of X.509v3 certificates is left to other
      > standards documents.
      >
      What documents does an implementer need to read?  Obviously, RFC 5280
      is needed.  Please list them as normative references.
  3. Alexey Melnikov: Comment [2010-11-24]:
    A well written document, one question:
    
    2.1.  Public Key Format
    
       For all of the public key algorithms specified in this document, the
       key format consists of a sequence of one or more X.509v3 certificates
       followed by a sequence of 0 or more Online Certificate Status
       Protocol (OCSP) responses as in Section 4.2 of [RFC2560].  Providing
       OCSP responses directly in this data structure can reduce the number
       of communication rounds required (saving the implementation from
       needing to perform OCSP checking out-of-band) and can also allow a
       client outside of a private network to receive OCSP responses from a
       server behind firewall.
    
    This text almost make it sound as if OCSP data is optional to include.
    
  4. Tim Polk: Discuss [2010-12-02]:
        This is a discuss-discuss.
    
    A third party IPR disclosure was recently filed on this document.  Given that
    Certicom is assumed to have IPR
    that could apply to any Internet Draft including
    elliptic curve technology, I do not think this changes the community
    consensus
    but I want to hear the opinions of other ADs. 
        
  5. Peter Saint-Andre: Discuss [2010-11-30]:
        Section 4 states:
    
       For the purposes of server authentication, the mapping between
       certificates and host names is left as an implementation and
       configuration issue for implementers and system administrators.
    
    Leaving this up to software implementers and service operators seems
    shortsighted. For the sake of interoperability and improved security, I think it
    would be good to specify rules for checking the identity of hostnames asserted
    by the server (if the client does not check the server's identity, how can it be
    said to have authenticated the server?). It might be appropriate to cite draft-
    saintandre-tls-server-id-check or to borrow some text from that document. 
        

draft-ietf-emu-eaptunnel-req

  1. Jari Arkko: Discuss [2010-12-02]:
        I would have voted Yes on this excellent document if it were not
    for the following statement: 
    
      The mandatory to implement cipher suites MUST NOT include "export
      strength" cipher suites
    
    First of all, I want to know what this means. What specific requirements
    are you setting, and from whose perspective?
    
    Secondly, the IETF has not been and I don't think it should be in the
    business of changing its technical requirements based on requirements
    from governments. And in particular not requirements specific to any 
    individual country. I think we need to make this new method as strong
    as it needs to be. In terms of symmetric ciphers, AES-128 or AES-256
    would be fine, for instance. If that's exceeding the particular export
    limitations mentioned above, I do not think we should compromise the
    specification. If not, why do we need to say something? Finally,
    do you expect to be able to implement this method based on OpenSSL or
    some limited version of it? I surely hope that the intention is the
    former. 
        
  2. Jari Arkko: Comment [2010-12-02]:
    I support Lars' discuss, but I also think that the document is clear
    with respect to what it is recommending, i.e., I'm not supportive of
    Alexey's discuss.
  3. Stewart Bryant: Comment [2010-12-01]:
    I support Lars' Discuss on RFC2119 language. I also found it very confusing.
  4. Lars Eggert: Discuss [2010-11-30]:
        Section 2., paragraph 0:
    > 2.  Conventions Used In This Document
    
      DISCUSS: It is *extremely* confusing to see RFC2119 terms being
      redefined in the local scope of a document, especially since the
      redefinitions seem comparable to what RFC2119 specified. Suggest to
      either include the normal RFC2119 boilerplate and reference, or else
      chose different local terms.
    
    Section 4.2.2., paragraph 1:
    >    Tunnel establishment sometimes requires the exchange of information
    >    that exceeds what can be carried in a single EAP message.  In
    >    addition information carried within the tunnel may also exceed this
    >    limit.  Therefore a tunnel method MUST support fragmentation and
    >    reassembly.
    
      DISCUSS: I'm not sure I understand this requirement. A TLS tunnel uses
      TLS on top of TCP. TCP byte streams have no fragmentation issues.
     
        
  5. Adrian Farrel: Comment [2010-12-01]:
    A number of acronyms need to be expanded on first use.
  6. Russ Housley: Discuss [2010-11-30]:
        
      Based on the discussion following the posting of the Gen-ART Review
      by Roni Even on 25-Oct-2101, at least one chaneg to the document was
      agreed.  The revised document has not been posted yet. 
        
  7. Alexey Melnikov: Discuss [2010-12-01]:
        For readers not familiar about internal discussions within EMU WG, it would be
    helpful to understand what exactly is the WG planning to design. Can you please
    describe in the Introduction the thing you are trying to build.
    Sean explained
    to me that that is supposed to be a new EAP method, that uses
    TLS and multiple
    EAP methods inside the TLS tunnel.
    
    Once I understood the scope, it became easier to review the document. Some
    additional comments:
    
    3.9.  Certificate-less Authentication and Generic EAP Method Extension
    
       In some cases the peer will not have a way to verify a server
       certificate and in some cases a server might not have a certificate
       to verify.  Therefore, it is desirable to support certificate-less
       authentication.  An application for this is credential provisioning
       where the peer and server authenticate each other with a shared
       password and credentials for subsequent authentication (e.g. a key
       pair and certificate or a shared key) can be passed inside the
       tunnel.  Another application is to extend existing EAP methods with
       new features such as channel bindings.
    
    This is the first time the term channel bindings is used. Did you mean
    EAP channel bindings or the channel bindings as used by other protocols
    such as GSS-API and SASL?
    
    I think you meant the latter here, but this is not clear.
     
        
  8. Alexey Melnikov: Comment [2010-12-01]:
    3.1.  Password Authentication
    
       Many legacy systems only support user authentication with passwords.
       Some of these systems require transport of the actual username and
       password to the authentication server.  This is true for systems
       where the authentication server does not have access to the cleartext
       password or a consistent transform of the cleartext password.
       Example of such systems are one time password (OTP) systems and other
    
    I don't think OTP systems require password in the clear, or at least not all of
    them.
    
       systems where the username and password are submitted to an external
       party for validation.
    
    4.2.1.  TLS Requirements
    
       The tunnel based method MUST support TLS version 1.2 [RFC5246] and
       may support earlier versions to enable the possibility of backwards
       compatibility.
    
    Just not SSL 2.0 :-).
    
    4.5.  Requirements Associated with Carrying Username and Passwords
    
       This section describes the requirements associated with tunneled
       password authentication.  The password authentication mentioned here
       refers to user or machine authentication using a legacy password
       database or verifier, such as LDAP, OTP, etc.  These typically
       require the password in its original text form in order to
       authenticate the peer, hence they require the peer to send the clear
       text user name and password to the EAP server.
    
    LDAP needs an Informative Reference.
    
    4.5.2.  Internationalization
    
       The password authentication exchange MUST support user names and
       passwords in international languages.  It MUST support encoding of
       user name and password strings in UTF-8 [RFC3629] format.  The method
       MUST specify how username and password normalizations and/or
       comparisons is performed in reference to SASLPrep [RFC4013] or Net-
       UTF-8 [RFC5198].
    
    Please add "or their replacement", as SASLPrepbis is going to be worked on in
    the Precis WG.
    
    4.5.2.  Internationalization
    
       These numeric codes are not subject
    
    Missing "to" after "subject".
    
       internationalization during transmission.
  9. Tim Polk: Comment [2010-12-02]:
    After reading the secdir review and various AD comments, I have come to the
    conclusion that diagrams and other
    architectural information are necessary for
    this document to be widely useful.  I enter this as a comment, since the
    primary
    audience for the document is the emu working group, and I expect that the
    participants are in rough agreement
    about the architecture.  That is, adding the
    diagrams and architectural information will have limited utility for emu
    itself
    (although we might identify some unknown disagreements in the process!)  The
    specification can serve its
    main purpose as it stands - guide and focus the
    development of a standards track EAP tunnel method.
    
    I leave to the authors, chairs, and sponsoring AD's discretion whether the
    working group has sufficient cycles or
    energy to fill this gap.
  10. Peter Saint-Andre: Comment [2010-12-01]:
    1. In Section 3.9, a reference to RFC 5056 would be helpful with regard to
    channel binding.
    
    2. In Section 3.9 and Section 4.6.3, it might be good to describe in a bit more
    how cryptographic binding is different from channel binding.
  11. Robert Sparks: Comment [2010-12-01]:
    Support Lars' DISCUSS re: 2119 language

draft-ietf-opsec-ip-security

  1. Jari Arkko: Discuss [2010-12-02]:
        Section 4.3.4 claims that based on ongoing work, the treatment
    of Class E address space (240/4) should be changed in current routers
    and hosts. I think this is inappropriate because the referred work is not 
    actually currently pursued in any way. There are also numerous
    technical problems in deploying something like that. Finally, while
    this is a great and much needed document, it should not be used as
    a vehicle to specify specific technical proposals of controversial nature. 
        
  2. Jari Arkko: Comment [2010-12-02]:
    
        
  3. Stewart Bryant: Discuss [2010-12-01]:
        
    The text in 3.5.2.2 on not using UDP c/s does not do justice to systems where
    performance requirements make this impractical, for example systems such as LISP
    where UDP is a tunnel, and IPFIX where the exporter is often a linecard
    forwarder. Equally, the text glosses over  just how poor the UDP c/s is. 
        
  4. Stewart Bryant: Comment [2010-12-01]:
    The introduction appears to incorrectly uses the term TCP/IP when the author
    means the Internet Protocol suit.
    
    "This document is the result of an assessment of the IETF specifications of the
    Internet Protocol (IP)"  - The document only discusses IPv4.
    
     I am surprised that Section 3 does not have a normative reference to RFC791
    
    In Figure 3, an attacker sends a 17914-byte datagram meant to the
    s/to/for/
    
    NDIS is used before it is defined.
    
    Section 3.11 (related to the aside on SA being an interface)  ought to have some
    text on loop-back addresses, and unnumbered interfaces.
  5. Adrian Farrel: Discuss [2010-11-15]:
        After discussion and on the request of the Responsible AD, Ron Bonica, I am
    converting my COmment to a Discuss.
    
    I am disappointed that this document doesn't highlight more fully the issues and
    concerns for security created by the Router Alert option. A reference to draft-
    ietf-intarea-router-alert-considerations might serve well. 
        
  6. Adrian Farrel: Comment [2010-11-15]:
    
        
  7. Peter Saint-Andre: Comment [2010-12-01]:
    Thank you for writing this helpful document.
    
    Appendix A borders on marketing and seems like a strange thing to include in an
    RFC. Why is this here?

draft-stone-mgcp-vbd

  1. Sean Turner: Discuss [2010-12-02]:
        #1) The security considerations recommend both IPsec and SRTP, but one is not
    specified as the mandatory-to-implement.  In order to achieve interop one needs
    to be picked or are you suggesting both be used?
    
    #2) The security considerations say use IPsec as the end-to-end protection
    scheme.  It needs to say a whole lot more.  See Section 8 of RFC 5406.
    
    #3) In the same veil is just pointing at SRTP sufficient to get two
    interoperable solutions? 
        
  2. Sean Turner: Comment [2010-12-02]:
    #1) Section 9: r/securuty/security

draft-chroboczek-babel-routing-protocol

  1. Lars Eggert: Comment [2010-11-30]:
    Section 5., paragraph 0:
    > 5.  IANA Considerations
    
      I note that the IANA Considerations do not actually *instruct* IANA to
      make any registrations?
    
  2. Adrian Farrel: Comment [2010-11-23]:
    I'd like to thank the author for being willing to engage with reviewers and
    working to accommodate their concerns even though this I-D is an independent
    submission.
  3. David Harrington: Discuss [2010-12-02]:
        I am interested in understanding the operational impact of deploying this
    experimental protocol in, say, a production environment or in the Internet.
    Will
    this experimental protocol interfere with other routing protocols, if deployed
    together, or can it co-exist easily? 
        

draft-tsou-diameter-explicit-routing

  1. Jari Arkko: Discuss [2010-12-02]:
        I do not think that we should publish a document that says it is a basis
    for a standardized extension, and it is particularly suspect in a
    situation where we have not gotten any formal expression of requirements
    from the 3GPP. They normally give us all their requirements and
    references to work that they depend on ends up in the 3GPP-IETF
    dependency list, which has not happened in this case AFAICT.
    
    Given this, the proposed IESG note is too weak, IMO.
    
    Here's a possible rewrite:
    
    The IESG has concluded that this work is related to IETF work done in the
    Diameter Maintenance and Extensions (DIME) WG, but this relationship does not
    prevent publishing, if (1) the abstract is changed to remove the discussion of
    standardized solutions and (2) the following text appears either in the document
    body or as an IESG note:
    
    Techniques similar to those discussed in this document were discussed in the
    IETF DIME Working Group. The group had no consensus that the problems addressed
    by such work are a real concern in Diameter deployments. Furthermore, there was
    no consensus that the proposed solutions would meet the architectural principles
    of the Diameter protocol. As a result the working group decided not to undertake
    the work. There has also not been any formal requests for this functionality
    from other standards bodies. This RFC represents a continuation of the abandoned
    work. Readers of this specification should be aware that the IETF has not
    reviewed this specification and cannot say anything about its suitability for a
    particular purpose or about its compatibility with the Diameter architecture and
    other extensions. 
        
  2. Jari Arkko: Comment [2010-12-02]:
    
        
  3. Lars Eggert: Comment [2010-11-30]:
    No objection with the proposed IESG Note.
  4. Adrian Farrel: Discuss [2010-12-02]:
        This is a Discuss-Discuss and does not require any action from the authors.
    
    I am not an expert on this protocol and would like to IANA situation with
    someone with deeper understanding.
    
    To me it looks like all AVPs are supposed to be tracked by IANA regardless of
    whether they are allocated for IETF standards track use, or for vendor-specific
    use.
    
    At the top of the AVP registry I see...
      Registration Procedures
         Expert review with Specification
      Note
         If more than 3 are needed, IETF consensus.
    
    The I-D only appears to need three new AVP Codes so IETF consensus is not
    required, but I would still expect IANA to be requested to track the AVP Codes
    to avoid clashes.
    
    Furthermore, the Vendor-Id AVP value of 2011 proposed for use in the
    Experimental-Result AVP indicates Huawei Technology Co. This doesn't seem
    apporpriate to the scope of the document as set out in the Abstract and
    Introduction.
    
        

draft-zorn-radius-keywrap

  1. Dan Romascanu: Discuss [2007-01-19]:
        The following input was received from AAA Doctor Bernard Aboba. I believe the
    points he is raising are correct. The solution seems to be not to approve the
    document and ask that it's re-submitted as AD-sponsored to allow for proper
    community review.
    
    ---------
    
    I do not think this document is eligible for publication as an Independent
    Submission, since it requests IANA to allocate parameters (RADIUS
    attributes)
    that require "IETF Consensus" under RFC 3575.  RFC 2434 defines IETF consensus
    as follows:
    
               IETF Consensus - New values are assigned through the IETF
               consensus process. Specifically, new assignments are made via
               RFCs approved by the IESG. Typically, the IESG will seek
               input on prospective assignments from appropriate persons
               (e.g., a relevant Working Group if one exists).
    
    Therefore I do not believe that this document can be published without at least
    going through IETF last call.
    
    In addition, the document updates a Draft Track RFC (RFC 2865). 
    
    -------------