IESG Narrative Minutes

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

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

Corrections from: Barry, Pete, Benoit

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. The OAuth 2.0 Authorization Protocol (Proposed Standard)
    draft-ietf-oauth-v2-25
    Token: Stephen Farrell
    Discusses/comments (from ballot draft-ietf-oauth-v2):
    1. Stewart Bryant: Discuss [2012-04-10]:
      It is not clear to me why it is necessary to create the protocol specific variant of the RFC5226 Review process described in section 11.1, 11.2, 11.3, 11.4.
      Creating new variants of the IANA process creates confusion, and unless there is a good reason specific to this protocol, one of the standard IANA processes should be called out.
      If the plan is to have a list review followed by an expert review of the list discussion, the timetable needs to call out time for the list to do a review and then a time for the expert to do their review.
    2. Benoit Claise: Comment [2012-04-10]:
      I read: "This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849."
      I've not been familiar with OAuth, and one question that bothered me: Why should I implement/upgrade to OAuth 2.0, compared to 1.0? It's not mentioned in the draft. I had to search somewhere to find the answer: in the current charter, which says:
      "In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). The working group has since been developing OAuth 2.0, a standards-track version that will reflect IETF consensus. Version 2.0 will consider the implementation experience with version 1.0, a discovered security vulnerability (session fixation attack), the use cases and functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will
      * improve the terminology used,
      * consider broader use cases,
      * embody good security practices,
      * improve interoperability, and
      * provide guidelines for extensibility."
      Adding at least the first two sentences (or something similar) + one about the "discovered security vulnerability" would make sense, at least to me... Unless this specified in a different document (maybe I-D.ietf-oauth-v2-threatmodel?)
    3. Ralph Droms: Comment [2012-04-10]:
      I came to a similar conclusion as Benoit: readers of this document would benefit from a one-paragraph summary of the reasons for the development of Oauth 2.0. A summary or overview of technical differences would be helpful, as well, if it's not too lengthy.
      I also agree with Stewart's DISCUSS regarding the adoption of modified RFC 5226 review processes rather than reusing existing processes.
    4. Wesley Eddy: Comment [2012-04-03]:
      In section 1, right before 1.1 begins, HTTP is called a transport protocol. While this tends to happen, it still isn't correct. It would be better to reword the sentence replacing: "with any other transport protocol" to something more like: "over any other protocol"
    5. Adrian Farrel: Discuss [2012-04-12]:
      I should like to see a statement along the lines of "OAuth 2.0 is not intended to be backward compatible with OAuth 1.0. The protocol versions may co-exist in the network and implementations may choose to support both. However, it is the intention of this document that new implementation support OAuth 2.0 as specified in this document, and that OAuth 1.0 is used only to support existing deployed implementations."
      It would be useful to include a concise section titled "Changes from OAuth 1.0 (RFC 5849)". This would help implementers moving from 1.0 to 2.0 (and would help reviewers as well :-)
    6. Adrian Farrel: Comment [2012-04-12]:
      Can't Appendix A be folded into Section 12. Perhaps make it 12.1?
    7. Pete Resnick: Comment [2012-04-11]:
      4.3.2 says that the authorization server MUST "validate the resource owner password credentials", but it doesn't say exactly how one might do that. For example, it doesn't say whether to compare things case-sensitively or (and this is the reason it even occurred to me) whether one should be normalizing the UTF-8. I'm fine with that being left as an exercise to the reader if this is the common practice in security protocols. And UTF-8 doesn't make this special; even comparing US-ASCII has it's quirks. The UTF-8 just made it noticable to me.
      8: Just confirming that you are OK with the following legal ABNF productions: ...
    8. Robert Sparks: Comment [2012-04-11]:
      Please consider the following substitutions for the websites and email lists pointed to in section 11.1:
      http://www.iesg.org -> http://www.ietf.org/iesg
      iesg@iesg.org -> iesg@ietf.org
    9. Sean Turner: Discuss [2012-04-12]:
      At v25, I appreciate that you must have slayed more than your fair share of dragons (and some more than once I bet). I appreciate your efforts. Just a couple of things I'd like to discuss:
      0) General: I found the lack of ABNF somewhat disconcerting in that implementers would have to hunt through the spec to figure out all the values of a given field. For example grant_type has different values based on the different kind of access_token requests - four to be more precise - but there's no ABNF for the field. There are many examples of this. It would greatly aid implementers if
      a) the ABNF for all fields were included in the draft and
      b) all the ABNF was collected in one place.
      I had individual discusses for each field that had missing ABNF, but it was getting out of hand so I'm just going to do this one general discuss on this topic.
      1) General: If I buy your argument in s1.7 that this is a framework and you can leave bits needed to fully implement it out, then should this draft not have "protocol" in the title or be tweaked to acknowledge it's not complete? I can hear you all groaning now, but it's truth in advertising. The other RFCs that have been oft quoted as frameworks, like PKIX and CMS, that would allow you to not pick MTI, like the token format, don't have "protocol" in the name. Adding some like ": Framework" after the title so that it's clear this ain't the hole shooting match would, I think, be truth in advertising. It's just a little misleading that the abstract/intro lead you to believe if you implement this draft you'll be access these resources but you have to dig in to s1.7 and s7 to know that the bits need to actually determine access aren't defined in the draft.
      2) Figure 1: Because so many of the later sections refer to the not shown protocol flow I decided to make it a discuss (though I'm sure more than one person would say this is a comment):
      s1.2: Figure 1: If the preferred mechanism for the client request is to go indirectly through the Authorization Server it would be really good to depict that. You could just add that to Figure 1 or add a Figure 2.
      Further, shouldn't the out-of-scope bits also be shown too: client registration, and the interaction between the authorization and resource servers so we get the complete picture? You can mark them out-of-scope in the figure.
      And another thing, the bearer token picture shows client credentials in (C) shouldn't this also show them as optional?
      3) s1.6/s2.3.1/s3.1: So some might consider this nit-picking but when you say "Whenever TLS is required by this specification" do you mean "Whenever this specification requires TLS be used"? MTI doesn't mean mandatory to use, but in this case I think you do mean mandatory to use because it ships around cleartext passwords. This also comes up in s2.3.1 and 3.1 where the text indicates:
      t/The authorization server MUST require TLS as described in Section 1.6 when sending requests using password authentication.
      I'd just replace require with use in both places. Note that s3.1.2.1 seems to have it right: "require the use of TLS".
      4) s1.7: When you say "authorization server capabilities" you're talking about the client discovering which token format is supported? I think the draft needs to be clear that without these underdefined things that the protocol can only interop with the clients being configured a priori.
      5) s1.7: Since you brought it up (and I thank you for being upfront about it) and you provided some examples, shouldn't the list of underdefined things be completely listed? That way if somebody wants to profile this for their use they know all the bits and pieces they need to write down.
      6) s2: The protocol to register the client is out-of-scope but is the directions for the client developer in scope? If so, shouldn't 2119 language be used here:
      When registering a client, the client developer:
      - MUST specify the client type…
      - SHOULD provide its client redirection …
      - MUST include any other …
      7) s2.1: How is trust established?
      8) s2.2: How unique is the client_id? Is it just for this server or universally unique? If it's the later how do you guarantee this? Is there some requirement for the length of the string?
      9) s2.3.1: Where is this described: "Since this client authentication method involves a password, the authorization server MUST protect any endpoint utilizing it against brute force attacks."
      10) s3.1/s3.1.2/s3.2/etc.: why the MUST NOT here and what happens if a fragment is included: "The endpoint URI MUST NOT include a fragment component."
      11) s3.1/s3.2: What happens if they are included more than once - is it rejected or is the first one accepted?: "Request and response parameters MUST NOT be included more than once."
      12) s3.1.2.1: This section made me scratch my head a bit. In which of the scenario's flows is the SHOULD for (i.e., where do you think TLS won't be implemented)? Is it (D) in Figure 3?
      13) s3.1.2.1: How does the authorization server warn the resource owner about the insecure endpoint?
      14) s3.1.2.4/s4.1.2.1: Under what circumstances wouldn't you inform the resource owner of the error (i.e., why isn't that SHOULD a MUST)?
      15) s3.1.2.5: Are there any security considerations that would result if the client includes third-party scripts?
      16) s3.1.2.5: How is this done: "If third-party scripts are included, the client MUST ensure that its own scripts (used to extract and remove the credentials from the URI) will execute first."
      17) s4.1.2.1/s4.2.2.1: The errors in these two sections have the same values but just slightly different meanings: one refers to authorization codes and the other refers to access tokens. Is it wise to use the same name for the error values? This issue would go away if the error_description was required.
      18) s4.1.2/s4.1.2.1/s4.2.2/s4.2.2.1/: Don't you need to say which type of HTTP status code is returned e.g., is it always 302 as shown in the exampled?
      19) How is the expiry time of the access token provided to the resource server? Is this supposed to be documented in the access token documents?
      20) the bearer token spec contained character set restrictions on the error, error_description, and error_uri:
      "Values for the "error" and "error_description" attributes MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E. Values for the "error_uri" attribute MUST conform to the URI-Reference syntax, and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E."
      Do these apply here as well? This might get cleared up with some ABNF.
      21) s10.3: Given Richard's point in GEN-ART review on 10.3, I think it might be worth adding the text you suggested.
      22) s10: About the parameters that require secure transmission/storage: Would a compromise be to just list the ones that require secure transmission/storage? We often do/require this for protocols (e.g., SNMP, NETCONF).
    10. Sean Turner: Comment [2012-04-12]:
      (15 items)

    Telechat:

  2. The OAuth 2.0 Authorization Protocol: Bearer Tokens (Proposed Standard)
    draft-ietf-oauth-v2-bearer-18
    Token: Stephen Farrell
    Discusses/comments (from ballot draft-ietf-oauth-v2-bearer):
    1. Wesley Eddy: Comment [2012-04-03]:
      In Section 1, I suggest changing: "for use with other transport protocols" to something more like: "for use over other protocols". HTTP is not a transport protocol.
    2. Brian Haberman: Comment [2012-04-02]:
      Section 2.1 states:
      "Clients SHOULD make authenticated requests with a bearer token using the "Authorization" request header field with the "Bearer" HTTP authorization scheme."
      Is the SHOULD simply to show a preference for the Authorization request approach over the methods defined in Sections 2.2 and 2.3? If so, in what type of situation would the Authorization request approach not be used?
    3. Russ Housley: Discuss [2012-04-10]:
      The Gen-ART Review by Alexey Melnikov on 10-Apr-2012 reports that two major issues that were raised in an earlier review were not addressed. I have added my own thoughts in addition to those provided by Alexey.
      First, the "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. In some cases, the "scope" value will be used when requesting a new access token with sufficient scope of access to make use of the protected resource. The "scope" attribute MUST NOT appear more than once. The "scope" value is intended for programmatic use and is not meant to be displayed to end users.
      In response to the previous review by Alexey, the document editor provided explanation in email; however, this response was not reflected in the subsequent update to the document.
      More information about the "scope" attribute is needed, especially about the manner that it is used and the possible values. As this attribute is not meant to be displayed to end users, please indicate what values are possible and which entity can allocate them. Is there an IANA registry for possible attribute values? If so, what are the rules for assigning a new registry value.
      Second, Section 3.1 specifies Error Codes. Alexey suggested the use of an IANA registry for this field. Apparently there is already a registry created by draft-ietf-oauth-v2. However this document does not register values defined in this section in that registry. Please explain why the IANA registry is not leveraged by this document.
    4. Pete Resnick: Comment [2012-04-11]:
      Mark Nottingham's Applications Area review has a couple of comments that I think deserve further reply:
      * Section 1: Introduction
      The introduction explains oauth, but it doesn't fully explain the relationship of this specification to OAuth 2.0. E.g., can it be used independently from the rest of OAuth? Likewise, the overview (section 1.3) seems more specific to the OAuth specification than this document. As I read it, this mechanism could be used for ANY bearer token, not just one generated through OAuth flows.
      If it is indeed more general, I'd recommend minimising the discussion of OAuth, perhaps even removing it from the document title.
      I agree that the title would be better simply as "HTTP Bearer Tokens", and then explain in the Abstract and Intro that the motivation and intended use of these Bearer Tokens is the OAuth 2.0 specification. A possibly useful side effect of this change might be that you can make OAuth 2.0 an informative (as against a normative) reference, and that these things could be reused for other purposes in the future. Not a huge deal, but I (like Mark) was unconvinced that the reference to OAuth in the title was necessary.
      * Section 3 The WWW-Authenticate Response Header Field
      The difference between a realm and a scope is not explained. Are the functionally equivalent, just a single value vs. a list?
      Some text, and probably an example, might help explain this a bit better.
      One of his comments asked for some additional review. I don't have a personal opinion whether this is needed, but perhaps you should pursue this:
      * General
      The draft currently doesn't mention whether Bearer is suitable for use as a proxy authentication scheme. I suspect it *may*; it would be worth discussing this with some proxy implementers to gauge their interest (e.g., Squid).
      Finally, there was his major issue. I have not put this in a DISCUSS since, in all honesty, I don't fully understand the implications here. I intend to re-post to the apps-discuss list to see if we can get a better explanation of what the issue is. However, I strongly urge the AD, shepherd, and chairs, as well as the authors, to review this concern. If I get more information that makes the issue clear to me, I may ask the IESG to discuss:
      * Section 2.3 URI Query Parameter
      This section effectively reserves a URI query parameter for the draft's use. This should not be done lightly, since this would be a precedent for the IETF encroaching upon a server's URIs (done previously in RFC5785, but in a much more limited fashion, as a tactic to prevent further, uncontrolled encroachment).
      Given that the draft already discourages the use of this mechanism, I'd recommend dropping it altogether. If the Working Group wishes it to remain, this issues should be vetted both through the APPS area and the W3C liaison.
      (The same criticism could be leveled at Section 2.2 Form-Encoded Body Parameter, but that at least isn't surfaced in an identifier)
    5. Sean Turner: Discuss [2012-04-12]:
      While editing this I say Mike's responses so I just cut them in to see if we can't have one thread going on this draft for my discusses/comments. I added Mike's responses in between <mike> and </mike>
      #1 was updated based on input from Julian.
      #9 was updated based Alexey's GEN-ART review.
      #13 is new.
      (see the link for details...)
    6. Sean Turner: Comment [2012-04-12]:
      (6 items, see link for details)

    Telechat:

  3. EAP Extensions for EAP Re-authentication Protocol (ERP) (Proposed Standard)
    draft-ietf-hokey-rfc5296bis-06
    Token: Stephen Farrell
    IPR: Stephen Farrell's Statement about IPR related to draft-ietf-hokey-rfc5296bis-06 belonging to Microsoft
    Discusses/comments (from ballot draft-ietf-hokey-rfc5296bis):
    1. Ralph Droms: Discuss [2012-04-12]:
      This DISCUSS is raised against the publication status of the document. No action is required from the authors until it is resolved. I expect to clear this DISCUSS after the telechat discussion of the document.
      The relationship between this document and RFC 5296, and the exact status of RFC 5296 should be clarified before this document is published. I've given an editorial example of the nature of the problem in my COMMENTs.
      Adrian has entered a COMMENT that I will expand to a DISCUSS to request a couple of sentences explaining why this document was written to accompany the summary of changes Adrian requested. This issue might be addressed by the RFC Editor note.
    2. Ralph Droms: Comment [2012-04-12]:
      There are at least two instances of references to "new EAP codes" or "New EAP Packets" that should be updated to reflect that the EAP-Initiate and EAP-Finish Packet Codes are already defined, and add a citation to the appropriate IANA registry.
      This typo (missing " " in the line containing "cryptosuite") was copied forward from RFC 5296 (best read with fixed-width font): ...
    3. Adrian Farrel: Comment [2012-04-06]:
      I have no objection to thepublication of this document.
      Please supply a short section "Changes from RFC 5296"
      Please check that all Errata have also been applied to this revision http://www.rfc-editor.org/errata_search.php?rfc=5296
    4. Barry Leiba: Discuss [2012-04-09]:
      This document says there are no IANA actions.
      RFC 5296 did a number of things in the EAP registry
      - Registered Packet Codes 5 and 6
      - Created the Message Types table
      - Created the Initiate and Finish Attributes table
      - Created the Re-authentication Cryptosuites table
      It also registered two values in the USRK Key Labels registry. Shouldn't the references in those IANA registries now all be changed to point to this new RFC, instead of the now-obsolete 5296?
    5. Pete Resnick: Comment [2012-04-11]:
      Pedantic nits: ...
    6. Sean Turner: Comment [2012-04-10]:
      Nice job folks. Only nits: ...

    Telechat:

  4. Round-trip Loss Metrics (Proposed Standard)
    draft-ietf-ippm-rt-loss-03
    Token: Wesley Eddy
    Note: Document shepherd is Henk Uijterwaal (henk@uijterwaal.nl).
    Discusses/comments (from ballot draft-ietf-ippm-rt-loss):
    1. Benoit Claise: Discuss [2012-04-11]:
      I have some clarifying questions for the point 1. and 2. that will determine whether these are real DISCUSS's or not. A 10 minutes discussion with Al would help a lot
      1. Looking at the list of documents at http://datatracker.ietf.org/wg/ippm/, I see that the first set of metrics where IP or IPPM related http://tools.ietf.org/html/rfc2680 -> A One-way Packet Loss Metric for IPPM http://tools.ietf.org/html/rfc2681 -> A Round-trip Delay Metric for IPPM ...
      then I see that that IP (or IPPM to be more precise) is not included any longer http://datatracker.ietf.org/doc/rfc4737/ -> Packet Reordering Metrics http://datatracker.ietf.org/doc/rfc5560/ -> A One-Way Packet Duplication Metric
      I would be interested to understand the change, and it might help with my next question.
      When reading this draft, I was wondering:
      1. if this metric is only for packets? I'm pretty sure it's the case, specifically, when I see the section 3.4 that speaks about packet loss. So should the title be "Round Trip Packet Loss Metrics", or even, to be fully in line with RFC2680, ""Round Trip Packet Loss Metrics for IPPM"?
      2. if the metric was not only for packet, but for application data (the abstract mentions "Many user applications"), then what would be the link with PMOL, RFC6390? Note: I believe that TWAMP doesn't deal with application data, but could be easily extended. A solution such as the Cisco IP SLA (http://tools.ietf.org/html/draft-cisco-sla-protocol-00) could do it.
      2. Section 4.3
      o the Dst sent a Type-P packet back to the Src as immediately as possible, and
      Why is this even useful to mention "as immediately as possible"? I mean: if you have to use round-trip packet loss (instead of one-way packet loss), it's because you're not able to install a "responder" application on the target device. Therefore, you have no control at all on that target device. And you are forced to use a protocol such as ICMP. So, why is this even useful to say "as immediately as possible" if you have no control on that target device? The sentence "the Dst sent a Type-P packet back to the Src as immediately as possible" only makes sense in the case of one-way delay metric.
      I have the same issue with your new proposed text (discussed with Adrian)
      o the Dst sent a Type-P packet back to the Src as quickly as possible (certainly less than Tmax, and fast enough for the intended purpose), and
      I have the same issue with your new proposed text in section 4.4 (discussed with Adrian, AFAIK)
      We add the following guidance regarding the responder process to "send a Type-P packet back to the Src as quickly as possible".
      "A response that was not generated within Tmax is inadequate for any realistic test, and the Src will discard such responses. A responder that serves typical round-trip loss testing (which is relevant to higher-layer application performance) SHOULD produce a response in 1 second or less. A responder that is unable to satisfy this requirement SHOULD log the fact so that an operator can adjust the load and priorities as necessary. Analysis of responder time-stamps [RFC5357] that finds responses are not generated in a timely fashion SHOULD result in operator notification, and the operator SHOULD suspend tests to the responder since it may be overloaded. Additional measurement considerations are described in Section 8, below."
      For example, "A responder that is unable to satisfy this requirement SHOULD log the fact so that an operator can adjust the load and priorities as necessary." I've been doing IP SLA measurements for years with Cisco boxes, and I would only use round trip delay and loss metrics when I can't touch the target device. And here you're asking the target device to do a task for you in case of round trip loss...
      Note: the default configuration for SLA measurement is to put a responder on the target device, and to measure in both directions the one way delay, the loss, and jitter.
      Or maybe, the metric in this draft can only be used with the TWAMP protocol, which I believe requires some configuration on the target device? However, it appears it's not a requirement as TWAMP is mentioned as one example in
      "8. Measurement Considerations and Calibration: Prior to conducting this measurement, the participating hosts MUST be configured to send and receive test packets of the chosen Type-P. Standard measurement protocols are capable of this task [RFC5357], but any reliable method is sufficient."
      Next question: why do mention "but any reliable method is sufficient.". It means that that metric can't be used with ICMP?
      Anyway, it needs some clarifications.
      3. In section 4.3: "Following the precedent of[RFC2681], we make the simplifying assertion: Type-P-Round-trip-Loss(Src->Dst) = Type-P-Round-trip-Loss(Dst->Src)"
      While I could agree that Type-P-Round-trip(Src->Dst) = Type-P-Round-trip(Dst->Src), at some conditions, I disagree with the assertion that if you lose 50% packets, you can conclude that you lost 25% in each direction.
    2. Benoit Claise: Comment [2012-04-11]:
      (five items)
    3. Adrian Farrel: Comment [2012-04-06]:
      Other comments coming from Dan Frost's review ...
    4. Stephen Farrell: Comment [2012-04-11]:
      I had a discuss to check that Sandy Murphy's secdir review comments had been taken into account. I asked and wasn't told they hadn't been, so I've cleared.
    5. Russ Housley: Discuss [2012-04-11]:
      In the last paragraph of Section 5, the document says: " ... (or other process, the details of which MUST be specified if used)."
      Specified how? Is an RFC required? Is a standards-track RFC required? This document already mentions the lack of an IANA registry. Will an IANA registry be needed to help locate these specifications.
    6. Russ Housley: Comment [2012-04-11]:
      Please consider the comments raised by the Gen-ART Review by Ben Campbell on 10-Apr-2012.

    Telechat:

  5. RTCP Extension for Third-party Loss Report (Proposed Standard)
    draft-ietf-avtcore-feedback-supression-rtp-16
    Token: Robert Sparks
    Note: Magnus Westerlund (magnus.westerlund@ericsson.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-avtcore-feedback-supression-rtp):
    1. Wesley Eddy: Discuss [2012-04-10]:
      (1) "screwed up" in Section 6.5 is not very technical; please say what is really wrong (loss, corruption, reordering, etc.)
      (2) Section 1 lists a number of *BUGS* in implementations as the motivations for this. It starts by saying that a use case for this is people not implementing RFC 4585 dithering correctly, then says that another use case is that there are other poor designs causing implosions of FIRs.
      It seems silly to write this new RFC adding a new mechanism rather than just applying pressure to fix those implementations; it would be useful to discuss why that isn't the right answer, since receivers have to implement reactions to this new report anyways, they should be fixing their bugs. I think this is an especially relevant question given the lack of implementation noted in the writeup and Pete's ballot.
    2. Stephen Farrell: Comment [2012-04-10]:
      Just checking: there's no way that a 3rd party loss report could cause a flood of re-transmitted data (that hadn't actually been lost) to be (re-)sent to a target is there? If so, that might constitute a new DoS vector. Its not clearly the case that that can't happen. If it could, then that'd be another reason to authenticate these messages.
      nits/typos: ...
    3. Brian Haberman: Comment [2012-04-04]:
      I just have a few questions on this draft:
      1. The Protocol Overview section states : "Intermediaries in the network that receive a RTCP TPLR SHOULD NOT send their own additional Third-Party Loss Report messages for the same packet sequence numbers." Why is this not a MUST? Is it simply to handle intermediate devices that don't support this function? If there is another scenario where a device may send a TPLR that overlaps, it would be good to spell that out.
      2. There are two places (Sections 4.1 & 4.2) where the length field in the feedback message is set to "2+1*N". Should I interpret that to mean the value is really just N+2? Or is there something I am missing?
    4. Pete Resnick: Comment [2012-04-08]:
      The document writeup says, "There are not yet any reported implementations." Are you really saying that for a protocol that appears to have serious congestion control effects, nobody has written a line of code yet? Has there been any testing of this at all? Are there any planned implementations (perhaps by more than one independent implementer)? If not, perhaps this should be published as Experimental first.
    5. Sean Turner: Comment [2012-04-11]:
      Had the same question Stephen had.

    Telechat:

  6. LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements (Proposed Standard)
    draft-ietf-pwe3-pw-typed-wc-fec-03
    Token: Stewart Bryant
    Note: Andrew Malis (amalis@gmail.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-pwe3-pw-typed-wc-fec):
    1. Adrian Farrel: Comment [2012-04-12]:
      Thanks for a well-written document.
    2. Stephen Farrell: Comment [2012-04-10]:
      I'm not sure if there are really no new security considerations here, but the difference may be relatively minor, (given how I understand these protocols are used, i.e. without any cryptographic authentication;-).
      Anyway, my questions:
      Which of the RFCs referred to in section 5 calls out that sending a spoofed wildcard message will have a bigger impact for lower cost for an attacker?
      Could it also be the case that an attacker able to inject one of these needs less information about the network to cause the same amount of damage compared to an attacker who could not send a wildcard message?
    3. Sean Turner: Comment [2012-04-09]:
      Only a nit: ...

    Telechat:

  7. Explicit Congestion Notification (ECN) for RTP over UDP (Proposed Standard)
    draft-ietf-avtcore-ecn-for-rtp-07
    Token: Robert Sparks
    Note: Roni Even (even.roni@huawei.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-avtcore-ecn-for-rtp):
    1. Stewart Bryant: Comment [2012-04-10]:
      Given that this
      1) This is of interest to 3GPP
      2) MPLS-TP seems to be a popular choice in Mobile wireless backhaul.
      3) Most service provider core networks use MPLS
      Should there not be a reference to RFC5129, and a note that ECN needs to be propagated from the tunnel to the payload?
      I am not sure how common MPLS ECN is, but it is not mentioned anywhere in the MPLS-TP specifications.
    2. Adrian Farrel: Comment [2012-04-12]:
      I don't object to the publication of this document, but it does bother me how much effort, time, and pages go into describing a protocol extension that no-one is apparently bothered to implement. What is the value of a standards track RFC in this case? How can we know whether the document or the protocol are right?
    3. Stephen Farrell: Comment [2012-04-08]:
      I've a couple of general comments and some nits. The former:
      - 55 pages to discuss two bits? something wrong there;-)
      - last para of section 3 (before 3.1), but a general question: you say ECN is set before congestion results in packet drops but I thought that was the point of PCN (the WG) which is just finishing. Are these things all sensible together? I assume a receiver/sender here can be within a PCN "domain" or whatever's the right term. Does all the ECN logic here work if the bits are actually set by a PCN conformant node?
      - Section 11: I don't get this sentence: "Secure RTP (SRTP) [RFC3711] does satisfy the requirement to protect this mechanism despite only providing authentication if a entity is within the security context or not." What's it mean?
      nits: ...
    4. Brian Haberman: Comment [2012-04-09]:
      I am also curious how this approach will interact with a PCN-conformant node (as asked by Stephen).
    5. Barry Leiba: Comment [2012-04-11]:
      Some non-blocking comments -- though I would *really* like to see the IANA Considerations comment addressed.
      Section 3: "ECN support is more important for RTP sessions than, for instance, is the case for TCP. This is because the impact of packet loss in real-time audio-visual media flows is highly visible to users. Effective ECN support for RTP flows running over UDP will allow real-time audio-visual applications to respond to the onset of congestion"
      I'm not clear about what the first sentence is comparing, because RTP doesn't compare to TCP. Do you mean that ECN support is more important for RTP sessions over UDP than for RTP sessions over TCP? I don't think so. Do you mean that it's more important for RTP sessions than for *other applications over TCP*? I think that's it. But then what does TCP have to do with it? It seems that the point is that RTP is more sensitive to congestion issues that other applications are, regardless of the underlying transport protocol. In any case, please clarify that sentence.
      Section 3.1: Do we really need 2119 language in the requirements? I rather think that requirements would generate 2119 language in the protocol.
      Section 9: You explain that the situation with existing APIs is such that it makes "this specification difficult to implement portably." And that's all you say. Any words of wisdom here? Advice to implementors about how to handle the situation?
      Section 10.1: "Following the guidelines in [RFC4566], the IANA is requested to register one new SDP attribute:"
      I see a lot of SDP Parameters registries and tables, and it's not at all clear to me which one this gets registered in. Maybe it's clear to IANA, and maybe this is fine, but maybe also it should be made clearer here. Can you give the exact name of the registry and the table within the registry, to avoid mistakes?
      In general, the different subsections of Section 10 are inconsistent in how (and how specifically) they name the registries and tables you intend to update. I like the way 10.6 does it -- no chance for confusion at all there.
    6. Pete Resnick: Comment [2012-04-11]:
      3.1: I don't understand what the 2119 words add. These are requirements for the protocol designers, not requirements for the protocol implementers.
      6.1: "qdtext = %x20-21 / %x23-7E / %x80-FF ; any 8-bit ASCII except <">"
      That makes me worried. You do not provide an escaping mechanism such that someone could put a quote in their quoted text. You do not specify the interpretation of the stuff from 0x80 through 0xFF (UTF-8? ISO-8859-1? uninterpreted octet?), and worse you call it "8-bit ASCII" which does not have a clear meaning. You also leave out 0x7F (not mentioned in the comment), and I have a guess as to why (it's not printable), but you don't say why. I understand you want this to be extensible, but I don't think the above is fully baked. Perhaps explain what you want to allow and I can recommend some alternatives.
      10.1: "This attribute defines the ability to negotiate the use of ECT (ECN capable transport) for RTP flows running over UDP/IP. This attribute should be put in the SDP offer if the offering party wishes to receive an ECT flow. The answering party should include the attribute in the answer if it wish to receive an ECT flow. If the answerer does not include the attribute then ECT MUST be disabled in both directions."
      I don't think it's a good idea to put protocol instructions into the IANA template. These are all already documented earlier in this document. Just put a pointer to [This document, section 6.1] and skip the last 3 sentences above. You don't want people trying to implement from the registry.

    Telechat:

  8. A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP (Proposed Standard)
    draft-ietf-tcpm-3517bis-02
    Token: Wesley Eddy
    Note: Pasi Sarolahti (pasi.sarolahti@iki.fi) is the document shepherd
    Discusses/comments (from ballot draft-ietf-tcpm-3517bis):
    1. Ronald Bonica: Comment [2012-04-09]:
      Please run this document through the NIT checker before publication.
    2. Stewart Bryant: Comment [2012-04-10]:
      It would be helpful to those searching for information if the abstract noted that this document revised RFC 3517
    3. Benoit Claise: Comment [2012-04-12]:
      I have no objection to the publication of this document.
      One comment from Chris LILJENSTOLPE, part of the OPS-Directorate review.
      I wish the authors had selected some other state variable name other than DupAck for the multiple SACK counter. While it is well described in the draft, on first read it is really not a Duplicate ACK counter, but a multiple SACK counter (number of SACKs between covering ACKs). While useful, it would have been more intuitive to call it MultSack or some such. I do not propose editing the draft just for this purpose, but if another version of the draft is required, it may make the digestion of the material a little easier.
      I leave up to you to act on his feedback.
    4. Adrian Farrel: Comment [2012-04-06]:
      I have no objection to the publication of this document.Just a couple of nits. ...
    5. Stephen Farrell: Comment [2012-04-10]:
      "Pipe" definition says "The algorithm" is often referred to as the pipe alg. That's a little unclear, maybe better to say "The algorithm defined here...." and if that is the case, to also put that in the abstract and intro just to make it easier for someone who does call it that to find the RFC.
    6. Brian Haberman: Comment [2012-04-03]:
      Section 7 talks about the effectiveness of this approach when paired with TCP Reno, but I do not see any discussion of possible interactions with other TCP congestion control algorithms. Has this re-transmission algorithm been tested with other congestion control algorithms?
    7. Russ Housley: Comment [2012-04-09]:
      The Gen-ART Review by Ben Campbell on 4-Apr-2012 suggests some improvements. Please consider them.
    8. Barry Leiba: Comment [2012-04-02]:
      This seems a good, clear document. Thanks for a thought-out Security Considerations section, as well.
      I have one question, as a non-expert on this topic:
      All four functions in section 4 are "SHOULD implement." Can a meaningful implementation really be done if NONE of them are included? If so, fine. If not, maybe a few more words in the first paragraph would be useful, explaining under what conditions it's important to include them or makes sense to leave them out.
    9. Martin Stiemerling: Comment [2012-04-02]:
      An editorial:
      It it is relative short document, but recents RFCs seems all to have a table of contents, which is missing in this draft.

    Telechat:

  9. Rebind Capability in DHCPv6 Reconfigure Messages (Proposed Standard)
    draft-ietf-dhc-dhcpv6-reconfigure-rebind-09
    Token: Brian Haberman
    Note: Ted Lemon (ted.lemon@nominum.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-dhc-dhcpv6-reconfigure-rebind):
    1. Adrian Farrel: Comment [2012-04-08]:
      I have no objection to the publication of this document, but I have a few comments that either reperesent my failure to grasp what you are doing, or would make useful improvements to the document.
      I would prefer that Section 3 did not include the format of the Reconfigure Message option. Rather than "update" the option with a full replacement, isn't it enough to say that msg-type may now additionally take the value 6 to indicate Rebind?
      Section 4: "The server MUST include a Reconfigure Message option (as defined in Section 3) to select whether the client responds with a Renew message, a Rebind message or an Information-Request message."
      Include in what?
      Section 4 is headed "Server Behavior": "The Reconfigure message causes the client to initiate a Renew/Reply, a Rebind/Reply message exchange or an Information-request/Reply message exchange."
      Seems to be describing the client behavior. At least give a forward pointer to Section 5.
      Section 4: "The server interprets the receipt of a Renew, a Rebind or an Information-request message (whichever was specified in the original Reconfigure message) from the client as satisfying the Reconfigure message request."
      Presumably, only if threceived message matches the msg-tpe in the Reconfigure Message option? What if there is a mismatch? can the mismatch be caused by a race?
      Section 5
      How is a legacy client going to handle a Reconfigure Message option with msg-type set to Rebind? Presumably it is going to run some 3315 logic to drop or nack the message as "msg-type unknown, unexpected, or unsupported".
      I believe you should mention this as it impacts on server behavior.
    2. Stephen Farrell: Discuss [2012-04-08]:
      Since I know squat about DHCPv6 these may be cleared up really quickly:
      - Section 7 calls out a clear vulnerability and suggests use of the AUTH option from RFC 3315. I'm told that nobody ever uses the v4 equivalent functionality, is that the same for v6? If so, it would then seem that we have a vulnerability with no practical mitigation which would seem like a bad thing. I'd hope to see at least an honest recognition of that, if its in fact the case.
      - I don't see why the dhc-secure-dhcpv6 is non-normative since its one of two possible ways to do a thing.
      - Should one of AUTH from 3315 or dhc-secure-dhcpv6 be mandatory to implement? If not, why not?
    3. Stephen Farrell: Comment [2012-04-08]:
      - 1st sentence of abstract seems odd, v. hard to read anyway and that's not so good usually. How does the "Reconfigure Message" extend "the Reconfigure Message"? (That's how I read it anyway)
    4. Russ Housley: Comment [2012-04-11]:
      Please consider the editorial suggestions in the Gen-ART Review by Francis Dupont on 7-Apr-2012.
    5. Robert Sparks: Comment [2012-04-11]:
      The introduction motivates some of these changes with a use case of a network administrator who is preparing to shut down a dhcpv6 server causing clients to move to a different server. Is it possible (if so, how easy would it be) to misconfigure the servers involved to cause them to enter a rebind war with each other? If this is something a client might experience, is there guidance to give the client implementations on how to react when it happens?
    6. Sean Turner: Comment [2012-04-10]:
      1) I support Stephen's discuss.
      2) s4: I was having some issues tracking exactly which paragraphs in 19.1-19.3 were being updated/replaced. Could you do the old/new so we knew which paragraphs were being replaced. Ex (assuming I got this bit right):
      4.1 Updates to Section 19.1
      OLD: "A server sends a Reconfigure message to cause a client to initiate immediately a Renew/Reply or Information-request/Reply message exchange with the server."
      NEW: "The server MUST include a Reconfigure Message option (as defined in Section 3) to select whether the client responds with a Renew message, a Rebind message or an Information-Request message."
      3) s5: If the text replaces the text in s19.4 of RFC 3315 could you just say that?
      r/This section updates specific text in/This section replaces

    Telechat:

2.1.2 Returning Items

  1. Gateway Initiated Dual-Stack Lite Deployment (Proposed Standard)
    draft-ietf-softwire-gateway-init-ds-lite-06
    Token: Ralph Droms
    Note: Yong Cui (cuiyong@tsinghua.edu.cn) is the document shepherd.
    IPR: Cisco's Statement of IPR relating to draft-ietf-softwire-gateway-init-ds-lite-00
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-softwire-gateway-init-ds-lite-05
    Discusses/comments (from ballot draft-ietf-softwire-gateway-init-ds-lite):
    1. Wesley Eddy: Comment [2012-04-11]:
      Support Stephen's DISCUSS
    2. Adrian Farrel: Comment [2012-04-08]:
      I have no objection to the publication of this document, but I note that the Security Considerations section is flimsy. Surely there are security issues with how the mapping table at the AFTR is built. Although that is a "local matter" inplementers and deployers need to be aware that this feature must be secured.
    3. Stephen Farrell: Discuss [2012-04-10]:
      1. The security considerations section here appears to be way too brief. I'd like to have known when it is safe to use this, and especially when it is not safe, e.g. if the g/w is on the customer premises and the CID is an IPv4 address, could the customer (hacking the g/w) hijack someone else's (guessable) CID? (That may or may not be a real threat, but I found it hard-to-impossible to figure out based on this draft.)
      2. RFC 6275's security considerations don't appear to apply to this in an obvious way, which part(s) of RFC6275 section 15 are relevant here? Same question applies to RFC 5213.
      3. TS29060 seems like a normative reference, why is it not? Is version 9.1.0 the right version to reference? (there seem to be many) That document (on page 143 of 155) has a two line section 12 on security which is just a reference to something else. I don't know what is meant by referring to this from section 9 here.
    4. Stephen Farrell: Comment [2012-04-10]:
      - p7, what does "must have a proper understanding" mean?
      - p8, CE, PE and ECMP are not expanded (and maybe need a reference/definition, particularly ECMP)
      - Please consider the points raised in Tobias Gondrom's secdir review.
    5. Brian Haberman: Comment [2012-04-04]:
      Section 6 lists a set of abbreviations to describe the type of IPv4 addresses being used in a deployment. I understand all the possibilities, except for "nm" (described as non-meaningful/dummy). This that just a diplomatic way of describing a network deployment that is squatting on someone's public IPv4 address space?
    6. Barry Leiba: Comment [2012-04-11]:
      I second Stephen's DISCUSS and Pete's comment.
    7. Pete Resnick: Comment [2012-04-07]:
      There is only one use of 2119 language, and I'm not convinced it's necessary:
      "o The softwire between the Gateway and the AFTR MAY be created at system startup time OR dynamically established on-demand."
      Is this a protocol option that one or both sides needs to be aware of? That is, does the Gateway or the AFTR need to prepare itself for on-demand establishment, or to be prepared that on-demand might not be available? I suspect you can change it to "may" or "can" and delete the reference to 2119.
    8. Sean Turner: Comment [2012-04-12]:
      I support Stephen's discuss.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. ECC in OpenPGP (Proposed Standard)
    draft-jivsov-openpgp-ecc-14
    Token: Sean Turner
    Note: Wener Koch (wk@gnupg.org) is the Document Shepherd.
    IPR: Certicom's Statement of IPR Related to draft-jivsov-openpgp-ecc-06
    Discusses/comments (from ballot draft-jivsov-openpgp-ecc):
    1. Stephen Farrell: Comment [2012-04-11]:
      Please also consider the (very recent) comments from the secdir review.
      My previous comments are below but from a quick glance seem to be addressed in -12.
      Two substantive comments and a bunch of nits, but this is good stuff.
      #1 The write up talks about running code which is great. Did the implementers of both take a look at this version of the document? I don't recall any last-minute changes but no harm checking.
      #2 I was left wondering about pkcs#1.5 and bleichenbacher's TLS attack and other side-channel attacks, e.g. based on timing or power. Those are not mentioned here, but are not things about which every coder would know. Is there a good document covering such side-channels against PGP, and/or ECC that could be added to section 13? (I'd bet there is, doesn't need to be an RFC.) I think that'd be a good addition. If there's no good document at least some mention of side channels as a security consideration would be good.
      Nits: ...
    2. Russ Housley: Comment [2012-04-09]:
      Thanks for addressing issues raised in the Gen-ART Review by Christer Holmberg on 19-Mar-2012.
      I suggest an update to the Abstract:
      "This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves."
    3. Barry Leiba: Comment [2012-04-11]:
      Some very minor comments [UPDATE: adequately addressed in -12]: ...
    4. Pete Resnick: Comment [2012-04-10]:
      [Thanks for addressing my other comment)
      In section 8: "o 20 octets representing the UTF-8 encoding of the string "Anonymous Sender ", where the space code point has the hexadecimal value 20."
      You would have been safer to say "the US-ASCII encoding of the string" instead of "the UTF-8 encoding". Given the goofiness of non-normalized encodings of characters in UTF-8, I still think it would probably be best to actually specify *all* of the octets to avoid some bonehead typing on a keyboard and getting it wrong:
      "o 20 octets representing the UTF-8 encoding of the string "Anonymous Sender ", the specific octets as follows: 41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20"
      That way you're sure.

    Telechat:

2.2.2 Returning Items

  1. CalDAV Scheduling Extensions to WebDAV (Proposed Standard)
    draft-desruisseaux-caldav-sched-12
    Token: Barry Leiba
    Note: Mike Douglass - douglm@rpi.edu - is the document shepherd.
    Discusses/comments (from ballot draft-desruisseaux-caldav-sched):
    1. Adrian Farrel: Comment [2012-03-15]:
      This is a huge document and it did make me worry that so many pages are needed to describe an *extension*. But I didn't find anything that was superfluous or wordy, so I have no issue with its publication.
      I did expect to see a short piece of text about how implementations of this spec would interact with deployed 4791 implementations. Not withstanding that this document updates 4791 (such that new 4791 implementations are presumably expected to include support for this document), we do have to worry about the deployed base.
      This would probably not take many words.
    2. Stephen Farrell: Comment [2012-03-11]:
      - Thanks for handling Klaas Wierenga's good secdir review so well and quickly!
      - 3.2.2.1 says the server "MUST allow" but later says how the server can return errors if e.g. the client hasn't permission for the change requested. It might be better to say at the top that "The server MUST be able to allow Attendees to:"
      - 3.2.3 says its about HTTP methods, but uses webdav methods as well (e.g. COPY, MOVE) so maybe a reference to rfc 4918 would be useful at the start here? (Or wherever is best to go for those.)
      - I guess this is maybe not too likely but just to check. If a client guesses a UID to try find out who's up to what, 3.2.4.1 says the server SHOULD return the URL if there is a collision. I wondered whether that URL might expose some information, in which case the question is whether such UIDs are easily guessed or not. If such UIDs can be guessable, then maybe say something to the effect that the server might want to not return URLs that might expose details of the events (if such exist) and might want to return an innocuous error. Or better might be to RECOMMNEND that the UIDs (and URLs as well maybe) used for this be hard to guess. Note that the attack here (if it exists) could come from an authenticated client as well as from the Internet. The point here is to check that the UIDs don't allow me to get at information for which I'd get only 403 if I sent a request to the URL. (I guess its a separate question as to whether sending 403 gives away something that a 404 doesn't, but if so, that'd be for another day and draft.)
      - In 7.x sections you say clients MUST NOT include these parameters. Is there a need to say that server MUST NOT accept messages from (bad) clients that do in fact contain these parameters? Might be easy enough to get wrong if the server developer didn't pay any attention to what the client developer might get or do wrong.
    3. Pete Resnick: Comment [2012-03-14]:
      Generally: I think the 2119 language could use a good scrub. I think you use it in places where there is no real option, or there is no real interoperability implication. Please review.
      Section 3.2.8: "Servers MUST reset the "PARTSTAT" property parameter value of all "ATTENDEE" properties, except the one that corresponds to the Organizer, to "NEEDS-ACTION" when the Organizer reschedules an event."
      Don't you mean for all "ATTENDEE" properties *on each affected component*? I wouldn't have complained about this except for the MUST; if it's a requirement, you've got to be clear. If the change is for a recurrence instance that does not include that attendee, PARTSTAT shouldn't be reset, correct? (See section 3.2.6.)

    Telechat:

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. ConEx Concepts and Use Cases (Informational)
    draft-ietf-conex-concepts-uses-04
    Token: Wesley Eddy
    Note: Nandita Dukkipati (nanditad@google.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-conex-concepts-uses):
    1. Ronald Bonica: Discuss [2012-04-10]:
      This may be a DISCUSS-DISCUSS, but I would like to pose the following questions:
      1) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs downstream?. For example, assume that my ISP deploys CONEX. Assume also that a loss-prone link connects my PC to the CPE router in my kitchen. The TCP stack on my PC will report lots of loss. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network?
      2) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs upstream? For example, assume that my ISP deploys CONEX. Assume also that I subscribe to a stream that incurs loss before it hits my ISPs network. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network?
      3) Is the applicability of CONEX restricted to access networks, where it is possible to deploy per-user policers at the distant end of the network from the user?
      4) Can CONEX markings be used as an attack vector?
      5) How will CONEX behave in networks where incoming traffic can be characterized as follows: 90% is streaming UDP over IP multicast 10% is TCP.
      In this example, assume that multicast traffic is responsible for 90% of the congestion and that the multicast receivers send traffic in the reverse direction very infrequently.
      6) How will CONEX work in a transition scenario, when some transport layer stacks are CONEX aware and others are not.
      7) Does CONEX encourage traffic originators to falsify congestion markings?
    2. Ronald Bonica: Comment [2012-04-09]:
      In Section 3.1, please be specific about the policer counting IP-Layer-ConEx-Signals, and not Congestion-Feedback-Signals
    3. Ralph Droms: Comment [2012-04-12]:
      I could use a little help understand the example in section 3.1. Do I have it right that ConEx is used to provide information about congestion in a flow to devices that are not directly experiencing the congestion? In the use case in section 3.1, the congestion policer is placed exactly at the point where the existence of congestion is known. Why is any signaling mechanism needed at all?
      In the first paragraph of section 3.2, how does ConEx specifically encourage the use of scavenger transport protocols, relative to other congestion policing mechanisms?
      Does the second paragraph of section 3.2 suggest that ConEx is used to actively affect traffic management in a way that is not directly related to congestion experienced at the user device? That is, the receiver uses artificially generated congestion signals to cause ConEx marking that affects its received traffic. This use case is fine, except that labeling the receiver->sender signaling as "congestion feedback" is no longer accurate.
    4. Adrian Farrel: Comment [2012-04-06]:
      A fine document that would have been enhanced by a short exposure of the Conex references to live up to the "entry point" claim.
      Classic ASCII-art. Well done!
    5. Stephen Farrell: Comment [2012-04-10]:
      Section 2.4: what (if any) metric is used for rest-of-path and upstream- congestion? Is it volume? If so, or if not, be good to say that.
    6. Brian Haberman: Comment [2012-04-10]:
      In general, this is a good high-level description of what the community should expect in the coming CONEX drafts. I do have a few questions though...
      1. The draft talks about attributing congestion-volume contributions. Shouldn't there be some description of how that would be done? That sounds like a lot of state to maintain when congestion begins to occur.
      2. Conceptually, if a CONEX-aware device in a network sees 10 packets of varying size from a single source and all have these CONEX markings, how do I equate the congestion-volume contribution of that source? Are there assumptions made about the packets' characteristics *in the last RTT* based on the packets seen in the current RTT?
    7. Sean Turner: Discuss [2012-04-11]:
      Interesting that congestion-volume can be measured in one of two ways. If I'm the user in s3.2 (or in the last para of s3.3) will I know which measurement technique was used? Is it up to the operator to decide which one to use?
    8. Sean Turner: Comment [2012-04-11]:
      s2.2: Maybe: "Congestion-volume is a property of traffic, whereas congestion describes *a property of* a link or a path."
      s3.1: 1st para: manage really meanest throttle and management means throttling right ;)
      s3.1: I'm obviously not hard over on either of these: Monitor is much a nicer term than policer, but maybe monitor is overloaded. Also "police traffic" maybe "manage misbehaving".
      s3.3: For give the security guy, but "scavenger transports" refers to ... Vultured TCP (vTCP)?

    Telechat:

  2. Analysis of solution proposals for hosts to learn NAT64 prefix (Informational)
    draft-ietf-behave-nat64-learn-analysis-03
    Token: Wesley Eddy
    Note: Dan Wing (dwing@cisco.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-behave-nat64-learn-analysis):
    1. Stephen Farrell: Comment [2012-04-11]:
      Basically I've a bunch of nits for what seems like a good piece of documentation.
      - There are a good few nitty few English language issues, too many to list now. Better if those were fixed before the RFC editor has to do it.
      - section 3, issue 3 - what does "implementing DNS" mean? Which kinds of DNS node, stub resolver, recursive resolver,...
      - section 4, calling RFC 6144 "The" framework document seems a bit generic, suggest using the full title.
      - section 4, are there cases where a host can't distinguish which of the 6144 scenarios apply that might confuse matters here? Not sure.
      - section 4, is "IPv6 connection" the right term?
      - Why are there no references for a bunch of I-Ds named here? It's ok to add informative references even to expired drafts IMO, (I wonder if others disagree;-)
      - There were changes agreed based on the secdir review. [1] Some of those may overlap with the above (sorry, didn't have time to check properly)
    2. Brian Haberman: Comment [2012-04-11]:
      This is a reasonable complete assessment of the problem space. I only have some comments/suggestions to put forth:
      1. In paragraph 5 of section 1, I would suggest changing "... analyses all known solution proposals known ..." to "... analyzes all proposed solutions known ...".
      2. In section 2, you reference WKP before you define the acronym.
      3. I see several uses of the noun "analyses" used as a verb. I suggest you change those to "analyzes".
      4. Section 4 has an expansion of WKP that is redundant with the expansion done earlier in section 2.
      5. Throughout most of the solution description sub-sections, drafts are called out by name and author(s) without a direct reference. Is this being done simply to avoid having to publish those drafts?
      6. Section 5.3 is an almost duplication of Section 5.2, only the summary is different.
      7. In 5.6.1, the acronyms ASM and SSM are used without expansion or context.
    3. Barry Leiba: Comment [2012-04-11]:
      Just a small thing:
      Section 4, third bullet:
      Is this an attempt to avoid references to "work in progress"? There's no need to avoid it, and I'd rather see the references. Just make them informative, and they won't block this document. If they're dead (or dying) I-Ds that won't be completed, I'd still like to see the names (not just the titles) so I can find them in the archives. The same goes for Brian Carpenter's "referrals" draft, which you refer to later in that section, and other drafts mentioned in other sections.
    4. Robert Sparks: Comment [2012-04-11]:
      Suggesting that elements hard-code an IPv4 address (see section 5.1.1) is perilous, and the draft referenced in that section doesn't seem to support the notion. Why is this suggestion here? Could it be removed?
    5. Sean Turner: Comment [2012-04-12]:
      I'm sure Wes saw that Jouni agreed to some additional text based on Sam Weiler jumping in with Alexey - https://www.ietf.org/mail-archive/web/secdir/current/msg03250.html - so this is just a reminded to include the text.

    Telechat:

  3. IP Flow Information Accounting and Export Benchmarking Methodology (Informational)
    draft-ietf-bmwg-ipflow-meth-09
    Token: Ronald Bonica
    Note: Al Morton (acmorton@att.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-bmwg-ipflow-meth):
    1. Stewart Bryant: Comment [2012-04-12]:
      On the basis of a quick read and complete confidence that Benoit will work with the authors to make the draft perfect.
    2. Benoit Claise: Discuss [2012-04-10]:
      - Introduction: "The most significant performance parameter is the rate at which IP flows are created and expired in the network device's memory and exported to a collector"
      One or multiple different rates? I guess different ones (but reading the document further will tell). So:
      The most significant performance parameters are the rates at which IP flows are created, expired in the network device's memory, and exported to a collector
      However, looking at the terminology section, it seems that you have only one benchmark metric: "Flow Monitoring Throughput".
      BMWG is about black box testing, but it doesn't mean that we don't have 3 different rates. The section 3.1 about "the Flow Monitoring Throughput" proves I'm right. Please improve the text.
      - See email "No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review)" sent to the IPFIX WG.
      - Section 4.3.1: "The (*) in Figure 2 designates the Observation Points in the default configuration. Other DUT Observation Points might be configured depending on the specific measurement needs as follows:
      a. ingress port/ports only
      b. egress port/ports only
      c. both ingress and egress"
      If I refer to figure 2, there is no return traffic to the "traffic sender". Therefore, how could it be b. or c.? Am I dreaming or you had in the past a similar figure that explains that the return traffic could come back to the "traffic sender"?
      Figure 2 should be updated, or a new figure added, because, for egress, the traffic analysis must happen also on the "traffic sender"
      - Section 4.3.3: "The Exporting Process SHOULD be configured with IPFIX [RFC5101] as the protocol to use to format the Flow Export data"
      You want a MUST here, as IP Flow = IPFIX at the IETF.
      Same remark for this sentence in 4.3 The DUT MUST support the Flow monitoring architecture as specified by [RFC5470]. The DUT SHOULD support IPFIX [RFC5101] to allow meaningful results comparison due to the standardized export protocol.
      Same remark for this sentence in 4.4: "However if the Collector is also used to decode the Flow Export data then it SHOULD support IPFIX [RFC5101] for meaningful results"
      However, looking at figure 1, you mention NetFlow, others. So you want to add that additional export mechanism MAY use the same benchmarking mechanism, i.e. NetFlow v9 [RFC3954]
    3. Benoit Claise: Comment [2012-04-10]:
      (24 items)
    4. Ralph Droms: Comment [2012-04-10]:
      A statement like this in section 1 begs for a little more explanation: "The most significant performance parameter is the rate at which IP flows are created and expired in the network device's memory and exported to a collector."
      Is there a reference or some other justification for this statement? Could this statement simply be elided without losing the importance of the document?
      And here are a couple of minor editorial or clarification suggestions:
      In section 3.4.2: "Mainly the Flow Export Rate caused by the test traffic during an [RFC2544] measurement MUST be known and reported."
      s/Mainly/Most importantly/ ??
      In section 4.9.1 and 4.9.2, is it intended that the destination IP address recycles to the address for stream 1 after stream 10000?
    5. Pete Resnick: Comment [2012-04-12]:
      As usual, I find most of the uses of 2119 language in a document of this sort to be bizarre: I don't understand how a statement like "MUST be part of the measurement report" constitutes something "required for interoperation or to limit behavior which has the potential for causing harm", and is not simply trying "to impose a particular method on implementors where the method is not required for interoperability." I'm hard pressed to find any occurrence of 2119 language in this document that is used as 2119 intended.

    Telechat:

  4. Applicability of Access Node Control Mechanism to PON based Broadband Networks (Informational)
    draft-ietf-ancp-pon-02
    Token: Ralph Droms
    Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.
    IPR: Deutsche Telekom AG's Statement about IPR related to draft-ietf-ancp-pon-02
    Discusses/comments (from ballot draft-ietf-ancp-pon):
    1. Adrian Farrel: Comment [2012-04-06]:
      Please don't include citations in the Abstract.
      I found just one use of RFC 2119 langauge in this document. I suggest fixing it to lower case and removing Section 1.
      It would be nice to havesome citations in the Introduction and Terminology sections.
      I was slightly confused as to whether this is intended as an applicablity statement (how you use SNCP for PON) or the definition of the extension of ANCP to PON (see Section 4). It might be nice to harmonize the language across the document.
      You are to be commended for your skill with ASCII-art. I will use your document as evidence that no other graphics tools are needed!
    2. Stephen Farrell: Discuss [2012-04-11]:
      The IETF LC announcement appears to have been missing the IPR declaration, which is RAND with possibly fee, and was only filed on March 27th 3 days before the end of IETF LC. I think this one has to go around the loop again, or am I missing something?
    3. Barry Leiba: Comment [2012-04-11]:
      I second Stephen's DISCUSS: Thomas Haag is both an editor on the document and an inventor on the disclosed patent.
      Also:
      The ToC and the section numbers appear to be confused: Section 9, Security Considerations, on page 31, comes after section 10, Access Loop Configuration. There's another Section 10 following it, and neither of those sections are in the ToC. Also, Section 13, Acknowledgments, is empty... that's OK if it's right, but is there really no one you want to acknowledge here?
    4. Pete Resnick: Comment [2012-04-11]:
      I agree with Adrian's comment: 2119 language is unnecessary in this document and should be removed.
      I also agree with regard to Stephen's DISCUSS; this must be re-last-called with a pointer to the IPR disclosure.
      I must say that I'm of two minds about this document, neither of them good. On the one hand, the document seems to be applying ANCP to a particular technology (in this case PON), and I therefore don't understand why it isn't going for Standards Track. On the other hand, from up here in the nosebleed section of the layers, the entirety of this document looks like it is either all layer 2 stuff or is a big giant walking layer violation. I really don't understand why the IETF is devoting WG time to working on technology like this. I was sorely tempted to simply Abstain on this document. I don't see what it adds to our document series. Perhaps someone can explain.
    5. Sean Turner: Discuss [2012-04-11]:
      1) It's entirely possible this is somewhere in the other ancp specs and I missed it. The draft claims:
      "Fundamental to leveraging the broadcast capability on the PON for multicast delivery is the ability to assign a single encryption key for all PON frames carrying all multicast channels or a key per set of multicast channels that correspond to service packages, or none."
      Is this referring to the key used for IPsec/IKEv2 as required by RFC 6320? How are you distributing the keys to everybody? It seems (to my untrained eye) like stream access in ancp is done through a join request and white/grey/black list checking not based on any kind of key material.
    6. Sean Turner: Comment [2012-04-11]:
      s11: Maybe strike the first used and add protocol after signalling in the following:
      "Here an appropriate mechanism to protect the used signalling needs to be used."
      NEW: "Here an appropriate mechanism to protect the signalling protocol needs to be used."

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. An IANA registry for Level of Assurance (LoA) Profiles (Informational)
    draft-johansson-loa-registry-05
    Token: Sean Turner
    Note: Tim Polk (tim.polk@nist.gov) is the document shepherd.
    Discusses/comments (from ballot draft-johansson-loa-registry):
    1. Adrian Farrel: Comment [2012-04-12]:
      Thanks for addressing my Discuss and Comments
    2. Stephen Farrell: Comment [2012-04-09]:
      What is the expectation for stability of the URI and URL elements of a registration? Should an expert disallow e.g. bit.ly or a blog URL? I think it'd be good to say something here. I don't care what you choose for any of the reasonable choices:-)
    3. Brian Haberman: Discuss [2012-04-11]:
      I agree with Pete's DISCUSSion and am also not a fan of 2119 keywords being used in this document.
      I would like to better understand if the concept of a LoA is consistent across the types of frameworks mentioned in this document. The introduction says that the registry will support LoAs from a variety of frameworks. However, the description of the Context Class in Section 3 talks about XML Schemas compliant with SAML 2.0. Is this registry limited to frameworks compliant with SAML 2.0? If so, this needs to be specified.
    4. Brian Haberman: Comment [2012-04-11]:
      I am not sure why the second paragraph in the Introduction begins and ends with underscores.
      Are there any existing LoAs that should be pre-populated in this table? If so, they should be shown in section 6.
    5. Russ Housley: Discuss [2012-04-09]:
      The Gen-ART Review by David Black on 1-Apr-2012 lead to some discussion and agreement on some document updates. The updates have not appeared yet.
    6. Barry Leiba: Comment [2012-04-09]:
      I agree with Pete's DISCUSS, as it refers to Section 5. I see no problem with using an Informational document to do what Section 4 does -- IANA will set up the registry as stated, and the terms specified here aren't meant to be used beyond this document, so Informational is fine. But Section 5 is telling implementors of *something* what they MUST and MUST NOT do, and Informational doesn't seem right for that.
      The second paragraph of Section 5 leaves me shaking my head. I'd like to see it be more clear about what one MUST NOT infer. It strikes me as a really wishy-washy statement as it is.
      Section 7 is missing something after "An implementor of". (I'd also hyphenate "level-of-assurance URIs", to make it clear that it's a compound modifier.)
      And I agree with Stephen's comment that the definition of "URI" in Section 3 should say something, one way or another, about what expectations do or don't exist on the lifetime of the URI. Also, is it acceptable/expected/to-be-avoided to have multiple URIs registered that define the same LoA profile? Given that the URI is the registry key, it seems important to expand a bit on this stuff here.
    7. Pete Resnick: Discuss [2012-04-07]:
      [I don't feel very strongly about this, so if everyone else is OK with it, I am happy to clear this DISCUSS. But I did think it was worthy of DISCUSSion.]
      If this was simply the creation of a registry, I wouldn't have thought twice about its status as Informational. But section 4 is giving a particular process and policy for additions to the registry and section 5 is attributing semantics for protocol users (both of them using 2119 language just to make the point). Doesn't that mean this should be a BCP since it's defining IETF policy and procedure?
    8. Pete Resnick: Comment [2012-04-07]:
      I am not a fan of using 2119 language in the registration template. You are not giving instructions to implementers on interoperability or damage to the network; this is for registrants and IANA. And in all cases I can find, it is simply unnecessary.
      I suggest: ...
    9. Robert Sparks: Discuss [2012-04-11]:
      Section 5 is confusing (it has drawn comments from several reviewers). Can it be reworded to avoid the confusion that's been expressed? Registries are often used to help implementations/deployments accidentally use the same name for two different purposes. The description here does not seem to consider that part of the motivation for having a registry - in fact, it goes to some length to tell users to expect there to be names in use that aren't listed, and by inference, might collide. Discussing the implications of such a collision may help avoid them.
    10. Robert Sparks: Comment [2012-04-11]:
      I agree with the comments posted about the second paragraph of section 5. If it needs to stay (even in a rewritten form), please consider providing an example of the kind of implied meaning that a user of the registry must not assume.

    Telechat:

  2. IETF meeting attendees' Frequently Asked (travel) Questions (Informational)
    draft-george-travel-faq-05
    Token: Russ Housley
    Discusses/comments (from ballot draft-george-travel-faq):
    1. Ronald Bonica: Comment [2012-04-09]:
      It's not clear to me that this needs to be documented as an RFC. Maybe a FAQ for meeting hosts?
    2. Stewart Bryant: Comment [2012-04-10]:
      re Mass transit:
      It would be good if there was an explicit note on safety
      It would be good if there was a note as to whether the signs include place names in a western character set.
    3. Benoit Claise: Comment [2012-04-10]:
      Section 3. Helpful information: "There are a number of general categories of information listed below. Some of it, such as sections 3.1 and 3.3, is necessary for travel, the rest can be considered nice-to-have."
      If you would change the Table of Content (TOC) to have the current 3.3 as 3.2, then you would have nice order in the TOC, sorting by importance/relevance ... which you could stress in the document. ...
    4. Wesley Eddy: Comment [2012-04-09]:
      This seems more like a nice webpage to me than something that needs to be an RFC.
    5. Stephen Farrell: Comment [2012-04-05]:
      You might note somewhere that meeting specific sites tend to go away, as has happened with ietf75.se which is now something to do with poker (or at least the advert offered there when I looked was).

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. NERD: A Not-so-novel EID to RLOC Database (Experimental)
    draft-lear-lisp-nerd-08
    Token: Brian Haberman
    Discusses/comments (from ballot draft-lear-lisp-nerd):
    1. Ronald Bonica: Comment [2012-04-11]:
      I support Stewart's DISCUSS. The distinction between this document and the other LISP documents, which are also EXPERIMENTAL, is subtle and likely to be lost on the reader.
    2. Stewart Bryant: Discuss [2012-04-11]:
      I am putting a discuss on this because I think that the IESG needs to talk about this draft. I will clear the discuss on the call.
      I think that the document needs some text in the introduction making it clear that the purpose of this draft is to record some early thoughts on this subject by the author. Otherwise the RFC will be too easily confused with the ordinary output of the LISP WG.
      The approach described seems a viable way of running LISP and thus I am not sure why this is not being taken through the WG or as AD sponsored. I understand the history is that this work pre-dated the WG, but there is now a WG.
    3. Stewart Bryant: Comment [2012-04-11]:
      I am surprised that the author did not tackle the database version wrap problem by providing some really large number that could never wrap (128 bits springs to mind). Given the size of the payload, the size of the database header seems unlikely to be an issue.
    4. Stephen Farrell: Comment [2012-04-11]:
      - I think a paragraph putting this into context (as per Eliot's mail) would be very valuable for the reader who might otherwise think this is the "mainstream" experiment.
      - Do you really want to refer to ITU-T x.509 rather than rfc5280 for certificates?
      - I think you could note that key roll-over and key distribution generally are for future study.
      - You could even mention the potential for using DANE if you wanted as a different PKI as another possibility for future study.
      - CMS is widely deployed (all S/MIME clients include it) but you could still say pkcs#7 is more widely supported by libraries and tools.
      - There doesn't seem to be any way to limit an authority to certain EIDs and/or RLOCs, such as is done by SIDR. Might be worth noting?
      - If you need revocation checks as part of signature validation, then you probably ought say that that's not included in the analysis in section 5.
    5. Brian Haberman: Comment [2012-04-10]:
      I agree that this document should be published as a record of one way of doing the LISP mapping. The following commentary is really meant for the IESG and the ISE...
      Given that there does not appear to be any effort to actually implement this specification, does it make sense to publish it as Experimental? It would seem that Informational would be a fine way to document this approach. If I follow some of the arguments that Pete and Ron have made recently, I would even support the publication of this document as Historical, but I am not sure if the ISE can do that.

    Telechat:

3.3.2 Returning Items

  1. (none)

1254 EDT break

1300 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. v4exit (v4exit)
    Token: Ralph

    Telechat:

  2. Network Virtualization Overlays (nvo3)
    Token: Stewart

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. Standards Tree Media Type for text/mizar [IANA #480998] (Michelle Cotton)

    Telechat:

  2. draft-ietf-pwe3-static-pw-status (Stewart Bryant)

    Telechat:

  3. Paul Eggert as new TZ coordinator (Russ Housley)

    Telechat:

7. Agenda Working Group News


Amy: HTTPbis?
Barry: wrong charter sent; best thing is to send version we intended to approve; does it need to go on another telechat; changes not insignificant, not sure whether IESG has seen the correct version
Russ: post correct version, diffs, ask if anyone wants to discuss again
Barry: there is a correct version, I'll sort it out

1356 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-04-12 07:30:04 PDT)

draft-ietf-oauth-v2

  1. Stewart Bryant: Discuss [2012-04-10]:
    It is not clear to me why it is necessary to create the protocol specific
    variant of the RFC5226 Review process described in section 11.1, 11.2, 11.3,
    11.4.
    
    Creating new variants of the IANA process creates confusion, and unless there is
    a good reason specific to this protocol, one of the standard IANA processes
    should be called out.
    
    If the plan is to have a list review followed by an expert review of the list
    discussion, the timetable needs to call out time for the list to do a review and
    then a time for the expert to do their review.
    
  2. Benoit Claise: Comment [2012-04-10]:
    I read: 
       This specification replaces and obsoletes the OAuth 1.0 protocol described
       in RFC 5849.
    
    I've not been familiar with OAuth, and one question that bothered me: Why should
    I implement/upgrade to OAuth 2.0, compared to 1.0? It's not mentioned in the
    draft. I had to search somewhere to find the answer: in the current charter,
    which says:
    
      In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
      was published as an informational document (RFC 5849). The working
      group has since been developing OAuth 2.0, a standards-track version
      that will reflect IETF consensus.  Version 2.0 will consider the
      implementation experience with version 1.0, a discovered security
      vulnerability (session fixation attack), the use cases and
      functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will
      * improve the terminology used,
      * consider broader use cases,
      * embody good security practices,
      * improve interoperability, and
      * provide guidelines for extensibility.
    
    Adding at least the first two sentences (or something similar) + one about the
    "discovered security vulnerability" would make sense, at least to me... Unless
    this specified in a different document (maybe I-D.ietf-oauth-v2-threatmodel?)
  3. Ralph Droms: Comment [2012-04-10]:
    I came to a similar conclusion as Benoit: readers of this
    document would benefit from a one-paragraph summary
    of the reasons for the development of Oauth 2.0.  A summary
    or overview of technical differences would be helpful,
    as well, if it's not too lengthy.
    
    I also agree with Stewart's DISCUSS regarding the adoption
    of modified RFC 5226 review processes rather than reusing
    existing processes.
  4. Wesley Eddy: Comment [2012-04-03]:
    In section 1, right before 1.1 begins, HTTP is called a transport protocol.
    While this tends to happen, it still isn't correct.  It would be better to
    reword the sentence replacing:
    "with any other transport protocol"
    to something
    more like:
    "over any other protocol"
  5. Adrian Farrel: Discuss [2012-04-12]:
    I should like to see a statement along the lines of "OAuth 2.0 is not
    intended to be backward compatible with OAuth 1.0. The protocol versions
    may co-exist in the network and implementations may chhose to support
    both. However, it is the intention of this document that new
    implementation support OAuth 2.0 as specified in this document, and that
    OAuth 1.0 is used only to support existing deployed implementations."
    
    ---
    
    It would be useful to include a concise section titled "Changes from
    OAuth 1.0 (RFC 5849)". This would help implementers moving from 1.0 to
    2.0 (and would help reviewers as well :-)
    
  6. Adrian Farrel: Comment [2012-04-12]:
    Can't Appendix A be folded into Section 12. Perhaps make it 12.1?
  7. Pete Resnick: Comment [2012-04-11]:
    4.3.2 says that the authorization server MUST "validate the resource owner
    password credentials", but it doesn't say exactly how one might do that. For
    example, it doesn't say whether to compare things case-sensitively or (and this
    is the reason it even occurred to me) whether one should be normalizing the
    UTF-8. I'm fine with that being left as an exercise to the reader if this is the
    common practice in security protocols. And UTF-8 doesn't make this special; even
    comparing US-ASCII has it's quirks. The UTF-8 just made it noticable to me.
    
    8: Just confirming that you are OK with the following legal ABNF productions:
    
    type-name and param-name could each be "...---..."
    response-name could be "_____"
    error-code could be "z...---..."
    
    Those all OK productions?
  8. Robert Sparks: Comment [2012-04-11]:
    Please consider the following substitutions for the websites and email lists
    pointed to in section 11.1:
    
    http://www.iesg.org -> http://www.ietf.org/iesg
    
    iesg@iesg.org -> iesg@ietf.org
  9. Sean Turner: Discuss [2012-04-12]:
    At v25, I appreciate that you must have slayed more than your fair share of
    dragons (and some more than once I bet).  I appreciate your efforts.  Just a
    couple of things I'd like to discuss:
    
    0) General: I found the lack of ABNF somewhat disconcerting in that implementers
    would have to hunt through the spec to figure out all the values of a given
    field.  For example grant_type has different values based on the different kind
    of access_token requests - four to be more precise - but there's no ABNF for the
    field.  There are many examples of this.   It would greatly aid implementers if
    a) the ABNF for all fields were included in the draft and b) all the ABNF was
    collected in one place.  I had individual discusses for each field that had
    missing ABNF, but it was getting out of hand so I'm just going to do this one
    general discuss on this topic.
    
    1) General: If I buy your argument in s1.7 that this is a framework and you can
    leave bits needed to fully implement it out, then should this draft not have
    "protocol" in the title or be tweaked to acknowledge it's not complete?  I can
    hear you all groaning now, but it's truth in advertising.  The other RFCs that
    have been oft quoted as frameworks, like PKIX and CMS, that would allow you to
    not pick MTI, like the token format, don't have "protocol" in the name.  Adding
    some like ": Framework" after the title so that it's clear this ain't the hole
    shooting match would, I think, be truth in advertising.  It's just a little
    misleading that the abstract/intro lead you to believe if you implement this
    draft you'll be access these resources but you have to dig in to s1.7 and s7 to
    know that the bits need to actually determine access aren't defined in the
    draft.
    
    2) Figure 1: Because so many of the later sections refer to the not shown
    protocol flow I decided to make it a discuss (though I'm sure more than one
    person would say this is a comment):
    
      s1.2: Figure 1: If the preferred mechanism for the client request
      is to go indirectly through the Authorization Server it would be
      really good to depict that.  You could just add that to Figure 1 or
      add a Figure 2.
    
    Further, shouldn't the out-of-scope bits also be shown too: client registration,
    and the interaction between the authorization and resource servers so we get the
    complete picture?  You can mark them out-of-scope in the figure.
    
    And another thing, the bearer token picture shows client credentials in (C)
    shouldn't this also show them as optional?
    
    3) s1.6/s2.3.1/s3.1: So some might consider this nit-picking but when you say
    "Whenever TLS is required by this specification" do you mean "Whenever this
    specification requires TLS be used"?  MTI doesn't mean mandatory to use, but in
    this case I think you do mean mandatory to use because it ships around cleartext
    passwords.  This also comes up in s2.3.1 and 3.1 where the text indicates:
    
      t/The authorization server MUST require TLS as described in Section
      1.6 when sending requests using password authentication.
    
    I'd just replace require with use in both places.  Note that s3.1.2.1 seems to
    have it right: "require the use of TLS".
    
    4) s1.7: When you say "authorization server capabilities" you're talking about
    the client discovering which token format is supported?  I think the draft needs
    to be clear that without these underdefined things that the protocol can only
    interop with the clients being configured a priori.
    
    5) s1.7: Since you brought it up (and I thank you for being upfront about it)
    and you provided some examples, shouldn't the list of underdefined things be
    completely listed?  That way if somebody wants to profile this for their use
    they know all the bits and pieces they need to write down.
    
    6) s2: The protocol to register the client is out-of-scope but is the directions
    for the client developer in scope?  If so, shouldn't 2119 language be used here:
    
    When registering a client, the client developer:
     - MUST specify the client type…
     - SHOULD provide its client redirection …
     - MUST include any other … 
    
    7) s2.1: How is trust established?
    
    8) s2.2: How unique is the client_id?  Is it just for this server or universally
    unique?  If it's the later how do you guarantee this?  Is there some requirement
    for the length of the string?
    
    9) s2.3.1: Where is this described:
    
     Since this client authentication method involves a password, the
     authorization server MUST protect any endpoint utilizing it against
     brute force attacks.
    
    10) s3.1/s3.1.2/s3.2/etc.: why the MUST NOT here and what happens if a fragment
    is included:
    
      The endpoint URI MUST NOT include a fragment component.
    
    11) s3.1/s3.2: What happens if they are included more than once - is it rejected
    or is the first one accepted?:
    
      Request and response parameters 
      MUST NOT be included more than once.
    
    12) s3.1.2.1: This section made me scratch my head a bit.  In which of the
    scenario's flows is the SHOULD for (i.e., where do you think TLS won't be
    implemented)?  Is it (D) in Figure 3?
    
    13) s3.1.2.1: How does the authorization server warn the resource owner about
    the insecure endpoint?
    
    14) s3.1.2.4/s4.1.2.1:  Under what circumstances wouldn't you inform the
    resource owner of the error (i.e., why isn't that SHOULD a MUST)?
    
    15) s3.1.2.5: Are there any security considerations that would result if the
    client includes third-party scripts?
    
    16) s3.1.2.5: How is this done:
    
     If third-party
     scripts are included, the client MUST ensure that its own scripts
     (used to extract and remove the credentials from the URI) will
     execute first.
    
    17) s4.1.2.1/s4.2.2.1: The errors in these two sections have the same values but
    just slightly different meanings: one refers to authorization codes and the
    other refers to access tokens.  Is it wise to use the same name for the error
    values?  This issue would go away if the error_description was required.
    
    18) s4.1.2/s4.1.2.1/s4.2.2/s4.2.2.1/: Don't you need to say which type of HTTP
    status code is returned e.g., is it always 302 as shown in the exampled?
    
    19) How is the expiry time of the access token provided to the resource server?
    Is this supposed to be documented in the access token documents?
    
    20) the bearer token spec contained character set restrictions on the error,
    error_description, and error_uri:
    
     Values for the "error" and
     "error_description" attributes MUST NOT include characters outside
     the set %x20-21 / %x23-5B / %x5D-7E. Values for the "error_uri"
     attribute MUST conform to the URI-Reference syntax, and thus MUST NOT
     include characters outside the set %x21 / %x23-5B / %x5D-7E.
    
    Do these apply here as well? This might get cleared up with some ABNF.
    
    21) s10.3: Given Richard's point in GEN-ART review on 10.3, I think it might be
    worth adding the text you suggested.
    
    22) s10: About the parameters that require secure transmission/storage: Would a
    compromise be to just list the ones that require secure transmission/storage?
    We often do/require this for protocols (e.g., SNMP, NETCONF).
    
  10. Sean Turner: Comment [2012-04-12]:
    0) s2.1: Assume either you'll rev the draft of Stephen will add the text via an
    RFC editor note:
    
      A clients may be implemented as a distributed set of components, each
      with a different client type and security context (e.g. a distributed
      client with both a confidential server-based component and a public
      browser-based component). If the authorization  server does not
      provide support for such clients, or does not provide guidance with
      regard to their registration, the client SHOULD register each
      component as a separate client. 
    
    1) s1: r/created by passwords/inherent in passwords
    
    2) s1: r/OAuth with any transport protocol other than HTTP is undefined./OAuth
    with any transport protocol other than HTTP is out-of-scope.
    
    3) s1: General: Nice reference to RFC 4949 in s1.8, but that got me to wondering
    whether you should use the term "capability token" as opposed to "access token"
    where the definition of capability token is:
    
     (I) A token (usually an unforgeable data object) that gives the
         bearer or holder the right to access a system resource. Possession
         of the token is accepted by a system as proof that the holder has
         been authorized to access the resource indicated by the token.
    
    4) s1.5: r/Issuing a refresh token is optional/Issuing a refresh token is
    OPTIONAL ?
    
    5) s1.5: r/If the authorization server issues a refresh token, it is included
    when issuing an access token./If the authorization server issues a refresh
    token, it is included when issuing an access token (i.e., step (D) in Figure 1).
    
    6) s1.6: Did you mean that additional transport-layer *security* mechanisms can
    be implemented?
    
    7) ID-nits is coughing on your 2119 paragraph.  Replace ' with " and it ought to
    go away.
    
    8) really we're going to use: application/x-www-form-urlencoded
    
    9) s3.1.2.2: add a period to the end of:prior to utilizing the authorization
    endpoint
    
    10) s4.1.1.1/s4.1.2/s4.2.2/s5.1: SHOULD in the following:
    
     The authorization server should document the size of
     any value it issues
    
    11) s5.2: 1st sentence indicates 400 is the response but in invalid_client it
    says might be a 401.  Should the 1st sentence use 4xx instead to indicate it's
    from the client error set of codes?
    
    12) This might have been settled already: s11.4.1: A GEN-ART comment on the
    bearer token draft might have trigged a necessary change to the OAuth Extension
    Error Registry to allow bearer tokens errors to use the same registry.  Would
    need to add a fourth usage location:  "resource access error response" to be
    able to use this registry for bearer error types.
    
    From Richard's GEN-ART review:
    
    13) On redirects: I think it might help to add somewhere that redirects and
    directs can be accomplished through HTTP redirects or through other
    implementation alternatives.
    
    14) s2.3.1: I think it would help to add something that says this is only used
    with Token Endpoint (3.2) which is limited to POST only.

draft-ietf-oauth-v2-bearer

  1. Wesley Eddy: Comment [2012-04-03]:
    In Section 1, I suggest changing:
    "for use with other transport protocols"
    to something more like:
    "for use over other protocols".
    HTTP is not a transport protocol.
  2. Brian Haberman: Comment [2012-04-02]:
    Section 2.1 states :
    
    Clients SHOULD make authenticated requests with a bearer token using the
    "Authorization" request header field with the "Bearer" HTTP authorization
    scheme.
    
    Is the SHOULD simply to show a preference for the Authorization request approach
    over the methods defined in Sections 2.2 and 2.3?  If so, in what type of
    situation would the Authorization request approach not be used?
  3. Russ Housley: Discuss [2012-04-10]:
      The Gen-ART Review by Alexey Melnikov on 10-Apr-2012 reports that two
      major issues that were raised in an earlier review were not addressed.
      I have added my own thoughts in addition to those provided by Alexey.
    
      First, the "scope" attribute is a space-delimited list of scope values
      indicating the required scope of the access token for accessing the
      requested resource.  In some cases, the "scope" value will be used
      when requesting a new access token with sufficient scope of access to
      make use of the protected resource.  The "scope" attribute MUST NOT
      appear more than once.  The "scope" value is intended for programmatic
      use and is not meant to be displayed to end users.
    
      In response to the previous review by Alexey, the document editor
      provided explanation in email; however, this response was not
      reflected in the subsequent update to the document.
    
      More information about the "scope" attribute is needed, especially
      about the manner that it is used and the possible values.  As this
      attribute is not meant to be displayed to end users, please indicate
      what values are possible and which entity can allocate them.  Is there
      an IANA registry for possible attribute values?  If so, what are the
      rules for assigning a new registry value.
    
      Second, Section 3.1 specifies Error Codes.  Alexey suggested the use
      of an IANA registry for this field.  Apparently there is already a
      registry created by draft-ietf-oauth-v2. However this document does
      not register values defined in this section in that registry.  Please
      explain why the IANA registry is not leveraged by this document.
    
  4. Pete Resnick: Comment [2012-04-11]:
    Mark Nottingham's Applications Area review <http://www.ietf.org/mail-archive/web
    /apps-discuss/current/msg03805.html> has a couple of comments that I think
    deserve further reply:
    
    	* Section 1: Introduction
    
    	The introduction explains oauth, but it doesn't fully explain the
    	relationship of this specification to OAuth 2.0. E.g., can it be
    	used independently from the rest of OAuth? Likewise, the overview
    	(section 1.3) seems more specific to the OAuth specification than
    	this document. As I read it, this mechanism could be used for ANY
    	bearer token, not just one generated through OAuth flows.
    
    	If it is indeed more general, I'd recommend minimising the
    	discussion of OAuth, perhaps even removing it from the document
    	title.
    
    I agree that the title would be better simply as "HTTP Bearer Tokens", and then
    explain in the Abstract and Intro that the motivation and intended use of these
    Bearer Tokens is the OAuth 2.0 specification. A possibly useful side effect of
    this change might be that you can make OAuth 2.0 an informative (as against a
    normative) reference, and that these things could be reused for other purposes
    in the future. Not a huge deal, but I (like Mark) was unconvinced that the
    reference to OAuth in the title was necessary.
    
    	* Section 3 The WWW-Authenticate Response Header Field
    
    	The difference between a realm and a scope is not explained. Are the
    	functionally equivalent, just a single value vs. a list?
    
    Some text, and probably an example, might help explain this a bit better.
    
    One of his comments asked for some additional review. I don't have a personal
    opinion whether this is needed, but perhaps you should pursue this:
    
    	* General
    
    	The draft currently doesn't mention whether Bearer is suitable for
    	use as a proxy authentication scheme. I suspect it *may*; it would
    	be worth discussing this with some proxy implementers to gauge their
    	interest (e.g., Squid).
    
    Finally, there was his major issue. I have not put this in a DISCUSS since, in
    all honesty, I don't fully understand the implications here. I intend to re-post
    to the apps-discuss list to see if we can get a better explanation of what the
    issue is. However, I strongly urge the AD, shepherd, and chairs, as well as the
    authors, to review this concern. If I get more information that makes the issue
    clear to me, I may ask the IESG to discuss:
    
    	* Section 2.3 URI Query Parameter
    
    	This section effectively reserves a URI query parameter for the
    	draft's use. This should not be done lightly, since this would be a
    	precedent for the IETF encroaching upon a server's URIs (done
    	previously in RFC5785, but in a much more limited fashion, as a
    	tactic to prevent further, uncontrolled encroachment).
    
    	Given that the draft already discourages the use of this mechanism,
    	I'd recommend dropping it altogether. If the Working Group wishes it
    	to remain, this issues should be vetted both through the APPS area
    	and the W3C liaison.
    
    	(The same criticism could be leveled at Section 2.2 Form-Encoded
    	Body Parameter, but that at least isn't surfaced in an identifier)
  5. Sean Turner: Discuss [2012-04-12]:
    While editing this I say Mike's responses so I just cut them in to see if we
    can't have one thread going on this draft for my discusses/comments.  I added
    Mike's responses in between <mike> and </mike>
    
    #1 was updated based on input from Julian.
    #9 was updated based Alexey's GEN-ART review.
    #13 is new.
    
    First off, I appreciate that you have likely slayed more than a few dragons
    working on this draft and I appreciate your efforts.  Would just like to clear
    up a few things:
    
    1) I'm hoping the answer to this one is "there's no problem" but I gotta ask and
    maybe the APPs ADs can confirm:  Is there any issue with this specification
    using ABNF from [I-D.ietf-httpbis-p1-messaging] while OAUTH 2.0 uses [RFC5234]?
    
    <mike>
    
    > None that I’m aware of.  Both specs are syntactically well-defined.
    
    </mike>
    
    From Julian: The ABNF from HTTPbis is a superset of RFC 5234 in that it defines
    a list rule for readability. I don't think that this rule is used anymore in the
    bearer spec, so it can just say it's using RFC 5234.
    
    So could can this just reference 5234 for the ABNF?
    
    2) I thought maybe this spec was going to explain how the resource server knows
    that the access token provided hasn't expired, but it didn't.  How's that going
    to happen again?
    
    <mike>
    
    > That’s out of scope for this specification, as the Bearer spec is, by
    > design, token type independent, but in scope for profiles for specific
    > token types such as draft-ietf-oauth-saml2-bearer and
    > draft-jones-oauth-jwt-bearer. In those profiles you’ll find requirements
    > for expiration time assertions in the tokens used.
    
    </mike>
    
    Okay I'll give you a on this one because this isn't really talking about the
    direct interaction between the authorization server and the resource server, but
    just for my own edification where is that exchange defined - is there a draft
    about this interaction?
    
    3) s1: Last para: Okay isn't it step (D) partially addressed too?  The access
    token format returned by the authorization server is defined in this
    specification - right?  Further, in s5.2 there are recommendations for issuance
    of access tokens and that's covered in (D)?
    
    <mike>
    
    > You’re correct that semantic requirements are placed upon the access
    > token communicated in step D. The protocol portion of D is solely within
    > the OAuth Core spec, however, whereas the protocol elements for steps E
    > and F are defined in the Bearer spec. If you think it’s warranted, a
    > sentence something like “This document also imposes requirements upon
    > the access token returned in Step D” could be added at the end of
    > Section 1. Your thoughts?
    
    </mike>
    
    Yeah I think that's worth adding.  Maybe I'm just being pedantic, but I think
    it's better to add this in.
    
    4) s2: What happens if the client uses more than one method?
    
    <mike>
    
    > The spec says “Clients MUST NOT use more than one method to transmit the
    > token in each request.” The behavior when violating a MUST is undefined.
    
    I was wondering if this was maybe an HTTP requirement?
    
    Anyway...often times when you say MUST NOT we'd like to know what happens when
    the implementation doesn't follow the rules and 2119 provides this helpful bit
    of advice:
    
     Document authors should take the time
     to elaborate the security implications of not following
     recommendations or requirements as most implementors will not have
     had the benefit of the experience and discussion that produced the
     specification.
    
    5) s2.1: b64token is pretty forgiving in that it allows a whole bunch of
    different encodings.  Is one the MTI?
    
    > None are MTI, again because this spec is, by design, token type
    > independent. Specific profiles using this spec will define particular
    > MTI encodings for particular token types. 
    
    Okay this confuses me.  Are you saying there's going to be different types of
    bearer tokens?  Is there going to be a registry for them?
    
    6) s3: What happens if realm, scope, and the error attributes appear more than
    once?
    
    <mike>
    
    > The spec says “The realm attribute MUST NOT appear more than once”, “The
    > scope attribute MUST NOT appear more than once”, and “…includes one of
    > the following error codes in the response”. The behavior when violating
    > these normative requirements is undefined.
    
    </mike>
    
    see #4.
    
    7) s3: Under what circumstances wouldn't you want an error returned?
    
    <mike>
    
    > The spec says “If the request lacks any authentication information (i.e.
    > the client was unaware authentication is necessary or attempted using an
    > unsupported authentication method), the resource server SHOULD NOT
    > include an error code or other error information.” This restriction is
    > in place to avoid leaking potentially useful information to an attacker. 
    
    </mike>
    
    Should'a caught that - consider this one closed.
    
    8) s3.1: Trying to figure out the error requirements.  Are the shoulds in the
    three codes telling you that you could send other 4** codes than those listed or
    that if you can come up with a good reason you don't need to send one at all?
    
    <mike>
    
    > The SHOULDs are there because while the use of 400, 401, and 403 for
    > those cases are highly recommended, the working group found, in
    > consultation with Mark Nottingham and other experts, that sometimes in
    > practice different error codes are used under these same or similar
    > circumstances. For instance, some implementations may be returning 401
    > (Unauthorized) for insufficient scope conditions, rather than 403
    > (Forbidden). 
    
    </mike>
    
    Consider this one closed.
    
    9) s3.1: I thought scope was defined in draft-ietf-oauth-v2 shouldn't you just
    point there and then you can pick up the character set restrictions from the
    ABNF there?
    
    <mike>
    
    > The scope syntax is also defined in Section 3.3 of OAuth Core, but for
    >use in different, but semantically related, protocol contexts. (Core
    >uses it as a request parameter. Bearer uses it as an error response
    >parameter.) Yes, the syntax restrictions for scope values could be
    > included by reference to Core, rather than included in Bearer, but given
    > that other parameter syntax restrictions are also needed for error
    > response parameters (see your next question), it seemed simpler for
    > developers to include all of them in once place in the Bearer spec. 
    
    </mike>
    
    and then I added:
    
    Additionally: 
    
    If the "scope" attribute defined in draft-ietf-oauth-v2-bearer-18.txt is the
    same as in draft-ietf-oauth-v2-25.txt, then draft-ietf-oauth-v2-bearer-18.txt
    must reference Section 3.3 of draft-ietf-oauth-v2.
    
    Secondly, the definitions are a bit out of sync and the one in draft-ietf-
    oauth-v2 seems a bit better.
    
    This actually answers my question about who can allocate values. (See my
    Gen-Art review and associated threads on the OAUTH mailing list.)
    
    If the value contains multiple space-delimited strings, their order does not
    matter, and each string adds an additional access range to the requested scope.
    
    I think this is quite valuable addition.
    
    Suggested updated text for draft-ietf-oauth-v2-bearer:.
    
      The "scope" attribute is defined in Section 3.3 of [draft-ietf-oauth-v2].
      The "scope" attribute is a space-delimited list of case sensitive scope
      values
      indicating the required scope of the access token for accessing the
      requested resource. "scope" values are implementation defined and
      there is no centralized registry for them, allowed values are defined
      by the authorization server. Note that the order of "scope" values
      is not significant. In some cases, the "scope" value will be used
      when requesting a new access token with sufficient scope of access to
      utilize the protected resource. Use of the "scope" attribute is
      OPTIONAL. The "scope" attribute MUST NOT appear more than once. The
      "scope" value is intended for programmatic use and is not meant to be
      displayed to end users. 
    
    10) s3.1: Shouldn't the character set restrictions on error, error_description,
    and error_uri be in draft-ietf-oauth-v2?
    
    <mike>
    
    > Yes, I believe these same restrictions should be present in the Core
    > spec. Unfortunately, they aren’t at present, I think in part, because
    > the “error”, “error_description”, and “error_uri” errors there are used
    > in a different protocol contexts where it’s easier to use non-ASCII
    > characters. (The Core spec specifies UTF-8 encoding for
    > error_description, for instance, rather than limiting it to the ASCII
    > subset in the Bearer spec.) I believe it would increase consistency and
    > reduce confusion for developers if you filed an issue against the Core
    > spec requesting that the same character set restrictions be applied to
    > these related error values in Core as were already agreed to (after MUCH
    > working group discussion) for Bearer. (ASCII is sufficient because the
    > error_description is “to provide developers a human-readable explanation
    > that is not meant to be displayed to end users”.) 
    
    </mike>
    
    I already did fie a discuss about this on the base spec :)
    
    11) s5.2: TLS is required and that's great, but what I think this means is that
    if the redirection endpoint (defined in 3.1.2 of draft-ietf-oauth-v2) decides
    not to implement TLS (it's only a SHOULD) then this token format can't be used
    in that scenario?  I think this needs to be very clearly documented - then again
    maybe I'm totally wrong.
    
    <mike>
    
    > I’m not sure how to be much more clear than the current statement that
    > “The authorization server MUST implement TLS”. 
    
    </mike>
    
    Fair enough, let me come up with some words.
    
    12) s5.2: Do the two "issue" recommendations apply generally to all types of
    tokens?  If they do, then shouldn't they be moved to the base spec?
    
    <mike>
    
    > (I assume you meant 5.3 here.) No, they do not. For instance,
    > proof-of-possession tokens (which require an additional protocol
    > exchange in general to use) have very different security
    > characteristics. The security considerations for each class of token can
    > be different (although sometimes admittedly overlapping).
    
    > BTW, for security considerations of the Core spec, reviewers should also
    > be aware of the intentionally much more comprehensive
    > draft-ietf-oauth-v2-threatmodel document, which has completed working
    > group last call. 
    
    </mike>
    
    I did mean s5.3.  Consider this one closed based on the idea that the
    explanation to #5 all makes sense.
    
    13) This one most like a DISCUSS-DISCUSS (i.e., nothing for the authors to do at
    this time):  Do we really want to define an HTTP authentication mechanism
    herein?  Isn't the http* WG going to work on that?
    
  6. Sean Turner: Comment [2012-04-12]:
    1) Figure 1: I've made some suggested changes to Figure 1 in draft-ietf-oauth-v2
    and you should keep the two aligned.
    
    <mike>
    
    > Sure. Please send these to me and keep me apprised about whether they
    > are adopted in the Core spec. 
    
    </mike>
    
    I'll make to.  There might no be any changes in the end.
    
    2) s2.1: r/Resource servers MUST support this method./Resource servers compliant
    with this specification MUST support this method.
    
    <mike>
    
    > OK
    
    </mike>
    
    3) s2.2/s2.3: r/Resource servers MAY support this method./Resource servers
    compliant with specification MAY support this method.
    
    <mike>
    
    > OK
    
    </mike>
    
    4) s5.2: You could point to the cookies document for security considerations on
    cookies: RFC 6265.
    
    <mike> 
    
    >cookies: RFC 6265.
    > OK in principle. Specific proposed text would be welcomed. 
    
    </mike>
    
    Fair enough.  How about adding the following to the end of the para that starts
    ... Cookies are typically:
    
      See [RFC6265] for security considerations about cookies (aka HTTP state
    management).
    
    5) s5.2: Peter's gone, but his document (RFC 6125) lives on.  It discusses
    matching server Ids.  Might add a reference to that draft in this draft.
    
    <mike>
    
    > There’s history on this one. :-/ Per the history entries, a previous
    > reference to RFC 2818 was changed to RFC 6125 in draft 14 at the request
    > of Stephen Farrell. Then, in draft 17, the 6125 reference was removed in
    > favor of text referencing 2818 supplied as a result of the Gen-ART
    > review by Alexey Melnikov (and reviewed by Stephen). I’d love to do
    > whatever the right thing is here, but if a change is to be made, I’d
    > request that the new text be reviewed by all of Stephen, Alexey, and
    > Peter Saint-Andre before being changed in the draft.
    
    </mike>
    
    I'll take the action to coordinate text with the five of us.  Should see a
    message shortly.
    
    6) s5.3: r/SSL/TLS ;)
    
    <mike>
    
    > Sure 
    
    </mike>

draft-ietf-hokey-rfc5296bis

  1. Ralph Droms: Discuss [2012-04-12]:
    This DISCUSS is raised against the publication status of the
    document.  No action is required from the authors until it is
    resolved.  I expect to clear this DISCUSS after the telechat
    discussion of the document.
    
    The relationship between this document and RFC 5296, and the exact
    status of RFC 5296 should be clarified before this document is
    published.  I've given an editorial example of the nature of the
    problem in my COMMENTs.  
    
    Adrian has entered a COMMENT that I will expand to a DISCUSS to
    request a couple of sentences explaining why this document was
    written to accompany the summary of changes Adrian requested.  This
    issue might be addressed by the RFC Editor note.
    
  2. Ralph Droms: Comment [2012-04-12]:
    There are at least two instances of references to "new EAP codes" or
    "New EAP Packets" that should be updated to reflect that the
    EAP-Initiate and EAP-Finish Packet Codes are already defined, and add
    a citation to the appropriate IANA registry.
    
    This typo (missing " " in the line containing "cryptosuite") was
    copied forward from RFC 5296 (best read with fixed-width font):
    
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Code      |  Identifier   |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |R|B|L| Reserved|             SEQ               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 1 or more TVs or TLVs                         ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | cryptosuite  |        Authentication Tag                     ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3. Adrian Farrel: Comment [2012-04-06]:
    I have no objection to thepublication of this document.
    
    Please supply a short section "Changes from RFC 5296"
    
    Pleasecheck that all Erratahave also been applied to this revision
    http://www.rfc-editor.org/errata_search.php?rfc=5296
  4. Barry Leiba: Discuss [2012-04-09]:
    This document says there are no IANA actions.
    
    RFC 5296 did a number of things in the EAP registry
    - Registered Packet Codes 5 and 6
    - Created the Message Types table
    - Created the Initiate and Finish Attributes table
    - Created the Re-authentication Cryptosuites table
    
    It also registered two values in the USRK Key Labels registry.
    Shouldn't the
    references in those IANA registries now all be changed to point to this new RFC,
    instead of the now-obsolete 5296?
    
  5. Pete Resnick: Comment [2012-04-11]:
    Pedantic nits:
    
    4.1 (and similarly in 4.3 and 4.6):
    
       The rIK Label is the 8-bit ASCII string:
    
    What is an "8-bit ASCII string"? Do you mean "the following string of US-ASCII
    characters encoded in octets" or something like that?
    
    5.2 (also 5.3.2 and 5.3.3):
    
          a 16-bit sequence number
    
    Any issue about byte order or sign/unsigned with these?
    
    5.3.3:
    
             The value
             field is a 32-bit field and contains the lifetime of the [...] in
             seconds.
             
    Again, any issue with byte order or sign/unsigned with these?
  6. Sean Turner: Comment [2012-04-10]:
    Nice job folks.  Only nits:
    
    s3.2: r/5shows/5 shows
    s4.1: 4th bullet r/must/MUST ?

draft-ietf-ippm-rt-loss

  1. Benoit Claise: Discuss [2012-04-11]:
    I have some clarifying questions for the point 1. and 2. that will determine
    whether these are real DISCUSS's or not.
    A 10 minutes discussion with Al would
    help a lot
    
    1.
    Looking at the list of documents at http://datatracker.ietf.org/wg/ippm/, I
    see that the first set of metrics where IP or IPPM related
    http://tools.ietf.org/html/rfc2680 ->  A One-way Packet Loss Metric for IPPM
    http://tools.ietf.org/html/rfc2681 -> A Round-trip Delay Metric for IPPM
    ...
    
    then I see that that IP (or IPPM to be more precise) is not included any longer
    http://datatracker.ietf.org/doc/rfc4737/ -> Packet Reordering Metrics
    http://datatracker.ietf.org/doc/rfc5560/ -> A One-Way Packet Duplication Metric
    
    I would be interested to understand the change, and it might help with my next
    question.
    When reading this draft, I was wondering:
    1. if this metric is only
    for packets? I'm pretty sure it's the case, specifically, when I see the section
    3.4 that speaks about packet loss.
    So should the title be "Round Trip Packet
    Loss Metrics", or even, to be fully in line with RFC2680, ""Round Trip Packet
    Loss Metrics for IPPM"?
    2. if the metric was not only for packet, but for
    application data (the abstract mentions "Many user applications"), then what
    would be the link with PMOL, RFC6390? Note: I believe that TWAMP doesn't deal
    with application data, but could be easily extended. A solution such as the
    Cisco IP SLA (http://tools.ietf.org/html/draft-cisco-sla-protocol-00) could do
    it.
    
    2.
    Section 4.3
          o  the Dst sent a Type-P packet back to the Src as
    immediately as possible, and
    
    Why is this even useful to mention "as immediately as possible"?
    I mean: if you
    have to use round-trip packet loss (instead of one-way packet loss), it's
    because you're not able to install a "responder" application on the target
    device. Therefore, you have no control at all on that target device. And you are
    forced to use a protocol such as ICMP. So, why is this even useful to say "as
    immediately as possible" if you have no control on that target device?
    The
    sentence "the Dst sent a Type-P packet back to the Src as immediately as
    possible" only makes sense in the case of one-way delay metric.
    
    I have the same issue with your new proposed text (discussed with Adrian)
      o  the Dst sent a Type-P packet back to the Src as quickly as
          possible (certainly less than Tmax, and fast enough for the
          intended purpose), and
    
    I have the same issue with your new proposed text in section 4.4 (discussed with
    Adrian, AFAIK)
       We add the following guidance regarding the responder process
    to
       "send a Type-P packet back to the Src as quickly as possible".
    
       A response that was not generated within Tmax is inadequate for any
       realistic test, and the Src will discard such responses.  A responder
       that serves typical round-trip loss testing (which is relevant to
       higher-layer application performance) SHOULD produce a response in 1
       second or less.  A responder that is unable to satisfy this
       requirement SHOULD log the fact so that an operator can adjust the
       load and priorities as necessary.  Analysis of responder time-stamps
       [RFC5357] that finds responses are not generated in a timely fashion
       SHOULD result in operator notification, and the operator SHOULD
       suspend tests to the responder since it may be overloaded.
       Additional measurement considerations are described in Section 8,
       below.
    
    For example, "A responder that is unable to satisfy this requirement SHOULD log
    the fact so that an operator can adjust the load and priorities as necessary. "
    I've been doing IP SLA measurements for years with Cisco boxes, and I would only
    use round trip delay and loss metrics when I can't touch the target device. And
    here you're asking the target device to do a task for you in case of round trip
    loss...
    Note: the default configuration for SLA measurement is to put a
    responder on the target device, and to measure in both directions the one way
    delay, the loss, and jitter.
    
    Or maybe, the metric in this draft can only be used with the TWAMP protocol,
    which I believe requires some configuration on the target device?
    However, it
    appears it's not a requirement as TWAMP is mentioned as one example in
    
        8.  Measurement Considerations and Calibration
    
       Prior to conducting this measurement, the participating hosts MUST be
       configured to send and receive test packets of the chosen Type-P.
       Standard measurement protocols are capable of this task [RFC5357],
       but any reliable method is sufficient.
    
    Next question: why do mention "but any reliable method is sufficient.". It means
    that that metric can't be used with ICMP?
    
    Anyway, it needs some clarifications.
    
    3.
    In section 4.3
    
       Following the precedent of[RFC2681], we make the simplifying
       assertion:
    
       Type-P-Round-trip-Loss(Src->Dst) = Type-P-Round-trip-Loss(Dst->Src)
    
    While I could agree that Type-P-Round-trip(Src->Dst) = Type-P-Round-
    trip(Dst->Src), at some conditions, I disagree with the assertion that if you
    loose 50% packets, you can conclude that you lost 25% in each direction.
    
  2. Benoit Claise: Comment [2012-04-11]:
    - section 1, introduction
    s/round-trip loss/ round-trip packet loss
    
    Note: I'm sure there are multiple instances of this one.
    
    - section 1, introduction
       Also, the
       specifications of the One-way Loss metric [RFC2680] and the Round-
       trip Delay metric [RFC2681] are frequently referenced and modified to
       match the round-trip circumstances addressed here
    
    s/One-way Loss metric [RFC2680]/A One-way Packet Loss Metric for IPPM [RFC2680]
    s/Round-trip Delay metric [RFC2681] /A Round-trip Delay Metric for IPPM
    [RFC2681]
    
    - Section 3.3.  Metric Definition
    
       This section is specific to each metric.
    
    What does this section add? Maybe it's part of a template?
    
    - Section 4.1.  Name: Type-P-Round-trip-Loss
    I double checked this name with RFC
    2680
    1. It should be Type-P-Round-trip-Packet-Loss throughout the document
    2. I
    opened this errata on RFC 2680 http://www.rfc-
    editor.org/errata_search.php?eid=3186
    
    - Section 7
      As discussed above, packet reordering is always a possibility.  In
       addition to the severe delay variation that usually accompanies it,
       reordering on the Src->Dst path will cause a mis-alignment of
       sequence numbers applied at the reflector when compared to the sender
       numbers.  Measurement implementations SHOULD address this possible
       outcome.
    
    "reflector" is a term specific to TWAMP, and not found in RFC2330
  3. Adrian Farrel: Comment [2012-04-06]:
    Other comments coming from Dan Frost's review
    
    > 1. Although it's probably obvious to most readers, it would be helpful
    > to provide a brief informal definition of "round-trip loss" early in
    > the introduction.  A mention of the venerable "ping" procedure would
    > also not be amiss.
    
    > 2. Most of the text seems to assume an "active" or test-based
    > measurement approach, but Section 9.2 refers to passive measurement.
    > It would be helpful to discuss the applicability of the latter
    > approach.
    
    > Nits:
    >
    > 1. The phrase "as immediately as possible" that appears a couple of
    > times in the text (and that seems to originate in RFC 5357) is a bit
    > unfortunate.  "Immediately" or "as quickly as possible" are better.
    >
    > 2. Section 5.4, second paragraph: s/affects/effects/
    >
    > 3. Section 8, second paragraph: s/Two key features ... is described/
    >  Two key features ... are described/
    >
    > 4. Section 9.3, first paragraph:
    > OLD
    >  it is possible to change the processing of the packets (e.g.
    >  increasing or decreasing delay) that may distort the measured
    >  performance.
    > NEW
    >  it is possible to change the processing of the packets (e.g.
    >  increasing or decreasing delay) in a way that may distort the
    >  measured performance.
    > END
  4. Stephen Farrell: Comment [2012-04-11]:
    I had a discuss to check that Sandy Murphy's secdir review 
    comments had been taken  into account. I asked and wasn't 
    told they hadn't been, so I've cleared.
  5. Russ Housley: Discuss [2012-04-11]:
    
      In the last paragraph of Section 5, the document says: " ... (or other
      process, the details of which MUST be specified if used)."
    
      Specified how? Is an RFC required?  Is a standards-track RFC required?
      This document already mentions the lack of an IANA registry.  Will an
      IANA registry be needed to help locate these specifications.
    
  6. Russ Housley: Comment [2012-04-11]:
      Please consider the comments raised by the Gen-ART Review by
      Ben Campbell on 10-Apr-2012.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07340.html

draft-ietf-avtcore-feedback-supression-rtp

  1. Wesley Eddy: Discuss [2012-04-10]:
    (1)
    
    "screwed up" in Section 6.5 is not very technical; please say what is really
    wrong (loss, corruption, reordering, etc.)
    
    (2)
    
    Section 1 lists a number of *BUGS* in implementations as the motivations for
    this.  It starts by saying that a use case for this is people not implementing
    RFC 4585 dithering correctly, then says that another use case is that there are
    other poor designs causing implosions of FIRs.
    
    It seems silly to write this new RFC adding a new mechanism rather than just
    applying pressure to fix those implementations; it would be useful to discuss
    why that isn't the right answer, since receivers have to implement reactions to
    this new report anyways, they should be fixing their bugs.  I think this is an
    especially relevant question given the lack of implementation noted in the
    writeup and Pete's ballot.
    
  2. Stephen Farrell: Comment [2012-04-10]:
    Just checking: there's no way that a 3rd party loss report
    could cause a flood of re-transmitted data (that hadn't
    actually been lost) to be (re-)sent to a target is there? If
    so, that might constitute a new DoS vector. Its not clearly
    the case that that can't happen. If it could, then 
    that'd be another reason to authenticate these messages.
    
    nits/typos:
    
    - s/to pose/pose/
    - s/message,which/message, which/
    - maybe s/the distribution source will not/if the
      distribution source will not/ in 6.1? (and some
      missing spaces there too)o
    - I like "badly screwed up" as a descriptive phrase!
  3. Brian Haberman: Comment [2012-04-04]:
    I just have a few questions on this draft:
    
    1. The Protocol Overview section states : "Intermediaries in the network that
    receive a RTCP TPLR SHOULD NOT send their own additional Third-Party Loss Report
    messages for the same packet sequence numbers."  Why is this not a MUST?  Is it
    simply to handle intermediate devices that don't support this function?  If
    there is another scenario where a device may send a TPLR that overlaps, it would
    be good to spell that out.
    
    2. There are two places (Sections 4.1 & 4.2) where the length field in the
    feedback message is set to "2+1*N".  Should I interpret that to mean the value
    is really just N+2?  Or is there something I am missing?
  4. Pete Resnick: Comment [2012-04-08]:
    The document writeup says, "There are not yet any reported implementations." Are
    you really saying that for a protocol that appears to have serious congestion
    control effects, nobody has written a line of code yet? Has there been any
    testing of this at all? Are there any planned implementations (perhaps by more
    than one independent implementer)? If not, perhaps this should be published as
    Experimental first.
  5. Sean Turner: Comment [2012-04-11]:
    Had the same question Stephen had.

draft-ietf-pwe3-pw-typed-wc-fec

  1. Adrian Farrel: Comment [2012-04-12]:
    Thanks for a well-written document.
  2. Stephen Farrell: Comment [2012-04-10]:
    I'm not sure if there are really no new security
    considerations here, but the difference may be relatively
    minor, (given how I understand these protocols are used, i.e.
    without any cryptographic authentication;-).  
    
    Anyway, my questions:
    
    Which of the RFCs referred to in section 5 calls out that
    sending a spoofed wildcard message will have a bigger
    impact for lower cost for an attacker?  
    
    Could it also be the case that an attacker able to inject one
    of these needs less information about the network to cause
    the same amount of damage compared to an attacker who could
    not send a wildcard message?
  3. Sean Turner: Comment [2012-04-09]:
    ONly a nit:
    
    S2: R bit: r/Must/MUST

draft-ietf-avtcore-ecn-for-rtp

  1. Stewart Bryant: Comment [2012-04-10]:
    Given that this
    
    1) This is of interest to 3GPP
    2) MPLS-TP seems to be a popular choice in Mobile wireless backhaul.
    3) Most service provider core networks use MPLS
    
    Should there not be a reference to RFC5129, and a note that ECN needs to be
    propagated from the tunnel to the payload?
    
    I am not sure how common MPLS ECN is, but it is not mentioned anywhere in the
    MPLS-TP specifications.
  2. Adrian Farrel: Comment [2012-04-12]:
    I don't object to the publication of this document, but it does bother
    me how much effort, time, and pages go into describing a protocol
    extension that no-one is apparently bothered to implement. What is the
    value of a standards track RFC in this case? How can we know whether the
    document or the protocol are right?
  3. Stephen Farrell: Comment [2012-04-08]:
    I've a couple of general comments and some nits. The former:
    
    - 55 pages to discuss two bits? something wrong there;-)
    
    - last para of section 3 (before 3.1), but a general question: you say ECN
    is set before congestion results in packet drops but I thought that was
    the point of PCN (the WG) which is just finishing. Are these things all
    sensible together? I assume a receiver/sender here can be within a PCN
    "domain" or whatever's the right term. Does all the ECN logic here work
    if the bits are actually set by a PCN conformant node?
    
    - Section 11: I don't get this sentence: "Secure RTP (SRTP) [RFC3711] does
    satisfy the requirement to protect this mechanism despite only providing
    authentication if a entity is within the security context or not." What's
    it mean? 
    
    nits:
    
    - 2nd last para of section 3, maybe s/differences will/differences/
    since you've presumably now figured it out?
    
    - p12, 2nd last para typo: s/mechanism/mechamisms/ in 2nd sentence. the
    leap-of-faith and ICE-based methods could do with references maybe
    
    - 3.3, 1st sentence seems odd, isn't it a tautology? 
    
    - last para on p13, is that a 2119 MUST? looks like one
     
    - s/the are/they are/ on p36
    
    - section 11 s/inferring/interfering/ in 3rd last para, and
  4. Brian Haberman: Comment [2012-04-09]:
    I am also curious how this approach will interact with a PCN-conformant node (as
    asked by Stephen).
  5. Barry Leiba: Comment [2012-04-11]:
    Some non-blocking comments -- though I would *really* like to see the IANA
    Considerations comment addressed.
    
    ---
    Section 3:
       ECN support is more important for RTP sessions than, for instance, is
       the case for TCP.  This is because the impact of packet loss in real-
       time audio-visual media flows is highly visible to users.  Effective
       ECN support for RTP flows running over UDP will allow real-time
       audio-visual applications to respond to the onset of congestion
    
    I'm not clear about what the first sentence is comparing, because RTP doesn't
    compare to TCP.  Do you mean that ECN support is more important for RTP sessions
    over UDP than for RTP sessions over TCP?  I don't think so.  Do you mean that
    it's more important for RTP sessions than for *other applications over TCP*?  I
    think that's it.  But then what does TCP have to do with it?  It seems that the
    point is that RTP is more sensitive to congestion issues that other applications
    are, regardless of the underlying transport protocol.  In any case, please
    clarify that sentence.
    
    ---
    Section 3.1:
    Do we really need 2119 language in the requirements?  I rather
    think that requirements would generate 2119 language in the protocol.
    
    ---
    Section 9:
    You explain that the situation with existing APIs is such that it
    makes "this specification difficult to implement portably."  And that's all you
    say.  Any words of wisdom here?  Advice to implementors about how to handle the
    situation?
    
    ---
    Section 10.1:
       Following the guidelines in [RFC4566], the IANA is requested to
       register one new SDP attribute:
    
    I see a lot of SDP Parameters registries and tables, and it's not at all clear
    to me which one this gets registered in.  Maybe it's clear to IANA, and maybe
    this is fine, but maybe also it should be made clearer here.  Can you give the
    exact name of the registry and the table within the registry, to avoid mistakes?
    
    In general, the different subsections of Section 10 are inconsistent in how (and
    how specifically) they name the registries and tables you intend to update.  I
    like the way 10.6 does it -- no chance for confusion at all there.
  6. Pete Resnick: Comment [2012-04-11]:
    3.1: I don't understand what the 2119 words add. These are requirements for the
    protocol designers, not requirements for the protocol implementers.
    
    6.1:
    
          qdtext         = %x20-21 / %x23-7E / %x80-FF
                           ; any 8-bit ASCII except <">
    
    That makes me worried. You do not provide an escaping mechanism such that
    someone could put a quote in their quoted text. You do not specify the
    interpretation of the stuff from 0x80 through 0xFF (UTF-8? ISO-8859-1?
    uninterpreted octet?), and worse you call it "8-bit ASCII" which does not have a
    clear meaning. You also leave out 0x7F (not mentioned in the comment), and I
    have a guess as to why (it's not printable), but you don't say why. I understand
    you want this to be extensible, but I don't think the above is fully baked.
    Perhaps explain what you want to allow and I can recommend some alternatives.
    
    10.1:
    
       This attribute defines the ability to negotiate the use of ECT (ECN
       capable transport) for RTP flows running over UDP/IP.  This attribute
       should be put in the SDP offer if the offering party wishes to
       receive an ECT flow.  The answering party should include the
       attribute in the answer if it wish to receive an ECT flow.  If the
       answerer does not include the attribute then ECT MUST be disabled in
       both directions.
    
    I don't think it's a good idea to put protocol instructions into the IANA
    template. These are all already documented earlier in this document. Just put a
    pointer to [This document, section 6.1] and skip the last 3 sentences above. You
    don't want people trying to implement from the registry.

draft-ietf-tcpm-3517bis

  1. Ronald Bonica: Comment [2012-04-09]:
    Please run this document through the NIT checker before publication.
  2. Stewart Bryant: Comment [2012-04-10]:
    It would be helpful to those searching for information if the abstract noted
    that this document revised RFC 3517
  3. Benoit Claise: Comment [2012-04-12]:
    I have no objection to the publication of this document.
    
    One comment from Chris LILJENSTOLPE, part of the OPS-Directorate review.
    I wish
    the authors had selected some other state variable name other than DupAck for
    the multiple SACK counter.  While it is well described in the draft, on first
    read it is really not a Duplicate ACK counter, but a multiple SACK counter
    (number of SACKs between covering ACKs).  While useful, it would have been more
    intuitive to call it MultSack or some such.  I do not propose editing the draft
    just for this purpose, but if another version of the draft is required, it may
    make the digestion of the material a little easier.
    
    I leave up to you to act on his feedback.
    
    Regards, Benoit.
  4. Adrian Farrel: Comment [2012-04-06]:
    I have no objection to the publication of this document.Just a couple of nits.
    
    ---
    
    Isn't [PF01] rather old to be cited as "evidence that hosts are not
    using the SACK information when making retransmission and congestion
    control decisions"?
    
    I guess this was good evidence when 3517 was first written, but maybe a
    different form of words is called for now? Perhapswe don't even need
    the evidence to motivte this work since it is now established.
    
    ---
    
    Section 1
    
       A
       summary of the changes between this document and [RFC3517] can be
       found in Section 9.
    
    Pardon my pedantry, but the changes are between 3517 and this document.
  5. Stephen Farrell: Comment [2012-04-10]:
    "Pipe" definition says "The algorithm" is often 
    referred to as the pipe alg. That's a little unclear, maybe
    better to say "The algorithm defined here...." and if
    that is the case, to also put that in the abstract
    and intro just to make it easier for someone who does
    call it that to find the RFC.
  6. Brian Haberman: Comment [2012-04-03]:
    Section 7 talks about the effectiveness of this approach when paired with TCP
    Reno, but I do not see any discussion of possible interactions with other TCP
    congestion control algorithms.  Has this re-transmission algorithm been tested
    with other congestion control algorithms?
  7. Russ Housley: Comment [2012-04-09]:
      The Gen-ART Review by Ben Campbell on 4-Apr-2012 suggests some
      improvements.  Please consider them.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07319.html
  8. Barry Leiba: Comment [2012-04-02]:
    This seems a good, clear document.  Thanks for a thought-out Security
    Considerations section, as well.
    
    I have one question, as a non-expert on this topic:
    All four functions in
    section 4 are "SHOULD implement."  Can a meaningful implementation really be
    done if NONE of them are included?  If so, fine.  If not, maybe a few more words
    in the first paragraph would be useful, explaining under what conditions it's
    important to include them or makes sense to leave them out.
  9. Martin Stiemerling: Comment [2012-04-02]:
    An editorial:
    It it is relative short document, but recents RFCs seems all to
    have a table of contents, which is missing in this draft.

draft-ietf-dhc-dhcpv6-reconfigure-rebind

  1. Adrian Farrel: Comment [2012-04-08]:
    I have no objection to the publication of this document, but I
    have a few comments that either reperesent my failure to grasp what
    you are doing, or would make useful improvements to the document.
    
    ---
    
    I would prefer that Section 3 did not include the format of the 
    Reconfigure Message option. Rather than "update" the option with a
    full replacement, isn't it enough to say that msg-type may now 
    additionally take the value 6 to indicate Rebind?
    
    ---
    
    Section 4
    
       The server MUST include a Reconfigure Message option (as defined in
       Section 3) to select whether the client responds with a Renew
       message, a Rebind message or an Information-Request message.
    
    Include in what?
    
    ---
    
    Section 4 is headed "Server Behavior"
    
       The Reconfigure message causes the client to initiate a Renew/Reply,
       a Rebind/Reply message exchange or an Information-request/Reply
       message exchange.  
    
    Seems to be describing the client behavior. At least give a forward 
    pointer to Section 5.
       
    ---   
    
    Section 4
    
                          The server interprets the receipt of a Renew, a
       Rebind or an Information-request message (whichever was specified in
       the original Reconfigure message) from the client as satisfying the
       Reconfigure message request.
    
    Presumably, only if threceived message matches the msg-tpe in the 
    Reconfigure Message option? What if there is a mismatch? can the 
    mismatch be caused by a race?
    
    ---
    
    Section 5
    
    How is a legacy client going to handle a Reconfigure Message option 
    with msg-type set to Rebind? Presumably it is going to run some 3315
    logic to drop or nack the message as "msg-type unknown, unexpected,
    or unsupported".
    
    I believe you should mention this as it impacts on server behavior.
  2. Stephen Farrell: Discuss [2012-04-08]:
    
    Since I know squat about DHCPv6 these may be cleared up 
    really quickly:
    
    - Section 7 calls out a clear vulnerability and suggests use of the AUTH
    option from RFC 3315. I'm told that nobody ever uses the v4 equivalent
    functionality, is that the same for v6? If so, it would then seem
    that we have a vulnerability with no practical mitigation which
    would seem like a bad thing. I'd hope to see at least an honest 
    recognition of that, if its in fact the case.
    
    - I don't see why the dhc-secure-dhcpv6 is non-normative since its
    one of two possible ways to do a thing.
    
    - Should one of AUTH from 3315 or dhc-secure-dhcpv6 be mandatory
    to implement? If not, why not?
    
  3. Stephen Farrell: Comment [2012-04-08]:
    - 1st sentence of abstract seems odd, v. hard to read anyway and that's
    not so good usually. How does the "Reconfigure Message" extend "the
    Reconfigure Message"? (That's how I read it anyway)
  4. Russ Housley: Comment [2012-04-11]:
      Please consider the editorial suggestions in the Gen-ART Review by
      Francis Dupont on 7-Apr-2012.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07344.html
  5. Robert Sparks: Comment [2012-04-11]:
    The introduction motivates some of these changes with a use case of a network
    administrator who is preparing to shut down a dhcpv6 server causing clients to
    move to a different server. Is it possible (if so, how easy would it be) to
    misconfigure the servers involved to cause them to enter a rebind war with each
    other? If this is something a client might experience, is there guidance to give
    the client implementations on how to react when it happens?
  6. Sean Turner: Comment [2012-04-10]:
    1) I support Stephen's discuss.
    
    2) s4: I was having some issues tracking exactly which paragraphs in 19.1-19.3
    were being updated/replaced.   Could you do the old/new so we knew which
    paragraphs were being replaced.  Ex (assuming I got this bit right):
    
    4.1 Updates to Section 19.1
    
    OLD:
    
     A server sends a Reconfigure message to cause a client to initiate
     immediately a Renew/Reply or Information-request/Reply message
     exchange with the server.
    
    NEW:
    
     The server MUST include a Reconfigure Message option (as defined in
     Section 3) to select whether the client responds with a Renew
     message, a Rebind message or an Information-Request message.
    
    3) s5: If the text replaces the text in s19.4 of RFC 3315 could you just say
    that? r/This section updates specific text in/This section replaces

draft-ietf-softwire-gateway-init-ds-lite

  1. Wesley Eddy: Comment [2012-04-11]:
    Support Stephen's DISCUSS
  2. Adrian Farrel: Comment [2012-04-08]:
    I have no objection to the publication of this document, but I note that
    the Security Considerations section is flimsy. Surely there are security
    issues with how the mapping table at the AFTR is built. Although that is
    a "local matter" inplementers and deployers need to be aware that this
    feature must be secured.
  3. Stephen Farrell: Discuss [2012-04-10]:
    1. The security considerations section here appears to be way
    too brief. I'd like to have known when it is safe to use
    this, and especially when it is not safe, e.g. if the g/w is
    on the customer premises and the CID is an IPv4 address,
    could the customer (hacking the g/w) hijack someone else's
    (guessable) CID? (That may or may not be a real threat,
    but I found it hard-to-impossible to figure out based on 
    this draft.)
    
    2. RFC 6275's security considerations don't appear to apply
    to this in an obvious way, which part(s) of RFC6275 section
    15 are relevant here? Same question applies to RFC 5213.
    
    3. TS29060 seems like a normative reference, why is it not?
    Is version 9.1.0 the right version to reference? (there seem
    to be many) That document (on page 143 of 155) has a two line
    section 12 on security which is just a reference to something
    else. I don't know what is meant by referring to this from
    section 9 here.
    
  4. Stephen Farrell: Comment [2012-04-10]:
    - p7, what does "must have a proper understanding" mean?
    
    - p8, CE, PE and ECMP are not expanded (and maybe need a
    reference/definition, particularly ECMP)
    
    - Please consider the points raised in Tobias Gondrom's
    secdir review. [1]
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03029.html
  5. Brian Haberman: Comment [2012-04-04]:
    Section 6 lists a set of abbreviations to describe the type of IPv4 addresses
    being used in a deployment.  I understand all the possibilities, except for "nm"
    (described as non-meaningful/dummy).  This that just a diplomatic way of
    describing a network deployment that is squatting on someone's public IPv4
    address space?
  6. Barry Leiba: Comment [2012-04-11]:
    I second Stephen's DISCUSS and Pete's comment.
  7. Pete Resnick: Comment [2012-04-07]:
    There is only one use of 2119 language, and I'm not convinced it's necessary:
    
       o  The softwire between the Gateway and the AFTR MAY be created at
          system startup time OR dynamically established on-demand.
    
    Is this a protocol option that one or both sides needs to be aware of? That is,
    does the Gateway or the AFTR need to prepare itself for on-demand establishment,
    or to be prepared that on-demand might not be available? I suspect you can
    change it to "may" or "can" and delete the reference to 2119.
  8. Sean Turner: Comment [2012-04-12]:
    I support Stephen's discuss.

draft-jivsov-openpgp-ecc

  1. Stephen Farrell: Comment [2012-04-11]:
    Please also consider the (very recent) comments from the
    secdir review. [1]
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03228.html
    
    My previous comments are below but from a quick glance 
    seem to be addressed in -12.
    
    Two substantive comments and a bunch of nits, but this is
    good stuff.
    
    #1 The write up talks about running code which is great. Did the
    implementers of both take a look at this version of the document?
    I don't recall any last-minute changes but no harm checking.
    
    #2 I was left wondering about pkcs#1.5 and bleichenbacher's TLS attack
    and other side-channel attacks, e.g. based on timing or power. Those
    are not mentioned here, but are not things about which every coder
    would know. Is there a good document covering such side-channels
    against PGP, and/or ECC that could be added to section 13? (I'd bet
    there is, doesn't need to be an RFC.) I think that'd be a good
    addition.  If there's no good document at least some mention of side
    channels as a security consideration would be good.
    
    Nits:
    
    - 1st para of section 5 reads as if the ECDH variant here is not
    interoperable with 6090, is that the case or not? If not (as I hope)
    then fixing that would be good.
    
    - the 2119 language at the end of section 6 is odd, better to say you
    MUST NOT use another format if there's any doubt that any recipient
    doesn't support the new format.
    
    - Does the 2119 lanaguage in section 7 mean that implementations MUST
    support all of sha-256, sha-384 and sha-512? I've no problem with that
    but making it clear would be better for interop.  Section 12 sort of
    says otherwise but its a little confusing.  Maybe add a forward
    reference to section 12 from 7? (Is the section 13 forward reference
    there correct?)
    
    - start of p7 s/respecfully/respectively/ nice typo:-) same typo
    elsewhere as well
    
    - the pesudocode on p7 would be better as a figure so it can be
    referenced.
    
    - "the" is missing in various places, I skipped over a bunch until it
    got to me;-) that was in section 10: s/applying KDF/applying the KDF/ 
    
    - section 11 could confuse a coder as to whether the truncated form or
    usual encoding of the OIDs is used in the protocol. Making that
    clearer would be good, e.g., by saying that the non-truncated form is
    never used in this protocol (but would be found in e.g., x.509 certs
    for keys concerned).
    
    - The reference to TripleDES in section 13 can I guess be deleted and
    probably refers to earlier text that's no longer present.
  2. Russ Housley: Comment [2012-04-09]:
      Thanks for addressing issues raised in the Gen-ART Review by
      Christer Holmberg on 19-Mar-2012.
    
      I suggest an update to the Abstract:
    
       This document defines an Elliptic Curve Cryptography extension to
       the OpenPGP public key format and specifies three Elliptic Curves
       that enjoy broad support by other standards, including standards
       published by the US National Institute of Standards and Technology.
       The document specifies the conventions for interoperability between
       compliant OpenPGP implementations that make use of this extension
       and these Elliptic Curves.
  3. Barry Leiba: Comment [2012-04-11]:
    Some very minor comments [UPDATE: adequately addressed in -12]:
    
    Section 2:
       Any implementation MAY adhere to the format and methods specified
       in this document, in which case such an implementation is called a
       compliant application.
    
    That seems a bit of a silly use of 2119 language.  I think what you really mean
    is this:
       Any implementation that adheres to the format and methods specified
    in this document is called a compliant application.
    
    The sentence after that seems silly as well: the normative language here only
    applies to applications that want it to apply to them.  We don't lock people up
    if they don't comply with our specs.  It's a small point, and I completely don't
    mind if you ignore me here, but I suggest removing the sentence.
  4. Pete Resnick: Comment [2012-04-10]:
    [Thanks for address my other comment)
    
    In section 8:
    
       o    20 octets representing the UTF-8 encoding of the string
            "Anonymous Sender     ", where the space code point has the
            hexadecimal value 20.
    
    You would have been safer to say "the US-ASCII encoding of the string" instead
    of "the UTF-8 encoding". Given the goofiness of non-normalized encodings of
    characters in UTF-8, I still think it would probably be best to actually specify
    *all* of the octets to avoid some bonehead typing on a keyboard and getting it
    wrong:
    
       o    20 octets representing the UTF-8 encoding of the string
            "Anonymous Sender     ", the specific octets as follows:
    
            41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20
    
    That way you're sure.

draft-desruisseaux-caldav-sched

  1. Adrian Farrel: Comment [2012-03-15]:
    This is a huge document and it did make me worry that so many pages are needed
    to describe an *extension*. But I didn't find anything that was superfluous or
    wordy, so I have no issue with its publication.
    
    ---
    
    I did expect to see a short piece of text about how implementations of this spec
    would interact with deployed 4791 implementations. Not withstanding that this
    document updates 4791 (such that new 4791 implementations are presumably
    expected to include support for this document), we do have to worry about the
    deployed base.
    
    This would probably not take many words.
  2. Stephen Farrell: Comment [2012-03-11]:
    - Thanks for handling Klaas Wierenga's good secdir review so well and
    quickly!
    
    - 3.2.2.1 says the server "MUST allow" but later says how the server
    can return errors if e.g. the client hasn't permission for the change
    requested. It might be better to say at the top that "The server MUST
    be able to allow Attendees to:"
    
    - 3.2.3 says its about HTTP methods, but uses webdav methods as well
    (e.g. COPY, MOVE) so maybe a reference to rfc 4918 would be useful at
    the start here?  (Or wherever is best to go for those.)
    
    - I guess this is maybe not too likely but just to check. If a client
    guesses a UID to try find out who's up to what, 3.2.4.1 says the
    server SHOULD return the URL if there is a collision. I wondered
    whether that URL might expose some information, in which case the
    question is whether such UIDs are easily guessed or not.  If such
    UIDs can be guessable, then maybe say something to the effect that
    the server might want to not return URLs that might expose details of
    the events (if such exist) and might want to return an innocuous
    error. Or better might be to RECOMMNEND that the UIDs (and URLs as
    well maybe) used for this be hard to guess. Note that the attack here
    (if it exists) could come from an authenticated client as well as
    from the Internet.  The point here is to check that the UIDs don't
    allow me to get at information for which I'd get only 403 if I sent a
    request to the URL. (I guess its a separate question as to whether
    sending 403 gives away something that a 404 doesn't, but if so,
    that'd be for another day and draft.)
    
    - In 7.x sections you say clients MUST NOT include these parameters.
    Is there a need to say that server MUST NOT accept messages from
    (bad) clients that do in fact contain these parameters? Might be easy
    enough to get wrong if the server developer didn't pay any attention
    to what the client developer might get or do wrong.
  3. Pete Resnick: Comment [2012-03-14]:
    Generally: I think the 2119 language could use a good scrub. I think you use it
    in places where there is no real option, or there is no real interoperability
    implication. Please review.
    
    Section 3.2.8:
    
       Servers MUST reset the "PARTSTAT" property parameter value of all
       "ATTENDEE" properties, except the one that corresponds to the
       Organizer, to "NEEDS-ACTION" when the Organizer reschedules an event.
    
    Don't you mean for all "ATTENDEE" properties *on each affected component*? I
    wouldn't have complained about this except for the MUST; if it's a requirement,
    you've got to be clear. If the change is for a recurrence instance that does not
    include that attendee, PARTSTAT shouldn't be reset, correct? (See section
    3.2.6.)

draft-ietf-conex-concepts-uses

  1. Ronald Bonica: Discuss [2012-04-10]:
    This may be a DISCUSS-DISCUSS, but I would like to pose the following questions:
    
    1) Can CONEX distinguish between congestion that occurs on the local network and
    congestion that occurs downstream?. For example, assume that my ISP deploys
    CONEX. Assume also that a loss-prone link connects my PC to the CPE router in my
    kitchen. The TCP stack on my PC will report lots of loss. My ISP will detect
    this and when it congests, it will penalize me even further, even though I am
    not contributing to loss on the ISP's network?
    
    2)  Can CONEX distinguish between congestion that occurs on the local network
    and congestion that occurs upstream? For example, assume that my ISP deploys
    CONEX. Assume also that I subscribe to a stream that incurs loss before it hits
    my ISPs network.  My ISP will detect this and when it congests, it will penalize
    me even further, even though I am not contributing to loss on the ISP's network?
    
    3) Is the applicability of CONEX restricted to access networks, where it is
    possible to deploy per-user policers at the distant end of the network from the
    user?
    
    4) Can CONEX markings be used as an attack vector?
    
    5) How will CONEX behave in networks where incoming traffic can be characterized
    as follows: 
         90% is streaming UDP over IP multicast 
        10% is TCP.
    
        In this example, assume that multicast traffic is responsible for 90% of the
    congestion and that the multicast receivers send traffic in the reverse
    direction very infrequently.
    
    6) How will CONEX work in a transition scenario, when some transport layer
    stacks are CONEX aware and others are not.
    
    7) Does CONEX encourage traffic originators to falsify congestion markings?
    
  2. Ronald Bonica: Comment [2012-04-09]:
    In Section 3.1, please be specific about the policer counting IP-Layer-ConEx-
    Signals, and not Congestion-Feedback-Signals
  3. Ralph Droms: Comment [2012-04-12]:
    I could use a little help understand the example in section 3.1.  Do I
    have it right that ConEx is used to provide information about
    congestion in a flow to devices that are not directly experiencing the
    congestion?  In the use case in section 3.1, the congestion policer is
    placed exactly at the point where the existence of congestion is
    known.  Why is any signaling mechanism needed at all?
    
    In the first paragraph of section 3.2, how does ConEx specifically
    encourage the use of scavenger transport protocols, relative to other
    congestion policing mechanisms?
    
    Does the second paragraph of section 3.2 suggest that ConEx is used to
    actively affect traffic management in a way that is not directly
    related to congestion experienced at the user device?  That is, the
    receiver uses artificially generated congestion signals to cause ConEx
    marking that affects its received traffic.  This use case is fine,
    except that labeling the receiver->sender signaling as "congestion
    feedback" is no longer accurate.
  4. Adrian Farrel: Comment [2012-04-06]:
    A fine document that would have been enhanced by a short exposure of the
    Conex references to live up to the "entry point" claim.
    
    ---
    
    Classic ASCII-art. Well done!
  5. Stephen Farrell: Comment [2012-04-10]:
    Section 2.4: what (if any) metric is used for
    rest-of-path and upstream- congestion? Is it volume?
    If so, or if not, be good to say that.
  6. Brian Haberman: Comment [2012-04-10]:
    In general, this is a good high-level description of what the community should
    expect in the coming CONEX drafts.  I do have a few questions though...
    
    1. The draft talks about attributing congestion-volume contributions.  Shouldn't
    there be some description of how that would be done?  That sounds like a lot of
    state to maintain when congestion begins to occur.
    
    2. Conceptually, if a CONEX-aware device in a network sees 10 packets of varying
    size from a single source and all have these CONEX markings, how do I equate the
    congestion-volume contribution of that source?  Are there assumptions made about
    the packets' characteristics *in the last RTT* based on the packets seen in the
    current RTT?
  7. Sean Turner: Discuss [2012-04-11]:
    Interesting that congestion-volume can be measured in one of two ways.  If I'm
    the user in s3.2 (or in the last para of s3.3) will I know which measurement
    technique was used?  Is it up to the operator to decide which one to use?
    
  8. Sean Turner: Comment [2012-04-11]:
    s2.2: Maybe:
    
       Congestion-volume is a
       property of traffic, whereas congestion describes *a property of*
       a link or a path.
    
    s3.1: 1st para: manage really meanest throttle and management means throttling
    right ;)
    
    s3.1: I'm obviously not hard over on either of these: Monitor is much a nicer
    term than policer, but maybe monitor is overloaded.  Also "police traffic" maybe
    "manage misbehaving".
    
    s3.3: For give the security guy, but "scavenger transports" refers to ...
    Vultured TCP (vTCP)?

draft-ietf-behave-nat64-learn-analysis

  1. Stephen Farrell: Comment [2012-04-11]:
    Basically I've a bunch of nits for what seems like a good piece
    of documentation.
    
    - There are a good few nitty few English language issues, too many to list
    now. Better if those were fixed before the RFC editor has to do it.
    
    - section 3, issue 3 - what does "implementing DNS" mean? Which kinds of
    DNS node, stub resolver, recursive resolver,...
    
    - section 4, calling RFC 6144 "The" framework document seems a bit
    generic, suggest using the full title.
    
    - section 4, are there cases where a host can't distinguish which of the
    6144 scenarios apply that might confuse matters here? Not sure.
    
    - section 4, is "IPv6 connection" the right term?
    
    - Why are there no references for a bunch of I-Ds named here?  Its ok to
    add informative references even to expired drafts IMO, (I wonder if
    others disagree;-)
    
    - There were changes agreed based on the secdir review. [1] Some of those
    may overlap with the above (sorry, didn't have time to check properly)
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03233.html
  2. Brian Haberman: Comment [2012-04-11]:
    This is a reasonable complete assessment of the problem space.  I only have some
    comments/suggestions to put forth:
    
    1. In paragraph 5 of section 1, I would suggest changing "... analyses all known
    solution proposals known ..." to "... analyzes all proposed solutions known
    ...".
    
    2. In section 2, you reference WKP before you define the acronym.
    
    3. I see several uses of the noun "analyses" used as a verb.  I suggest you
    change those to "analyzes".
    
    4. Section 4 has an expansion of WKP that is redundant with the expansion done
    earlier in section 2.
    
    5. Throughout most of the solution description sub-sections, drafts are called
    out by name and author(s) without a direct reference.  Is this being done simply
    to avoid having to publish those drafts?
    
    6. Section 5.3 is an almost duplication of Section 5.2, only the summary is
    different.
    
    7. In 5.6.1, the acronyms ASM and SSM are used without expansion or context.
  3. Barry Leiba: Comment [2012-04-11]:
    Just a small thing:
    
    Section 4, third bullet:
    Is this an attempt to avoid references to "work in
    progress"?  There's no need to avoid it, and I'd rather see the references.
    Just make them informative, and they won't block this document.  If they're dead
    (or dying) I-Ds that won't be completed, I'd still like to see the names (not
    just the titles) so I can find them in the archives.  The same goes for Brian
    Carpenter's "referrals" draft, which you refer to later in that section, and
    other drafts mentioned in other sections.
  4. Robert Sparks: Comment [2012-04-11]:
    Suggesting that elements hard-code an IPv4 address (see section 5.1.1) is
    perilous, and the draft referenced in that section doesn't seem to support the
    notion. Why is this suggestion here? Could it be removed?
  5. Sean Turner: Comment [2012-04-12]:
    I'm sure Wes saw that Jouni agreed to some additional text based on Sam Weiler
    jumping in with Alexey - https://www.ietf.org/mail-
    archive/web/secdir/current/msg03250.html - so this is just a reminded to include
    the text.

draft-ietf-bmwg-ipflow-meth

  1. Stewart Bryant: Comment [2012-04-12]:
    On the basis of a quick read and complete confidence that Benoit will work with
    the authors to make the draft perfect.
  2. Benoit Claise: Discuss [2012-04-10]:
     - Introduction
        The most significant performance parameter is the rate at which IP
        flows are created and expired in the network device's memory and
        exported to a collector
    
    One or multiple different rates? I guess different ones (but reading the
    document further will tell). So:
        The most significant performance parameters
    are the rates at which IP
        flows are created, expired in the network device's
    memory, and
        exported to a collector
    However, looking at the terminology
    section, it seems that you have only one benchmark metric: "Flow Monitoring
    Throughput".
    BMWG is about black box testing, but it doesn't mean that we don't
    have 3 different rates. The section 3.1 about "the Flow Monitoring Throughput"
    proves I'm right. Please improve the text.
    
    - See email "No active/inactive timeout definitions in any IPFIX RFCs? Idle
    versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review)"
    sent to the IPFIX WG.
    
    - Section 4.3.1
       The (*) in Figure 2 designates the Observation Points in the default
       configuration. Other DUT Observation Points might be configured
       depending on the specific measurement needs as follows:
    
       a. ingress port/ports only
       b. egress port/ports only
       c. both ingress and egress
    
    If I refer to figure 2, there is no return traffic to the "traffic sender".
    Therefore, how could it be b. or c.?
    Am I dreaming or you had in the past a
    similar figure that explains that the return traffic could come back to the
    "traffic sender"?
    Figure 2 should be updated, or a new figure added, because,
    for egress, the traffic analysis must happen also on the "traffic sender"
    
    - Section 4.3.3
      The Exporting Process SHOULD be configured with IPFIX
    [RFC5101] as
       the protocol to use to format the Flow Export data
    You want a
    MUST here, as IP Flow = IPFIX at the IETF.
    Same remark for this sentence in 4.3
    The DUT MUST support the Flow monitoring architecture as specified by
    [RFC5470]. The DUT SHOULD support IPFIX [RFC5101] to allow meaningful
       results
    comparison due to the standardized export protocol.
    Same remark for this
    sentence in 4.4
       However if the Collector is also used to decode the Flow
    Export data
       then it SHOULD support IPFIX [RFC5101] for meaningful results
    However, looking at figure 1, you mention NetFlow, others. So you want to add
    that additional export mechanism MAY use the same benchmarking mechanism, i.e.
    NetFlow v9 [RFC3954]
    
  3. Benoit Claise: Comment [2012-04-10]:
    - Introduction
        Monitoring of IP flows (Flow monitoring) is defined in the
        Architecture for IP Flow Information Export [RFC5470] and related
        IPFIX documents.
    
    Which documents? Do we expect the BMWG community to know about the relevant
    IPFIX documents. Please refer to "them"
    
    - Abstract mentions
    
       This document provides a methodology and framework for quantifying
       the performance impact of monitoring of IP flows on a network device
       and export of this information to a collector. It identifies the rate
       at which the IP flows are created, expired, and successfully exported
       as a new performance metric in combination with traditional
       throughput. The metric is only applicable to the devices compliant
       with the Architecture for IP Flow Information Export [RFC5470].
    
    However, the introduction mentions:
       This document provides a methodology for measuring Flow
        monitoring performance so that network operators have a framework
        for measurements of impact on the network and network equipment.
    
    So if this document covers both "impact on the network and network equipment",
    it should be clearly mentioned in the abstract.
    Maybe this is what you mean by
    "export of this information to a collector", but it can be understood in
    different ways: impact on the Exporter, and/or Collector, and/or network.
    
    -
        A more
        complete understanding of the stress points of a particular device
        can be attained using this internal information and the tester MAY 
        choose to gather this information during the measurement iterations. 
    
    replace "device" by "DUT"
    
    -
    
    2.1 Existing Terminology -> I would refer to RFC5101 instead of RFC5470 when
    possible.
    Because RFC5101 will be updated by RFC5101bis. And one important
    change in RFC5101bis will be the new "Flow" definition, which will be removed
    "IP". RFC5470 will most likely not have a bis version.
    
    - 2.2.5 Flow Export Rate
          
       Definition:
          The number of Cache entries that expire from the Cache (as defined
          by the Flow Expiration term) and are exported to the Collector
          within a measurement time interval. There SHOULD NOT be any export
          filtering, so that all the expired cache entries are exported. If
          there is export filtering and it can't be disabled, this needs to
          be noted.
    
    If you use to use RFC2119 terms in the definition, be consistent: replace "this
    needs to
          be noted. " by this MUST be noted".
    
    - 3.2 Device Applicability
    
       The Flow monitoring performance metric is applicable to network
       devices that implement [RFC5470] architecture.
    
    Replace the end with something similar to: "that implement
    RFC5101 and RFC5102, according to [RFC5470] architecture."
    After reading the entire draft, I see the sentence I was looking in section 4.3
       The DUT MUST support the Flow monitoring architecture as specified by
       [RFC5470]. The DUT SHOULD support IPFIX [RFC5101] to allow meaningful
       results comparison due to the standardized export protocol.
    You should have something similar in section 3.2
    
    - NetFlow is mentioned. At least refer to RFC3954.
    
    - "The Cache
       entries are expired from the Cache depending on the Cache
       configuration (ie, the Active and Inactive Timeouts, number of Cache
       entries and the Cache Size)"
    The cache entries is not a configuration parameter.
    
    -  The DUT's export interface (connecting the Collector) MUST NOT be
       used for forwarding the test traffic but only for the Flow Export
       data containing the Flow Records. In all measurements, the export
       interface MUST have enough bandwidth to transmit Flow Export data
       without congestion. In other words, the export interface MUST NOT be
       a bottleneck during the measurement.
    
    I guess that the "the collector (interface) MUST NOT be a bottleneck during the
    measurement".
    Exactly like you wrote for the traffic receiver " The traffic
    receiver MUST have sufficient resources to measure all
       test traffic
    transferred successfully by the DUT."
    After reading section 4.4, I see this
    sentence:
      The Collector MUST be capable of capturing the export packets sent
    from the DUT at the full rate without losing any of them.
    This is a source of
    confusion for me in this draft. It seems that the information is fragmented
    throughout the draft... Therefore, the reading flow is sometimes not easy...
    
    - what is the difference between "Any such feature configuration MUST be part of
    the measurement
       report." and "All configurations MUST be fully documented."
    Should the latter say "All configurations MUST be fully documented in the
    measurement report"?
    
    -    The DUT configuration and any existing Cache MUST be erased before
       application of any new configuration for the currently executed
       measurement.
    
    replace Cache by Cache entries?
    
    - Section 4.3.2
       The Cache Size available to the DUT MUST be known and taken into
       account when designing the measurement as specified in section 5.
    
    What about Metering Process features that increase the cache size. Is this
    allowed? Should this be documented in the measurement report? Or should the
    cache size be set up to its maximum before starting the measurement?
    
    - Section 4.3.2
      The configuration of the Metering Process MUST be recorded.
    -> MUST be included in the measurement report?
    
    - Section 4.3.3
       The templates used by the tested implementations SHOULD
       be analysed and reported as part of the measurement report. Ideally
       only tests with same templates layout should be compared.
    "template layout" = Template Record in RFC5101.
    Please add to the terminology and use the term.
    
    - Section 4.3.3
       Only benchmarks with the
       same transport layer protocol should be compared.
    should -> SHOULD
    
    - Section 4.3.4.
    For all the examples such as the following, please include the
    IPFIX Information Element.
          Flow Keys:
                   Source IP address
    Destination IP address
                   MPLS label (for MPLS traffic type only)
    Transport layer source port
                   Transport layer destination port
    IP protocol number (IPv6 next header)
                   IP type of service (IPv6
    traffic class)
    Rational:
        - what does the MPLS label mean? In IPFIX IANA, we
    report mplsTopLabelStackSection, which is a combination of "The Label, Exp, and
    S fields".  Note: clarify this as well in the section 4.3.6
        - packet
    counters, byte counters: we have multiple IEs for those. Which one should the
    DUT chose?
        - IP addresses: IPv4 and/or IPv6?
    
    - 4.6 Frame Formats
    
       Flow monitoring itself is not dependent in any way on the media used
       on the input and output ports. Any media can be used as supported by
       the DUT and the test equipment.
    
    What about the export interface?
    
    - section 4.8
        The used packet size SHOULD be part of the measurement
       report
    Why not a MUST?
    
    - section 5.1
    I read multiple times the following sentences, and still could not
    understand the link between the first two.
         The number of unique Flow Keys
    sets that the traffic
          generator (sender) provides should be multiple times
    larger than
          the Cache Size. This ensures that the existing Cache entries
    are
          never updated before Flow Expiration and Flow Export. The Cache
    Size MUST be known in order to define the measurement
          circumstances
    properly.
    
    - Section 7 Flow Monitoring Accuracy
    Don't you have to say a few words about the
    accuracy of DUT that also does forwarding, i.e. the traffic analysis at the
    "traffic receiver" in figure 1 must also check that no packets were lost in the
    case of ingress monitoring. Note: there is also the case of egress monitoring.
    Interestingly, bidirectional is mentioned in the "Appendix A: Recommended Report
    Format", but not a single time in the draft.
    
    - Appendix A:
        would be great to mention which entries are SHOULD and MUST
    Note: not sure why it's an appendix, as there is normative text referring to
    each entries
    
    - Appendix A
        could be very helpful to poll the IPFIX-MIB
    (http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, currently in RFC-
    editor queue) and IPFIX-CONF (http://tools.ietf.org/html/draft-ietf-ipfix-
    configuration-model-10, currently in RFC-editor queue) as MAY in the measurement
    report.
    Note: [IPFIX-CONF] is almost ready, simply waiting for PSAMP-MIB. I
    believe it makes sense to wait for this RFC.
    
    - Appendix B.
    Not sure whether the use of "SHOULD" in the appendix is
    appropriate. To be checked.
    
    - Appendix B.6 Tests With Bidirectional Traffic
    Not sure why this is an appendix. The recommended report mentions
     Traffic Direction                 unidirectional, bidirectional
      Direction                         ingress, egress, both
    ... and the bidirectionality is only mentioned in the appendix?
    
    -  Section 5.2
       Traffic Generation
          The traffic generator needs to increment the Flow Keys values with
          each sent packet. This way each packet represents one Cache entry
          in the DUT Cache.
    
    Here is a comment I made to you years ago. You will find surprises if you
    increment the IP addresses by one in your generator, as opposed to random
    traffic, as the hash function are not optimized for incremental IP addresses.
    You should say a few words about this.
  4. Ralph Droms: Comment [2012-04-10]:
    A statement like this in section 1 begs for a little more explanation:
    
        The most significant performance parameter is the rate at which IP 
        flows are created and expired in the network device's memory and 
        exported to a collector.
    
    Is there a reference or some other justification for this statement?
    Could this statement simply be elided without losing the importance of
    the document?
    
    And here are a couple of minor editorial or clarification suggestions:
    
    In section 3.4.2:
    
       Mainly the Flow Export 
       Rate caused by the test traffic during an [RFC2544] measurement MUST 
       be known and reported.
    
    s/Mainly/Most importantly/  ??
    
    In section 4.9.1 and 4.9.2, is it intended that the destination IP
    address recycles to the address for stream 1 after stream 10000?
  5. Pete Resnick: Comment [2012-04-12]:
    As usual, I find most of the uses of 2119 language in a document of this sort to
    be bizarre: I don't understand how a statement like "MUST be part of the
    measurement report" constitutes something "required for interoperation or to
    limit behavior which has the potential for causing harm", and is not simply
    trying "to impose a particular method on implementors where the method is not
    required for interoperability." I'm hard pressed to find any occurrence of 2119
    language in this document that is used as 2119 intended.

draft-ietf-ancp-pon

  1. Adrian Farrel: Comment [2012-04-06]:
    Please don't include citations in the Abstract.
    
    ---
    
    I found just one use of RFC 2119 langauge in this document. I suggest
    fixing it to lower case and removing Section 1.
    
    ---
    
    It would be nice to havesome citations in the Introduction and
    Terminology sections.
    
    ---
    
    I was slightly confused as to whether this is intended as an 
    applicablity statement (how you use SNCP for PON) or the definition
    of the extension of ANCP to PON (see Section 4). It might be nice
    to harmonize the language across the document.
    
    ---
    
    You are to be commended for your skill with ASCII-art. I will use your
    document as evidence that no other graphics tools are needed!
  2. Stephen Farrell: Discuss [2012-04-11]:
    
    The IETF LC announcement appears to have been missing the IPR
    declaration, which is RAND with possibly fee, and was only filed on
    March 27th 3 days before the end of IETF LC.  I think this one has
    to go around the loop again, or am I missing something?
    
  3. Barry Leiba: Comment [2012-04-11]:
    I second Stephen's DISCUSS: Thomas Haag is both an editor on the document and an
    inventor on the disclosed patent.
    
    Also:
    The ToC and the section numbers appear to be confused: Section 9, Security
    Considerations, on page 31, comes after section 10, Access Loop Configuration.
    There's another Section 10 following it, and neither of those sections are in
    the ToC.  Also, Section 13, Acknowledgments, is empty... that's OK if it's
    right, but is there really no one you want to acknowledge here?
  4. Pete Resnick: Comment [2012-04-11]:
    I agree with Adrian's comment: 2119 language is unnecessary in this document and
    should be removed.
    
    I also agree with regard to Stephen's DISCUSS; this must be re-last-called with
    a pointer to the IPR disclosure.
    
    I must say that I'm of two minds about this document, neither of them good. On
    the one hand, the document seems to be applying ANCP to a particular technology
    (in this case PON), and I therefore don't understand why it isn't going for
    Standards Track. On the other hand, from up here in the nosebleed section of the
    layers, the entirety of this document looks like it is either all layer 2 stuff
    or is a big giant walking layer violation. I really don't understand why the
    IETF is devoting WG time to working on technology like this. I was sorely
    tempted to simply Abstain on this document. I don't see what it adds to our
    document series. Perhaps someone can explain.
  5. Sean Turner: Discuss [2012-04-11]:
    1) It's entirely possible this is somewhere in the other ancp specs and I missed
    it.  The draft claims:
    
     Fundamental to leveraging the broadcast capability on the PON for 
     multicast delivery is the ability to assign a single encryption key 
     for all PON frames carrying all multicast channels or a key per set 
     of multicast channels that correspond to service packages, or none.
    
    Is this referring to the key used for IPsec/IKEv2 as required by RFC 6320?  How
    are you distributing the keys to everybody?  It seems (to my untrained eye) like
    stream access in ancp is done through a join request and white/grey/black list
    checking not based on any kind of key material.
    
  6. Sean Turner: Comment [2012-04-11]:
    s11: Maybe strike the first used and add protocol after signalling in the
    following:
    
     Here an appropriate mechanism to protect the used signalling
     needs to be used.
    
    NEW:
    
     Here an appropriate mechanism to protect the signalling protocol
     needs to be used.

draft-johansson-loa-registry

  1. Adrian Farrel: Comment [2012-04-12]:
    Thanks for addressing my Discuss and Comments
  2. Stephen Farrell: Comment [2012-04-09]:
    What is the expectation for stability of the URI and URL
    elements of a registration? Should an expert disallow e.g.
    bit.ly or a blog URL? I think it'd be good to say something
    here. I don't care what you choose for any of the
    reasonable choices:-)
  3. Brian Haberman: Discuss [2012-04-11]:
    I agree with Pete's DISCUSSion and am also not a fan of 2119 keywords being used
    in this document.
    
    I would like to better understand if the concept of a LoA is consistent across
    the types of frameworks mentioned in this document.  The introduction says that
    the registry will support LoAs from a variety of frameworks. However, the
    description of the Context Class in Section 3 talks about XML Schemas compliant
    with SAML 2.0.  Is this registry limited to frameworks compliant with SAML 2.0?
    If so, this needs to be specified.
    
  4. Brian Haberman: Comment [2012-04-11]:
    I am not sure why the second paragraph in the Introduction begins and ends with
    underscores.
    
    Are there any existing LoAs that should be pre-populated in this table?  If so,
    they should be shown in section 6.
  5. Russ Housley: Discuss [2012-04-09]:
    
      The Gen-ART Review by David Black on 1-Apr-2012 lead to some
      discussion and agreement on some document updates.  The updates
      have not appeared yet.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07309.html
    
  6. Barry Leiba: Comment [2012-04-09]:
    I agree with Pete's DISCUSS, as it refers to Section 5.  I see no problem with
    using an Informational document to do what Section 4 does -- IANA will set up
    the registry as stated, and the terms specified here aren't meant to be used
    beyond this document, so Informational is fine.  But Section 5 is telling
    implementors of *something* what they MUST and MUST NOT do, and Informational
    doesn't seem right for that.
    
    The second paragraph of Section 5 leaves me shaking my head.  I'd like to see it
    be more clear about what one MUST NOT infer.  It strikes me as a really wishy-
    washy statement as it is.
    
    Section 7 is missing something after "An implementor of".  (I'd also hyphenate
    "level-of-assurance URIs", to make it clear that it's a compound modifier.)
    
    And I agree with Stephen's comment that the definition of "URI" in Section 3
    should say something, one way or another, about what expectations do or don't
    exist on the lifetime of the URI.  Also, is it acceptable/expected/to-be-avoided
    to have multiple URIs registered that define the same LoA profile?  Given that
    the URI is the registry key, it seems important to expand a bit on this stuff
    here.
  7. Pete Resnick: Discuss [2012-04-07]:
    [I don't feel very strongly about this, so if everyone else is OK with it, I am
    happy to clear this DISCUSS. But I did think it was worthy of DISCUSSion.]
    
    If this was simply the creation of a registry, I wouldn't have thought twice
    about its status as Informational. But section 4 is giving a particular process
    and policy for additions to the registry and section 5 is attributing semantics
    for protocol users (both of them using 2119 language just to make the point).
    Doesn't that mean this should be a BCP since it's defining IETF policy and
    procedure?
    
  8. Pete Resnick: Comment [2012-04-07]:
    I am not a fan of using 2119 language in the registration template. You are not
    giving instructions to implementers on interoperability or damage to the
    network; this is for registrants and IANA. And in all cases I can find, it is
    simply unnecessary. I suggest:
    
    OLD:
    
       The following information MUST be provided with each registration:
    
    NEW:
    
       The following information must be provided with each registration:
    
    OLD:
    
       Informational URL:  A URL containing auxilliary information.  This
          URL MUST minimally reference contact information for the
          administrative authority of the level of assurance definition.
    
    NEW:
    
       Informational URL:  A URL containing auxilliary information.  At a
          minimum this URL needs to reference contact information for the
          administrative authority of the level of assurance definition.
    
    OLD:
    
       Note that it is not uncommon for a single XML Schema to contain
       definitions of multiple URIs.  In that case the registration MUST be
       repeated for each URI.  Both the name and the URI MUST uniquely
       identify the LoA.
    
    NEW:
    
       Note that it is not uncommon for a single XML Schema to contain
       definitions of multiple URIs.  In that case a separate registration is
       to be used for each URI.  The name and the URI are to uniquely
       identify the LoA.
    
    OLD:
    
       The name MUST fulfill the following ABNF:
    
    NEW:
    
       Names are defined by the following ABNF:
    
    OLD:
    
       The following ABNF productions represent reserved values and names
       matching any of these productions MUST NOT be present in any
       registration:
    
    NEW:
    
       Names that correspond to the following ABNF productions are reserved
       values and are not to be registered:
  9. Robert Sparks: Discuss [2012-04-11]:
    Section 5 is confusing (it has drawn comments from several reviewers). Can it be
    reworded to avoid the confusion that's been expressed? Registries are often used
    to help implementations/deployments accidentally use the same name for two
    different purposes. The description here does not seem to consider that part of
    the motivation for having a registry - in fact, it goes to some length to tell
    users to expect there to be names in use that aren't listed, and by inference,
    might collide. Discussing the implications of such a collision may help avoid
    them.
    
  10. Robert Sparks: Comment [2012-04-11]:
    I agree with the comments posted about the second paragraph of section 5. If it
    needs to stay (even in a rewritten form), please consider providing an example
    of the kind of implied meaning that a user of the registry must not assume.

draft-george-travel-faq

  1. Ronald Bonica: Comment [2012-04-09]:
    It's not clear to me that this needs to be documented as an RFC. Maybe a FAQ for
    meeting hosts?
  2. Stewart Bryant: Comment [2012-04-10]:
    re Mass transit:
    
    It would be good if there was an explicit note on safety
    It would be good if
    there was a note as to whether the signs include place names in a western
    character set.
  3. Benoit Claise: Comment [2012-04-10]:
    Section 3.  Helpful information
    
       There are a number of general categories of information listed below.
       Some of it, such as sections 3.1 and 3.3, is necessary for travel,
       the rest can be considered nice-to-have.
    
    If you would change the Table of Content (TOC) to have the current 3.3 as 3.2,
    then you would have nice order in the TOC, sorting by importance/relevance ...
    which you could stress in the document.
    
       3.  Helpful information  . . . . . . . . . . . . . . . . . . . . .  5
         3.1.  Travel . . . . . . . . . . . . . . . . . . . . . . . . . .  5
           3.1.1.  Transit between the airport or train station and
                   primary hotels . . . . . . . . . . . . . . . . . . . .  5
             3.1.1.1.  Taxi information . . . . . . . . . . . . . . . . .  6
             3.1.1.2.  Mass Transit . . . . . . . . . . . . . . . . . . .  6
           3.1.2.  Getting around near the conference venue . . . . . . .  7
         3.2.  Regional/International considerations  . . . . . . . . . . 
           3.2.1.  Health and Safety  . . . . . . . . . . . . . . . . . . 
             3.2.1.1.  Water availability . . . . . . . . . . . . . . . .
           3.3.2.  Money  . . . . . . . . . . . . . . . . . . . . . . . .
         3.3.  Food . . . . . . . . . . . . . . . . . . . . . . . . . . . 
           3.3.1.  Restaurants  . . . . . . . . . . . . . . . . . . . . . 
           3.3.2.  Other Food items . . . . . . . . . . . . . . . . . . . 
         3.4.  Communications and electronics . . . . . . . . . . . . . . 10
         3.5.  Weather  . . . . . . . . . . . . . . . . . . . . . . . . . 11
         3.6.  Fitness  . . . . . . . . . . . . . . . . . . . . . . . . .
  4. Wesley Eddy: Comment [2012-04-09]:
    This seems more like a nice webpage to me than something that needs to be an
    RFC.
  5. Stephen Farrell: Comment [2012-04-05]:
    You might note somewhere that meeting specific sites tend to go away,
    as has happened with ietf75.se which is now something to do with poker
    (or at least the advert offered there when I looked was).

draft-lear-lisp-nerd

  1. Ronald Bonica: Comment [2012-04-11]:
    I support Stewart's DISCUSS. The distinction between this document and the other
    LISP documents, which are also EXPERIMENTAL, is subtle and likely to be lost on
    the reader.
  2. Stewart Bryant: Discuss [2012-04-11]:
    I am putting a discuss on this because I think that the IESG  needs to talk
    about this draft. I will clear the discuss on the call.
    
    I think that the document needs some text in the introduction making it clear
    that the purpose of this draft is to record some early thoughts on this subject
    by the author. Otherwise the RFC will be too easily confused with the ordinary
    output of the LISP WG.
    
    The approach described seems a viable way of running LISP and thus I am not sure
    why this is not being taken through the WG or as AD sponsored. I understand the
    history is that this work pre-dated the WG, but there is now a WG.
    
  3. Stewart Bryant: Comment [2012-04-11]:
    I am surprised that the author did not tackle the database version wrap problem
    by providing some really large number that could never wrap (128 bits springs to
    mind). Given the size of the payload, the size of the database header seems
    unlikely to be an issue.
  4. Stephen Farrell: Comment [2012-04-11]:
    - I think a paragraph putting this into context (as per Eliot's
    mail) would be very valuable for the reader who might otherwise
    think this is the "mainstream" experiment.
    
    - Do you really want to refer to ITU-T x.509 rather than rfc5280 for
    certificates?
    
    - I think you could note that key roll-over and key distribution
    generally are for future study. 
    
    - You could even mention the potential for using DANE if you wanted
    as a different PKI as another possibility for future study.
    
    - CMS is widely deployed (all S/MIME clients include it) but you
    could still say pkcs#7 is more widely supported by libraries and
    tools.
    
    - There doesn't seem to be any way to limit an authority to certain
    EIDs and/or RLOCs, such as is done by SIDR. Might be worth noting?
    
    - If you need revocation checks as part of signature validation,
    then you probably ought say that that's not included in the analysis
    in section 5.
  5. Brian Haberman: Comment [2012-04-10]:
    I agree that this document should be published as a record of one way of doing
    the LISP mapping.  The following commentary is really meant for the IESG and the
    ISE...
    
    Given that there does not appear to be any effort to actually implement this
    specification, does it make sense to publish it as Experimental?  It would seem
    that Informational would be a fine way to document this approach.  If I follow
    some of the arguments that Pete and Ron have made recently, I would even support
    the publication of this document as Historical, but I am not sure if the ISE can
    do that.