IESG Narrative Minutes

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

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

Corrections from:

1 Administrivia

  1. Roll Call 1133 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. Multicast Ping Protocol (Proposed Standard)
    draft-ietf-mboned-ssmping-08
    Token: Ron Bonica
    Discusses/comments (from ballot 3666):
    1. Stewart Bryant: Discuss [2011-07-13]:
      The timestamp specifies the time when the Echo Request message is sent. The first 4 bytes specify the number of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 bytes specify the number of microseconds since the second specified in the first 4 bytes.
      It would seem to be in the best interests of the Internet if we were to minimize the number of timestamp epochs and formats that we used in our OAM protocols. Unless there are good reasons to choose a different format, the NTP format shown in Figure 3 of RFC5905 and used in RFC 4379 (see Errata) would seem to be most appropriate.
      There is a good case for writing a BCP on the subject of on the wire and in particular OAM timestamps so that there is a reference point for future occasions when the subject arrises.
    2. Stewart Bryant: Comment [2011-07-13]:
      (blank)
    3. Wesley Eddy: Discuss [2011-06-22]:
      in section 2, there's discussion of rate limiting and mention of a one request per second per IP address limit. This is a bit of a heuristic, and should be described as such. It is not necessarily ideal for all networks and configurations and may err on either the too conservative or too aggressive sides depending on several variables.
    4. Wesley Eddy: Comment [2011-06-22]:
      Section 1 should really be more to the point about what this document's purpose is. It specifies a way to send packets to a unicast address which elicit responses to both a unicast and a multicast addresses, yet never says that so clearly until midway through section 2.
    5. Adrian Farrel: Discuss [2011-07-14]:
      The mboned charter says: "This is not meant to be a protocol development Working Group."
      Is this not a protocol? In which other WGs has it been reviewed? (The write-up is silent)
      idnits says... "== You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/)"
      I think we need the draft to be resubmitted with the up-to-date license notice before we can accept it for publication.
      The Experimental ranges available here are far too large. There are 64 experimental message types and 16384 experimental option types. Experiments are supposed to have limited scope and duration. Such large experimental ranges will encourage code-point squatting. Please reduce the available range to one or two messages and no more than six options.
      Section 3.2: "Values 7 and 8 are reserved."
      You need to be more careful. I suspect that you mean "reserved and must not be allocated by any future document." If you just say "reserved" this may be mistaken for "available".
      But anyway, the text later in 3.2 is confusing:
      Reserved, type 7: "This option code value was used by early implementations for an option that is now deprecated. This option should no longer be used. Clients MUST NOT use this option. Servers MUST treat it as an unknown option (not process it if received, but if received in an Echo Request message, it MUST be echoed in the Echo Reply message)."
      You say "deprecated" but you asked for the code point to be "reserved".
      This says both "should (sic) no longer be used" and MUST NOT be used by a client. Then it goes on to say that that MUST NOT is not an error and MUST be processed by the server.
      I suggest: "This option code value was used by implementations of version 1 of this protocol, and is not used in this version. Servers MUST treat it as an unknown option (not process it if received, but if received in an Echo Request message, it MUST be echoed in the Echo Reply message)."
      Similarly, I suggest:
      Reserved, type 8: "This option code value was used by implementations of version 1 of this protocol, and is not used in this version. Servers MUST treat it as an unknown option (not process it if received, but if received in an Echo Request message, it MUST be echoed in the Echo Reply message)."
      Section 3.2: Client ID says... "A server should treat this as opaque data, and MUST echo this option back in the reply if present (both Server Response and Echo Reply)."
      But Version says... "Client ID and Sequence Number options SHOULD be echoed if present"
      MUST != SHOULD
      Similarly: Sequence Number... "A server replying to an Echo Request message MUST copy it into the Echo Reply (or Server Response message on error)."
      The table in Section 3.4 confirms the "MUST" echo.
    6. Adrian Farrel: Comment [2011-07-14]:
      I am slightly puzzled by the author's contact details. Are they up-to-date and will the email address reach the author in AUTH48?
      I think it would help, very early in Section 2, to say that the Server is typically the root of a multicast tree, and the Client is typically the leaf. You could go on to explain variations from this.
      Section 3: "The Init message generally contains some prefix options asking the server for a group from one of the specified prefixes.
      "For an Echo Request the client generally includes a number of options"
      These are pretty vague statements for a protocol specification!
    7. Stephen Farrell: Comment [2011-07-13]:
      This sets up a sort-of covert channel between the client sending the Init and the MC group members that could be used e.g. in botnet control. (I've no idea if that's actually happened or not.)
      I don't know what might be done about that right now, but having the server just send a hash of the client supplied options should work, but would be a fairly large change to the protocol at this stage.
      I guess it might be worth noting this potential abuse and possible solution in case the protocol is revised later.
    8. Russ Housley: Discuss [2011-07-12]:
      The Gen-ART Review by Suresh Krishnan on 12-Jul 2011 raised two concerns that deserve a response.
      * I am not sure why this spec needs to contain the options 7 and 8 as they are not relevant to this version of the protocol. Wouldn't the default behavior with unknown options take care of this automatically?
      * It would be good if the draft specifies a default TTL (e.g. 64) in case the server did not include a TTL option. In this case, the server implementations need not bother to add the option if they are happy with the default (which I suspect they would be).
    9. Dan Romascanu: Comment [2011-07-14]:
      I support Wesley's DISCUSS. The one second interval between answers of a server to a given client may be too little, just fine or too much depending on many factors, size and topology of the network included. Either some justification or some other indication of how this value is to be used (or deviated from) is required.
    10. Peter Saint-Andre: Comment [2011-07-11]:
      I concur with Sean Turner's DISCUSS. Regarding denial of service attacks, reference to RFC 4732 would be helpful (both to formulate appropriate text and for completeness of the references).
    11. Sean Turner: Discuss [2011-07-12]:
      This is an update discuss based on Vincent's SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02772.html).
      #1) Random #s: The minute you mention random #s a reference to RFC 4086 pop in to my mind. Please tweak the following..
      A question: Section 2 includes the following: "At runtime, a client generates a client ID that is unique for the ping test."
      But then there's no requirement in 3.2 about the ID being unique. Shouldn't there be?
      #2) Shouldn't there be something about DoS attacks in the security considerations?
      #3) Section 5, "Server Behaviour", says: "When the server receives an Echo Request message, it may first check that the group address and Session ID (if provided) are valid."
      This is a "MUST"!!! If the Session ID is used, the server has no choice but checking it during the first processing stages.
      #4) Section 5 says: "Note that the server may receive Echo Request messages with no prior Init message. This may happen when the server restarts or if a client sends an Echo Request with no prior Init message. The server may go ahead and respond if it is okay with the group used. If the group is not okay, the server sends back a Server Response."
      This "may go ahead and respond" is in total contradiction with the security recommendations. Using a Session ID is a "SHOULD", and it is allowed to ignore this recommendation only in rare circumstances. A few ping requests may fail if the server is restarted, sure, but this will only be a transitory problem, so it's not a big deal.
      I'm also wondering if the "sends back a Server Response" strategy is appropriate. With this "Response", an attacker that spoofs the IP address of a target has a way to oblige a server to send back a UDP packet to the target. It's questionable.
      #5) Section 9 says: "The server SHOULD then only respond to Echo Request messages that have a valid Session ID associated with the source IP address of the Echo Request."
      How should the server behave if the Session ID is not valid? This is not clarified whereas this is a critical aspect.
    12. Sean Turner: Comment [2011-07-12]:
      This is an update comment based on Vincent's SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02772.html).
      (13 items)

    Telechat:

  2. Diameter Network Address and Port Translation Control Application (Proposed Standard)
    draft-ietf-dime-nat-control-09
    Token: Dan Romascanu
    Note: Jouni Korhonen (jouni.korhonen@nsn.com, jouni.nospam@gmail.com) is the Document Shepherd.
    Discusses/comments (from ballot 3690):
    1. Jari Arkko: Comment [2011-07-14]:
      I do not understand IPv6 on figures 3 and 4. Are they trying to show dual-stack operation? If so, why is there only "public IPv4" on the right side? Or are they trying to show NAT64-type of deployment? If so, why is there IPv4 on the left side? Please clarify.
    2. Ralph Droms: Discuss [2011-07-13]:
      This DISCUSS asks about process and can be quickly resolved.
      Has this document been reviewed by the Transport Area; e.g., behave Working Group or the Transport Area Directorate?
    3. Wesley Eddy: Comment [2011-07-11]:
      my DISCUSS comments have been very well-addressed in the update, and I've cleared them
    4. Stephen Farrell: Discuss [2011-07-14]:
      (1) Why is the on-demand query feature required? (Section 1, bullet 5.) This seems to be something that might have significant privacy implications if abused. There is some text in the security considerations about this, but I don't see text saying why this is needed at all.
      (2) Session IDs need to be hard to guess or else any Diameter node (or nearby host pretending to be such) could use the query NCR to suck all the state from a NAT. Does 3588 mandate that? If not, maybe this spec should (as an additional requirement). If 3588 does mandate that then re-iterating it here would maybe be good.
      (3) 5.1 says that identity MAY be verified and that authorization is also a MAY. Why are both not SHOULD or MUST? Even within a "trusted" network, hosts may be compromised, or users may misbehave.
      (4) Security considerations says that it "is assumed" that the DNCA peers are in the same, "trusted" domain. To me, that implies that this specification MUST NOT be used outside that scenario, if you have not defined how to do authentication and authorization in an interoperable manner.
    5. Stephen Farrell: Comment [2011-07-14]:
      (1) Possibly dumb question: Why does this assume that all external addresses are IPv4?
      (2) I agree with Sean's discuss.
    6. Robert Sparks: Discuss [2011-07-12]:
      The deployment framework section strongly implies that there will be a single entity acting as the NAT controller. The introduction implies other deployment models, calling out that applications hosted by the service provider may be involved as a NAT controller (the example used is SIP-proxy server deployments).
      Is it the case that you expect multiple, perhaps uncoordinated controllers? If so, some discussion in the document seems warranted. Either way, the document should be explicit.
    7. Robert Sparks: Comment [2011-07-12]:
      I'm surprised there is no discussion of how this relates to midcom and other nat control proposals.
    8. Sean Turner: Discuss [2011-07-13]:
      This might be somewhat related to Robert's discuss:
      According to the security considerations authentication, authorization, integrity, and confidentiality is demanded. Does this require either IPsec between the NAT-controller and NAT-device (where both are end-points) or directly connected (i.e., no relays/agents) with TLS between the NAT-controller and NAT-device? Figures 3 and 4 show this but I don't see something that explicitly says this.

    Telechat:

  3. Diameter Attribute-Value Pairs for Cryptographic Key Transport (Proposed Standard)
    draft-ietf-dime-local-keytran-11
    Token: Dan Romascanu
    Note: Lionel Morand (lionel.morand@orange-ftgroup.com) is the document shepherd.
    Discusses/comments (from ballot 3773):
    1. Stephen Farrell: Discuss [2011-07-13]:
      (1) I'm not sure that the Key-Type AVP is well enough specified. At least for the RSA-KEM variant, I would have expected to see a set of CMS options (e.g. are certs to be included or not) would be needed in order to get interop. (I was offine doing the review and am not familiar enough with the other options to know if the same issue arises.) Have there been any implementations of these, and if so, what did they put in the key values? I also don't get why the RFCs defining the details for Key-Type AVPs are informative and not normative. If this document defines a protocol that will result in interop, then they need to be normative I'd have thought.
      (2) Which of the Key-Type(s) are implementers of this expected to support?
      (3) The security considerations need to say something about transporting keys that are not otherwise protected. I think you need to say that Keying-Material AVPs that are not suitable to be sent in clear MUST only be sent between two Diameter nodes using TLS or IPsec unless all the Diameter nodes on a path are known to be equally trusted. I'm sure wordsmithing is needed there but don't have time right now to offer a suggestion. (Sorry) Neither of the RFCs referenced in the security considerations section say that. I've no idea how far that might be from the WG's opinion.
    2. Russ Housley: Comment [2011-07-11]:
      The Gen-ART Review by Joel Halpern on 2-Jun-2011 asks a reasonable question. I would like to see it answered.
      The document carefully and reasonably does not define the contents of the keying material AVP. This reviewer presumes that those closer to the activity will know where the contents have been or will be defined. Are they already defined, or will they be defined in future documents? If they are already defined, would it make sense to state that, and identify the location? (My confusion is that it would seem difficult for existing RFCs to define the format of a TLV that did not exist. But that may be a failure of my understanding.)
    3. Sean Turner: Discuss [2011-07-13]:
      I gotta ask about the choice of RSA-KEM. I couldn't find email on the list about it. Why not straight up RSA - for which almost everybody on the planet who has a certificate has one where few (any?) have RSA-KEM certificates? If it's just list algs why not also add RSAES-OAEP Key Transport Algorithm [RFC4055]? Maybe ECDH too? I'm just curious if somebody asked for RSA-KEM or you just picked a second one for agility purposes.
    4. Sean Turner: Comment [2011-07-13]:
      I fully support Stephen's discuss positions.

    Telechat:

  4. A Profile for Resource Certificate Repository Structure (BCP)
    draft-ietf-sidr-repos-struct-08
    Token: Stewart Bryant
    Note: Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd.
    Discusses/comments (from ballot 3775):
    1. Adrian Farrel: Discuss [2011-07-13]:
      idnits shows: ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch')
      I didn't see this downref called out in the last call
    2. Adrian Farrel: Comment [2011-07-13]:
      I agree with the Discuss points about referencing RFC 2119 and about being Standards Track.
      In Section 3... "* It is recommended in Section 2.1 that repository operators SHOULD implement some form of directory management regime"
      I don't think Section 2.1 makes this as a "recommendation". I think it is a definition. Perhaps change to... "* Section 2.1 states that repository operators SHOULD implement some form of directory management regime"
      I found a number of cases of "SHOULD" being used without any indication of why or when divergence is allowed/advisable. I don't have any reason to debate SHOULD/MUST in these cases, but it is normal to accompany a SHOULD with some discussion (often a MAY) to explain why MUST is not used.
    3. Stephen Farrell: Comment [2011-07-13]:
      (1) Including examples for all the recommended names would be a real help for implementers and shouldn't be too hard if someone has code already. I'd really like to see that added.
      (2) Did the WG consider specifying that repositories MAY or SHOULD contain a README-like file informally describing the content of the repository. It might be good to have a well-defined place for that kind of information.
    4. Pete Resnick: Discuss [2011-07-10]:
      Why is this not simply standards track? The MUSTs and SHOULDs that I see are perfectly sensible behaviors that can be observed "from the 'net", and all of the protocol in here looks like it can be updated over time to reflect what might be learned from deployment experience. I see no reason not to make this standards track.
    5. Peter Saint-Andre: Discuss [2011-07-12]:
      This document is missing a normative reference to RFC 2119.
      The Security Considerations section states: "Repositories are not assumed to be integrity-protected databases, and repository retrieval operations MAY be vulnerable to various forms of "man-in-the-middle" attacks."
      I don't think you mean that it is OPTIONAL for repositories to expose themselves to MITM attacks, so please change "MAY" to "might".
    6. Peter Saint-Andre: Comment [2011-07-12]:
      I agree with Pete Resnick that this document deserves to be Standards Track.
    7. Sean Turner: Comment [2011-07-13]:
      Please make the following changes to Section 3:
      OLD: The publication repository MUST be available using RSYNC [RFC5781].
      NEW: The publication repository MUST be available using RSYNC [RFC5781][RSYNC].
      And the following normative reference: [RSYNC] Tridgell, A., "rsync", March 2008, <http://rsync.samba.org/>
      This will line it up with the arch document.

    Telechat:

  5. Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (Proposed Standard)
    draft-ietf-mpls-ldp-p2mp-14
    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-p2mp-05
    IPR: Cisco's Statement of IPR relating to draft-ietf-mpls-ldp-p2mp-01
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mpls-ldp-upstream-09 and draft-ietf-mpls-ldp-p2mp-11
    Discusses/comments (from ballot 3819):
    1. Stewart Bryant: Comment [2011-07-12]:
      "The loops are transient and will disappear as soon as the unicast routing protocol converges. "
      Strictly they disappear when both the unicast routing converges AND THEN mLDP converges to use the new unicast topology. The point here is that the microloop time will be longer than the unicast routing protocols convergence time. Also one may note that the loop time is usually dominated by LFIB update time.
    2. Adrian Farrel: Comment [2011-07-11]:
      Please address the following "minor issues" from the GenArt review by Joel Halpern:
      The definition (section 1.2) of MP2MP LSPs should indicate that even though all nodes are allowed to send on the LSP, there is still a distinguished root node.
      The LDP MP Opaque Value Element extended type (section 2.3, second definition) seems to be gratuitous complexity, adding extra matching cases in the LDP processing path for no stated value. Is there really believed to be a need for more than 254 types of Opaque values? If so, explain it in the document.
      Section 3.3.1.3 begins by describing two methods for installing the upstream path of a MP2MPLSP. After carefully describing both, it says to only and always use the second method. Would it not be better to describe the constraint (that the upstream path must be in place all the way to the root before it claims to be established), and then describe the one method that meets taht. Just don't describe a method that is not to be used.
    3. Stephen Farrell: Discuss [2011-07-14]:
      Maybe not really for this document, but this references 5036 for security considerations, and 5036 says use TCP MD5 but that when something better comes along that ought be used. Since we now have TCP-AO, (rfc 5926) is there a plan to move to that?
    4. Stephen Farrell: Comment [2011-07-14]:
      Are gopher: URIs really appropriate to be used now? (Definition of CRC32)
    5. Russ Housley: Comment [2011-07-12]:
      The Gen-ART Review by Joel Halpern on 23-June-2011 resulted in a small amount of discussion. The need for that discussion indicates to me that the document needs a better introduction. In particular, the reader needs to be told that the same TLVs are being used to reporting on the status of LSPs as well as a downstream device sending a request to an upstream device.
      In addition, Section 3.3.1.3 describes two methods for installing the upstream path of a MP2MPLSP. After carefully describing both, it says to always use the second method. Would it not be better to describe the constraint (that the upstream path must be in place all the way to the root before it claims to be established), and then describe the one method that meets the requirement.
    6. Dan Romascanu: Discuss [2011-07-14]:
      This is a mature and well written document and I have no concerns about its quality and no special operational issues. However, as this is quite a significant extension of the LDP I would expect such a document to include a minimal set of operational considerations. Is a revision / extension of RFC 3815 considered for P2MP LDP? If not is there any other standard management interface considered? If all is proprietary at protocol level what initialization, configuration objects and operations, performance monitoring and/or notifications should be considered at minimum by a network operator in order to activate and manage properly a network that deploys this protocol? If this information belongs to some other document please point to it.
    7. Sean Turner: Comment [2011-07-13]:
      (blank)

    Telechat:

  6. Configuration Data Model for IPFIX and PSAMP (Proposed Standard)
    draft-ietf-ipfix-configuration-model-10
    Token: Dan Romascanu
    Note: Juergen Quittek (quittek@neclab.eu) is the document shepherd.
    Discusses/comments (from ballot 3830):
    1. Russ Housley: Comment [2011-07-11]:
      The Gen-ART Review by Vijay Gurbani on 8-June-2011 raises one editorial comment:
      There are references in the Abstract, which could probably be removed and replaced in the body of the draft.
    2. Peter Saint-Andre: Comment [2011-07-12]:
      [W3C.REC-xml-20040204] is the 3rd edition of the XML spec. The most recent edition is the 5th: [W3C.REC-xml-20081126]

    Telechat:

  7. Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels (BCP)
    draft-ietf-6man-flow-ecmp-04
    Token: Jari Arkko
    Note: Brian Haberman (brian@innovationslab.net) is the document shepherd for this document.
    Discusses/comments (from ballot 3844):
    1. Stewart Bryant: Discuss [2011-07-13]:
      Since the document is giving advice on ECMP, it should alert the reader to the polarization problem.
      The document should also alert the reader to the OAM issues that arise with ECMP.
    2. Stewart Bryant: Comment [2011-07-13]:
      A reference to draft-ietf-mpls-entropy-label-00 would seem appropriate since they seek to achieve the same though at different layers.
    3. Adrian Farrel: Comment [2011-07-13]:
      There is no mention of the fact that individual nodes in a network are free to implement different algorithms without impacting the interoperability or function of the network.
    4. Pete Resnick: Discuss [2011-07-11]:
      Section 3 of this document (the main section) seems like protocol to me. (For example, "Inner packets MUST be encapsulated in an outer IPv6 packet whose source and destination addresses are those of the tunnel end points (TEPs)".) Therefore, I see no reason for this not to be on the Standards Track. It seems like it has interoperability impacts and gives normative implementation guidance.
    5. Peter Saint-Andre: Comment [2011-07-11]:
      I agree with the DISCUSS from Pete Resnick that this seems like a Standards Track document, not a BCP.
    6. Robert Sparks: Comment [2011-07-11]:
      I found this document clear and hope it has the impact the group intends. I support Pete's discuss though - why did the group choose BCP as the intended status for this document?
    7. Sean Turner: Comment [2011-07-14]:
      Maybe add (e.g., by using IPsec between the two tunnel end-points) to the end of the 2nd sentence in the security considerations. Just to provide an example of how it might be done.

    Telechat:

  8. IPv6 Flow Label Specification (Proposed Standard)
    draft-ietf-6man-flow-3697bis-06
    Token: Jari Arkko
    Note: Brian Haberman (brian@innovationslab.net) is the document shepherd for this document.
    Discusses/comments (from ballot 3846):
    1. Stewart Bryant: Discuss [2011-07-13]:
      Since the document is giving advice on ECMP, it should alert the reader to the polarization problem.
      The document should also alert the reader to the OAM issues that arise with ECMP.
    2. Stewart Bryant: Comment [2011-07-13]:
      A reference to draft-ietf-mpls-entropy-label-00 would seem appropriate since they seek to achieve the same though at different layers.
    3. Wesley Eddy: Discuss [2011-07-11]:
      In Section 2, paragraph 4, this MUST NOT is clearly a SHOULD NOT as this document itself permits a case where it's allowed to be broken. MUST NOT is absolute per 2119; no exceptions are allowed.
    4. Wesley Eddy: Comment [2011-07-11]:
      The first paragraph of the introduction mentions that a flow could consist of all packets in a specific transport connection. Many transport connections have bidirectional packet flows. The authors might consider clarifying whether the same flow label MAY, SHOULD, or SHOULD NOT be used bidirectionally or whether a flow is really just unidirectional.
    5. Adrian Farrel: Comment [2011-07-14]:
      There is no mention of the fact that individual nodes in a network are free to implement different algorithms without impacting the interoperability or function of the network.
    6. David Harrington: Discuss [2011-07-11]:
      This specification uses the full size of the flow label. Since it has no discriminator to indicate that it is being used for load balancing, no other use can be made of this field. I would think it might be better to reduce the hash size (maybe to 16 bits) to allow a usage-discriminator so other standardized usages of the flow label could be accomodated.
    7. Russ Housley: Comment [2011-07-12]:
      The Gen-ART Review by Roni Even on 6-Jul-2011 points out one typo in section 3, fifth paragraph: "An alternative approach is to to use"
    8. Peter Saint-Andre: Comment [2011-07-12]:
      Does this document intend to classify RFC 3697 as Historic?
      The keyword boilerplate does not include "NOT RECOMMENDED", but the text does (in Section 3).
      An informative or perhaps even normative reference to BCP 106 (RFC 4086) might be in order regarding the assignment of flow label values.
      An informative reference to RFC 4732 might be in order regarding denial of service.
    9. Robert Sparks: Discuss [2011-07-11]:
      It's not clear whether the exceptional token rewriting described in section 6.1 should take the existing flow token into account, or treat the incoming packets as if they had a flow token of zero and behave exactly like a Section 3 forwarding node. If the intent is that this security device is only obfuscating the values some upstream element may have chosen for flow tokens while keeping the flows distinguishable, some additional text should say that and point out what's lost by doing so. If nothing is lost, then why are you keeping the requirement that otherwise forwarding nodes MUST NOT change the flow label value?
    10. Robert Sparks: Comment [2011-07-11]:
      I agree with Wes that the currently stated "MUST NOT change the flow label value"..."A possible exception" formulation in section 2 could be improved editorially. If the questions in my DISCUSS don't lead to a different change, one way to adjust this would be to say something like "MUST either leave the flow label unchanged or change it only as described in section ..."
    11. Sean Turner: Discuss [2011-07-13]:
      I don't think the point made by Richard Barnes' made it in the last version:
      Richard: Given the risks that this document discusses, it might be worth considering a recommendation that networks SHOULD NOT make resource allocation decisions based on flow labels without some external means of assurance. Or some similar warning against making resource decisions on a completely unsecured field.
      Brian: Yes, that makes sense when *not* in the stateless load distribution scenario.
    12. Sean Turner: Comment [2011-07-13]:
      Ditto for this:
      Richard: Also, purely from a terminology perspective, I found the phrase "unintended service" confusing and less accurate than the "better service" phrase used in RFC 3697. It might be better to spell this out: " ... an adversary may be able to obtain a class of service that the network did not intend to provide ... "
      Brian: Agreed.

    Telechat:

  9. IP Router Alert Considerations and Usage (BCP)
    draft-ietf-intarea-router-alert-considerations-06
    Token: Ralph Droms
    Note: Julien Laganier (julien.ietf@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3849):
    1. Ron Bonica: Discuss [2011-07-13]:
      I intend to change this from a DISCUSS to YES as soon as a few minor changes are made.
      s/network operators need to actively protect themselves against externally generated IP Router Alert packets/network operators SHOULD actively protect themselves against externally generated IP Router Alert packets
      s/ Thus, it is RECOMMENDED that applications and protocols not be deployed with a dependency on processing of the Router Alert option (as currently specified) across independent administrative domains in the Internet./ Thus, applications and protocols MUST NOT be deployed with a dependency on processing of the Router Alert option (as currently specified) across independent administrative domains in the Internet.
      - In Section 4.2.2, just above Figure 4, you talk about a private enterprise network. Do you mean a VPN? Is there any chance of another enterprise (C) sending a RA Optioned Packet to Enterprise A? If so, should B deliver it?
      - In the second part of section 4.2.2, you talk about "special agreements between administrative domains". More text is required. here. Let's say that A enters into an agreement with B. That's fine. Now let's say that B enters into an agreement with C. That's fine, so long as B tells A about the agreement with C. Now let's say that C enters into an agreement with D. Will D inform A? If not, the special agreement has been breached. I don't see this flying in the real world.
    2. Ron Bonica: Comment [2011-07-13]:
      1) You might want to find another word for "punt". This word may not be understood by those not familiar with American Football or Rugby.
    3. Wesley Eddy: Comment [2011-07-07]:
      definition of fast-path should mention that this is the nominal processing path within a router for datagrams, and then the slow-path definition should say that this is a sub-nominal processing path for packets that require special processing or differ from assumptions made in fast path heuristics.
    4. Adrian Farrel: Comment [2011-07-11]:
      I wouldn't mind my name being spelled right :-)
    5. Russ Housley: Comment [2011-07-13]:
      The Gen-ART Review by Miguel Garcia on 13-Jul-2011 includes two editorial comments:
      - Make sure that "Router Alert Option" is written with capital "O" across the document. There are a few instances with a lower "o".
      - Expand acronyms at first occurrence. This includes: ASIC
    6. Pete Resnick: Discuss [2011-07-13]:
      The way 2119 terminology is used in this document is problematic. Three general issues:
      1. The document repeatedly says "it is RECOMMENDED", in the passive voice, instead of saying who should be doing what. For example, in 4.1:
      "Thus, it is RECOMMENDED that applications and protocols not be deployed with a dependency on processing of the Router Alert option (as currently specified) across independent administrative domains in the Internet."
      (This one has the additional problem that the recommendation is *not* to do something, making it more confusing.) It seems to me much better to rewrite this as:
      Thus, applications and protocols SHOULD NOT be deployed with a dependency on processing of the Router Alert option (as currently specified) across independent administrative domains in the Internet.
      If for some reason you want to use the term "RECOMMENDED" and stick to the passive voice (which I would wonder about because it is identical to using the term "SHOULD"), you could try:
      Thus, deployment of applications and protocols with a dependency on processing of the Router Alert option across independent administrative domains in the Internet is NOT RECOMMENDED."
      The same sort of thing appears twice in section 4.3 and twice in section 5. The current phrasing I fear will confuse implementers and obscures what the document is actually requiring.
      2. The use of the phrase "MAY be safely deployed" seems like an inappropriate use of the term "MAY". That doesn't seem to be specifying a protocol option. I think what you mean is "can be safely deployed". This occurs in 4.2.1 three times and 4.2.2 three times.
      3. In section 4.3: "As a last resort, if the SP does not have any means to safely transport end to end IP Router Alert option packets over his network, the SP MAY drop those packets."
      That "MAY" seems odd as the other choices are given as examples (not protocol options) in the preceeding three paragraphs. Also, because this is a "last resort" with "undesirable consequences", it seems that it is not a real option as much as something that the SP SHOULD NOT do except as a "last resort". Again, using the word "can" would work here, or it ought to be rewritten with the "SHOULD NOT".
      A similar thing applies to the MAYs in the first and last paragraphs of section 5. They appear to be examples, not protocol options.
    7. Pete Resnick: Comment [2011-07-13]:
      I think this document would do fine as a standards track document instead of a BCP.
    8. Peter Saint-Andre: Comment [2011-07-12]:
      In Section 3, it would be good to expand "DOS" on first use and add an informative reference to RFC 4732.
    9. Sean Turner: Discuss [2011-07-14]:
      Doesn't this document update RFC 2113 and 2711? If this document is all about security considerations of something defined in those two documents doesn't it update that document?
      I think the security considerations ought to be tweaked a bit to note that 2311 and 2711 originally defined the RAO and included some security considerations:
      This document expands the security considerations of [RFC2113] and [RFC2711], which defined the RAO, to discuss security risks associated with current usage of the IP Router Alert Option and associated practices. See [RFC4081] for additional security considerations.

    Telechat:

  10. MPLS-TP Linear Protection (Proposed Standard)
    draft-ietf-mpls-tp-linear-protection-07
    Token: Adrian Farrel
    Note: Ross Callon (rcallon@juniper.net) is the Document Shepherd
    Discusses/comments (from ballot 3861):
    1. Adrian Farrel: Discuss [2011-07-11]:
      Significant Routing Directorate review comments from Lou Berger need to be resolved before this document can be approved
    2. Dan Romascanu: Discuss [2011-07-13]:
      The DISCUSS and COMMENT is partially based on the OPS-DIR review performed by Bert Wijnen:
      1. in section 3.1: "o OAM indication - OAM fault management or performance measurement tools may detect a failure or degrade condition on either the working or protection transport path and this SHOULD input an indication to the Local Request Logic."
      Why is this only a SHOULD and not a MUST? If there are exception cases I suggest to detail them.
      2. Same question about the next bullet: "o WTR expires - The Wait-to-Restore timer is used in conjunction with recovery from failure conditions on the working path in revertive mode. The timer SHALL signal the PSC control process when it expires and the end point SHOULD revert to the normal transmission of the user data traffic."
      3. in section 4.1: "The frequency of the three rapid messages and the separate frequency of the continual transmission SHOULD be configurable by the operator. For protection switching within 50ms, it is RECOMMENDED that the default interval of the first three PSC messages SHOULD be no larger than 3.3ms. The subsequent messages SHOULD be continuously transmitted with an interval of 5 seconds."
      It might be good to explain the rationale for the RECOMMENDED intervals and maybe some explanation as to what considerations need to be taken into account when configuring these values. Has the WG considered to standardize the configurability of these frequencies? Or is it left (intentionally?) to each implementation how this is done? Can an operator (or an NMS) easily see what the values are at the various LERs?
      4. In section 4.3.3.1 and 4.3.3,2 the description of the transitions of the Normal State and Unavailable State end by 'All other local inputs SHALL be ignored.' and 'All other remote messages SHALL be ignored'. In 4.3.3.3 'Protecting administrative state' we have 'All other local inputs SHALL be ignored.' but 'All other remote messages SHOULD be ignored.' In 4.3.3.4. Protecting failure state, 4.3.3.5. Wait-to-restore state, and 4.3.3.6. Do-not-revert state the lists of transitions end with 'All other local inputs SHOULD be ignored.' and 'All other remote messages SHOULD be ignored.' Why SHOULD and not SHALL, what are the exception cases and the recommended behavior?
    3. Sean Turner: Discuss [2011-07-14]:
      Some more from the obviously uninformed reader...
      #1) Section 4.2.2, I thought this section would also say something along the lines of "other values are ignored by this version of the protocol".
      #2) Section 4.2.5 & 4.2.6: Shouldn't there be a registry for FPath and Path values?
      #3) In Section 4.2.7, should it also say that the reserved fields "MUST be ignored on receipt"?
      #4) RFC 5586 says that the ACH is in network byte order, but doesn't say anything about the encoding for ACH TLVs. Maybe this draft should explicitly state that the TLV is encoded in network byte order (or is this stated somewhere else in the MPLS suite of RFC+drafts)?
    4. Sean Turner: Comment [2011-07-14]:
      #1) Section 1.1: r/compared to other survivability mechanisms/, compared to other survivability mechanisms (e.g., ... ).
      Isn't it kind of an empty claim otherwise? The survivability draft only claims: "In a mesh network, linear protection provides a very suitable protection mechanism because it can operate between any pair of points within the network."
      #2) Expand P2P on first use.
      #3) In Section 4.2.2, I think it would aid the reader greatly to add a pointer to registry in Section 5.2? When I read 4.2.2, the first thought that popped in to my mind was: well what about all the other values are they reserved? It's probably also worth point out that values are assigned by IANA.

    Telechat:

  11. MPLS-TP Identifiers (Proposed Standard)
    draft-ietf-mpls-tp-identifiers-06
    Token: Adrian Farrel
    Note: Ross Callon (rcallon@juniper.net) is the document shepherd.
    Discusses/comments (from ballot 3877):
    1. Jari Arkko: Discuss [2011-07-14]:
      Thanks for writing this draft. I would like to recommend its publication as an RFC, but before that I had two question marks that I'd like to understand better. It may be that I'm just missing some background information, I'm not necessarily saying that there is a problem in the document.
      I would like to talk about the choice of "::" as a separator. The document does not make it clear if this only a syntactic construct in this document or also something that might appear in configuration interfaces, debug outputs, or even on the wire in textual messages. If so, are there any cases where a colon or double colon of an IPv6 address might lead to am ambigious representation?
      Secondly, Section 5.3 maps tunnel endpoint addresses to node identifiers. I'd like to discuss when such mappings are possible, as it certainly sees that in some contexts (e.g., signaling) you actually need an address, not an identifier, particularly when for IPv6 the node identifiers are not addresses.
    2. Stewart Bryant: Discuss [2011-07-12]:
      The purpose of this discuss is to be able to review the resolution of the outstanding last call comments.
    3. Adrian Farrel: Discuss [2011-07-11]:
      A number of IETF Last Call comments need to be addressed in a new revision...
      AD review: Add the following section:
      7.2.1. MPLS-TP Section MEP_IDs
      ...
      Section 1.3
      OLD: The notation does define a preferred ordering of the fields.
      NEW: The notation defines a preferred ordering of the fields.
      Section 1.3
      OLD: Z9 is used to indicated the
      NEW: Z9 is used to indicate the
      Greg Mirsky
      I have a question to new Section MEP-ID. In MPLS-TP a Section can be either physical link or logical, section layer LSP, link. I think that listed Section MEP_ID addresses the former case. Would Section MEP-ID in the latter case be the LSP MEP-ID? I think that both cases must be identified and their Section MEP-IDs listed.
      Alessandro D'Alessandro
      Sect 7: "A maintenance point is either a Maintenance Entity Group End-point (MEP) or a Maintenance Entity Group Intermediate Point (MIP). Maintenance points are uniquely associated with a MEG."
      This is true for MEP. MIP, as currently defined, are not uniquely associated with a MEG.
      Sec 7.4: "At a cross-connect point, in order to automatically generate MIP_IDs for MPLS-TP, we simply use the IF_IDs of the two interfaces which are cross-connected"
      The above given definition refers to "intermediate node". It should be extended to cover also the case of "end nodes" because MIPs could be located in such nodes when per-interface MEPs model is applied (e.g. draft-ietf-mpls-tp-oam-framework and Yoshinori's contributions) a reference to sect 4, where IF_ID are defined, should be added
      ITU-T Question 12/15: https://datatracker.ietf.org/documents/LIAISON/file1237.pdf
    4. Russ Housley: Comment [2011-07-12]:
      Please consider adding CC::ICC.
    5. Sean Turner: Discuss [2011-07-14]:
      #1) Is there a reason there's not a normative reference for OAM in the intro: "OAM, as defined in [RFC6291], functions"? Should the phrase "MPLS-TP management and OAM functions" be changed to match the recommendations in 6291 by using the phrase "MPLS-TP OAM and Management (O&M) function"
      #2) I'm not so sure I buy the "this is a framework so we're not going to say anything" argument in the security considerations. The abstract and intro say that this document defines identifiers and it's telling operators how to make them (see 1st comment). If you're going to do that then I think you need to say something about how the identifier's uniqueness is guaranteed and maybe a couple of generic things about might happen if they're not unique. I don't think you need to say a lot, but something along the lines of:
      "Uniqueness of the identifiers from this document is guaranteed by the assigner (e.g., a Global_ID is unique based on the assignment of ASNs from IANA and both a Node_ID and a IF_Num are unique based on the assignment by an operator). Failure by an assigner to use unique values for the identifier will [insert words - an example: result in the end of the world as we know it because an operator will have unleashed the zombie apocalypse]."
      #3) If this is really a framework, should it be a standards track doc? Maybe it should be a BCP because you're telling operators how to identify their stuff?
    6. Sean Turner: Comment [2011-07-14]:
      Section 3: must->MUST
      A Global_ID must be derived from a 4-octet AS number assigned to the operator.

    Telechat:

  12. Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile (Proposed Standard)
    draft-ietf-mpls-tp-cc-cv-rdi-05
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.

    Discusses/comments (from ballot 3878):
    1. Stewart Bryant: Comment [2011-07-11]:
      Please ask the RFC editor to align the state diagrams on to single pages in final layout.
    2. Dan Romascanu: Comment [2011-07-14]:
      Joel Jaeggli made a number of editorial suggestions in his OPS-DIR review. I suggest that these are taken into consideration:
      2.1: I would add continuity check to the glossary since cv is in there (both are also defined elsewhere)
      3.5 says: "The base spec is unclear on aspects of how a MEP with a BFD transmit rate set to zero behaves. One interpretation is that no periodic messages on the reverse component of the bi-directional LSP originate with that MEP, it will only originate messages on a state change."
      I would prefer think that by suggesting this the doucment would simply state thst this is the interpretation that SHOULD be used. it should probably also site teh mpls tp base spec.
      3.7.7. Discriminator values..
      Discriminator show always be capatalized given that it's the name of the field.
      likewise..
      My Discriminator should also be capitalized, I would also be consistent about the use of quotes either use them or not. probably I would just be consistent with rfc 5884
    3. Sean Turner: Discuss [2011-07-14]:
      #1) Is there a reason there's not a normative reference to "OAM, as defined in [RFC6291]."?
      #2) (This is related to the my discuss #2 on draft-ietf-mpls-tp-identifiers) I was going to place this against the mpls-tp-identifiers draft, but it says that the protocols that make use of the identifiers have to explain the security considerations of the identifiers...so ... Are there security consequences if the identifiers are not unique? If additional text gets added to tp-identifiers, are there any additional concerns?
    4. Sean Turner: Comment [2011-07-14]:
      (11 items)

    Telechat:

2.1.2 Returning Items

  1. Terminology Used in Internationalization in the IETF (BCP)
    draft-ietf-appsawg-rfc3536bis-06
    Token: Pete Resnick
    Discusses/comments (from ballot 3825):
    1. Ralph Droms: Comment [2011-07-09]:
      I've cleared my DISCUSS.
    2. Adrian Farrel: Comment [2011-06-30]:
      In Section 7.1 the definition ends with "<Stringprep>" but there is no such reference.
      While I found the indications of source references useful, I did not find that angle brackets were the best indicators as they are also used for two other (distinct) purposes in the document.
      Replacing <NONE> with <THIS> might send a more positive message.
    3. Stephen Farrell: Comment [2011-06-27]:
      (1) s/provides identifiers/provide identifiers/ in definition of language (standards is plural)
      (2) s/for global from the/for global use from the/ on p8
      (3) Is anchor9 in 3.2 supposed to remain or not? I would have thought the time for comments on that was past?
    4. Dan Romascanu: Comment [2011-07-07]:
      (blank)
    5. Robert Sparks: Comment [2011-06-29]:
      I don't agree that this document needs BCP status as currently formulated. We can find a way to address the downref inconvenience if that's a primary motivation. I don't find a basis in 2026 for "This is informational but we REALLY mean it". If there are requirements being placed on future IETF work (even if those requirements apply only to a particular set of groups), I can see an argument for BCP in the 2026 definitions.
      That said, if this is published as a BCP, I don't believe it does any harm to the work it is attempting to influence, and very little additional harm to how the world (especially outside the IETF) interprets RFCs with this designation (beyond continued erosion of the perception of BCPs as "special"), so I am balloting no objection while stating a preference that the choice be reconsidered.
    6. Sean Turner: Comment [2011-07-12]:
      This is updated to add Catherine's comment:
      I'm curious to see how Dan's 1st discuss point shakes out. If it's really going to be a BCP, then the following should be changed:
      "The definitions in this document are not normative for IETF standards; however, they are useful and standards may make informative reference to this document after it becomes an RFC."
      If it's a BCP then, as Barry noted in his response to Dan, everybody could normatively reference this document. I'm not really sure I buy the rationale of wanting to make this a BCP because everybody wants to normatively reference it (because DOWNREFs are easy), but if that is the case, then we ought to say so.
      Is there somebody outside the IETF that can't reference an informational RFC that wants to refer to this draft?
      Catherine's: I found the phrase "Internet users must be able to be enter text in typical input methods and displayed in any human language." in the introduction somewhat hard to parse. Does it mean that 1) users should be able to use any of a set of typical input methods and 2) it should be possible to display the results in any human language, or that users should be able to enter text from any human language using typical input methods?

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Web Host Metadata (Proposed Standard)
    draft-hammer-hostmeta-16
    Token: Peter Saint-Andre
    Note: The Document Shepherd is James Manger <James.H.Manger@team.telstra.com>.
    Discusses/comments (from ballot 3418):
    1. Jari Arkko: Comment [2011-07-14]:
      The JRD document format - a general purpose XRD 1.0 represenation - s/represenation/representation/
    2. Stephen Farrell: Discuss [2011-07-13]:
      (1) Section 2 - Question - you say the client MUST follow redirects. Is that the same as for HTTP generally? If not, then I think it needs to be justified. (Not sure, but I thought 30x wasn't a MUST follow generally.) If you stick with the current MUST, then I think you need a security consideration that a bad server could DoS a client via a redirect loop and that clients SHOULD or MUST handle this gracefully.
      (2) Section 2 - Are you saying that a client that gets a 404 on port 80 MUST also try 443 to see if the same thing happens? That seems onerous and given you've said the server MUST give the same response, it also seems fairly useless.
      (3) Section 3 - are you saying that servers MAY include any old element/attribute they want but that clients MUST ignore any they don't understand? If so, please make that clear.
      (4) Section 3 - "If there is any discrepancy between the content of the XRD 1.0 XML representation and any other representation for the same resource, the client MUST only use the XRD 1.0 XML representation." I don't get that - how will the client end up with 2 representations to compare? (Is it signalled via more than one Accept or what? Needs to be stated.) Is a client supposed to actually compare all variants? e.g. if it asks for XRD and JSON. If a client has two Accept values (headers or values?) then how does the server return both? That all seems over complex - why not just say that a client MUST ask for one and get one (or an error) and then use that? (Or maybe I missed something.)
      (5) The security considerations say that applications with sensitive stuff MUST only send host-meta information via TLS. Doesn't that conflict with the earlier statement that the same information MUST be sent via both HTTP and HTTPS? (2nd para of section 2)
    3. Stephen Farrell: Comment [2011-07-13]:
      (8 items)
    4. Russ Housley: Comment [2011-07-11]:
      The Gen-ART Review by Suresh Krishnanon 26-Jun-2011 points out that this document has two downrefs that have not been called out in the writeup: RFC 2818 and RFC 4627.
    5. Sean Turner: Comment [2011-07-11]:
      It's okay to use "NOT RECOMMENDED" in the context of RFC 2119, but you need to add it to the notation section..

    Telechat:

  2. The Codecs and Profiles Parameters for "Bucket" Media Types (Proposed Standard)
    draft-gellens-mime-bucket-bis-05
    Token: Pete Resnick
    Discusses/comments (from ballot 3772):
    1. Russ Housley: Discuss [2011-07-12]:
      The Gen-ART Review by Miguel Garcia on 5-Jul-2011 raised several concerns with the RFC 2119 language, ABNF, and IANA considerations. Please respond to this review, which can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg06490.html
    2. Peter Saint-Andre: Comment [2011-07-12]:
      It's not good to place normative text into ABNF comments, so please move these directives to real paragraphs:
      ; Parsers MAY ignore <language>
      ; Parsers MAY support only US-ASCII and UTF-8
      Does the text "Parsers MAY support only US-ASCII and UTF-8" actually mean "Parsers MUST support US-ASCII and UTF-8 but MAY support other encodings"? If so, please add a normative reference to RFC 3629 for UTF-8.
      Nothing in the text explains why Section 3.4 is included.
      http://tools.ietf.org/tools/bap/abnf.cgi reports several errors in the ABNF.
      I concur with the feedback provided by Robert Sparks and Sean Turner.
    3. Robert Sparks: Discuss [2011-07-12]:
      1) The document states that if the codecs parameter is lost, the information it contained can be found in the body - adding it to the Content-Type header field is essentially an optimization. Futher, if the information in the body contradicts the information in the codecs parameter, the information from the codecs parameter is discarded. I'm not seeing the same statements for the profile parameter. So:
      Is it true that the information that is intended to be captured in the profile parameter is always already available in the body? If so, text analogous to what exists for the codecs parameter needs to be added to the draft. I would also encourage text making it even clearer to someone wanting to use these two parameters that it must be the case that the body can be correctly interpreted if the parameter values are lost.
      If it's not true that the information intended for the profile parameter value is already available in the body, the draft needs to explore the ramifications of minting new parameter values more explicitly.
      2) It would help to describe what "profile" means, and disambiguate the kinds of profiles that are already encoded in the codecs values from the kinds of profiles this parameter is intended to talk about.
      3) How should a recipient treat a Content-Type header field value that has both a codecs and profile parameter that are inconsistent with each other?
    4. Robert Sparks: Comment [2011-07-12]:
      The document should explain (or perhaps it could avoid) "registered brands" as used in section 4.4
    5. Sean Turner: Discuss [2011-07-11]:
      If you're adding this an optional parameter to media types defined in RFCs aren't you updating those RFCs? This would adding "Updates: 3839, 4339, and 4393 (once approved)" to the header.
      Please add a section that lists the differences between RFC 4281 and this draft. This will greatly aid implementers.
    6. Sean Turner: Comment [2011-07-11]:
      (5 items)

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) (Informational)
    draft-ietf-radext-crypto-agility-requirements-06
    Token: Dan Romascanu
    Note: Bernard Aboba (Bernard_Aboba@hotmail.com) is the document shepherd.
    Discusses/comments (from ballot 3809):
    1. Russ Housley: Discuss [2011-07-11]:
      The Gen-ART Review by Mary Barnes raises quite a few concerns. It deserves a response. The review can be found at: http://wiki.tools.ietf.org/dav/genart/reviews/draft-ietf-radext-crypto-agility-requirements-06-barnes.txt
    2. Sean Turner: Comment [2011-07-11]:
      Section 2: r/can selected/can be selected
      Section 4.2: maybe add a reference to RFC 5280 in the following: "it is RECOMMENDED that a RADIUS crypto-agility solution support X.509 certificates *[RFC5280]* for authentication between the NAS and RADIUS server"

    Telechat:

  2. IPv6 Node Requirements (Informational)
    draft-ietf-6man-node-req-bis-11
    Token: Ralph Droms
    Note: Bob Hinden (bob.hinden@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3837):
    1. Pete Resnick: Comment [2011-07-13]:
      I agree with Peter's DISCUSS comment.
    2. Peter Saint-Andre: Discuss [2011-07-12]:
      This document is full of normative keywords and says it is "intended to be an Applicability Statement". Per Section 3.2 of RFC 2026, why is it not on the standards track?
    3. Sean Turner: Discuss [2011-07-14]:
      This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do at this time).
      There are quite a number of errata reported on the RFCs referenced in this draft: 2460, 4861, 4191, 3971, 1981, 2675, 4443, 4291, 4941, 3315, 5952. Resolving these would aid, some might say greatly aid, implementers.
      Is there any chance of getting a group of reviewers comprised of some subset of the august body of authors/contributors from 4294 and this document to address the errata?
    4. Sean Turner: Comment [2011-07-14]:
      Consider adding DNSSEC to the title of 7.1.

    Telechat:

  3. Rationale for update to the IPv6 flow label specification (Informational)
    draft-ietf-6man-flow-update-07
    Token: Jari Arkko
    Note: Brian Haberman (brian@innovationslab.net) is the document shepherd for this document.
    Discusses/comments (from ballot 3847):
    1. (none)

    Telechat:

  4. Codec Requirements (Informational)
    draft-ietf-codec-requirements-04
    Token: Robert Sparks
    Note: Jonathan Rosenberg (jdrosen@jdrosen.net) is the document shepherd.
    Discusses/comments (from ballot 3863):
    1. Wesley Eddy: Comment [2011-07-05]:
      Note section 3.1 is inconsistent with section 2 which defined narrowband as 8 kHz not 8-16 kbps; this pattern of error is repeated many times throughout the rest of the document. The document should be internally consistent when using this terminology. It seems to use the terminology in reference to bit rates more often than to sampling rates, so maybe the definition just needs to be updated?
      In section 5.2 and 5.3, how is quality / betterness measured specifically? Do you mean via an actual MOS test, formally carried out, or just more subjectively?
      A couple of the references section entries (carrot08 and wright09) aren't sufficient to actually locate the works in a library and need to be expanded. The full citation information can be found pretty easily via google.
    2. Adrian Farrel: Comment [2011-07-14]:
      I have reviewed this document for its impact on routing and have no issues.
    3. Stephen Farrell: Discuss [2011-07-01]:
      Good document, but I have one thing I think needs fixing. I hope this is trivial.
      This document says: "In terms of quality vs bit-rate, the codec to be developed must be better than the currently available codecs that satisfy the IPR requirements in the guidelines document."
      So you're importing those IPR requirements and therefore you're missing a normative reference to draft-ietf-codec-guidelines.
    4. Stephen Farrell: Comment [2011-07-01]:
      (1) section 3.2: VBR is used but not expanded (until 5.2) or defined. There are also terms like "transform domain" etc which are probably familiar to those in this field but that are not defined. I'm not asking that all those definitions be added but would suggest adding a good reference or two to the introduction to some introductory material that does define these things, preferably including something that is widely available at no cost, if that exists.
      (2) top of p10: "the reference implementation" - this seems to be something that the authors/wg are assuming will exist but that has not so far been stated. Maybe easiest is to just s/the/a/ unless you really do mean "the" reference implementation for some reason in which case stating some requirements for that would seem to be called for. (Same thing on p14.)
      (3) Please add references for the mentioned codecs (Speex etc.) - if those are already referenced from some other WG document, just pointing at that would be fine.
      (4) There have been some more recent results about encrypted VBR leaking. I think this'd be a good additional reference: "Phonotactic Reconstruction of Encrypted VoIP Conversations: Hookt on fon-iks", White et al. 2011 IEEE Symposium on Security and Privacy (I would have added a URL there but last time I did that I broke the tracker;-)
    5. Dan Romascanu: Comment [2011-07-14]:
      The title of the document does not reflect the content with any degree of accuracy. It also may be possible that other codec work will be done in the future in the IETF based on different requirements. I suggest to change the title to something on the lines of 'Internet Audio Codec Requirements for Interractive Applications'.
    6. Peter Saint-Andre: Comment [2011-07-12]:
      It would be good to provide informational references for the following technologies mentioned in Section 4: SIP [RFC3261], SDP [RFC4566], XMPP [RFC6120], and Jingle [XEP-0167].
      Please also provide a reference to RFC 3951 for iLBC, a reference to the G.722.1 specification, and a URL for the Speex project.
      Several acronyms are not expanded (e.g., FFT, DTX).

    Telechat:

  5. Coupled Congestion Control for Multipath Transport Protocols (Experimental)
    draft-ietf-mptcp-congestion-05
    Token: Wesley Eddy
    Note: Yoshifumi Nishida (nishida@sfc.wide.ad.jp) is the document shepherd.
    Discusses/comments (from ballot 3871):
    1. Stewart Bryant: Discuss [2011-07-11]:
      I know that the ASCII text that we use makes it very difficult to publish maths, but I found that the method of presenting the math chosen by the authors, particularly the math embedded in the paragraphs, and the absence of equation numbers made it extremely difficult to understand what they were saying.
      I have the three worst examples below, but I would request that the authors work on the rest of the math to find a clearer way to present it.
      (3 examples)
    2. Wesley Eddy: Comment [2011-07-06]:
      the authors should consider the comments sent by David Black in his TSVDIR review; a minor revision may be necessary in order to answer the main question raised.
    3. Pete Resnick: Comment [2011-07-13]:
      I don't understand why this document is being put forward for Experimental instead of standards track. The document writeup says there is strong consensus in the WG for this document, there is a good discussion of how this mechanism will not cause congestion problems, and there are already some implementations. It doesn't seem research or something that isn't appropriate for attempted deployment.
    4. Sean Turner: Comment [2011-07-14]:
      For the Security Considerations, I think maybe you meant to say something like:
      "This coupled congestion control algorithm defined in this draft adds no new security considerations to those found in [I-D.ford-mptcp-multiaddressed] and [RFC6181]. Detailed security analysis for the Multipath TCP protocol itself is included in [I-D.ford-mptcp-multiaddressed] and [RFC6181]."
      Instead of None followed by where the security considerations are found.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Conclusion of FYI RFC Sub-series (Informational)
    draft-iesg-rfc1150bis-01
    Token: Adrian Farrel
    Note: Adrian Farrel (adrian@olddog.co.uk) is the document shepherd
    Discusses/comments (from ballot 3845):
    1. Wesley Eddy: Comment [2011-07-07]:
      something seems wrong with the last sentence of the first paragraph of the Background section around "that regarding"
    2. Stephen Farrell: Comment [2011-07-01]:
      maybe s/should be used/can be used/ for citations.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. VP8 Data Format and Decoding Guide (Informational)
    draft-bankoski-vp8-bitstream-04
    Token: Robert Sparks
    Note: ISE submission.
    IPR: Google Inc's Statement of IPR Related to draft-bankoski-vp8-bitstream-02
    Discusses/comments (from ballot 3865):
    1. Stewart Bryant: Comment [2011-07-11]:
      I have only reviewed this document for Routing implications and see no issues.
    2. Wesley Eddy: Comment [2011-07-09]:
      The document seems to be incomplete. I'm unsure where to find the yv12config.h referenced in section 2 or the vpx_config.h referenced later -- are these supposed to be included in the document, or do they live somewhere else that the reader is supposed to know how to find? You should make sure this is as self-contained as possible, as references to files that may not be available N years from now doesn't seem like a good idea. Note, there may be other files like this missing; I only spot-checked a number of them as I was walking through it. Otherwise, I thought this was nicely written.
    3. Adrian Farrel: Comment [2011-07-14]:
      It is always a shame when a document shows up (even as an independendent publication request) and fails to pass idnits.
      Thank you for the inclusion of the clear patent-related text in the document.
    4. Peter Saint-Andre: Comment [2011-07-13]:
      Informational documentation is good, especially when it is accurate and complete. I am unable to judge the accuracy of this document (however, I did notice some small errors, such as "/*!\file decoder_impl.h" instead of "/*!\file vpx_codec_internal.h" in Section 20.19). As Wes Eddy noted regarding completeness, some files seem to be missing. Although I'm not quite sure which files are supposed to be included, according to my count the following files might be missing:
      (14 file names)

    Telechat:

3.3.2 Returning Items

  1. (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. Home Networking (homenet)
    Token: Jari

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Network Configuration (netconf)
    Token: Dan

    Telechat:

4.2.2 Proposed for Approval

  1. Protocol Independent Multicast (pim)
    Token: Adrian

    Telechat:

5. IAB News We can use

6. Management Issues

  1. SMI Security for Mechanism Codes Request [IANA #472222] (Michelle Cotton)

    Telechat:

  2. Response to Keith Moore's Request to Change RFCs 3056 and 3068 to EXPERIMENTAL (Ron Bonica)

    Telechat:

  3. Policy for milestone updates in the automated tool (Russ Housley)

    Telechat:

  4. Minutes of interim meetings (Member)

    Telechat:

7. Agenda Working Group News

Reminder from Secretariat

1355 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-07-14 07:30:04 PDT)

draft-ietf-mboned-ssmping

  1. Stewart Bryant: Discuss [2011-07-13]:
        The timestamp specifies the time when the Echo
    Request message is sent.  The first 4 bytes specify the number
    of seconds since the Epoch (0000 UTC Jan 1, 1970).  The next 4
    bytes specify the number of microseconds since the second
    specified in the first 4 bytes.
    
    It would seem to be in the best interests of the Internet if we were to minimize
    the number of timestamp epochs and formats that we used in our OAM protocols.
    Unless there are good reasons to choose a different format, the NTP format shown
    in Figure 3 of RFC5905 and used in RFC 4379 (see Errata) would seem to be most
    appropriate.
    
    There is a good case for writing a BCP on the subject of on the wire and in
    particular OAM timestamps so that there is a reference point for future
    occasions when the subject arrises. 
        
  2. Stewart Bryant: Comment [2011-07-13]:
    
        
  3. Wesley Eddy: Discuss [2011-06-22]:
        in section 2, there's discussion of rate limiting and
    mention of a one request per second per IP address limit.
    This is a bit of a heuristic, and should be described as
    such.  It is not necessarily ideal for all networks and
    configurations and may err on either the too conservative
    or too aggressive sides depending on several variables.
     
        
  4. Wesley Eddy: Comment [2011-06-22]:
    Section 1 should really be more to the point about what
    this document's purpose is.  It specifies a way to send
    packets to a unicast address which elicit responses to
    both a unicast and a multicast addresses, yet never says
    that so clearly until midway through section 2.
  5. Adrian Farrel: Discuss [2011-07-14]:
        The mboned charter says:
       This is not meant to be a protocol development Working Group.
    
    Is this not a protocol? In which other WGs has it been reviewed? (The
    write-up is silent)
    
    ---
    
    idnits says...
    
      == You're using the IETF Trust Provisions' Section 6.b License Notice
         from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. 
         (See http://trustee.ietf.org/license-info/)
    
    I think we need the draft to be resubmitted with the up-to-date
    license notice before we can accept it for publication.
    
    ---
    
    The Experimental ranges available here are far too large. There are 64
    experimental message types and 16384 experimental option types.
    Experiments are supposed to have limited scope and duration. Such large
    experimental ranges will encourage code-point squatting. Please reduce 
    the available range to one or two messages and no more than six options.
    
    ---
    
    Section 3.2
    
       Values 7 and 8 are reserved.
    
    You need to be more careful. I suspect that you mean "reserved and must
    not be allocated by any future document."  If you just say "reserved" 
    this may be mistaken for "available".
    
    But anyway, the text later in 3.2 is confusing:
    
          Reserved, type 7
    
             This option code value was used by early implementations for an
             option that is now deprecated.  This option should no longer be
             used.  Clients MUST NOT use this option.  Servers MUST treat it
             as an unknown option (not process it if received, but if
             received in an Echo Request message, it MUST be echoed in the
             Echo Reply message).
    
    You say "deprecated" but you asked for the code point to be "reserved".
    
    This says both "should (sic) no longer be used" and MUST NOT be used by 
    a client. Then it goes on to say that that MUST NOT is not an error and
    MUST be processed by the server.  
    
    I suggest:
    
             This option code value was used by implementations of version 1
             of this protocol, and is not used in this version. Servers MUST
             treat it as an unknown option (not process it if received, but
             if received in an Echo Request message, it MUST be echoed in 
             the Echo Reply message).
    
    Similarly, I suggest:
    
          Reserved, type 8
    
             This option code value was used by implementations of version 1
             of this protocol, and is not used in this version. Servers MUST
             treat it as an unknown option (not process it if received, but
             if received in an Echo Request message, it MUST be echoed in
             the Echo Reply message).
    
    ---
    
    Section 3.2
    
    Client ID says...
    
             A server should treat
             this as opaque data, and MUST echo this option back in the
             reply if present (both Server Response and Echo Reply).
                             
    But Version says...
    
             Client
             ID and Sequence Number options SHOULD be echoed if present
    
    MUST != SHOULD
    
    Similarly:
    Sequence Number...
    
             A
             server replying to an Echo Request message MUST copy it into
             the Echo Reply (or Server Response message on error).  
    
    The table in Section 3.4 confirms the "MUST" echo.
     
        
  6. Adrian Farrel: Comment [2011-07-14]:
    I am slightly puzzled by the author's contact details. Are they 
    up-to-date and will the email address reach the author in AUTH48?
    
    ---
    
    I think it would help, very early in Section 2, to say that the Server
    is typically the root of a multicast tree, and the Client is typically
    the leaf. You could go on to explain variations from this.
    
    ---
    
    Section 3
    
       The Init message generally contains some prefix options asking the
       server for a group from one of the specified prefixes.
    
       For an Echo Request the client generally includes a number of
       options
    
    These are pretty vague statements for a protocol specification!
    
  7. Stephen Farrell: Comment [2011-07-13]:
    This sets up a sort-of covert channel between the
    client sending the Init and the MC group members 
    that could be used e.g. in botnet control. (I've no
    idea if that's actually happened or not.)
    
    I don't know what might be done about that right now, but
    having the server just send a hash of the client supplied 
    options should work, but would be a fairly large change 
    to the protocol at this stage.
    
    I guess it might be worth noting this potential abuse
    and possible solution in case the protocol is revised later.
    
  8. Russ Housley: Discuss [2011-07-12]:
        
      The Gen-ART Review by Suresh Krishnan on 12-Jul 2011 raised two
      concerns that deserve a response.
    
      * I am not sure why this spec needs to contain the options 7 and 8
        as they are not relevant to this version of the protocol. Wouldn't
        the default behavior with unknown options take care of this
        automatically?
    
      * It would be good if the draft specifies a default TTL (e.g. 64) in
        case the server did not include a TTL option. In this case, the
        server implementations need not bother to add the option if they
        are happy with the default (which I suspect they would be). 
        
  9. Dan Romascanu: Comment [2011-07-14]:
    I support Wesley's DISCUSS. The one second interval between answers of a server
    to a given client may be too little, just fine or too much depending on many
    factors, size and topology of the network included. Either some justification or
    some other indication of how this value is to be used (or deviated from) is
    required.
  10. Peter Saint-Andre: Comment [2011-07-11]:
    I concur with Sean Turner's DISCUSS. Regarding denial of service attacks,
    reference to RFC 4732 would be helpful (both to formulate appropriate text and
    for completeness of the references).
  11. Sean Turner: Discuss [2011-07-12]:
        This is an update discuss based on Vincent's SECDIR review (http://www.ietf.org
    /mail-archive/web/secdir/current/msg02772.html).
    
    #1) Random #s
    
    The minute you mention random #s a reference to RFC 4086 pop in to my mind.
    Please tweak the following:
    
    Section 3.2:
    
    Add a reference to [RFC4086] in the following sentence (Client ID):
    
        The value might be a randomised string that is likely
        to be unique, possibly combined with the client IP address.
    
    Section 5:
    
    Add a reference to [RFC4086] in the following sentence:
    
       A good Session ID would be a pseudo random
       byte string that is hard to predict.
    
    Section 8: 
    
    Please add the following:
    
      [RFC4086] provides more information on generating
      pseudo-random numbers.
    
    Section 11:
    
    Add a normative reference to RFC 4086
    
    A question:
    
    Section 2 includes the following:
    
       At runtime, a client generates a client ID that is unique for the
       ping test.
    
    But then there's no requirement in 3.2 about the ID being unique.  Shouldn't
    there be?
    
    #2) Shouldn't there be something about DoS attacks in the security
    considerations?
    
    #3) Section 5, "Server Behaviour", says:
    
       When the server receives an Echo Request message, it may first check
       that the group address and Session ID (if provided) are valid."
    
       This is a "MUST"!!! If the Session ID is used, the server has no
       choice but checking it during the first processing stages.
    
    #4) Section 5 says:
    
            "Note that the server may receive Echo Request messages with no prior
             Init message.  This may happen when the server restarts or if a
             client sends an Echo Request with no prior Init message.  The server
             may go ahead and respond if it is okay with the group used.  If the
             group is not okay, the server sends back a Server Response."
    
       This "may go ahead and respond" is in total contradiction with 
       the security recommendations. Using a Session ID is a "SHOULD", and
       it is allowed to ignore this recommendation only in rare circumstances.
       A few ping requests may fail if the server is restarted, sure, but
       this will only be a transitory problem, so it's not a big deal. 
    
       I'm also wondering if the "sends back a Server Response" strategy is
       appropriate. With this "Response", an attacker that spoofs the IP address
       of a target has a way to oblige a server to send back a UDP packet to
       the target. It's questionable.
    
    #5) Section 9 says:
    
            "The server SHOULD then only respond to Echo
             Request messages that have a valid Session ID associated with the
             source IP address of the Echo Request."
    
       How should the server behave if the Session ID is not valid?
       This is not clarified whereas this is a critical aspect. 
        
  12. Sean Turner: Comment [2011-07-12]:
    This is an update comment based on Vincent's SECDIR review (http://www.ietf.org
    /mail-archive/web/secdir/current/msg02772.html).
    
    #1) Section 3.2 (Server Info, type 6):
    
    1.1) r/Support for this option is optional./Support for this option is OPTIONAL.
    
    1.2) Need a normative reference to UTF-8.
    
    #2) Section 6, If these are really recommendations shouldn't the text be tweaked
    to use the phrases like "It is RECOMMENDED that ..." Technically, there's no
    2119 language in the section.
    
    #3) Section 8, unless you're trying to redefine the meaning of the following:
    "Message types 0-191 require specification (an RFC or other permanent and
    readily available reference)," replace it with "Message type 0-191 are
    registered following the procedures for Specification Required from [RFC5226],"
    and add a normative reference to RFC 5226 (which is where specification required
    is defined). X2
    
    #4) Section 8, I think this ought to be a MUST:
    
       An option specification must describe how
       the option may be used with the known message types.
    
    #5) Section 3.2, Is there a recommendation for the Session ID format?  Maybe a
    16-bit or 32-bit field should be recommended?
    
    #6) Section 3.4, When describing the format of the "Server Response, type 83",
    there should be a note that a Session ID option SHOULD be included, since this
    is the only way for a server to communicate this option.
    
    #7) Section 4, "Client behaviour": must -> MUST in:
    
       If the Server Response contained a Session ID, then it
       must also include that, with the exact same value, in the Echo
       Requests.
    
    #8) Section 5: should -> SHOULD in:
    
       The server should additionally include a Session ID.
    
    #9) Section 9 says:
            "The worst case is if the host receiving the unicast Echo Replies also
             happens to be joined to the multicast group used."
    
       Yes in case of an ASM session, no in case of an SSM session
       (unless the server is also the SSM source, of course). This should
       be clarified.
    
    #10) Section 9 says:
    
            "...responding to at most one Echo Request per second."
    
       It should be clarified that this is one response per second per client.
       BTW, I'm also wondering if there should not be a global rate limitation,
       in addition to the per-client rate limitation.
    
    #11) Section 9 says:
    
       Rather than saying "how spoofing can be prevented", I'd rather
       say "how spoofing can be mitigated" since spoofing is NOT
       prevented with this approach.
    
       Note also that an attacker that is on the path between a client
       and a server may eavesdrop the traffic, learn a valid Session ID,
       and if he can use spoofing, he can also continue generating Echo
       Requests until the Session ID validity period times out... A note
       may be added to clarify that this is by no means a definite security
       mechanism.
    
    #12) Section 9, 2nd paragraph:
    
       It's clear that group management is critical with ASM, and that
       the multicast IP address range used for multicast ping SHOULD be
       disjoint from those used for data sessions. There is no clear
       recommendation though. I suggest to add some text here.
    
    #13) Section 9 says:
    
            "The main concern is bandwidth."
    
       Is it really "the main concern"? I'm not sure. Disturbing an ASM
       data session with Echo Response traffic (when feasible) is a serious
       concern, since Echo Response traffic may be misinterpreted by the
       receivers.

draft-ietf-dime-nat-control

  1. Jari Arkko: Comment [2011-07-14]:
    I do not understand IPv6 on figures 3 and 4. Are they trying to show
    dual-stack operation? If so, why is there only "public IPv4" on the
    right side? Or are they trying to show NAT64-type of deployment? If
    so, why is there IPv4 on the left side? Please clarify.
    
  2. Ralph Droms: Discuss [2011-07-13]:
        This DISCUSS asks about process and can be quickly resolved.
    
    Has this document been reviewed by the Transport Area; e.g., behave Working
    Group or the Transport Area Directorate? 
        
  3. Wesley Eddy: Comment [2011-07-11]:
    my DISCUSS comments have been very well-addressed in the update, and I've
    cleared them
  4. Stephen Farrell: Discuss [2011-07-14]:
        (1) Why is the on-demand query feature required? (Section 1, bullet 5.)
    This seems to be something that might have significant privacy
    implications if abused. There is some text in the security
    considerations about this, but I don't see text saying why this is
    needed at all.
    
    (2) Session IDs need to be hard to guess or else any Diameter node (or
    nearby host pretending to be such) could use the query NCR to suck all the
    state from a NAT.  Does 3588 mandate that? If not, maybe this spec
    should (as an additional requirement). If 3588 does mandate that then
    re-iterating it here would maybe be good.
    
    (3) 5.1 says that identity MAY be verified and that authorization is
    also a MAY. Why are both not SHOULD or MUST? Even within a 
    "trusted" network, hosts may be compromised, or users may 
    misbehave.
    
    (4) Security considerations says that it "is assumed" that the DNCA
    peers are in the same, "trusted" domain. To me, that implies that this
    specification MUST NOT be used outside that scenario, if you have
    not defined how to do authentication and authorization in an
    interoperable manner.  
        
  5. Stephen Farrell: Comment [2011-07-14]:
    (1) Possibly dumb question: Why does this assume that all external
    addresses are IPv4?
    
    (2) I agree with Sean's discuss.
  6. Robert Sparks: Discuss [2011-07-12]:
        The deployment framework section strongly implies that there will be a single
    entity acting as the NAT controller. The introduction implies other deployment
    models, calling out that applications hosted by the service provider may be
    involved as a NAT controller (the example used is SIP-proxy server deployments).
    
    Is it the case that you expect multiple, perhaps uncoordinated controllers? If
    so, some discussion in the document seems warranted. Either way, the document
    should be explicit. 
        
  7. Robert Sparks: Comment [2011-07-12]:
    I'm surprised there is no discussion of how this relates to midcom and other nat
    control proposals.
  8. Sean Turner: Discuss [2011-07-13]:
        This might be somewhat related to Robert's discuss:
    
    According to the security considerations authentication, authorization,
    integrity, and confidentiality is demanded.  Does this require either IPsec
    between the NAT-controller and NAT-device (where both are end-points) or
    directly connected (i.e., no relays/agents) with TLS between the NAT-controller
    and NAT-device?  Figures 3 and 4 show this but I don't see something that
    explicitly says this. 
        

draft-ietf-dime-local-keytran

  1. Stephen Farrell: Discuss [2011-07-13]:
        
    (1) I'm not sure that the Key-Type AVP is well enough specified.  At least
    for the RSA-KEM variant, I would have expected to see a set of CMS options
    (e.g. are certs to be included or not) would be needed in order to get
    interop. (I was offine doing the review and am not familiar enough with 
    the other options to know if the same issue arises.) Have there been any 
    implementations of these, and if so, what did they put in the key values? 
    I also don't get why the RFCs defining the details for Key-Type AVPs
    are informative and not normative. If this document defines a protocol
    that will result in interop, then they need to be normative I'd have
    thought. 
    
    (2) Which of the Key-Type(s) are implementers of this expected
    to support? 
    
    (3) The security considerations need to say something about transporting
    keys that are not otherwise protected. I think you need to say that 
    Keying-Material AVPs that are not suitable to be sent in clear MUST 
    only be sent between two Diameter nodes using TLS or IPsec unless 
    all the Diameter nodes on a path are known to be equally trusted. 
    I'm sure wordsmithing is needed there but don't have time right now 
    to offer a suggestion. (Sorry) Neither of the RFCs referenced in the
    security considerations section say that. I've no idea how far that might
    be from the WG's opinion.
     
        
  2. Russ Housley: Comment [2011-07-11]:
      The Gen-ART Review by Joel Halpern on 2-Jun-2011 asks a reasonable
      question.  I would like to see it answered.
    
      The document carefully and reasonably does not define the contents of
      the keying material AVP.  This reviewer presumes that those closer to
      the activity will know where the contents have been or will be
      defined.  Are they already defined, or will they be defined in future
      documents?  If they are already defined, would it make sense to state
      that, and identify the location?  (My confusion is that it would seem
      difficult for existing RFCs to define the format of a TLV that did not
      exist.  But that may be a failure of my understanding.)
  3. Sean Turner: Discuss [2011-07-13]:
        I gotta ask about the choice of RSA-KEM.  I couldn't find email on the list
    about it.  Why not straight up RSA - for which almost everybody on the planet
    who has a certificate has one where few (any?) have RSA-KEM certificates?  If
    it's just list algs why not also add RSAES-OAEP Key Transport Algorithm
    [RFC4055]?  Maybe ECDH too? I'm just curious if somebody asked for RSA-KEM or
    you just picked a second one for agility purposes. 
        
  4. Sean Turner: Comment [2011-07-13]:
    I fully support Stephen's discuss positions.

draft-ietf-sidr-repos-struct

  1. Adrian Farrel: Discuss [2011-07-13]:
        idnits shows:
    
      ** Downref: Normative reference to an Informational draft:
         draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch')
    
    I didn't see this downref called out in the last call 
        
  2. Adrian Farrel: Comment [2011-07-13]:
    I agree with the Discuss points about referencing RFC 2119 and about
    being Standards Track.
    
    ---
    
    In Section 3...
    
          *  It is recommended in Section 2.1 that repository operators
             SHOULD implement some form of directory management regime
    
    I don't think Section 2.1 makes this as a "recommendation". I think it
    is a definition. Perhaps change to...
    
          *  Section 2.1 states that repository operators SHOULD implement
             some form of directory management regime
    
    ---
    
    I found a number of cases of "SHOULD" being used without any indication
    of why or when divergence is allowed/advisable. I don't have any reason
    to debate SHOULD/MUST in these cases, but it is normal to accompany a
    SHOULD with some discussion (often a MAY) to explain why MUST is not
    used.
  3. Stephen Farrell: Comment [2011-07-13]:
    (1) Including examples for all the recommended names would be a real
    help for implementers and shouldn't be too hard if someone has code
    already. I'd really like to see that added. 
    
    (2) Did the WG consider specifying that repositories MAY or SHOULD
    contain a README-like file informally describing the content of the
    repository. It might be good to have a well-defined place for that kind
    of information.
    
  4. Pete Resnick: Discuss [2011-07-10]:
        Why is this not simply standards track? The MUSTs and SHOULDs that I see are
    perfectly sensible behaviors that can be observed "from the 'net", and all of
    the protocol in here looks like it can be updated over time to reflect what
    might be learned from deployment experience. I see no reason not to make this
    standards track. 
        
  5. Peter Saint-Andre: Discuss [2011-07-12]:
        This document is missing a normative reference to RFC 2119.
    
    The Security Considerations section states:
    
       Repositories are not assumed to be integrity-protected databases, and
       repository retrieval operations MAY be vulnerable to various forms of
       "man-in-the-middle" attacks.
    
    I don't think you mean that it is OPTIONAL for repositories to expose themselves
    to MITM attacks, so please change "MAY" to "might". 
        
  6. Peter Saint-Andre: Comment [2011-07-12]:
    I agree with Pete Resnick that this document deserves to be Standards Track.
    
  7. Sean Turner: Comment [2011-07-13]:
    Please make the following changes to Section 3:
    
    OLD:
    
       The publication repository MUST be available using RSYNC [RFC5781].
    
    NEW:
    
    The publication repository MUST be available using RSYNC [RFC5781][RSYNC].
    
    And the following normative reference:
    
       [RSYNC]    Tridgell, A., "rsync", March 2008,
                  <http://rsync.samba.org/>
    
    This will line it up with the arch document.

draft-ietf-mpls-ldp-p2mp

  1. Stewart Bryant: Comment [2011-07-12]:
    "The loops are transient and will disappear as soon as the unicast routing
    protocol converges. "
    
    Strictly they disappear when both the unicast routing converges AND THEN mLDP
    converges to use the new unicast topology. The point here is that the microloop
    time will be longer than  the unicast routing protocols convergence time. Also
    one may note that the loop time is usually dominated by LFIB update time.
  2. Adrian Farrel: Comment [2011-07-11]:
    Please address the following "minor issues" from the GenArt review by Joel
    Halpern:
    
    The definition (section 1.2)  of MP2MP LSPs should indicate that even though all
    nodes are allowed to send on the LSP, there is still a distinguished root node.
    
    ---
    
    The LDP MP Opaque Value Element extended type (section 2.3, second definition)
    seems to be gratuitous complexity, adding extra matching cases in the LDP
    processing path for no stated value.  Is there really believed to be a need for
    more than 254 types of Opaque values?  If so, explain it in the document.
    
    ---
    
    Section 3.3.1.3 begins by describing two methods for installing the upstream
    path of a MP2MPLSP.  After carefully describing both, it says to only and always
    use the second method.  Would it not be better to describe the constraint (that
    the upstream path must be in place all the way to the root before it claims to
    be established), and then describe the one method that meets taht.  Just don't
    describe a method that is not to be used.
  3. Stephen Farrell: Discuss [2011-07-14]:
        Maybe not really for this document, but this references 5036
    for security considerations, and 5036 says use TCP MD5 but
    that when something better comes along that ought be used. 
    Since we now have TCP-AO, (rfc 5926) is there a plan to 
    move to that?
     
        
  4. Stephen Farrell: Comment [2011-07-14]:
    Are gopher: URIs really appropriate to be used now? (Definition 
    of CRC32)
    
  5. Russ Housley: Comment [2011-07-12]:
      The Gen-ART Review by Joel Halpern on 23-June-2011 resulted in a
      small amount of discussion.  The need for that discussion indicates
      to me that the document needs a better introduction.  In particular,
      the reader needs to be told that the same TLVs are being used to
      reporting on the status of LSPs as well as a downstream device
      sending a request to an upstream device.
    
      In addition, Section 3.3.1.3 describes two methods for installing
      the upstream path of a MP2MPLSP.  After carefully describing both, it
      says to always use the second method.  Would it not be better to
      describe the constraint (that the upstream path must be in place all
      the way to the root before it claims to be established), and then
      describe the one method that meets the requirement.
  6. Dan Romascanu: Discuss [2011-07-14]:
        This is a mature and well written document and I have no concerns about its
    quality and no special operational issues. However, as this is quite a
    significant extension of the LDP I would expect such a document to include a
    minimal set of operational considerations. Is a revision / extension of RFC 3815
    considered for P2MP LDP? If not is there any other standard management interface
    considered? If all is proprietary at protocol level what initialization,
    configuration objects and operations, performance monitoring and/or
    notifications should be considered at minimum by a network operator in order to
    activate and manage properly a network that deploys this protocol? If this
    information belongs to some other document please point to it. 
        
  7. Sean Turner: Comment [2011-07-13]:
    
      

draft-ietf-ipfix-configuration-model

  1. Russ Housley: Comment [2011-07-11]:
      The Gen-ART Review by Vijay Gurbani on 8-June-2011 raises one
      editorial comment:
      
      There are references in the Abstract, which could probably
      be removed and replaced in the body of the draft.
  2. Peter Saint-Andre: Comment [2011-07-12]:
    [W3C.REC-xml-20040204] is the 3rd edition of the XML spec. The most recent
    edition is the 5th: [W3C.REC-xml-20081126]

draft-ietf-6man-flow-ecmp

  1. Stewart Bryant: Discuss [2011-07-13]:
        Since the document is giving advice on ECMP, it should alert the reader to the
    polarization problem.
    
    The document should also alert the reader to the OAM issues that arise with
    ECMP. 
        
  2. Stewart Bryant: Comment [2011-07-13]:
    A reference to draft-ietf-mpls-entropy-label-00 would seem appropriate since
    they seek to achieve the same though at different layers.
  3. Adrian Farrel: Comment [2011-07-13]:
    There is no mention of the fact that individual nodes in a network are free to
    implement different algorithms without impacting the interoperability or
    function of the network.
  4. Pete Resnick: Discuss [2011-07-11]:
        Section 3 of this document (the main section) seems like protocol to me. (For
    example, "Inner packets MUST be encapsulated in an outer IPv6 packet whose
    source and destination addresses are those of the tunnel end points (TEPs)".)
    Therefore, I see no reason for this not to be on the Standards Track. It seems
    like it has interoperability impacts and gives normative implementation
    guidance. 
        
  5. Peter Saint-Andre: Comment [2011-07-11]:
    I agree with the DISCUSS from Pete Resnick that this seems like a Standards
    Track document, not a BCP.
  6. Robert Sparks: Comment [2011-07-11]:
    I found this document clear and hope it has the impact the group intends.
    I
    support Pete's discuss though - why did the group choose BCP as the intended
    status for this document?
  7. Sean Turner: Comment [2011-07-14]:
    Maybe add (e.g., by using IPsec between the two tunnel end-points) to the end of
    the 2nd sentence in the security considerations.  Just to provide an example of
    how it might be done.

draft-ietf-6man-flow-3697bis

  1. Stewart Bryant: Discuss [2011-07-13]:
        Since the document is giving advice on ECMP, it should alert the reader to the
    polarization problem.
    
    The document should also alert the reader to the OAM issues that arise with
    ECMP. 
        
  2. Stewart Bryant: Comment [2011-07-13]:
    A reference to draft-ietf-mpls-entropy-label-00 would seem appropriate since
    they seek to achieve the same though at different layers.
  3. Wesley Eddy: Discuss [2011-07-11]:
        In Section 2, paragraph 4, this MUST NOT is clearly a SHOULD NOT as this
    document itself permits a case where it's allowed to be broken.  MUST NOT is
    absolute per 2119; no exceptions are allowed. 
        
  4. Wesley Eddy: Comment [2011-07-11]:
    The first paragraph of the introduction mentions that a flow could consist of
    all packets in a specific transport connection.  Many transport connections have
    bidirectional packet flows.  The authors might consider clarifying whether the
    same flow label MAY, SHOULD, or SHOULD NOT be used bidirectionally or whether a
    flow is really just unidirectional.
  5. Adrian Farrel: Comment [2011-07-14]:
    There is no mention of the fact that individual nodes in a network are free to
    implement different algorithms without impacting the interoperability or
    function of the network.
  6. David Harrington: Discuss [2011-07-11]:
        This specification uses the full size of the flow label.
    Since it has no
    discriminator to indicate that it is being used for load balancing, no other use
    can be made of this field.
    I would think it might be better to reduce the hash
    size (maybe to 16 bits) to allow a usage-discriminator so other standardized
    usages of the flow label could be accomodated. 
        
  7. Russ Housley: Comment [2011-07-12]:
      The Gen-ART Review by Roni Even on 6-Jul-2011 points out one typo in
      section 3, fifth paragraph: "An alternative approach is to to use"
  8. Peter Saint-Andre: Comment [2011-07-12]:
    Does this document intend to classify RFC 3697 as Historic?
    
    The keyword boilerplate does not include "NOT RECOMMENDED", but the text does
    (in Section 3).
    
    An informative or perhaps even normative reference to BCP 106 (RFC 4086) might
    be in order regarding the assignment of flow label values.
    
    An informative reference to RFC 4732 might be in order regarding denial of
    service.
  9. Robert Sparks: Discuss [2011-07-11]:
        It's not clear whether the exceptional token rewriting described in section 6.1
    should take the existing flow token into account, or treat the incoming packets
    as if they had a flow token of zero and behave exactly like a Section 3
    forwarding node. If the intent is that this security device is only obfuscating
    the values some upstream element may have chosen for flow tokens while keeping
    the flows distinguishable, some additional text should say that and point out
    what's lost by doing so. If nothing is lost, then why are you keeping the
    requirement that otherwise forwarding nodes MUST NOT change the flow label
    value? 
        
  10. Robert Sparks: Comment [2011-07-11]:
    I agree with Wes that the currently stated "MUST NOT change the flow label
    value"..."A possible exception" formulation in section 2 could be improved
    editorially. If the questions in my DISCUSS don't lead to a different change,
    one way to adjust this would be to say something like "MUST either leave the
    flow label unchanged or change it only as described in section ..."
  11. Sean Turner: Discuss [2011-07-13]:
        I don't think the point made by Richard Barnes' made it in the last version:
    
    Richard:
    
    Given the risks
    that this document discusses, it might be worth considering a
    recommendation that networks SHOULD NOT make resource
    allocation decisions based on flow labels without some
    external means of assurance.  Or some similar warning against
    making resource decisions on a completely unsecured field.
    
    Brian:
    
    Yes, that makes sense when *not* in the stateless load
    distribution scenario.
     
        
  12. Sean Turner: Comment [2011-07-13]:
    Ditto for this:
    
    Richard: Also, purely from a terminology perspective, I found the
    phrase "unintended service" confusing and less accurate than
    the "better service" phrase used in RFC 3697.  It might be
    better to spell this out: " ... an adversary may be able to
    obtain a class of service that the network did not intend to
    provide ... "
    
    Brian: Agreed.

draft-ietf-intarea-router-alert-considerations

  1. Ron Bonica: Discuss [2011-07-13]:
        I intend to change this from a DISCUSS to YES as soon as a few minor changes are
    made.
    
    s/network operators need to actively protect themselves against externally
    generated IP Router Alert packets/network operators SHOULD actively protect
    themselves against externally generated IP Router Alert packets
    
    s/ Thus, it is RECOMMENDED that applications and protocols not be deployed with
    a dependency on processing of the Router Alert option (as currently specified)
    across independent administrative domains in the Internet./   Thus, applications
    and protocols MUST NOT be deployed with a dependency on processing of the Router
    Alert option  (as currently specified) across independent administrative domains
    in the Internet.
    
    - In Section 4.2.2, just above Figure 4, you talk about a private enterprise
    network. Do you mean a VPN? Is there any chance of another enterprise (C)
    sending a RA Optioned Packet to Enterprise A? If so, should B deliver it?
    
    - In the second part of section 4.2.2, you talk about "special agreements
    between administrative domains". More text is required. here. Let's say that A
    enters into an agreement with B. That's fine. Now let's say that B enters into
    an agreement with C. That's fine, so long as B tells A about the agreement with
    C. Now let's say that C enters into an agreement with D. Will D inform A? If
    not, the special agreement has been breached. I don't see this flying in the
    real world. 
        
  2. Ron Bonica: Comment [2011-07-13]:
    1) You might want to find another word for "punt". This word may not be
    understood by those not familiar with American Football or Rugby.
  3. Wesley Eddy: Comment [2011-07-07]:
    definition of fast-path should mention that this is the nominal processing path
    within a router for datagrams, and then the slow-path definition should say that
    this is a sub-nominal processing path for packets that require special
    processing or differ from assumptions made in fast path heuristics.
  4. Adrian Farrel: Comment [2011-07-11]:
    I wouldn't mind my name being spelled right :-)
  5. Russ Housley: Comment [2011-07-13]:
      The Gen-ART Review by Miguel Garcia on 13-Jul-2011 includes two
      editorial comments:
    
      - Make sure that "Router Alert Option" is written with capital "O"
        across the document. There are a few instances with a lower "o".
    
      - Expand acronyms at first occurrence. This includes: ASIC
  6. Pete Resnick: Discuss [2011-07-13]:
        The way 2119 terminology is used in this document is problematic. Three general
    issues:
    
    1. The document repeatedly says "it is RECOMMENDED", in the passive voice,
    instead of saying who should be doing what. For example, in 4.1:
    
       Thus, it is RECOMMENDED that applications and protocols not be
       deployed with a dependency on processing of the Router Alert option
       (as currently specified) across independent administrative domains in
       the Internet.
    
    (This one has the additional problem that the recommendation is *not* to do
    something, making it more confusing.) It seems to me much better to rewrite this
    as:
    
       Thus, applications and protocols SHOULD NOT be deployed with a
       dependency on processing of the Router Alert option (as currently
       specified) across independent administrative domains in the Internet.
    
    If for some reason you want to use the term "RECOMMENDED" and stick to the
    passive voice (which I would wonder about because it is identical to using the
    term "SHOULD"), you could try:
    
       Thus, deployment of applications and protocols with a dependency on
       processing of the Router Alert option across independent
       administrative domains in the Internet is NOT RECOMMENDED.
    
    The same sort of thing appears twice in section 4.3 and twice in section 5. The
    current phrasing I fear will confuse implementers and obscures what the document
    is actually requiring.
    
    2. The use of the phrase "MAY be safely deployed" seems like an inappropriate
    use of the term "MAY". That doesn't seem to be specifying a protocol option. I
    think what you mean is "can be safely deployed". This occurs in 4.2.1 three
    times and 4.2.2 three times.
    
    3. In section 4.3:
    
       As a last resort, if the SP does not have any means to safely
       transport end to end IP Router Alert option packets over his network,
       the SP MAY drop those packets.
    
    That "MAY" seems odd as the other choices are given as examples (not protocol
    options) in the preceeding three paragraphs. Also, because this is a "last
    resort" with "undesirable consequences", it seems that it is not a real option
    as much as something that the SP SHOULD NOT do except as a "last resort". Again,
    using the word "can" would work here, or it ought to be rewritten with the
    "SHOULD NOT".
    
    A similar thing applies to the MAYs in the first and last paragraphs of section
    5. They appear to be examples, not protocol options. 
        
  7. Pete Resnick: Comment [2011-07-13]:
    I think this document would do fine as a standards track document instead of a
    BCP.
  8. Peter Saint-Andre: Comment [2011-07-12]:
    In Section 3, it would be good to expand "DOS" on first use and add an
    informative reference to RFC 4732.
  9. Sean Turner: Discuss [2011-07-14]:
        Doesn't this document update RFC 2113 and 2711?  If this document is all about
    security considerations of something defined in those two documents doesn't it
    update that document?
    
    I think the security considerations ought to be tweaked a bit to note that 2311
    and 2711 originally defined the RAO and included some security considerations:
    
    This document expands the security considerations of [RFC2113] and [RFC2711],
    which defined the RAO, to discuss security risks associated with current usage
    of the IP Router Alert Option and associated practices.  See [RFC4081] for
    additional security considerations. 
        

draft-ietf-mpls-tp-linear-protection

  1. Adrian Farrel: Discuss [2011-07-11]:
        Significant Routing Directorate review comments from Lou Berger need to be
    resolved before this document can be approved 
        
  2. Dan Romascanu: Discuss [2011-07-13]:
        The DISCUSS and COMMENT is partially based on the OPS-DIR review performed by
    Bert Wijnen:
    
    1. in section 3.1:
    
       o  OAM indication - OAM fault management or performance measurement
          tools may detect a failure or degrade condition on either the
          working or protection transport path and this SHOULD input an
          indication to the Local Request Logic.
    
    Why is this only a SHOULD and not a MUST? If there are exception cases I suggest
    to detail them.
    
    2. Same question about the next bullet: 
    
    o  WTR expires - The Wait-to-Restore timer is used in conjunction
          with recovery from failure conditions on the working path in
          revertive mode.  The timer SHALL signal the PSC control process
          when it expires and the end point SHOULD revert to the normal
          transmission of the user data traffic.
    
    3. in section 4.1:
    
        The frequency of the three rapid messages and the separate frequency
        of the continual transmission SHOULD be configurable by the operator.
        For protection switching within 50ms, it is RECOMMENDED that the
        default interval of the first three PSC messages SHOULD be no larger
        than 3.3ms.  The subsequent messages SHOULD be continuously
        transmitted with an interval of 5 seconds.
    
    It might be good to explain the rationale for the RECOMMENDED intervals and
    maybe some explanation as to what considerations need to be taken into account
    when configuring these values. Has the WG considered to standardize the
    configurability of these frequencies? Or is it left (intentionally?) to each
    implementation how this is done?
    Can an operator (or an NMS) easily see what the
    values are at the various LERs?
    
    4. In section 4.3.3.1 and 4.3.3,2 the description of the transitions of the
    Normal State and Unavailable State end by 'All other local inputs SHALL be
    ignored.' and 'All other remote messages SHALL be ignored'. In 4.3.3.3
    'Protecting administrative state' we have 'All other local inputs SHALL be
    ignored.' but 'All other remote messages SHOULD be ignored.' In 4.3.3.4.
    Protecting failure state, 4.3.3.5.  Wait-to-restore state, and 4.3.3.6.  Do-not-
    revert state the lists of transitions end with 'All other local inputs SHOULD be
    ignored.' and 'All other remote messages SHOULD be ignored.' Why SHOULD and not
    SHALL, what are the exception cases and the recommended behavior? 
        
  3. Sean Turner: Discuss [2011-07-14]:
        Some more from the obviously uninformed reader...
    
    #1) Section 4.2.2, I thought this section would also say something along the
    lines of "other values are ignored by this version of the protocol".
    
    #2) Section 4.2.5 & 4.2.6: Shouldn't there be a registry for FPath and Path
    values?
    
    #3) In Section 4.2.7, should it also say that the reserved fields "MUST be
    ignored on receipt"?
    
    #4) RFC 5586 says that the ACH is in network byte order, but doesn't say
    anything about the encoding for ACH TLVs.  Maybe this draft should explicitly
    state that the TLV is encoded in network byte order (or is this stated somewhere
    else in the MPLS suite of RFC+drafts)? 
        
  4. Sean Turner: Comment [2011-07-14]:
    #1) Section 1.1: r/compared to other survivability mechanisms/, compared to
    other survivability mechanisms (e.g., ... ).
    
    Isn't it kind of an empty claim otherwise?  The survivability draft only claims:
    
       In a mesh network, linear protection
       provides a very suitable protection mechanism because it can operate
       between any pair of points within the network.
    
    #2) Expand P2P on first use.
    
    #3) In Section 4.2.2, I think it would aid the reader greatly to add a pointer
    to registry in Section 5.2?  When I read 4.2.2, the first thought that popped in
    to my mind was: well what about all the other values are they reserved?  It's
    probably also worth point out that values are assigned by IANA.

draft-ietf-mpls-tp-identifiers

  1. Jari Arkko: Discuss [2011-07-14]:
        Thanks for writing this draft. I would like to recommend its
    publication as an
    RFC, but before that I had two question marks that
    I'd like to understand
    better. It may be that I'm just missing some
    background information, I'm not
    necessarily saying that there is a problem in the
    document.
    
    I would like to talk about the choice of "::" as a separator. The
    document does not make it clear if this only a syntactic construct in
    this document or also something that might appear in configuration
    interfaces, debug outputs, or even on the wire in textual messages. If
    so, are there any cases where a colon or double colon of an IPv6
    address might lead to am ambigious representation?
    
    Secondly, Section 5.3 maps tunnel endpoint addresses to node
    identifiers. I'd like to discuss when such mappings are possible, as
    it certainly sees that in some contexts (e.g., signaling) you actually
    need an address, not an identifier, particularly when for IPv6 the
    node identifiers are not addresses.
     
        
  2. Stewart Bryant: Discuss [2011-07-12]:
        The purpose of this discuss is to be able to review the resolution of the
    outstanding last call comments. 
        
  3. Adrian Farrel: Discuss [2011-07-11]:
        A number of IETF Last Call comments need to be addressed in a new revision...
    
    =====
    
    AD review
    
    Add the following section:
    
    7.2.1.  MPLS-TP Section MEP_IDs
    
       IP compatible MEP_IDs for MPLS-TP are simply the IF_IDs of each end
       of the section.  For example, for a section whose MEG_ID is
    
          A1-IF_ID::Z9-IF_ID
    
       the Section MEP_ID at A1 would be
    
          A1-IF_ID
    
       and the Section MEP_ID at Z9 would be
    
          Z9-IF_ID.
    
       Where the Section MEP_ID needs to be globally unique, this is
       accomplished by using globally unique Node_IDs as defined above.
       Thus a globally unique Section MEP_ID becomes
    
          Global_ID::IF_ID.
    
    ---
    
    Section 1.3
    
    OLD
    The notation does define a preferred ordering of the fields.
    NEW
    The notation defines a preferred ordering of the fields.
    END
    
    ---
    
    Section 1.3
    
    OLD
     Z9 is used to indicated the
    NEW
     Z9 is used to indicate the
    END
    
    =====
    
    Greg Mirsky
    
    I have a question to new Section MEP-ID. In MPLS-TP a Section can be either
    physical link or logical, section layer LSP, link. I think that listed Section
    MEP_ID addresses the former case. Would Section MEP-ID in the latter case be the
    LSP MEP-ID? I think that both cases must be identified and their Section MEP-IDs
    listed.
    
    =====
    
    Alessandro D'Alessandro
    
    Sect 7: 
       A maintenance point is either a Maintenance 
       Entity Group End-point (MEP) or a Maintenance Entity Group
       Intermediate Point (MIP). Maintenance points are uniquely associated
       with a MEG.
    
    This is true for MEP. MIP, as currently defined, are not uniquely associated
    with a MEG.
    
    ---
    
    Sec 7.4
       At a cross-connect point, in order to automatically generate MIP_IDs
       for MPLS-TP, we simply use the IF_IDs of the two interfaces which are
       cross-connected
    
    The above given definition refers to "intermediate node". It should be extended
    to cover also the case of "end nodes" because MIPs could be located in such
    nodes when per-interface MEPs model is applied (e.g. draft-ietf-mpls-tp-oam-
    framework and Yoshinori's contributions) a reference to sect 4, where IF_ID are
    defined, should be added
    
    =====
    
    ITU-T Question 12/15
    
    https://datatracker.ietf.org/documents/LIAISON/file1237.pdf
     
        
  4. Russ Housley: Comment [2011-07-12]:
      Please consider adding CC::ICC.
    
  5. Sean Turner: Discuss [2011-07-14]:
        #1) Is there a reason there's not a normative reference for OAM in the intro:
    "OAM, as defined in [RFC6291], functions"?  Should the phrase "MPLS-TP
    management and OAM functions" be changed to match the recommendations in 6291 by
    using the phrase "MPLS-TP OAM and Management (O&M) function"
    
    #2) I'm not so sure I buy the "this is a framework so we're not going to say
    anything" argument in the security considerations. The abstract and intro say
    that this document defines identifiers and it's telling operators how to make
    them (see 1st comment).  If you're going to do that then I think you need to say
    something about how the identifier's uniqueness is guaranteed and maybe a couple
    of generic things about might happen if they're not unique.  I don't think you
    need to say a lot, but something along the lines of:
    
    Uniqueness of the identifiers from this document is guaranteed by the assigner
    (e.g., a Global_ID is unique based on the assignment of ASNs from IANA and both
    a Node_ID and a IF_Num are unique based on the assignment by an operator).
    Failure by an assigner to use unique values for the identifier will [insert
    words - an example: result in the end of the world as we know it because an
    operator will have unleashed the zombie apocalypse].
    
    #3) If this is really a framework, should it be a standards track doc?  Maybe it
    should be a BCP because you're telling operators how to identify their stuff? 
        
  6. Sean Turner: Comment [2011-07-14]:
    Section 3: must->MUST
    
       A Global_ID must be derived from a 4-octet AS number assigned to the
       operator.

draft-ietf-mpls-tp-cc-cv-rdi

  1. Stewart Bryant: Comment [2011-07-11]:
    Please ask the RFC editor to align the state diagrams on to single pages in
    final layout.
  2. Dan Romascanu: Comment [2011-07-14]:
    Joel Jaeggli made a number of editorial suggestions in his OPS-DIR review. I
    suggest that these are taken into consideration:
    
    2.1 
    
    I would add continuity check to the glossary since cv is in there (both are also
    defined elsewhere)
    
    3.5 says:
    
       The base spec is unclear on aspects of how a MEP with a BFD transmit
       rate set to zero behaves. One interpretation is that no periodic
       messages on the reverse component of the bi-directional LSP originate
       with that MEP, it will only originate messages on a state change.
    
    I would prefer think that by suggesting this the doucment would simply state
    thst this is the interpretation that SHOULD be used. it should probably also
    site teh mpls tp base spec.
    
       3.7.7. Discriminator values 
    
       In the BFD control packet the discriminator values have either local 
       to
    the sink MEP or no significance (when not known). 
        
       My Discriminator
    field MUST be set to a nonzero value (it can be a 
       fixed value), the
    transmitted your discriminator value MUST reflect 
       back the received value of
    My discriminator field or be set to 0 if 
       that value is not known. 
        
    Your
    Discriminator show always be capatalized given that it's the name of the field.
    
    likewise:
    
       Per RFC5884 Section 7 [8], a node MUST NOT change the value of the 
       "my discriminator" field for an established BFD session.  
    
    My Discriminator  should also be capitalized, I would also be consistent about
    the use of quotes either use them or not. probably I would just be consistent
    with rfc 5884
  3. Sean Turner: Discuss [2011-07-14]:
        #1) Is there a reason there's not a normative reference to "OAM, as defined in
    [RFC6291]."?
    
    #2) (This is related to the my discuss #2 on draft-ietf-mpls-tp-identifiers) I
    was going to place this against the mpls-tp-identifiers draft, but it says that
    the protocols that make use of the identifiers have to explain the security
    considerations of the identifiers...so ... Are there security consequences if
    the identifiers are not unique?  If additional text gets added to tp-
    identifiers, are there any additional concerns? 
        
  4. Sean Turner: Comment [2011-07-14]:
    1) Both the secdir reviewer and I tripped over the use of integrity in the
    abstract:
    
    Abstract: "integrity of the continuity" seems redundant. Just
    "continuity" is better.
    
    Abstract: "any loss of continuity defect". So you lost a "continuity
    defect", did you? Slipper little guys, aren't they? Maybe you mean
    "any loss-of-continuity defect".
    
    #2) Expand OAM on first use.
    
    #3) Introduction: Double references: "[12][12]" and "[13][13]".
    
    #4) Introduction: Missing commas: "the same
       continuity check (CC) proactive continuity verification (CV) and
       remote defect indication (RDI) capabilities" should be "the same
       continuity check (CC), proactive continuity verification (CV), and
       remote defect indication (RDI) capabilities".
    
    #5) Section 2.1: Please include entries for P/F, MPLS, OAM, and PDU.
    
    #6) Section 3.7.4.1: Are the figure #s correct?
    
    #7) Section 4: There should be a blank line before the title. 
    
    #8) Figure 4, Figure 6: There should be a blank line after the Figure label.
    
    #9) Section 4, Section 6: No blank line before Section header.
    
    #10) Section 4: Ends with a list of length 1. List constructs should not be
    used for lists of length one.
    
    #11) Section 6: There should be a blank line before the title.

draft-ietf-appsawg-rfc3536bis

  1. Ralph Droms: Comment [2011-07-09]:
    I've cleared my DISCUSS.
  2. Adrian Farrel: Comment [2011-06-30]:
    In Section 7.1 the definition ends with "<Stringprep>" but there is no
    such reference.
    
    ---
    
    While I found the indications of source references useful, I did not
    find that angle brackets were the best indicators as they are also 
    used for two other (distinct) purposes in the document.
    
    ---
    
    Replacing <NONE> with <THIS> might send a more positive message.
  3. Stephen Farrell: Comment [2011-06-27]:
    (1) s/provides identifiers/provide identifiers/ in definition
    of language (standards is plural)
    
    (2) s/for global from the/for global use from the/ on p8
    
    (3) Is anchor9 in 3.2 supposed to remain or not? I would
    have thought the time for comments on that was past?
    
  4. Dan Romascanu: Comment [2011-07-07]:
    
        
  5. Robert Sparks: Comment [2011-06-29]:
    I don't agree that this document needs BCP status as currently formulated. We
    can find a way to address the downref inconvenience if that's a primary
    motivation. I don't find a basis in 2026 for "This is informational but we
    REALLY mean it".
    If there are requirements being placed on future IETF work
    (even if those requirements apply only to a particular set of groups), I can see
    an argument for BCP in the 2026 definitions.
    
    That said, if this is published as a BCP, I don't believe it does any harm to
    the work it is attempting to influence, and very little additional harm to how
    the world (especially outside the IETF) interprets RFCs with this designation
    (beyond continued erosion of the perception of BCPs as "special"), so I am
    balloting no objection while stating a preference that the choice be
    reconsidered.
  6. Sean Turner: Comment [2011-07-12]:
    This is updated to add Catherine's comment:
    
    I'm curious to see how Dan's 1st discuss point shakes out.  If it's really going
    to be a BCP, then the following should be changed:
    
       The
       definitions in this document are not normative for IETF standards;
       however, they are useful and standards may make informative reference
       to this document after it becomes an RFC.
    
    If it's a BCP then, as Barry noted in his response to Dan, everybody could
    normatively reference this document.  I'm not really sure I buy the rationale of
    wanting to make this a BCP because everybody wants to normatively reference it
    (because DOWNREFs are easy), but if that is the case, then we ought to say so.
    
    Is there somebody outside the IETF that can't reference an informational RFC
    that wants to refer to this draft?
    
    Catherine's:
    
    I found the phrase
    
    "Internet users must be
       able to be enter text in typical input methods and displayed in any
       human language."
    
    in the introduction somewhat hard to parse.  Does it mean that 1) users should
    be able to use any of a set of typical input methods and 2) it should be
    possible to display the results in any human language, or that users should be
    able to enter text from any human language using typical input methods?

draft-hammer-hostmeta

  1. Jari Arkko: Comment [2011-07-14]:
     The JRD document format - a general purpose XRD 1.0 represenation -
    
    s/represenation/representation/
  2. Stephen Farrell: Discuss [2011-07-13]:
        
    (1) Section 2 - Question - you say the client MUST follow redirects. Is
    that the same as for HTTP generally? If not, then I think it needs to be
    justified. (Not sure, but I thought 30x wasn't a MUST follow generally.)
    If you stick with the current MUST, then I think you need a security
    consideration that a bad server could DoS a client via a redirect
    loop and that clients SHOULD or MUST handle this gracefully.
    
    (2) Section 2 - Are you saying that a client that gets a 404 on port 80
    MUST also try 443 to see if the same thing happens? That seems onerous and
    given you've said the server MUST give the same response, it also seems
    fairly useless. 
    
    (3) Section 3 - are you saying that servers MAY include any old
    element/attribute they want but that clients MUST ignore any they don't
    understand? If so, please make that clear.
    
    (4) Section 3 - "If there is any discrepancy between the content of the
    XRD 1.0 XML representation and any other representation for the same
    resource, the client MUST only use the XRD 1.0 XML representation." I
    don't get that - how will the client end up with 2 representations to
    compare? (Is it signalled via more than one Accept or what? Needs to be
    stated.) Is a client supposed to actually compare all variants? e.g. if it
    asks for XRD and JSON. If a client has two Accept values (headers or
    values?) then how does the server return both? That all seems over complex
    - why not just say that a client MUST ask for one and get one (or an
    error) and then use that? (Or maybe I missed something.)
    
    (5) The security considerations say that applications with sensitive
    stuff MUST only send host-meta information via TLS. Doesn't that conflict
    with the earlier statement that the same information MUST be sent
    via both HTTP and HTTPS? (2nd para of section 2) 
        
  3. Stephen Farrell: Comment [2011-07-13]:
    1) The term "host" is odd here, this is really talking about meta-data
    for what I would call a web server.  Since a single physical host can
    serve up many virtual hosts with Apache for example, that'd be worth
    clarifying in case someone thinks that host-wide refers to the physical
    device.
    
    (2) Intro: "This often leads to..." Just wondering - is there documented
    evidence of this happening often somewhere?
    
    (3) Intro: the description of link templates is entirely opaque to me.
    (Actually, I think a rewrite of the entire section would be good.) An
    example would help but I don't get the "hub" example in 1.1 - you say that
    link templates are for more fine-grained information, but this one is not.
    Is that just a badly chosen example? (When I understand this I may be able
    to suggest a better wording.)
    
    (4) 1.1.1 - you say "using an HTTP GET request: " but then present what I
    think is a response.
    
    (5) 1.1.1 - I don't get the reason for presenting the "together" version
    of the URI specific meta-data. I think showing this as an xml document
    just confuses, unless there's a way to make a request that leads to this
    as a response, which you don't say.
    
    (6) 1.1.1 - I don't get what having a higher priority means for the order
    of links and you don't say.
    
    (7) Section 2 - grammar: s/The decision which protocol is used to obtain
    the host-meta document have significant security ramifications as
    described in Section 5./The decision as to which protocol is used to
    obtain the host-meta document can have significant security ramifications
    as described in Section 5./
    
    (8) "only canonical representation" is superfluous s/only//
    
  4. Russ Housley: Comment [2011-07-11]:
      The Gen-ART Review by Suresh Krishnanon 26-Jun-2011 points out that
      this document has two downrefs that have not been called out in the
      writeup: RFC 2818 and RFC 4627.
  5. Sean Turner: Comment [2011-07-11]:
    It's okay to use "NOT RECOMMENDED" in the context of RFC 2119, but you need to
    add it to the notation section:
    
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
    in this document are to be interpreted as described in [RFC2119].
    
    Making this change would fix an ID nit.

draft-gellens-mime-bucket-bis

  1. Russ Housley: Discuss [2011-07-12]:
        
      The Gen-ART Review by Miguel Garcia on 5-Jul-2011 raised several
      concerns with the RFC 2119 language, ABNF, and IANA considerations.
      Please respond to this review, which can be found at:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06490.html 
        
  2. Peter Saint-Andre: Comment [2011-07-12]:
    It's not good to place normative text into ABNF comments, so please move these
    directives to real paragraphs:
    
                      ; Parsers MAY ignore <language>
                      ; Parsers MAY support only US-ASCII and UTF-8
    
    Does the text "Parsers MAY support only US-ASCII and UTF-8" actually mean
    "Parsers MUST support US-ASCII and UTF-8 but MAY support other encodings"? If
    so, please add a normative reference to RFC 3629 for UTF-8.
    
    Nothing in the text explains why Section 3.4 is included.
    
    http://tools.ietf.org/tools/bap/abnf.cgi reports several errors in the ABNF.
    
    I concur with the feedback provided by Robert Sparks and Sean Turner.
  3. Robert Sparks: Discuss [2011-07-12]:
        1) The document states that if the codecs parameter is lost, the information it
    contained can be found in the body - adding it to the Content-Type header field
    is essentially an optimization. Futher, if the information in the body
    contradicts the information in the codecs parameter, the information from the
    codecs parameter is discarded. I'm not seeing the same statements for the
    profile parameter. So:
    
    Is it true that the information that is intended to be captured in the profile
    parameter is always already available in the body? If so, text analogous to what
    exists for the codecs parameter needs to be added to the draft. I would also
    encourage text making it even clearer to someone wanting to use these two
    parameters that it must be the case that the body can be correctly interpreted
    if the parameter values are lost.
    
    If it's not true that the information intended for the profile parameter value
    is already available in the body, the draft needs to explore the ramifications
    of minting new parameter values more explicitly.
    
    2) It would help to describe what "profile" means, and disambiguate the kinds
    of profiles that are already encoded in the codecs values from the kinds of
    profiles this parameter is intended to talk about.
    
    3) How should a recipient treat a Content-Type header field value that has both
    a codecs and profile parameter that are inconsistent with each other? 
        
  4. Robert Sparks: Comment [2011-07-12]:
    The document should explain (or perhaps it could avoid) "registered brands" as
    used in section 4.4
  5. Sean Turner: Discuss [2011-07-11]:
        If you're adding this an optional parameter to media types defined in RFCs
    aren't you updating those RFCs?  This would adding "Updates: 3839, 4339, and
    4393 (once approved)" to the header.
    
    Please add a section that lists the differences between RFC 4281 and this draft.
    This will greatly aid implementers. 
        
  6. Sean Turner: Comment [2011-07-11]:
    #1) Section 3.1 & 4.2 contains the following:
    
       This parameter is optional in all current types to which it is added.
    
    shouldn't it be "OPTIONAL"?
    
    #2) Section 3.1 contains the following:
    
      Future types that contain ambiguity are strongly encouraged to
       include this parameter.
    
    Could we strengthen this to say "are RECOMMENDED"?
    
    #3) Section 3.1 and 4.2 contains the following:
    
       An element MAY include an octet that [RFC2045] REQUIRES to be
       encoded.
    
    REQUIRES isn't 2119 language and I'm not sure you meant to use it here.  I think
    you can probably lower case this because it's a requirement from 2045.
    
    #4) Section 3.5 contains the following:
    
       For existing media types, it is generally advisable for
       the parameter to be optional; for new media types, the parameter MAY
       be optional or required, as appropriate.
    
    Shouldn't optional be OPTIONAL?
    
    #5) Section 4.3 contains the following:
    
       The 'profiles' parameter is an optional parameter that indicates one
       or more profiles to which the file claims conformance.
    
    Shouldn't it be OPTIONAL?

draft-ietf-radext-crypto-agility-requirements

  1. Russ Housley: Discuss [2011-07-11]:
        
      The Gen-ART Review by Mary Barnes raises quire a few concerns.  It
      deserves a response.  The review can be found at:
    
        http://wiki.tools.ietf.org/dav/genart/reviews/
        draft-ietf-radext-crypto-agility-requirements-06-barnes.txt 
        
  2. Sean Turner: Comment [2011-07-14]:
    Section 2: r/can selected/can be selected
    
    Section 4.2: maybe add a reference to RFC 5280 in the following:
    
      it is RECOMMENDED that a RADIUS crypto-agility solution
      support X.509 certificates *[RFC5280]* for authentication
      between the NAS and RADIUS server

draft-ietf-6man-node-req-bis

  1. Pete Resnick: Comment [2011-07-13]:
    I agree with Peter's DISCUSS comment.
  2. Peter Saint-Andre: Discuss [2011-07-12]:
        This document is full of normative keywords and says it is "intended to be an
    Applicability Statement". Per Section 3.2 of RFC 2026, why is it not on the
    standards track? 
        
  3. Sean Turner: Discuss [2011-07-14]:
        This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do at this time).
    
    There are quite a number of errata reported on the RFCs referenced in this
    draft: 2460, 4861, 4191, 3971, 1981, 2675, 4443, 4291, 4941, 3315, 5952.
    Resolving these would aid, some might say greatly aid, implementers.
    
    Is there any chance of getting a group of reviewers comprised of some subset of
    the august body of authors/contributors from 4294 and this document to address
    the errata? 
        
  4. Sean Turner: Comment [2011-07-14]:
    Consider adding DNSSEC to the title of 7.1.

draft-ietf-6man-flow-update

  1. (none)

draft-ietf-codec-requirements

  1. Wesley Eddy: Comment [2011-07-05]:
    Note section 3.1 is inconsistent with section 2 which defined narrowband as 8
    kHz not 8-16 kbps; this pattern of error is repeated many times throughout the
    rest of the document.  The document should be internally consistent when using
    this terminology.  It seems to use the terminology in reference to bit rates
    more often than to sampling rates, so maybe the definition just needs to be
    updated?
    
    In section 5.2 and 5.3, how is quality / betterness measured specifically?  Do
    you mean via an actual MOS test, formally carried out, or just more
    subjectively?
    
    A couple of the references section entries (carrot08 and wright09) aren't
    sufficient to actually locate the works in a library and need to be expanded.
    The full citation information can be found pretty easily via google.
  2. Adrian Farrel: Comment [2011-07-14]:
    I have reviewed this document for its impact on routing and have no issues.
  3. Stephen Farrell: Discuss [2011-07-01]:
        
    Good document, but I have one thing I think needs fixing. I hope
    this is trivial.
    
    This document says:
    
      "In terms of
       quality vs bit-rate, the codec to be developed must be better than
       the currently available codecs that satisfy the IPR requirements in
       the guidelines document."
    
    So you're importing those IPR requirements and therefore you're
    missing a normative reference to draft-ietf-codec-guidelines.
    
        
  4. Stephen Farrell: Comment [2011-07-01]:
    (1) section 3.2: VBR is used but not expanded (until 5.2) or defined. There are
    also terms like "transform domain" etc which are probably familiar to those in
    this field but that are not defined. I'm not asking that all those definitions
    be added but would suggest adding a good reference or two to the introduction
    to some introductory material that does define these things, preferably
    including something that is widely available at no cost, if that exists.
    
    (2) top of p10: "the reference implementation" - this seems to be something
    that the authors/wg are assuming will exist but that has not so far been stated.
    Maybe easiest is to just s/the/a/ unless you really do mean "the" reference
    implementation for some reason in which case stating some requirements for
    that would seem to be called for. (Same thing on p14.)
    
    (3) Please add references for the mentioned codecs (Speex etc.) - if those
    are already referenced from some other WG document, just pointing at that
    would be fine.
    
    (4) There have been some more recent results about encrypted VBR leaking.  I
    think this'd be a good additional reference: "Phonotactic
    Reconstruction of Encrypted VoIP Conversations: Hookt on fon-iks", White et al.
    2011 IEEE Symposium on Security and Privacy (I would have added a URL there
    but last time I did that I broke the tracker;-)
  5. Dan Romascanu: Comment [2011-07-14]:
    The title of the document does not reflect the content with any degree of
    accuracy. It also may be possible that other codec work will be done in the
    future in the IETF based on different requirements. I suggest to change the
    title to something on the lines of 'Internet Audio Codec Requirements for
    Interractive Applications'.
  6. Peter Saint-Andre: Comment [2011-07-12]:
    It would be good to provide informational references for the following
    technologies mentioned in Section 4: SIP [RFC3261], SDP [RFC4566], XMPP
    [RFC6120], and Jingle [XEP-0167].
    
    Please also provide a reference to RFC 3951 for iLBC, a reference to the G.722.1
    specification, and a URL for the Speex project.
    
    Several acronyms are not expanded (e.g., FFT, DTX).

draft-ietf-mptcp-congestion

  1. Stewart Bryant: Discuss [2011-07-11]:
        I know that the ASCII text that we use makes it very difficult to publish maths,
    but I found that the method of presenting the math chosen by the authors,
    particularly the math embedded in the paragraphs, and the absence of equation
    numbers made it extremely difficult to understand what they were saying.
    
    I have the three worst examples below, but I would request that the authors work
    on the rest of the math to find a clearer way to present it.
    
    =========
    
    This is worse in my browser than in the text itself, but even so it is difficult
    to understand the equation
    
    The formula to compute alpha is:
    
                                          cwnd_i
                                     max --------
                                      i         2
                                          rtt_i
                 alpha = tot_cwnd * ----------------
                                   /      cwnd_i \ 2
                                   | sum ---------|
                                   \  i   rtt_i  /
    
    Please can a clearer specification of the equation be provided
    
    =====
    
    Hence, it is possible to compute alpha only once per drop according
       to the formula above, by replacing rtt_i with rtt_avg_i.
    
    There were lots of formulii above
    
    ======
    
    The following is just about readable.
    
    For each ack received on subflow i, increase cwnd_i by min (
          (alpha*bytes_acked*mss_i/tot_cwnd)/alpha_scale ,
          bytes_acked*mss_i/cwnd_i )
     
        
  2. Wesley Eddy: Comment [2011-07-06]:
    the authors should consider the comments sent by David Black in his TSVDIR
    review; a minor revision may be necessary in order to answer the main question
    raised.
  3. Pete Resnick: Comment [2011-07-13]:
    I don't understand why this document is being put forward for Experimental
    instead of standards track. The document writeup says there is strong consensus
    in the WG for this document, there is a good discussion of how this mechanism
    will not cause congestion problems, and there are already some implementations.
    It doesn't seem research or something that isn't appropriate for attempted
    deployment.
  4. Sean Turner: Comment [2011-07-14]:
    For the Security Considerations, I think maybe you meant to say something like:
    
    This coupled congestion control algorithm defined in this draft adds no new
    security considerations to those found in [I-D.ford-mptcp-multiaddressed] and
    [RFC6181].  Detailed security analysis for the Multipath TCP protocol itself is
    included in [I-D.ford-mptcp-multiaddressed] and [RFC6181].
    
    Instead of None followed by where the security considerations are found.

draft-iesg-rfc1150bis

  1. Wesley Eddy: Comment [2011-07-07]:
    something seems wrong with the last sentence of the first paragraph of the
    Background section around "that regarding"
  2. Stephen Farrell: Comment [2011-07-01]:
    maybe s/should be used/can be used/ for citations.
    

draft-bankoski-vp8-bitstream

  1. Stewart Bryant: Comment [2011-07-11]:
    I have only reviewed this document for Routing implications and see no issues.
  2. Wesley Eddy: Comment [2011-07-09]:
    The document seems to be incomplete.  I'm unsure where to find the yv12config.h
    referenced in section 2 or the vpx_config.h referenced later -- are these
    supposed to be included in the document, or do they live somewhere else that the
    reader is supposed to know how to find?  You should make sure this is as self-
    contained as possible, as references to files that may  not be available N years
    from now doesn't seem like a good idea.  Note, there may be other files like
    this missing; I only spot-checked a number of them as I was walking through it.
    Otherwise, I thought this was nicely written.
    
    
  3. Adrian Farrel: Comment [2011-07-14]:
    It is always a shame when a document shows up (even as an independendent
    publication request) and fails to pass idnits.
    
    ---
    
    Thank you for the inclusion of the clear patent-related text in the document.
  4. Peter Saint-Andre: Comment [2011-07-13]:
    Informational documentation is good, especially when it is accurate and
    complete. I am unable to judge the accuracy of this document (however, I did
    notice some small errors, such as "/*!\file decoder_impl.h" instead of "/*!\file
    vpx_codec_internal.h" in Section 20.19). As Wes Eddy noted regarding
    completeness, some files seem to be missing. Although I'm not quite sure which
    files are supposed to be included, according to my count the following files
    might be missing:
    
    coef_update_probs.c
    dboolhuff.c
    dboolhuff.h
    decodeframe.c (in one place called decodframe.c)
    decodemv.c
    dmode.c
    filter_c.c
    onyxd_if.c
    quant_common.c
    reconinter.c
    reconintra.c
    tree_reader.h
    vpx_decoder_compat.h
    yv12config.h